Nous vous avons proposé récemment de découvrir une série d’outils permettant à une start-up de déployer très rapidement une infrastructure de production. Aujourd’hui nous nous intéressons au premier de ces outils, Ansible : pour une start-up, le premier besoin en termes d’infrastructure est de déployer une stack de façon automatisée et de pouvoir gérer l’ensemble de ses dépendances.

Scripts, images toutes prêtes à déployer…il existe plusieurs solutions pour répondre à ce besoin, mais aucune n’est optimale. D’où l’idée de faire appel à un configuration manager afin de pouvoir orchestrer tous les déploiements : ce qui est appellé à être fait plus d’une fois doit être automatisé.

Les outils de configuration management

Quels sont les outils de configuration management sur le marché ? Puppet, Chef, Saltstack et Ansible sont aujourd’hui les solutions les plus plébiscitées. Mais si Puppet, Chef et Saltstack sont des outils très puissants, ils ne peuvent fonctionner qu’avec des agents. Or, quand dans le cas d’une start-up on doit déployer une infrastructure en partant de rien, on ne dispose pas de VM ou d’image disque OS avec des agents installés. Il est certes toujours possible d’utiliser des outils comme Packer pour contourner ce problème, mais à mon sens cela rajoute une couche de complexité. A cette étape de la construction de la start-up, autant s’en passer.

Critères de choix d’Ansible comme configuration manager

Et puisqu’on parle de complexité, il faut également prendre en compte la question de la prise en main de l’outil. Puppet, Chef et Saltstack ne peuvent pas être pris en main rapidement, en quelques heures. Encore une fois, la start-up a besoin d’outils qui permettent une montée en compétence rapide, dont l’usage soit simple, et facile à transmettre aux autres. Ces outils seront peut-être remplacés plus tard, mais l’important est de démarrer rapidement. Pour la start-up, la technique ne doit pas être un frein ! De fait, Ansible est plus facile à prendre en main que les autres outils : quelques heures suffisent pour comprendre son fonctionnement et faire pas mal de choses avec, et ce sans avoir un fort background en configuration management.

Enfin, Ansible est un outil open source, et donc gratuit. Le rachat récent d’Ansible par Red Hat rassure quant à son avenir : on sait que le produit va vivre et qu’il sera soutenu. Ansible bénéficie d’ailleurs d’une communauté très active, que l’on retrouve sur Ansible Galaxy. Le site regroupe toutes les contributions permettant de créer des nouveaux rôles ou des modules. A ce jour, Ansible est déjà très complet : je ne me suis pas trouvé limité par l’outil. C’est vraiment sa simplicité qui m’a plu : le fait qu’Ansible fonctionne sans agent rend le déploiement du kit start-up extrêmement simple et évite d’avoir à ajouter un composant supplémentaire.

Après la mise en place, Ansible peut servir à gérer le cycle de vie des outils internes et de la software factory. Cela permet à la start-up de faire de l’intégration et déploiement continu sur ses applications et ses propres outils internes. Ansible sera utilisé tout au long du pipeline DevOps du kit start-up.

Comment fonctionne Ansible

Point de départ de toutes les tâches confiées à Ansible : le Playbook. Le Playbook centralise :

• Les serveurs sur lesquels faire des actions
• Les variables de configuration
• Les rôles

Chaque rôle correspond à une action : Jenkins, Docker, heure du serveur… et il est possible de créer des relations de dépendance entre des rôles. Par exemple, pour déployer Jenkins, il faut avoir Docker installé, et un système Linux au préalable.

Exemple de Playbook Ansible :

- hosts: softwarefactory
tags: swf
remote_user: admin
roles:
- { role: datadog, datadog_api_key: "{{ datadog['api_key'] }}", tags: ['swf', 'admin', 'datadog'] }
- { role: docker, tags: ['swf', 'admin', 'docker'] }
- { role: consul, tags: ['swf', 'admin', 'consul'] }
- { role: basic_server_setup, tags: ['swf', 'admin', 'base'] }
- { role: fail2ban, tags: ['swf', 'admin', 'fail2ban'] }
- { role: vpn, tags: ['swf', 'admin', 'vpn'] }
- { role: letsencrypt, tags: ['swf', 'admin', 'letsencrypt'] }
- { role: webserver, tags: ['swf', 'admin', 'webserver'] }
- { role: ldap, tags: ['swf', 'admin', 'ldap'] }
- { role: gitlab, tags: ['swf', 'admin', 'gitlab'] }
- { role: graylog, tags: ['swf', 'admin', 'graylog'] }
- { role: jenkins, tags: ['swf', 'admin', 'jenkins'] }
- { role: registry, tags: ['swf', 'admin', 'registry'] }
- { role: ratticdb, tags: ['swf', 'admin', 'ratticdb'] }
- { role: wiki, tags: ['swf', 'admin', 'wiki'] }
- { role: rundeck, tags: ['swf', 'admin', 'rundeck'] }
- docker_cluster
vars_files:
- vars.yml

