Docker & containers

La semaine dernière j’ai pu assister à une formation docker chez Hopwork.

Le formateur, David Gageot nous a fait une bonne intro dans le monde de docker. La formation était surtout technique et donc composée de pratique mais j’ai quand même 2/3 commentaires à ajouter aux slides que j’ai ajouté en bas.

  • Notion de non-persistence: par défaut si on éteint un container et qu’on le reboot, les changements qui y ont été effectués sont perdus.
  • Les containers sont surtout un moyen de partager des binaires prêts à l’emploi donc en redémarrant un binaire (= un container = une image), on repart dans son état initial
  • Les containers sont limités à linux / linux : on utilise le kernel de la machine hôte pour émuler le kernel du système qu’on veut « faire tourner »
  • L’isolation entre containers se fait au niveau des applications. Tout ce qui est mutualisable entre 2 containers l’est. Par exemple les fichiers readonly /etc sont partagés entre 2 containers émulant le même système.
  • Docker exploite des technologies déjà connues (lxc par exemple) mais son apport est une standardisation du système et donc la possibilité d’échanger facilement des containers
  • On crée des dockerfile pour créer un container (= une recette) mais on partage le container déjà construit (= le gâteau)
  • Il n’y pas d’include dans les dockerfile mais on fait de l’héritage entre containers : par exemple on crée un  container « debian 7 » puis un container « apache » qui va utiliser « debian 7 » puis un container applicatif qui va contenir la conf d’un vhost
  • Par défaut aucun port du container n’est exposé
  • Possibilité d’avoir des démons pour faire tourner les containers, les ports peuvent être mappés au démarrage du container i.e: une machine qui héberge 10 containers java avec chaque container qui écoute son port 8080, on choisi au démarrage le port de la machine hote vers lequel on mappera le port: le port hote 8081 renvoie vers le 8080 du 1er container, le 8082 vers le 8080 du 2ème container, etc.

  • On peut lier des containers entre eux en leur donnant des noms (puisque pas d’ip fixe)

Toutes les infos de conf permettant de joindre le container (alias du container, ports accessibles, etc.) sont à définir au lancement du container pour être capable de lancer de multiples instances d’un même container sans conflit.

On peut faire des partages de dossiers de la même manière qu’avec une VM, possibilité de faire des data volume = un container qui ne fait que partager des volumes pour d’autres containers => on laisse les autres container monter tous les volumes de ce container. Beaucoup de risques de bugs sur les points de montages notamment car imaginons 2 containers mysql qui montent /var/lib/mysql/data => soucis

Aujourd’hui docker se développe très vite (la v1 est sorti en mars 2013) et est déjà stable pour la production, grâce notamment au fait qu’il n’agisse que comme un facilitateur et ne cherche pas à être un environnement fullstack. L’esprit étant d’être une seule brique et surtout d’agir comme un acteur de standardisation.

Si aujourd’hui l’outil est mature pour la production, la gestion est pour le moment relativement compliquée dès qu’il s’agit d’avoir plusieurs serveurs. Quelques outils d’orchestration sont déjà disponibles mais il semble que pour pouvoir réellement mettre ça en oeuvre à grande ampleur il faille beaucoup investir dans l’outillage autour du déploiement de la surveillance de ces instances. Un chiffre à retenir, google déploie chaque semaine 2 milliards de containers.

Présentation complète et + lisible sur google drive

 

Vous aimerez aussi...

1 réponse

  1. m dit :

    Je pense que cela va ruiner son héritage.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *