Pas convaincu par Docker !

Docker sur CentOS : pas convaincu pour deux sous !J’utilise LXC depuis plusieurs années en production et j’avoue que cette technique de containerisation me donne entière satisfaction. Elle est simple d’emploi. Concernant Docker, en dehors d’une utilisation pour des tests et des développements, je ne vois pas franchement pas l’intérêt, dans le cadre de mes activités, à orchestrer dans un container le déploiement d’une application. C’est encore une fois de plus faire le choix de l’emmerdement maximum. Ce n’est que mon simple avis. J’ai sans doute loupé quelque chose.

L’image officielle de la CentOS ne contient même pas de serveur SSH. Et la commande systemctl nécessaire au lancement des services ne fonctionne même pas pour démarrer le démon SSH dans le container ! Là-encore, j’ai dû louper quelque chose.

Installation de Docker sur CentOS

Docker a mis un script d’installation pour Linux, téléchargeable à l’aide de la commande curl :

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

Ajoutez votre utilisateur – ici root – au groupe docker :

usermod -aG docker root

Lancement du service Docker

Le lancement de Docker se fait avec :

systemctl start docker
systemctl enable docker

Mise en œuvre de l’image officielle CentOS

Il faut tout d’abord installer l’image du container.

docker search centos
docker pull centos
docker images

Ensuite, vous devez créer un container

docker create -i centos
docker ps -a

Enfin, vous devez le démarrer :

docker start $(docker ps -a -q)
docker exec $(docker ps -a -q) ls
docker stop $(docker ps -a -q)

Nettoyage des containers et des images

Pour effacer les  containers créés précédemment :

docker rm $(docker ps -a -q)

Pour supprimer l’image officielle de la CentOS sur votre distribution :

docker rmi centos

Virtualisation  / Docker 

Commentaires

Alors le but de docker n’est pas de faire tourner une « VM like ». C’est de faire tourner une app.
Mettre un démon SSH sur un container docker, c’est possible, mais c’est un peu une hérésie dans la philosophie docker.

D’ailleurs c’est probablement pour ça que l’image officielle de centos n’en propose pas, un container doit être le plus petit possible.

Il faut donc penser un container comme une seule et unique appli et non pas un OS. D’ailleurs beaucoup de container docker se repose sur des distribution alpine linux plutôt que Debian ou Centos.

Donc si on parle de cas typique « en production » de l’utilisation de docker:
1- isoler des applications. Si vous voulez faire tourner une app isolé du systeme hôte pour des raisons de sécurité, docker permet de le faire a moindre cout, mais ça restera moins isolé qu’une VM.

2- je veux faire tourner plusieurs app web utilisant des techno differentes voir des version differentes de ces technos. Exemple j’ai 3 sites web utilisant des versions differentes de PHP, je peux tout faire tourner sur la meme machine en rajoutant un peux de sécurité grace a l’isolation.

3- La souplesse de déploiement. J’ai des fermes de serveurs et je veux déployer une nouvelle version, je deploie des containers en masse (swarm), ce qui me permet de déployer en meme temps l’environnement sans trop me soucier de celui de l’hotes. Il est de fait aussi possible de jouer aisément sur la scalabilité. Il y a aussi une notion de versionning des images intégré a docker.

Un petit 4 qui s’eloigne de la production un peu, le fait de pouvoir monter des « environnements de prod » sur des machines de dev et ainsi réduire CERTAINS temps de tests lié a l’environnement. On pousse l’appli avec son environnement.

Par contre si vous souhaitez faire tourner des OS plus complet c’est possible, mais il faudra creer votre propre image, ce qui n’est pas tres compliqué.

Pour ce qui est de LXC, Docker « utilise » LXC, il est une couche plus évolué et peut etre plus spécialisé. J’ai pas joué avec LXC je m’apprete donc potentiellement a dire une ânerie, mais il me semble qu’avec LXC le container est difficilement passable d’un hote a un autre. Docker par contre, c’est la base.

LXC dispose de commandes permettant de cloner le container et d’en faire des snapshots (mieux que le commit de Docker). Effectivement, il est nativement plus isolé et donc plus sécurisé. La consommation mémoire par container LXC est de 1 Mo supplémentaire, une fois le container lancé. On peut utiliser Ansible pour orchestrer le container LXC.

Docker ne me semble pas pratique pour tout ce qui est interactif, une fois le container lancé. C’est pour cela que j’ai voulu installer le démon SSH plutôt que d’utiliser docker exec. Y-a-t-il d’ailleurs d’autres solutions que le SSH afin d’éviter l’arrêt du container dès qu’on fait exit à partir d’une session Bash sur le container ? J’ai rien trouvé sur le sujet.

Comme je disais Docker c’est orienté pour faire tournée une app, plus précisément, un exécutable.

Si vous créez votre propre image, vous allez devoir lancer votre programme en foreground et non pas en tant que daemon. Si ce process coupe, le container s’éteint.

Du coup c’est pas vraiment pensé pour interagir avec un container. On interagie avec le container pendant la phase de dev (d’ou le exec), mais pas en production.

