Tutoriel Ansible pour débutants : Playbook et commandes

Ansible est l'un des outils d'automatisation open source les plus largement utilisés dans le monde moderne. DevOpsApprécié pour son architecture sans agent et ses fichiers de configuration simples et lisibles, Ansible est un outil d'apprentissage automatique très apprécié. Ce tutoriel pour débutants explique ce qu'est Ansible, comment l'installer et comment utiliser les commandes ad hoc, les playbooks, les rôles et les modèles à travers des exemples pratiques.

Qu'est-ce qu'Ansible?

Ansible est un outil open source d'automatisation et d'orchestration pour le provisionnement, la gestion de la configuration et le déploiement de logiciels. Il configure les systèmes de type Unix et Windows Ansible, qui fournit une infrastructure sous forme de code grâce à son propre langage déclaratif, est souvent comparé à des outils basés sur des agents tels que… Fantoche.

Ansible est populaire pour sa simplicité d'installation, sa facilité de connexion client et son architecture sans agent. Il se connecte aux clients via SSHAinsi, aucun agent spécifique n'est requis côté client. Ansible déploie des modules sur chaque client, ces modules s'exécutent localement et leur résultat est renvoyé au serveur Ansible.

Grâce à son protocole SSH, Ansible se connecte facilement aux clients à l'aide de clés SSH, ce qui simplifie l'ensemble du processus. Les informations client, telles que les noms d'hôte ou les adresses IP et les ports SSH, sont stockées dans des fichiers appelés fichiers d'inventaire. Une fois ces fichiers créés et renseignés, Ansible peut les utiliser.

Pourquoi utiliser Ansible ?

Voici quelques avantages importants de l'utilisation d'Ansible :

• L'un des avantages les plus importants d'Ansible est qu'il est gratuit pour tous.
• Son installation et son utilisation ne nécessitent pas de compétences particulières en administration système, et la documentation officielle est très complète.
• Sa modularité, à travers ses plugins, modules, inventaires et playbooks, fait d'Ansible un excellent outil pour orchestrer de grands environnements.
• Ansible est léger et cohérent, sans aucune contrainte liée au système d'exploitation ou au matériel sous-jacent.
• Il est très sécurisé grâce à sa conception sans agent et à son utilisation des fonctionnalités de sécurité d'OpenSSH.
• Ansible offre une courbe d'apprentissage progressive, grâce à une documentation complète et une structure et une configuration faciles à appréhender.

Ces atouts, surtout lorsqu'on les compare à d'autres Alternatives à AnsibleCela permet d'expliquer son adoption rapide. Avant de l'installer, il est utile de comprendre comment le projet a évolué.

Histoire d'Ansible

Voici les étapes importantes de l'histoire d'Ansible :

• Le projet Ansible a débuté en février 2012. Il a été initialement développé par Michael DeHaan, le créateur de Cobbler et de Func (Fedora Unified Network Controller).
• Initialement appelée AnsibleWorks Inc., la société finançant Ansible a été acquise par Red Hat en 2015 et, par la suite, a rejoint le groupe Red Hat. IBM parapluie.
• Aujourd'hui, Ansible est inclus dans des distributions telles que Fedora Linux, RHEL, CentOS et Oracle Linux.

Termes importants utilisés dans Ansible

Les termes suivants apparaissent tout au long de ce tutoriel Ansible et il est utile de les connaître avant de commencer :

Serveur Ansible

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

Module

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

Tâche

Une tâche est une section qui consiste en une seule procédure à accomplir.

Rôle

Une méthode pour organiser les tâches et les fichiers associés afin de pouvoir les rappeler ultérieurement dans un playbook.

Fait

Informations extraites des variables globales du système client via l'opération gather_facts.

Inventaire

Un fichier contenant des données sur les serveurs clients Ansible. Il est défini dans les exemples suivants comme le fichier hosts.

JOUER

L'exécution d'un plan de jeu.

Maître

Une tâche qui n'est appelée que lorsqu'un notificateur est présent.

Notifier

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

Jour

Un nom attribué à une tâche et qui peut être utilisé ultérieurement pour exécuter uniquement cette tâche ou ce groupe de tâches.

Installation d'Ansible sous Linux

