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.
C'est à votre tour maintenant ! Vous devez rajouter les builds de l'API dans le registry. Pensez également quand il faut construire cette image. Par exemple: pensez-vous qu'il soit nécessaire de reconstruire l'image si les tests changent mais aucun fichier source ne change ?
Changer le .gitlab-ci.yml du repo de l'API pour construire l'image et vérifiez si l'image a bien été envoyée.
Donc, n'oubliez pas de vérifier le registry du répository ! Une fois bon, faites de même pour front et global.
A 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 .gitlab-ci.yml, vous devez toujours vous identifier.
Cependant, le système par mot de passe ne fonctionnera pas.
En effet, le mot de passe vous donnera accès au registry du repo "global" et non des autres.
Nous allons opter pour la deuxième option présentée par Gitlab: le jeton.
echo "$CI_JOB_TOKEN" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
Ce dernier permet d'identifier la provenance du job avec son repo. Or, durant le laboratoire précédent, nous avons autorisé les accès aux autres repos via le repo global. Essayez de repérer dans quel job vous devriez utiliser l'identification par token.
Le token permet d'accéder (et donc de lire) le registre d'un autre répertoire. Posez-vous donc la question suivante: quel job a besoin de pouvoir lire les images des autres répertoires ?
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 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.
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, puis dans "Access tokens", puis dans la partie Personal access token.
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.
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.
