DEVOPS Ansible, l’outil de prédilection des Devops
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 par tiellement 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. 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 noeuds 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 noeuds gérés eux- mêmes qui vont à la pêche aux instructions.
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
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 oeuvre 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 noeuds 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/ list_ of_ all_ modules. 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 noeud 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
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 noeuds : 100, 5 000 ou 10 000.
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 noeuds isolés permettent de contrôler les déploiements avec précision. Les licences Tower sont gratuites jusqu’à 10 noeuds ou pour une période d’évaluation. Au- delà, il existe des licences annuelles pour, là encore, 100, 5 000 ou 10 000 noeuds. 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. ✖