Tutoriel Ansible pour les débutants : playbook, commandes et exemple

Qu'est-ce qu'Ansible?

Ansible est un outil open source d'automatisation et d'orchestration pour le provisionnement de logiciels, la gestion de la configuration et le déploiement de logiciels. Ansible peut facilement exécuter et configurer des systèmes de type Unix ainsi que Windows systèmes pour fournir une infrastructure sous forme de code. Il contient son propre langage de programmation déclaratif pour la configuration et la gestion du système.

Ansible est apprécié pour sa simplicité d'installation, sa facilité d'utilisation en ce qui concerne la connectivité aux clients, son manque d'agent pour les clients Ansible et la multitude de compétences. Il fonctionne en se connectant via SSH aux clients, il n'a donc pas besoin d'un agent spécial côté client, et en poussant les modules vers les clients, les modules sont ensuite exécutés localement côté client et la sortie est renvoyée vers le serveur Ansible.

Puisqu'il utilise SSH, il peut très facilement se connecter aux clients à l'aide de clés SSH, simplifiant ainsi l'ensemble du processus. Les détails des clients, tels que les noms d'hôte ou les adresses IP et les ports SSH, sont stockés dans des fichiers appelés fichiers d'inventaire. Une fois que vous avez créé un fichier d'inventaire et l'avez rempli, ansible peut l'utiliser.

Pourquoi utiliser Ansible ?

Voici quelques avantages/avantages importants de l’utilisation d’Ansible

• L’un des avantages les plus importants d’Ansible est qu’il est gratuit et utilisable par tous.
• Aucune compétence particulière d’administrateur système n’est nécessaire pour installer et utiliser Ansible, et la documentation officielle est très complète.
• Sa modularité concernant les plugins, modules, inventaires et playbooks fait d'Ansible le compagnon idéal pour orchestrer de grands environnements.
• Ansible est très léger et cohérent, et aucune contrainte concernant le système d'exploitation ou le matériel sous-jacent n'est présente.
• Il est également très sécurisé grâce à ses capacités sans agent et à l’utilisation des fonctionnalités de sécurité OpenSSH.
• Un autre avantage qui encourage l'adoption d'Ansible est sa courbe d'apprentissage fluide déterminée par la documentation complète et sa structure et sa configuration faciles à apprendre.

Histoire d'Ansible

Voici des repères importants de l’histoire d’ansible :

• En février 2012, le projet Ansible a débuté. Il a été développé pour la première fois par Michael DeHaan, le créateur de Cobbler et Func, Fedora Unified Network Controller.
• Initialement appelée AnsibleWorks Inc, la société finançant l'outil ansible a été acquise en 2015 par RedHat et a ensuite été transférée, avec RedHat, sous l'égide de IBM.
• À l'heure actuelle, Ansible est inclus dans des distributions comme Fedora Linux, RHEL, Centos et Oracle Linux.

Termes importants utilisés dans Ansible

• Serveur Ansible

  La machine sur laquelle Ansible est installé et à partir de laquelle toutes les tâches et playbooks seront exécutés

• Module

  Fondamentalement, un module est une commande ou un ensemble de commandes Ansible similaires destinées à être exécutées côté client.

• Tâche

  Une tâche est une section qui consiste en une seule procédure à réaliser

• Rôle

  Une façon d'organiser les tâches et les fichiers associés pour être appelés ultérieurement dans un playbook

• Fait

  Informations extraites du système client à partir des variables globales avec l'opération de collecte de faits

• Inventaire

  Fichier contenant des données sur les serveurs clients ansible. Défini dans les exemples ultérieurs en tant que fichier hosts

• JOUER

  Exécution d'un playbook

• Maître

  Tâche qui n'est appelée que si un notificateur est présent

• Notifier

  Section attribuée à une tâche qui appelle un gestionnaire si la sortie est modifiée

• Jour

  Nom défini pour une tâche qui peut être utilisée ultérieurement pour émettre uniquement cette tâche ou ce groupe de tâches spécifique.

