Ansible : et si on commençait ?

Dans l’article précédent je t’expliquais que je faisais tout via playbook ansible. Je ne vais pas t’expliquer ce que c’est ni comment l’installer, il y a suffisamment de sites qui en parlent (par exemple tu peux voir ici pour l’installation.

Nous allons surtout voir comment commencer réellement (parce qu’on ne va pas se mentir, c’est assez relou de trouver comment bien faire les choses quand on ne sait pas trop comment ça fonctionne). Je vais te montrer ce que j’ai fait… mais ça ne veut pas dire que cette méthode est la meilleure du monde, juste qu’elle est adaptée à mon besoin personnel.

Mon besoin de départ : installer et faire les updates de serveurs.

On commence par créer (si ce n’est pas déjà fait) un répertoire ansible (dans /opt). Il sera notre répertoire de travail. Il vous faudra, au minimum, un fichier hosts, un playbook.yml et un répertoire roles/. Le fichier hosts renseignera tous vos hosts qui seront touchés par votre playbook. Vous pourrez y classez les hosts par catégorie en fonction de votre besoin.

En voici un exemple :

[local]
localhost ansible_connection=local

[DEV]
host.de.dev.1
host.de.dev.2
host.de.dev.3

[PRE-PROD]
host.de.pp.1
host.de.pp.2
host.de.pp.3

[PROD]
host.de.prod.1
host.de.prod.2
host.de.prod.3

Tu peux aussi y ajouter des variables :

[local]
 localhost ansible_connection=local

[DEV]
 host.de.dev.1
 host.de.dev.2
 host.de.dev.3

[DEV:vars]
 environment=development

[PRE-PROD]
 host.de.pp.1
 host.de.pp.2
 host.de.pp.3

[PRE-PROD:vars]
 environment=preproduction

[PROD]
 host.de.prod.1
 host.de.prod.2
 host.de.prod.3

[PROD:vars]
 environment=production

Ces variables peuvent être ensuite appelées dans le playbook afin de cibler qu’une catégorie. Par exemple, si l’environnement est production, il ne faut pas reboot le serveur n’importe quand.

Nous verrons le playbook un peu plus tard.

Pour ce qui est du répertoire roles/ voici comment je l’ai organisé : Un répertoire par soft (par exemple tmux) qui sera composé de :
* – defaults/*
* – files/*
* – handlers/*
* – meta/*
* – tasks/*
* – templates/*
* – vars/*

Même si ces répertoires ne contiennent pas de fichiers, ils sont présents (histoire d’uniformiser l’architecture et de pouvoir évoluer par la suite si les rôles se complètent).

Les répertoires sont assez parlants, après tu peux toujours aller voir quelques repos git pour voir les constructions.

Un fichier important à renseigner est le tasks/main.yml. C’est ici que seront indiquées les actions à mener.

Si je reprends mon tasks/main.yml de tmux, voici ce que j’ai :

---

- name: install tmux
  apt: name=tmux state=latest

- name: deploy etc_tmux_conf file
  copy:
  src: roles/tmux/templates/etc_tmux_conf
  dest: /etc/tmux.conf
  owner: root
  group: root
  mode: 0644
  backup: no
  force: yes

On va décomposer : – Un fichier .yml pour ansible commence toujours par

• name: permet de nommer l’action (sera visible lorsque le playbook se lancera)
• apt: l’action à mener (ici un apt)

puis name= avec le nom du paquet et state=latest pour la dernière version.

Pour la seconde action, il s’agit simplement de déposer un fichier de conf personnalisé. Comme tu peux le voir, ce fichier de conf est dans templates. Pour faciliter la lecture, je nomme le fichier par le chemin où il est (ici etc/tmux.conf). Il n’y a pas réellement besoin de fichier de configuration pour tmux, mais ça permet surtout de mettre des entêtes du type :

############################################################################
# This file is managed by Ansible, any manual changes will be OVERWRITTEN #
############################################################################

C’est simplement un exemple hein, tu n’es pas obligé(e) de poser un fichier de conf à chaque fois, après c’est toi qui vois.

Nous avons donc notre rôle tmux.

Donc là, nous avons le rôle, une task, une conf et des hosts. Il nous reste qu’à faire un playbook pour relier le tout.

Nous allons donc le créer. Appelons-le par exemple playbook-install.yml.

---

- hosts: "{{ target }}"
  user: username
  become: true
  become_method: sudo
 
roles:
  - { role: tmux }

Et… voilà. Oui hein, c’est pas grand chose. Alors oui, tu peux faire simplement un playbook, sans répertoire ni rien. Sauf que lorsque tu veux ajouter un truc ça devient vite crappy. Alors que là… tu fais un rôle par soft, si ça foire tu sais où chercher, tu commentes ou tu laisses en fonction des machines que tu vises si besoin mais en attendant tu n’as qu’un playbook pour l’installation. Tu peux ajouter tous les softs dont tu as besoin pour ton environnement (Apache/nginx – PHP – PostGreSQL etc…) et les configurer une seule fois… et déployer la même configuration partout.

Après, si toutes les configurations ne sont pas identiques, tu peux aussi jouer avec les variables en fonction de l’host visé… mais bon on y va petit à petit hein 😉

Pour l’update tu peux simplement faire un roles/updates/tasks/main.yml avec :

---

- name: Update packages list
  apt:
  update_cache=yes
  cache_valid_time=3600

- name: Simulate update packages
  apt:
  upgrade: dist
  check_mode: yes
  register: output_s

- name: Check changes
  set_fact:
  update_need: true
  when: not output_s.stdout | search("0 upgraded, 0 newly installed")

- name: update apt cache
  apt:
  update_cache=yes
  cache_valid_time=3600
  tags: update_apt_cache

- name: upgrade all packages
  command: apt-get upgrade -y
  tags: upgrade_packages
  when: update_need is defined and update_need == true

- name: upgrade linux kernel
  apt:
  upgrade: dist
  register: output
  tags: upgrade_linux_kernel

- name: autoremove obsolete packages
  apt:
  autoremove: yes
  tags: auto_remove_packages

- name: clean
  apt:
  autoclean: yes
  tags: clean_packages
Et modifier ton playbook de la sorte :

---

- hosts: "{{ target }}"
  user: username
  become: true
  become_method: sudo

roles:
  - { role: tmux }
  - { role: updates }

Et tu peux bien évidemment faire la même avec un reboot par exemple… et tout ce que tu veux.

Attention toutefois à bien respecter la structure et les espaces, sinon le playbook risque de crasher et tu vas perdre des heures à comprendre pourquoi…

En espérant qu’Ansible te sera moins obscure à présent.

Et comme toujours, si tu as des questions, tu sais où me trouver 🙂