Mise en place d'une CI / CD

Master Expert Technologie de l'information EPITECH 2020.

Co-fondateur et CTO d'une startup dans l'Edtech 2019 - fin 2022. (+3 ans)

Formation PSPO-1 Agile Scrum 2022.

Co-fondateur et CTO d'une startup dans la Deeptech fin 2022 - aujourd'hui.

Valentin MONTAGNE

1

Qu'est-ce qu'une CI / CD ?

3

Bonus - Mise en place d'une CI / CD avec Github Actions

2

Mise en place d'une CI / CD avec Gitlab

Déroulement du cours

4

Mise en place du CD avec Terraform

Chaque séance débutera par la présentation d'un concept et de l'intérêt d'utilisation de celui-ci.

1 Théorie

Après la théorie, nous verrons alors la pratique en réalisant des exercices sur un repository gitlab.

2 Pratique

Nous verrons ensemble la correction des travaux pratiques. N'hésitez pas à poser vos questions.

3 Correction

Déroulement des journées

Connaissez-vous le principe de
CI / CD ?

Rendu TP et exercices

Pour faciliter le rendu final des TPs et exercices, vous allez créer un dépôt sur Github avec le nom cicd en publique et le cloner sur votre machine.

Si vous préférez le garder en privé, vous devez m'ajouter avec les droits pour voir votre dépôt avec le nom d'utilisateur : ValentinMontagne

Qu'est-ce qu'une CI / CD ?

1. Qu'est-ce que l'intégration continue ?

Intégration fréquente des changements au code source pour éviter les régressions.

Automatiser pour éviter les erreurs humaines et la pénibilité de tâche répétitive.

Utilise une pipeline avec différentes étapes pour vérifier la qualité des changements.

Le principe de non-regression

La régression est un type de bug, une fonctionnalité déjà présente et fonctionnel dans la solution n'est maintenant plus utilisable.

Un autre type de régression que la régression fonctionnelle existe, on l'appelle la régression de performance. Plus précisément, la fonctionnalité consomme maintenant bien plus de ressources pour fonctionner.

C'est un principe fondamental du développement d'éviter les bugs et les régressions.

Par exemple en Agilité, chaque itération du produit doit développer le produit, jamais diminuer involontairement sa qualité ou ses fonctionnalités.

Pourquoi utiliser l'intégration continue ?

Itérer rapidement, apprendre rapidement.

Permettre le Lean et l'Agile

Garder un produit fonctionnel car le déploiement est automatisable avec le Cloud as a service.

Lean, Agile, etc.

Beaucoup de méthode de gestion d'entreprise, de projet ou de produit se base sur une itération continue où l'apprentissage est la clé.

Lean, Agile, Hypothesis driven

Google Design Sprint

Grâce au Sprint Design, Google est capable de tester une nouvelle fonctionnalité en 5 jours ouvrés.

Course à l'itération !

Pour cela, les équipes ont besoin de méthodes pour éviter les régressions et augmenter la rapidité des livraisons.

Accelerate

Scientifiquement prouvé

Corrélation entre les performances et le bien-être au travail avec le CI / CD et le Lean

Computers perform repetitive tasks; People solve problems.

Key Indicators

Delivery lead time
Deployment frequency
Time to restore service
Change fail rate

DORA - DevOps Status

Le Workflow en CI / CD

Pourquoi se soucier de la qualité ?

Protéger l'entreprise d'incidents techniques

Créer un lien de confiance et garder les utilisateurs

Augmenter la productivité et le bien-être des équipes techniques

Pourquoi automatiser l'intégration ?

Réduire le temps et le coût de la validation des changements.

Les tâches pénibles et répétitives sont facilement ignorées.

Éviter les régressions à la source au lieu de les corriger après déploiement.

Les outils - Jenkins

Créé par Kohsuke Kawaguchi en 2011 avec Oracle car réalisé en Java.

Open source, s'interface avec des systèmes de versions comme Git.

Automatise le build, les tests et le déploiement.

Les outils - Gitlab CI

Créé par Gitlab Inc. en 2014, open source avec une version Entreprise.

Solution tout-en-un du CI / CD avec gestion des issues et pipelines liés aux projets.

Permet d'héberger une version de Gitlab directement sur les serveurs de l'entreprise.

Les outils - Github Actions

Après l'impulsion du rachat par Microsoft, créations de la partie Actions de Github en 2018.

