Comment mettre automatiquement à l’échelle le déploiement continu de GitLab avec GitLab Runner sur DigitalOcean

introduction

GitLab est un outil à code source ouvert utilisé par les équipes logicielles pour gérer l’ensemble de leur cycle de développement et de livraison. GitLab fournit un large éventail de fonctionnalités: suivi des problèmes, référentiels git, intégration continue, registre de conteneurs, déploiement et surveillance. Ces fonctionnalités sont toutes construites à partir de la base en une seule application. Vous pouvez héberger GitLab sur vos propres serveurs ou utiliser https://gitlab.com [GitLab.com], un service de cloud computing dans lequel les projets open source bénéficient gratuitement de toutes les fonctionnalités de premier plan.

La fonctionnalité d’intégration continue / livraison continue (CI / CD) de GitLab est un moyen efficace de prendre l’habitude de tester tout le code avant son déploiement. GitLab CI / CD est également hautement évolutif grâce à un outil supplémentaire, GitLab Runner, qui automatise la mise à l’échelle de votre file d’attente de construction afin d’éviter de longs délais d’attente pour les équipes de développement qui souhaitent libérer du code.

Dans ce guide, nous montrerons comment configurer une infrastructure GitLab hautement évolutive qui gère ses propres coûts et répond automatiquement à la charge en augmentant et en diminuant la capacité du serveur disponible.

Buts

Nous allons créer un processus CI / CD évolutif sur DigitalOcean qui répond automatiquement à la demande en créant de nouveaux serveurs sur la plate-forme et les détruit lorsque la file est vide.

Ces serveurs réutilisables sont créés par le processus GitLab Runner et sont automatiquement supprimés lorsqu’aucune tâche n’est en cours d’exécution, ce qui réduit les coûts et les coûts administratifs pour votre équipe.

Comme nous l’expliquerons dans ce didacticiel, vous contrôlez le nombre de machines créées à un moment donné, ainsi que la durée pendant laquelle elles sont conservées avant d’être détruites.

Nous allons utiliser trois serveurs distincts pour construire ce projet, voyons d’abord la terminologie:

* GitLab *: votre instance GitLab hébergée ou votre instance auto-hébergée où vos référentiels de code sont stockés.
* Bastion GitLab *: Le serveur bastion ou Droplet est au cœur de ce que nous allons configurer. C’est l’instance de contrôle utilisée pour interagir avec l’API DigitalOcean afin de créer des gouttelettes et de les détruire le cas échéant. Aucun travail n’est exécuté sur ce serveur.
* GitLab Runners *: Vos runners sont des serveurs transitoires ou des Droplets créés à la volée par le serveur bastion lorsque cela est nécessaire pour exécuter un travail CI / CD dans votre file d’attente de construction. Ces serveurs sont jetables et sont les endroits où votre code est exécuté ou testé avant que votre construction ne soit marquée comme réussie ou en échec.

image: https: //assets.digitalocean.com/articles/gitlab-runner/Autoscaling-GitLab-Runners.png [Diagramme des coureurs GitLab]

En tirant parti de chacun des composants GitLab, le processus CI / CD vous permettra d’évoluer en fonction des demandes. Avec ces objectifs en tête, nous sommes prêts à commencer à configurer notre déploiement continu avec GitLab et DigitalOcean.

Conditions préalables

Ce tutoriel supposera que vous avez déjà configuré GitLab sur votre propre serveur ou via le service hébergé et que vous possédez déjà un compte DigitalOcean.

Pour l’installer sur une gouttelette Ubuntu 16.04, vous pouvez utiliser l’image d’un clic de DigitalOcean ou suivre notre guide: «https://www.digitalocean.com/community/tutorials/how-to-install-and-configure- gitlab-on-ubuntu-16-04 [Comment installer et configurer GitLab sur Ubuntu 16.04]. ”

Pour les besoins de ce didacticiel, nous supposons que vous avez activé la mise en réseau privée sur cette Droplet, ce que vous pouvez obtenir en suivant notre guide sur «https://www.digitalocean.com/community/tutorials/how-to-enable-digitalocean- private-networking-on-existing-droplets [Comment activer la mise en réseau privée DigitalOcean sur des gouttelettes existantes], "mais ce n’est pas obligatoire.

