Après sa formation d’ingénieur à l’ESME Sudria en 2005, où il a aussi enseigné à temps partiel jusqu’en 2012, Romain Pelisse mit l’Open Source et le logiciel libre au centre de sa carrière. Après dix ans de consulting autour des technologies Java (JBoss et son écosystème) et Linux, d’abord chez Atos Origin puis chez Red Hat, il rejoint le département R&D et l’équipe de maintenance logicielle autour de JBoss EAP.
Au-delà de ses contributions dans le monde Java (notamment sur les projets Wildfly, PMD et Bugclerk), Romain est aussi passionné par Linux, Git, Ansible et Bash, qui sont des sujets récurrents de ses articles dans GNU/Linux Magazine.
Les scripts « Bash » sont omniprésents et forment un outil fabuleux d’automatisation. Malheureusement, ils sont souvent, à tort, vus comme fragiles. Cependant, il existe des options et des techniques, simples d’utilisation, qui permettent de rendre l’exécution de ceux-ci aussi robuste et fiable que nécessaire.
Molecule, l'outil de test d'intégration pour Ansible, dispose d'un mécanisme de pilotage pour contrôler les instances utilisées lors de l'exécution de ses scénarios. Dans cet article, nous étudierons comment implémenter un pilote délégué afin d'utiliser Molecule avec sa propre infrastructure.
Pour faire suite au récent hors-série dédié à Ansible [0], cet article fait le tour de la conception de tests pour le célèbre outil d’automatisation à l’aide de Molecule. Il fait également office d’introduction au sujet, pour un prochain article dédié à la conception d’un pilote délégué (driver delegated) pour Molecule, qui permet d’exécuter ses scénarios sur sa propre plateforme. Mais, pour le moment, abordons déjà Molecule.
Notre précédent chapitre a fait le point sur les bases d’Ansible. Celui-ci va maintenant aller plus loin, en étudiant comment, à l’aide d’extension nommée Collection, on peut augmenter les capacités de l’outil d’automatisation afin de bénéficier de contenu réutilisable supplémentaire. Démonstration par l’exemple et la pratique dans ce second chapitre de notre hors-série.
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.
Dans le chapitre précédent de ce hors-série, nous avons détaillé comment construire sa propre collection et ainsi développer et distribuer sa propre extension pour Ansible. Ceci nous a permis de réutiliser aisément des playbooks et des rôles Ansible. Nous avons néanmoins laissé de côté une fonctionnalité importante de ce format de distribution : la possibilité de déployer un module supplémentaire, soit un ensemble de code Python qui implémente une nouvelle fonctionnalité pour Ansible.
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...
