Il n 'y aucune raison de moinsé, c'est un débat interessant.
Sauf que non. La philosophie derrière Docker, c'est de lancer un process (et un seul) par conteneur. Et en foreground parce que le conteneur s'arrête si le process lancé s'arrête
J'aimerai savoir sur quoi tu te bases pour dire ça.
Tu peux parfaitement utiliser un seul container docker pour lancer plusieurs services.
Tu peux parfaitement l'utiliser pour lancer un serveur d'application et Apache ( et même rsyslog ) dans le même conteneur.
Et ce sans supervisord, un simple script bash fait l'affaire.
Installer SSH dans un container docker est considéré comme une mauvaise pratique en effet, pour la simple raison que c'est un over kill. Il y a une dizaines de manière différente de "binder" dans un container sans avoir à déployer SSH.
Le système de cache de Docker ne comprends pas que apt-get update; apt-get full-upgrade n'est pas idempotent et gardera en cache une image avec une ancienne liste de paquets sans la mettre à jour.
Les mises à jour sont problématiques oui. Mais ça c'est pas propre à docker, c'est propre à tout système qui a un versionning stricte. Que ça soit docker, le système d'apps d'OSX ou nix.
Un workaround pour ça est simplement de faire executer un apt-get upgrade au démarrage du container....
Le système de construction via les Dockerfile est aussi trop rudimentaire pour gérer facilement des déploiements d'applications et la lenteur des builds et gênante.
Ça c'est ton avis. J'aurai plutôt tendance à dire que sa simplicité est sa force. Le Dockerfile t'autorise simplement à construire une image comme une recette de cuisine, étape par étape, couche par couche.
Si tu trouves ça limité: qu'est-ce qui t’empêche d'utiliser Docker build avec Cloudinit, puppet ou je ne sais quel tool de on choix ? ça se fait en deux lignes dans le Dockerfile.
Docker (et tout système de container) n'est PAS une solution de virtualisation, c'est juste un chroot sous stéroïdes que tu peux déployer/cloner/distribuer facilement.
# Conclusion un peu hative
Posté par Firwen (site web personnel) . En réponse au journal Docker, la plateforme à la mode. Évalué à 10. Dernière modification le 06 mars 2015 à 20:31.
Il n 'y aucune raison de moinsé, c'est un débat interessant.
J'aimerai savoir sur quoi tu te bases pour dire ça.
Tu peux parfaitement utiliser un seul container docker pour lancer plusieurs services.
Tu peux parfaitement l'utiliser pour lancer un serveur d'application et Apache ( et même rsyslog ) dans le même conteneur.
Et ce sans supervisord, un simple script bash fait l'affaire.
Installer SSH dans un container docker est considéré comme une mauvaise pratique en effet, pour la simple raison que c'est un over kill. Il y a une dizaines de manière différente de "binder" dans un container sans avoir à déployer SSH.
Les mises à jour sont problématiques oui. Mais ça c'est pas propre à docker, c'est propre à tout système qui a un versionning stricte. Que ça soit docker, le système d'apps d'OSX ou nix.
Un workaround pour ça est simplement de faire executer un apt-get upgrade au démarrage du container....
Ça c'est ton avis. J'aurai plutôt tendance à dire que sa simplicité est sa force. Le Dockerfile t'autorise simplement à construire une image comme une recette de cuisine, étape par étape, couche par couche.
Si tu trouves ça limité: qu'est-ce qui t’empêche d'utiliser Docker build avec Cloudinit, puppet ou je ne sais quel tool de on choix ? ça se fait en deux lignes dans le Dockerfile.
Docker (et tout système de container) n'est PAS une solution de virtualisation, c'est juste un chroot sous stéroïdes que tu peux déployer/cloner/distribuer facilement.