Installation d'Ansible sous Linux

Une fois que vous avez comparé et pesé vos options et décidé d'opter pour Ansible, l'étape suivante consiste à l'installer sur votre système. Nous passerons en revue les étapes d'installation dans différents Linux distributions, les plus populaires, dans le prochain petit tutoriel.

Installer Ansible sur les systèmes Centos/RedHat

Étape 1) Installer le dépôt EPEL

[root@ansible-server ~]# sudo yum install epel-release

Étape 2) Installer le paquet ansible

[root@ansible-server ~]# sudo  yum install -y ansible

Installer ansible sur Ubuntu/Systèmes Debian

Étape 1) Effectuer une mise à jour des packages

$ sudo apt update

Étape 2) Installez le package software-properties-common

$ sudo apt install software-properties-common

Étape 3) Installer l'archive de packages personnels Ansible

$ sudo apt-add-repository ppa:ansible/ansible

Étape 4) Installer Ansible

$ sudo apt update
$ sudo apt install ansible

Commandes ad hoc Ansible

L’une des façons les plus simples d’utiliser Ansible consiste à utiliser des commandes ad hoc. Ceux-ci peuvent être utilisés lorsque vous souhaitez émettre des commandes sur un serveur ou un groupe de serveurs. Les commandes ad hoc ne sont pas stockées pour des utilisations futures mais représentent un moyen rapide d'interagir avec les serveurs souhaités.

Pour ce didacticiel Ansible, un simple fichier hôte de deux serveurs sera configuré, contenant host1 et host2.

Vous pouvez vous assurer que les hôtes sont accessibles depuis le serveur ansible en émettant une commande ping sur tous les hôtes.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping
host1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Explication:

1. Statut de la commande, dans ce cas, SUCCÈS
2. Hôte sur lequel la commande a été exécutée
3. La commande émise via le paramètre -m, dans ce cas, ping
4. Avec le paramètre -i, vous pouvez pointer vers le fichier hosts.

Vous pouvez émettre la même commande uniquement sur un hôte spécifique si nécessaire.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Explication:

1. Le paramètre Limit peut être utilisé pour émettre des commandes uniquement sur des hôtes spécifiques dans le fichier de l'hôte
2. Nom de l'hôte tel que défini dans le fichier d'inventaire

Si vous devez copier rapidement un fichier vers plusieurs destinations, vous pouvez utiliser le module de copie d'ansible qui utilise SCP. La commande et son résultat ressemblent donc à ci-dessous :

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"
host1 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.43-256741011164877/source",
    "state": "file",
    "uid": 0
}
host2 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.6-280302911361278/source",
    "state": "file",
    "uid": 0
}

Explication:

1. Module de copie défini
2. Les arguments du module, dans ce cas, sont le chemin absolu source et le chemin absolu de destination.
3. Sortie de la commande Ansible reflétant le succès de la commande de copie et d'autres détails tels que les sommes de contrôle sha1 ou md5 pour la vérification de l'intégrité des fichiers et les métadonnées telles que le propriétaire, la taille ou les autorisations. Il est facile d'installer un package sur un groupe de serveurs. Ansible dispose de plusieurs modules qui interagissent avec les installateurs utilisés, comme yum, apt, dnf, etc.

Dans l'exemple suivant, vous découvrirez comment installer un package via le module yum sur deux hôtes Centos.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [


"Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.xservers.ro\n * epel: fedora.mirrors.telekom.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: remi.schlundtech.de\n * remi-safe: remi.schlundtech.de\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version                Repository       Size\n================================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.leadhosts.com\n * epel: mirrors.nav.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: mirrors.uni-ruse.bg\n * remi-safe: mirrors.uni-ruse.bg\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version                Repository       Size\n================================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Explication:

