TOC

Comment construire des images Docker et héberger un référentiel d’images Docker avec GitLab

introduction

La conteneurisation est rapidement en train de devenir la méthode la plus répandue pour empaqueter et déployer des applications dans des environnements en nuage. La standardisation qu’il fournit, ainsi que l’efficacité de ses ressources (par rapport aux machines virtuelles complètes) et sa flexibilité, en font un formidable catalyseur de la mentalité moderne de DevOps. De nombreuses stratégies de déploiement, d’orchestration et de surveillance cloud native intéressantes deviennent possibles lorsque vos applications et microservices sont entièrement conteneurisés.

Docker Les conteneurs sont de loin le type de conteneur le plus courant à l’heure actuelle. Bien que les référentiels d’images Docker publics tels que Docker Hub regorgent d’images logicielles open source conteneurisées que vous pouvez «docker tirer +» et utiliser aujourd’hui, pour le code privé, vous devrez soit payer un service pour construire et stocker vos images, ou exécuter votre propre logiciel pour le faire.

GitLab Community Edition est une suite logicielle auto-hébergée qui fournit notamment l’hébergement de référentiels Git, le suivi de projets, les services de CI / CD et un registre d’images Docker. Dans ce tutoriel, nous utiliserons le service d’intégration continue de GitLab pour créer des images Docker à partir d’un exemple d’application Node.js. Ces images seront ensuite testées et téléchargées dans notre propre registre privé Docker.

Conditions préalables

Avant de commencer, nous devons configurer * un serveur GitLab sécurisé * et * un coureur GitLab CI * pour exécuter des tâches d’intégration continues. Les sections ci-dessous fourniront des liens et plus de détails.

Un serveur GitLab sécurisé avec SSL

Pour stocker notre code source, exécuter les tâches CI / CD et héberger le registre Docker, une instance GitLab doit être installée sur un serveur Ubuntu 16.04. GitLab recommande actuellement * un serveur avec au moins 2 cœurs de processeur et 4 Go de RAM *. De plus, nous allons sécuriser le serveur avec des certificats SSL de Let’s Encrypt. Pour ce faire, vous aurez besoin d’un nom de domaine dirigé vers le serveur.

Vous pouvez compléter ces conditions préalables avec les tutoriels suivants:

Un coureur GitLab CI

Comment configurer des pipelines d’intégration continue avec GitLab CI sur Ubuntu 16.04 vous donnera un aperçu du service CI de GitLab et vous montrera comment configurer un coureur de CI pour traiter des travaux. Nous allons construire sur l’application de démonstration et l’infrastructure de runner créées dans ce tutoriel.

Étape 1 - Configuration d’un coureur GitLab CI privilégié

Dans le didacticiel d’intégration continue GitLab, nous avons configuré un coureur GitLab à l’aide de + sudo gitlab-runner register + et de son processus de configuration interactif. Ce programme est capable d’exécuter des versions et des tests de logiciels à l’intérieur de conteneurs Docker isolés.

Cependant, pour créer des images Docker, notre coureur doit avoir un accès complet à un service Docker lui-même. Le moyen recommandé de le configurer consiste à utiliser l’image officielle + docker-in-docker de Docker pour exécuter les travaux. Cela nécessite d’accorder au coureur un mode d’exécution spécial + privilégié +, nous allons donc créer un deuxième coureur avec ce mode activé.

En raison des problèmes de sécurité liés à l’utilisation d’un programme privilégié, nous allons créer un programme spécifique au projet qui acceptera uniquement les travaux Docker sur notre projet + hello_hapi + (les administrateurs de GitLab pourront toujours l’ajouter manuellement à d’autres projets ultérieurement.) ) Depuis votre page de projet + hello_hapi +, cliquez sur * Paramètres * en bas du menu de gauche, puis sur * CI / CD * dans le sous-menu:

image: https: //assets.digitalocean.com/articles/gitlab-docker/settings-ci.png [Menu des paramètres du projet GitLab]

