Aller au contenu principal

GitLab CI

GitLab embarque son propre service d'intégration continue et de déploiement continu, sous l'appellation GitLab Continuous Integration (CI) & Continuous Delivery (CD). L'outil proposé est complètement intégré à l'environnement GitLab, il est similaire aux solutions de type Jenkins ou Travis.

Informations​

Comme d'habitude avec GitLab, la documentation officielle est claire, illustrée et toujours à jour :

Contexte Forge INRAE​

La partie CI/CD de GitLab fonctionne avec des runners, c'est à dire une ou plusieurs machines qui exécutent les instructions que vous souhaitez dans le cadre de l'intégration / déploiement continu.

Vous pouvez utiliser vos propres runners, dans votre environnement de production.

L'ajout de Specific Runners est très simple (voir la documentation).

Shared Runners​

Afin de simplifier l'utilisation de GitLab CI/CD pour tous, l'équipe d'administration de Forge INRAE met à disposition des Shared Runners. Ces runners sont partagés, utilisables par tous, pour l'ensemble des projets de Forge INRAE.

Si aucun Specific Runners n'est configuré au niveau de votre projet / groupe, vous utiliserez par défaut les Shared Runners disponibles.

Condition d'utilisation des Shared Runners​

Il est demandé à l'ensemble des utilisateurs de surveiller le temps d'exécution des jobs, afin de ne pas monopoliser les ressources disponibles : les Shared Runners sont partagés (temps CPU, utilisation disque, RAM…), il est donc nécessaire d'être vigilant pour que chacun puisse les utiliser dans de bonnes conditions.

Fonctionnement​

Afin d'être le plus flexible possible, et pour pouvoir s'adapter à de multiples contexte, nous avons choisi Docker comme executor des Shared Runners. C'est également le cas pour les runners disponibles dans l'offre gitlab.com, de nombreuses documentations et explications sont donc disponibles pour la configuration, le choix et l'utilisation des images…

Réseau​

Les Shared Runners sont dans une zone de sécurité privée, sans filtrage en sortie. Si vous souhaitez connaître leurs IPs, vous pouvez nous contacter par mail. Cependant, pour des raisons de sécurité, il n'est pas recommandé d'utiliser nos runners partagés pour déployer sur d'autres infrastructures. Préférez installer votre propre runner directement sur votre infrastructure.

Exemple​

Voici un exemple très simple de mise en place et d'utilisation de GitLab CI/CD via les Shared Runners disponibles : https://forgemia.inra.fr/adminforgemia/demo-ci

Cas d'utilisation​

Pour notre exemple, nous prenons un cas d'utilisation simple : nous voulons pousser des fichiers vers un serveur web. Dans notre dépôt Git : nous avons un répertoire PUSH-data qui contient l'ensemble des fichiers (PHP, HTML…) et répertoires à transférer vers notre serveur web. Nous utiliserons Alpine Linux, SSH (authentification par paire de clefs) et rsync pour le transfert des données.

Authentification SSH​

Conseil

Générer une nouvelle paire de clefs qui va être utilisée spécifiquement pour les jobs d'intégration et de déploiement.

Settings > CI/CD > Variables > Expand

ssh

Nous avons créé une variable SSH_PRV_KEY avec le statut Protected. Elle contient la clef privée et sera utilisable dans le script d'intégration continue.

Activer CI/CD​

Il suffit d'ajouter le fichier de configuration .gitlab-ci.yml à la racine du dépôt pour activer l'intégration continue dans la projet. Via l'interface web, au niveau de la page d'accueil du projet, on peut utiliser le bouton Set up CI/CD qui va créer le fichier .gitlab-ci.yml et permettre l'édition en ligne.

Pour notre exemple :

image: alpine
variables:
  USER: "login"
  HOST: "exemple.inra.fr"
  DIR: "PUSH-data"
push:
  before_script:
    - apk add --no-cache openssh-client rsync
    - mkdir -p ~/.ssh
    - touch ~/.ssh/id_rsa
    - echo "$SSH_PRV_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - eval $(ssh-agent -s)
    - ssh-add
  script:
    - rsync -avz $DIR $USER@$HOST:/var/www/html

Source

Exécution et suivi des jobs​

Par défaut les jobs d'intégration continue sont automatiquement exécutés à chaque git push. Les exécutions et retours terminal sont visibles dans la partie CI/CD de votre projet de la barre latérale gauche.