Une fois que vous avez pesé le pour et le contre et décidé d'adopter Ansible, l'étape suivante consiste à l'installer sur votre système. Le guide d'installation ci-dessous décrit les systèmes les plus courants. Linux répartitions.

Installer Ansible sur les systèmes Centos/RedHat

Étape 1) Installez le dépôt EPEL.

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

Étape 2) Installez le paquet ansible.

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

Installer ansible sur Ubuntu/Systèmes Debian

Étape 1) Effectuez une mise à jour des packages.

$ sudo apt update

Étape 2) Installez le paquet software-properties-common.

$ sudo apt install software-properties-common

Étape 3) Installez l'archive du package personnel Ansible.

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

Étape 4) Installez Ansible.

$ sudo apt update
$ sudo apt install ansible

Commandes ad hoc Ansible

L'une des manières les plus simples d'utiliser Ansible est via les commandes ad hoc. Celles-ci sont utiles pour exécuter une commande sur un seul serveur ou sur un groupe de serveurs. Les commandes ad hoc ne sont pas enregistrées pour une utilisation ultérieure, mais elles permettent d'interagir rapidement avec les serveurs de votre choix.

Pour ce tutoriel Ansible, un fichier hosts simple à deux serveurs est configuré, contenant host1 et host2.

Vous pouvez confirmer que les hôtes sont accessibles depuis le serveur Ansible en exécutant une commande ping commande 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 également exécuter la même commande sur un seul hôte 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

Pour copier rapidement un fichier vers plusieurs destinations, utilisez le module copy, qui repose sur SCP. La commande et son résultat ressemblent à ceci :

