par Benjamin Lallement, conseiller DevOps et membre du collectif Gologic
Objectifs de cette série
Cette série d’articles a pour but d’explorer les différents outils pour effectuer des déploiements en pipeline as code.
L’objectif de chaque article reste le même : récupérer le code source depuis GIT, compiler un projet JAVA/Spring-Boot avec Maven, lancer les tests puis déployer l’application sur AWS BeanStalk.
Ces étapes seront écrites sous forme de code dans un pipeline et exécutées avec l’outil CI/CD.
Chaque article sera divisé en plusieurs parties :
- Installation et démarrage d’un outil CI/CD
- Configuration de l’outil CI/CD (si nécessaire)
- Développement du pipeline de déploiement continu
- Vérification du déploiement
- Conclusion simple
Si vous voulez exécuter un pipeline, vous aurez besoin de :
- Runtime Docker pour exécuter les étapes du pipeline.
- Un environnement AWS BeanStalk avec clé d’accès et secret pour déployer l’application.
Avant de commencer, définissons deux concepts clés : déploiement continu et pipeline as code.
Que signifie “déploiement continu”?
Le déploiement continu est étroitement lié à l’intégration continue et fait référence à la mise en production d’un logiciel qui réussit les tests automatisés.
“Essentially, it is the practice of releasing every good build to users”, explique Jez Humble, auteur du livre Continuous Delivery.
En adoptant à la fois l’intégration continue et le déploiement continu, vous réduisez non seulement les risques et les erreurs rapidement, mais vous améliorer régulièrement les applications pour arriver à une meilleure solution.
Avec des livraisons plus rapides et régulières, vous pouvez rapidement vous adapter aux besoins de l’entreprise et aux besoins des utilisateurs. Cela permet une plus grande collaboration entre les opérations et la livraison, ce qui transforme votre processus de livraison en un avantage commercial.
Que signifie “pipeline as code”?
Les équipes font pression pour automatiser leurs environnements (tests), y compris l’infrastructure.
Le “pipeline as code” permet de définir les étapes de déploiement via du code au lieu de configurer ces étapes manuellement.
Code source
La référence de la démo est disponible dans GitHub : Continuous Deployment Demo
GitLab
Objectif
Pour ce troisième article, GitLab est notre prochaine cible. Vous trouverez le premier et le deuxième en cliquant ici : #1-Jenkins, #2-Concourse.
GitLab est une suite d’outils pour gérer tout le développement d’une application. Il intègre tout le cycle DevOps de développement et livraison d’une application. Cette suite est vraiment impressionnante par sa couverture, la qualité de ses outils et l’intégration complète de chaque fonctionnalité.
Dans cet article, nous présentons la partie Pipeline. La fonction Pipeline de GitLab fonctionne sous forme de descripteur au format YAML, la configuration est stockée dans le projet.
Le pipeline est déclenché lors d’un changement du code source sur une branche, que ce soit un changement au niveau du contenu du code source ou le pipeline lui-même. Étant donné que tout est intégré à même le projet et ses branches, le “checkout” du code source est implicite lors de l’exécution du pipeline.
Un pipeline est composé de stages et de tâches : les stages sont les phases du pipeline comme “Build” ou “Deploy”, les tâches sont associées à des stages et sont exécutées parallèlement pour chaque stage.
Les tâches sont principalement des exécutions de scripts et invoquent des Dockers pour exécuter les opérations. Plusieurs éléments sont disponibles dans des tâches pour être réalisés. La documentation est disponible à cet emplacement.
Installer et exécuter GitLab CE avec Docker
Démarrer GitLab avec Docker en suivant les instructions officielles : https://docs.gitlab.com/omnibus/docker/README.html
Vérifier que GitLab est disponible à l’adresse : http://localhost
Puis se connecter en changeant le mot de passe et s’identifier avec le compte root selon les instructions suivantes :
Création d’un projet
Le prérequis pour utiliser le pipeline de GitLab est de créer un projet. En suivant les instructions de la page d’accueil de GitLab, il est très facile de créer un projet comme le montre l’aperçu ci-dessous.
Lorsque votre projet est créé, il faut y ajouter le code source en suivant les instructions GIT sur la page du projet.
Installation d’un GitLab Runner
Un GitLab Runner permet d’exécuter des tâches d’un pipeline. Il est requis d’avoir au moins un Runner en plus de l’installation de GitLab. Un runner est facilement exécutable comme l’indique la documentation d’installation et d’enregistrement.
Dès lors que le Runner est disponible, il est possible d’exécuter le pipeline d’une application!
Pipeline as code : let’s get started
GitLab utilise des pipelines sous forme déclarative à l’inverse des pipelines de type scripting (voir Jenkinsfile). Ce format requiert une bonne courbe d’apprentissage. La documentation de GitLab est très bien faite et aide beaucoup pour débuter.
Dans les sources du projet, ouvrez le script .gitlab.yml et étudiez le contenu :
# Base docker image to run pipeline
image: docker:latest
services:
- docker:dind
# path to cache Maven dependencies
cache:
paths:
- .m2/
# Stages in pipeline
stages:
- build
- deploy
# Build maven step
maven-build:
# Use maven docker image
image: maven
# Join to build stage
stage: build
# Command to execute in docker image
script: "mvn package -Dmaven.repo.local=.m2"
artifacts:
paths:
- target/*.jar
# Deploy AWS step
aws-deploy:
# Use aws docker with eb-cli
image: chriscamicas/awscli-awsebcli
# Join to deploy stage
stage: deploy
# Commands to execute to deploy application to AWS
script:
- echo "$AWS_ACCESS_KEY_ID"
- eb init continuous-deployment-demo -p "64bit Amazon Linux 2017.09 v2.6.4 running Java 8" --region "ca-central-1"
- eb create gitlab-env --single || true
- eb setenv SERVER_PORT=5000
- eb deploy gitlab-env
- eb status
Dès l’ajout du fichier .gitlab.yml dans le projet, la vue pipeline devient disponible via le menu ou en ajoutant /pipelines à la suite de l’adresse du projet.
Liste des exécutions du pipeline
Détails d’une exécution du pipeline
Le pipeline (.gitlab.yml) est défini. À chaque changement de code les étapes et les stages sont déclenchés pour compiler, stocker dans le dossier de travail du pipeline puis déployer sur AWS.
Grâce à son intégration, les changements au code source sont visibles dans la vue détaillée du pipeline et, inversement, les exécutions du pipeline sont visibles dans la vue des changement du code source. Cette intégration facilite la navigation et la validation du statut de la branche.
Conclusion
GitLab offre une suite complète pour gérer le cycle DevOps d’une application.
GitLab offre une intégration complète et intuitive pour l’ensemble de ses fonctionnalités.
L’exécution de pipeline des merge-request est déclenchée automatiquement.
GitLab n’offre pas de CLI pour tester l’exécution des pipelines, il est requis de faire le “commit” du pipeline pour le voir fonctionner, ce qui peut engendrer beaucoup d’essais/erreurs.
La syntaxe YAML du pipeline sous forme déclarative demande un bon temps d’apprentissage avant d’être maîtrisée et être utilisée sans erreurs.
