Et donc vous avez installé docker sous centos7 et vous voulez vous jeter dans le grand bain 🙂

1- Quelques notions de base

1,1 Les images

Pour vulgariser, les images sont les “iso” des distributions que vous allez utiliser dans vos containers. Ce sont des distributions “brutes” ou modifiées par la communauté (docker pour les officielles, mais vous en trouverez des custom faites par n’importe qui que ce soit sur le hub docker comme sur github).

Quand vous lancez un container en appelant une image, celle-ci est appelée localement, si elle n’existe pas, docker commencera par la télécharger.

Pour voir la liste des images que vous possédez en local, voici la commande :

Repository correspond au nom officiel de l’image.

Tag correspond à la version, les images sont versionnées, voir certaines images contiennent des tags en fonction de l’implémentation que vous voulez trouver au lancement. Par exemple, l’image officielle de PHP permet de choisir sa version d’apache et / ou le mode de fonctionnement de PHP et sa version.

Image ID : correspond à un ID unique qui identifie l’image, cet ID peut servir pour identifier une image à supprimer par exemple.

Pour supprimer une image, voici la commande :

Le petit tips si vous voulez supprimer la totalité de vos images :

docker images -q, pour information, liste uniquement les ID de vos images.

1,2 Les containers

Les containers sont donc des “instances” docker dans lesquelles tournent un process , une image. C’est à partir de cela que l’on peut créer nos services, nos VMs, fin bref vraiment faire ce que l’on veut.

Vous pouvez lister vos images sur votre disque via la commande :

-a liste la totalité des containers, en enlevant l’argument, vous voyez uniquement les containers qui sont en cours de fonctionnement.

Container ID  tout comme l’image, c’est l’ID unique de votre container.

Image l’image sur laquelle tourne votre container

Command le process principale qui tourne dans le container

Status Vous donne l’état du container, up pour actif, exited pour un container éteint (attention il y a une petite différence entre un container éteint et un data-container “éteint” mais nous y reviendrons) et restarting (le statut qui sent pas bon généralement, le container connaît souvent un problème et il restart en boucle)

Ports La liste des ports mappés entre le container et la machine hôte.

Il faut savoir que docker se créée un sous-réseau sur votre machine et va lancer ses containers dessus, vous pouvez donc pinger vos containers ou les faire communiquer entre eux si vous connaissez l’adresse du réseau docker. Vous pouvez aussi interagir directement avec vos containers par ce biais.

A gauche de l’expression commençant par 0.0.0.0 (ou 127.0.0.1) c’est le port de l’hôte, de votre machine, à droite de la virgule, le port à l’intérieur du container qui lui correspond.

Names Les petits noms customs de vos containers. A savoir que docker fait aussi des relations entre les noms et les IPS de votre instance, ce qui veut dire que depuis une instance de container en appelant le nom d’une autre, docker résout automatiquement l’IP.

Il est important de noter que les instances / containers dockers en l’état sont des instances éphémères, ce qui veut dire que si vous montez par exemple un serveur Web avec admettons WordPress dedans, en cas de coupure du container, toute les données qui ont pu être créées entre le démarrage du container et la coupure seront perdues… il convient donc d’utiliser des “data-container” pour la persistance. Je vais y venir 😉

La suppression de containers se fait via la commande :

Mais la plus grande question étant, comment lance-t-on une instance ?

La version simple :

exemple :

Dans cet exemple de commande j’ai lancé un container avec ubuntu (n’ayant pas précisé de tag, docker va aller prendre la dernière version sur le dépôt), j’ai ensuite demandé d’exécuter la commande /bin/bash pour avoir accès à bash dans le container.

Pour la liste des options, j’ai pris parti de mettre -ti. Pour vulgariser, -ti est l’option qui me permet de garder le terminal ouvert dans le container. Le –rm permet de détruire le container une fois que je sors de celui-ci. Vous pouvez enlever la commande si vous souhaitez que votre container fonctionne en permanence.

Personnellement, je commence toujours par un –rm pour effectuer mes tests.

Pour lancer le container avec ubuntu en fond et le laisser tourner :

Voila pour les commandes de base, je vous laisse apprécier les diverses images dispo sur le web.

1,3 Les volumes

Il existe plusieurs moyens de communiquer et surtout de partager des flux de données entre l’hôte et le container docker. Mais la communauté a prévu un système assez pratique s’ils sont bien utilisés : les volumes.

Pour vulgariser, vous pouvez faire des synchros entre un répertoire locale et un répertoire dans le container. Ce qui peut s’avérer très pratique si vous faites en environnement de dev en local.

Pour créer un volume, il suffit d’utiliser l’option à cet effet :

Ici je demande au container de lier le répertoire /var/tmp (donc à l’intérieur du container) avec le répertoire courant de la machine hôte. Il faut donc se positionner dans le répertoire qui doit être lié pour que ça marche correctement.

Mais rassurez-vous, vous pouvez aussi spécifier le répertoire local que vous voulez lier, exemple :

Alors petite précision nécessaire au niveau des volumes : les répertoires sont partagés entre la machine hôte et le container, ce qui veut dire que 2 utilisateurs différents vont utiliser le volume (ou plus), l’utilisateur local et l’utilisateur dans le container. Ces 2 utilisateurs ont forcément un id et un gid différent, ce qui peut créer quelques problèmes de droits.

C’est la raison pour laquelle j’utilise personnellement les volumes de cette manière (ou quelque peu détourné) en développement uniquement. Par contournement, tous les répertoires, fichiers créés en local ou dans le container pendant les phases de développement peuvent avoir des droits 777.

1,4 Les data containers

Les datas-containers sont le complément des containers. En schématisant, les containers contiennent l(applicatif, les datas containers… les datas 🙂 et surtout les datas containers ont une persistance, ce que les containers, eux comme énoncé plus haut, n’ont pas.

Le principe est plutôt simple, on lance une instance d’une image qui sera utilisée comme data-container, puis on le lie au container qui contient un applicatif à persister. Le tout en utilisant le principe des volumes 🙂

La création d’un data-container est simple :

Sur le même principe que tout à l’heure, on lance un container, on applique un volume à partager (/var/tmp dans mon exemple), on le nomme parce que c’est quand même plus propre et on lui précise l’image à utiliser.

Très souvent vous verrez dans les tutoriels l’utilisation de busibox ou de ces petites / grandes soeurs comme image pour les datas container, ce sont des “distrib” vides et donc peu coûteuses en place et en ressources qui ont pour vocation simplement d’amasser les datas. Alors encore un petit warning à ce sujet… Tout comme pour les volumes, les users peuvent différer entre le container et le data-container et générer des problèmes de droits… ce pourquoi personnellement encore, je lance des data-containers basés sur la même image que le container qui va servir de duo.

Si on reprend le principe que je suis depuis le début de ce tuto, il faudra donc créer un data-container sur une image ubuntu.

Pour lier vos 2 containers ensemble, il faut préciser l’option volumes-from pour le container principal (par le data-containers donc).

Aussi simple que ça.

Cette première phase d’initiation étant terminée, n’hésitez pas à poster en commentaires vos questions, remarques, suggestions.
A bientôt pour la suite 🙂