Découvre les mécaniques des outils de pipeline as code – #3 GitLab

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.

Suivez-nous et partagez

Laisser un commentaire