Leader dans le stockage de dépôt de code et développement de projet Open Source, grande communauté.

Plus limité que Gitlab CI sur la partie DevOps / Docker.

Les outils - Git Hooks

Les hooks sont des scripts qui s'exécutent automatiquement à des moments précis du Workflow Git, par exemple lors d'un commit, pull ou push des modifications d'un dépôt. Ces scripts peuvent être utilisés pour effectuer diverses tâches, comme la validation du code, le formatage des fichiers ou même l'envoi de notifications.

Il existe deux types de hooks Git :

Côté client : Ils sont exécutés sur votre machine locale avant d'effectuer des modifications.
Côté serveur : Ils sont exécutés sur le serveur distant lorsque vous transférez des modifications.

Nous allons utiliser cet outil côté client pour éviter qu'un développeur ne commit du code qui n'est pas validé par notre CI.

Qu'est-ce que le déploiement continu ?

Le code est déployé après chaque modification.

Au vu de la fréquence, on automatise alors le déploiement.

Plusieurs stratégies de déploiement existent. (Blue / Green, Feature Flag, Canary...)

Pourquoi utiliser le déploiement continue ?

Gérer correctement les différents environnements de la solution.

Identifier et corriger rapidement les bugs et régressions.

Améliorer la stabilité de la solution et revenir rapidement à la version d'avant.

AWS, Google Cloud, Azure, Heroku, Vercel...

Externaliser son infrastructure

Automatiser et monitorer le déploiement des applications

Cloud as a service

Code as Infrastructure

Définir toute son infrastructure via des fichiers de configuration.

Automatiser la création, l'édition et la suppression des ressources de l'infrastructure dans le cloud.

Suivre les différentes versions de l'infrastructure en fonction de la solution.

Terraform

Automatise le déploiement sur tous les grands Clouds.

Est capable de gérer des grands cluster avec Kubernetes.

S'intègre facilement dans les pipelines CI / CD.

OpenTofu

Terraform a été mis en open-source en 2014 sous la Mozilla Public License (v2.0).

Puis, le 10 août 2023, avec peu ou pas de préavis, HashiCorp a changé la licence pour Terraform de la MPL à la Business Source License (v1.1), une licence non open source.

OpenTofu est un fork de la version Open source de Terraform et est géré par la fondation Linux. C'est donc une bonne alternative à Terraform aujourd'hui.

La migration à OpenTofu est extrêmement simple car il n'y a pas de différence de fonctionnement avec Terraform.

Stratégies de déploiement

Blue / Green

Feature Flag

Canary

1. Comment déployer fréquemment sans interrompre les utilisateurs ?

2. Comment déployer fréquemment sans bugs ou régressions pour les utilisateurs ?

3. Comment tester les changements avec de vrais utilisateurs ?

Stratégie Blue / Green

On crée deux environnements distincts mais identiques. Un environnement (Blue) exécute la version actuelle de l'application et un environnement (Green) exécute la nouvelle version de l'application.

Stratégie Feature Flag

Gère les fonctionnalités dans le code source. Une condition dans le code permet d'activer ou de désactiver une fonctionnalité pendant l'exécution. Voir Unleash.

Stratégie Canary

Redirige le trafic d'une portion des utilisateurs en fonction de critères ou d'un simple pourcentage vers la nouvelle version. Après un certain temps ou d'une condition, l'ensemble du trafic est rédirigé.

Mise en place des stratégies avec Gitlab CI

Implémentation de Blue / Green

Implémentation Feature Flag et Canary

Des questions ?

Mise en place d'une CI / CD avec Gitlab

2.

– Conrad Anker

Comment fonctionne Gitlab ?

Gitlab utilise le fichier à la racine de votre dépôt .gitlab-ci.yml qui contient toutes les instructions pour votre pipeline CI / CD. Lors d'évènement comme un commit ou une pull request (ou merge request), la pipeline s'execute grâce à des runners.

Les runners peuvent être hébergé par l'équipe (personnalisé) ou directement par Gitlab (partagé). Ils s'executent sur des machines physiques, virtuelles ou des conteneurs Docker.

# .gitlab-ci.yml File
# Configure the global image and cache for every stage
image: node:latest
cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/
    - .npm/
    
# Define all the stages used for the pipeline
stages:
  - validate
  - test
  - build
  - release
  - deploy
  
