Playbooks simples 1 – Blog Libre

Cet article fait partie de la série Ansible for the win, contenant les articles suivants :

Cet article a été initialement écrit sur le blog-libre aujourd’hui fermé, certains liens dans l’article peuvent donc être morts.

On rentre dans le vif du sujet. Je vous ai quasi-exclusivement présenté la seule commande ansible mais celle qui fait toute la force d’Ansible, c’est la commande ansible-playbook.

Un playbook, c’est un livre de recettes en bon Français, ça utilise la syntaxe YAML dont le but est d’être simple et le plus lisible possible par des humains. On va commencer par des playbooks simples, je ne rentrerai volontairement pas dans toute la puissance des playbooks. Mon but c’est de vous donner les bases pour vous simplifier l’administration de vos postes et on va voir des exemples pour essayer d’être le plus didactique possible.

Voici déjà quelques commandes de base.

ansible-playbook --help # Afficher l'aide #
ansible-playbook script.yml # Lancer le playbook script.yml, attention il faut que le playbook soit dans le même dossier #
ansible-playbook /etc/ansible/script.yml # Lancer le playbook script.yml peu importe où vous vous trouvez dans l'arborescence de votre poste #
ansible-playbook -i mesjolishosts script.yml # Lorsque l'option i n'est pas renseignée, Ansible prend par défaut le fichier /etc/ansible/hosts mais dans ce cas-ci on prend le fichier mesjolishosts dans le dossier courant #
ansible-playbook -i mesjolishosts script.yml -e MAJOLIEVARIABLE=PC-PUPUCE # -e extra-vars pour ajouter des variables #
ansible-playbook script.yml -vvv # -v verbose mode, -vvv encore plus de verbosité, -vvvv pour débuguer #

Pour toutes les commandes ci-dessous, on se place dans le dossier /etc/ansible.

Utilisation du playbook : ansible-playbook script.yml
Utilité du playbook : Lancer un script sur le(s) client(s), le module script fourni par Ansible copie le script sur la machine distante et l’exécute
Playbook script.yml

---
- name: Transfer and execute a script
  hosts: PC-PUPUCE
  tasks:
    - name: Execute the script
      script: files/script.sh

Explications : Un fichier YAML (extension yml) débute toujours par trois tirets, c’est une convention. On voit ensuite qu’on nomme la tâche (vous pouvez évidemment écrire un truc en Français), on renseigne le host sur lequel on souhaite que s’exécute le playbook. Enfin, on définit la tâche à accomplir. Comme on peut le voir, la syntaxe est très simple et très claire. Méfiez-vous surtout des espaces et saut de lignes, ça peut mettre votre playbook en erreur. Il faut évidemment que vous ayez un script nommé script.sh et étant donné qu’on lance la commande dans le dossier /etc/ansible alors vous devez avoir créé un dossier files dans lequel se trouve un fichier script.sh (en deux mots vous devez avoir : /etc/ansible/files/script.sh)

Utilisation du playbook : ansible-playbook apt_key.yml
Utilité du playbook : Ajouter la clé d’un dépôt sur le(s) client(s), le module apt-key fourni par Ansible fait cela
Playbook apt_key.yml

---
- name: Add an APT signing key
  hosts: server
  tasks:
    - name: Add the APT signing key
      apt_key: url=http://www.dotdeb.org/dotdeb.gpg state=present

Explications : Cette fois-ci, notre playbook concerne non pas un seul host mais un groupe (server), on peut mettre un host, un groupe (ou sous-groupe), all pour tous les hosts. Précédemment nous avions script: et là nous avons apt_key:, c’est à chaque fois le module que nous utilisons. Avec la commande ansible, cela donnerait ansible server -m script etc. et ansible server -m apt_key etc.

Vous remarquerez le state=present et là on va sortir le terme magique Idempotence. D’après Wikipédia, le concept d?’idempotence signifie essentiellement qu’une opération a le même effet qu’on l’applique une ou plusieurs fois, ou encore qu’en la réappliquant on ne modifiera pas le résultat. Ansible est idempotent càd que si vous lancez votre playbook apt_key.yml une première fois, les hosts du groupe server vont récupérer la clé du dépôt Dotdeb. Si vous relancez le playbook apt_key.yml, les hosts du groupe server ne feront rien, la clé est déjà installée càd que le déroulement du playbook sera immédiat. Pour faire simple, la tâche d’ajouter la clé du dépôt Dotdeb n’est faite qu’une seule et unique fois. Ansible est intelligent.

Utilisation du playbook : ansible-playbook clamscan.yml -e host=SRV-WEB
Utilité du playbook : Lancer un scan clamav sur le(s) client(s)
Playbook clamav.yml

---
- name: Scan du serveur
  hosts: "{{ host }}"
  tasks:
    - name: Mise à jour des bases de ClamAV
      command: freshclam
    - name: Scan du serveur
      command: /usr/bin/clamscan -r / --exclude-dir=/sys/ --exclude-dir=/proc/ --exclude-dir=/dev/ --infected

Explications : Comme on peut le voir on utilise le module command pour lancer la commande clamscan. Il est de bon ton de préciser le chemin complet de l’exécutable. La nouveauté c’est bien évidemment « {{ host }} » qui est une variable, elle sera remplacée par SRV-WEB car on a utilisé -e host=SRV-WEB.

Utilisation du playbook : ansible-playbook reboot.yml -e host=all
Utilité du playbook : Rebooter le(s) client(s)
Playbook reboot.yml