Tout au long de ce didacticiel, nous utiliserons des utilisateurs non root dotés des privilèges d’administrateur sur nos droplets.

Étape 1 - Importer un projet JavaScript

Pour commencer, nous allons créer un nouvel exemple de projet dans votre instance GitLab existante contenant un exemple d’application Node.js.

image: https: //assets.digitalocean.com/articles/gitlab-runner/gitlab.jpg [Interface GitLab]

Connectez-vous à votre instance GitLab et cliquez sur l’icône * plus *, puis sélectionnez * Nouveau projet * dans le menu déroulant.

Sur l’écran du nouveau projet, sélectionnez la balise * Import project *, puis cliquez sur * Repo par URL * pour importer notre exemple de projet directement depuis GitHub.

Collez l’URL de clone ci-dessous dans l’URL du référentiel Git:

https://github.com/do-community/hello_hapi.git

Ce référentiel est une application JavaScript de base à des fins de démonstration, que nous n’utilisons pas en production. Pour terminer l’importation, cliquez sur le bouton * Nouveau projet *.

Votre nouveau projet sera maintenant dans GitLab et nous pouvons commencer à configurer notre pipeline CI.

Étape 2 - Configuration de l’infrastructure

Notre programme d’exécution de code GitLab nécessite une configuration spécifique, car nous prévoyons de créer par programme des gouttelettes pour gérer la charge des éléments de configuration au fur et à mesure de sa croissance et de sa réduction.

Nous allons créer deux types de machines dans ce didacticiel: une instance * bastion *, qui contrôle et génère de nouvelles machines, et nos instances * runner *, qui sont des serveurs temporaires créés par le bastion Droplet pour générer du code si nécessaire. L’instance Bastion utilise Docker pour créer vos coureurs.

Voici les produits DigitalOcean que nous utiliserons, et à quoi sert chaque composant:

* Droplets flexibles * - Nous créerons des droplets à mémoire optimisée pour nos serveurs GitLab Runners car il s’agit d’un processus exigeant en mémoire qui s’exécutera à l’aide de Docker pour la conteneurisation. Vous pouvez réduire ou agrandir cette Droplet à l’avenir, en fonction des besoins. Cependant, nous vous recommandons d’utiliser l’option de Droplet flexible comme point de départ pour comprendre les performances de votre pipeline sous charge.
* DigitalOcean Spaces (Object Storage) * - Nous utiliserons DigitalOcean Spaces pour conserver les composants de construction mis en cache dans vos runners au fur et à mesure de leur création et de leur destruction. Cela réduit le temps nécessaire à la configuration d’un nouveau coureur lorsque le pipeline CI est occupé et permet aux nouveaux coureurs de reprendre leurs activités là où d’autres se sont arrêtés immédiatement.
* Mise en réseau privée * - Nous allons créer un réseau privé pour les coureurs de votre bastion Droplet et GitLab afin d’assurer la compilation de code sécurisé et de réduire la configuration du pare-feu requise.

Pour commencer, nous allons créer le bastion Droplet. Créez un new Droplet, puis sous * choisissez une image *, sélectionnez l’onglet * Applications en un clic *. À partir de là, sélectionnez * Docker le 16.04 * (notez que cette version est à jour), puis choisissez la plus petite taille de gouttelette disponible, car notre bastion Droplet gérera la création d’autres gouttelettes plutôt que de réaliser des tests.

Il est recommandé de créer votre serveur dans un centre de données comprenant DigitalOcean Spaces pour pouvoir utiliser les fonctions de mise en cache de stockage d’objets. mentionné plus tôt.

Sélectionnez les options * Réseau privé * et * Surveillance *, puis cliquez sur * Créer un droplet *.

Nous devons également configurer notre espace de stockage qui sera utilisé pour la mise en cache. Suivez les étapes décrites dans «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] pour créer un nouvel espace dans le même centre de données ou le centre de données le plus proche que votre instance GitLab hébergée, avec une clé API.

