Mais mon idée derrière tout ça, c'est que Docker est une solution qui permet d'aller vite, mais qui est bien plus consommatrice de ressources qu'un paquet RPM/DEB. Et on a l'avantage de bénéficier du support logiciel de sa distribution, et de mieux maîtriser la chaîne des dépendances.
Mais tu pars du principe que ta distribution propose les paquets que tu veux. Et c'est quand même pas toujours le cas.
Par exemple, j'ai une application web super simple qui file un fichier ics indiquant quand il y a du merdier à cause du changement d'heure (genre, les 3 prochaines semaines, les joies de bosser dans une multinationale).
J'utilise exactement 3 paquets python pour ça. J'ai l'impression que le module ics n'est ni dans Debian (mais j'ai pas trop regardé, trop de match via apt), ni dans Fedora (ou n'était pas à l'époque).
Résultat, je me suis résolu à faire un pip install à l'époque, et le faire dans un conteneur me va parfaitement (parce que le pip install va pas consommer sensiblement plus de ressources que apt/dnf install).
Et ça fait quelques mois que je me dit "je devrais refaire l'application en rust", et la, ça serait encore pire niveau paquets de distributions.
Donc le jour ou je trouve une lib rust qui remplace mon usage de pytz (ou que je décide de parser les fichiers à la main), je passerais directement par cargo, d'autant plus qu'avec une CI et un bot, je peux automatiser la mise à jour des dépendances comme ici. Et donc avec le pipeline de déploiement qui vient avec un infra de conteneur, je pourrait avoir le serveur déployé à jour sans avoir à intervenir.
Maintenant, c'est sur que si tu as pas l'infra de gestion des conteneurs, c'est pas aussi bien. Moi, j'ai celle du boulot dont je suis responsable, et ça marche bien (genre le cluster s'auto update, j'ai du config as code pour pas mal de chose, etc, etc).
Mais lancer un conteneur sur un serveur seul, c'est bof, surtout si le conteneur est mal foutu.
[^] # Re: Huhu
Posté par Misc (site web personnel) . En réponse au lien Difficile de recommander Python en production . Évalué à 6.
Mais tu pars du principe que ta distribution propose les paquets que tu veux. Et c'est quand même pas toujours le cas.
Par exemple, j'ai une application web super simple qui file un fichier ics indiquant quand il y a du merdier à cause du changement d'heure (genre, les 3 prochaines semaines, les joies de bosser dans une multinationale).
J'utilise exactement 3 paquets python pour ça. J'ai l'impression que le module ics n'est ni dans Debian (mais j'ai pas trop regardé, trop de match via apt), ni dans Fedora (ou n'était pas à l'époque).
Résultat, je me suis résolu à faire un pip install à l'époque, et le faire dans un conteneur me va parfaitement (parce que le pip install va pas consommer sensiblement plus de ressources que apt/dnf install).
Et ça fait quelques mois que je me dit "je devrais refaire l'application en rust", et la, ça serait encore pire niveau paquets de distributions.
Donc le jour ou je trouve une lib rust qui remplace mon usage de pytz (ou que je décide de parser les fichiers à la main), je passerais directement par cargo, d'autant plus qu'avec une CI et un bot, je peux automatiser la mise à jour des dépendances comme ici. Et donc avec le pipeline de déploiement qui vient avec un infra de conteneur, je pourrait avoir le serveur déployé à jour sans avoir à intervenir.
Maintenant, c'est sur que si tu as pas l'infra de gestion des conteneurs, c'est pas aussi bien. Moi, j'ai celle du boulot dont je suis responsable, et ça marche bien (genre le cluster s'auto update, j'ai du config as code pour pas mal de chose, etc, etc).
Mais lancer un conteneur sur un serveur seul, c'est bof, surtout si le conteneur est mal foutu.