1. Le module Yum est utilisé dans cet exemple
2. Il définit les arguments du module, et dans ce cas, vous choisirez le nom du package et son état. Si l'état est absent, par exemple, le package sera recherché et s'il est trouvé, supprimé
3. Lorsqu'elle est colorée en jaune, vous verrez la sortie de la commande ansible avec l'état modifié, ce qui signifie dans ce cas, que le package a été trouvé et installé.
4. Statut de la commande yum install émise via ansible. Dans ce cas, le package ncdu.x86_64 0:1.14-1.el7 a été installé.

Bien sûr, toutes les options du programme d'installation de yum peuvent être utilisées via ansible, y compris la mise à jour, l'installation, la dernière version ou la suppression.

Dans l'exemple ci-dessous, la même commande a été émise pour supprimer le package ncdu précédemment installé.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version               Repository        Size\n================================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n================================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version               Repository        Size\n================================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n================================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Explication:

1. Le résultat de la commande yum montre que le package a été supprimé.

Une autre fonctionnalité utile et essentielle qu'ansible utilise pour interagir avec le serveur du client est de rassembler des informations sur le système. Ainsi, il récupère les informations sur le matériel, les logiciels et les versions du système et stocke chaque valeur dans une variable qui peut être utilisée ultérieurement.

Si vous avez besoin d'informations détaillées sur les systèmes à modifier via ansible, la commande suivante peut être utilisée. Le module de configuration rassemble des faits à partir des variables système.

Les commandes du playbook Ansible utilisent le format YAML, il n'y a donc pas beaucoup de syntaxe nécessaire, mais l'indentation doit être respectée. Comme son nom l’indique, un playbook est une collection de pièces de théâtre. Grâce à un playbook, vous pouvez désigner des rôles spécifiques à certains hôtes et d'autres rôles à d'autres hôtes. Ce faisant, vous pouvez orchestrer plusieurs serveurs dans des scénarios très divers, le tout dans un seul playbook.

Pour avoir tous les détails précis avant de continuer avec les exemples de playbook Ansible, nous devons d'abord définir une tâche. Il s'agit de l'interface vers les modules Ansible pour les rôles et les playbooks.

Maintenant, apprenons le playbook Ansible à travers un exemple avec un playbook avec un seul jeu, contenant plusieurs tâches comme ci-dessous :

---

- hosts: group1
  tasks:
  - name: Install lldpad package
    yum:
      name: lldpad
      state: latest
  - name: check lldpad service status
    service:
      name: lldpad
      state: started

Dans l'exemple de playbook Ansible ci-dessus, le groupe1 d'hôtes dans le fichier de l'hôte est ciblé pour l'installation du package lldpad à l'aide du module yum, puis le service lldpad créé après l'installation est ensuite démarré à l'aide du module de service utilisé principalement pour interagir avec l'ensemble systemd.

Explication:

1. Groupe d'hôtes sur lequel le playbook s'exécutera
2. Le module Yum est utilisé dans cette tâche pour l'installation de lldpad
3. Le module de service est utilisé pour vérifier si le service est opérationnel après l'installation

Chaque playbook ansible fonctionne avec un fichier d'inventaire. Le fichier d'inventaire contient une liste de serveurs divisés en groupes pour un meilleur contrôle des détails tels que IP dédiée et port SSH pour chaque hôte.

Le fichier d'inventaire que vous pouvez utiliser pour cet exemple de playbook Ansible ressemble à ci-dessous. Il existe deux groupes, nommés group1 et group2, contenant chacun respectivement host1 et host2.

[group1]
host1 ansible_host=192.168.100.2 ansible_ssh_port=22
[group2]
host2 ansible_host=192.168.100.3 ansible_ssh_port=22

Explication:

1. Nom du groupe
2. Nom d'hôte, avec adresse IP et port ssh, dans ce cas, celui par défaut, 22.

Un autre exemple utile de playbook Ansible contenant cette fois deux jeux pour deux hôtes est le suivant. Pour le premier groupe d'hôtes, group1, selinux sera activé. S'il est activé, un message apparaîtra sur l'écran de l'hôte.

Pour le deuxième groupe d'hôtes, le package httpd sera installé uniquement si ansible_os_family est RedHat et ansible_system_vendor est HP.

