Gérer les containers avec Docker

Posté par  . Édité par ZeroHeure, Benoît Sibaud, Florent Zara, NeoX, claudex, Nils Ratusznik et tuiu pol. Modéré par Florent Zara. Licence CC By‑SA.
47
25
mar.
2014
Virtualisation

Docker est un projet open-source sous licence Apache 2 pour automatiser le déploiement d'application sous forme de containers LXC

logo docker

Jusqu'à présent on trouvait couramment des applications prêtes à l'emploi sous forme d'images VMware, XEN, VirtualBox, QEMU, etc. mais quasiment jamais l'équivalent sous forme de containers. Pourtant les containers représentent une forme de virtualisation légère qui peut dans bien des cas servir d'alternative à la virtualisation lourde.

NdM : merci aussi à Nycolive pour sa proposition de dépêche, qui a été fusionnée avec celle-ci.

Rappel

  • émulation complète : on émule un ordinateur virtuel complet. C'est lent mais très flexible, On peut par exemple émuler un processeur SPARC sur un ordinateur Intel. Exemple de logiciel : QEMU
  • virtualisation : on émule un ordinateur virtuel du même type que l'hôte. C'est moins flexible que l'émulation complète mais c'est beaucoup plus rapide. Techniquement ça repose sur les différents niveaux d'exécution du processeur (Ring 0,1,2,3) Exemple de logiciels : VMWare, Xen, VirtualBox, KVM, Hyper-V
  • containers : ce n'est plus l'ordinateur qui est virtuel, mais uniquement l'environnement d'exécution. Un seul et même noyau est utilisé par des containers qui sont isolés les uns des autres. C'est moins flexible que la virtualisation (on ne peut pas mélanger Windows/Linux), mais ça consomme moins de ressources systèmes. Techniquement ça repose sur chroot et cgroups. Exemple : OpenVZ, VServer, LXC, … et Docker dont nous parlerons ici.

Déploiement d'application

Actuellement, la solution la plus facile pour distribuer une application complexe, c'est de la fournir sous forme de machine virtuelle. Mais dans la plupart des cas on pourrait faire la même chose avec des containers et c'est là que docker intervient.

Docker permet de créer un container sur une machine puis de l'exécuter sur n'importe quel autre.

Docker fournit un dépôt de conteneurs avec des images officielles et des images créées par les utilisateurs enregistrés, un peu à la manière des dépôts GIT.

Nota

Docker ne concerne que Linux, pourtant les autres Unix disposent aussi de containers :

Grand logo Docker

