Conteneurisation de l'application

[theoraim]

Je pose ici un sujet ouvert à discussion qui peut (ou pas) faire débat. Ca serait la conteneurisation de l'application en vue de la déployer plus facilement et sur n'importe quelle plateforme.

Ca présente des avantages, mais des défis aussi donc je pose le sujet sur la table.

Je serais disposé à mettre la main à la pâte pour mener ce projet à bien. Il y a aussi sûrement quelques analyses à faire au niveau des prérequis de l'application, en plus d'une pipeline de build et d'intégration à envisager.

[imperosol]

C'est une question qu'on s'est pas mal posé.

En prod, ça serait pas une bonne idée, je pense, dans la mesure où on a déjà un setup virtualisé en place, et que tout refaire de manière conteneurisé pose son propre lot de problèmes : plus de difficulté à gérer l'espace disque, plus de difficulté pour se connecter au terminal du site, moins bon isolement...

En dev, ça se discute, étant donné que faire tourner tous les services, c'est pas toujours nécessaire, mais parfois c'est bien quand même (je pense en particulier à redis, qu'on utilise comme cache et task broker, qu'il a fallu faire tourner en dev pour commencer à développer des fonctionnalités liées à celery). Là encore, on a le problème que dev efficacement dans le cadre de docker n'est pas forcément évident.

Personnellement, j'étais donc parti sur la piste d'un docker-compose utilisé uniquement en dev, permettant de faire tourner uniquement les services annexes du site. Comme ça, les gens qui veulent développer peuvent le faire avec un docker compose up -d && uv run ./manage.py runserver, et ils ont alors tous les services nécessaires qui tournent, sans avoir à se soucier plus que ça de Docker. J'avais fait ça ici.

En fin de compte, on a opté pour une autre idée : les services annexes dont on a besoin en dev sont décrits dans un .procfile, et on a une lib (honcho), qui se charge de la parser et de faire tourner ces services. Il n'y a aucune isolation (mais c'est un setup de dev uniquement), mais c'est plus léger, il n'y a pas à gérer le réseau et les volumes de docker, et c'est lancé automatiquement par le runserver, ce qui permet d'être sûr que les environnements de dev de chacun sont les plus similaires possibles. Ca s'est fait là.

Je sais pas si j'ai bien répondu au sujet que tu mentionnes.

@klmp200 si jamais tu veux rajouter quelque chose

[theoraim]

En prod, ça serait pas une bonne idée, je pense, dans la mesure où on a déjà un setup virtualisé en place, et que tout refaire de manière conteneurisé pose son propre lot de problèmes : plus de difficulté à gérer l'espace disque, plus de difficulté pour se connecter au terminal du site, moins bon isolement...

Qu'est-ce que tu entends par "moins bon isolement" ? Justement cette conteneurisation permettrait de vraiment isoler le process de l'application. Quant à l'espace disque, je ne pense pas que ça change quoique ce soit (tu peux utiliser des bind mounts pour garder la main sur le stockage et monter le share nfs dans le conteneur).

Ce que je vois dans les avantages là dedans c'est la portabilité et la garantie que l'environnement d'exécution soit toujours identique.

Mais je peux comprendre que ça rajoute de la complexité.

[klmp200]

Pour ce qui est de docker en dev, perso, je déteste dev dans un conteneur docker, ça nécessite du tooling particulier dans son éditeur pour que les librairies soient découvertes, docker (ou podman) réserve 20go de ton disque dur par défaut et ça nécessite de savoir ce que tu fait quand t'as besoin de lancer autre chose que la commande de runserver. C'est pour ça que j'ai développé la version light avec honcho. Après, si quelqu'un veut dev dans un container, il peut s'amuser avec, mais je pense pas qu'on devrais supporter cet usecase en tant que mainteneurs.

Pour ce qui est de la mise en prod, actuellement, l'application est isolée sur une VM dédiée de type 2 (kvm/qemu), le seul moyen d'isoler ça davantage c'est de passer sur une vm de type 1 (type xenserver). Le bénéfice de sécurité est assez minime pour nous. Faire tourner ça dans un containeur pour isoler d'avantage ça a très peu d'intérêt, il n'y a aucune autre application sur la VM, on va l'isoler de rien du tout et en plus rajouter l'overhead de la virtualisation.

Pour ce qui est de la « simplicitée » de mise en prod, elle est à nuancer. C'est facile de faire docker compose up mais dès que quelque chose ne se passe pas bien, il faut commencer à savoir ce qu'on fait et c'est encore un autre outil à apprendre. Les containers ça demande aussi plus de maintenance qu'on peut le penser et ça a une facheuse tendance à remplir l'espace disque quand on ne le surveille pas :/

L'un dans l'autre, je ne pense pas que les bénéfices soient supéreiurs aux inconvénients pour notre cas d'application. Ce serait plus intéressant à une plus grosse échelle mais là on aurais les inconvénients sans vraiment profiter des bénéfices.

J'utilise beaucoup docker en perso, j'adore comment fonctionnent les dockerfile et même après plusieurs histoires d'horreur sur de la prod avec docker, je sais que je ne sais pas tous les scénarios catastrophes qui peuvent arriver avec. Je ne souhaite pas à des personnes moins expérimentées de se retrouver sur une situation terrible qu'ils ne peuvent pas résoudre.

[theoraim]

Pour ce qui est de docker en dev, perso, je déteste dev dans un conteneur docker, ça nécessite du tooling particulier dans son éditeur pour que les librairies soient découvertes, docker (ou podman) réserve 20go de ton disque dur par défaut et ça nécessite de savoir ce que tu fait quand t'as besoin de lancer autre chose que la commande de runserver. C'est pour ça que j'ai développé la version light avec honcho. Après, si quelqu'un veut dev dans un container, il peut s'amuser avec, mais je pense pas qu'on devrais supporter cet usecase en tant que mainteneurs.

