Ansible : mises à jour des solutions clés pour automatiser votre monde

La communauté Ansible continue de nous ravir avec de nouveaux contenus – des plugins et des modules – tout en générant beaucoup de travail pour ceux qui s'occupent de l'entretien d'Ansible, car le nouveau code doit être intégré dans les dépôts le plus rapidement possible. Respecter les délais n'est pas toujours facile, et le lancement de certains produits déjà prêts est reporté jusqu'à la prochaine version officielle d'Ansible Engine. Jusqu'à récemment, l'utilisateur final n'avait qu'un seul moyen d'obtenir de nouveaux contenus Ansible – avec la nouvelle version d'Ansible Engine.

Pour remédier à cette situation, la communauté Ansible a commencé à travailler sur des options plus flexibles pour créer et obtenir du contenu.

Red Hat Ansible Engine 2.8 : vers de nouvelles méthodes de traitement du contenu Ansible

En réponse à la demande des utilisateurs, des modifications concernant le traitement du contenu ont été introduites dans Ansible Engine 2.8, qui ne fait pas partie de la version officielle. Ces changements permettront de mettre en place un nouveau mode de livraison du contenu aux utilisateurs, qui ne dépendra pas de ceux qui gèrent Ansible, tant pour le contenu d'Ansible que pour le code de la plateforme elle-même.

Il est prévu que dans les prochaines versions, les créateurs (Creators) de contenu puissent le distribuer sous forme de paquets spéciaux, appelés Collections, qui pourront être installés à l'emplacement d'exécution approprié sur le nœud principal d'Ansible (control node) ou sur le nœud géré (managed node). Le créateur de la collection décrira directement dans le paquet les détails d'exécution via des rôles et des playbooks. Grâce aux modifications mentionnées ci-dessus dans Ansible Engine, les collections deviendront l'un des outils qui permettront de dissocier la publication de contenu de la sortie des versions officielles d'Ansible Engine..

La nouvelle construction Become

La construction Become existe depuis longtemps, mais à partir de la version 2.8, le mot BECOME est par défaut utilisé dans Ansible Engine pour demander le mot de passe lors de l'élévation des privilèges (privilèges sudo sur les systèmes *nix ou mode enable sur les appareils réseau). En d'autres termes, maintenant BECOME est l'outil standard d'élévation des privilèges qui gère déjà la cible par lui-même.

Voici comment un exemple de son utilisation ressemble :

ansible-playbook --become --ask-become-pass site.yml
BECOME password:

De plus, le plugin BECOME a été ajouté à Ansible Engine 2.8, qui fonctionne comme doas sur Linux et runas sur Windows, permettant d'exécuter des actions au nom d'un utilisateur spécifié. Pour élever les privilèges sur les dispositifs réseau, le plugin become enable est utilisé.

Recherche de l'interpréteur Python

Vous avez peut-être rencontré une telle erreur :

/usr/bin/python: bad interpreter: No such file or directory

En fait, dans les versions précédentes d'Ansible Engine, il était considéré par défaut que l'interpréteur Python principal (utilisé par défaut) se trouvait dans le dossier /usr/bin/python. Depuis la version 2.8, Ansible recherche l'interpréteur sur chaque système cible, d'abord en vérifiant la table des chemins et des noms de fichiers exécutables de l'interpréteur Python principal dans différentes distributions, puis en utilisant des listes de secours ordonnées (fallback list), pour plus de détails, consultez le Guide de portage vers Ansible 2.8.

Les fichiers Retry ne sont plus créés par défaut

Vous avez longtemps cherché des fichiers .retry sur votre disque ? Si vous utilisez Ansible depuis un certain temps, vous en avez probablement beaucoup, et ils occupent inutilement de l'espace. À partir de la version 2.8, Ansible Engine ne crée plus ces fichiers par défaut (ce qui peut être annulé en modifiant le fichier ansible.cfg par défaut).

Play Recap mis à jour

Extrait de Guides de portage vers Ansible 2.8:

Play Recap compte désormais les tâches (tasks) avec le statut ignored et rescued, ainsi que ok, changed, unreachable, failed et skipped, grâce à deux nouveaux compteurs de statistiques dans le plugin de rappel par défaut. Les tâches échouées pour lesquelles le drapeau ignore_errors : yes a été défini sont comptées comme ignored. Les tâches échouées pour lesquelles la section rescue a ensuite été exécutée sont comptées comme rescued. Notez qu'à la différence des versions précédentes d'Ansible, les tâches rescued ne sont plus considérées comme échouées.

Dans le tableau Play Recap à la fin de l'exécution du playbook, des colonnes supplémentaires skipped, rescued et ignored ont été ajoutées pour les hôtes :

Clouds et conteneurs