# Add first job using the '.pre' stage defined by Gitlab, could be a defined stage too
# .pre is always run as the first stage
install:
  stage: .pre
  script:
    # define cache dir & use it npm!
    - npm ci --cache .npm --prefer-offline

Exemple de Pipeline CI / CD

Lien du fichier source

– Conrad Anker

Pour aller plus loin

Terraform

# The configuration for the `remote` backend.
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.16"
    }
  }
  required_version = ">= 1.2.0"
}

provider "aws" {
  region = var.aws_region
}

# AWS EC2 instance
resource "aws_instance" "example" {
  ami           = var.ec2_ami
  instance_type = var.ec2_instance_type
  key_name      = var.ec2_key_name
  tags = {
    Name = "ExampleInstance"
  }
  user_data = <<-EOF
              #!/bin/bash
              sudo yum update -y
              sudo yum install -y docker
              sudo service docker start
              # Pull and run your Docker image here
              docker run -d -p 80:80 valentinmontagne/nginx-web-example:${var.docker_image_version}
              EOF
}

TP - Auth API

Gitlab CI

Création d'une pipeline CI

Création du compte Gitlab

Si vous n'avez pas encore de compte Gitlab, je vous invite pour la suite du TP et des exercices à créer un compte avec votre adresse étudiante.

Récupérer le projet de base

Maintenant que vous avez un compte Gitlab, vous pouvez "Fork" directement le projet ou le cloner sur votre machine et créer un nouveau projet vide pour récupérer le contenu du projet de base pour réaliser ce TP :

https://gitlab.com/vm-marvelab/ci-cd

(Tous les fichiers sont à mettre à la racine de votre dépôt.)

Auth API

Le projet de base est une API très simple en NodeJS, elle utilise Express pour lancer un serveur qui écoute les requêtes sur des routes définies.

N'hésitez pas à lire le README pour comprendre comment fonctionne la route /auth.

Utilisez la commande pour installer les dépendances du projet :

npm install

Ensuite utilisez la commande pour lancer l'API :

npm start

Configuration pipeline CI - 1

Maintenant que notre projet de base fonctionne, nous allons commencer à intégrer notre pipeline CI.

Pour cela, créez à la racine du projet le fichier .gitlab-ci.yml

N'hésitez pas à installer une extension sur votre IDE pour vous aider avec le format du fichier.

Passons à la prochaine étape.

Configuration pipeline CI - 2

Nous devons spécifier avec quel image notre Runner doit s'executer pour lancer notre pipeline CI, étant une API en nodejs, nous allons utiliser une image nodejs.

Nous allons ajouter des informations sur le cache pour éviter qu'à chaque Job de chaque Stage que nous soyons obliger de réinstaller les dépendances.

# .gitlab-ci.yml file

image: node:latest
cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/
    - .npm/

Configuration pipeline CI - 3

Comme vu ensemble, un Job est une étape spécifique du processus, comme exécuter des tests, compiler du code, ou déployer une application. Un job peut être configuré avec des scripts, des environnements d'exécution, et des conditions spécifiques (par exemple, quand il doit être exécuté). Plusieurs jobs peuvent s'exécuter en parallèle ou en séquence, en fonction des dépendances et de la structure du pipeline.

Un Stage est un groupe de Job et permet d'organiser la pipeline, ils s'exécutent dans l'ordre dont ils sont définis.

https://docs.gitlab.com/ee/ci/pipelines/

https://docs.gitlab.com/ee/ci/jobs/

Configuration pipeline CI - 4

Définissons nos Stages et réalisons notre premier Job qui sera l'installation des dépendances à la suite du fichier :

stages:
  - validate
  - test
  - build
  - release
  - deploy

install:
  stage: .pre
  script:
    # define cache dir & use it npm!
    - npm ci --cache .npm --prefer-offline

Ici le stage .pre est un Stage déjà créé par Gitlab, il est obligatoirement le premier à être lancé.

Nos Stages sont les étapes habituelles d'une pipeline de CI / CD.

Configuration pipeline CI - 5

Une fois ajouté, réaliser un git commit et un git push pour envoyer les changements à votre dépôt sur Gitlab.

Une fois fait, allez dans la section Build dans la barre à gauche du dépôt sur gitlab.com et cliquez sur Pipelines, il n'y a pas encore de Pipeline lancée, c'est parce que nous n'avons pas encore de Job hors installation.

Passons à l'étape suivante pour réaliser notre Stage validate.

Configuration pipeline CI - 6

