Avec l’arrivée du cloud, la gestion de configuration de manière automatique est devenue obligatoire. Un serveur a maintenant une espérance beaucoup plus courte qu’il y a quelques temps, avec les VM, un petit souci ? Pas de problème, on repart de 0. Maintenant, on ne pousse plus notre mise à jour sur notre vieux serveur, on pop une machine, on lui donne notre stack, et on la clone pour remplacer les serveurs ayants une vielle version de notre code. Dans ce petit tutorial, nous verrons les bases de Ansible, un outil qui va grandement nous faciliter la vie si l’on a une fâcheuse tendance à ne pas avoir d’uptime de plus de 2 jours sur nos machines.

Pourquoi Ansible ?

Ansible est un outil de déploiement extrêmement simple à prendre en main, contrairement à Puppet ou autre, il est particulièrement adapté aux problématiques du Cloud. Il vous permettra de vous faire rapidement une petite bibliothèque de rôles (taches que ansible va exécuter) et vous fera gagner du temps dans la gestion de votre parc.


Installation d’Ansible

Ici, j’utilise deux machines (Debian 8) mais un playbook est executable aussi bien en distant qu’en local. Le plus simple pour installer ansible sur notre machine maitre est de passer par la commande pip de Python.

$ pip install ansible
$ ansible --version

Pour assurer la communication entre notre machine maître et notre machine esclave, il est conseillé de créer un utilisateur ansible, dans le cadre de cette découverte nous utiliserons l’utilisateur root pour gagner quelques secondes. L’authentification est réalisée par le service ssh, il faut donc exporter la clef publique de notre machine maitre dans le fichier “/root/.ssh/authorized_keys” de notre serveur esclave.

$ ssh-keygen # (Pour générer notre clef)

Dans cet exemple, nous allons utiliser Ansible pour deployer automatiquement un site via Caddy en récupérant les sources de celui-ci sur GitHub. Les sources du playbook sont ici: https://github.com/antoiner77/caddy-ansible. Pour comprendre plus facilement cet exemple, il est conseillé d’avoir lu cet article sur l’installation de Caddy.

Apres avoir récupéré le dossier, il vous faudra établir la liste de vos hosts. Ansible dispose de Modules pour scanner différents services comme AWS et récupérer les IP’s ou tag des VM’s ? Dans notre cas, nous allons simplement déclarer un fichier /etc/ansible/hosts et noter manuellement nos serveurs ainsi que leur groupe.

[webserver]
#Ip de mon serveur esclave
172.16.96.141
[mysqlservers]
# Ici, deux serveurs qui ne seront pas utilisés (voir plus bas)
172.16.96.142
172.16.96.144
  • Architecture du playbook:

    .
    ├── hosts
    ├── playbook.yml
    └── roles
    ├── caddy
    │   ├── tasks
    │   │   └── main.yml
    │   └── templates
    │       ├── Caddyfile
    │       └── caddy.service
    ├── checkntp
    │   └── tasks
    │       └── main.yml
    └── git
        └── tasks
            └── main.yml
    
  • playbook.yml

C’est dans ce fichier que l’on peut définir nos différents rôles et indiquer les hosts à utiliser

#playbook.yml
---
- hosts: webserver  # Le group de serveurs à utiliser
  remote_user: root # Le compte que Ansible doit utiliser
  vars:             # Variables
    site_uri: foo.bar 
    user_mail: john.doe@unknow.com
    site_repo: https://github.com/antoiner77/ansible-site-demo.git
  roles:            # Déclaration de nos rôles
    - checkntp
    - git
    - caddy

Ici, 3 rôles sont appelés, ces 3 rôles sont présents dans le dossier roles de notre playbook. Un rôle est obligatoirement composé d’un dossier task et d’un fichier main.yml, c’est celui-ci qui indiquera les actions à effectuer.

~ Le premier rôle, checkntp:

#/roles/checkntp/task/main.yml
---
- name: Install ntpdate
  apt: update_cache=yes cache_valid_time=3600
  apt: upgrade=dist
  apt: name=ntpdate state=present

- name: Run ntpdate
  command: ntpdate 0.fr.pool.ntp.org

Avec Ansible, nous pouvons utiliser différentes directives comme ‘apt’ ou ‘command’. Ce fichier peut se traduire par les commandes bash suivantes:

$ apt-get update && apt-get upgrade
$ apt-get install ntpdate
$ ntpdate 0.fr.pool.ntp.org

~ Le second rôle, git: Rien de nouveau ici, nous effectuons l’installation de Git.

~ Le dernier rôle, caddy:

Décomposons le fichier main.yml pour comprendre les différentes actions:

- name: Create Caddy home
  file: path=/var/lib/caddy state=directory

- name: Create Caddy user
  user: name=caddy system=yes home=/var/lib/caddy

- name: Set perms
  file: path=/var/lib/caddy state=directory owner=caddy mode=0700

Ici, nous créons l’utilisateur caddy, nous lui attribuons son dossier home et nous réglons les permissions sur ce dernier

- name: Download caddy
  get_url: url=https://caddyserver.com/download/build?os=linux&arch=amd64 dest=/tmp/caddy.tar.gz 

- name: Extract caddy
  command: tar xvf /tmp/caddy.tar.

Le code ci dessus récupère la dernière version de caddy grâce à l’instruction get_url et l’extrait grâce à la commande tar xvf

- name: Create Caddy config file
  template: src=Caddyfile dest=/etc/caddy/Caddyfile

Dans notre dossier /roles/caddy/templates, deux fichiers sont disponibles, ceux-ci vont être envoyer sur notre serveur esclaves. C’est dans ces deux fichiers que nos variables déclarées dans le playbook vont être utilisée. Ainsi, dans le cas du fichier Caddyfile, {{ site_uri }} va être remplacé par l’url déclarée dans nos variables.

- name: Download the site
  git: repo={{ site_repo }} dest=/var/www

L’instruction git permet de cloner un repository et de choisir la destination du contenue de celui-ci, dans notre cas, notre dossier /var/www.

Notre playbook est fini, nous pouvons maintenant le lancer:

$ ansible-playbook -i hosts playbook.yml

Résultat

À ce stade, nous avons accès à notre site web via le serveur esclaves (à conditions d’avoir fait une redirection DNS vers ceux-ci. Pour vos tests, vous pouvez utiliser l’ip de votre serveur dans la variable site_uri, ainsi, vous pouvez accéder à votre site via le port 2015). Pour activer https sur votre site, il vous faudra supprimer la ligne “tls off” dans le template de notre Caddyfile.


Vous l’aurez compris, Ansible est extrêmement tourné vers le cloud. Il permet aux développeurs de gérer leurs stacks et aux administrateurs système de ne pas s’embêter avec les dépendances :). Ici le terme DevOps prends du sens, l’administrateur “codant” son infrastructure.