Guide de prise en main d'Ansible à l'usage des administrateurs système pressés

12 mars 2018Curtis Rempel14 minutes (temps de lecture)

Faites-vous partie des nombreux administrateurs système qui ont trop de travail et pas assez de temps ? Vous stressez à l'idée d'effectuer un simple changement de serveur DNS, d'ajuster les paramètres de noyau pour l'ensemble de votre ferme de serveurs ou, pire encore, d'apporter des modifications en fonction de caractéristiques système variables telles que la mémoire installée ou la version du produit ? Vous ne comprenez pas non plus les développeurs lorsqu'ils vous parlent de ce fameux modèle DevOps ?

Red Hat Ansible Automation est un outil d'automatisation sans agent et lisible par l'homme qui utilise le protocole SSH pour orchestrer la gestion des configurations, le déploiement des applications et le provisionnement dans un environnement à un ou plusieurs niveaux. Il repose sur la technologie Open Source Ansible, l'une des technologies Open Source d'automatisation informatique les plus prisées au monde.

Dans cet article de blog, nous allons expliquer les principes de base d'Ansible et comment il peut vous être utile dans votre rôle d'administrateur système pour gérer vos systèmes plus efficacement.

Avant toute chose, prenons le temps de définir certains termes :

Nœud de contrôle : hôte sur lequel vous utilisez Ansible pour exécuter des tâches sur les nœuds gérés

Nœud géré : hôte configuré par le nœud de contrôle

Inventaire des hôtes : liste des nœuds gérés

Commande ad hoc : tâche ponctuelle simple

Playbook : ensemble de tâches reproductibles pour les configurations plus complexes

Module : code qui effectue une tâche courante particulière, comme l'ajout d'un utilisateur, l'installation d'un paquet, etc.

Idempotence : une opération est idempotente si elle donne exactement le même résultat que vous l'exécutiez une fois ou de manière répétée, sans aucune intervention

Environnement

L'environnement utilisé dans cet article comprend un nœud de contrôle (vm1) et quatre nœuds gérés (vm2, vm3, vm4, vm5) exécutés dans un environnement virtuel doté d'une version minimale de Red Hat Enterprise Linux 7.4. Par souci de simplicité, le nœud de contrôle comporte les entrées suivantes dans le fichier /etc/hosts :

192.168.102.211 vm1 vm1.redhat.lab
192.168.102.212 vm2 vm2.redhat.lab
192.168.102.213 vm3 vm3.redhat.lab
192.168.102.214 vm4 vm4.redhat.lab
192.168.102.215 vm5 vm5.redhat.lab

Par commodité pour cette démonstration, je vais attribuer à mon utilisateur système une autorisation sudo sans mot de passe. Votre politique de sécurité sera probablement différente et Ansible est capable de gérer de nombreux cas d'utilisation de la réattribution des privilèges. La réattribution des privilèges de ce compte utilisateur a été configurée via l'entrée suivante dans le fichier /etc/sudoers :

%wheel ALL=(ALL) NOPASSWD: ALL

Il ne s'agit là que d'un exemple. Vous pouvez utiliser votre propre variante de configuration sudo.

Enfin, l'authentification des clés publiques SSH a été configurée et testée pour ce compte utilisateur à partir du nœud de contrôle pour chacun des nœuds gérés.

Installation

Ansible pour Red Hat Enterprise Linux 7 se trouve dans Extras channel. Si vous utilisez Red Hat Enterprise Linux 6, activez le référentiel EPEL. Cette solution sur le Portail client peut également s'avérer utile pour EPEL (Extra Packages for Enterprise Linux). Sur les systèmes Fedora, vous trouverez Ansible dans le référentiel de base.

Une fois le référentiel adéquat configuré, l'installation est simple et rapide :

[curtis@vm1 ~]$ sudo yum install -y ansible

Vérifions la version :