Notez cette touche, car nous en aurons besoin plus tard dans le tutoriel.

Il est maintenant temps de lancer notre IC!

Étape 3 - Configurer le serveur GitLab Runner Bastion

Avec la nouvelle Droplet prête, nous pouvons maintenant configurer GitLab Runner. Nous installerons des scripts à partir des référentiels GitLab et GitHub.

Il est recommandé d’inspecter les scripts pour vérifier ce que vous allez installer avant d’exécuter les commandes complètes ci-dessous.

Connectez-vous à Droplet à l’aide de SSH, accédez au répertoire + / tmp +, puis ajoutez le référentiel https://docs.gitlab.com/runner/install/linux-repository.html&official GitLab Runner] au gestionnaire de paquets d’Ubuntu:

cd /tmp
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

Une fois ajouté, installez l’application GitLab Runner:

sudo apt-get install gitlab-runner

Nous devons également installer * https: //docs.docker.com/machine/install-machine/#install-machine-directly [Docker Machine] *, un outil supplémentaire de Docker permettant d’automatiser le déploiement de conteneurs sur le cloud. fournisseurs:

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && \
sudo install /tmp/docker-machine /usr/local/bin/docker-machine

Une fois ces installations terminées, nous pouvons passer à la connexion de notre GitLab Runner à notre installation GitLab.

Étape 4 - Obtenir le jeton d’inscription du coureur

Pour lier GitLab Runner à votre installation GitLab existante, nous devons lier les deux instances en obtenant un jeton qui authentifie votre coureur dans vos référentiels de code.

Connectez-vous à votre instance GitLab existante en tant qu’utilisateur administrateur, puis cliquez sur l’icône représentant une clé pour accéder à la zone des paramètres administrateur.

Sur la gauche de votre écran, survolez * Overview * et sélectionnez * Runners * dans la liste.

Sur la page Runners sous la section * Comment configurer un Runner partagé pour un nouveau projet *, copiez le jeton présenté à l’étape 3 et notez-le avec l’URL accessible au public de votre instance GitLab à partir de l’étape 2. Si vous utilisez HTTPS pour Gitlab, assurez-vous qu’il ne s’agit pas d’un certificat auto-signé, sinon GitLab Runner ne démarrera pas.

Étape 5 - Configurez GitLab sur le droplet Bastion

De retour dans votre connexion SSH avec votre bastion Droplet, exécutez la commande suivante:

sudo gitlab-runner register

Cela initiera le processus de liaison et une série de questions vous sera posée.

A l’étape suivante, entrez l’URL * de l’instance GitLab * de l’étape précédente:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com)

Entrez le jeton que vous avez obtenu de votre instance GitLab:

Please enter the gitlab-ci token for this runner

Entrez une description qui vous aidera à le reconnaître dans l’interface Web de GitLab. Nous vous recommandons de nommer cette instance avec un nom unique, tel que + runner-bastion + pour plus de clarté.

Please enter the gitlab-ci description for this runner

Le cas échéant, vous pouvez entrer les balises du code que vous construirez avec votre coureur. Cependant, nous recommandons de laisser ce champ vide à ce stade. Cela peut facilement être modifié ultérieurement à partir de l’interface GitLab.

Please enter the gitlab-ci tags for this runner (comma separated):

Choisissez si votre coureur doit ou non être capable d’exécuter des travaux sans étiquette. Ce paramètre vous permet de choisir si votre coureur doit créer des référentiels sans balises ou nécessiter des balises spécifiques. Sélectionnez true dans ce cas afin que votre coureur puisse exécuter tous les référentiels.

Whether to run untagged jobs [true/false]:

Choisissez si ce programme doit être partagé entre vos projets ou verrouillé sur le projet actuel, ce qui l’empêche de générer tout code autre que ceux spécifiés. Sélectionnez false pour le moment, car cela pourra être modifié ultérieurement dans l’interface de GitLab:

Whether to lock Runner to current project [true/false]:

Choisissez l’exécuteur qui construira vos machines. Comme nous allons créer de nouvelles gouttelettes à l’aide de Docker, nous choisirons + docker + machine + ici, mais vous pouvez en savoir plus sur les avantages de chaque approche dans cette https://docs.gitlab.com/runner/executors/ README.html # compatibilité-chart [tableau de compatibilité]:

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:

