Commit 654fc5b8 authored by Matthieu Boileau's avatar Matthieu Boileau
Browse files

Merge branch 'pages' into 'master'

Pages

See merge request m.boileau/tp-gitlab-ci!4
parents 9080761f 2480e914
%% Cell type:markdown id: tags:
### Journée X/Stra-Dev Intégration continue
21 novembre 2017
---
# L'intégration continue avec GitLab
![image.png](tanuki.png)
## *Session pratique*
- [Notebook](http://nbviewer.jupyter.org/urls/boileau.pages.math.unistra.fr/tp-gitlab-ci/tp-gitlab-ci.ipynb)
- [Slideshow](https://boileau.pages.math.unistra.fr/tp-gitlab-ci/tp-gitlab-ci.slides.html)
- [Sources](https://git.unistra.fr/m.boileau/tp-gitlab-ci)
---
Matthieu Boileau - <matthieu.boileau@math.unistra.fr>
*Contenu sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0)*
......
%% Cell type:markdown id: tags:
### Journée X/Stra-Dev Intégration continue
21 novembre 2017
---
# L'intégration continue avec GitLab
![image.png](tanuki.png)
## *Session pratique*
---
Matthieu Boileau - <matthieu.boileau@math.unistra.fr>
*Contenu sous licence [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0)*
%% Cell type:markdown id: tags:
# GitLab CI
GitLab CI propose une chaîne complète d'intégration continue intégrée à son système de forge logicielle.
![](cicd_pipeline_infograph.png)
<span style="font-size:0.7em;"><https://docs.gitlab.com/ee/ci/README.html></span>
**Les avantages :**
- la simplicité de mise en oeuvre
- la robustesse d'une solution intégrée
%% Cell type:markdown id: tags:
## Le gitlab runner
### Introduction
- `gitlab-runner` est un démon installé sur une machine destinée à exécuter les tâches d'intégration continue.
- Pour chaque *runner* enregistré, `gitlab-runner` écoute l'instance de gitlab correspondante dans l'attente d'une tâche
- Cette tâche est déclenchée par des évènements (`push`, `merge`, etc.) sur le projet avec lequel il est lié
- Ce lien est créé à l'enregistrement du *runner* par un token associé au projet.
[**Doc en ligne**](https://docs.gitlab.com/ce/ci/runners/#shared-vs-specific-runners)
%% Cell type:markdown id: tags:
### Runners : *shared* vs *specific*
- *shared* : n'importe quel projet peut s'en servir. Seul l'administrateur du GitLab peut enregistrer des runners partagés.
- *specific* : seul le créateur du runner peut s'en servir dans d'autres projets
> **Attention** : les runners partagés sont pratiques mais peuvent présenter des [problèmes de sécurité](https://docs.gitlab.com/ee/ci/runners/README.html#be-careful-with-sensitive-information).
### Runners : *locked* vs *unlocked runners*
- *locked* : le runner ne peut être utilisé que pour le projet avec lequel il est lié
- *unlocked* : le créateur du runner peut l'utiliser dans ses autres projets
%% Cell type:markdown id: tags:
### Installer `gitlab-runner`
La **[procédure](https://docs.gitlab.com/runner/install/)** dépend du système d'exploitation.
%% Cell type:markdown id: tags:
## Fork du TP
Faire un *fork* du projet sur votre compte GitLab en allant sur la page d'accueil du projet
![fork.png](fork.png)
ou en suivant [ce lien](https://git.unistra.fr/m.boileau/tp-gitlab-ci/forks/new).
%% Cell type:markdown id: tags:
## Clone du TP
%% Cell type:markdown id: tags:
- Pour paramétrer les commandes de ce notebook, positionner les variables d'environnement suivantes :
%% Cell type:code id: tags:
``` bash
export USERNAME="m.boileau" # votre login sur git.unistra.fr
export TPBASEDIR=$HOME # le répertoire où vous souhaitez installer le TP
export TPDIR=$TPBASEDIR/tp-gitlab-ci
```
%% Cell type:markdown id: tags:
- Cloner localement votre projet
%% Cell type:code id: tags:
``` bash
cd $TPBASEDIR
git clone git@git.unistra.fr:$USERNAME/tp-gitlab-ci.git
```
%% Cell type:markdown id: tags:
## Enregistrer un nouveau runner
> Si `gitlab-runner` n'est pas installé sur votre machine, rdv à la section **Exo1**
Engistrer un runner consiste à créer un nouveau runner associé à un projet.
Si vous n'êtes pas administrateur du GitLab, il s'agit forcément d'un runner spécifique. Celui-ci se trouve dans
votre projet, rubrique :
```
Settings > CI / CD > Runners settings
```
%% Cell type:markdown id: tags:
Dans le terminal, maintenant :
%% Cell type:code id: tags:
``` bash
export CI_SERVER_URL=https://git.unistra.fr/ # Do not change for this session
export RUNNER_NAME=a_runner_for_$USERNAME
export REGISTRATION_TOKEN=xxx # Replace by the value provided by the runner setting page
export REGISTER_NON_INTERACTIVE=true
#gitlab-runner register --executor shell # sous MacOS
#sudo gitlab-runner register --executor shell # sous Linux
```
%% Cell type:markdown id: tags:
Ou bien lancez la commande en mode interactif et en suivant pas à pas la [procédure](http://docs.gitlab.com/runner/register/#registering-runners):
```
gitlab-runner register # sous MacOS
sudo gitlab-runner register # sous Linux
```
%% Cell type:markdown id: tags:
- Retournez sur la page de paramètrage des runners
- Repérez votre nouveau runner
- Editez-le et ajouter les tags `specific, shell`
Votre runner est maintenant prêt à travailler. Nous allons le tester en lui soumettant une tâche GitLab CI déclenchée par un `git push` sur votre projet.
%% Cell type:markdown id: tags:
## Exo1 : helloworld en bash
### Mettre en place une action d'intégration continue
Allez dans le répertoire racine du clone local de votre projet et basculez sur la branche `exo1`
%% Cell type:code id: tags:
``` bash
cd $TPDIR
```
%% Cell type:code id: tags:
``` bash
git pull
git stash
git checkout exo1
git checkout exo1-start .gitlab-ci.yml # Clean previous modifications
```
%% Cell type:markdown id: tags:
Repérer le fichier `.gitlab-ci.yml`
%% Cell type:code id: tags:
``` bash
ls -al
```
%% Cell type:markdown id: tags:
L'éditer avec l'éditeur de votre choix
%% Cell type:code id: tags:
``` bash
cat .gitlab-ci.yml
```
%% Cell type:markdown id: tags:
- `helloworld` indique le nom du job d'intégration continue
- `tags` permet de sélectionner des runners sur la base de mot-clés
- `scripts` correspond aux lignes de commande `bash` que vous souhaitez exécuter
%% Cell type:markdown id: tags:
### Si vous souhaitez utiliser un runner partagé
Dans la rubrique :
```
Settings > CI / CD > Runners settings
```
Notez la présence de plusieurs runners partagés dont `clu1-tp-gitlab-ci` qui porte les tags `shell` et `docker` mais pas `specific`. Pour cibler ce runner, retirer le tag `specific` du fichier `.gitlab-ci.yml`
Notez la présence de plusieurs runners partagés dont `clu1-tp-gitlab-ci` qui portent les tags `shell` et `docker` mais pas `specific`. Pour cibler ce runner, retirer le tag `specific` du fichier `.gitlab-ci.yml`
%% Cell type:markdown id: tags:
### Déclenchez une action d'intégration continue
Modifiez la ligne de script, par exemple:
%% Cell type:code id: tags:
``` bash
echo ' - echo "bonjour, monde"' >> .gitlab-ci.yml
cat .gitlab-ci.yml
```
%% Cell type:markdown id: tags:
Enregistrez avec git
%% Cell type:code id: tags:
``` bash
git add .gitlab-ci.yml
git commit -m "Update .gitlab-ci.yml"
```
%% Cell type:markdown id: tags:
Poussez vos modifications
%% Cell type:code id: tags:
``` bash
git push
```
%% Cell type:markdown id: tags:
Sur GitLab, observez l'exécution de votre job dans la rubrique de votre projet :
```
CI / CD > Pipelines
```
%% Cell type:markdown id: tags:
### Provoquez une erreur
Dans `.gitlab-ci.yml`, introduisez une erreur dans une des lignes du script et observer l'effet dans `CI / CD > Pipelines` après avoir poussé les modifications.
> **Note :** les fichiers peuvent s'éditer directement dans GitLab.
%% Cell type:markdown id: tags:
## Exo2 : helloworld en C
### Description
On écrit le programme `helloworld` en C qui doit afficher `hello, world`.
### Mettre en place une action de *build*
Dans votre clone local, basculez sur la branche `exo2`
%% Cell type:code id: tags:
``` bash
cd $TPDIR
git stash # si vous avez des modifications non enregistrées dans exo1
git checkout exo2
git rm .gitlab-ci.yml # Clean previous commits
```
%% Cell type:markdown id: tags:
Listez le contenu du répertoire
%% Cell type:code id: tags:
``` bash
ls -al
```
%% Cell type:markdown id: tags:
Vérifiez que le progamme compile
%% Cell type:code id: tags:
``` bash
make
```
%% Cell type:markdown id: tags:
On crée le fichier `.gitlab-ci.yml` avec une étape (`stage`) de `build`. Il doit contenir :
```yaml
build_hello:
stage: build
tags:
- shell
script:
- make
```
%% Cell type:code id: tags:
``` bash
cat > .gitlab-ci.yml <<- EOM
build_hello:
stage: build
tags:
- shell
script:
- make
EOM
```
%% Cell type:markdown id: tags:
On vérifie le contenu
%% Cell type:code id: tags:
``` bash
cat .gitlab-ci.yml
```
%% Cell type:markdown id: tags:
On enregistre et on pousse.
%% Cell type:code id: tags:
``` bash
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml with a build stage"
```
%% Cell type:code id: tags:
``` bash
git push
```
%% Cell type:markdown id: tags:
Sur GitLab, observez l'exécution de votre job dans la rubrique de votre projet :
```
CI / CD > Pipelines
```
%% Cell type:markdown id: tags:
### Ajouter une action de *test*
On souhaite ajouter une étape de test réalisée avec `make test`. Tester l'exécution du test (il ne doit pas renvoyer d'erreur) :
%% Cell type:code id: tags:
``` bash
make test
```
%% Cell type:markdown id: tags:
Il faut ajouter le contenu suivant :
```yaml
test_hello:
stage: test
tags:
- shell
script:
- make test
```
%% Cell type:code id: tags:
``` bash
cat >> .gitlab-ci.yml <<- EOM
test_hello:
stage: test
tags:
- shell
script:
- make test
EOM
```
%% Cell type:code id: tags:
``` bash
cat .gitlab-ci.yml
```
%% Cell type:markdown id: tags:
On enregistre, on pousse et on vérifie l'exécution de la chaîne d'intégration continue dans `CI / CD > Pipelines`
%% Cell type:code id: tags:
``` bash
git add .gitlab-ci.yml
git commit -m "Add a test stage to .gitlab-ci.yml"
```
%% Cell type:code id: tags:
``` bash
git push
```
%% Cell type:markdown id: tags:
### Provoquez des erreurs
Modifier les fichiers pour provoquer des erreurs.
Notez que le test n'est pas exécuté si le build échoue.
%% Cell type:markdown id: tags:
## Exo3 : Docker pour gérer les dépendances
À `helloworld`, on ajoute un programme en python `rosenbrock.py` qui calcule la [fonction de Rosenbrock](https://fr.wikipedia.org/wiki/Fonction_de_Rosenbrock). Ce programme nécessite [`pythran`](http://pythran.readthedocs.io/), un traducteur de python vers C++ qui permet d'accélérer le code python.
Cet exercice a pour but d'illustrer la gestion des dépendances de compilation avec les conteneurs Docker dans une chaîne GitLab CI.
Pour le reproduire, il est nécessaire de :
1. créer un compte sur [DockerHub](https://hub.docker.com/)
2. y créer un dépôt vierge intitulé `rosen`
3. que Docker soit installé sur la machine qui héberge le runner (c'est le cas pour le runner partagé de ce TP).
%% Cell type:markdown id: tags:
Dans votre clone local, basculez sur `exo3`
%% Cell type:code id: tags:
``` bash
cd $TPDIR
git stash # si vous avez des modifications non enregistrées dans exo2
git checkout exo3
```
%% Output
No local changes to save
Already on 'exo3'
Your branch is up-to-date with 'origin/exo3'.
%% Cell type:markdown id: tags:
### Entête et étape préliminaire du fichier `.gitlab-ci.yml`
```yaml
stages:
- build
- test
- release
variables:
CONTAINER_TEST_IMAGE: boileaum/rosen:$CI_COMMIT_REF_NAME
CONTAINER_RELEASE_IMAGE: boileaum/rosen:latest
before_script:
- echo $DOCKERHUB_PASSWD | docker login -u boileaum --password-stdin
[...]
```
Pour faire marcher l'exercice :
1. Remplacez `boileaum` par votre `username` sur DockerHub.
2. Sur GitLab dans `Settings > CI / CD > Secret variables`, créez une variable `DOCKERHUB_PASSWD` qui contient le mot de passe de votre compte DockerHub.
%% Cell type:markdown id: tags:
### Etape de `build` :
```yaml
[...]
b:docker:
stage: build
tags:
- shell, docker
script:
- docker build --pull -t $CONTAINER_TEST_IMAGE -f ./docker/Dockerfile-rosen .
- docker push $CONTAINER_TEST_IMAGE
[...]
```
- on construit l'image de test à partir du fichier `./docker/Dockerfile-rosen`
- on pousse cette image sur DockerHub
> **Note :** l'image `Dockerfile-rosen` est basée sur l'image construite avec `./docker/Dockerfile-pythran` et qui contient les dépendances.
%% Cell type:markdown id: tags:
### Etapes de `test`
```yaml
[...]
t:helloworld:
stage: test
tags:
- shell, docker
script:
- docker pull $CONTAINER_TEST_IMAGE
- docker run $CONTAINER_TEST_IMAGE /bin/bash -c 'python test_helloworld.py'
[...]
```
- on tire l'image de test
- on lance les tests unitaires
%% Cell type:markdown id: tags:
### Etape de livraison
```yaml
[...]
r:docker:
stage: release
tags:
- shell, docker
script:
- docker pull $CONTAINER_TEST_IMAGE
- docker tag $CONTAINER_TEST_IMAGE $CONTAINER_RELEASE_IMAGE
- docker push $CONTAINER_RELEASE_IMAGE
only:
- exo3
[...]
```
On ne fait que tirer l'image de test validée, la renommer, la pousser vers DockerHub.
%% Cell type:markdown id: tags:
### Pipeline complet
![](pipeline.png)
Comme le montre ce schéma, l'exécution de différents jobs d'une même étape peut être réalisée en parallèle par différents runners.
Plus d'information
Plus d'information sur la [doc en ligne](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html).
%% Cell type:markdown id: tags:
## Récupérer un artifact
# Conclusion
%% Cell type:code id: tags:
### Ce qu'on a vu
- comment configurer un runner `shell`
- comment cibler différents runners
- comment mettre en place une chaîne d'intégration continue
- comment tirer/construire/pousser des images Docker
``` bash
```
### Ce qu'on n'a pas vu
- comment utiliser les autres types de runners (en particulier `docker`)
- comment récupérer des artefacts d'intégration
- les problèmes de [sécurité](http://docs.gitlab.com/runner/executors/shell.html#security)
- GitLab Pages
- bien plus !
Mais beaucoup de réponses sont dans la [doc en ligne](https://docs.gitlab.com/ee/ci/README.html) qui est très complète !
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment