Ansible Automates Paris

Le 6 février dernier, nous avons eu le plaisir d’assister à l’édition 2020 du Ansible Automates Paris à l’Alternatif.

L’alternatif est un lieu qui se prête bien à ce genre d’événements avec ses différents espaces et notamment son auditorium parfaitement adapté aux présentations.

Le programme de la journée était assez équilibré avec des présentations commerciales, des retours d’expérience clients et les fameuses démonstrations.

Au programme :

• REX Total et Capgemini
• Bonnes pratiques Ansible
• Apartés
• Portfolio automatisation Red Hat et démonstration
• Automatisation du réseau

REX Total

Chez Total l’automatisation s’est inscrite dans une démarche de transformation de l’organisation des équipes d’une structure hiérarchique « traditionnelle » vers une structure basée sur des squads et communautés à la mode Spotify.

L’implémentation d’Ansible fut progressive et incrémentale en commençant par un POC permettant de déployer des machines virtuelles basiques, puis de les intégrer dans l’écosystème du SI et ensuite enrichir les possibilités de configurations et installations post-déploiement.

Les évolutions successives ont permis d’obtenir une chaine de livraison complète depuis le catalogue de service exposé par ServiceNow en passant par Ansible pour piloter les déploiements via CloudForms.

Un des principaux avantages d’Ansible appréciés par Total est l’utilisation de modules qui masquent les évolutions logicielles de bas niveau et permettent de garder les mêmes playbooks au fil du temps.

Le petit conseil pour la route : commencer par automatiser des opérations simples à forte récurrence puis monter en complexité progressivement.

Qu’en dit Capgemini ?

Chez Capgemini les principaux objectifs de l’automatisation étaient la réduction du nombre d’erreurs de réalisation et l’homogénéisation des processus au niveau mondial

Les cas d’usage concernés étaient principalement le déploiement de machines virtuelles ainsi que leur reconfiguration, l’installation de logiciels et la gestion de la configuration des équipements réseau.

Afin de mener à bien la transformation vers l’automatisation, l’accent a été mis sur la promotion du projet auprès des équipes techniques autour du monde mais également sur l’accompagnement pour aider chaque intervenant à se familiariser avec ces nouveaux outils.

La possibilité de réaliser des formulaires dans Ansible Tower a permis de démocratiser l’utilisation des playbooks et par la même faciliter son adoption.

Bonnes pratiques Ansible

Vous allez rire, Ansible se base sur des playbooks pour décrire le séquencement des tâches menant au résultat escompté. Ces playbooks sont écrits dans le langage YAML.

Et ?

Bah nous voilà à écrire du code informatique et je vous le donne en mille, les bonnes pratiques de développement logiciel s’appliquent aussi à l’élaboration de playbooks Ansible.

Concrètement ?

Il est recommandé de gérer son code Ansible avec Git, ça tombe bien, Ansible Tower permet l’intégration avec Git.

La structure de Git doit évoluer en phase avec votre niveau de maturité : commencer avec une branche unique puis créer un dépôt soit par équipe soit par rôle Ansible.

• Avoir une arborescence claire basée sur les recommandations Red Hat est une façon saine de gérer son code.

• Préfixer les variables avec le nom du rôle auquel elles contribuent permet une meilleure lisibilité du code.
• Ne pas stocker les variables dans les playbooks mais plutôt dans des fichiers YAML présents dans les répertoires group_vars et host_vars.
• Penser aux journaux et avertissements qui seront générés lors de l’exécution des playbooks afin qu’ils puissent être exploitables par d’autres outils.
• Utiliser les structures « Block » afin de factoriser le code et par conséquent faciliter sa réutilisation.
• Eviter au maximum de faire appel à des commandes du système cible (shell, batch…), préférer l’utilisation des fonctions mises à disposition par les modules Ansible. Vous trouverez peut être votre bonheur sur Automation Hub.
• Préférer l’exécution des opérations via l’instruction « Become » (équivalent d’un sudo ou runas) au lieu d’utiliser un compte administrateur/root.
• Gérez vos secrets/mots de passe via Ansible vault, ceci permet de consommer des mots de passe sans les faire apparaitre en clair dans vos déclarations de variables. Ce système peut s’interfacer avec des solutions PAM du marché tel que CyberArk, HashiCorp Vault ou Azure Key Vault.
• Profitez de la gestion des habilitations en vous basant sur votre annuaire d’entreprise.
• Avoir des inventaires bien structurés et régulièrement mis à jour pour mieux cibler l’application des playbooks. Il est possible d’agréger des composants provenant de sources différentes en un seul inventaire grâce au concept d’inventaire dynamique. Exemple, un seul inventaire agrégeant les machines virtuelles de plusieurs hyperviseurs.