[curtis@vm1 ~]$ ansible --version
ansible 2.4.1.0
 config file = /etc/ansible/ansible.cfg
 configured module search path = [u'/home/curtis/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
 ansible python module location = /usr/lib/python2.7/site-packages/ansible
 executable location = /bin/ansible
 python version = 2.7.5 (default, May 3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)]

Notez le fichier de configuration par défaut. Vous voyez également que Python est requis et présent dans notre installation minimale de la version 7.4 de Red Hat Enterprise Linux.

Configuration

Puisque nous avons déjà configuré les nœuds gérés avec un compte utilisateur, la réattribution des privilèges et l'authentification des clés publiques SSH, nous allons maintenant configurer le nœud de contrôle.

La configuration du nœud de contrôle passe par un fichier de configuration Ansible et un fichier d'inventaire des hôtes.

Fichier de configuration

Comme nous venons de le voir, le fichier de configuration par défaut est /etc/ansible/ansible.cfg.

Vous pouvez modifier ce fichier de configuration global ou effectuer une copie propre à un répertoire particulier. Voici l'ordre suivi pour l'emplacement d'un fichier de configuration :

ANSIBLE_CONFIG (variable d'environnement)

```
ansible.cfg (par répertoire)
```
```
~/.ansible.cfg (répertoire principal)
```
```
/etc/ansible/ansible.cfg (global)
```

Dans cet article, je vais utiliser un fichier de configuration minimale dans le répertoire principal du compte utilisateur ajouté précédemment :

[curtis@vm1 ~]$ cat ansible.cfg 
[defaults] 
inventory = $HOME/hosts

Inventaire des hôtes

Le fichier d'inventaire des hôtes par défaut est /etc/ansible/hosts, mais vous pouvez le modifier dans le fichier de configuration (comme illustré ci-dessus) ou en utilisant l'option -i dans la commande Ansible. Ici, nous allons utiliser un fichier d'inventaire statique simple. Vous pouvez également procéder à des inventaires dynamiques, mais cela dépasse la portée de cet article.

Notre fichier d'inventaire des hôtes se présente comme suit :

[webservers]
vm2
vm3

[dbservers]
vm4

[logservers]
vm5

[lamp:children]
webservers
dbservers

Nous avons défini quatre groupes : webservers sur vm2 et vm3, dbserveurs sur vm4, logservers sur vm5 et lamp, qui comprend les groupes webservers et dbservers.

Vérifions que tous les hôtes peuvent être localisés grâce à ce fichier de configuration :

[curtis@vm1 ~]$ ansible all --list-hosts
 hosts (4):
   vm5
   vm2
   vm3
   vm4

La commande est similaire pour les groupes individuels, comme le groupe webservers :

[curtis@vm1 ~]$ ansible webservers --list-hosts
 hosts (2):
   vm2
   vm3

Maintenant que nous avons validé notre inventaire des hôtes, procédons à une vérification rapide afin de nous assurer que tous nos hôtes sont opérationnels. Pour ce faire, nous allons utiliser une commande ad hoc ayant recours au module ping :

[curtis@vm1 ~]$ ansible all -m ping
vm4 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm5 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm3 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}
vm2 | SUCCESS => {
   "changed": false, 
   "failed": false, 
   "ping": "pong"
}

Comme vous le voyez dans le résultat ci-dessus, tous les systèmes ont renvoyé un résultat positif, aucun changement n'a été apporté et le résultat de chaque « ping » était « pong ».

Vous pouvez obtenir une liste des modules disponibles grâce à la commande suivante :

[curtis@vm1 ~]$ ansible-doc -l

Le nombre de modules intégrés continue à augmenter avec chaque version d'Ansible :

[curtis@vm1 ~]$ ansible-doc -l | wc -l 
1378

La documentation de chaque module est disponible sur la page http://docs.ansible.com/ansible/latest/modules_by_category.html.

La dernière étape d'installation dans notre environnement consiste à configurer vm1 avec Apache et un référentiel Yum Red Hat Enterprise Linux 7 afin que les nœuds gérés puissent installer des paquets supplémentaires :

