VT2022 Ansible fiche

VT Ansible Auteur: Tom DA COSTA (tom.da-costa@etu.univ-grenoble-alpes.fr)

Résumé

Face aux grande nombre croisant de serveur/machines, il faut un outil capable de les maintenir : Ansible. Ansible est un outil de provsionnement, de gestion de configuration et surtout, un outil d'orchestration. Il est capable, à partir d'un inventaire (fichier ini/yml), d'orchestrater l'installation de serveur/machine et les configurer grâce à l'idempotence des modules qui le compose et tout cela en mode bach (sur plusieurs machine en même temps).

Summary

Faced with the increasing number of servers/machines, a tool capable of maintaining them is needed: Ansible. Ansible is a provisioning tool, a configuration management tool and above all, an orchestration tool. It is able, from an inventory (ini/yml file), to orchestrate the installation of servers/machines and to configure them thanks to the idempotence of the modules which compose it and all this in bach mode (on several machines at the same time).

Synthèse

Motivation

Gérer un park de machine (physique ou virtuelle) manuellement est fastidieux et extrêmement chronophage. La communication entre les différents opérateurs doit être sans faille pour assurer la cohérence du park. Internet grandit très vite et les besoins numériques aussi. De plus en plus de serveurs sont nécessaire pour faire tourner l'ensemble des applicatifs nécessaire au quotidien. De plus, les applicatifs hébergés sont de plus en plus complexe et les méthodes de développement évolue avec l'émergence du DevOps et de la méthodologie agile. L'intervention manuelle sur chaque serveur n'est plus souhaité et l'évolution a été l'IaC (Infrastructure as Code) cad "la gestion et le provisionnement de l'infrastructure via le code plutôt que via des processus manuels" (source RedHat). Couplé à un outil de gestion de version tel que git, cela permet de développer son infrastructure comme on développe une application : avec seulement du code.

Contexte

On peut distinguer 3 sous-parties du problème : - Le provisionnement : C'est la mise en place de l'infrastructure qui supportera de l'applicatif. (ex : création de VM, de réseau) - La gestion de configuration : C'est le processus de maintenir une infrastructure dans un état voulu et décrit dans des fichiers de configuration) - L'orchestration : C'est l'automatisation et le rassemblement des processus atomiques qui forme la gestion d'un park de machine / d'une infrastructure.

Il existe des outils pour adresser un ou plusieurs de ces problèmes. Terraform, par exemple est un puissant outil de provisining capable de travailler avec l'ensemble des fournisseurs de services cloud tel que AWS , Azure, OVH, etc ... Pour la gestion de la configuration, on observe ensuite 2 approches très connues ( dans le secteur en tout cas :) ) : Agentless et Agentful. Avec la méthode agentful, un agent (un daemon) est installé sur la machine et il "pull" (=tire) sa configuration d'un serveur central. Puppet est l'exemple parfait de cette approche : le puppet agent va tiré sa configuration du puppet master toutes les 30 secondes. Avec la méthode agentless, les configurations sont "push" (poussées) sur les machines (Hosts) à partir d'une machine ou est installé la logiciel (Master/Management Node) et la base de donné de configuration (pull via git généralement). C'est Ansible, dont voici un résumé : Ansible est crée en 2012 par Ansible Inc puis racheter par RedHat en 2015. Actuellement dans sa version 2.14, ce logiciel est écrit en python, opensource, simple, puissant, agentless, etc... Il est capable de réaliser le provisionnement de machine(, la gestion de configuration) et surtout l'orchestration. L'aspect gestion de configuration de ansible est une conséquence de l'idempotence de ses modules, on y reviendra pas la suite.

Fonctionnement

