J'aimerai (re)faire mes premiers pas avec Ansible et, par la même occasion, faciliter le déploiement et l'organisation des différents "services" nécessaires au Lexpage. Je découvre les histoires de "rôles" d'Ansible qui me semblent une belle avancée par rapport à l'accumulation des playbooks (je m'étais arrêté là il y a quelques années). Je ne sais pas encore à quelle "vitesse" je vais apprendre et tester tout ça, mais j'ouvre un thread pour en discuter, vu qu'il y a des connaisseurs

Pour rappel, Lexpage est plus ou moins organisé comme suit :
- Un serveur nginx frontal qui dispatche les requêtes (via un file socket pour l'instant) vers Gunicorn;
- Une instance de Gunicorn qui récupère ces requêtes et les transmet à Django;
- L'application Lexpage bâtie sur Django et "lue" par Gunicorn lorsque les workers sont créés. L'application consiste en un clone du repository git (dispo sur github) auquel j'ajoute un fichier de settings spécifique pour la prod (qui contient notamment les clés de chiffrement);
- Un serveur pgsql uniquement utilisé par Lexpage;
- Un serveur redis uniquement utilisé par Lexpage;
- Un bricolage pour dumper la db régulièrement (via logrotate) à des fins de backups (synchronisation via Dropbox sur un compte dédié).

J'aimerai placer "Lexpage & co" dans un conteneur (ou VM, peu importe, je voudrai que ça soit isolé). J'imagine donc qu'il convient de laisser Nginx en dehors du conteneur (vu qu'il sert aussi pour d'autres services). A priori, je compte partir sur Vagrant dans un premier temps pour faire mes tests (tout d'abord via VirtualBox et ensuite probablement via LXC, dans les deux cas, la distribution serait une CentOS7 parce que j'ai l'habitude avec CentOS/Fedora et que l'hôte est un CentOS6, ça uniformise un peu ).

Je suppose que l'idée de base est de partir sur des rôles (probablement prédéfinis et trouvables sur Ansible Galaxy) pour Redis, pgsql et Gunicorn, et ensuite de voir comment organiser tout ça ?

GuybrushJe suppose que l'idée de base est de partir sur des rôles (probablement prédéfinis et trouvables sur Ansible Galaxy) pour Redis, pgsql et Gunicorn, et ensuite de voir comment organiser tout ça ?

Dans un monde parfait, oui, ton besoin est super standard donc Ansible Galaxy devrait te donner les building blocks pour le faire rapidement.

Dans les faits, j'ai souvent du mal à trouver des rôles qui me conviennent sur le galaxy. Ils sont soient trop simples en exposant pas certains templates de configuration importants, soit trop complexes avec beaucoup trop de variables mandatory, soit complètement pétés. C'est un problème qui se retrouve d'une certaine manière avec les images communautaires du Docker Hub d'ailleurs.

Mon workflow ansible est généralement:
- délimiter une brique interchangeable de mon système (nginx, redis, gunicorn, appli Django) et la configuration spécifique que j'ai besoin de voir exposée (vhost nginx)
- chercher sur le galaxy si les rôles best rated conviennent au besoin, sinon initialiser un rôle moi-même
- écrire le playbook
- écrire l'inventory

Dans l'idée, les rôles sont comme des modules de code, on ne devrait pas trop en créer si on a pas l'intention de les réutiliser. En pratique, je trouve que c'est le meilleur moyen de séparer les responsabilités dans un playbook pour pas se retrouver avec des playbooks de 5000 lignes, du coup j'ai tendance à en faire souvent.

Je vais jeter un oeil à Ansible Galaxy et voir ce qu'il y a de disponible pour supporter mon use case.
A voir aussi comment je "provisionne" la configuration du Lexpage, pour permettre un déploiement aussi bien dans un environnement de développement qu'en production.

Guybrushpermettre un déploiement aussi bien dans un environnement de développement qu'en production.

Habituellement, je joue avec les groups et subgroups dans l'inventory. Avoir un groupe par environnement permet d'avoir des group_vars dédiées ("production", "dev"), en plus des groupes fonctionnels ("nginxhost", "appcontainer", "dbservers").

L'autre solution est simple et mauvaise, c'est de surcharger les variables pour la machine de dev dans les hosts_vars.

J'ai envie de garder tout ça le plus "simple possible". A vrai dire, c'est surtout pour apprendre Ansible, parce que sinon je pense qu'un simple script bash suffirait pour "provisionner" la VM pour Lexpage

J'ai fait quelques tests avec Vagrant (avant de m'attaquer réellement à Ansible) et je ne suis pas convaincu que ça soit la bonne approche pour Lexpage, essentiellement à cause de la taille des images (même en LXC ou avec Alpine) vu l'espace disponible sur les VPS basiques. Je regarde actuellement comment Docker a évolué les dernières années... Est-ce que les soucis de daemon en root et la sécurité qui va avec ont été réglés ? Ou bien convient-il de lancer Docker au sein d'une VM avant de popper les conteneurs ?

Bon, pas de progrès récent sur le sujet. Je me suis un peu concentré sur Docker, mais je n'ai pas regardé plus que ça, et pas encore abordé la partie "Ansible" (a voir si ce sera utile, vu que le Dockerfile permet déjà de faire un peu de provisionning et que mes besoins sont faibles de ce coté).

Par contre, c'est pas trivial de faire en sorte que l'application soit utilisable au sein d'un docker en prod (avec les settings qui vont avec), d'un docker en dev (avec les settings qui vont avec) voire même sans docker (parce que tout le monde a pas forcément envie d'avoir à installer docker juste pour tester). Je n'ai pas encore vraiment trouvé de tuto qui explique convenablement comment organiser tout ça (souvent, les gens se disent "ok, c'est dans docker, je me fous du reste").

GuybrushPar contre, c'est pas trivial de faire en sorte que l'application soit utilisable au sein d'un docker en prod (avec les settings qui vont avec), d'un docker en dev (avec les settings qui vont avec) voire même sans docker

C'est à dire ? la philosophie de Docker c'est d'avoir une seule image pour dev et prod, ce qui change devrait être exposé dans les variables d'environnements ou dans un éventuel gestionnaire de secret externe.
Pour tester sans Docker, le mieux est toujours d'avoir une application qui build au make ou a minima avec les standards de son langage (pip/composer/maven, que sais-je).

Pour la sécurité du démon docker, j'en sais rien

Merci d'avoir pointé ce détail Guy! Et de le traiter^^

Et ce serait super sympa d'en informer tous les autres gens qui ne font que du docker et pour lesquels tu peux te brosser si tu veux installer à l'ancienne! Et oui installer à l'ancienne pour connaitre le bousin ça a une valeur à minima éducative, faire l'expérience de la stack et tout via un moyen simple : le déploiement!

Je fais référence à AWX d'ailleurs, la version open source de Ansible Tower. Installer à la main ça n'existe pas et n'est pas documenté dans le projet, c'est pas assez hype.

Bref c'était ma rant du moment, et de n'est pas ma faute monsieur l'agent : le bouton pour poster m'incite à troller!

Fabela philosophie de Docker c'est d'avoir une seule image pour dev et prod, ce qui change devrait être exposé dans les variables d'environnements ou dans un éventuel gestionnaire de secret externe.

Je commence seulement à voir les subtilités du CMD dans Docker et des possibilités de pouvoir passer des arguments à ce qui va être exécuté dans le conteneur. Mais la "difficulté", c'est qu'il y a une couche intermédiaire (gunicorn) qui doit aussi connaître ces paramètres pour distinguer prod/dev. Mon idée pour l'instant est de faire en sorte que le conteneur fonctionne sur base d'un seul fichier settings, qui sera différent en fonction de l'environnement dans lequel le conteneur va tourner. Le "hic", c'est qu'il y a déjà trois settings différents pour Lexpage (dev, prod et travis), et que je vais devoir "dupliquer" certains settings pour permettre de faire tourner le site en dehors d'un conteneur également (par ex, hors conteneur, c'est sqlite et memcache qui sont utilisés, alors que dans le conteneur ou en prod, c'est pgsql/redis). J'aimerai éviter de dupliquer les settings (y a déjà un "settings_common" qui est inclus dans les deux fichiers de settings existants, mais j'aimerai pouvoir "composer" tout cela un peu plus proprement).

SyssonEt ce serait super sympa d'en informer tous les autres gens qui ne font que du docker et pour lesquels tu peux te brosser si tu veux installer à l'ancienne! Et oui installer à l'ancienne pour connaitre le bousin ça a une valeur à minima éducative, faire l'expérience de la stack et tout via un moyen simple : le déploiement!

Tout à fait, sans compter que certaines opérations ne sont pas simples à réaliser si l'application tourne dans un conteneur lors du dev (par exemple, je ne sais pas dans quelle mesure nos tests de Django avec Selenium peuvent être lancés dans le conteneur, tout en ayant Selenium qui communique avec le browser en dehors du conteneur. A moins de faire comme avec Travis et de faire tourner ces tests en mode "headless" (mais ça veut dire un dockerfile spécifique pour le dev, du coup, même si c'est pas "fondamentalement" un souci).