Pelisse Romain

Avec l’arrivée du cloud il y a maintenant une bonne décennie, l’automatisation est devenue un must de l’infrastructure logicielle...

Le précédent chapitre a illustré l’utilisation et le déploiement de collection Ansible afin de réutiliser une automatisation existante au sein de son playbook. Ce nouveau chapitre va aller plus loin dans cette démarche, en évoquant comment concevoir sa propre collection afin de distribuer et réutiliser son propre contenu.

Bienvenue dans ce hors-série spécial dédié à Ansible ! Nous commencerons celui-ci par un tour rapide des fonctionnalités et jargons associés à ce fabuleux outil d’automatisation afin de nous assurer que le lecteur possède toutes les informations nécessaires à la bonne compréhension de l’intégralité de ce magazine.

Si le Bash est aujourd’hui souvent critiqué pour sa relative complexité, et à tort pour son manque de robustesse, il reste néanmoins un outil d’automatisation fondamental, comme nous allons l’illustrer dans cet article. En effet, grâce à lui et aussi à la puissance de SSH, nous allons résoudre une difficulté d’optimisation d’infrastructure, en l’occurrence sur un serveur d’intégration continue Jenkins, d’une manière fiable et solide, mais également plus performante...

Ansible est une solution d’automatisation fabuleuse, mais qui requiert l’utilisation de nombreux outils et la mise en place d’un environnement d’exécution approprié à ses besoins, disposant des versions adaptées du logiciel en lui-même comme du langage Python. Afin de faciliter ceci, le projet propose aujourd’hui un nouveau point d’entrée envers l’intégralité de son écosystème : Ansible Navigator. Démonstration et tour d’horizon de celui-ci !

Ansible est un fabuleux outil d’automatisation, mais la gestion de son environnement d’exécution (version utilisée de l’outil ou de Python, librairies, dépendances système) se révèle parfois un véritable casse-tête… qui est désormais résolu par l’introduction des « Ansible Environnements Execution ». Explication détaillée de cette fonctionnalité dans cet article !

Dans notre précédent article [1], nous avons effectué la refonte d’un script Scala sous la forme d’une application Java à l’aide de Quarkus. L’ensemble des fonctionnalités requises ayant été implémenté, nous allons maintenant étudier dans ce nouvel article comment déployer cette solution. Ceci nous permettra, en particulier, d’explorer la possibilité offerte par Quarkus de générer une application native au système cible, plutôt qu’une application Java usuelle, qui nécessite l’installation de sa machine virtuelle.

Lors d’un précédent article, nous avons entièrement automatisé la mise en place d’un serveur Apache Tomcat à l’aide d’Ansible [1]. Dans celui-ci, nous reprenons là où nous nous sommes arrêtés, afin d’aller un peu loin et d’évoquer, en détail, comment personnaliser son installation un peu plus et configurer, de manière plus spécifique, le serveur web Java, cette fois-ci dans sa version supportée par Red Hat, nommée JBoss Web Server.

Quarkus est un cadre d’exécution Java séduisant et dédié la réalisation de service ReST à la fois performant, léger et aisé à déployer. Grâce à une récente et audacieuse innovation, le framework permet désormais de créer des applications en ligne de commande. Démonstration par la pratique, dans cet article, de cette nouvelle et excitante fonctionnalité du projet.