{"id":35513,"date":"2019-10-31T22:04:46","date_gmt":"2019-10-31T19:04:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira\/"},"modified":"2019-10-31T22:04:46","modified_gmt":"2019-10-31T19:04:46","slug":"ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","title":{"rendered":"Ansible : mises \u00e0 jour des solutions cl\u00e9s pour automatiser votre monde","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La communaut\u00e9 Ansible continue de nous ravir avec de nouveaux contenus \u2013 des plugins et des modules \u2013 tout en g\u00e9n\u00e9rant beaucoup de travail pour ceux qui s'occupent de l'entretien d'Ansible, car le nouveau code doit \u00eatre int\u00e9gr\u00e9 dans les d\u00e9p\u00f4ts le plus rapidement possible. Respecter les d\u00e9lais n'est pas toujours facile, et le lancement de certains produits d\u00e9j\u00e0 pr\u00eats est report\u00e9 jusqu'\u00e0 la prochaine version officielle d'Ansible Engine. Jusqu'\u00e0 r\u00e9cemment, l'utilisateur final n'avait qu'un seul moyen d'obtenir de nouveaux contenus Ansible \u2013 avec la nouvelle version d'Ansible Engine.<\/p>\n

\"Ansible
\n
\nPour rem\u00e9dier \u00e0 cette situation, la communaut\u00e9 Ansible a commenc\u00e9 \u00e0 travailler sur des options plus flexibles pour cr\u00e9er et obtenir du contenu.
\n<\/a><\/noindex><\/p>\n

Red Hat Ansible Engine 2.8 : vers de nouvelles m\u00e9thodes de traitement du contenu Ansible<\/h3>\n

\nEn r\u00e9ponse \u00e0 la demande des utilisateurs, des modifications concernant le traitement du contenu ont \u00e9t\u00e9 introduites dans Ansible Engine 2.8, qui ne fait pas partie de la version officielle<\/b>. Ces changements permettront de mettre en place un nouveau mode de livraison du contenu aux utilisateurs, qui ne d\u00e9pendra pas de ceux qui g\u00e8rent Ansible, tant pour le contenu d'Ansible que pour le code de la plateforme elle-m\u00eame.<\/p>\n

Il est pr\u00e9vu que dans les prochaines versions, les cr\u00e9ateurs (Creators) de contenu puissent le distribuer sous forme de paquets sp\u00e9ciaux, appel\u00e9s Collections, qui pourront \u00eatre install\u00e9s \u00e0 l'emplacement d'ex\u00e9cution appropri\u00e9 sur le n\u0153ud principal d'Ansible (control node) ou sur le n\u0153ud g\u00e9r\u00e9 (managed node). Le cr\u00e9ateur de la collection d\u00e9crira directement dans le paquet les d\u00e9tails d'ex\u00e9cution via des r\u00f4les et des playbooks. Gr\u00e2ce aux modifications mentionn\u00e9es 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.<\/b>.<\/p>\n

La nouvelle construction Become<\/h4>\n

\nLa construction Become existe depuis longtemps, mais \u00e0 partir de la version 2.8, le mot BECOME est par d\u00e9faut utilis\u00e9 dans Ansible Engine pour demander le mot de passe lors de l'\u00e9l\u00e9vation des privil\u00e8ges (privil\u00e8ges sudo sur les syst\u00e8mes *nix ou mode enable sur les appareils r\u00e9seau). En d'autres termes, maintenant BECOME est l'outil standard d'\u00e9l\u00e9vation des privil\u00e8ges qui g\u00e8re d\u00e9j\u00e0 la cible par lui-m\u00eame.<\/p>\n

Voici comment un exemple de son utilisation ressemble :<\/p>\n

ansible-playbook --become --ask-become-pass site.yml\nBECOME password:\n<\/code><\/pre>\n
\nDe plus, le plugin BECOME a \u00e9t\u00e9 ajout\u00e9 \u00e0 Ansible Engine 2.8, qui fonctionne comme doas sur Linux et runas sur Windows, permettant d'ex\u00e9cuter des actions au nom d'un utilisateur sp\u00e9cifi\u00e9. Pour \u00e9lever les privil\u00e8ges sur les dispositifs r\u00e9seau, le plugin become enable est utilis\u00e9.<\/p>\n
Recherche de l'interpr\u00e9teur Python<\/h4>\n
\nVous avez peut-\u00eatre rencontr\u00e9 une telle erreur :<\/p>\n
\/usr\/bin\/python: bad interpreter: No such file or directory\n<\/code><\/pre>\n
\nEn fait, dans les versions pr\u00e9c\u00e9dentes d'Ansible Engine, il \u00e9tait consid\u00e9r\u00e9 par d\u00e9faut que l'interpr\u00e9teur Python principal (utilis\u00e9 par d\u00e9faut) se trouvait dans le dossier \/usr\/bin\/python. Depuis la version 2.8, Ansible recherche l'interpr\u00e9teur sur chaque syst\u00e8me cible, d'abord en v\u00e9rifiant la table des chemins et des noms de fichiers ex\u00e9cutables de l'interpr\u00e9teur Python principal dans diff\u00e9rentes distributions, puis en utilisant des listes de secours ordonn\u00e9es (fallback list), pour plus de d\u00e9tails, consultez le Guide de portage vers Ansible 2.8<\/a><\/noindex>.<\/p>\n
Les fichiers Retry ne sont plus cr\u00e9\u00e9s par d\u00e9faut<\/h4>\n
\nVous avez longtemps cherch\u00e9 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. \u00c0 partir de la version 2.8, Ansible Engine ne cr\u00e9e plus ces fichiers par d\u00e9faut (ce qui peut \u00eatre annul\u00e9 en modifiant le fichier ansible.cfg par d\u00e9faut).<\/p>\n
Play Recap mis \u00e0 jour<\/h4>\n
\nExtrait de Guides de portage vers Ansible 2.8<\/a><\/noindex>:<\/p>\n
Play Recap compte d\u00e9sormais les t\u00e2ches (tasks) avec le statut ignored et rescued, ainsi que ok, changed, unreachable, failed et skipped, gr\u00e2ce \u00e0 deux nouveaux compteurs de statistiques dans le plugin de rappel par d\u00e9faut. Les t\u00e2ches \u00e9chou\u00e9es pour lesquelles le drapeau ignore_errors : yes a \u00e9t\u00e9 d\u00e9fini sont compt\u00e9es comme ignored. Les t\u00e2ches \u00e9chou\u00e9es pour lesquelles la section rescue a ensuite \u00e9t\u00e9 ex\u00e9cut\u00e9e sont compt\u00e9es comme rescued. Notez qu'\u00e0 la diff\u00e9rence des versions pr\u00e9c\u00e9dentes d'Ansible, les t\u00e2ches rescued ne sont plus consid\u00e9r\u00e9es comme \u00e9chou\u00e9es.<\/p><\/blockquote>\n
\nDans le tableau Play Recap \u00e0 la fin de l'ex\u00e9cution du playbook, des colonnes suppl\u00e9mentaires skipped, rescued et ignored ont \u00e9t\u00e9 ajout\u00e9es pour les h\u00f4tes :<\/p>\n
\"Ansible<\/p>\n
Clouds et conteneurs<\/h4>\n
\nLa version 2.8 a introduit des am\u00e9liorations et des ajouts dans les modules cloud et conteneur pour fonctionner avec Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman<\/a><\/noindex> et kubevirt<\/a><\/noindex>. Il convient \u00e9galement de noter que les fichiers TOML peuvent d\u00e9sormais \u00eatre utilis\u00e9s comme source d'inventaire.<\/p>\n
Paramiko<\/h4>\n
\nUtilisez-vous Red Hat Ansible Network Automation ? Ansible Engine 2.8 ne contient plus paramiko et ne d\u00e9pend plus de lui. Par d\u00e9faut, Ansible Engine utilise ssh. Si vous avez besoin de paramiko, vous pouvez l'installer avec la commande pip install paramiko.<\/p>\n
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\u00e8s les nouvelles installations d'Ansible Engine.<\/a><\/noindex>.<\/p>\n
Ainsi, la nouvelle version de Red Hat Ansible Engine a \u00e9t\u00e9 enrichie d'une liste impressionnante d'am\u00e9liorations et de changements, dont vous pouvez trouver plus de d\u00e9tails. ici<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5 : plus d'automatisation.<\/h3>\n
\n\u00c0 partir de fin mai, une nouvelle version de Red Hat Ansible Tower 3.5 est disponible, offrant plusieurs am\u00e9liorations importantes pour l'automatisation, et nous allons en parler, si vous n'avez pas encore eu l'occasion de les v\u00e9rifier vous-m\u00eame.<\/p>\n
Alors, d'abord les points cl\u00e9s :<\/p>\n