On vous demandera quelle image utiliser pour les projets qui n’en définissent pas explicitement une. Nous choisirons une configuration de base sécurisée par défaut:

Please enter the Docker image (e.g. ruby:2.1):

Vous avez maintenant terminé de configurer le coureur principal du bastion! À ce stade, il devrait apparaître dans la page GitLab Runner de vos paramètres d’administrateur GitLab, auxquels nous avons accédé pour obtenir le jeton.

Si vous rencontrez des problèmes avec ces étapes, la documentation GitLab Runner comprend des options de dépannage.

Étape 6 - Configurer la mise en cache Docker et la machine Docker

Pour accélérer la création de Droplet lorsque la file d’attente de construction est occupée, nous allons utiliser les outils de mise en cache de Docker sur Bastion Droplet pour stocker les images de vos conteneurs couramment utilisés sur DigitalOcean Spaces.

Pour ce faire, mettez à niveau Docker Machine sur votre shell SSH à l’aide de la commande suivante:

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && sudo install /tmp/docker-machine /usr/local/bin/docker-machine

Grâce à la mise à niveau de Docker Machine, nous pouvons maintenant configurer nos jetons d’accès pour GitLab Runner.

Étape 7 - Rassemblez les informations d’identification DigitalOcean

Nous devons maintenant créer les informations d’identification que GitLab Runner utilisera pour créer de nouvelles Droplets à l’aide de votre compte DigitalOcean.

Visitez votre site Web DigitalOcean https://cloud.digitalocean.com [tableau de bord] et cliquez sur * API *. Sur l’écran suivant, recherchez * Jetons d’accès personnel * et cliquez sur * Générer un nouveau jeton *.

Donnez au nouveau jeton un nom que vous reconnaîtrez, tel que + GitLab Runner Access + et assurez-vous que les étendues de lecture et d’écriture sont activées, car nous avons besoin de Droplet pour créer de nouvelles machines sans intervention humaine.

Copiez le jeton dans un endroit sûr, car nous l’utiliserons à l’étape suivante. Vous ne pouvez pas récupérer ce jeton sans le régénérer. Assurez-vous qu’il est stocké de manière sécurisée.

Étape 8 - Éditer les fichiers de configuration de GitLab Runner

Pour réunir tous ces composants, nous devons terminer la configuration de notre bastion Droplet afin qu’il puisse communiquer avec votre compte DigitalOcean.

Dans votre connexion SSH à votre bastion Droplet, utilisez votre éditeur de texte préféré, tel que nano, pour ouvrir le fichier de configuration GitLab Runner à des fins d’édition:

nano /etc/gitlab-runner/config.toml

Ce fichier de configuration est responsable des règles que votre configuration CI utilise pour s’adapter à la demande. Pour configurer le bastion à l’échelle automatique à la demande, vous devez ajouter les lignes suivantes:

/etc/gitlab-runner/config.toml

concurrent = 50   # All registered Runners can run up to 50 concurrent builds

[[runners]]
 url = ""
 token = ""             # Note this is different from the registration token used by `gitlab-runner register`
 name = "example-runner"
 executor = "docker+machine"        # This Runner is using the 'docker+machine' executor
 limit = 10                         # This Runner can execute up to 10 builds (created machines)
 [runners.docker]
   image = "alpine:latest"               # Our secure image
 [runners.machine]
   IdleCount = 1                    # The amount of idle machines we require for CI if build queue is empty
   IdleTime = 600                   # Each machine can be idle for up to 600 seconds, then destroyed
   MachineName = "gitlab-runner-autoscale-%s"    # Each machine will have a unique name ('%s' is required and generates a random number)
   MachineDriver = "digitalocean"   # Docker Machine is using the 'digitalocean' driver
   MachineOptions = [
       "digitalocean-image=coreos-stable", # The DigitalOcean system image to use by default
       "digitalocean-ssh-user=core", # The default SSH user
       "digitalocean-access-token=", # Access token from Step 7
       "digitalocean-region=", # The data center to spawn runners in
       "digitalocean-size=", # The size (and price category) of your spawned runners
       "digitalocean-private-networking" # Enable private networking on runners
   ]
 [runners.cache]
   Type = "s3"   # The Runner is using a distributed cache with the S3-compatible Spaces service
   ServerAddress = ".spaces.digitaloceanspaces.com"
   AccessKey = ""
   SecretKey = ""
   BucketName = ""
   Insecure = true # We do not have a SSL certificate, as we are only running locally