Aller plus loin

  • # Souligner APPLICATION et minimiser le mot virtualisation

    Posté par  . Évalué à 10.

    Rapide et précis : « déploiement d'application » !

    Pour faire très court (et pas très cours) :
    Il y a des années, un programme (en stand-alone) se découpait en : binaire, données, configuration et log.
    L'objectif de Docker est de mettre cette approche dans des services. Un container contient le binaire, pour le reste, il est préférable d'injecter la configuration, de monter de l'extérieur les répertoires contenant les données (DB généralement) et les logs.

    Les commandes exécutées dans le containers doivent tourner au premier plan, si l'application se termine alors le conteneur se terminé (il y a des moyens de lancer des applications en arrière plan avec Supervisord, par exemple). Pour faire tourner un site statique avec Apache, il y aura uniquement les PID d'Apache dans votre containers et rien de plus (dans d'init, pas de Bash, de SSH…)

    L'autre avantage de Docker est le versionnage des images disques : chaque commande effectuée dans un container crée une nouvelle image. La création d'un service est donc très rapide car on peut repartir d'une image dont la configuration était adéquate.

    Il faut repenser le design de son services dans ce sens, sinon cela reste de la virtuallisation.
    « Quand on a un marteau, on voit tout les problèmes comme des clous »

    • [^] # Re: Souligner APPLICATION et minimiser le mot virtualisation

      Posté par  . Évalué à 2. Dernière modification le 25 mars 2014 à 13:08.

      Pour faire tourner un site statique avec Apache, il y aura uniquement les PID d'Apache dans votre containers et rien de plus (dans d'init, pas de Bash, de SSH…)

      Est-ce que le processus qui tourne dans le conteneur est le PID 1 ? Si oui, je suppose qu’il est possible de lancer systemd ?

      En fait ma question est plus : si on suppose que mon application est un service PHP/nginx/postgres, est-ce que je dois distribuer trois conteneurs (myapp-phpfpm, myapp-postgres, myapp-nginx) ou un seul myapp ?

      Un container contient le binaire, pour le reste, il est préférable d'injecter la configuration, de monter de l'extérieur les répertoires contenant les données (DB généralement) et les logs

      Est-ce que ce n’est pas un peu opposé à l’idée « déploiement en une commande » ?

      • [^] # Re: Souligner APPLICATION et minimiser le mot virtualisation

        Posté par  . Évalué à 3.

        Il est possible de déployer un rootfs complet dans un conteneur. Un conteneur peut utiliser la stack ip de l'hote ou avoir sa propre instance (via les namespace) de stack ip et être relié à l'hote par des bridge par exemple.

        Pour une application PHP/nginx/postgres, je pense qu'il faut mettre PHP et nginx dans le même conteneur. Pour postgres, la communication se faisant par des sockets, l'application peut soit être dans le même conteneur, soit dans un conteneur séparé.

      • [^] # Re: Souligner APPLICATION et minimiser le mot virtualisation

        Posté par  . Évalué à 4.

        Est-ce que le processus qui tourne dans le conteneur est le PID 1 ? Si oui, je suppose qu’il est possible de lancer systemd ?

        L'objectif de Docker est justement de ne pas lancer init ou systemd mais on peut toujours le faire.

        En fait ma question est plus : si on suppose que mon application est un service PHP/nginx/postgres, est-ce que je dois distribuer trois conteneurs (myapp-phpfpm, myapp-postgres, myapp-nginx) ou un seul myapp ?

        Un seul conteneur ! Sauf si l'on veut donner de l'indépendance entre les services (Web/App/DB).
        Docker est une couche de LXC, il est donc possible d'attribuer un nombre de CPU, de mémoire, d'I/O ou d'espace disque (tout ce que peut faire cgroup).
        Une seule image permet de pouvoir le multiplier par la suite avec exactement les mêmes processus à l'intérieur.

        Il manque une chose importante de la philosophie Docker : il n'y a pas d'interface réseau visible de l'extérieur mais uniquement des ports bindés explicitement depuis l'hôte. Ce qui est déroutant au début ;-)
        Docker utilise son propre bridge réseau (que l'on peut lier sur plusieurs machines avec vSwitch) et dans lequel on peut attribuer des IP (statiquement ou par DHCP).

        Est-ce que ce n’est pas un peu opposé à l’idée « déploiement en une commande » ?

        C'est l'objectif que je vois dans Docker. Une commande pour une application. Le fait qu'elle soit « découper » (ce que je préconise) permet simplement de « bien » penser son système en délimitant chaque chose. La sauvegarde des données ne se fait pas de la même façon que la configuration (qui est dans un gestionnaire de version).

        Cependant, il manque dans Docker un environnement de lancement des conteneurs (l'attribution de certains paramètres, des montages externes, des interdépences entre service…).
        Pour le moment, cette partie est à gérer à la main (ou avec des outils d'orchestration…)

        Pour reprendre sur PHP/nginx/postgres. Ce que l'on veut c'est configurer le conteneur pour avoir un site fonctionnelle « out of the box » avec les paramètres de NGinx, PHP et Postgres aux petits oignons. Ensuite l'exécution de ce container ce fait avec une base de données que j'hébergerai sur l'hôte (en lien des répertoires). Ainsi lorsqu'il y aura des mises à jour, on rejoue le Dockerfile, on copie la BD dans un autre répertoire (pour éviter les bêtises) et on lance ce nouveau container pour tester que tout marche bien.

        • [^] # Re: Souligner APPLICATION et minimiser le mot virtualisation

          Posté par  (site web personnel) . Évalué à -2.

          "L'objectif de Docker est justement de ne pas lancer init ou systemd mais on peut toujours le faire."

          Mouais. Il faut se lever tot quand meme.

          Dans la pluspart des cas, ca va foirer pour des raisons X ou Y.

          De plus, l'un des desavantages de la containeurisation est de passer outre les applications dependentes des kernel headers (iptables, etc…).

          • [^] # Re: Souligner APPLICATION et minimiser le mot virtualisation

            Posté par  (site web personnel) . Évalué à 5.

            De plus, l'un des desavantages de la containeurisation est de passer outre les applications dependentes des kernel headers (iptables, etc…).

            Ah, nouveauté, il n'est plus possible de faire des règles iptables dans un conteneur LXC ? Dommage, ca fonctionnait super bien avant pourtant.

        • [^] # Re: Souligner APPLICATION et minimiser le mot virtualisation

          Posté par  . Évalué à 3.

          Je ne suis pas sur de comprendre.

          Reprenons l'exemple du conteneur avec une appli PHP qui a besoin de postgres. Si on met pas apache ou ngnix en processus principal (et donc, pas de initd/systemd), comment je fais pour faire tourner postgresql à coté ? Est-ce que je dois faire un script qui lance postgresql en background, et je fais un exec sur mon serveur web ?

          Et si j'ai tout faux, et qu'il faut un conteneur web et un postgresql, tout de suite, je vois moins l'intérêt.

          Bref, je trouve le concept très très intéressant, mais je suis pas sur de tout avoir compris, et j'ai pas trop envie de faire de container foireux que je devrai refaire plus tard.

  • # Sécurité

    Posté par  (site web personnel) . Évalué à 5.

    Il y a (avait) un problème de sécurité avec LXC. C'est assez facile d'arrêter la machine maître par exemple si mes souvenirs sont bons. Avec LXC, on dresse la liste des choses qu'on ne veut pas et non l'inverse, ce qui est aussi problématique.

    Bref, très performant mais personnellement, je ne les utilise qu'en interne, jamais dans un DMZ.

    • [^] # Re: Sécurité

      Posté par  . Évalué à 10.

      Depuis LXC 1.0, on peut lancer les conteneurs en tant que simple utilisateur, ça veut dire que le root du conteur ne peut pas avoir plus de droit que l'utilisateur qui le lance, ça limite déjà pas mal la surface d'attaque.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # dans la presse

    Posté par  (site web personnel) . Évalué à 5.

  • # Il y a justement une présentation de Docker ce jeudi 27 mars (soir) à Grenoble...

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    qui est organisée par le groupe d'utilisateur python de Grenoble - http://www.meetup.com/Groupe-dutilisateurs-Python-Grenoble/events/171032122

  • # Hum ?

    Posté par  . Évalué à 8.

    Il manquerait pas une partie de la dépêche ? Elle présente pas grand chose…

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.