--- layout: post slug: ansible status: published title: Automatisez votre déploiement avec Ansible description: Un fichier pour les gouverner tous disqus: true categories: - web tags: --- Ansible est un outil en ligne de commande pour automatiser vos déploiements. L'objectif de cet article est bien évidemment de vous convaincre de son utilité. Avant d'entrer dans le vif du sujet, revenons sur les différentes façons de déployer votre code sur un serveur. ## L'âge de pierre ### A la main Le niveau zéro de l'administration système consiste à vous connecter en SSH sur le serveur distant, taper des commandes jusqu'à ce que vous obteniez le résultat désiré. Même si cette méthode peut convenir pour apprendre, elle trouve assez vite ses limites au fil du temps : comment faire quand vous avez plusieurs serveurs, quand vous devez faire une mise à jour, quand vous êtes plusieurs à gérer ces serveurs, quand un serveur crash et que vous devez le réinstaller ? ### Écrire un script Afin de pouvoir redéployer votre configuration autant de fois que vous voulez, vous avez peut-être déjà pensé à écrire un script bash qui regroupe l'ensemble des commandes pour déployer votre code. Mais vous vous doutez bien que tout n'est pas parfait. En effet, comment gérer le cas où vous devez cloner un dépôt git à la première installation, mais à chaque réexécution du script vous voulez vous contenter de le mettre à jour ? Vous pouvez écrire deux scripts, un d'installation et un de mise à jour, mais comment faire quand ce genre de cas se reproduit plusieurs fois, et que lors d'une mise à jour il faut créer un nouveau fichier une seule fois ? Vous allez devoir créer un troisième fichier, et executer le bon script sur le bon serveur. Une seconde approche est de faire les tests directement dans le script. Ce dernier d'adaptera donc à votre environnement. Mais certains tests sont complexes, et votre script va s'alourdir considérablement. C'est là où Ansible va vraiment vous faciliter la vie, en réalisant ces tests de manière totalement invisible. ## Fonctionnement d'Ansible ### Des étâts plutôt que des commandes Ansible fonctionne par étât, vous décrivez donc dans quel étât vous voulez qu'une chose soit. Par exemple, je ne vais pas demander de cloner ou de mettre à jour mon dépôt git sur ma machine. Je vais demander à Ansible que mon projet git soit à jour. Si le dossier existe déjà, Ansible va le mettre à jour. Si il n'existe pas, Ansible va le cloner. ### Un fonctionnement sans agent ![Schema Ansible : Sans Agent](/assets/images/posts/ansible-agentless.png) Ansible fonctionne sans agent sur le serveur. Et alors ? En fait, vous n'avez pas besoin d'installer ansible sur votre serveur. Tout se passe sur votre client. Votre serveur aura juste besoin de python2 (et avec un peu de chance il sera déjà installé). Ansible va se connecter au serveur en SSH, récupérer les informations dont il a besoin, puis générer la commande qui correspond à votre requête en fonction de l'état de ce dernier. ### Les templates ![Schema Ansible : Les Templates](/assets/images/posts/ansible-template.png) Les templates vous permettent d'adapter vos fichiers de configuration avec des variables propres à chaque serveur. Imaginons que vous vouliez lancer un logiciel sur x serveurs, ayant chacun dans leur configuration le nom d'hôte du serveur. Lors de l'envoi de mon fichier de configuration sur le serveur, Ansible va prendre le template et remplacer les variables par les bonnes valeurs. ### Sous le capot Ansible est écrit en python2. Chaque commande à un module Ansible, et son utilisation est décrite dans la documentation. Il va se connecter en SSH au serveur, envoyer une charge utile en python, qu'il va exécuter, et va envoyer son retour. ### Versionner En créant des fichiers de configuration sur votre ordinateur, vous pouvez les versionner, dans git par exemple. Ce qui vous permet de : * Travailler à plusieurs sur le déploiement de votre application * Redéployer une ancienne version de votre application * Avoir un script de déploiement pour develop, master, etc. et le gérer comme votre code. (#DevOps :p) ### Les alternatives Je vous présente un peu Ansible comme l'alternative miracle. Rassurez-vous, le monde est vaste, et ce n'est pas la seule option possible. Le plus important c'est de trouver l'outil qui vous convient. Il existe des outils de déploiement avec agent, comme Chef. D'autres consiste à empaqueter vos modifications dans une machine virtuelle, comme Puppet ou Vagrant. Enfin, une autre approche, semblable à la précédente, utilise des conteneurs comme Docker ou Rocket. ## Place à la pratique Si je ne vous ai pas montré des bouts de fichier tout de suite, c'est que je voulais être sûr que vous compreniez bien le fonctionnement d'Ansible, et surtout pourquoi ça peut vous aider. Je ne vous ferai pas de long tutoriel sur son installation, tout se trouve sur [la page d'installation de la documentation officielle](http://docs.ansible.com/ansible/intro_installation.html). En général ça se résume à l'installation via votre gestionnaire de dépendance (dnf, apt, pacman...). ### Prise en main Tout d'abord, Ansible utilise un fichier hosts, un peu particulier, qui n'est pas versionné. Vous pourrez le trouver en général ici : `/etc/ansible/hosts`. En effet, dans vos fichiers de déploiement, vous ne mettez pas directement le nom du serveur distant, mais juste un nom, et les paramètres seront définis dans votre fichiers hosts. Ca permet de décoreller votre déploiement de vos serveurs. Voici à quoi ressemble ce fichier (toutes les informations ne sont pas obligatoires): ``` server1 ansible_ssh_port=22 ansible_ssh_host=192.168.1.1 ansible_ssh_user=root server2 ansible_ssh_port=22 ansible_ssh_host=192.168.1.2 ansible_ssh_user=john ``` _Note : Dans le premier cas, on utilise l'identifiant root, qui est donc super utilisateur. On pourra donc faire tout ce que l'on veut, mais ce n'est pas très sécurisé d'authoriser les connexions directement depuis root. Dans le second cas on se connecte avec un compte non privilégié, c'est plus sécurisé mais on ne pourra rien installer. Sauf si john est dans les sudoers, et dans ce cas là, vous devrez rajouter l'argument `--ask-sudo-pass` à Ansible. C'est la solution à préférer pour la production !_ ### Votre premier "playbook" Un playbook est un fichier au format YML qui décrit les différentes étapes de votre déploiement. Choissisez un nom (par exemple `git-test.yml`), et créez un nouveau fichier avec votre éditeur de texte préféré : ``` --- - hosts: server1 tasks: - name: Install git apt: name=git state=present - name: Clone git repository git: repo=https://github.com/ansible/ansible-examples.git dest=/src/ansible-example ``` ### Executer votre playbook Après avoir ajouté votre fichier à un dépôt git, vous êtes prêt à l'exécuter. ```bash ansible-playbook git-test.yml ``` Si tout se passe bien, vous devriez obtenir un résultat semblable : ![Capture Ansible : le déploiement](/assets/images/posts/ansible-deploy.png) _Ici on voit que git était déjà installé, c'est pour ça qu'il est OK en vert, il est dans l'état que nous souhaitons, rien n'a été modifié. Par contre, le dépôt n'était pas cloné, une action a donc été réalisée, d'où le "changed"._ ### Aller plus loin Vous avez certainement vu le "Gathering Fact" sur la capture précédente. Cette étape permet à Ansible de récupérer beaucoup d'informations sur votre serveur, que vous pourrez réexploiter dans vos scripts. Vous aurez aussi besoin assez vite des handlers. Imaginons que vous modifiez le fichier de configuration du serveur web nginx. Pour que cette modification soit prise en compte, nginx doit être redémarré. Mais vous ne voulez pas redémarrer nginx à chaque fois. Les handlers sont là pour ça ! Ce billet touche à sa fin, Ansible devrait quand même vous réserver encore plein de (bonnes) surprises. Mais ne vous inquiétez pas, vous devriez maintenant avoir toutes les clés pour bien déployer vos projets ! Bon courage !