Ajoutons maintenant le Stage de validation, pour cela nous allons ajouter les outils Eslint pour vérifier la qualité de notre code NodeJS :

npm init @eslint/config@latest

Choisissez les options "Style et problems", puis "CommonJS", "None of these", "No" pour Typescript et cochez "Node".

Un nouveau fichier eslint.config.mjs est apparu, passons à l'étape suivante.

Configuration pipeline CI - 7

Changez la configuration du fichier pour ignorer les fichiers de tests et ajouter des règles comme ici ne pas avoir de variables inutilisés, de variable non défini ou de console.log dans le code.

// eslint.config.mjs
import globals from "globals";
import pluginJs from "@eslint/js";

export default [
  {
    ignores: ["**/*.test.js"],
    files: ["**/*.js"],
    languageOptions: { sourceType: "commonjs" },
  },
  { languageOptions: { globals: globals.node } },
  pluginJs.configs.recommended,
  {
    rules: {
      "no-unused-vars": "error",
      "no-undef": "error",
      "no-console": "error",
    },
  },
];

Configuration pipeline CI - 8

Ajoutons maintenant le script "lint" au package.json pour pouvoir lancer la commande :

npm run lint

// package.json
// ...
  "scripts": {
    "start": "node src/index.js",
    "lint": "eslint src --max-warnings=0"
  },
// ...

Configuration pipeline CI - 9

Ajoutons maintenant un console.log que l'on a "oublié" dans une route de notre API dans le fichier index.js qui affiche la variable secret et qui ne devrait pas être dans nos logs !

const express = require("express");
const auth = require("./modules/authentication");

const app = express();
const port = process.env.PORT || 3000;

app.get("/", (req, res) => {
  res.send("Hello World!");
});

app.get("/auth/:secret", (req, res) => {
  const { secret } = req.params;
  const response = auth(secret);

  console.log(secret);
  res.status(response.status).send(response.message);
});

app.listen(port, () => {
  // eslint-disable-next-line no-console
  console.log(`Example app listening on http://localhost:${port}`);
});

Configuration pipeline CI - 10

Lancez la commande npm run lint vous devriez maintenant avoir une erreur.

Ajoutons maintenant un Job dans notre pipeline CI pour lancer cette commande automatiquement. A la suite du fichier .gitlab-ci.yml, ajoutez le Job lint dans le Stage validate.

// .gitlab-ci.yml
// ...

install:
  stage: .pre
  script:
    # define cache dir & use it npm!
    - npm ci --cache .npm --prefer-offline

lint:
  stage: validate
  script:
    - npm run lint

Configuration pipeline CI - 11

Faites un nouveau commit et faites un push sur la branch main à nouveau et retournez voir les Pipelines de votre dépôt pour voir le résultat.

La même erreur est détecté automatiquement par votre CI maintenant. Enlevez le console.log et faites de nouveau un push pour corriger le problème.

Mais cela serait plus fiable si l'on détectait ce genre de problème avant qu'il n'arrive sur notre pipeline non ?

Mettons en place notre Git hooks à l'étape suivante.

Installation des Git hooks - 1

Maintenant nous allons installer Husky à notre projet, qui permet de mettre en place les Git hooks pour nous permettre d'executer notre validation ou nos tests avant chaque commit. Cela rentre totalement dans l'intégration continue pour éviter de commit du code qui n'est pas fonctionnel ou de mauvaise qualité.

Lancez la commande :

npm install --save-dev husky && npx husky init

Husky génère alors un dossier .husky, ouvrez le fichier pre-commit dans ce dossier et changez npm test par npm run lint.

Installation des Git hooks - 2

Essayez de commit, vous allez maintenant avoir npm run lint qui s'execute automatiquement. Essayez d'oublier à nouveau un console.log dans le code, lors de la tentative de commit vous devriez être bloqué par l'echec de la commande npm run lint.

Maintenant ajoutons les tests à notre pipeline à l'étape suivante.

Ajout des tests - 1

Pour réaliser l'étape des tests, nous allons installer Vitest :

npm install -D vitest

Ensuite, ajoutons dans package.json la commande "test".

