Image custom sur le registry
Nous l'avons vu dans le laboratoire précédent: nous avons besoin des images Docker. Le souci est simple: construire une image Docker, ça prend du temps. Dans le laboratoire 4, nous devions construire trois images: celles de l'API, du front et de Testcafe. Cependant, ce n'était pas forcément le plus pratique.
Dans ce laboratoire, nous allons essayer de construire un pipeline efficace pour avoir une construction d'image quand c'est nécessaire. Vous allez repartir du laboratoire précédent et nous allons apporter des modifications au fur et à mesure.
Ce laboratoire s'appuie fortement sur l'écosystème Docker ! Si vous avez des doutes sur le fonctionnement de certaines choses, n'hésitez pas à consulter la documentation !
Introduction
Docker utiliser un système de registry. Quand vous lui demandez d'utiliser une image qu'il ne connait pas (qu'il a déjà chargée), il va aller récupérer cette image dans le registry. Par défaut, Docker va se rendre sur le registry de Docker Hub. Mais il est possible de lui demander de voir d'autres registry comme celui de Gitlab.
Gardez à l'esprit que les images prennent de la place. Si vous utilisez la version en ligne de Gitlab, sachez que les comptes ont une taille limite. Cette limite tient compte des fichiers du projet (fichiers, images, etc) et également des images de container que vous créées.
Exercice 1: création d'image dans le registry
Dans un premier temps, nous allons consacrer nos efforts à envoyer une image dans le registry de Gitlab. Comme nos repo sont privés, il va de soi que les registry le sont aussi ! Donc, nous allons devoir nous identifier dans notre job pour accéder au registry.
Il faut se connecter au registry en utilisant la commande docker login.
Dans notre job, nous avons deux possibilités:
- via mot de passe
- via token
Dans le cas du mot de passe, ce dernier est généré par Gitlab et n'est valable que durant l'exécution du job. Pour récupérer ce mot de passe, il faut passer par des variables prédéfinies dans Gitlab. Donc, dans notre job, nous devrons faire:
- récupérer ce mot de passe
- l'adresse du registry
- l'utilisateur pour se connecter Tout se trouve dans des variables et il suffira d'utiliser cette commande:
echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
La commande a l'air un peu mystérieuse, mais elle est en réalité assez simple.
docker login prend les informations nécessaires via les paramètres de la ligne de commande.
Par contre, il faut encore le mot de passe et il n'est pas possible de faire passer via un paramètre.
La solution consiste à utiliser un pipe pour "simuler" une entrée utilisateur sur le clavier.
Exercice 1.1: back
C'est à votre tour maintenant !
Commencez par le répertoire back, rajoutez un stage de build et un job build.
Vous aurez besoin de 3 instructions pour arriver à votre objectif.
Je vous conseille de lire cette page: https://docs.gitlab.com/user/packages/container_registry/build_and_push_images/?tab=From+the+container+registry.
Elle vous donnera les instructions à effectuer ainsi que les variables nécessaires.
Je vous conseille vivement de voir la documentation pour comprendre le contenu de ces variables.
En effet, la partie 2 du laboratoire risque de devenir complexe si vous n'avez aucune idée du contenu.
Vous ne devez rien faire pour front, celui-ci n'a pas besoin d'une image.
Pour voir si tout est bon, allez voir le registry de votre répertoire:
Ici, nous avons juste push une image pour back dans son registry.
On ne l'utilisera pas dans global à l'exercice 1.2 mais à l'exercice 2
Exercice 1.2: global
Pour global:
- Ajoutez un stage "build"
- Construisez l'image pour le
back - Construisez l'image pour le
front - Construisez l'image pour le
global
Vous devrez réfléchir à
- Est-ce que ces jobs de build dépendent d'un autre job ? (pensez au laboratoire précédent)
- Quand vous devrez construire ces images (
rules)
À chaque fois, n'oubliez pas de vérifier que tout est bon, car vous aurez besoin de ces images pour l'exercice 2 !
Exercice 2: Utilisation de l'image dans un projet
Maintenant, nous allons utiliser ces images dans notre répertoire global.
En effet, c'est dans ce projet que nous construisions chaque fois nos images.
Il faut s'occuper de ce fichier compose.yml.
Actuellement, nous utilisons soit les images classiques disponibles sur Docker hub, soit nous les construisions nous-mêmes.
Cependant, si l'exercice 1 est correctement réalisé, il ne nous reste plus qu'à appeler ces images dans notre fichier.
Cette fois-ci, nous aurons besoin de changer deux fichiers:
compose.yml(dans le répertoire global).gitlab-ci.yml(dans le répertoire global)
Dans le fichier compose.yml, nous allons avoir besoin d'utiliser dynamiquement le nom de l'image que l'on souhaite utiliser.
Ainsi, si à l'avenir, nous souhaitons changer le nom de nos images, il serait assez facile de pouvoir adapter notre pipeline.
Pour utiliser une variable dans un fichier compose.yml, il suffit d'utiliser l'interpolation.
Derrière ce nom compliqué, se cache en réalité une simple syntax qui permet de déterminer où commence et finit une variable.
Dans un premier temps, ne regardez que pour l'API. Nous ferons le reste si tout fonctionne.
Revenez ensuite dans le fichier .gitlab-ci.yml, car nous devons maintenant passer cette variable à Docker compose.
Gitlab permet justement de créer des variables via variables.
Maintenant, à vous de modifier le fichier .gitlab-ci.yml pour insérer le bon nom de l'image.
Pour définir le nom de l'image, vous aurez besoin de 2 variables de Gitlab et probablement d'une petite chaîne de caractères en plus.
Vous aurez sûrement besoin des variables $CI_REGISTRY et $CI_PROJECT_NAMESPACE pour pouvoir accéder à l'image du back.
Si tout fonctionne, vous pouvez faire de même pour la partie front et global !
Exercice 3: Utilisation de l'image en dehors de votre projet
Parfait ! Il ne nous reste plus qu'une dernière chose à faire. On aimerait pouvoir se connecter à ce registry depuis l'extérieur. En effet, il existe des cas où ce sera le serveur distant qui va se connecter à notre registry. On pourrait également imaginer un cas où un développeur aimerait récupérer l'image produite par nos pipelines pour les étudier. Dans ce cas, il faut un token d'une "entité" (une personne ou un groupe) pouvant accéder au registry.
Nous utilisons la version gratuite de Gitlab.com qui ne permet pas de créer un token pour un groupe. Nous n'avons donc pas le choix et nous allons créer ce token au niveau de notre utilisateur.
Vous aurez besoin d'une machine pour tester le chargement de l'image depuis Gitlab. Vous pouvez utiliser votre ordinateur ou celui de l'école.
Allez dans votre profil sur Gitlab.com (paramètres utilisateur), puis dans la partie "Personal access tokens".
Vous devrez aussi choisir le scope de token. À votre avis, quel devrait-être les autorisations de votre token en sachant qu'il ne sera utile UNIQUEMENT utiliser pour obtenir des images ?
Une fois crée, n'oubliez pas de copier votre token quelque part, car une fois que vous aurez quitté la page, vous ne pourrez plus l'obtenir.
Maintenant, il ne reste plus qu'à utiliser ce token pour que notre Docker puisse se connecter ! La commande pour ajouter le registry a été donnée un peu plus tôt dans le laboratoire.
Pour connaître l'adresse du registry, il vous suffit de la copier depuis l'interface. Au niveau de l'image Docker, vous avez un bouton pour copier son adresse.
Dans mon cas, en effectuant cette commande
docker pull registry.gitlab.com/devops9734207/back
j'ai pu récupérer l'image depuis le registry de Gitlab
Using default tag: latest
latest: Pulling from devops9734207/back
d49a2dee86fb: Already exists
6502d5344302: Pull complete
cf0e50e0378f: Pull complete
204fcb694ab0: Pull complete
62a9f0bcab8a: Pull complete
513fd504af04: Pull complete
Digest: sha256:263cd89e532e1a24e1b536cac7b923686c0f9f59a600f70858339ca236ca7583
Status: Downloaded newer image for registry.gitlab.com/devops9734207/back:latest
registry.gitlab.com/devops9734207/back:latest
Conclusion
Dans ce laboratoire, nous avons vu comment gérer la construction d'image dans Gitlab. Nous pouvons ainsi grandement améliorer l'efficacité de nos pipelines. Nous avons également vu comment rendre accessible ces images aux développeurs.