[root@vm1 ~]# yum install -y httpd
[root@vm1 ~]# systemctl enable httpd
[root@vm1 ~]# systemctl start httpd
[root@vm1 ~]# mkdir /media/iso
[root@vm1 ~]# mount -o loop /root/rhel-server-7.4-x86_64-dvd.iso /media/iso
[root@vm1 ~]# ln -s /media/iso /var/www/html/rhel7

À vos marques, prêts, Ansible !

Maintenant que notre environnement est configuré, nous pouvons commencer à utiliser Ansible.

Étant donné que des paquets supplémentaires devront être installés pour les nœuds gérés, notre première tâche consiste à configurer un référentiel Yum sur chaque hôte à l'aide de ce fichier de configuration :

[curtis@vm1 ~]$ cat dvd.repo
[RHEL7]
name = RHEL 7
baseurl = http://vm1/rhel7/
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 1
gpgcheck = 1

Nous pouvons copier ce fichier sur chacun des nœuds gérés à l'aide d'une commande ad hoc avec le module copy en utilisant l'option -m et en spécifiant les arguments requis avec l'option -a comme suit :

[curtis@vm1 ~]$ ansible all -m copy -a 'src=dvd.repo dest=/etc/yum.repos.d owner=root group=root mode=0644' -b
vm5 | SUCCESS => {
   "changed": true, 
   "checksum": "c15fdb5c1183f360ce29a1274c5f69e4e43060f5", 
   "dest": "/etc/yum.repos.d/dvd.repo", 
   "failed": false, 
   "gid": 0, 
   "group": "root", 
   "md5sum": "db5a5da08d1c4be953cd0ae6625d8358", 
   "mode": "0644", 
   "owner": "root", 
   "secontext": "system_u:object_r:system_conf_t:s0", 
   "size": 135, 
   "src": "/home/curtis/.ansible/tmp/ansible-tmp-1516898124.58-210025572567032/source", 
   "state": "file", 
   "uid": 0
}

[...]

Dans un souci de concision, nous avons enlevé le résultat des hôtes restants.

À ce stade, il convient de noter plusieurs points :

Chaque nœud indique SUCCESS et "changed": true, ce qui veut dire que l'exécution du module a réussi et que le fichier a été créé/modifié. Si nous exécutons à nouveau la commande, le résultat indiquera "changed": false, ce qui veut dire que le fichier est déjà présent et configuré comme requis. En d'autres termes, Ansible n'effectue les changements requis que s'ils n'ont pas déjà été faits. C'est ce que nous appelons « indempotence ».
L'option -b (voir http://docs.ansible.com/ansible/latest/become.html) force la tâche distante à utiliser la réattribution des privilèges (p. ex. sudo), qui est requise pour copier des fichiers dans le répertoire /etc/yum.repos.d.
Pour connaître les arguments dont le module copy a besoin, exécutez la commande suivante :

[curtis@vm1 ~]$ ansible-doc copy

Playbooks

Si les commandes ad hoc sont utiles pour les tests et les tâches ponctuelles simples, les playbooks permettent de capturer un ensemble de tâches reproductibles à exécuter ultérieurement. Un playbook contient un ou plusieurs plays qui définissent un ensemble d'hôtes à configurer et une liste de tâches à effectuer.

Dans notre scénario, nous devons configurer des serveurs web, des serveurs de bases de données et un serveur de journalisation centralisé. Voici les exigences spécifiques à respecter :

Le paquet httpd doit être installé sur les serveurs web, activé et démarré.
Chaque serveur web doit disposer d'une page par défaut avec le texte « Bienvenue dans <hostname> sur <ip address> ».
Chaque serveur web doit disposer d'un compte utilisateur avec un accès adéquat pour la gestion de contenu.
Le paquet MariaDB doit être installé sur les serveurs de bases de données, activé et démarré.
L'hôte du serveur de journaux doit être configuré de façon à accepter les messages de journalisation distants.
Les hôtes des groupes webservers et dbservers doivent envoyer une copie des messages de journalisation à l'hôte du serveur de journaux.