Ansible_os_family et ansible_system_vendor sont des variables rassemblées avec l'option rassemble_facts et peuvent être utilisées comme dans cet exemple conditionnel.

---

- hosts: group1
  tasks:
  - name: Enable SELinux
    selinux:
      state: enabled
    when: ansible_os_family == 'Debian'
    register: enable_selinux

  - debug:
      Imsg: "Selinux Enabled. Please restart the server to apply changes."
    when: enable_selinux.changed == true

- hosts: group2
  tasks:
  - name: Install apache
    yum:
      name: httpd
      state: present
    when: ansible_system_vendor == 'HP' and ansible_os_family == 'RedHat'

Explication:

1. Exemple de clause when, dans ce cas, lorsque le type de système d'exploitation est Debian. La variable ansible_os_family est collectée via la fonctionnalité rassemble_facts.
2. La sortie de la tâche est enregistrée pour une utilisation future, avec son nom activate_selinux
3. Un autre exemple de la clause when. Dans ce cas, un message sera affiché pour l'utilisateur hôte si le SELinux a effectivement été activé auparavant.
4. Un autre exemple de la clause when composée de deux règles

Outre les tâches, il existe également des tâches particulières appelées gestionnaires. Les gestionnaires doivent avoir un nom unique dans tout le playbook. Celles-ci fonctionnent de la même manière qu'une tâche normale, mais un gestionnaire peut être averti via un notificateur.

Si un gestionnaire n'est pas averti lors de l'exécution du playbook, celui-ci ne s'exécutera pas. Cependant, si plusieurs tâches notifient un gestionnaire, cela ne sera exécuté qu'une seule fois une fois toutes les tâches terminées.

Dans l'exemple ci-dessous, vous pouvez voir comment une tâche spécifique possède une section de notification qui fait appel à une autre tâche. Si le résultat de la première tâche est modifié, une tâche de gestionnaire sera appelée. Le meilleur exemple est de modifier un fichier de configuration, puis de redémarrer ce service spécifique.

---

- hosts: group2
  tasks:
  - name: sshd config file modify port
    lineinfile:
     path: /etc/ssh/sshd_config
     regexp: 'Port 28675'
     line: '#Port 22'
    notify:
       - restart sshd
handlers
    - name: restart sshd
      service: sshd
        name: sshd
        state: restarted

Dans ce cas, si la première tâche, « port de modification du fichier de configuration sshd » est modifiée, ce qui signifie que si le port n'est pas 28675 en premier lieu, alors il sera modifié et la tâche informera le gestionnaire du même nom d'exécuter , et il redémarrera le service sshd.

Explication:

1. Exemple de notifiant
2. Exemple de gestionnaire

Rôles Ansibles

Lorsqu’il s’agit de playbooks volumineux, il est plus facile de diviser les tâches en rôles. Cela aide également à réutiliser les rôles à l’avenir. Les rôles sont un ensemble de tâches, qui peuvent être déplacées d'un playbook à un autre et exécutées indépendamment, mais uniquement via un fichier playbook.

Les rôles sont stockés dans des répertoires distincts et ont une structure de répertoires particulière.

[root@ansible-server test2]# tree
.
`-- role1
    |-- defaults
    |   `-- main.yml
    |-- handlers
    |   `-- main.yml
    |-- meta
    |   `-- main.yml
    |-- README.md
    |-- tasks
    |   `-- main.yml
    |-- tests
    |   |-- inventory
    |   `-- test.yml
    `-- vars
        `-- main.yml

7 directories, 8 files

Le fichier yaml dans le répertoire defaults contient une liste de variables par défaut qui doivent être utilisées avec le playbook. Le répertoire des gestionnaires est utilisé pour stocker les gestionnaires. Le méta-répertoire est censé contenir des informations sur l'auteur et les dépendances de rôle. Dans le répertoire des tâches se trouve le fichier yaml principal pour le rôle.