Maintenant, cliquez sur le bouton * Développer * à côté de la section * Paramètres du coureur *:

image: https: //assets.digitalocean.com/articles/gitlab-docker/runner-expand.png [bouton de développement de GitLab "Paramètres du coureur"]

Des informations sur la configuration d’un * Specific Runner *, y compris un jeton d’enregistrement, seront fournies. Prenez note de ce jeton. Lorsque nous l’utilisons pour inscrire un nouveau coureur, celui-ci sera verrouillé uniquement sur ce projet.

image: https: //assets.digitalocean.com/articles/gitlab-docker/runner-token.png [Options des coureurs spécifiques au projet GitLab]

Alors que nous sommes sur cette page, cliquez sur le bouton * Désactiver les coureurs partagés *. Nous voulons nous assurer que nos tâches Docker s’exécutent toujours sur notre coureur privilégié. Si un coureur partagé non privilégié était disponible, GitLab pourrait choisir de l’utiliser, ce qui entraînerait des erreurs de construction.

Connectez-vous au serveur sur lequel se trouve votre coureur de CI actuel. Si vous n’avez pas encore configuré de machine avec des coureurs, revenez en arrière et complétez la page https://www.digitalocean.com/community/tutorials/how-to-set-up-continuous-integration-integration-pipelines-with-gitlab. -ci-on-ubuntu-16-04 # installation de la section gitlab-ci-runner-service [Installation du service GitLab CI Runner +] du didacticiel préalable avant de poursuivre.

Maintenant, exécutez la commande suivante pour configurer le coureur privilégié spécifique au projet:

sudo gitlab-runner register -n \
 --url https:/// \
 --registration-token  \
 --executor docker \
 --description "" \
 --docker-image "docker:latest" \
 --docker-privileged