Pour chaque rôle, on indiquera :

• Les variables par défaut
• Les tâches
• Les templates, généralement des fichiers de configuration qui seront complétés par les bonnes valeurs des variables. Par exemple, pour déposer des fichiers sur un serveur, certaines valeurs changeront selon qu’on l’on soit sur le serveur de développement, de pré-production ou de production
• Les meta, qui sont les dépendances entre les rôles
• Les fichiers (fichiers qui ne sont jamais modifiés)
• Les handlers

Exemple de rôle Jenkins :

- name: Add Jenkins Nginx conf file
template: src=nginx.conf.j2 dest=/etc/nginx/sites-enabled/jenkins.conf mode=0440
notify:
- Reload Nginx
- file: path=/data/jenkins state=directory owner=root group=root mode=0777
- name: docker-jenkins-master
docker:
name: jenkins
image: jenkins
volumes:
- /data/jenkins:/var/jenkins_home
net: "{{ env }}-net"
- name: Cron backup Jenkins Master
cron:
name: Cron backup Jenkins Master
minute: "0"
hour: "3"
job: "tar zcf /tmp/jenkins.tar.gz /data/jenkins ; scp /tmp/jenkins.tar.gz {{ backup['uri'] }}/{{ env }}/jenkins-$(date '+%Y%m%d').tar.gz; rm /tmp/jenkins.tar.gz"
when: backup

Dans cet exemple, on peut voir la configuration du serveur Web Nginx, le déploiement du Docker Jenkins et de son répertoire de travail, et enfin le job de backup.

Dans le cas du déploiement de la software factory pour startup, nous utilisons Ansible pour déployer Jenkins, outil de continuous delivery. Pour être plus précis, on confie à Ansible la tâche de déployer un conteneur Docker avec Jenkins. Dans ce cas, pourquoi ne pas déployer directement avec Docker ? Parce qu’on ne déploie pas uniquement un conteneur, mais aussi:

• Le monitoring
• Le backup des données Jenkins (une tâche récurrente quotidienne)
• Des logs. Une configuration ElasticSearch ou Splunk est possible afin que les logs du conteneur soient récupérés
• Configuration de loadbalancer
• Configuration du serveur Web par lequel passent les requêtes Jenkins. Ici on utilise Nginx et des certificats SSL

Docker et Ansible sont ici utilisés de façon complémentaire. En effet, pour que l’application soit prête pour la production, il faut pouvoir déployer toutes ses dépendances, et c’est que permet de faire Ansible. Pour résumer, on déploie avec Ansible l’ensemble de la Software Factory de la start-up, mais aussi ses outils internes :

• Software factory
• Jenkins (Intégration continue)
• Ansible (Configuration manager)
• Gitlab (Gestionnaire de dépôt Git pour le versionning du code)
• Rundeck (Outil d’orchestration de tâche, similaire à HP OO mais en plus simpliste)
• Cluster Docker Swarm
• Docker Registry (Repository manager des images Docker. C’est un Docker Hub privé)
• Graylog (Gestion de logs)

Outils internes :

• OpenVPN (Accès VPN)
• Owncloud (Partage de fichiers)
• Odoo (CRM)
• RatticDB (gestionnaire de mot de passe)
• Dokuwiki (Wiki interne et documentation)
• Annuaire d’utilisateurs OpenLDAP
• Monitoring DatadogHQ

Ansible est ici utilisé comme pierre angulaire de l’automatisation des déploiements de la start-up. Par sa facilité de prise en main et sa facilité d’évolution, Ansible est aussi bien utilisable côté infrastructure que côté applicatif.

Dans le prochain article de cette série, nous verrons comment déployer un cluster Docker et faire du Container as a Service avec Swarm.