Le répertoire tests contient un exemple de fichier de playbook yaml et un exemple de fichier d'inventaire et est principalement utilisé à des fins de test avant de créer le rôle réel.

Le répertoire vars contient le fichier yaml dans lequel seront définies toutes les variables utilisées par le rôle. Les modèles de répertoire et les fichiers de répertoire doivent contenir des fichiers et des modèles qui seront utilisés par les tâches du rôle.

Pour créer l'arborescence de répertoires pour un rôle, vous devez utiliser la commande suivante avec le dernier paramètre, le nom du rôle :

[root@ansible-server test2]# ansible-galaxy init role1

Ansible fonctionne également bien avec les modèles. En tant que langage de création de modèles, il utilise Jinja2.

Dans l'exemple suivant, vous découvrirez à quoi ressemble un modèle jinja2 de base et l'utiliserez dans un rôle.

Au moment de l'exécution, en fonction, disons, du centre de données dans lequel se trouve votre serveur, vous pouvez sélectionner parmi plusieurs serveurs de noms, chacun correspondant à un centre de données, à l'aide de la variable « resolver_ip_addresses ».

{% for resolver in resolver_ip_addresses %}
nameserver {{ resolver }}
{% endfor %}

options timeout:1
options attempts:5
options rotate

Dans cet exemple, dans le répertoire playbook, certaines variables sont définies, dont une variable nommée solver_ip_addresses avec des valeurs différentes selon le centre de données.

- name: Set resolver for server
  template:
    src: dns.j2
    dest: /etc/resolv.conf
    group: root
    owner: root
    mode: "0644"
    tag: resolver	

Explication:

1. Nom du modèle à utiliser. Le modèle se trouve dans le répertoire des modèles dans le chemin du rôle
2. Chemin de destination du nom de fichier à remplacer par le modèle, côté client.
3. Autorisations du fichier de destination

Les tâches de rôles peuvent également avoir un champ de balise auquel est attribué un nom. Plusieurs tâches peuvent partager la même balise. Lors de l'exécution d'un playbook ansible, vous pouvez également spécifier la balise afin que ces tâches soient exécutées.

Étude de cas Ansible

Dans cette section, nous analyserons une étude de cas d'un playbook ansible essentiel qui a trois rôles. Le but de ceci est de donner un exemple pratique de ce dont nous avons parlé précédemment. Certains des exemples utilisés précédemment dans ce didacticiel du playbook Ansible seront adaptés et utilisés dans ce playbook.

Vous trouverez ci-dessous la structure des répertoires du playbook. Le fichier Yaml qui sera utilisé sera p4.yml.

[root@ansible-server test_ansible]# ls -lrth
total 16K
-rw-r--r--. 1 root root   0 Jul  3 10:13 testfile
-rw-r--r--. 1 root root 203 Jul  3 13:30 p1.yml
-rw-r--r--. 1 root root 125 Jul  3 15:00 hosts
-rw-r--r--. 1 root root 488 Jul  3 16:40 p2.yml
-rw-r--r--. 1 root root 188 Jul  4 17:33 p4.yml
drwxr-xr-x. 5 root root  47 Jul  4 17:35 roles
[root@ansible-server test_ansible]# cd roles
[root@ansible-server roles]# ls -lrth
total 12K
drwxr-xr-x. 9 root root 4.0K Jul  4 12:52 httpd
drwxr-xr-x. 9 root root 4.0K Jul  4 13:55 selinux
drwxr-xr-x. 9 root root 4.0K Jul  4 16:54 resolver

Le playbook a trois rôles, dont un appelé résolveur qui définit un serveur de noms spécifique sur les serveurs en copiant un fichier du serveur vers la destination /etc/resolv.conf. Un autre s'appelle httpd et installe le package httpd avec le module yum, et le troisième active SELinux et informe l'utilisateur connecté de redémarrer le système. Chaque rôle a été créé à l'aide de la commande ansible-galaxy.

Rôle de résolution, tâche main.yml :

Rôle Httpd, tâche main.yml :

Rôle Selinux, tâche main.yml :

