docker-compose est un outil de gestion des conteneurs Docker qui résout les problèmes de déploiement d’applications complexes, mais il ne suffit pas pour un self-hosting simple destiné au grand public.- Un niveau d’abstraction plus élevé est nécessaire, incluant les notions de base de données SQL, de cache local, de stockage persistant, de découverte de services et de gestion des ressources.
Le rôle de Docker
- Docker est l’outil qui a popularisé la conteneurisation, et le système hôte peut être comparé à un navire.
- Il y a le matériel, le système d’exploitation et le runtime de conteneurs ; les conteneurs s’exécutent dans ce runtime et communiquent avec d’autres services comme une base de données ou un serveur web.
Le rôle de Docker Compose
docker-compose est un outil qui permet de définir un groupe de conteneurs fonctionnant ensemble, ce qui facilite le déploiement d’applications auto-hébergées.- Cependant, il casse l’interface standardisée et reproduit les problèmes que les conteneurs étaient censés résoudre au départ.
- Exemple : Pihole
- Pihole est un serveur DNS qui nécessite un fichier
docker-compose complexe.
- Il faut configurer le nom du conteneur, l’image, les ports, les variables d’environnement, les volumes, les fonctionnalités additionnelles, la politique de redémarrage, etc.
- Cette configuration complexe doit être gérée directement par l’utilisateur, ce qui constitue un défaut de Docker Compose.
- Exemple : Jitsi Meet
- Jitsi Meet est un logiciel complexe qui génère une configuration
docker-compose comprenant 4 conteneurs, 7 volumes, 9 ports et plus de 200 variables d’environnement.
- Exemple : d’autres applications auto-hébergées populaires rencontrent des problèmes similaires
- Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX et bien d’autres applications existent, et chacune de leurs configurations
docker-compose remplace de dizaines à des centaines de commandes docker.
- Chaque application peut inclure sa propre base de données, son propre cache et son propre gestionnaire HTTP, ce qui entraîne une utilisation redondante des ressources.
Les problèmes
docker-compose est trop flexible, trop détaillé, et fonctionne au mauvais niveau d’abstraction.- Chaque application possède son propre processus de gestion HTTP, son cache ou sa base de données. La sauvegarde des bases de données repose sur l’administrateur système.
- Exemple : proxy HTTP inverse
- Un proxy HTTP inverse est un programme qui transmet les requêtes HTTP entrantes à un autre programme. Chaque programme doit décider s’il inclut ou non un serveur web.
- Avec serveur web intégré
- Si le programme inclut un serveur web, il fonctionne, mais uniquement sur certains ports, et il faut remapper les ports lorsqu’il y a plusieurs conteneurs.
- Sans serveur web intégré
- Si le programme n’inclut pas de serveur web, cela évite de gaspiller des ressources, mais l’application doit alors être configurée sans interface d’administration.
- DNS
- Une interface web a une adresse, et si l’on veut du TLS, un nom est nécessaire. Lorsque plusieurs services tournent sur un même hôte, il faut router les requêtes via un nom de domaine ou un chemin.
- Ports
docker-compose permet d’exposer et de remapper des ports, mais en pratique il faut prendre en charge des configurations réseau complexes.
- Exemple : base de données
- Dans une base de données, toutes les modifications de fichiers sont supprimées quand le conteneur est effacé. Un conteneur de base de données doit ajouter un volume pour conserver son contenu.
- N+1=2 ou plus
- Pour sauvegarder une base de données, il faut une sauvegarde hors site. Lorsque chaque service embarque son propre processus de serveur de base de données, cela gaspille les ressources de calcul.
Les solutions
- Il faut passer à une couche d’abstraction supérieure et ajouter une sémantique distinguant des types de conteneurs comme les bases de données, les reverse proxies web, les caches ou les ressources web statiques.
- Exemple de sémantique
- Introduire un nouveau format de configuration permettant de définir le nom de l’application, le build, le proxy inverse HTTPS et les services de cache.
- Solution n°1
- Chaque programme demande un proxy inverse, ce qui évite les duplications et le gaspillage. Le proxy inverse fournit un nom DNS et transmet tous les chemins au programme.
- Solution n°1.5
- Ajouter une section base de données afin de demander une base conforme au standard SQL, le programme s’attendant à disposer des droits « complets ».
- Solution pour les ports
- Chaque programme reçoit sa propre adresse IPv6 et peut utiliser les numéros de port standard. Pour la sécurité, un pare-feu est utilisé afin que seul le proxy inverse puisse accéder aux ports.
Tealok - un nouveau runtime de conteneurs
- Tealok est un nouveau runtime de conteneurs qui fournit un niveau d’abstraction plus élevé et une interface standardisée.
- Il gère automatiquement les certificats TLS, la configuration du reverse proxy, les enregistrements DNS, la gestion des sauvegardes, etc.
- Il exploite IPv6 afin que chaque conteneur dispose d’une adresse IP indépendante et puisse utiliser les numéros de port standard.
- Les développeurs d’applications peuvent déployer leurs applications via une interface standard sans configuration complexe.
- Pour les opérateurs, cela apporte des bonnes pratiques cohérentes, réduit le gaspillage de ressources et allège la charge d’administration.
- Pour les développeurs, cela simplifie la manière de déployer et réduit le poids des décisions à prendre.
- Les utilisateurs peuvent bénéficier de la propriété des données et de l’indépendance vis-à-vis du cloud computing.
6 commentaires
Je suis allé voir tealok, et ça ne semble pas du tout être dans un état qui puisse en faire une alternative.
Ça aurait été vraiment bien qu’ils suppriment aussi le runtime.
Je pense qu’il reste encore nécessaire d’utiliser docker-compose pour mettre en place un environnement proche de la production avant d’y entrer, mais…
En revanche, j’ai du mal à être d’accord avec l’idée de dire : sur la base d’une expérience dans un environnement très particulier qui est le sien, « c’était mauvais, donc j’ai créé quelque chose de nouveau »… haha
Le contenu peut facilement prêter à confusion, haha…
Comme je n’avais vu que le titre, je me disais plutôt : « Ah, c’est vrai que je n’aime vraiment pas l’utiliser dans un environnement de développement… » haha
J’ai l’impression qu’essayer d’utiliser Docker Compose dans le même but que dans l’article est, dès le départ, une mauvaise approche.
Je suis en partie d'accord avec ce que vous dites, mais je ne pense pas que l'approche ait été mauvaise.
C'était probablement le meilleur choix possible dans l'environnement qui était le leur :)
Commentaires sur Hacker News
Il existe des solutions simples aux problèmes de mappage de ports et de sauvegarde des volumes de données
docker-composedistinct pour l’environnement de développement afin de définir des configurations différentes selon l’environnementEn tant que personne qui fait de l’auto-hébergement sur un serveur personnel avec Docker, l’auteur considère positivement la flexibilité de la configuration Docker
macvlanest utilisé pour attribuer à chaque conteneur une adresse IP et une adresse MAC uniquesdocker-composeest principalement utilisé pour le développement ou un usage personnel, et la V2 est un plugin intégré à Docker, contrairement à la V1En production, il vaut mieux utiliser Kubernetes, tandis que
docker-composeconvient bien au développement localdocker-composeest un produit destiné au petit auto-hébergement, ciblant des personnes sans bagage techniqueÉcrire un programme pour piloter Docker est plus simple qu’on ne le pense, et un script Python peut résoudre le problème
Un développement est en cours avec
canine.shpour rendre l’usage d’un cluster Kubernetes aussi simple qu’HerokuIl est intéressant que Tealok développe une alternative à
docker-composedocker-compose, Kubernetes et Helm sont considérés comme de mauvais niveaux d’abstractionCertains se disent perplexes face à l’affirmation selon laquelle
docker-composeserait un mauvais niveau d’abstraction