Le playbook suivant (myplaybook.yml) configurera tout ce dont nous avons besoin.

Pendant que vous passez en revue le playbook, notez les points suivants :

Le module user requiert un hachage du mot de passe en texte brut (voir « ansible-doc user » pour plus d'informations). Pour ce faire, vous pouvez utiliser la commande suivante :

[curtis@vm1 ~]$ python -c "from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.encrypt(getpass.getpass())" Password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.

Le contenu de la page web par défaut est créé à l'aide des « faits » collectés auprès de l'hôte. Le module setup permet de découvrir et d'utiliser des faits au sujet de l'hôte :

[curtis@vm1 ~]$ ansible vm2 -m setup

---
- hosts: webservers
 become: yes
 tasks:
   - name: install Apache server
     yum:
       name: httpd
       state: latest

   - name: enable and start Apache server
     service:
       name: httpd
       enabled: yes
       state: started

   - name: open firewall port
     firewalld:
       service: http
       immediate: true
       permanent: true
       state: enabled

   - name: create web admin group
     group:
       name: web
       state: present

   - name: create web admin user
     user:
       name: webadm
       comment: "Web Admin"
       password: $6$rounds=656000$bp7zTIl.nar2WQPS$U5CBB15GHnzBqnhY0r7UX65FrBI6w/w9YcAL2kN9PpDaYQIDY6Bi.CAEL6PRRKUqe2bJYgsayyh9NOP1kUy4w.
       groups: web
       append: yes

   - name: set content directory group/permissions 
     file:
       path: /var/www/html
       owner: root
       group: web
       state: directory
       mode: u=rwx,g=rwx,o=rx,g+s

   - name: create default page content
     copy:
       content: "Welcome to {{ ansible_fqdn}} on {{ ansible_default_ipv4.address }}"
       dest: /var/www/html/index.html
       owner: webadm
       group: web
       mode: u=rw,g=rw,o=r

- hosts: dbservers
 become: yes
 tasks:
   - name: install MariaDB server
     yum:
       name: mariadb-server
       state: latest

   - name: enable and start MariaDB server
     service:
       name: mariadb
       enabled: yes
       state: started

- hosts: logservers
 become: yes
 tasks:
   - name: configure rsyslog remote log reception over udp
     lineinfile:
       path: /etc/rsyslog.conf
       line: "{{ item }}"
       state: present
     with_items:
       - '$ModLoad imudp'
       - '$UDPServerRun 514'
     notify:
       - restart rsyslogd

   - name: open firewall port
     firewalld:
       port: 514/udp
       immediate: true
       permanent: true
       state: enabled

 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

- hosts: lamp
 become: yes
 tasks:
   - name: configure rsyslog
     lineinfile:
       path: /etc/rsyslog.conf
       line: '*.* @192.168.102.215:514'
       state: present
     notify:
       - restart rsyslogd

 handlers:
   - name: restart rsyslogd
     service:
       name: rsyslog
       state: restarted

Exécution du playbook

Notre playbook peut être exécuté à l'aide de la commande suivante :

[curtis@vm1 ~]$ ansible-playbook myplaybook.yml

Le résultat ci-dessous montre que la configuration des serveurs web n'est effectuée que sur vm2 et vm3 (play 1), tandis que la base de données est installée sur vm4 (play 2) et que le serveur de journaux (vm5) est configuré avec play 3. Enfin, play 4 configure les hôtes webservers et dbservers via le groupe « lamp » pour la journalisation à distance.

PLAY [webservers] *********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm2]
ok: [vm3]

TASK [install Apache server] **********************************************************
changed: [vm3]
changed: [vm2]

TASK [enable and start Apache server] *************************************************
changed: [vm2]
changed: [vm3]

TASK [open firewall port] *************************************************************
changed: [vm2]
changed: [vm3]

TASK [create web admin group] *********************************************************
changed: [vm3]
changed: [vm2]

