@@ -905,21 +905,31 @@ On distingue deux stratégies de déploiement pour mettre en place un mécanisme
Afin de mettre en place ce mécanisme, j’ai choisi d’utiliser les outils suivants :
- **Gitlab** comme dépôt pour les fichiers de déploiement des applications et, lorsqu’il s’agit d’un développement interne, leur code source
- **Gitlab-CI** est le moteur d'exécution des mécanismes d'intégration continue, livraison continue et déploiement continu (CI/CD) de Gitlab
- **Gitlab-CI** est le moteur d'exécution des tâches d'intégration continue, livraison continue et déploiement continu (CI/CD) de Gitlab
- **Gitlab-Runner** est l'outil qui permet l'exécution des taches de CI/CD sur les machines distantes
> **Note** : Gitlab intègre un registre d'images Docker qui pourra être utilisé comme registry externe pour le Swarm. Le registre a été activé sur la Forge UCLouvain et sur le GItlab de SISG.
La mise en place du mécanisme est relativement simple et est détaillée dans [la documentation de Gitlab](https://docs.gitlab.com/ee/ci/).
Le mécanisme contient deux parties :
- Un service gitlab-runner doit être déployé sur la machine qui exécutera les tâches de déploiement
- Ce service doit être configuré dans les runners disponibles sur Gitlab. Cela peut se faire à 3 niveaux : global (pour l'ensemble des projets héberger sur l'instance Gitlab), sur un groupe ou sur un projet spécifique.
- Ce service doit être configuré dans les runners disponibles sur Gitlab. Un runner peut être soit `shared` pour l'ensemble des projets héberger sur l'instance Gitlab, soit dédié à un groupe de projets ou à un projet spécifique.
L'enregistrement d'un runner se fait via l'interface de Gitlab, chaque runner se voit associé un token qui l'identifie et un autre qui permet au service gitlab-runner de s'enregistré auprès de gitlab.
Les opérations à exécuter sont définie dans une pipeline. Les différents tâches (jobs) seront exécutées par le runner. Les jobs d'une pipeline peuvent traités en parrallèles et exécutés par des runners différents (par exemple un runner chargé de construire l'application, un autre chargé de son déploiement). Les pipelines sont définis dans un fichier YAML nommé `.gitlab-ci.yml`.
L'exécution d'une pipeline peut être déclencher par différents événements :
Dans le cadre d'une infrastructure Docker, l'idéal est de déployer les services gitlab-runner sous la forme de conteneurs Docker.
- Opération push sur un dépôt qui peut-être systématique ou avec des conditions (filtrage par branche, push sur un tag...)
- A la main via un click dans l'interface de gitlab
- De manière planifiée via un scheduler intégré à gitlab
- Via l'API de gitlab
Voici un exemple d'un tel fichier :
La mise en place du mécanisme est relativement simple et est détaillée dans [la documentation de Gitlab](https://docs.gitlab.com/ee/ci/). Toutefois, le nombre d'options disponibles pour les pipelines est assez gigantesques et la consultation d'exemples peut s'avérer rapidement nécessaire.
Dans le cadre d'une infrastructure Docker, l'idéal est de déployer les services gitlab-runner sous la forme de conteneurs Docker afin de lui donner facilement accès aux opérations sur les services déployés dans le Swarm.
Voici un exemple de fichier de déploiement de Gitlab Runner :
```yaml
version: '3.9'
...
...
@@ -962,7 +972,7 @@ services:
> **Note** :
>
> - le runner doit s'exécuter avec un utilisateur qui a des droits suffisants pour accéder aux fichiers du répertoire de travail pour le déploiement (ici respectivement gitlab-runner et /home/gitlab-runner).
> - le runner utilise une image "docker in docker" (`docker:dind`) afin de pouvoir exécuter des commandes docker depuis le conteneur lui-même
> - le runner utilise une image "docker in docker" `docker:dind` afin de pouvoir exécuter des commandes docker depuis le conteneur lui-même
Et le fichier d'environnement correspondant qui définit les paramètres nécessaires à l'exécution du runner.
...
...
@@ -982,6 +992,8 @@ RUNNER_TAG_LIST=deploy
```
Les commandes qui seront exécutées par le runner sont définies dans un fichier `.gitlab-ci.yml` situé à la racine du projet concerné. Il suffit alors de déclarer un pipeline dans le projet Gitlab et de configurer ses conditions d'exécution, sa fréquence d'exécution et des variables additionelles. Si ce n'est pas fait, le runner devra être exécuté à la main via "Run pipeline".
> **Note** : Des exemples plus complet peuvent être trouvés en ligne, par exemple sur https://gitlab.actilis.net/formation/gitlab/deploy-runner
Chaque Pipeline se caractérise par des "étages" (stages) qui seront exécutés dans l'odre de leur déclaration. Par exemple :
```yaml
...
...
@@ -1007,6 +1019,8 @@ deploy-on-swarm
Il y a également des directives prédéfinies comme `before_script` ou `after_script` qui seront exécutées respectivement avant et après chaque exécution d'une commande `script`. Chaque job peut lui-mème déclarer ses propres directives `before_script` ou `after_script`.
Gitlab CI constitue donc un outil extrèmement flexible et complet pour mettre en place la livraison continue avec Docker Swarm. Les pipelines et le runner sont relativement simple à mettre en place et à configurer.