---
- name: Reboot all hosts
  hosts: "{{ host }}"
  tasks:
    - name: Reboot hosts
      command: /sbin/reboot

Explications : Je pense que ça se passe de commentaires, c’est simple, clair, aisément compréhensible.

Utilisation du playbook :

ansible-playbook copy.yml -e 'host=server file=ntp.conf dest=/etc/ntp.conf' # vous remarquerez les guillemets pour protéger les variables #

Utilité du playbook : Copier un fichier (de configuration par exemple) sur le(s) client(s)
Playbook copy.yml

---
- name: Copy a file
  hosts: "{{ host }}"
  tasks:
    - name: copy the file
      copy: src=files/{{ file }} dest={{ dest }} owner=root group=root mode=0644 backup=yes

Explications : On a maintenant 3 variables, il est à noter qu’on pourrait évidemment rajouter des variables pour le owner, group et mode mais la plupart du temps ça ne bouge pas beaucoup pour les fichiers de configuration. Remarquez le src=files/, n’oubliez pas de mettre le fichier (ici ntp.conf) dans /etc/ansible/files. L’option backup=yes est une merveille, on comprend tout de suite la puissance de l’idempotence avec. Le fichier ntp.conf n’est pas identique lors du premier lancement du playbook, une sauvegarde de l’ancien fichier est faite puis le nouveau ntp.conf remplace l’ancien. On relance notre playbook, aucune sauvegarde ne sera faite car aucun changement sur le fichier est nécessaire.

Utilisation du playbook : ansible-playbook copy_bash.yml -e host=home
Utilité du playbook : Copier les fichiers de configuration bash pour root
Playbook copy_bash.yml

---
- name: Copy .bashrc, .bash_aliases, .bash_functions for root
  hosts: "{{ host }}"
  tasks:
    - name: copy the files for root
      copy: src=files/{{ item }} dest=/root/{{ item }} owner=root group=root mode=0644 backup=yes
      with_items:
        - .bashrc
        - .bash_aliases
        - .bash_functions

Explications : On voit ici comment gérer une liste avec la variable {{ item }}.

Utilisation du playbook : ansible-playbook install_packages.yml -e host=all
Utilité du playbook : Installer des packages (on fait un update suivi d’un upgrade auparavant)
Playbook install_packages.yml

---
- name: Update APT package cache, upgrade then install packages
  hosts: "{{ host }}"
  tasks:
    - name: Update APT package cache and upgrade
      apt: upgrade=yes update_cache=yes cache_valid_time=7200

    - name: Install packages
      apt: name={{ item }} state=present
      with_items:
        - chkconfig
        - cifs-utils
        - clamav
        - clamav-daemon
        - clamav-freshclam
        - cron-apt
        - debian-goodies
        - fail2ban
        - htop
        - logrotate
        - logwatch
        - manpages-fr
        - manpages-fr-dev
        - manpages-fr-extra
        - ssmtp
        - ncdu
        - ntp
        - rkhunter
        - rsync
        - rsyslog
        - sysv-rc-conf

Explications : Ansible va installer tous ces packages et une fois fait, il ne le refera plus (–> Idempotence). Le playbook idéal pour avoir vos paquets (de base) sur tous vos postes. L’option cache_valid_time=7200 permet d’éviter de mettre à jour le cache si il est plus récent que 2h (7200 secondes).

Utilisation du playbook : ansible-playbook ssh.yml -e host=PC-PUPUCE
Utilité du playbook : Mettre à jour le fichier sshd_config, en faire une sauvegarde si modification il y a puis redémarrer le service SSH
Playbook ssh.yml

---
- name: Copy sshd_config
  hosts: "{{ host }}"
  tasks:
    - name: copy sshd_config
      copy: src=files/sshd_config dest=/etc/ssh/sshd_config owner=root group=root mode=0644 backup=yes
      notify: restart ssh

  handlers:
    - name: restart ssh
      service: name=ssh state=restarted

Explications : On voit ici les handlers, une action qui ne sera exécutée que sur notification d’une autre action. Bien sûr si le fichier sshd_config ne nécessite aucune modification, il n’y a pas de sauvegarde faite et le service SSH n’est pas redémarré. Si le sshd_config nécessite une modification, Ansible fait une sauvegarde de l’ancien sshd_config puis redémarre le service SSH. Attention concernant notify : restart ssh et name: restart ssh, il faut évidemment que ce soit identique. Si vous avez notify : restart ssh et name: restart, ça ne fonctionnera pas.

Utilisation du playbook : ansible-playbook webmin.yml
Utilité du playbook : Installer Webmin
Playbook webmin.yml

---
- name: Install Webmin
  hosts: server
  tasks:
    - name: download webmin
      get_url: url=http://www.webmin.com/download/deb/webmin-current.deb dest=/tmp/webmin.deb

    - name: install dependencies
      apt: name={{ item }} state=present update_cache=yes
      with_items:
        - apt-show-versions
        - libauthen-pam-perl

    - name: install webmin
      apt: deb=/tmp/webmin.deb
      notify: delete webmin.deb

  handlers:
    - name: delete webmin.deb
      shell: rm /tmp/webmin.deb

Pour clôturer cet article (il serait temps ha ha ha), une synthèse de tout ce qu’on a vu. On verra dans un prochain article des playbooks plus complexes avec Globbing et variables proposées par Ansible.

Sources : http://lesaventuresdeyannigdanslemondeit.blogspot.fr/2014/10/comparaison-de-la-gestion-des-fs-avec.html
https://blog.deimos.fr/category/hi-tech/ansible/