Je suis partiellement d'accord, la conteneurisation des services dont l'application dépend peut faire gagner du temps pour configurer l'environnement.

Pour ce qui est de la mise en prod, actuellement, l'application est isolée sur une VM dédiée de type 2 (kvm/qemu), le seul moyen d'isoler ça davantage c'est de passer sur une vm de type 1 (type xenserver). Le bénéfice de sécurité est assez minime pour nous. Faire tourner ça dans un containeur pour isoler d'avantage ça a très peu d'intérêt, il n'y a aucune autre application sur la VM, on va l'isoler de rien du tout et en plus rajouter l'overhead de la virtualisation.

Quand je parlais d'isolation, je pense que je n'ai pas employé le bon terme. Par isolation j'entendais le fait qu'un conteneur docker embarque avec lui toutes ses dépendances et permet de les gérer plus facilement qu'à travers une VM (je pense à l'update de python ou la simple modification du dockerfile et le build de l'image permet de valider le fonctionnement, contrairement à la VM où on serait potentiellement limité par la version de l'OS).

Pour ce qui est de la « simplicitée » de mise en prod, elle est à nuancer. C'est facile de faire docker compose up mais dès que quelque chose ne se passe pas bien, il faut commencer à savoir ce qu'on fait et c'est encore un autre outil à apprendre. Les containers ça demande aussi plus de maintenance qu'on peut le penser et ça a une facheuse tendance à remplir l'espace disque quand on ne le surveille pas :/

L'un dans l'autre, je ne pense pas que les bénéfices soient supérieurs aux inconvénients pour notre cas d'application. Ce serait plus intéressant à une plus grosse échelle mais là on aurais les inconvénients sans vraiment profiter des bénéfices.

Je suis d'accord que le ratio bénéfices/inconvénients n'est pas optimal. Mais pour ce qui est de docker (et de la conteneurisation) c'est un skill qui est maintenant très répandu (et demandé aussi dans les profils) et je trouvais que justement ça serait une bonne manière d'apprendre/de faire apprendre ces technologies.

Le meilleur moyen d'apprendre est de mettre les mains dans la pâte à mon sens. L'idée pourrait être dans un premier temps de voir comment ça se passe sans le remplacement de la prod (pourquoi pas un environnement léger pour étudier la faisabilité ou encore avec taiste).

J'utilise beaucoup docker en perso, j'adore comment fonctionnent les dockerfile et même après plusieurs histoires d'horreur sur de la prod avec docker, je sais que je ne sais pas tous les scénarios catastrophes qui peuvent arriver avec. Je ne souhaite pas à des personnes moins expérimentées de se retrouver sur une situation terrible qu'ils ne peuvent pas résoudre.

J'utilise aussi beaucoup docker et pour moi les risques de prod sont équivalents à un déploiement classique. J'adore cet outil et à quel point d'autres outils se basent dessus pour aller encore plus loin (avec kubernetes au hasard, mais c'est encore un autre sujet).

[imperosol]

Je suis partiellement d'accord, la conteneurisation des services dont l'application dépend peut faire gagner du temps pour configurer l'environnement.

Le setup actuel du site en dev, c'est :

• les apt install
• git clone
• npm i
• uv sync
• cp .env.example .env
• uv run ./manage.py install_xapian
• uv run ./manage.py setup
• uv run ./manage.py runserver

Et c'est tout. On peut difficilement faire plus simple. Docker ne simplifierait pas le processus outre mesure. Il pourrait peut-être permettre de raccourcir toute la partie apt, npm, uv, xapian, mais au prix d'une complexité rajoutée par ailleurs (en rajoutant la gestion des volumes, conteneurs et réseaux de docker) et d'une plus grande difficulté à configurer son environnement de dev.
Ca peut faire gagner un peu de temps au tout début, mais ça peut aussi en faire perdre beaucoup par la suite.

Je suis d'accord que le ratio bénéfices/inconvénients n'est pas optimal.

Pour moi, le coeur du problème est là, justement. On a tous nos technos qu'on aime, mais ça n'est pas une raison pour autant de tout mettre par terre et d'investir du temps et des efforts à tout refaire... Pour se retrouver à la fin avec quelque chose qui n'est pas mieux que ce qu'il y avait à l'origine.

Mais pour ce qui est de docker (et de la conteneurisation) c'est un skill qui est maintenant très répandu (et demandé aussi dans les profils) et je trouvais que justement ça serait une bonne manière d'apprendre/de faire apprendre ces technologies.

C'est sûr que c'est bien, mais la priorité reste au bon fonctionnement du site et à la bonne intégration des nouveaux développeurs sur le projet. La ligne sur le CV, c'est du bonus.
Et justement, j'ai peur qu'en balançant une nouvelle couche de complexité qu'il faut gérer en prod et que les nouveaux développeurs doivent appréhender dès le début de leur expérience sur le site, on nuise au final à ce qui est en réalité le plus important.

On n'arrivera pas forcément à ce résultat, mais c'est un risque qui est loin d'être négligeable. On peut éventuellement réussir à mettre en place un docker qui ne gène pas l'expérience de développement (voire qui la simplifie), mais ça demandera sans doute beaucoup de travail et de discussions.

Le meilleur moyen d'apprendre est de mettre les mains dans la pâte à mon sens. L'idée pourrait être dans un premier temps de voir comment ça se passe sans le remplacement de la prod (pourquoi pas un environnement léger pour étudier la faisabilité ou encore avec taiste).

Si tu veux proposer un setup docker, le sith est ouvert aux contributions 😉