Une fois que vous avez ajouté les nouvelles lignes, personnalisez le jeton d’accès, la région et la taille de la gouttelette en fonction de votre configuration. Pour les besoins de ce didacticiel, nous avons utilisé la plus petite taille de gouttelettes de 1 Go et avons créé nos gouttelettes dans NYC3. Veillez à utiliser les informations pertinentes dans votre cas.

Vous devez également personnaliser le composant de cache et entrer l’adresse du serveur de votre espace à partir de l’étape de configuration de l’infrastructure, la clé d’accès, la clé secrète et le nom de l’espace que vous avez créé.

Une fois terminé, redémarrez GitLab Runner pour vous assurer que la configuration est utilisée:

gitlab-runner restart

Si vous souhaitez en savoir plus sur toutes les options disponibles, y compris les heures creuses, consultez la page GitLab.

Étape 9 - Testez votre coureur GitLab

À ce stade, notre droplet GitLab Runner Bastlet est configuré et peut créer des gouttelettes DigitalOcean à la demande, au fur et à mesure du remplissage de la file d’attente des CI. Nous devrons le tester pour nous assurer qu’il fonctionne correctement en vous dirigeant vers votre instance GitLab et le projet importé à l’étape 1.

Pour déclencher une construction, éditez le fichier + readme.md en cliquant dessus, puis en cliquant sur * edit *, ajoutez le texte de test pertinent au fichier, puis cliquez sur * Valider les modifications *.

Maintenant, une construction sera automatiquement déclenchée, ce qui peut être trouvé sous l’option * CI / CD * du projet dans la navigation de gauche.

Sur cette page, vous devriez voir une entrée de pipeline avec le statut * en cours *. Dans votre compte DigitalOcean, vous verrez un certain nombre de Droplets automatiquement créées par GitLab Runner afin de générer cette modification.

Toutes nos félicitations! Votre pipeline de CI est évolutif dans le cloud et gère désormais sa propre utilisation des ressources. Après le délai d’inactivité spécifié, les ordinateurs devraient être automatiquement détruits, mais nous vous recommandons de le vérifier manuellement pour vous assurer que votre facture ne sera pas facturée de manière inattendue.

Dépannage

Dans certains cas, GitLab peut signaler que le coureur est inaccessible et, par conséquent, ne réaliser aucune action, y compris le déploiement de nouveaux coureurs. Vous pouvez résoudre ce problème en arrêtant GitLab Runner, puis en le redémarrant en mode débogage:

gitlab-runner stop
gitlab-runner --debug start

La sortie devrait générer une erreur, ce qui sera utile pour déterminer quelle configuration est à l’origine du problème.

Si votre configuration crée trop de machines et que vous souhaitez toutes les supprimer en même temps, vous pouvez exécuter cette commande pour toutes les détruire:

docker-machine rm $(docker-machine ls -q)

Pour plus d’étapes de dépannage et d’options de configuration supplémentaires, vous pouvez vous reporter à la documentation GitLab.

Conclusion

Vous avez configuré avec succès un pipeline de CI / CD automatisé avec GitLab Runner et Docker. À partir de là, vous pouvez configurer des niveaux plus élevés de mise en cache avec Docker Registry pour optimiser les performances ou explorer l’utilisation de générations de code de marquage pour des coureurs de code GitLab spécifiques.

Pour en savoir plus sur GitLab Runner, voir la documentation détaillée, ou pour en savoir plus, vous pouvez lire les GitLab des articles de blog sur la façon de tirer le meilleur parti de votre pipeline d’intégration continue.

Ce article apparaît également sur GitLab Blog .

TOC