Vos playbooks doivent également être construits de façon à garantir l’idempotence de leurs actions.

Si vous voulez compléter les bonnes pratiques évoquées, Red Hat met à disposition une documentation plutôt riche sur le sujet.

https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html

Apartés

Ce type d’évènement permet de discuter de divers sujets et j’ai eu l’opportunité de parler orchestration et Terraform.

Orchestration avec un retour d’expérience concernant le couple HP Orchestration Operations et HP Cloud Service Automation : les limitations de HP CSA ont amené un client à le remplacer par Ansible avec succès.

HP OO a survécu mais pour combien de temps ?

Autre information intéressante, Terraform a donné des sueurs froides avec le passage à la version 0.12 et l’arrivée de HCL 2 (HashiCorp Langage) en mai dernier qui a nécessité la réécriture de certains fichiers de configuration et modules. Un récapitulatif des nouveautés est disponible ici

Autre bonne nouvelle, la compatibilité avec AHV pour ceux disposant d’infrastructures Nutanix.

Portfolio Automatisation Red Hat et démonstration 

Vous êtes intéressés par Ansible ?

Ne bougez pas, on en profite pour vous présenter ses compagnons.

Commençons par Red Hat Satellite qui va se charger de licencier et patcher vos OS mais aussi gérer les dépôts de paquets. En collaboration avec Ansible, il se chargera des tâches post-déploiement.

Vient ensuite Red Hat Insights pour gérer les inventaires et faire des analyses d’état de santé du parc, couplé avec Ansible, il pourra déclencher des opérations de remédiation.

Lors de la première démonstration, l’interface de Satellite a permis de cibler la remédiation de machines et d’évaluer l’impact de l’opération grâce au niveau de criticité des vulnérabilités / bugs qui vont être patchés ainsi que le besoin de redémarrage.

Une deuxième démonstration nous a permis de voir le déploiement d’une application de type site e-Commerce composée d’un serveur MS SQL sur RHEL couplé à deux frontaux hébergeant JBoss EAP, le tout sur Azure puis AWS.

Chaque playbook Ansible embarque les spécificités liées à chaque Cloud, ceci permet d’obtenir le même résultat de déploiement quelque soit le Cloud choisi.

Une simulation de panne sur l’un des serveurs JBoss est passée totalement inaperçue et n’a nullement empêché un utilisateur de continuer ses achats sur le site e-Commerce.

L’exercice a été répété avec succès suite au déploiement du même site dans des containers sur une infrastructure OpenShift / Kubernetes, preuve s’il en est, qu’Ansible peut s’adapter à toutes les plateformes.

Automatisation du réseau 

L’un des principaux défis de l’automatisation du réseau est de pouvoir piloter indifféremment n’importe quel équipement.

En effet, un même constructeur peut avoir un jeu de commandes différent en fonction des gammes de produits ce qui rend l’exercice d’autant plus difficile.

Malgré cela, de nombreux cas d’usage s’offrent à nous :

• Sauvegarde et restauration des configurations
• Inventaire des équipements et collecte de leurs spécifications
• Gestion des configurations afin de s’assurer qu’il n’y ait pas de déviance par rapport aux modèles
• Permettre le pilotage depuis des outils tiers comme des ITSM par exemple

L’une des principales difficultés remontées par les administrateurs réseau est d’avoir un inventaire exhaustif et une vue claire de l’ensemble des équipements de leur périmètre.

Dans une optique plus orienté sécurité, l’automatisation du réseau peut également permettre les opérations suivantes :

• Augmentation de la verbosité des journaux en cas d’alerte
• Ciblage des équipements les plus vulnérables afin de les mettre à jour rapidement

Red is Dead

Après cette première participation à Ansible Automates Paris, j’en ressors avec un gout un peu RTFM si l’on veut aller plus loin.

Je comprends bien que le but de ces évènements n’est pas de faire des initiations aux outils mais plutôt de démontrer leurs possibilités. Mais une session « Ansible pour les nuls » m’aurait bien plu.

Là où Red Hat à fait fort, c’est que je ressorts de cet évènement avec l’impression qu’il serait préférable de mettre en œuvre toute une suite d’outils afin de pouvoir automatiser convenablement divers éléments d’infrastructure.

Un travers que l’on retrouve chez d’autres éditeurs également mais qui m’a surpris ici lorsque l’on connait les capacités intrinsèques d’Ansible.

J’aurais également apprécié quelques références à AWX pour ceux qui trouvent Tower trop cher.

Goodies ?

Ou pas. On a eu droit au traditionnel chapeau rouge (toujours bienvenu), un petit carnet et quelques autocollants, faute de sponsors, difficile de faire mieux.