Chapitre 1 : Introduction au DevOps

1.1 Qu'est-ce que DevOps ?

Le mot DevOps provient de la contraction de deux termes : Development (Développement) et Operations (Exploitation/Infrastructure). DevOps est une culture, un ensemble de pratiques et de méthodes qui permettent aux équipes de collaborer afin de livrer des logiciels de qualité, plus rapidement et avec une plus grande fiabilité.

DevOps est une approche collaborative qui automatise le cycle de vie complet d'une application : développement, intégration, tests, déploiement, surveillance et amélioration continue.

1.2 Pourquoi DevOps ?

Traditionnellement, les équipes fonctionnaient en silos fermés :

• Le Développeur écrit le code et réalise les tests locaux (sa priorité est la vitesse et l'innovation).
• L'Exploitant (Ops) configure les serveurs et gère la stabilité de production (sa priorité est la sécurité et le contrôle).

Ce conflit naturel provoquait de nombreux blocages, des retards de livraison et des pannes de production. DevOps supprime cette frontière artificielle en alignant les objectifs des deux équipes autour de la livraison continue.

1.3 Les Principes CALMS

DevOps repose sur cinq piliers indispensables décrits par l'acronyme CALMS :

Chapitre 2 : Git & GitHub

2.1 Pourquoi Git ?

Git évite le versioning chaotique consistant à multiplier des répertoires locaux (ex: Projet_Final_v2_OK). Il offre un historique infalsifiable, permet de revenir en arrière sur n'importe quelle modification et de faire travailler simultanément des dizaines de développeurs sur les mêmes fichiers.

2.2 L'Architecture Git

Git fonctionne avec quatre zones de cycle de vie des fichiers :

2.3 Commandes fondamentales

$ git init                   # Initialiser un dépôt local
$ git status                 # Voir les fichiers modifiés et indexés
$ git add .                  # Indexer tous les fichiers
$ git commit -m "Message"    # Valider les modifications locales
$ git push origin main       # Envoyer le commit vers le dépôt distant

2.4 Le Modèle GitFlow

Le workflow GitFlow structure le développement en branches dédiées :

• main : La branche de production (stable).
• develop : Branche de développement actif.
• feature/* : Branches temporaires pour développer de nouvelles fonctionnalités.
• release/* : Préparation et stabilisation d'une nouvelle version de production.
• hotfix/* : Correction immédiate et urgente d'un bug en production.

Chapitre 3 : Docker et la Conteneurisation

3.1 Pourquoi Docker ?

Avant l'avènement de Docker, le déploiement d'applications souffrait du problème classique de l'incompatibilité des environnements (le syndrome du « Chez moi ça fonctionne »). Les différences de versions de systèmes d'exploitation, de librairies système (comme glibc), ou de dépendances logicielles (versions de Node, Python, Java) provoquaient fréquemment des pannes lors du déploiement en production.

Docker résout ce problème en s'appuyant sur des fonctionnalités du noyau Linux (les Namespaces pour l'isolation des processus, réseaux et disques, et les **Control Groups / cgroups** pour la limitation des ressources physiques comme le CPU et la RAM). Il permet d'emballer une application et tout son environnement d'exécution dans une unité logique standardisée et portable.

3.2 Machine virtuelle vs Conteneur

Contrairement aux machines virtuelles traditionnelles qui nécessitent un système d'exploitation invité (Guest OS) complet et un hyperviseur, les conteneurs partagent le noyau du système d'exploitation de la machine hôte. Cela se traduit par une efficacité de ressources incomparable.

3.3 Les composants Docker

• Dockerfile : Fichier texte de configuration contenant les instructions successives pour assembler l'image applicative. Directives majeures :
  • FROM : Définit l'image de base (ex: python:3.12-slim).
  • WORKDIR : Définit le répertoire de travail dans le conteneur.
  • COPY : Copie des fichiers locaux de l'hôte vers le conteneur.
  • RUN : Exécute des commandes lors de la construction (build) de l'image (ex: installation de paquets).
  • EXPOSE : Documente le port d'écoute réseau.
  • CMD : Commande par défaut exécutée au démarrage du conteneur.
• Image : Modèle immuable en lecture seule constitué d'une superposition de couches (layers). Chaque instruction du Dockerfile crée une nouvelle couche, facilitant le cache de build.
• Conteneur : Instance active et modifiable d'une image. Docker y ajoute une fine couche accessible en écriture (writable layer) au-dessus des couches de l'image.
• Registry : Dépôt centralisé d'images (Docker Hub, GitHub Container Registry, GitLab Registry) servant à distribuer les images.

3.4 Cycle de vie de l'application conteneurisée

Le workflow Docker repose sur le principe de Build, Ship, and Run (Construire, Distribuer, Exécuter) :

3.5 Commandes essentielles détaillées

# 1. Construire l'image avec un tag depuis le dossier courant (.)
$ docker build -t mon-application:v1.0.0 .

# 2. Lister les images stockées localement
$ docker images

# 3. Lancer un conteneur en arrière-plan (-d) avec mappage de port (-p local:conteneur)
$ docker run -d -p 8080:5000 --name instance-web mon-application:v1.0.0

# 4. Lister les conteneurs actifs (ajouter -a pour inclure les conteneurs arrêtés)
$ docker ps

# 5. Consulter les logs de l'application en direct (-f pour suivre le flux)
$ docker logs -f instance-web

# 6. Exécuter une commande interactive (TTY) à l'intérieur du conteneur
$ docker exec -it instance-web bash

# 7. Arrêter et supprimer le conteneur
$ docker stop instance-web
$ docker rm instance-web

3.6 Docker Compose

Docker Compose simplifie la gestion des applications multi-conteneurs. Au lieu de taper de longues lignes de commande Docker pour chaque service, on décrit toute la pile technique dans un fichier YAML unique (docker-compose.yml) :

version: "3.9"

services:
  web:
    build: .
    container_name: web-service
    ports:
      - "5000:5000"
    depends_on:
      - database

  database:
    image: postgres:16
    container_name: db-service
    environment:
      POSTGRES_DB: devops_db
      POSTGRES_PASSWORD: root_pass
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Toute l'infrastructure (le serveur web Flask et sa base de données PostgreSQL) démarre d'une seule commande : docker compose up -d.

3.7 Volumes et Réseaux

• Les Volumes : Par défaut, les conteneurs sont éphémères (toutes les données créées à l'intérieur sont perdues à sa suppression). Les volumes permettent de monter un répertoire de la machine hôte dans le conteneur pour persister les fichiers sensibles (comme les données de base de données ou les uploads utilisateurs).
• Les Réseaux (Networks) : Permettent aux conteneurs de communiquer entre eux de manière isolée et sécurisée. Docker Compose crée automatiquement un réseau privé par défaut pour tous les services définis, leur permettant de s'adresser par leur nom de service (ex: l'application web peut se connecter à la base de données en utilisant l'hôte database au lieu d'une adresse IP).

Chapitre 4 : CI/CD avec GitHub Actions

4.1 Qu'est-ce que la CI (Intégration Continue) ?

L'Intégration Continue (Continuous Integration) est une pratique de développement logiciel dans laquelle les membres d'une équipe fusionnent fréquemment leurs modifications de code dans la branche principale (généralement plusieurs fois par jour).

Chaque fusion ou git push déclenche automatiquement un pipeline de validation qui effectue :

• La récupération du code source (checkout).
• L'installation de l'environnement et des dépendances.
• La vérification de la syntaxe et de la qualité du code (Linting).
• La compilation/build de l'application.
• La vérification fonctionnelle via l'exécution des tests automatisés (tests unitaires et d'intégration).

L'objectif principal est de détecter les régressions et les conflits d'intégration le plus tôt possible dans le cycle de développement, évitant les mauvaises surprises avant la mise en production.

4.2 Qu'est-ce que le CD (Livraison et Déploiement Continus) ?

Le **CD** représente l'extension logique de l'Intégration Continue. Il existe deux approches distinctes :

• Continuous Delivery (Livraison Continue) : Le pipeline automatise toutes les étapes jusqu'à la production. Une image ou un package stable est généré et prêt à être déployé à tout moment, mais le clic final pour envoyer le code en production nécessite une validation humaine (ex: un chef de projet ou un administrateur).
• Continuous Deployment (Déploiement Continu) : Le pipeline est entièrement automatisé de bout en bout. Dès qu'un commit franchit toutes les validations de la CI, il est automatiquement déployé en production, sans aucune intervention humaine. C'est l'approche la plus avancée.

4.3 Qu'est-ce que GitHub Actions ?

GitHub Actions est la plateforme CI/CD intégrée nativement à GitHub. Elle permet d'automatiser, de personnaliser et d'exécuter des workflows de développement logiciel directement dans votre dépôt. Les pipelines de GitHub Actions sont décrits dans des fichiers au format **YAML** placés impérativement dans le répertoire suivant du projet : .github/workflows/.

4.4 Les éléments fondamentaux d'un workflow

• Event (Événement) : Le déclencheur qui démarre le workflow (ex: un push sur la branche main, une pull_request, ou une planification chronologique cron).
• Job (Travail) : Un ensemble d'étapes (Steps) exécutées séquentiellement sur un même exécuteur (Runner). Par défaut, si vous avez plusieurs Jobs, ils s'exécutent en parallèle, mais vous pouvez les lier par des dépendances (ex: le job de déploiement dépend du succès du job de test).
• Step (Étape) : Une tâche individuelle au sein d'un Job. Il peut s'agir d'une simple commande bash (ex: npm run test) ou de l'appel à une Action réutilisable.
• Action : Un module de tâche pré-packagé (disponible sur la Marketplace GitHub) pour simplifier les workflows (ex: actions/checkout pour cloner le dépôt, ou docker/setup-buildx-action).
• Runner (Exécuteur) : La machine virtuelle ou le conteneur sur lequel le Job est exécuté (fourni par GitHub comme ubuntu-latest, windows-latest, ou auto-hébergé sur vos propres serveurs).

4.5 Exemple complet d'un pipeline CI/CD YAML

Voici un fichier de workflow type (.github/workflows/ci-cd.yml) configuré pour tester une application Python Flask, compiler son image Docker et la publier sur Docker Hub :

name: Pipeline CI/CD DevOps

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  run-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Récupérer le code source
        uses: actions/checkout@v4

      - name: Configurer Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Installer les dépendances
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Exécuter les tests unitaires
        run: |
          python -m unittest discover tests/

  build-and-push-docker:
    runs-on: ubuntu-latest
    needs: run-tests # Ce job ne démarre que si le job 'run-tests' réussit !
    steps:
      - name: Récupérer le code source
        uses: actions/checkout@v4

      - name: Se connecter à Docker Hub
        uses: docker/login-action@v3
        with:
          username: $
          password: $

      - name: Configurer Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build et Push de l'image Docker
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: $/devops-app:latest

4.6 Les avantages de la CI/CD

• Détection précoce des erreurs : Les bugs sont identifiés et corrigés immédiatement après l'écriture du code, réduisant considérablement le coût des corrections.
• Livraison accélérée : Le déploiement ne prend plus des heures de manipulation manuelle stressante ; il se fait en quelques minutes de manière automatique.
• Qualité et homogénéité : Les tests sont joués systématiquement sur des machines virtuelles neutres et propres, garantissant qu'aucune bibliothèque locale du développeur ne fausse les résultats.
• Historique et Audit : Chaque déploiement en production est documenté par un commit Git et un rapport d'exécution du workflow CI/CD, offrant une traçabilité totale.

Chapitre 5 : Déploiement Professionnel et Administration

5.1 Préparation et Sécurisation du VPS

Un VPS (Virtual Private Server) est une instance virtuelle louée chez un hébergeur Cloud (ex: OVH, DigitalOcean, AWS, GCP). Par défaut, le serveur est livré avec le compte administrateur root accessible. Pour des raisons évidentes de sécurité, il convient de durcir l'accès immédiatement :

1. Création d'un utilisateur système non-root doté des droits d'administration :

   $ adduser devopsuser
   $ usermod -aG sudo devopsuser

2. Sécurisation de SSH : Désactiver l'authentification par mot de passe au profit d'une clé SSH publique/privée, et interdire la connexion directe en root dans le fichier /etc/ssh/sshd_config :

   PermitRootLogin no
   PasswordAuthentication no

   Puis redémarrer le service SSH : sudo systemctl restart ssh.
3. Configuration du pare-feu (UFW) : Bloquer par défaut tous les ports entrants, sauf le port SSH, HTTP et HTTPS :

   $ sudo ufw default deny incoming
   $ sudo ufw default allow outgoing
   $ sudo ufw allow 22/tcp
   $ sudo ufw allow 80/tcp
   $ sudo ufw allow 443/tcp
   $ sudo ufw enable

5.2 Installation de Docker Engine

Pour installer proprement Docker sur Ubuntu, on évite les paquets obsolètes fournis par défaut et on configure les dépôts officiels Docker :

# Mettre à jour l'index des paquets et installer les prérequis
$ sudo apt update && sudo apt install -y ca-certificates curl gnupg

# Ajouter la clé GPG officielle de Docker
$ sudo install -m 0755 -d /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
$ sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configurer le dépôt apt officiel
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Installer Docker Engine, le CLI et Docker Compose
$ sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Autoriser notre utilisateur devopsuser à lancer Docker sans sudo
$ sudo usermod -aG docker devopsuser

5.3 Déploiement avec Docker Compose

Une fois le fichier docker-compose.yml transféré sur le serveur (via Git ou une action SSH de notre CI/CD), le déploiement se fait d'une seule commande. Docker se charge de télécharger les images requises, de créer le réseau privé et de démarrer les conteneurs dans le bon ordre de dépendance :

# Lancer la pile applicative en arrière-plan (detached mode)
$ docker compose up -d

# Vérifier le statut des conteneurs
$ docker compose ps

# Consulter les journaux en direct de toute la stack
$ docker compose logs -f

5.4 Nginx comme Reverse Proxy

Nginx est installé sur le système hôte (ou en tant que conteneur Docker séparé) et sert d'aiguillage réseau. Il écoute sur les ports standards du web (80 et 443) et redirige le trafic vers le bon conteneur en y injectant les entêtes HTTP d'origine. Voici un bloc de configuration type de Nginx (/etc/nginx/sites-available/default) :

server {
    listen 80;
    server_name mon-domaine.com;

    location / {
        proxy_pass http://127.0.0.1:5000; # Redirige vers le conteneur Flask
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Activer la configuration et redémarrer Nginx : sudo systemctl restart nginx.

5.5 Sécurisation HTTPS avec Let's Encrypt & Certbot

Pour passer notre site en HTTPS (port 443), on utilise l'autorité de certification gratuite **Let's Encrypt**. L'utilitaire **Certbot** analyse la configuration Nginx et génère automatiquement le certificat d'autorité :

# Installer Certbot et son plugin Nginx
$ sudo apt install -y certbot python3-certbot-nginx

# Lancer la génération et la configuration automatique SSL
$ sudo certbot --nginx -d mon-domaine.com

Certbot modifie la configuration Nginx pour y insérer les chemins vers la clé privée et le certificat SSL générés, et ajoute une redirection automatique HTTP vers HTTPS. Les certificats durent 90 jours ; Certbot installe un démon système (Systemd Timer) qui vérifie et renouvelle les certificats automatiquement deux fois par jour.

5.6 Surveillance, Diagnostic et Maintenance

Une fois l'application déployée, la phase de "Run" (Exploitation) commence. Le DevOps doit monitorer l'état du système :

• docker stats : Visualisation en temps réel de la consommation CPU, RAM et réseau de chaque conteneur.
• docker logs -n 100 [container_id] : Affiche les 100 dernières lignes de log pour diagnostiquer une erreur applicative.
• journalctl -u docker.service -n 50 : Consulte les logs du démon système Docker.
• Scripting de Sauvegardes : Automatisation d'un dump de base de données PostgreSQL compressé quotidien, puis son transfert sécurisé vers un espace de stockage objet froid (S3) :

  docker exec -t db-service pg_dump -U postgres devops_db | gzip > backup_$(date +%F).sql.gz

5.7 Bonnes pratiques de déploiement professionnel

• Séparation des Environnements : Utilisez des environnements distincts (Dev, Staging pour les tests, Prod pour les utilisateurs) pour éviter les perturbations.
• Secrets Manager : Ne stockez jamais d'identifiants ou secrets en clair. Chargez-les via des variables d'environnement injectées par GitHub Secrets en production.
• Déploiement Blue-Green / Canary : Stratégies de livraison avancées limitant le downtime (interruption de service) lors des mises à jour.
• Rollback automatique : Si les tests de santé (Healthchecks) échouent suite à une mise à jour automatique, le pipeline CI/CD doit immédiatement redéployer l'ancienne version stable d'image Docker.

Conclusion du Cours

Le DevOps : une culture et un standard incontournable.

Le DevOps n'est pas seulement une boîte à outils technologiques, c'est avant tout un changement culturel visant à briser le fossé historique entre les équipes de développement et d'infrastructure.

En combinant Git pour le contrôle de versions, GitHub pour la collaboration, Docker pour la portabilité des environnements, GitHub Actions pour l'automatisation systématique, et un VPS Ubuntu sécurisé par Nginx et HTTPS pour l'hébergement, vous disposez d'un socle d'ingénierie robuste, capable de livrer de la valeur en continu, rapidement, et en toute sécurité. La maîtrise de cette chaîne DevOps est la clé pour concevoir des applications modernes et fiables de l'idée jusqu'à la production.