La version 2.8 a introduit des améliorations et des ajouts dans les modules cloud et conteneur pour fonctionner avec Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman et kubevirt. Il convient également de noter que les fichiers TOML peuvent désormais être utilisés comme source d'inventaire.

Paramiko

Utilisez-vous Red Hat Ansible Network Automation ? Ansible Engine 2.8 ne contient plus paramiko et ne dépend plus de lui. Par défaut, Ansible Engine utilise ssh. Si vous avez besoin de paramiko, vous pouvez l'installer avec la commande pip install paramiko.

Si vous avez besoin d'assistance concernant l'utilisation de paramiko dans le cadre de votre abonnement Red Hat, consultez l'article de la base de connaissances. Le package Paramiko est manquant après les nouvelles installations d'Ansible Engine..

Ainsi, la nouvelle version de Red Hat Ansible Engine a été enrichie d'une liste impressionnante d'améliorations et de changements, dont vous pouvez trouver plus de détails. ici.

Red Hat Ansible Tower 3.5 : plus d'automatisation.

À partir de fin mai, une nouvelle version de Red Hat Ansible Tower 3.5 est disponible, offrant plusieurs améliorations importantes pour l'automatisation, et nous allons en parler, si vous n'avez pas encore eu l'occasion de les vérifier vous-même.

Alors, d'abord les points clés :

• Support de Red Hat Enterprise Linux 8 ;
• Support des stockages de données externes avec des plugins appropriés ;
• Support des plugins become dans Ansible Tower.

De plus, la nouvelle version corrige plus de 160 bugs et problèmes enregistrés.

Support de Red Hat Enterprise Linux 8.

Nous répétons souvent que Red Hat Enterprise Linux (RHEL) est une base solide et polyvalente pour construire, par exemple, un cloud hybride. Ansible Tower 3.5 (comme Ansible Engine 2.8) gère les hôtes RHEL 8 et peut également être exécuté sur la plateforme Red Hat Enterprise Linux 8 en tant que nœud de gestion du système Red Hat Ansible Automation.

Stockages de données externes

En plus du stockage de données intégré, Ansible Tower 3.5 peut désormais également utiliser des stockages de données externes, car il est parfois nécessaire de rendre les données plus accessibles pour des applications distribuées. Ainsi, la nouvelle version d'Ansible Tower peut travailler directement avec différentes solutions de stockage de mots de passe et de clés, telles que :

• HashiCorp Vault ;
• CyberArk AIM ;
• CyberArk Conjur ;
• Microsoft Azure Key Vault.

Les détails sur l'utilisation de ces systèmes sont fournis dans les documents du Système de gestion des secrets.

Nouveaux plugins pour la gestion des inventories et l'élévation de privilèges.

En suivant l'évolution d'Ansible Engine, Ansible Tower 3.5 propose de nouveaux plugins d'inventory et un plugin pour le nouvel outil d'élévation des privilèges.

Grâce à nouveaux plugins d'inventory Ansible Tower peut désormais utiliser comme source d'inventory les plateformes Microsoft Azure, Google Cloud Platform et Red Hat OpenStack Platform, ce qui permet de travailler avec des environnements cloud hybrides « prêts à l'emploi ».

Le nouveau plugin d'élévation de privilèges offre un traitement complet des tâches d'élévation de privilèges, offrant beaucoup plus de flexibilité et de contrôle par rapport aux traditionnels sudo et su.

Interface utilisateur remaniée des listes.

La nouvelle version offre une gestion des listes beaucoup plus conviviale. Il est possible de les développer pour afficher des détails et de les réduire afin d'afficher plus d'éléments à l'écran. Les listes peuvent également être triées par différents champs et filtrées pratiquement selon n'importe quelle propriété.

Métriques améliorées

Les métriques disposent désormais de ce qu'on appelle des endpoints (/api/v2/metrics), ce qui permet à Ansible Tower d'être facilement surveillé à l'aide de Prometheus et d'autres systèmes similaires, tout en pouvant utiliser plusieurs systèmes simultanément, y compris des solutions cloud.

Ansible Tower 3.5 est déjà disponible en téléchargement, la dernière version de Red Hat Ansible Tower peut être installée à la fois localement et via Vagrant ou Amazon AMI.

Webinaires sur Ansible : améliorez vos compétences

Une bibliothèque de webinaires en constante expansion sur le sujet : www.ansible.com/resources/webinars-training?hsLang=en-us

Le 4 juin a eu lieu webinaire Quoi de Neuf dans l'Automatisation Ansible, consacré aux nouvelles fonctionnalités et améliorations de Red Hat Ansible Tower et Red Hat Ansible Engine. Prochainement disponible dans la bibliothèque.

Un webinaire en russe sur l'automatisation des réseaux avec Ansible est disponible.

Source : habr.com