// package.json
// ...
  "scripts": {
    "start": "node src/index.js",
    "lint": "eslint src --max-warnings=0",
    "prepare": "husky",
    "test": "vitest run"
  },
  "devDependencies": {
// ...

Vérifiez que tout est fonctionnel avec la commande :

npm test

Ajoutez ensuite cette commande au Git hooks.

Ajout des tests - 2

Ensuite, ajoutons notre Job unit-test qui sera dans notre Stage test.

// .gitlab-ci.yml
// ...
install:
  stage: .pre
  script:
    # define cache dir & use it npm!
    - npm ci --cache .npm --prefer-offline

lint:
  stage: validate
  script:
    - npm run lint

unit-test:
  stage: test
  script:
    - npm test

Faites un push à nouveau et vérifiez que le job apparait bien dans votre pipeline et qu'il lance les tests.

Variables d'environnement et Rules - 1

Nous allons maintenant permettre de release une version de notre API via notre Pipeline. Ce Job doit alors être manuel pour nous laisser la possibilité d'activer la release au bon moment.

Par sécurité nous allons ajouter des Rules pour éviter que le Job Release se lance sur d'autres branches que main.

Pour créer une nouvelle version nous allons utiliser Release-it :

npm init release-it

Choisissez les réponses "Yes" et "package.json" à l'installation.

Variables d'environnement et Rules - 2

Ajoutez dans le package.json dans le champ "release-it" les informations "git" suivantes :

Voir à l'étape suivante l'ajout au .gitlab-ci.yml du Stage Release.

// package.json
// ...
  "dependencies": {
    "express": "^4.18.2"
  },
  "release-it": {
    "$schema": "https://unpkg.com/release-it/schema/release-it.json",
    "gitlab": {
      "release": true
    },
    "git": {
      "commitMessage": "chore: release v${version}"
    }
  }
// ...

Variables d'environnement et Rules - 3

// .gitlab-ci.yml
// ...
unit-test:
  stage: test
  script:
    - npm test

release:
  stage: release
  when: manual
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"
        && $CI_COMMIT_TAG == null
        && $CI_COMMIT_TITLE !~ /^chore: release/'
  before_script:
    - git config user.email $GITLAB_USER_EMAIL
    - git config user.name $GITLAB_USER_NAME
    - git remote set-url origin
      "https://gitlab-ci-token:$GITLAB_TOKEN@$CI_SERVER_HOST/$CI_PROJECT_PATH.git"
    - git checkout $CI_COMMIT_BRANCH
    - git pull origin $CI_COMMIT_BRANCH --rebase
  script:
    - npx --yes release-it --ci

Variables d'environnement et Rules - 4

// Permet de spécifier que ce Job sera activé manuellement.
when: manual
// Permet d'ajouter des rules au Job pour l'afficher ou non grâce au if.
// Ici le commit doit être sur la branche main, cela ne doit pas être un tag
// et le title du commit doit être différent de ce format.
rules:
	- if: '$CI_COMMIT_BRANCH == "main"
        && $CI_COMMIT_TAG == null
        && $CI_COMMIT_TITLE !~ /^chore: release/'

Quelques explications :

Variables d'environnement et Rules - 5

Ensuite, pour fonctionner, Release-it a besoin d'une variable d'environnement GITLAB_TOKEN. Pour cela nous allons devoir l'ajouter manuellement, mettez votre souris sur Settings et cliquez sur CI / CD, ensuite ouvrez le menu Variables. Ouvrez sur une autre page vos Access Tokens en mettant votre souris sur votre profil en haut à gauche, puis en cliquant sur Préférences, là vous devez cliquer sur Access Tokens et générer un nouveau Token avec les droits api.

Ajoutez ce token dans une nouvelle variable CI / CD de votre projet GITLAB_TOKEN.

Faites un push et lancez la release.

Appelez-moi quand vous avez terminé pour que l'on valide ensemble le TP.

Exercice 1 - Retirez des étapes

Nous avons un problème, ici après la release, deux pipelines se lancent, cela est inutile.

Vous devez retirer les étapes validate et test en ajoutant des rules aux Jobs pour qu'ils ne se lancent pas lorsqu'un tag est créé ou que le commit est le commit de release "chore: release".

Appelez-moi pour que l'on puisse valider ensemble.

Documentation :

https://docs.gitlab.com/ee/ci/jobs/job_rules.html

Exercice 2 - Ajouter une étape

Préparons un nouveau Job e2e-test dans le Stage test, pour l'instant il ne doit juste réaliser la commande suivante :

echo "Hello E2E !"

Il doit être visible uniquement dans les Merge Requests (Pull Requests).

Appelez-moi pour que l'on puisse valider ensemble.

Documentation :

https://docs.gitlab.com/ee/ci/jobs/job_rules.html

https://docs.gitlab.com/ee/ci/yaml/workflow.html

Exercice 3 - Ajouter une variable d'environnement

Préparons un nouveau Job only-canary dans le Stage validate, qui ne doit se lancer que quand l'on lance la pipeline pour l'environnement Canary, pour cela, nous allons créer une variable d'environnement "ENV_TARGET" qui doit être égale à "canary" pour que le Job se lance.

Pour l'instant il ne doit juste réaliser la commande suivante :

echo "Hello Only Canary !"

Appelez-moi pour que l'on puisse valider ensemble.

Documentation :

https://docs.gitlab.com/ee/ci/variables/

Exercice 4 - Ajouter des dépendances

Préparons un nouveau Job integration-test dans le Stage test, qui ne doit se lancer que quand le Job unit-test réussi, de même pour e2e-test qui ne doit maintenant se lancer que quand integration-test réussi.

Pour l'instant il ne doit juste réaliser la commande suivante :

echo "Hello Integration !"

Appelez-moi pour que l'on puisse valider ensemble.

Documentation :

https://docs.gitlab.com/ee/ci/yaml/needs.html

Exercice 5 - Enlevons la duplication de code

Durant les derniers exercices, nous avons souvent appliqué le même comportement à plusieurs Jobs. Pour éviter la duplication de code et que le fichier soit plus maintenable, utilisons les Anchors en YAML pour pouvoir faire hériter à nos Jobs une configuration.

Appelez-moi pour que l'on puisse valider ensemble.

Documentation :

https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html#use-extends-to-reuse-configuration-sections

TP - Déployer Docker

Maintenant que vous avez terminé l'intégration continue, nous allons maintenant voir le côté déploiement continu.

Pour cela, nous allons rajouter les étapes de builds pour l'image Docker et du déploiement de celle-ci.

Vous devez réaliser un fichier Dockerfile pour build le projet.

Ajouter l'étape suivante build-image :

# If your language needs to build you can create another build job before

# Add docker job to build the image
# Only for testing purpose, you can add a docker run + command to check health
# Gitlab has a lot of variables to use in the pipeline
# Here we are using $CI_REGISTRY_IMAGE and $CI_COMMIT_SHORT_SHA
build-image:
  stage: build
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  variables:
    IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  script:
    - docker image build -t $IMAGE_TAG .

TP - Déployer Docker - 2

Ici, nous utilisons un service spécial docker:20.10.16-dind pour permettre l'utilisation de Docker dans un container Docker.

On pourrait ici build plusieurs images si besoin durant cette étape.

Vérifiez que cette étape fonctionne en réalisant un push sur votre branche.

Ajoutez ensuite l'étape deploy-image :

deploy-image:
  needs:
    - release
  image: docker:20.10.16
  stage: deploy
  rules:
    - if: '$CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG == null && $CI_COMMIT_TITLE !~ /^chore: release/'
  services:
    - docker:20.10.16-dind
  variables:
    IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker image build --platform=linux/amd64 -t $IMAGE_TAG -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE --all-tags
  environment: production

TP - Déployer Docker - 3

Vérifiez après avoir push à nouveau les changements que votre image est bien ajoutée dans votre Container Registry en allant dans le menu Deploy sur votre dépôt Gitlab. C'est terminé !

Voici un exemple pour déployer sur un serveur distant, ceci n'est pas la meilleure méthode mais elle est très simple.

deploy:
  needs:
    - deploy-image
  stage: deploy
  rules:
    - if: '$CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG == null && $CI_COMMIT_TITLE !~ /^chore\(release\): publish/ && $CI_COMMIT_TITLE !~ /^chore\(pre-release\): publish/'
  before_script:
    - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
  script:
    - ssh-add <(echo "$SSH_PRIVATE")
    - ssh -o StrictHostKeyChecking=no "$SSH_SERVER" 'which docker || (sudo yum update -y && sudo yum install -y docker && sudo service docker start)'
    - <SAME> "sudo docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY"
    - <SAME> "(sudo docker rm -f example || true) && sudo docker run -p 80:3000 -d --name example registry.gitlab.com/vm-marvelab/docker-cicd:$CI_COMMIT_SHORT_SHA"
  environment: production

– Conrad Anker

Ex 1 : Créer une pipeline CI/CD

Récupérez les fichiers de la branche example
Créer un repository sur Gitlab pour créer une CI / CD en y ajoutant les fichiers.
Réaliser l'étape de validation de la CI.
Réaliser l'étape de build de l'image Docker de la CI.
Réaliser l'étape de release de la CD.
Réaliser l'étape de publication de l'image Docker de la CD.

Mise en place d'une CI / CD avec Github

3. Github Actions

Découvrons ensemble Github Actions, pour cela nous allons recommencer ce TP en utilisant uniquement Github.

Je vous invite à créer un compte Github si ce n'est pas déjà le cas pour la suite du TP.

Validation et tests

name: Node.js CI
on:
  push:
    branches: ['main']
  pull_request:
    branches: ['main']
jobs:
  build:
    runs-on:
      ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - name: Install
        run: npm ci --cache .npm --prefer-offline
      - name: Validate
        run: npm run lint
      - name: Test
        run: npm test
      - name: Build for production
        run: npm run build
      - uses: actions/upload-artifact@master
        with:
          name: web
          path: ./dist

Lien vers le fichier source

TP - Auth API

Github Actions

Github Actions

Maintenant que vous êtes plus à l'aise avec l'intégration continue, vous serez en autonomie, suivez la documentation https://docs.github.com/fr/actions pour réaliser le même TP qu'avec Gitlab CI, vous devez retrouver via la documentation de Github Actions comment refaire les étapes qu'on a réalisé avec Gitlab.

N'hésitez pas à m'appeler en cas de problème.

– Conrad Anker

Exercice 1 : Créer une pipeline CI/CD

Récupérez les fichiers de la branche example
Créer un repository sur Github pour créer une CI / CD en y ajoutant les fichiers.
Réaliser l'étape de validation de la CI.
Réaliser l'étape de build de l'image Docker de la CI.
Réaliser l'étape de release de la CD.
Réaliser l'étape de publication de l'image Docker de la CD.

Mise en place d'une CI / CD

Valentin MONTAGNE

1

3

2

Déroulement du cours

4

1

Théorie

2

Pratique

3

Correction

Déroulement des journées

Connaissez-vous le principe de CI / CD ?

Rendu TP et exercices

Qu'est-ce qu'une CI / CD ?

1.

Qu'est-ce que l'intégration continue ?

Le principe de non-regression

Pourquoi utiliser l'intégration continue ?

Lean, Agile, Hypothesis driven

Accelerate

DORA - DevOps Status

Le Workflow en CI / CD

Pourquoi se soucier de la qualité ?

Pourquoi automatiser l'intégration ?

Les outils - Jenkins

Les outils - Gitlab CI

Les outils - Github Actions

Les outils - Git Hooks

Qu'est-ce que le déploiement continu ?

Pourquoi utiliser le déploiement continue ?

Cloud as a service

Code as Infrastructure

Terraform

OpenTofu

Stratégies de déploiement

Stratégie Blue / Green

Stratégie Feature Flag

Stratégie Canary

Mise en place des stratégies avec Gitlab CI

Des questions ?

Mise en place d'une CI / CD avec Gitlab

2.

Comment fonctionne Gitlab ?

Exemple de Pipeline CI / CD

Pour aller plus loin

Terraform

TP - Auth API

Création d'une pipeline CI

Auth API

Configuration pipeline CI - 1

Configuration pipeline CI - 2

Configuration pipeline CI - 3

Configuration pipeline CI - 4

Configuration pipeline CI - 5

Configuration pipeline CI - 6

Configuration pipeline CI - 7

Configuration pipeline CI - 8

Configuration pipeline CI - 9

Configuration pipeline CI - 10

Configuration pipeline CI - 11

Installation des Git hooks - 1

Installation des Git hooks - 2

Ajout des tests - 1

Ajout des tests - 2

Variables d'environnement et Rules - 1

Variables d'environnement et Rules - 2

Variables d'environnement et Rules - 3

Variables d'environnement et Rules - 4

Variables d'environnement et Rules - 5

Exercice 1 - Retirez des étapes

Exercice 2 - Ajouter une étape

Exercice 3 - Ajouter une variable d'environnement

Exercice 4 - Ajouter des dépendances

Exercice 5 - Enlevons la duplication de code

TP - Déployer Docker

TP - Déployer Docker - 2

TP - Déployer Docker - 3

Connaissez-vous le principe de
CI / CD ?