OutputRegistering runner... succeeded                     runner=61SR6BwV
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Assurez-vous de substituer vos propres informations. Nous définissons toutes les options de notre coureur sur la ligne de commande au lieu d’utiliser les invites interactives, car elles ne nous permettent pas de spécifier le mode `+ - privilégié +.

Votre coureur est maintenant configuré, enregistré et en cours d’exécution. Pour vérifier, revenez à votre navigateur. Cliquez sur l’icône représentant une clé dans la barre de menus principale de GitLab, puis cliquez sur * Runners * dans le menu de gauche. Vos coureurs seront listés:

image: https: //assets.digitalocean.com/articles/gitlab-docker/runner-list.png [Liste des coureurs GitLab]

Maintenant que nous avons un coureur capable de créer des images Docker, configurons un registre privé Docker sur lequel il peut envoyer des images.

Étape 2 - Configuration du registre de Docker de GitLab

La configuration de votre propre registre Docker vous permet de transférer et d’extraire des images de votre propre serveur privé, ce qui renforce la sécurité et réduit les dépendances de votre flux de travail sur des services externes.

GitLab va configurer un registre privé Docker avec seulement quelques mises à jour de configuration. Nous allons d’abord configurer l’URL du registre. Ensuite, nous allons (éventuellement) configurer le registre pour qu’il utilise un service de stockage d’objets compatible S3 pour stocker ses données.

SSH sur votre serveur GitLab, puis ouvrez le fichier de configuration GitLab:

sudo nano /etc/gitlab/gitlab.rb

Faites défiler jusqu’à la section * Container Registry settings *. Nous allons décommenter la ligne + registry_external_url + et la définir sur notre nom d’hôte GitLab avec un numéro de port égal à + ​​5555 +:

/etc/gitlab/gitlab.rb

registry_external_url 'https://:5555'

Ensuite, ajoutez les deux lignes suivantes pour indiquer au registre où trouver nos certificats Let’s Encrypt:

/etc/gitlab/gitlab.rb

registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live//fullchain.pem"
registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live//privkey.pem"

Enregistrez et fermez le fichier, puis reconfigurez GitLab:

sudo gitlab-ctl reconfigure
Output. . .
gitlab Reconfigured!

Mettez à jour le pare-feu pour autoriser le trafic sur le port de registre:

sudo ufw allow 5555

Passez maintenant à une autre machine sur laquelle Docker est installé et connectez-vous au registre privé Docker. Si Docker n’est pas installé sur votre ordinateur de développement local, vous pouvez utiliser le serveur configuré pour exécuter vos travaux GitLab CI, car Docker est déjà installé sur celui-ci:

docker login :5555

Vous serez invité à entrer votre nom d’utilisateur et votre mot de passe. Utilisez vos informations d’identification GitLab pour vous connecter.

OutputLogin Succeeded

Succès! Le registre est configuré et fonctionne. Actuellement, il stockera les fichiers sur le système de fichiers local du serveur GitLab. Si vous souhaitez plutôt utiliser un service de stockage d’objets, continuez avec cette section. Sinon, passez à l’étape 3.

Pour configurer un backend de stockage d’objets pour le registre, nous devons connaître les informations suivantes sur notre service de stockage d’objets:

  • Clef d’accès

  • Clef secrète

  • * Region * (+ us-east-1 +), par exemple, si vous utilisez Amazon S3, ou * Region Endpoint *, si vous utilisez un service compatible S3 (+ https: // nyc.digitaloceanspaces.com +)

  • * Nom du seau *

Si vous utilisez DigitalOcean Spaces, vous pouvez savoir comment configurer un nouvel espace et obtenir les informations ci-dessus en consultant https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean- space-and-api-key [Comment créer un espace DigitalOcean et une clé API].

Lorsque vous avez les informations de stockage d’objets, ouvrez le fichier de configuration GitLab:

sudo nano /etc/gitlab/gitlab.rb

Encore une fois, faites défiler jusqu’à la section du registre de conteneurs. Recherchez le bloc + registry ['storage'] +, décommentez-le et mettez-le à jour, en vous assurant de substituer vos propres informations le cas échéant:

/etc/gitlab/gitlab.rb

registry['storage'] = {
 's3' => {
   'accesskey' => '',
   'secretkey' => '',
   'bucket' => '',
   'region' => '',
   'regionendpoint' => ''
 }
}

Si vous utilisez Amazon S3, vous n’avez besoin que de + région + et non de + régionendpoint +. Si vous utilisez un service compatible S3 tel que Spaces, vous aurez besoin de + regionendpoint +. Dans ce cas, + région + ne configure rien et la valeur que vous entrez importe peu, mais elle doit toujours être présente et non vide.

Enregistrez et fermez le fichier.

Reconfigurez GitLab une fois de plus:

sudo gitlab-ctl reconfigure

Sur votre autre ordinateur Docker, connectez-vous à nouveau au registre pour vous assurer que tout va bien:

docker login :5555

Vous devriez recevoir un message + Login Succeeded +.

Maintenant que notre registre Docker est configuré, mettons à jour la configuration de notre application pour créer et tester notre application, et transmettons les images Docker à notre registre privé.

Étape 3 - Mise à jour de + gitlab-ci.yaml + et construction d’une image Docker

Pour que notre application soit créée dans Docker, nous devons mettre à jour le fichier + .gitlab-ci.yml +. Vous pouvez éditer ce fichier directement dans GitLab en cliquant dessus depuis la page principale du projet, puis en cliquant sur le bouton * Modifier *. Alternativement, vous pouvez cloner le référentiel sur votre machine locale, éditer le fichier, puis + git push + le retourner à GitLab. Cela ressemblerait à ceci:

git clone [email protected]:sammy/hello_hapi.git
cd hello_hapi
# edit the file w/ your favorite editor
git commit -am "updating ci configuration"
git push

Tout d’abord, supprimez tout le fichier, puis collez la configuration suivante:

gitlab-ci.yml
image: docker:latest
services:
- docker:dind

stages:
- build
- test
- release

variables:
 TEST_IMAGE: //hello_hapi:$CI_COMMIT_REF_NAME
 RELEASE_IMAGE: //hello_hapi:latest

before_script:
 - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN

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

Assurez-vous de mettre à jour les adresses URL et les noms d’utilisateur en surbrillance avec vos propres informations, puis enregistrez-les avec le bouton * Valider les modifications * de GitLab. Si vous mettez à jour le fichier en dehors de GitLab, validez les modifications et + git push + dans GitLab.

Ce nouveau fichier de configuration demande à GitLab d’utiliser la dernière image du menu fixe (+ image: docker: latest +) et de la relier au service docker-in-docker (menu fixe: dind). Il définit ensuite les étapes + build,` + test` et + release. L’étape + build construit l’image Docker à l’aide du` + Dockerfile` fourni dans le référentiel, puis la télécharge dans notre registre d’images Docker. Si cela réussit, l’étape + test téléchargera l’image que nous venons de construire et exécutera la commande` + npm test` à l’intérieur de celle-ci. Si la phase de test réussit, la phase + release + extrait l’image, la marque comme + hello_hapi: latest + et la renvoie au registre.

En fonction de votre flux de travail, vous pouvez également ajouter des étapes + test, voire des étapes` + deploy` supplémentaires, qui poussent l’application dans un environnement de transfert ou de production.

La mise à jour du fichier de configuration aurait dû déclencher une nouvelle construction. Revenez dans le projet + hello_hapi + dans GitLab et cliquez sur l’indicateur d’état du CI pour la validation:

image: https: //assets.digitalocean.com/articles/gitlab-docker/commit-widget.png [Notification de validation GitLab avec l’icône du statut du pipeline]

Sur la page résultante, vous pouvez ensuite cliquer sur l’une des étapes pour voir leur progression:

image: https: //assets.digitalocean.com/articles/gitlab-docker/commit-pipeline.png [Détail du pipeline GitLab]

image: https: //assets.digitalocean.com/articles/gitlab-docker/stage-detail.png [Progression de l’étape du pipeline GitLab]

Finalement, toutes les étapes doivent indiquer qu’elles ont réussi en affichant des icônes en forme de coche verte. Nous pouvons trouver les images Docker qui viennent d’être construites en cliquant sur l’élément * Registre * dans le menu de gauche:

image: https: //assets.digitalocean.com/articles/gitlab-docker/docker-list.png [Liste des images du registre de conteneurs GitLab]

Si vous cliquez sur la petite icône "document" à côté du nom de l’image, la commande + docker pull …​ + appropriée sera copiée dans votre presse-papiers. Vous pouvez ensuite tirer et exécuter votre image:

docker pull
docker run -it --rm -p 3000:3000
Output> [email protected] start /usr/src/app
> node app.js

Server running at: http://56fd5df5ddd3:3000

L’image a été extraite du registre et démarrée dans un conteneur. Basculez vers votre navigateur et connectez-vous à l’application sur le port 3000 pour le tester. Dans ce cas, nous utilisons le conteneur sur notre ordinateur local pour pouvoir y accéder via * localhost * à l’URL suivante:

http://localhost:3000/hello/test
OutputHello, test!

Succès! Vous pouvez arrêter le conteneur avec + CTRL-C +. À partir de maintenant, chaque fois que nous mettons un nouveau code dans la branche + master + de notre référentiel, nous construisons et testons automatiquement une nouvelle image + hello_hapi: latest +.

Conclusion

Dans ce didacticiel, nous avons configuré un nouveau coureur GitLab pour créer des images Docker, créé un registre privé Docker pour les stocker et mis à jour une application Node.js pour qu’elle soit construite et testée à l’intérieur des conteneurs Docker.

Pour en savoir plus sur les différents composants utilisés dans cette configuration, vous pouvez consulter la documentation officielle de GitLab CE, https://docs.gitlab.com/ee. /administration/container_registry.html[GitLab Container Registry], et Docker.

Related