Architecture de la plate-forme d’automatisation Red Hat Ansible Automation Platform.
Ansible tient une assez belle place dans le palmarès des outils favoris des DevOps. Il permet d’automatiser des traitements sur un parc de machines. Nous allons voir quelles sont ses possibilités en la matière.
Ansible a été développé en 2012 par un dénommé Michael DeHaan. La société Red Hat, la distribution Linux au chapeau rouge, le rachète en octobre 2015. Il devient rapidement un produit phare de sa stack, s’intégrant parfaitement aux solutions de l’éditeur pour la gestion de parc informatique. Après avoir acquis Ansible, Red Hat a développé le module Engine et l’a diffusé sous forme d’offre commerciale. Elle a ensuite créé AWX, la version open source (en amont) de Tower.
Ansible repose sur une approche sans agent, contrairement aux offres concurrentes qui, elles, en installent un, même si certaines configurations agent-less peuvent parfois être possibles. Les outils CM (Configuration Management), ou gestion de configuration, dont Ansible, se retrouvent également en concurrence avec Docker et d’autres technologies d’orchestration pour la gestion des charges de travail en conteneurs.
Un utilisateur Ansible peut créer un container en définissant sa charge utile grâce à son module Ansible Container, un projet open source qui permet de construire, déployer et gérer des conteneurs. Bien qu’ils empiètent partiellement sur le domaine des outils CI (Continuous Integration), ou d’intégration continue tels que Jenkins, Ansible et ses concurrents collaborent aussi avec ces technologies en se chargeant notamment du déploiement après livraison par le pipeline CI d’un code prêt à l’emploi.
Ansible est donc une plate-forme informatique open source de gestion des configurations et d’automatisation.
Modèles YAML
Elle utilise des modèles YAML aisés à modifier et permettant aux utilisateurs de programmer l’exécution automatique de tâches répétitives sans devoir apprendre un langage évolué. Techniquement, Ansible est sans doute moins puissant que DSC, PowerShell étant un langage bien plus élaboré – soit un shell objet disposant de toutes les bibliothèques du .Net. Mais sa faiblesse le rend accessible à la plupart des SysAdmin, ce qui est bien moins évident pour PowerShell qui nécessite, lui, de se mettre à la programmation objet. Ansible remplace l’écriture de scripts ad hoc ou la CM manuelle par un processus automatisé et reproductible.
L’outil transmet en mode push (par défaut) sous forme de modules du code applicatif, des programmes et des instructions de configuration de l’infrastructure informatique à des nœuds dits gérés (serveurs physiques, machines virtuelles ou instances cloud). Il est également possible d’inverser sa configuration pour la transformer en architecture de type pull, dans laquelle ce sont les nœuds gérés eux-mêmes qui vont à la pêche aux instructions.
Vous trouverez sur le site d’Ansible (ansible.com) des informations détaillées sur ses fonctionnalités ainsi que les différents modules disponibles à télécharger.
Les points forts d’Ansible
Les avantages d’Ansible sont sa facilité d’apprentissage et sa grande facilité d’utilisation. Son fonctionnement est très proche de celui d’un script shell, ne demandant pas de compétences pointues en développement. Son déroulement est principalement séquentiel, et donc très proche des tâches “ manuelles ”.
Côté réseau, son utilisation nécessite que les machines cibles à configurer soient accessibles via SSH. Il est donc devenu rapidement le compagnon idéal de tout administrateur système souhaitant automatiser au maximum les tâches, particulièrement sous RHEL et les autres distributions Linux, mais aussi sous Windows. Le fonctionnement d’Ansible repose donc sur une connexion SSH pour pousser les configurations. Il peut gérer le stockage sécurisé des mots de passe SSH (avec ansiblevault), mais il est recommandé d’utiliser plutôt des clefs.
Ansible propose un nombre important de modules, officiels ou communautaires, destinés à faciliter la gestion d’éléments courants (paquets, services, utilisateurs, fichiers de configuration…). Ces modules permettent une certaine abstraction, en ne passant que des arguments pertinents (nom d’utilisateur et mot de passe pour la création d’un utilisateur, par exemple) et assurent une certaine sécurité : le module s’occupe de vérifier les prérequis éventuels et la validité des arguments passés et ne réalise les actions que si cela est nécessaire. Les modules sont appelés via des tâches (tasks), qui sont regroupées dans des rôles (ou playbooks). Le projet Ansible propose aussi des modules prêts à l’emploi via sa communauté, la Ansible galaxy. Le moteur Ansible et ses modules sont principalement écrit en Python. Les playbooks et autres fichiers décrivant les tâches sont, eux, écrits en YAML. Voici à quoi ressemble l’écriture d’une tâche (très) basique pour ajouter un paquet :
- name: "S’assurer que vim est installé"
package: name=vim state=present
Le nombre des modules disponibles pour Ansible est réellement impressionnant.
Vous en trouverez la liste exhaustive ici : https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
L’équivalent en shell aurait été bien plus long et complexe à coder. Les tâches peuvent aussi être taguées, afin de ne cibler que certains éléments de configuration à appliquer. Idem pour les machines. Il est possible de les cibler spécifiquement via leur groupe, leur nom ou une partie de leur nom. Vous pouvez aussi indiquer à partir de quelle tâche commencer un scénario. Enfin, les différentes variables que vous serez amené à utiliser, dans des modèles de fichiers de configuration, par exemple, peuvent être surchargées à différents endroits. Vous pourrez ainsi avoir des valeurs par défaut dans la définition de votre tâche, qui pourront être redéfinies dans l’inventaire et/ou dans la ligne de commande. Ansible propose aussi des drivers afin de piloter le déploiement de machines virtuelles sur des solutions d’hébergement telles que OpenStack, par exemple. Ansible permet de déployer des machines, d’automatiser l’exécution des tâches et de faire de la gestion de configuration sur tout un parc en traitant plusieurs machines simultanément (en mode workflow). L’utilisation d’Ansible consiste à élaborer des instructions sous forme de commandes ou de les regrouper dans des scénarios réutilisables, exécutés dans des playbooks. Ansible met en œuvre une fonction d’orchestration permettant de contrôler l’ordre de l’exécution de ces étapes automatisées. Comme dit précédemment, Ansible est agentless. Cela signifie qu’il ne nécessite l’installation d’aucun logiciel sur les nœuds qu’il gère, ce qui élimine le risque de points de défaillance et de failles de sécurité et, de plus, économise les ressources système. Il met à contribution le protocole (très) sécurisé SSH afin de mettre en place les actions à réaliser, qui sont écrites en YAML. Ansible se décompose en fait en plusieurs éléments : Ansible Playbook, Ansible Vault, Ansible Tower, Ansible Engine et Ansible Galaxy. Ansible-Galaxy (https:// galaxy.ansible.com/) est tout simplement un hub destiné à partager vos modules. Il fonctionne un peu sur le même principe que Docker Hub (http://hub.docker.com/) pour les images Docker.
Les modules d’Ansible
Ansible se décompose en plusieurs modules, dont vous trouverez la liste à l’adresse https://docs.ansible.com/ansible/latest/modules/modules_by_category.html. Il vous est également possible d’en créer de nouveaux à l’aide du langage Python. Cela en fait un outil très ouvert et aisé à étendre. L’outil CM s’intègre à d’autres technologies de gestion et d’hébergement de systèmes, dont les bibliothèques de ressources, les logiciels de surveillance et de collaboration et les plates-formes de Cloud et de virtualisation. Ansible peut aussi contrôler et gérer des systèmes Windows à l’aide de WinRM (Windows Remote Management, le protocole de communication de PowerShell), mais le nœud de contrôle Ansible doit impérativement être sous Linux, avec une version de Python supérieure ou égale à la 2.6. Si vous souhaitez, par exemple, vérifier que votre machine est accessible via le réseau avec le module ping, cela donnera quelque chose de ce genre :
ansible localhost -m ping
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
Pour spécifier d’autres machines du réseau que la vôtre, identifiée par le nom générique localhost (équivalent à l’adresse de boucle locale 127.0.0.0.1 en IPv4), vous devez renseigner le fichier /etc/ansible/hosts avec leurs noms ou leurs adresses IP.
Les playbooks d’Ansible
Ce n’est pas tout de gérer un parc de machines en ligne de commande, il faut aussi automatiser leur exécution. C’est là qu’intervient ansible-playbook. Les scénarios s’écrivent bien sûr en YAML. En voici un exemple :
- hosts: machine-untelle.fr
tasks:
- name: Add APT key for Docker repository
apt_key:
…………………………………………………..
- name: Add APT Docker repository
…………………………………………………..
- name: Update APT cache with new repository
apt: update_cache=yes
- name: Install docker-engine package if it
doesn’t exist
apt: name=docker-engine state=present
- name: Enable and start Docker service
systemd: enabled=yes state=started
name=docker
- name: Install Python
apt: name=python state=present
- name: Install PIP
apt: name=python-pip state=present
- name: docker-py dependency
pip: name=docker-py
- name: Pull Nginx image
docker_image: name=nginx pull=yes
- name: Create a Nginx container docker_container:
name: proxy
image: nginx
published_ports:
- "80:80"
state: present
Vous pouvez ainsi exécuter un scénario complet sur un ensemble de serveurs. Si le scénario n’est pas exécuté sur une machine, un fichier .retry est généré automatiquement afin de relancer la commande exactement à partir de là où elle s’était arrêtée – c’est le principe d’un mode Workflow.
Vault et la protection des données sensibles
Vous aurez parfois besoin de stocker dans vos scénarios des informations sensibles telles que des mots de passe, par exemple. Il n’est bien évidemment pas question de stocker en clair ces données. Vous devrez encoder et décoder ces fichiers. En voici un petit exemple :
# mon_playbook.yml
- hosts: localhost
tasks:
- shell: sshpass -p "foo" scp -r /bar machine@ localhost:/qux
# Encodage du fichier avec Vault
$ ansible-vault encrypt mon_playbook.yml
New Vault password:
Confirm New Vault password:
Encryption successful
# Affichage du playbook crypté
$ cat mon_playbook.yml
$ANSIBLE_VAULT;1.1;AES256
326462313238383863313936646230653834
636636613734366437643365363266628736
49032944
313361636336313731623563396337393564
6165613035353330613761343666333338313
7376366
623862643237333435643661393530663037
6461633136650a31656131653132393763396 3643032 3463373265636232640a6263643066663736
653036336636303531323837643235306464
38383737
…………………………………………………………
…………………………………………………………
……………………………………
# Utiliser le playbook encodé sans le décoder préalablement
$ ansible-playbook mon_playbook.yml
--ask-vault-pass
Vault password:
………………………………….
L’utilisation d’Ansible Vault pour protéger vos playbooks est, somme toute, assez simple.
Ansible Engine et Ansible Tower peuvent être utilisés soit isolément, soit en collaboration, comme le montre cette figure extraite du site ansible.com.
Ansible Engine
Ansible Engine inclut le module central d’exécution de tâches et des modules pour les fonctionnalités de base, la mise en réseau, la communauté et d’autres domaines. Il fonctionne uniquement via une interface en ligne de commande assez proche d’un shell Linux. Ansible Engine propose le même modèle d’abonnement que les autres offres open source de Red Hat, avec des mises à jour de sécurité et de maintenance et un accord de niveau de service (SLA) régissant les éventuelles interventions. Le produit est disponible avec deux niveaux d’assistance internationale. Les licences Engine, proposées en abonnement annuel, se déclinent selon le nombre de nœuds : 100, 5 000 ou 10 000.
Ansible Tower propose des tableaux de bord permettant de surveiller les configurations ainsi qu’une interface graphique plutôt efficace.
Ansible Tower
Ansible Tower est constitué d’un ensemble de fonctions de gestion et de contrôle d’accès aptes à renforcer les fonctionnalités d’Ansible Engine. Cette offre est basée sur le projet AWX. Grâce au contrôle des accès fondé sur les rôles (RBAC, Role-Based Access Control). Il est possible, à l’aide de Tower, de contrôler les identifiants des utilisateurs pour les systèmes gérés. La plateforme, munie d’une interface graphique, propose des tableaux de bord personnalisables, un module de gestion des stocks, un système de notification et des fonctions de planification des tâches. Outre la GUI, une interface ligne de commande (CLI) Tower est disponible. Les utilisateurs de Tower peuvent ainsi intégrer Ansible dans leurs processus et chaînes de compilation. Les groupes d’instances et les nœuds isolés permettent de contrôler les déploiements avec précision. Les licences Tower sont gratuites jusqu’à 10 nœuds ou pour une période d’évaluation. Au-delà, il existe des licences annuelles pour, là encore, 100, 5 000 ou 10 000 nœuds. Les utilisateurs peuvent acquérir Ansible Engine ou Tower séparément, ou bien sous la forme d’une offre groupée.
Installation
L’installation n’est nécessaire que sur la machine d’administration qui servira à se connecter aux machines à configurer. Le seul pré-requis sur les clients est de disposer de Python et de certaines de ses bibliothèques bien spécifiques pour certains modules. Cette machine d’administration doit pouvoir se connecter en SSH aux machines à configurer. Ansible est disponible dans les dépôts officiels. Il peut s’installer via l’outil dnf avec la commande suivante :
dnf install ansible
Utilisation
L’utilisation basique repose sur le répertoire /etc/ansible. L’inventaire des machines est décrit dans le fichier /etc/ansible/hosts. Cela impose d’avoir les droits root pour pouvoir modifier ce fichier. Cette méthode est pratique si vous avez un petit parc de quelques machines à gérer. Pour un nombre de machines plus important, et aussi pour avoir encore plus de souplesse et de portabilité, il vaut mieux passer aux rôles (playbooks) d’Ansible.
Utilisation basique
La liste des machines à configurer doit être rentrée dans le fichier /etc/ansible/ hosts, comme nous l’avons évoqué plus haut. Imaginons que nous ayons deux machines à gérer, que nous les regroupons dans un groupe “ labo ”. Voici quel serait le contenu de ce fichier /etc/ ansible/hosts :
[labo]
machine1
machine2
Le fichier décrivant les tâches à effectuer sur ces machines est donc un playbook (ou rôle). Appelons le playbook.yml. Mettons que nous souhaitions avoir le paquet tcpdump sur toutes les machines du groupe labo, mais le paquet vim seulement sur “ machine1 ”. Voici ce que contiendrait alors le fichier playbook.yml :
- hosts: web
remote_user: root
tasks:
- name: "ensure tcpdump is present"
package:
name: tcpdump
- hosts: srvweb1
remote_user: root
tasks:
- name: "ensure vim is present"
package: name=vim
Et la commande pour exécuter ce playbook :
$ ansible-playbook playbook.yml
Utilisation avec des rôles
Supposons maintenant un projet avec deux machines à configurer destinées à héberger un site internet nécessitant un serveur Apache, un moteur d’exécution PHP et une base de données MySQL. Une machine s’occupera de la partie web (Apache+PHP) et l’autre de la partie base de données (MySQL). Voici à quoi ressemblera notre arborescence :
site-internet/
roles/
commun/
apache/
php/
mysql/
wordpress/
ansible.cfg
inventory
Dans cet exemple, les noms des rôles sont assez explicites. Nous aurons donc un rôle apache qui s’occupera d’installer Apache, un rôle php pour installer PHP, un troisième rôle pour l’installation de MySQL et, enfin, un dernier rôle qui s’occupera de la partie WordPress. Un rôle générique commun pourrait éventuellement contenir des points de configuration utiles pour l’ensemble des machines.
Ansible et Red Hat, le couple parfait
Chez Red Hat, Ansible sert à améliorer de diverses façons l’intégration et le fonctionnement d’autres produits tels que OpenShift ou RHEL (Red Hat Enterprise Linux). Ansible fait partie intégrante du groupe des produits de gestion de systèmes de Red Hat pour l’informatique d’entreprise. Ce groupe comprend également la solution de gestion d’infrastructures Satellite, la structure de gestion de cloud CloudForms et le service de surveillance et de dépannage Red Hat Insights. Les rôles et playbooks d’Ansible permettent de gérer de façon cohérente les produits Red Hat de versions différentes. Ansible est disponible pour Red Hat et d’autres distributions Linux via APT, EPEL (Extra Packages for Enterprise Linux), Fedora et le réseau de diffusion de contenu (CDN, Content Delivery Network) de Red Hat ou, bien évidemment, sur le site d’Ansible (ansible.com).
Ansible, Chef, Puppet and co
Plusieurs produits présentent des approches concurrentes en matière d’automatisation de l’infrastructure, de déploiement d’applications et de CM. Ansible et ses concurrents proposent des offres variées, qu’elles soient purement open source, open source avec prise en charge (support payant, comme RHEL) ou exclusivement commerciales. Il est possible d’utiliser plusieurs de ces solutions en collaboration. Puppet peut, par exemple, exécuter des configurations qui seront ensuite orchestrées par Ansible ou les développeurs peuvent employer Chef pour le déploiement tandis que l’équipe chargée de l’exploitation utilise Ansible. En résumé, les principaux concurrents d’Ansible sont Chef, Puppet, PowerShell DSC (Desired State Configuration) et Salt. La technologie CM d’Ansible est, de fait, beaucoup plus récente que celle de Chef et Puppet, et contemporaine de celle de Salt et PowerShell DSC, le dernier arrivé – notre article du mois dernier. Ansible, tout comme Salt, s’appuie sur le langage YAML, alors que Chef utilise JSON et Ruby et que Puppet s’appuie sur son propre langage déclaratif. Les utilisateurs de PowerShell DSC doivent connaître la programmation PowerShell mais aussi le langage Python sous Linux pour compléter le code PowerShell.