TASK [create web admin user] **********************************************************
changed: [vm3]
changed: [vm2]

TASK [set content directory group/permissions] ****************************************
changed: [vm3]
changed: [vm2]

TASK [create default page content] ****************************************************
changed: [vm3]
changed: [vm2]

PLAY [dbservers] **********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm4]

TASK [install MariaDB server] *********************************************************
changed: [vm4]

TASK [enable and start MariaDB server] ************************************************
changed: [vm4]

PLAY [logservers] *********************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm5]

TASK [configure rsyslog remote log reception over udp] ********************************
changed: [vm5] => (item=$ModLoad imudp)
changed: [vm5] => (item=$UDPServerRun 514)

TASK [open firewall port] *************************************************************
changed: [vm5]

RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm5]

PLAY [lamp] ***************************************************************************

TASK [Gathering Facts] ****************************************************************
ok: [vm3]
ok: [vm2]
ok: [vm4]

TASK [configure rsyslog] **************************************************************
changed: [vm2]
changed: [vm3]
changed: [vm4]

RUNNING HANDLER [restart rsyslogd] ****************************************************
changed: [vm3]
changed: [vm2]
changed: [vm4]

PLAY RECAP ****************************************************************************
vm2                        : ok=11 changed=9 unreachable=0    failed=0 
vm3                        : ok=11 changed=9 unreachable=0    failed=0 
vm4                        : ok=6 changed=4 unreachable=0    failed=0 
vm5                        : ok=4 changed=3 unreachable=0    failed=0

Voilà, c'est terminé !

Vous pouvez vérifier les hôtes webservers à l'aide de la commande suivante :

[curtis@vm1 ~]$ curl http://vm2
Welcome to vm2 on 192.168.102.212
[curtis@vm1 ~]$ curl http://vm3
Welcome to vm3 on 192.168.102.213

Vous pouvez vérifier la journalisation à distance à l'aide de la commande logger sur les hôtes webservers et dbservers :

[curtis@vm1 ~]$ ansible lamp -m command -a 'logger hurray it works'
vm3 | SUCCESS | rc=0 >>

vm4 | SUCCESS | rc=0 >>

vm2 | SUCCESS | rc=0 >>

Confirmation sur le serveur de journalisation central :

[curtis@vm1 ~]$ ansible logservers -m command -a "grep 'hurray it works$' /var/log/messages" -b
vm5 | SUCCESS | rc=0 >>
Jan 30 13:28:29 vm3 curtis: hurray it works
Jan 30 13:28:29 vm2 curtis: hurray it works
Jan 30 13:28:29 vm4 curtis: hurray it works

Conseils et astuces

Si vous êtes un nouvel utilisateur du langage YAML, la syntaxe peut être difficile à appréhender, en particulier l'espacement (pas de tabulations).

Avant d'exécuter un playbooks, vous pouvez vérifier la syntaxe à l'aide de la commande suivante :

$ ansible-playbook --syntax-check myplaybook.yml

L'éditeur Vim avec coloration de la syntaxe est utile non seulement pour apprendre le langage YAML, mais aussi pour identifier les problèmes de syntaxe. Pour activer rapidement Vim pour la syntaxe YAML, ajoutez la ligne suivante à votre fichier ~/.vimrc :

autocmd Filetype yaml setlocal tabstop=2 ai colorcolumn=1,3,5,7,9,80

Si vous souhaitez utiliser un outil offrant des fonctionnalités supplémentaires, y compris la coloration, un plug-in est disponible ici.
Si vous préférez utiliser Emacs plutôt que Vim, activez le référentiel EPEL et installez le paquet emacs-yaml-mode.

Vous pouvez tester un playbook sans apporter de modifications aux hôtes cibles :

$ ansible-playbook --check myplaybook.yml

L'exécution d'un playbook ligne par ligne peut également s'avérer utile :

$ ansible-playbook --step myplaybook.yml

Comme pour un script shell, vous pouvez rendre votre playbook Ansible exécutable et ajouter la commande suivante en haut du fichier :

