Automatisation de la Chaîne de Production

1. Jenkins

1.1. Définition

1.1.1. Outil open-source permettant d’automatiser les tâches CI/CD.

1.2. Installation

1.2.1. Windows

1.2.1.1. Téléchargement depuis le site officiel et exécution d’un fichier .exe.

1.2.2. MacOS

1.2.2.1. Installation via Homebrew

1.2.2.1.1. brew install jenkins-lts

1.2.3. Linux

1.2.3.1. Ajout du repository et installation

1.2.3.1.1. apt-get install jenkins

1.2.4. Docker

1.2.4.1. docker pull jenkins/jenkins:ltsc

1.2.4.1.1. docker run -d \ --name jenkins \ -p 8080:8080 \ -p 50000:50000 \ -v jenkins_home:/var/jenkins_home \ jenkins/jenkins:lts

1.3. Interface Graphique

1.3.1. Composants clés de Jenkins

1.3.1.1. Plugins

1.3.1.1.1. Extensions pour ajouter des fonctionnalités comme Docker, GitHub

1.3.1.2. Crédentials

1.3.1.2.1. Système sécurisé de gestion des accès (clés SSH, tokens)

1.3.1.3. Utilisateurs et Labels

1.3.1.3.1. Gestion des permissions et catégorisation des tâches.

1.4. Jobs (freestyle project)

1.4.1. Jobs basiques

1.4.1.1. Exemple

1.4.1.1.1. Bash

1.4.1.1.2. Java

1.4.1.1.3. Python

1.4.2. Jobs en cascade

1.4.2.1. Déclenchement d’un job après l’exécution d’un autre.

1.4.2.1.1. Dans la configuration du jobs > ce qui déclenche le build > projet à surveiller (selectionner le projet) > choisir 'Déclenche que si la construction est stable'

1.4.3. Trigger GitHub

1.4.3.1. Jenkins peut être configuré pour exécuter un job après chaque commit ou push sur GitHub.

1.4.3.1.1. Configurer un webhooks sur le dépot github

1.4.4. Job périodique

1.4.4.1. Ce qui déclenche le build > Construire périodiquement

1.4.4.1.1. format cron : MINUTE HEURE JOUR_DU_MOIS MOIS JOUR_DE_LA_SEMAINE

1.5. Pipelines

1.5.1. Définition

1.5.1.1. Processus automatisé défini en script Groovy.

1.5.2. Types de pipelines

1.5.2.1. Déclaratif

1.5.2.1.1. Syntaxe plus simple et lisible (pipeline { ... }).

1.5.2.2. Scripté

1.5.2.2.1. Plus flexible, écrit sous forme de node { ... }.

1.5.3. Exemple de trigger Github

1.5.3.1. Déclenchement du pipeline via GitHub

1.5.3.1.1. Jenkins peut être configuré pour exécuter un pipeline lorsqu’un événement GitHub se produit, comme un push ou une pull request.

1.5.3.2. Agent Jenkins

1.5.3.2.1. Spécifie que le pipeline peut s’exécuter sur n’importe quel agent disponible.

1.5.3.2.2. Possibilité de restreindre (agent { label 'linux' } pour exécuter sur un agent spécifique).

1.5.3.2.3. Exemple

1.5.3.3. Stages et Steps

1.5.3.3.1. Le pipeline est divisé en stages, chacun contenant des steps.

1.5.3.4. Améliorations possibles

1.5.3.4.1. Ajout de tests unitaires

1.5.3.4.2. Déploiement automatique

1.5.4. Exemple de création de tag

1.5.4.1. Définition Générale du Pipeline

1.5.4.1.1. Confiuration de l'agent

1.5.4.1.2. Configuration des tools

1.5.4.1.3. Déclaration des Variables d’Environnement

1.5.4.1.4. Déroulement des Stages

1.5.4.1.5. Gestion des Résultats

1.6. Les vues

1.6.1. Objectif

1.6.1.1. Limiter l’accès aux jobs en fonction des rôles et améliorer l’organisation des projets.

1.6.2. Types de vues

1.6.2.1. Vue Liste

1.6.2.1.1. Liste simple des jobs.

1.6.2.2. Vue Grille

1.6.2.2.1. Liste simple des jobs.

1.6.2.3. Vue Pipeline

1.6.2.3.1. Permet de visualiser l’enchaînement des jobs.

2. CI/CD (Intégration et Déploiement Continus)

2.1. Définition

2.1.1. CI/CD est un ensemble de pratiques DevOps visant à automatiser l’intégration du code, ses tests et son déploiement pour accélérer la mise en production tout en garantissant une meilleure fiabilité.

2.2. Intégration Continue (CI - Continuous Integration)

