X
Ansible
Thierry Thaureaux / lundi 17 février 2020 / Thèmes: Développement, Dossier, Dev

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.

Architecture de la plate-forme d’automatisation Red Hat Ansible Automation Platform.

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.

 
Print
4276

x
Rechercher dans les dossiers

Actuellement à la Une...
Le crime organisé en Europe vient de subir un coup dur, avec de nombreuses arrestations et saisies en Suède, en Norvège, aux Pays-Bas ou encore au Royaume-Uni. Des opérations permises par les données collectées sur les serveurs d’EncroChat, un fournisseur de terminaux sécurisés à destination du grand banditisme. 

Retardée par le confinement, la décision du tribunal de Commerce de Paris est enfin tombée : lundi, la justice a donné son feu vert à la reprise d'un Kosc Telecom mal en point par Altitude Infrastructure. Ce dernier débourse 14 millions d'euros et compte investir un total de 100 millions d'euros dans cette activité wholesales only. 

L’éditeur de solutions SaaS pour les services financiers et RH annonce la disponibilité de Workday Help et Workday Journeys qui étendent la puissance de Workday People Experience.

Le fabricant japonais réaligne sa stratégie et se concentre maintenant sur les demandes des clients et l’accompagnement autour de leur transformation numérique.

L’éditeur vient de sortir une nouvelle solution EDR à destination des petites & moyennes entreprises, laquelle rassemble trois outils de réponse aux cyber-incidents. Baptisée Integrated Endpoint Security, ce logiciel intègre dorénavant une console de gestion cloud et les outils Kaspersky EDR Optimum et Kaspersky Sandbox. L’objectif est d’apporter une réponse aux entreprises dont l’expertise et les ressources en matière de cybersécurité sont limitées.

Toutes les autres News
LIVRES BLANCS

Actuellement, il existe un gouffre entre les environnements informatiques traditionnels des entreprises et le cloud public. Tout diffère : les modèles de gestion, de consommation, les architectures applicatives, le stockage, les services de données.


Les avantages de l’architecture hyperconvergée étant de plus en plus reconnus, de nombreuses entreprises souhaitent l’utiliser pour des types d’applications variés. Cependant, son manque de souplesse pour une mise à niveau des ressources de calcul indépendantes de celles de stockage ne lui permet pas d’être utilisée plus largement.

Au cours de l’événement HPE Discover qui s’est tenu en juin 2019, HPE a répondu à cette préoccupation en présentant la plateforme HPE Nimble Storage dHCI.

Ce Livre Blanc IDC se penche sur les exigences du marché ayant stimulé le besoin de solutions HCI plus flexibles, puis il examine brièvement la solution HPE Nimble Storage dHCI en expliquant pourquoi elle répond à ce besoin.


Malgré des investissements massifs dans le développement à hauteur de près de 4 milliards de dollars l'année dernière, près de la moitié du temps consacré au DevOps est perdu dans la répétition des tâches et dans la logistique. Ceci fait que 90% des entreprises qui ont adopté ces pratiques sont déçues par les résultats, selon une étude publiée par le Gartner.


Découvrez dans ce livre blanc, les avantages des toutes nouvelles solutions NETGEAR, pour simplifier et rentabiliser vos déploiements, et gérer votre réseau à distance, où que vous soyez, au bureau ou en télé-travail.


OneTrust est une plateforme logicielle innovante de gestion de la confidentialité, de la sécurité des données personnelles et des risques fournisseurs. Plus de 4 000 entreprises ont choisi de faire confiance à cette solution pour se conformer au RGPD, au CCPA, aux normes ISO 27001 et à différentes législations internationales de confidentialité et de sécurité des données personnelles.

OneTrust vous propose de télécharger le texte officiel du Règlement Général sur la Protection des Données (RGPD). Vous aurez également la possibilité de recevoir la version imprimée de ce texte, sous forme de guide pratique au format A5, spiralé, en complétant le formulaire.


Tous les Livres Blancs
0123movie