Vous trouverez ci-dessous le playbook p4.yml défini. Il s'exécutera sur tous les hôtes sauf indication contraire dans la ligne de commande, il s'exécutera en tant qu'utilisateur root sur le port 22 (SSH), il rassemblera des informations avant d'exécuter les rôles et il exécutera les trois rôles mentionnés précédemment. Chaque rôle peut être exécuté indépendamment en spécifiant la balise dans la ligne de commande ansible-playbook avec le paramètre –t.

---

- hosts: all
  user: root
  port: 22
  gather_facts: True
  roles:
    - { role: selinux, tags: selinux }
    - { role: httpd, tags: httpd }
    - { role: resolver, tags: resolver }

Exécuter le playbook p4.yml sur deux hôtes et interpréter la sortie. La même commande peut être exécutée avec le paramètre –check pour un essai à sec. Si vous souhaitez utiliser l'authentification par mot de passe, utilisez le paramètre -k.

Explication:

1. Commande Ansible-playbook qui exécute p4.yml
2. Playbook ignore le rôle SELinux car il est déjà activé.
3. Ansible a découvert que le package httpd est déjà installé, il renvoie donc ok.
4. Le résolveur a été défini et le statut du résolveur de rôle a été modifié.

Aide-mémoire sur les commandes Ansible

Installer le dépôt EPEL sur les systèmes Centos/RHEL

[root@ansible-server ~]# sudo yum install epel-release

Installer le package ansible sur les systèmes Centos/RHEL

[root@ansible-server ~]# sudo  yum install -y ansible

Effectuer une mise à jour des paquets sur Debian/Ubuntu les systèmes

$ sudo apt update

Installez le paquet software-properties-common sur Debian/Ubuntu les systèmes

$ sudo apt install software-properties-common

Installer l'archive personnelle des paquets Ansible sur Debian/Ubuntu les systèmes

$ sudo apt-add-repository ppa:ansible/ansible

Installer ansible sur Debian/Ubuntu les systèmes

$ sudo apt update
$ sudo apt install ansible

Émettez une commande ping sur tous les serveurs définis dans le fichier d'inventaire nommés hosts

 
[root@ansible-server test_ansible]# ansible -i hosts all -m ping

Émettez une commande ping uniquement sur host2

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2

Copiez le fichier « testfile » sur tous les hôtes du fichier d'inventaire

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"

Installer le package ncdu sur tous les hôtes

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'

Supprimer le package ncdu sur tous les hôtes

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'

Créez la structure de répertoires pour le rôle nommé role1.

[root@ansible-server test2]# ansible-galaxy init role1

Playbook p4.yml à sec

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml --check

Exécutez le playbook p4.yml avec authentification par mot de passe pour tous les hôtes

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml -k

Résumé

Dans un monde où la technologie évolue continuellement à un rythme rapide et connaît une croissance incroyablement rapide en même temps, les administrateurs système et les ingénieurs DevOps doivent réfléchir à différentes approches sur la façon d'automatiser les tâches de routine et d'orchestrer de grands pools de serveurs.

Bien qu'il y ait beaucoup alternative à Ansible (Chef, Puppet) qui font la même chose avec quelques différences, Ansible a réussi à les dépasser tous grâce à sa simplicité, sa sécurité améliorée et, surtout, sa courbe d'apprentissage fluide. En raison de ces qualités et de l’adoption rapide d’Ansible, nous avons créé un didacticiel rempli d’exemples afin que vous puissiez vivre une première expérience encore plus fluide de travail avec Ansible.

Dans ce didacticiel sur les bases d'Ansible, nous avons décrit Ansible et parlé un peu de son histoire. Nous avons évoqué les points forts d'Ansible et les avantages qu'ansible peut apporter à l'automatisation et à l'orchestration d'infrastructures de différentes tailles. Nous avons défini les termes essentiels utilisés par Ansible et défini la structure des playbooks Ansible. Des exemples détaillés accompagnaient toutes les informations avec des explications détaillées.