#!/bin/ansible-playbook

Pour exécuter des commandes shell ad hoc arbitraires, utilisez le module command (le module par défaut si -m n'est pas spécifié). Si vous avez besoin d'utiliser des éléments comme la redirection, des pipelines, etc., utilisez plutôt le module shell.

Accélérez l'écriture des playbooks en vous reportant à la section « EXEMPLES : » de la documentation d'un module spécifique.

Utilisez l'adressage des chaînes de caractères dans les playbooks pour éviter les problèmes liés aux caractères spéciaux dans une chaîne.

La journalisation est désactivée par défaut. Pour l'activer, utilisez le paramètre log_path dans le fichier de configuration Ansible.

J'espère que cet article vous a donné un meilleur aperçu du fonctionnement d'Ansible et de la façon dont il peut vous aider à gagner du temps et à économiser de l'énergie en utilisant des playbooks pour documenter et reproduire des tâches courantes avec simplicité et précision. Pour en apprendre davantage, consultez les pages http://docs.ansible.com et https://www.redhat.com/fr/technologies/management/ansible.

Bonne automatisation !

Curtis Rempel, architecte certifié Red Hat (RHCA), est responsable de compte technique Plateforme et chef d'équipe au Canada. Avant cela, il occupait le poste d'instructeur et d'examinateur certifié Red Hat (RHCI/RHCX). Il a découvert Linux en 1994, avec un CD Red Hat Linux 2.1 de Jon Hall, surnommé « maddog » (chien fou). En tant que responsable de compte technique, il fournit une assistance à des entreprises évoluant dans les secteurs de la finance, des télécommunications et du transport aérien, et dispose d'une vaste expertise en matière d'automatisation, de noyau et de stockage. En savoir plus sur Curtis Rempel.

Un responsable de compte technique Red Hat est un spécialiste produit qui travaille en collaboration avec les services informatiques afin d'établir une stratégie pour assurer la réussite des déploiements, ainsi que des performances et une croissance optimales. Le responsable de compte technique fait partie du service d'expérience et d'engagement client reconnu de Red Hat et vous donne des conseils proactifs pour vous aider à identifier et à résoudre des problèmes potentiels avant qu'ils ne surviennent. Si un problème surgit, votre responsable de compte technique le prendra en charge et y affectera les meilleures ressources afin de le résoudre aussi vite que possible en limitant les perturbations pour votre activité.

Rencontrez des responsables de compte technique à l'occasion d'un événement Red Hat Convergence près de chez vous. Red Hat Convergence est un événement gratuit sur invitation qui offre aux utilisateurs techniques l'opportunité d'approfondir leurs connaissances sur les produits Red Hat et de découvrir de nouvelles façons de tirer parti des technologies Open Source pour atteindre leurs objectifs métier. Organisés dans des villes du monde entier, ces événements vous offrent l'occasion de pratiquer près de chez vous, pendant une journée, afin d'apprendre et de rencontrer des spécialistes Red Hat ainsi que d'autres acteurs du secteur.

La curiosité collaborative est la raison d'être de l'Open Source. Rejoignez-nous au Red Hat Summit qui se tiendra du 8 au 10 mai à San Francisco pour rencontrer des responsables de compte technique et d'autres spécialistes Red Hat en personne. Inscrivez-vous pour seulement 1 100 dollars avec le code CEE18.

Red Hat Cloud Success est conçu pour vous aider à simplifier votre transformation informatique et à accélérer l'adoption des technologies cloud grâce à une expertise approfondie des produits, à des conseils et à une assistance. De la preuve de concept à la production, un spécialiste technique hautement qualifié collaborera avec vous pour garantir la continuité des opérations et assurer la réussite de la mise en œuvre de votre solution cloud. Grâce à cet engagement à durée limitée, Red Hat Cloud Success peut vous aider à planifier et à déployer efficacement des solutions cloud, ainsi qu'à établir une stratégie pour l'avenir.