Docker ++ : Gitlab CI

Gitlab CI

Dans cet exercice, nous allons étudier l'utilisation de docker dans le cadre de l'intégration continue de Gitlab. Le principe de l'intégration continue est d'exécuter une série d'opérations (compilation, tests, documentation, publication) lorsqu'un commit Git est poussé sur Gitlab. Pour cela on va utiliser l'instance Gitlab de l'UTC.

La CI fonctionne grâce à deux aspects :

  • Un fichier .gitlab-ci.yml qui décrit la série d'opérations (aussi appelée pipeline) et comment la lancer

  • Un runner, c'est-à-dire un container sur lequel tournera la suite d'opération

Description de la CI

La structure d'un fichier .gitlab-ci.yml est en YAML et ressemble à

1
image: debian
2
3
build-job:
4
  stage: build
5
  tags: [docker]
6
  script:
7
    - echo "Hello, $GITLAB_USER_LOGIN!"
8
9
test-job1:
10
  stage: test
11
  tags: [docker]
12
  script:
13
    - echo "This job tests something"
14
15
test-job2:
16
  stage: test
17
  tags: [docker]
18
  script:
19
    - echo "This job tests something, but takes more time than test-job1."
20
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
21
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
22
    - sleep 20
23
24
deploy-prod:
25
  stage: deploy
26
  tags: [docker]
27
  script:
28
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
Pour aller plus loin sur ce fichier, on peut se référer à la documentation en ligne, et s'inspirer de ce qui est fait à Picasoft.
Il est possible d'exporter des fichiers à chaque étape de la pipeline dans ce qu'on appelle des artifacts. Pour cela, il suffit d'énumérer les fichiers/dossiers à exporter dans un champ artifacts de la forme
1
projet:
2
  stage: build
3
  tags:
4
    - docker
5
    - latex
6
  script:
7
    - cd projet && latexmk -shell-escape -pdf
8
  artifacts:
9
    paths:
10
      - projet/projet.pdf
11
    expire_in: 1 hour
Il existe finalement un espace spécial sur Gitlab nommé Gitlab Pages. Il s'agit d'un espace associé à chaque repository capable de servir des pages statiques (html, pdf, etc), qui est concrètement un mini-serveur statique hébergé sur les serveurs de Gitlab (ou de l'UTC dans notre cas). Il est possible d'y mettre des fichiers à l'aide de la CI avec quatre conditions :
  • Avoir un job nommé pages dans le fichier .gitlab-ci.yml
  • Qu'il soit à l'étape de déploiement
  • Qu'il mette lesdits fichiers dans un dossier public
  • Qu'il exporte ce dossier public
Si ces conditions sont réunies, un site de la forme <username>.gitlab.utc.fr/<projet> sera créé. La première fois qu'un Gitlab Page est crée, cela peut prendre jusqu'à 30 minutes.
1
pages:
2
  stage: deploy
3
  tags:
4
    - linux
5
  script:
6
    - mkdir -p public
7
    - cp projet/projet.pdf public/
8
  artifacts:
9
    paths:
10
      - public
11
    expire_in: 1 year
Utilisation de Runners
Un runner est un programme qui met à disposition la puissance de calcul d'une machine réelle (un VPS, votre machine personnelle, n'importe quel ordinateur) à Gitlab. Installer un runner sur une machine Linux revient simplement à exécuter la bonne image docker en suivant ce tuto. Il existe d'autres façons de faire mais celle ci est de loin la plus simple.
Pour éviter que tout le monde ai à déployer son propre VPS, l'UTC propose un Shared Runner, un runner accessible à n'importe qui à l'UTC mais qui peut être un peu lent car partagé entre tous les utilisateurs.
On peut également spécifier son propre runner, en théorie bien plus rapide et disponible juste à côté. Pour cela, on peut suivre le tuto et récupérer le token spécifique au projet dans la configuration du repository.
Jobs
Lorsqu'un commit est poussé sur Gitlab et que le repository contient un .gitlab-ci.yml, un pipeline va automatique se lancer. On peut retrouver les pipelines courants et passés dans le menu CI/CD.
Question
Créer un repository sur gitlab.utc.fr dans lequel vous ajouterez un fichier .gitlab-ci.yml qui reprend l'exemple précédent. Ajouter dans les paramètres du repository le shared runner afin que la CI puisse se dérouler dessus.
Question
Déployer un runner sur votre VPS, le sélectionner dans les paramètres du repository et vérifier que la CI se déroule bien dessus.
Question
Utilisez les Gitlab Pages pour mettre en ligne une page html ou un pdf de votre choix.
Question
Il est de bonne pratique de ne pas mettre en clair ses identifiants et mots de passe dans les scripts. Pour cela Gitlab propose un système de variables. En vous aidant de la documentation, remplacer dans le fichier .gitlab-ci.yml précédent les identifiants, hôte et mot de passes par des variables que vous aurez préalablement créé dans les paramètres du repository.