Déployer ces conteneurs dans un serveur distant

On sait maintenant comment plus ou moins créer une image et lancer un conteneur en local. C’est top, mais pas très utile si l’on veut déployer notre image dans un serveur distant.

À la manière de Git qui dispose de sites / dépôt type GitHub, GitLab, BitBuckets … Docker dispose de la même idée que l’on appelle registry. Un registry est un dépôt distant d’image de conteneur.

Il existe plusieurs registry, dont celui de GitLab (gratuit pour tous les projets, mais avec une limite de taille) ou celui de Docker par exemple, nommé DockerHub. DockerHub n’est gratuit que pour les images dites “publiques”. C'est-à-dire les images dont l’accès est disponible pour tous.

D’ailleurs, par défaut, lorsque docker ne trouve pas une image en local, il tente de la télécharger en ligne sur le registry de DockerHub.

Envoyé une image sur ces registry est accessible à tous, et ce que nous allons faire.

L’intérêt est de pouvoir construire une image en local (ou dans une pipeline CI/CD) pour ensuite l’envoyer sur le registry afin de pouvoir récupérer et lancer l’image directement depuis le serveur de production.

ATTENTION : si tu mets en ligne sans contrôle d’accès (de manière publique) tes images, toutes tes images sont accessibles par tous ! Fais bien attention de ne pas envoyer de clef / mot de passe dans ton image si elle est publique. De manière générale, il ne faut jamais mettre de secret dans une image docker, et plutôt les fournir au lancement du conteneur en variable d’environnement par exemple.

Avant de pouvoir envoyer quelques chose sur un registry, il faut se connecter à ce dernier. Pour cela, on utilise la commande docker login <registry>. L’option registry peut être omise si on se connecte directement à DockerHub.

Par exemple, pour se connecter au registry de GitLab

docker login registry.gitlab.com

N’importe quelle image construite à partir d’un Dockerfile peut être envoyé en ligne. Juste après le docker build, on utilise docker push pour envoyer une image en ligne.

Il y a tout de même une particularité. Pour savoir où envoyer l’image (dans quel registry et sur quel compte), docker utilise les tags de l’image. Il faut donc ajouter un tag, respectant une syntaxe spécifique, pour envoyer notre image au bon endroit. Ce tag peut être ajouté au build, ou avec la commande docker image tag.

La syntaxe du tag est la suivante registry/compte/nom_image:<version>.

Par exemple, pour envoyer notre image sur le registry de gitlab, sur mon compte et en nommant l’image “monimage” dernière du nom, on écrit le tag suivant :

docker build --tag registry.gitlab.com/boutvalentin/monimage:latest .

Et l’on envoie notre image en ligne avec

docker push registry.gitlab.com/boutvalentin/monimage:latest

À chaque nouveau build de l’image, il ne faut pas oublie d’envoyer aussi l’image avec docker push.

Sur le serveur distant, on doit faire la même première étape, c'est-à-dire s’identifier.

docker login <registry>

Une fois fais, il nous reste plus qu’à télécharger l’image, avec docker pull <tag> ou simplement de lancer un conteneur, car docker se chargera d’aller télécharger l’image si elle n’est pas dispo en local.

docker pull registry.gitlab.com/boutvalentin/monimage:latest
docker run registry.gitlab.com/boutvalentin/monimage:latest

Takeaways

Les images docker peuvent être stockés en ligne pour être ensuite téléchargé par d’autres personnes ou sur d’autres ordinateurs. C’est que l’on appelle des registry.

Il existe plusieurs registry tel que DockerHub ou le registry de Gitlab.

Pour pouvoir envoyer des images ou les télécharger si elles ne sont pas publiques, il faut utiliser docker login <registry>.

Pour envoyer une image sur un regsitry, docker utilise le tag de cette image pour savoir où l’envoyer. Il faut donc taguer nos images au moment du build, ou après avec docker image tag en respectant le format suivant : registry/compte/nom_image:version.

On envoie l’image avec docker push <tag>.

Sur un serveur distant ou un autre ordinateur, on peut récupérer cette image avec docker pull <tag> ou directement en lançant un conteneur docker run <tag>.