Automatisation du provisioning et du déploiement d'une application (poll/worker/result) via Ansible sur un parc de machines.
Telecharger & tester
make && ./octopus (voir le sujet PDF pour l'utilisation exacte)
Octopus est un projet Epitech (Tek4, module B-DOP-400) qui reprend l'application de sondage developpee lors du projet Popeye (client web Flask collectant les votes, file Redis, worker Java consommant la file et ecrivant dans PostgreSQL, client web Node.js affichant les resultats) pour la deployer, cette fois sans conteneur, sur cinq machines distinctes a l'aide d'Ansible. Le livrable central est un playbook.yml accompagne d'un repertoire roles, teste via une commande ansible-playbook -i production utilisant un inventaire fourni par les correcteurs et un compte non-root disposant de sudo.
Le projet impose l'ecriture de six roles Ansible : base (paquets utiles comme Git, configuration generale de l'instance) applique a toutes les machines, redis (installation et configuration du serveur de file d'attente), postgresql (installation de PostgreSQL 12, creation d'un utilisateur applicatif paul avec des droits limites, distinct de la base de donnees paul elle-meme, et creation du schema), puis poll, worker et result qui uploadent chacun leur service, installent leurs dependances et le lancent. Docker, Podman et Ansible Galaxy sont explicitement interdits, ce qui force a ecrire les roles avec les modules natifs d'Ansible.
La securite est un axe evalue strictement : tout mot de passe en clair dans le depot entraine l'echec immediat du projet, ce qui impose l'usage d'Ansible Vault (le mot de passe du coffre etant fourni via la variable ANSIBLE_VAULT_PASSWORD_FILE au moment du test). Les taches doivent privilegier des modules dedies (apt, apt_key, apt_repository, pip) plutot que command/shell/raw, reserves aux cas sans module equivalent, et tous les services applicatifs doivent etre geres par systemd, demarrer automatiquement au boot, et etre configures par variables d'environnement conformement aux principes 12-factor (hote, port, utilisateur, mot de passe, nom de base, etc.).
L'idempotence est un critere de qualite explicite : rejouer le playbook une seconde fois doit produire un PLAY RECAP avec un nombre de taches changed aussi proche de zero que possible. L'environnement cible est compose de cinq groupes d'inventaire (redis, postgres, poll, result, worker) representant chacun une machine virtuelle Debian 10 (Buster), et le depot final doit respecter une arborescence precise : playbook.yml, les archives poll.tar / result.tar / worker.tar, un group_vars/all.yml, et le repertoire roles contenant fichiers de configuration (pg_hba.conf, schema.sql, redis.conf, fichiers .service systemd) et taches pour chacun des six roles.
Projet suivant