Le fonctionnement d'ansible est le suivant : Un playbook (ensemble de tâches) est lancé sur une liste de machine. Ansible se connecte simultanément à l'ensemble des machines et récupérer les informations des machines (OS, version de l'interpréteur, IP, nom, etc ... , c'est l'étape "Gather Facts" (rassemblement des faits en français). Il va ensuite réaliser de manière séquentielle l'ensemble des tâches du playbook toujours de façon parallèle sur l'inventaire, cependant, il faut noté qu'il attend que la terminaison de la tâche actuelle sur toutes les machines avant lancer la suivante. Un rapport est ensuite avec le nombre de changement est rendu à la fin de l’exécution d'un playbook. Il est aussi possible d’exécuter des tâches Ad-Hoc cad, en gros, de réaliser une tâche à partir de la commande "ansible" directement dans le terminal sans l'utilisation d'un playbook : > ansible <group_inventaire> -m nom_de_module -a "clé=valeur clé=valeur clé=valeur"

Composants Internes

Voici les différents composants permettant de réaliser tout cela : - Node Manager : Ansible est installé sur un noeux : le Node Manager (= Management Node ou Master Node ou Controler Node, beaucoup de nom qui enfaîte réfère à la même entité). Idéalement, cette machine possède un accès ssh complet et est connecté en réseau avec toutes les machines à administrer. - L'inventory : Il s'agit d'une liste de machine écrit en format ini ou yaml. Il peut s'agir des IP ou alors des noms (hostname résolu ensuite via le DNS). Au sein même de l'inventaire (= du fichier), il est possible d'affecter des machines à des groupes. Il est aussi possible de spécifier pour une machine précise ou pour un group entier, des paramètres tel que la méthode de connexion, l'IP de la machine , l'identité ssh (private key) utilisée, l'utilisateur ssh utilisé, le fait de monter en privilège ou non, etc ... Des variables spécifiques au groupe ou à une machine peuvent être définit ici aussi. - Les tâches : Une tâche = une module avec des paramètres. - Les modules : Il s'agit de petit bout de code autonome écrit python (mais n'importe quel langage retournant du json utilisable) qui est poussé sur la machine distante avec les paramètres décrit dans la tâche. Ce code est exécuté sur l’hôte distant et le résultat est retourné au node manager en json. Les modules sont édité par RedHat mais peuvent aussi être crée par n'importe qui et être publié. On retrouve ici l'esprit de l'opensource. - Les playbooks : C'est un ensemble de tâches réalisées sur un inventaire. On peut voir cela comme un script. - Les roles : Aspect dur à expliquer et à comprendre. Les roles peuvent être vu comme un boût de script réutilisable dans différent playbooks et sont écrit par l'utilisateur. Exemple : role nginx. Ce role, par exemple, peut permettre, à son importation dans un playbook, la présence d'nginx. On peut ensuite appeler des bouts du role dans le playbook afin de, par exemple, déployer notre site web. Un role étant de haut niveau par définition (très abstrait), il est possible de la partager de la même manière qu'un module. - Les handlers : Ce tâche qui sont exécuté à la fin d'un playbook si et seulement si, une autre tâche a apporté un changement. Exemple : Si une tâche a modifié la configuration d'apache, elle va notifié l'handler "reload apache" - Les plugins : Il s'agit de boût de code qui permettent d'augmenter les fonctionnalités d'ansible. Exemple : le plugin azure.azcollection.azure_rm permettant la gestion d'inventaire de ressource azure. - Les collections : il s'agit d'un format standard pour le partage de modules, de roles, de playbooks et de plugins, récupérable avec l'outil ansible-galaxy.

Idempotence

Je vous ait dit plus haut que l'aspect gestion de configuration de ansible vient de l'idempotence de ses modules, il est temps de completer cela. L'idempotence signifie, en informatique, qu'une opération a le même effet qu'on l'applique une ou plusieurs fois. Appliquer à notre contexte, cela veut dire qu'une même tâche peut être appliquer une ou N fois, l'état d'arrivé sera le même. Prenons un exemple concret : On veut faire un script pour rajouter un ligne dans un fichier, disons "coucou\n" dans le fichier "toto". La solution shell direct serait de faire : echo "coucou" >> toto. Cependant, que se passe-t-il si on exécuté 2 fois le script ? On aura 2 fois la ligne "coucou". Ce n'est pas l'état désiré. Avec Ansible, On utilisera le module "lineinfile" avec paramètre path=toto line='coucou'. Si le playbook contenant cette tâche est exécuté 2 fois, on retrouvera la ligne "coucou" qu'une seule fois car la deuxième fois, la ligne était déja présente. La conséquence est que l'on décrit ou lieu de donner une action et ceux exactement comme l'on configure une machine/un logiciel. On passe de 'rajouter la ligne "coucou" dans le fichier "toto"' à 's'assurer que la ligne "coucou" est dans le fichier "toto"'