2.2.1. Principe

2.2.1.1. Chaque modification du code est automatiquement testée et intégrée.

2.2.2. Objectif

2.2.2.1. Automatiser l’intégration du code dans un dépôt central pour détecter les erreurs le plus tôt possible.

2.2.3. Pourquoi

2.2.3.1. Évite les conflits entre développeurs.

2.2.3.2. Assure un code de qualité grâce à des tests automatiques.

2.2.3.3. Diminue le temps entre le développement et la livraison.

2.2.4. Outils principaux

2.2.4.1. Jenkins

2.2.4.1.1. Serveur d’automatisation.

2.2.4.2. GitHub Actions

2.2.4.2.1. CI/CD intégré à GitHub.

2.2.4.3. GitLab CI/CD

2.2.4.3.1. Solution complète de CI/CD sur GitLab.

2.2.4.4. CircleCI

2.2.4.4.1. Outil cloud permettant des tests et des déploiements automatisés.

2.2.5. Bonnes pratiques

2.2.5.1. Tests unitaires systématiques

2.2.5.1.1. Pour valider le code.

2.2.5.2. Commit régulier

2.2.5.2.1. Pour éviter de gros changements non testés.

2.2.5.3. Analyse statique du code

2.2.5.3.1. Avec SonarQube par exemple

2.3. Déploiement Continu (CD - Continuous Deployment/Delivery)

2.3.1. Objectif

2.3.1.1. Assurer un passage fluide du code en production, avec peu d’intervention humaine.

2.3.2. Continuous Delivery

2.3.2.1. Le code est préparé pour être mis en production après validation humaine.

2.3.3. Continuous Deployment

2.3.3.1. Automatisation complète du passage en production sans intervention humaine.

2.3.4. Stratégies de déploiement

2.3.4.1. Rolling Updates

2.3.4.1.1. Mise à jour progressive des serveurs sans arrêt total.

2.3.4.2. Blue-Green Deployment

2.3.4.2.1. Deux environnements, l’un en production, l’autre en pré-prod.

2.3.4.3. Canary Deployment

2.3.4.3.1. Mise en production progressive sur un petit groupe d’utilisateurs avant déploiement total.

3. Docker

3.1. Lancement de conteneurs avec Volumes

3.1.1. Définition

3.1.1.1. L’utilisation des volumes Docker permet de stocker les données de manière persistante, même si un conteneur est supprimé.

3.1.2. Pourquoi utiliser des volumes ?

3.1.2.1. Évite la perte de données après l’arrêt d’un conteneur.

3.1.2.2. Permet d’intégrer Jenkins dans un environnement persistant.

3.1.2.3. Partage des fichiers entre plusieurs conteneurs.

3.1.3. Commandes clés

3.1.3.1. Créer un volume

3.1.3.1.1. docker volume create jenkins_data

3.1.3.2. Monter un volume dans un conteneur

3.1.3.2.1. docker run -d -v jenkins_data:/var/jenkins_home jenkins/jenkins:lts

3.1.3.3. Lister les volumes existants

3.1.3.3.1. docker volume ls

3.2. Cgroups et Namespaces

3.2.1. Définition

3.2.1.1. Ces technologies sous-jacentes assurent l’isolation et la gestion des ressources des conteneurs.

3.2.1.1.1. Namespaces

3.2.1.1.2. Cgroups

3.2.1.1.3. ContainerD & RunC

4. Jenkins avec Vagrant

4.1. Objectif

4.1.1. Automatiser la gestion d’environnements de développement et tester des builds dans des machines virtuelles reproductibles.

4.2. Utilisation de Vagrant

4.2.1. Définition

4.2.1.1. Vagrant est un outil permettant de créer des environnements virtualisés rapidement.

4.2.2. Pourquoi utiliser Vagrant avec Jenkins ?

4.2.2.1. Permet de tester les déploiements sur différentes plateformes sans modifier la machine locale.

4.2.2.2. Facilement intégrable avec Docker, Ansible et Terraform.

4.2.3. Installation de Vagrant

4.2.3.1. Linux

4.2.3.1.1. sudo apt-get install vagrant

4.2.3.2. Mac

4.2.3.2.1. brew install vagrant

4.2.4. Creation VM

4.2.4.1. Exemple VM Ubuntu dans un Vagrantfile

4.2.4.1.1. Vagrant.configure("2") do |config| config.vm.box = "ubuntu/bionic64" config.vm.network "private_network", type: "dhcp" config.vm.provider "virtualbox" do |vb| vb.memory = "1024" end end

4.2.5. Lancer la VM

4.2.5.1. vagrant up

4.2.6. Se connecter en SSH

4.2.6.1. vagrant ssh