J’ai jamais essayé de mettre en place un SSH. Mais je pense que c’est possible mais j’utiliserais le trick de faire une image qui démarre un script sans fin pour son programme principale(qui termine par un pause par exemple) et qui permet d’utiliser plusieurs programmes dans un docker.

Mais si le but est de faire des bancs de tests avec pas mal d’interaction, pour moi docker n’est pas désigné pour ça.

@Draak Pour moi, c’est sans intérêt !

Hello,

Les premières versions de docker étaient basées sur LXC mais ce n’est plus le cas depuis quelques années, ils utilisent leur propre bibliothèque désormais.

Vouloir exécuter un SSH sur un container est peut-être le pire des exemples pour tester Docker. Moi aussi j’ai fait la bêtise de croire que ça permettait de faire « des vms », c’est vraiment fait pour une application unique par container, avec une isolation entre chacun (il m’a fallu un moment pour bien le comprendre, entre mes premiers essais, une pause, de nouvelles lectures et de nouvelles expérimentations). En dehors d’un éventuel volume partagé les applications ne se voient pas entre elles et ont chacun leur environnement d’exécution. Une sorte de chroot ++ quoi. Si tu veux vraiment pouvoir te connecter dessus c’est ssh sur l’hôte et docker exec. Y’a aussi la possibilité d’exposer l’api docker directement en https pour l’accès distant depuis son poste mais ça demande une gestion de certificat au poil, perso je préfère plutôt faire confiance à SSH. Et on l’a dit, c’est fait pour des applications, pas des services. Si tu regardes comment fonctionne l’image apache, tu verras que c’est le process httpd, mais pas en démon, en foreground. Si le process s’arrête, le container s’arrête. Un container est concu pour être éphémère.

En fait, plus la technologie mature et plus on se rend compte que docker seul n’a pas d’intérêt sans orchestration, c’est à dire sans gestion automatisée des containers. L’aspect éphémère des containers fait qu’on peut les remplacer à loisir, le but étant d’avoir des applications qu’on peut tuer/redémarrer sans impact. C’est très adapté dans une architecture dite microservices où plusieurs petits composants bossent dans leur coin. Il faut alors un chef d’orchestre pour tout lancer en même temps, et surtout s’assurer qu’ils restent tous debout.

A la maison, j’ai déployé un cluster swarm (mais swarm fonctionne aussi sur une seule machine), ça rajoute plusieurs éléments d’orchestration à la base Docker pour avoir une meilleure expérience que celle de base. T’as aussi du vite entendre parler de Kubernetes, qui est un monstre mais qui est conçu pour les déploiements de containers à grande échelle (j’ai un projet au taf de déploiement de 7 clusters, dont un qui contiendra une vingtaine de machines bien musclées pour déployer plusieurs centaines de containers). Tout ça pour dire qu’en entreprise, à fortiori en production, on n’utilise pas Docker tout seul.

Maintenant, j’ai évoqué que c’était particulièrement adapté pour certains types d’application, mais pas pour toutes ! Et c’est là que devrait être ta conclusion, pour tes usages et les applications dont tu as besoin, Docker ne t’apporte rien. Je ne suis moi-même pas un grand fan, notamment parce qu’il y a un discours sur la sécurité qui n’est pas complètement honnête (oui ça isole, mais une application vulnérable le restera dans un container, juste elle aura moins d’impact sur les voisins — un peu comme les pubs pour les VPN qui parlent d’anonymat…). Mais je suis le premier à reconnaître que dans des cas de plus en plus fréquents (sites web reposant sur du nodejs, architectures microservices asynchrones, etc), ça fait super bien le taf pour peu que les développeurs construisent intelligemment leurs images. Certes ça n’arrive pas toujours comme on le voudrait, et on a déjà eu des fails, comme un client dont l’image docker n’a jamais été stable en production (le process fpm crashait sans cesse).

@Seboss66

Sur le plan de la sécurité, il y a aussi la question de l’origine et la manière dont sont faits les containers.

Docker est arrivé, en effet, avec la vague NodeJS. L’outil semble avoir été fait pour ce type d’usage, effectivement très éloigné de mes pratiques. Et puis, la multiplication des containers posent à peu près autant de problèmes que celles des VM en terme d’exploitation. En fait, Docker ne m’intéresse pas du tout. Je voulais juste y jeter un oeil pour comprendre. Vos commentaires m’ont permis de comprendre. Merci à tous.

« on se rend compte que docker seul n’a pas d’intérêt sans orchestration »

Effectivement j’ai pas parler de ça mais c’est comme ça que je m’en sert.

A titre perso par exemple, j’ai une petite infra avec un seul serveur de prod pour faire du mail, du cloud fichier, serveur web, base de donnée et plein d’autres services.
Tout est géré par un orchestrateur, si je fais une modif je la pousse sur le git et elle sera poussé en prod en temps voulu. Pour mettre a jour ou reinstallé entierement le serveur, c’est une ligne de commande.

@Draak

Un script ou Ansible peuvent très bien faire l’affaire.

Quand je parle d’une ligne de commande c’est pour forcer la mise a jour via Chef ( http://www.chef.io ) :)

Laisser un commentaire

(requis)

(requis)