Ansible

Ce projet contient plusieurs façon d'automatiser le déploiement d'une application conteneurisée. Tous ces déploiements se basent sur l'image demofastapi:simple construite ici.

Il est conseillé d'installer ansible sur votre machine en créant un environnemen virtuel python, puis en y lançant :

pip install ansible

Ces exemples ont pour but de montrer plusieurs façons d'organiser du code ansible, mais pas d'être un cours exhaustif sur Ansible et sa syntaxe.

1. Compose

La méthode la plus populaire pour déployer des conteneurs est l'utilisation de compose. Cela peut être fait via les commandes suivantes :

cd 1_compose
docker compose up -d

Le service peut ensuite être consulté à l'adresse http://127.0.0.1:8000, puis peut être arrêté via :

cd 1_compose
docker compose down

2. Inventaire Simple

Plutôt que d'aller copier le fichier compose sur un serveur à la main puis lancer le compose, les tâches peuvent être automatisées via Ansible. Dans ce premier inventaire, un unique playbook va copier le fichier compose dans /tmp/demofastapi sur la machine local (localhost) puis va lancer ce compose. Un second playbook permet de stopper le docker compose.

Notez que ces playbooks sont lancés sur la machine localhost pour simplifier l'execution de ces demos. Le projet terraform contient un inventaire ansible s'executant sur une machine à distance.

Le service peut être lancé via :

cd 2_playbook
ansible-playbook ./1_up.yml

Le service peut ensuite être consulté à l'adresse http://127.0.0.1:8001, puis peut être arrêté via :

cd 2_playbook
ansible-playbook ./2_down.yml

Plutôt que de dupliquer le playbook et créer de la difficulter à maintenir les scripts de déploiement, on peut utiliser les variables ansible pour variabiliser l'état du déploiement :

cd 2_playbooks
ansible-playbook --extra-vars "state=present" ./3_variable.yml
ansible-playbook --extra-vars "state=absent" ./3_variable.yml

3. Role interne

Dans l'exemple précédent, nous avons créé un playbook contenant une variable pour éviter de dupliquer la logique de déploiement entre le playbook de lancement et le playbook d'arrêt du service. Cependant nous ne pouvons plus lancer le playbook sans fournir cette variable state.

Une autre approche est de passer par un rôle ansible, ainsi on peut mettre la logique de déploiement dans ce role, puis faire en sorte que nos deux playbooks 1_up et 2_down appelent ce rôle en specifiant la variable state. Ainsi on a bien un emplacement unique pour le role, mais nos deux playbooks séparés.

Notez que la structure du role a été créée en utilisant l'outil ansible-galaxy

cd 3_internal_role/roles
ansible-galaxy init demofastapi

Le point d'entrée de ce rôle est le fichier tasks/main.yml et est le seul fichier absolument nécessaire.

Le service peut être lancé via :

cd 3_internal_role
ansible-playbook ./1_up.yml

Le service peut ensuite être consulté à l'adresse http://127.0.0.1:8002, puis peut être arrêté via :

cd 3_internal_role
ansible-playbook ./2_down.yml

4. Role externe

Pour qu'un rôle puisse être utilisé par plusieurs inventaires ansible (par exemple un inventaire de production et un autre de lab), les rôles peuvent être publiés sur git.

Un rôle similaire à celui utilisé dans l'exemple 3 a été publié ici, et est déclaré comme dépendance dans le fichier 4_external_role/requirements.yml.

Ce rôle est ensuite appelé dans les différents playbooks.

Avant d'executer ceux-ci, il faut installer les dépendances :

cd 4_external_role
ansible-galaxy install -r ./requirements.yml

Le service peut ensuite être lancé via :

cd 4_external_role
ansible-playbook ./1_up.yml

Le service peut ensuite être consulté à l'adresse http://127.0.0.1:8003, puis peut être arrêté via :

cd 4_external_role
ansible-playbook ./2_down.yml

5. Collection et Molecule

Plutôt que de devoir installer les rôles individuellement, et se retrouver avec un immense fichier requirements.yml à gérer, en s'assurant que toutes les versions des rôles sont compatibles entre elles, il est possible de regrouper ces rôles dans des collections.

Ainsi, en installation une version x.y.z d'une collection, on est sûr que tous les rôles sont compatibles entre eux (par exemple le rôle de reverse proxy et les rôles de services). De plus, les collections permettent aussi de packager des plugins et des modules Ansible, écrits en python, qui permettent de palier des lacunes d'Ansible.

Comme pour les rôles, les collections peuvent être initialisées avec ansible-galaxy, les noms de collections doivent cependant respecter la nomenclature <organisation>.<collection>.

# Initialize collection
ansible-galaxy collection init cyberschool.demos
# Initialize role in collection
cd cyberschool/demos/roles
ansible-galaxy init fastapi

Le rôle fastapi peut ensuite être appelé en tant que cyberschool.demos.fastapi.

Une collection contenant un rôle similaire à ceux utilisé précédemment a été créée ici. et est déclaré dans le fichier 5_collection/requirements.yml.

Ce rôle est ensuite appelé dans les différents playbooks.

Avant d'executer ceux-ci, il faut installer les dépendances :

cd 5_collection
ansible-galaxy install -r ./requirements.yml

Le service peut ensuite être lancé via :

cd 5_collection
ansible-playbook ./1_up.yml

Le service peut ensuite être consulté à l'adresse http://127.0.0.1:8003, puis peut être arrêté via :

cd 5_collection
ansible-playbook ./2_down.yml

6. Pour aller plus loin

Tous les exemples ici se sont contentés de déployer le service sur la machine locale (localhost). La puissance d'Ansible vient aussi de sa gestion d'un inventaire de machine et comment s'y connecter. Un exemple d'inventaire est présenté une fois une VM déployée dans la section terraform.