La technologie de conteneurisation a grandement progressé dans le domaine technologique du développement de logiciels en tant que méthode la plus acceptée pour empaqueter et déployer des applications dans des environnements cloud. Cela a été rendu nécessaire par le besoin d'intégration continue (CI) et de déploiement continu (CD) qui sont des aspects déterminants du DevOps. Les développeurs et ingénieurs logiciels utilisent des conteneurs pour réaliser l'aspect CI/CD de l'architecture logicielle. Un conteneur est essentiellement une plateforme informatique portable, entièrement empaquetée et autonome. Bien qu'il existe plusieurs plateformes de conteneurs sur le web, Docker s'avère être la plus courante.
Docker est une plateforme de conteneurs open-source qui rend le développement efficace et prévisible. Docker propose un registre public d'images Docker disponible sur Docker Hub. Il contient de nombreuses images Docker open-source pour les implémentations les plus courantes que vous pouvez récupérer et utiliser. S'agissant d'un registre public, vous êtes également libre d'ajouter vos propres images Docker pour les partager avec le public. Si toutefois vous possédez du code privé/propriétaire, vous devrez peut-être payer pour un registre d'images privé ou créer votre propre service de registre d'images. C'est là que GitLab entre en jeu.
GitLab est un outil basé sur le web de Git dépôts qui est bien plus qu'un simple outil de contrôle de version. Il fournit des outils DevOps pour l'intégration et le déploiement continus, le suivi des tickets, des registres d'images Docker, et plus encore. Il propose trois options : GitLab Community Edition (CE), GitLab Enterprise Edition (EE) et GitLab SaaS. GitLab CE and GitLab EE sont des solutions auto-gérées qui vous permettent de télécharger, d'installer et de gérer vous-même l'instance GitLab. GitLab SaaS est hébergé par GitLab Inc., et vous n'avez pas à vous soucier d'installer quoi que ce soit pour l'utiliser.
Dans un tutoriel précédent, nous vous avons montré comment configurer une instance GitLab sur un serveur CloudSigma et héberger votre propre dépôt Git. Nous vous avons également montré comment implémenter des pipelines d'intégration continue avec GitLab runner pour créer et exécuter automatiquement vos tests à chaque nouveau commit. Si vous n'avez pas suivi les tutoriels mentionnés, veuillez le faire car ils constituent les bases de ce tutoriel.
Dans ce tutoriel, nous allons vous montrer comment créer une image Docker simple et l'héberger avec une instance GitLab auto-hébergée (que vous utilisiez la Community Edition ou l'Enterprise Edition – le déroulement des étapes est le même).
Prérequis
Pour suivre chaque étape de ce tutoriel, veuillez vous assurer que vous disposez d'un GitLab CI runner et d'un serveur GitLab auto-hébergé comme expliqué ci-dessous.
1. Un serveur GitLab sécurisé
Nous l'utiliserons pour stocker le code source, exécuter les tâches CI/CD et héberger le registre d'images Docker. Vous devriez disposer d'un serveur avec au moins 2 CPU cœurs et 4 Go de RAM comme recommandé par GitLab pour installer une instance GitLab auto-gérée. Vous aurez également besoin d'un nom de domaine enregistré pointant vers le serveur, car nous l'utiliserons pour obtenir un certificat SSL de Let’s Encrypt afin de sécuriser le serveur. Vous trouverez ci-dessous quelques liens à suivre pour configurer une instance GitLab auto-hébergée.
- Enregistrez un nom de domaine auprès du registraire de votre choix et pointez-le vers CloudSigma.
- Suivez ce tutoriel pour la configuration initiale du serveur Ubuntu, ajouter un utilisateur non-root, et activer le pare-feu UFW d'Ubuntu.
- Enfin, suivez ce tutoriel pour installer et configurer une instance GitLab auto-hébergée.
2. Un GitLab CI runner
Un GitLab CI runner est nécessaire pour exécuter des tâches automatisées sur vos cas de test. Le tutoriel sur comment configurer des pipelines d'intégration continue GitLab sur Ubuntu 20.04 vous donne un aperçu du serveur GitLab CI et vous montre comment déclencher des tâches. Suivez les étapes du tutoriel pour configurer le service GitLab CI runner si ce n'est pas déjà fait. Le tutoriel contient une application de démonstration Node.js avec des cas de test – nous l'utiliserons dans ce tutoriel.
Maintenant, commençons !
Étape 1 : Configuration d'un GitLab CI Runner privilégié
Dans le tutoriel sur la configuration d'un GitLab CI Runner, nous avons configuré un runner GitLab en utilisant la commande sudo gitlab-runner register commande qui nous a permis d'ajouter de manière interactive les paramètres requis. Bien que cela ait fonctionné pour notre cas d'utilisation précédent, qui consistait à exécuter des builds et des tests dans des conteneurs Docker isolés, cela peut ne pas gérer la construction d'images Docker. La construction d'images Docker nécessite que le runner ait un accès complet au service Docker. Vous pouvez obtenir cette configuration en utilisant le docker-in-docker officiel pour exécuter les tâches. Une telle configuration implique d'accorder au runner un privilégié d'exécution.
Bien que l'octroi du privilégié d'exécution soit nécessaire pour construire des images Docker, cela comporte des risques de sécurité. C'est parce que cela implique de renoncer aux avantages de sécurité des conteneurs. Vous pensez peut-être que les autres runners Docker sont sûrs, mais il se trouve qu'ils rencontrent les mêmes problèmes que ceux expliqués dans la documentation officielle de Docker.
Nous allons créer un autre runner avec le mode d'exécution privilégié. Ce sera un runner spécifique au projet en raison des implications de sécurité mentionnées ci-dessus. Il acceptera les tâches du projet Node Pipeline que nous avons créé dans le tutoriel sur comment configurer des pipelines CI continus avec GitLab.
La première chose à faire est de vérifier que les Shared Runners sont désactivés sur le projet. Depuis la page de projet du projet Node Pipeline, cliquez sur Settings dans le menu en bas à gauche et sélectionnez CI/CD dans le sous-menu :
Trouvez le bouton Expand dans la section Runners et cliquez dessus pour révéler les détails sur les runners disponibles :
Cliquez sur le commutateur pour Disable Shared Runners pour ce projet. Si vous aviez ajouté un runner spécifique au projet dans la section précédente, désactivez-le également. Nous allons ajouter un runner spécifique au projet privilégié afin d'exécuter les tâches de ce projet. Cela garantit que nous ne nous retrouvons pas avec des erreurs de build au cas où GitLab attribuerait de manière aléatoire des tâches à des runners qui n'ont pas été enregistrés avec un mode d'exécution privilégié. Dans la capture d'écran ci-dessus, sous l'onglet Specific runners, vous devriez voir le jeton d'enregistrement de votre projet. Notez-le car vous l'utiliserez ci-dessous.
| Note : Un runner spécifique au projet peut également être attribué à d'autres projets depuis la section Admin panel > Runners. Lorsque vous sélectionnez un runner dans la liste des runners, vous accédez à la page de configuration du runner. Faites défiler vers le bas pour afficher la section Restrict projects for this runner: |
Il est temps d'ouvrir votre terminal. Si vous n'avez pas suivi les étapes du tutoriel sur comment configurer des pipelines d'intégration continue GitLab sur Ubuntu 20.04, faites une pause dans ce tutoriel et suivez les étapes afin d'avoir un serveur avec le service de runner GitLab CI. Sinon, connectez-vous en SSH au GitLab CI runner server avec votre utilisateur sudo pour les étapes suivantes.
Pour configurer le runner spécifique au projet privilégié, entrez la commande suivante dans votre terminal, en remplaçant votre nom de domaine et le jeton d'enregistrement copiés ci-dessus :
|
1 2 3 4 5 6 7 |
sudo gitlab-runner register -n \ --url https://your-gitlab-instance-domain.com/ \ --registration-token your-project-specifc-registration-token \ --executor docker \ --description "docker-privileged-builder" \ --docker-image "docker:latest" \ --docker-privilegedh |
Cette sortie indique un enregistrement réussi :
Pour vérifier que votre instance GitLab a bien détecté le runner, retournez sur le navigateur et actualisez la page Settings > CI/CD. Développez la section Runners et vous devriez voir votre runner sous Specific Runners:
Facultativement, si vous allez dans la Admin Panel (en cliquant sur le bouton Menu dans la barre supérieure et en sélectionnant Admin), puis sélectionnez Runners dans les options du menu :
Vous should arriver sur cette page affichant tous les runners disponibles connectés à votre instance GitLab, à la fois les runners partagés et spécifiques au projet :
À ce stade, vous avez configuré avec succès un runner capable de construire des images Docker.
Étape 2 : Configuration du registre Docker de GitLab
Certains flux de travail cruciaux nécessitent une indépendance vis-à-vis des services externes. C’est là qu’intervient la version auto-gérée de GitLab du Docker Registry . Non seulement il est sécurisé, mais il vous garantit également la flexibilité d'adapter vos tâches et pipelines selon vos besoins. Pour configurer le Docker Registry, vous allez modifier le fichier de configuration de GitLab. Tout d'abord, connectez-vous en SSH à l'instance GitLab, puis ouvrez le fichier avec la commande suivante :
|
1 |
sudo nano /etc/gitlab/gitlab.rb |
Faites défiler vers le bas jusqu'à ce que vous voyiez Container Registry Settings:
Décommentez la ligne avec registry_external_url et définissez-la sur le nom de domaine de votre instance GitLab, en spécifiant le port 8888 à la fin :
|
1 |
registry_external_url 'https://your-gitlab-domain.com:8888' |
Ensuite, nous devons spécifier où le registre trouvera les certificats Let’s Encrypt en ajoutant les lignes suivantes. N'oubliez pas de modifier avec le nom de domaine réel de votre instance GitLab :
|
1 2 |
registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/your-gitlab-domain.com/fullchain.pem" registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/your-gitlab-domain.com/privkey.pem" |
Une fois terminé, enregistrez et fermez le fichier. Entrez la commande suivante dans votre terminal pour reconfigurer GitLab :
|
1 |
sudo gitlab-ctl reconfigure |
Ensuite, attendez quelques secondes que la commande se termine. Si elle réussit, vous devriez voir la sortie suivante :
Ensuite, nous devons nous assurer que le pare-feu (ufw) autorise le trafic vers le port du registre que nous avons attribué à l'aide de la commande :
|
1 |
sudo ufw allow 8888 |
Ensuite, vous devez tester que le Docker Registry fonctionne en vous y connectant depuis une autre machine sur laquelle Docker est installé à l'aide de la commande docker login . Si vous n'aviez pas configuré Docker sur votre environnement local, vous pouvez vous connecter en SSH au serveur du runner GitLab CI car Docker y est déjà installé. Ensuite, exécutez la commande suivante, en spécifiant bien sûr le nom de domaine de votre instance GitLab :
|
1 |
docker login your-gitlab-domain.com:8888 |
Votre sortie affichera le message Login Succeeded comme ceci :
Cela signifie que le registre a été configuré avec succès et qu'il fonctionne. Lorsque vous créez des images, elles seront stockées localement dans le système de fichiers du serveur GitLab. Cela convient pour un registre d'entreprise privé. Cependant, si vous prévoyez de laisser votre registre ouvert au public, vous pourriez avoir besoin d'un espace de stockage plus important. Heureusement, GitLab propose des options pour se connecter à des buckets de stockage. Vous pouvez en savoir plus dans la documentation du registre de conteneurs GitLab pour voir comment vous pouvez configurer un bucket de stockage pour votre instance GitLab.
Étape 3 : Modifier le fichier gitlab-ci.yml et créer une image Docker
Pour procéder à cette étape, vous devez disposer du projet Node Pipeline sur votre instance GitLab. Voici la vue du projet sur GitLab :
Nous avons parlé de gitlab-ci.yml comme étant le fichier que le runner GitLab CI lit lorsqu'il est déclenché pour savoir comment compiler votre application et effectuer des tests automatisés. Nous devons modifier ce fichier pour ajouter des instructions de construction d'images Docker. Vous pouvez choisir de modifier ce fichier directement dans l'interface de GitLab. Vous pouvez également le cloner sur votre machine locale et le modifier avec votre éditeur préféré, puis faire un commit et un git push vers GitLab. Par souci de concision, nous utiliserons l'interface de GitLab.
Cliquez sur le fichier pour l'ouvrir, puis cliquez sur le bouton Modifier :
Cela ouvre le fichier prêt à être modifié. Supprimez tout le contenu du fichier et ajoutez le code suivant :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
image: docker:20-dind services: - name: docker:20-dind alias: docker command: ["--tls=false"] stages: - build - test - release variables: TEST_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:$CI_COMMIT_REF_NAME RELEASE_IMAGE: gitlab-domain.com:8888/hackins/node_pipeline:latest DOCKER_HOST: tcp://docker:2375 DOCKER_DRIVER: overlay2 DOCKER_TLS_CERTDIR: "" before_script: - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab-domain.com:8888 build: stage: build script: - docker build --pull -t $TEST_IMAGE . - docker push $TEST_IMAGE test: stage: test script: - docker pull $TEST_IMAGE - docker run $TEST_IMAGE npm test release: stage: release script: - docker pull $TEST_IMAGE - docker tag $TEST_IMAGE $RELEASE_IMAGE - docker push $RELEASE_IMAGE only: - master |
Pendant que vous ajoutez l'extrait de code ci-dessus, n'oubliez pas de mettre à jour la partie en surbrillance avec vos informations réelles. Lorsque vous avez terminé, enregistrez les modifications en appuyant sur le bouton Commit changes. Si vous avez travaillé en dehors de GitLab, validez (commit) et poussez (push) vos modifications.
Comprenons ce que fait le code que nous avons ajouté au fichier .gitlab-ci.yml. La première ligne indique à GitLab d'utiliser l'image officielle Docker-in-Docker et l'associe au service docker-in-docker (docker:dind). Nous définissons ensuite les étapes pour build, test, et release. L'étape build construit l'image en utilisant les instructions du Dockerfile puis la téléverse vers le Docker Registry que nous avons configuré lors d'une étape précédente.
Lorsque l'étape build réussit, l'étape test télécharge l'image, l'exécute en tant que conteneur et exécute la commande npm test pour effectuer des tests automatisés à l'intérieur. Si l'étape test réussit, l'étape release prend le relais. Dans l'étape de release, l'image est téléchargée et étiquetée comme node_pipeline:latest. Elle est ensuite repoussée vers le registre.
Il ne s'agit que d'une configuration de base pour un projet de démonstration. Pour vos projets réels, vous pourriez avoir d'autres étapes, par exemple staging, production, etc. Lorsque vous enregistrez le fichier après modification, un pipeline est déclenché. Il commence alors à exécuter les tâches. Revenez à la page Node Pipeline. Vous devriez voir que la tâche est actuellement en cours d'exécution :
Cliquez sur l'icône de l'indicateur CI pour afficher les différentes étapes de la tâche :
Comme vous pouvez le voir sur la capture d'écran ci-dessus, toutes les étapes ont réussi, comme l'indiquent les icônes de coche vertes. Vous pouvez cliquer sur chaque étape pour voir le résultat de la tâche :
Dans le menu de gauche, cliquez sur Packages & Registres et sélectionnez Container Registry:
Cela affiche une page listant les images Docker disponibles pour le projet sélectionné. L'image que nous avons construite et publiée devrait apparaître dans la liste avec le tag assigné:
Cliquez pour révéler les différents tags de l'image :
Si Docker est installé dans votre environnement local, vous pouvez récupérer (pull) l'image et vérifier qu'elle fonctionne comme prévu. Cliquez sur l'icône Copier à côté du nom du tag de l'image. Cela copiera dans votre presse-papiers le nom complet de l'image que vous pourrez utiliser avec la commande docker pull :
|
1 2 |
docker pull feetspark.com:8888/hackins/node_pipeline:latest docker run -it --rm -p 8090:8090 feetspark.com:8888/hackins/node_pipeline:latest |
Les commandes ci-dessus vont récupérer l'image et l'exécuter dans un conteneur :
L'application est maintenant disponible sur le port 8090. Si vous ouvrez votre navigateur et accédez à votre-adresse-IP:8090 vous devriez voir la page s'afficher :
Si vous pouvez voir une telle page dans votre navigateur, cela signifie que vous avez réussi à créer une image Docker et à la partager sur un Docker Registry privé. À l'avenir, si vous apportez des modifications à la branche master, les étapes définies dans le fichier .gitlab-ci.yml seront exécutées, et si elles réussissent, une nouvelle image Docker avec le tag latest sera reconstruite et poussée vers le registre.
Conclusion
Dans ce projet, vous avez appris comment ajouter un runner GitLab privilégié à votre instance GitLab auto-hébergée afin de pouvoir créer des images Docker. Vous avez également configuré un registre d'images Docker privé pour héberger vos images. En utilisant le projet Node pipeline, vous avez pu tester chaque composant de la configuration et vous assurer qu'ils se connectaient et communiquaient comme prévu. Une fois votre image disponible dans le registre, vous avez pu la récupérer et confirmer qu'elle s'exécutait dans un conteneur.
Ceci est un tutoriel d'introduction, qui vous donne les bases sur lesquelles vous appuyer. Veuillez suivre la documentation officielle de GitLab pour en savoir plus sur GitLab. Ce lien peut fournir des informations sur le GitLab Container Registry.
Pour d'autres ressources sur l'utilisation de Docker, vous pouvez consulter d'autres tutoriels sur notre blog:
- Partager des données entre conteneurs Docker
- Configuration d'un registre Docker privé sur Ubuntu 18.04
- Comment partager des données entre un conteneur Docker et un hôte
- Nettoyer les ressources Docker – Images, conteneurs et volumes
Bonne informatique !
Commentaires
Aucun commentaire pour l'instant. Soyez le premier.