Pelisse Romain

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.

Une distribution Linux est l’assemblage fonctionnel d’un grand nombre de logiciels différents, qui offrent tous des options de paramétrage à des fins, entre autres, d’optimisation. Ainsi, il est possible de modifier de très nombreux aspects de l’exécution de ces logiciels pour optimiser les performances de la machine. C’est une tâche dantesque qui, heureusement, est largement simplifiée par l’outil tuned. Démonstration par l’exemple dans cet article.

Une fois une faille découverte et corrigée, il est crucial de mettre à jour au plus vite ses systèmes. Cependant, avec la complexité des infrastructures logicielles, il n’est pas toujours aisé d’effectuer la manœuvre. C’est là que disposer d’un outil d’automatisation aussi complet et puissant qu’Ansible se révèle un atout considérable. Démonstration par la pratique…

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.

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.

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.