[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 installerez un paquet avec 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 entendu, toutes les options de l'installateur yum peuvent être utilisées via Ansible, y compris la mise à jour, l'installation, la dernière version et la suppression.

Dans l'exemple ci-dessous, la même commande est utilisée pour supprimer le paquet 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é essentielle d'Ansible est sa capacité à collecter des informations sur un système. Il recueille des données matérielles, logicielles et de version, et stocke chaque valeur dans une variable réutilisable ultérieurement.

Lorsque vous avez besoin d'informations détaillées sur les systèmes qu'Ansible va modifier, le module de configuration collecte ces informations à partir des variables système.

Manuels de jeu Ansible

Manuels de jeu Ansible Les playbooks permettent d'envoyer des commandes à des systèmes distants via des scripts. Ils configurent des environnements système complexes et accroissent la flexibilité en exécutant un seul script sur un ou plusieurs systèmes. Leur fonctionnement s'apparente davantage à celui d'un langage de configuration qu'à celui d'un langage de programmation.

Les commandes de playbook utilisent le format YAML, ce qui réduit la syntaxe requise, mais impose le respect de l'indentation. Comme son nom l'indique, un playbook est un ensemble de séquences de commandes. Grâce à un playbook, vous pouvez attribuer des rôles spécifiques à certains hôtes et des rôles différents à d'autres, orchestrant ainsi plusieurs serveurs dans un seul fichier.

Avant de poursuivre avec les exemples de playbooks, il est utile de définir une tâche. Les tâches constituent l'interface entre les modules Ansible pour les rôles et les playbooks.

Considérons maintenant un playbook Ansible comportant une seule tâche, comme illustré 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 le playbook ci-dessus, les hôtes du groupe 1, définis dans le fichier hosts, sont ciblés pour l'installation du paquet lldpad via le module yum. Le service lldpad créé après l'installation est ensuite démarré à l'aide du module service, qui interagit principalement 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 utilise un fichier d'inventaire. Ce fichier contient une liste de serveurs répartis en groupes, permettant un meilleur contrôle sur des détails tels que l'adresse IP et le port SSH de chaque hôte.

Le fichier d'inventaire de cet exemple de playbook se présente comme suit. Il comporte deux groupes, group1 et group2, contenant 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.

L'exemple de playbook Ansible suivant contient deux playbooks pour deux groupes d'hôtes. Pour le premier groupe, group1, SELinux est activé, et lorsqu'il est activé, un message s'affiche sur l'écran de l'hôte.

Pour le deuxième groupe, le paquet httpd est installé uniquement si ansible_os_family est RedHat et ansible_system_vendor est HP.

Les variables ansible_os_family et ansible_system_vendor sont collectées avec l'option gather_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 spéciales appelées gestionnaires. Un gestionnaire doit avoir un nom unique dans tout le playbook. Les gestionnaires fonctionnent comme une tâche classique, mais ils peuvent être notifiés par un notificateur.

Si un gestionnaire n'est pas notifié lors de l'exécution d'un playbook, il ne s'exécute pas. Toutefois, si plusieurs tâches notifient un gestionnaire, celui-ci ne s'exécute qu'une seule fois, une fois toutes les tâches terminées.

Dans l'exemple ci-dessous, une tâche spécifique comporte une section de notification qui appelle une autre tâche. Si la sortie de la première tâche change, une tâche de gestion est déclenchée. Un exemple courant consiste à modifier un fichier de configuration, puis à redémarrer le service concerné.

---

- 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, « sshd config file modify port », change, c'est-à-dire que le port n'est pas déjà 28675, le port est modifié et la tâche notifie le gestionnaire du même nom, qui redémarre le service sshd.

Explication:

1. Exemple de notifiant
2. Exemple de gestionnaire

Rôles Ansibles

Lorsqu'on travaille avec des playbooks volumineux, il est plus simple de répartir les tâches en rôles. Les rôles facilitent également la réutilisation du travail. Un rôle est 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 de playbook.

Les rôles sont stockés dans des répertoires distincts et suivent une structure de répertoires spécifique.

[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 du répertoire « defaults » contient les variables par défaut utilisées par le playbook. Le répertoire « handlers » stocke les gestionnaires, et le répertoire « meta » contient des informations sur l'auteur et les dépendances de rôle. Le répertoire « tasks » contient le fichier YAML principal du rôle.

Le répertoire de tests contient un exemple de playbook YAML et un exemple de fichier d'inventaire, et il est principalement utilisé pour les tests avant la création du rôle réel.

Le répertoire `vars` contient le fichier YAML où sont définies toutes les variables utilisées par le rôle. Les répertoires `templates` et `files` contiennent les modèles et les fichiers utilisés par les tâches du rôle.

Pour créer l'arborescence de répertoires d'un rôle, utilisez la commande suivante en indiquant le nom du rôle comme dernier paramètre :

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

Ansible fonctionne également très bien avec les modèles, et il utilise Jinja2 comme langage de modèles.

L'exemple suivant montre à quoi ressemble un modèle Jinja2 de base et comment l'utiliser dans un rôle.

Lors de l'exécution, en fonction par exemple 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, en utilisant 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, le répertoire du playbook définit plusieurs variables, notamment resolver_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ôle peuvent également comporter un champ d'étiquette auquel un nom est attribué. Plusieurs tâches peuvent partager la même étiquette, et lors de l'exécution d'un playbook, vous pouvez spécifier une étiquette afin que seules les tâches étiquetées soient exécutées.

Étude de cas Ansible

Dans cette section, nous analysons une étude de cas portant sur un playbook Ansible essentiel comportant trois rôles. L'objectif est de fournir un exemple pratique des concepts abordés jusqu'à présent. Certains exemples précédents de ce tutoriel sont adaptés et réutilisés dans ce playbook.

Vous trouverez ci-dessous la structure du répertoire du playbook. Le fichier YAML utilisé est 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 comporte trois rôles. Le rôle de résolveur configure un serveur de noms spécifique sur les serveurs en copiant un fichier dans le répertoire `/etc/resolv.conf`. Le rôle `httpd` installe le paquet `httpd` avec le module `yum`. Enfin, le troisième rôle active SELinux et notifie l'utilisateur connecté de redémarrer le système. Chaque rôle a été créé avec 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 :

Voici le playbook p4.yml. Il s'exécute sur tous les hôtes, sauf indication contraire sur la ligne de commande, en tant qu'utilisateur root sur le port 22 (SSH), collecte les informations nécessaires avant d'exécuter les rôles, puis exécute les trois rôles. Chaque rôle peut être exécuté indépendamment en spécifiant son étiquette sur 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 }

Vous pouvez ensuite exécuter le playbook p4.yml sur les deux hôtes et interpréter le résultat. La même commande peut être exécutée avec le paramètre `--check` pour une simulation, et avec le paramètre `-k` pour une authentification par mot de passe.

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

Émettre un ping commande sur tous les serveurs définis dans le fichier d'inventaire nommé hosts

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

Émettre un ping commande uniquement sur l'hôte 2

[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

FAQ