Conteneurisation avec Docker et Kubernetes

Public Visé

• Développeurs logiciels
• Administrateurs système
• Ingénieurs DevOps
• Chefs de projet IT

Objectifs du Cours

• Comprendre les concepts fondamentaux de la conteneurisation.
• Apprendre à créer, gérer et déployer des conteneurs avec Docker.
• Maîtriser les techniques d'orchestration de conteneurs avec Docker Compose et Kubernetes.
• Mettre en œuvre les meilleures pratiques de conteneurisation dans des environnements de développement et de production.

Prérequis

• Connaissance de base de la ligne de commande.
• Expérience en développement logiciel.
• Connaissance des systèmes d'exploitation, particulièrement Linux.

Durée

• 5 jours (8 heures par jour)
  1. Introduction à la conteneurisation et Docker
  2. Commandes de base de Docker et gestion des conteneurs
  3. Docker Compose et gestion des réseaux et volumes
  4. Introduction à Kubernetes et orchestration de conteneurs
  5. Meilleures pratiques et cas d'usage

Découvrir le cloud

1. Introduction au cloud

   Le cloud computing est la livraison de services informatiques — calcul, stockage, bases de données, réseaux — via l'internet, avec une facturation à l'usage. On ne possède plus le matériel : on consomme une ressource.

   Les trois modèles de service

   • IaaS (Infrastructure as a Service) : vous gérez le système d'exploitation et les applications, le fournisseur gère le matériel et la virtualisation. C'est le modèle le plus proche d'un datacenter classique.
   • PaaS (Platform as a Service) : le fournisseur gère l'infrastructure et le système d'exploitation ; vous ne publiez que votre code.
   • SaaS (Software as a Service) : l'application est entièrement gérée par le fournisseur. C'est le modèle de la messagerie d'entreprise ou d'un CRM.

   Le passage du modèle on-premise au cloud ne consiste pas à « déplacer des serveurs » : le principal changement est l'inversion des responsabilités, et c'est ce qui structure toute la suite du cours.

   Le modèle de responsabilité partagée

   Ce modèle est la règle d'or du cloud, et une source classique d'erreur. En IaaS, le client est responsable du système d'exploitation, des données et des applications ; le fournisseur est responsable du matériel, de la virtualisation et du réseau physique. En SaaS, le fournisseur est responsable de tout sauf vos données et vos accès.

   Conséquence pratique : « c'est dans le cloud, donc ce n'est pas mon problème » est faux. La sûreté du système d'exploitation, le correctif applicatif et la gestion des identités restent votre responsabilité.

   Régions et zones de disponibilité

   • Une région est une zone géographique indépendante qui héberge l'ensemble des services.
   • Une zone de disponibilité (Availability Zone, AZ) est un datacenter isolé au sein d'une même région.

   Déployer sur plusieurs AZ d'une même région protège d'une panne d'infrastructure tout en gardant la latence faible (une seule région). Déployer sur plusieurs régions protège aussi d'une catastrophe régionale, au prix d'une plus grande complexité.

   Choisir sa région, c'est arbitrer entre latence (proximité des utilisateurs), conformité (données qui ne doivent pas sortir d'un pays) et coût (les prix varient d'une région à l'autre).

2. Économie du cloud : comment on paie

   En cloud, l'essentiel du coût vient de la capacité provisionnée, pas du trafic. C'est le point le plus important à retenir, et la première cause de facture surprise.

   Les quatre modes de paiement (Amazon EC2)

   Repris de la documentation AWS sur les options d'achat EC2 :

   • On-Demand — paiement à l'usage, à l'heure ou à la seconde (60 secondes minimum), sans engagement ni paiement initial. C'est le tarif de référence.
   • Spot Instances — capacité inutilisée remise sur le marché, jusqu'à 90 % de réduction selon AWS, mais interruptible : AWS peut reprendre la machine.
   • Savings Plans — engagement sur un montant horaire cohérent pendant 1 ou 3 ans, en échange d'une réduction : jusqu'à 66 % pour Compute Savings Plans, jusqu'à 72 % pour Amazon EC2 Instance Savings Plans (AWS annonce ces maximums).
   • Reserved Instances — jusqu'à 75 % de réduction en prépayant. AWS recommande aujourd'hui de les remplacer par les Savings Plans pour EC2, plus flexibles.

   Comment combiner

   Le schéma recommandé par AWS dans le pilier « Cost Optimization » est un mélange : un socle stable engagé en Savings Plans, complété par de l'On-Demand ou des Spot pour les variations, et des réservations de capacité quand la disponibilité prime.

   Socle stable et prévisible  -> Savings Plans ou RI (engagement 1-3 ans)
   Pics et traitements différés -> Spot Instances (jusqu'à -90 %, interruptible)
   Charge imprévisible          -> On-Demand
    criticité maximale          -> On-Demand Capacity Reservation (capacité garantie)

   Attention : les Spot ne sont pas adaptés à un travail non interruptible (une base de données unique, un serveur frontal critique). Les Savings Plans ne garantissent pas la disponibilité de la capacité, seulement un prix plus bas.

3. Piliers d'une architecture cloud

   Les six piliers du AWS Well-Architected Framework, repris de la documentation AWS. Toute architecture cloud se juge sur ces six axes, et une conception qui en oublie un se paie plus tard.

   1. Excellence opérationnelle — soutenir le développement et exploiter les charges, obtenir de la visibilité sur l'exploitation et améliorer continuellement les processus.
   2. Sécurité — protéger les données, les systèmes et les actifs, et améliorer sa posture de sécurité.
   3. Fiabilité — garantir qu'une charge remplit sa fonction prévue, de façon constante, et pouvoir la tester sur tout son cycle de vie.
   4. Efficience de performance — utiliser les ressources de calcul de manière efficace et maintenir cette efficacité quand la demande évolue.
   5. Optimisation des coûts — délivrer la valeur métier au prix le plus bas possible.
   6. Durabilité — améliorer continuellement l'impact environnemental en réduisant la consommation d'énergie, en maximisant l'utilisation des ressources provisionnées et en minimisant les ressources nécessaires.

   Le pilier de durabilité est relativement récent dans le framework : c'est une bonne illustration du fait qu'un référentiel évolue et qu'il faut le consulter plutôt que de le réciter de mémoire.

4. Exercices

   1. Comparer les modèles : pour une application interne de gestion, dites quel modèle (IaaS, PaaS, SaaS) you'd choisir et justifiez en une phrase par critère : qui gère quoi, qui porte la responsabilité de la sécurité.
   2. Choisir une région : un site sert des utilisateurs en France et en Allemagne, avec des données soumises au RGPD. Combien de régions et de zones déployez-vous, et pourquoi ?
   3. Dimensionner un coût : une API tourne 24 h/24 à débit constant, et un traitement de nuit dure 3 heures, par lots, tolérant à l'interruption. Quel mode de paiement pour chacune, et pourquoi ?
   4. Auditer un existant : pour un site web d'e-commerce installé sur un serveur dédié, listez ce qui change au niveau de la responsabilité, de la disponibilité et de la facture.

AWS : les fondamentaux

1. Introduction à AWS

   Amazon Web Services est le premier fournisseur cloud au monde. Le catalogue dépasse 200 services ; un premier sous-ensemble suffit à couvrir la très grande majorité des besoins.

   La console de gestion donne accès à tous ces services, mais l'outillage professionnel repose sur deux autres interfaces : l'AWS CLI et l'AWS CloudShell (un terminal déjà configuré dans la console).

   # Vérifier la configuration
   aws configure
   aws sts get-caller-identity
   
   # Lister les régions disponibles
   aws ec2 describe-regions --query 'Regions[?Region==\`eu-west-3\`]' --output table
   
   # Créer une instance (puis la détruire : elle est facturée dès qu'elle tourne)
   aws ec2 run-instances --image-id ami-xxxx --instance-type t3.micro --count 1
   aws ec2 describe-instances --filters "Name=instance-state-name,Values=running"
   aws ec2 terminate-instances --instance-ids i-xxxx

   Règle d'or du coût : une instance EC2 est facturée dès qu'elle est en marche, même si personne ne s'y connecte. Une instance arrêtée continue d'être facturée pour son stockage (EBS). D'où la règle : arrêter ou détruire dès que ce n'est pas nécessaire, et toujours étiqueter ses ressources.

2. Les services essentiels

   Six services couvrent l'essentiel des cas d'usage :

   • Amazon EC2 — machines virtuelles. Unité de calcul de référence.
   • Amazon S3 — stockage objet, durable, avec des classes de stockage selon la fréquence d'accès. Extrémement économique, à ne pas confondre avec un disque attaché.
   • Amazon RDS — base de données relationnelle gérée (MySQL, PostgreSQL, etc.) : AWS gère les sauvegardes, les correctifs et la réplication.
   • AWS Lambda — exécution de fonctions sans serveur, facturée à la durée d'exécution réelle, avec mise à l'échelle automatique.
   • Amazon VPC — réseau isolé, avec sous-réseaux publics et privés, et contrôle des flux par groupes de sécurité.
   • AWS IAM — gestion des identités et des permissions. C'est le service le plus critique : une politique trop large est la première cause de fuite de données.

   Choisir entre EC2 et Lambda

   Critère	EC2	Lambda
   Facturation	à l'heure/à la seconde tant que l'instance tourne	à la milliseconde réellement utilisée
   Gestion du serveur	oui	aucune
   Durée maximale d'exécution	illimitée	bornée (environ 15 minutes)
   Fonctionnalité standard	tout	contraintes mémoire et disque
   Adapté à	application serveur, base, traitement long	API événementielle, tâche planifiée, glue

3. Disponibilité, sécurité et coûts

   La haute disponibilité

   Objectif : qu'une panne n'arrête pas le service. Trois niveaux d'engagement, du plus simple au plus coûteux :

   • Plusieurs AZ dans une région — protège d'un incident de datacenter. C'est le socle attendu pour un service de production.
   • Plusieurs régions — protège d'une catastrophe régionale, au prix de la complexité (réplication des données, bascule, DNS).
   • Zone de reprise — en cas de panne, on redémarre dans une autre région. C'est un pis-aller, avec perte de données possible.

   L'autoscaling et l'équilibre de charge répartissent la charge et remplacent les instances défaillantes : disponibilité et dimensionnement devient automatique.

   La sécurité, du réseau vers les données

   1. Réseau       : VPC + sous-réseaux public/privé + groupes de sécurité
   2. Identités   : IAM, rôles, pas d'utilisateur root au quotidien
   3. Chiffrement  : au repos (S3, EBS, RDS) et en transit (TLS, KMS)
   4. Traçabilité : CloudTrail (qui a fait quoi), CloudWatch (métriques et alarmes)

   Maîtriser le coût

   • cette même distinction IaaS / PaaS / SaaS : le serverless déplace une partie du coût vers l'usage réel ;
   • dimensionner au plus juste et surveiller avec CloudWatch ;
   • engager sur le socle stable (Savings Plans), garder On-Demand et Spot pour les variations ;
   • stocker dans la bonne classe S3 (Standard, Infrequent Access, Glacier) selon la fréquence d'accès ;
   • activer les alertes budgétaires avant de subir la facture.

4. Référentiel AWS Certified Solutions Architect

   Si vous visez la certification AWS Certified Solutions Architect – Associate, voici le référentiel en vigueur, repris du guide d'examen officiel :

   • Code de l'examen : SAA-C03. Il remplace SAA-C02, en vigueur depuis le 30 août 2022.
   • Format : 65 questions, à choix unique ou multiples réponses.
   • Domaines et pondérations officielles :

   Domaine	Pondération
   Concevoir des architectures sécurisées	30 %
   Concevoir des architectures résilientes	26 %
   Concevoir des architectures performantes	24 %
   Concevoir des architectures optimisées en coût	20 %

   La préparation consiste donc à raisonner en scénarios : pour une exigence donnée, quel service et quelle combinaison de services répondent, et avec quel coût. Ce cours fournit la matière ; la certification valide l'entraînement.

   À noter : un référentiel de certification évolue. Vérifiez toujours la version en vigueur sur le site AWS avant de vous engager sur un code d'examen — c'est exactement le piège que ce module essaie de vous montrer.

5. Exercices

   1. Choisir le bon service : un site vitrine, une base relationnelle, un traitement déclenché par l'envoi d'un fichier, et un stockage d'archives anciennes. Pour chacun : service(s) retenu(s) et justification en une phrase.
   2. Dimensionner la disponibilité : une boutique en ligne doit rester joignable 99,9 % du temps. Combien d'AZ, et quelles briques sont obligatoires ? Que changerait l'exigence à 99,99 % ?
   3. Estimer le coût : une instance t3.micro tourne en continu dans une région européenne, avec un disque de 20 Go. Quel mode de paiement pour le socle, et quelles optimisations appliquez-vous sur le reste ?
   4. Sécurité : pourquoi ne doit-on pas utiliser les identifiants AWS dans le code ? Que mettre à la place ?

Conteneurisation : bases, Docker, Compose et Kubernetes

1. Les Bases de la Conteneurisation

   1. Introduction à Docker

      1. Présentation de Docker
      2. Installation de Docker
      3. Concepts Clés de Docker : Image Docker, Conteneur Docker, Dockerfile, Docker Hub

   2. Commandes de Base de Docker

      1. Créer une Image Docker
      2. Lister les Images Docker
      3. Exécuter un Conteneur
      4. Lister les Conteneurs
      5. Arrêter un Conteneur
      6. Supprimer une Image

2. Création et Gestion des Conteneurs

   1. Création d'une Image avec Dockerfile

      1. Syntaxe et exemples de Dockerfile
      2. Construction d'une Image Docker

   2. Gestion des Réseaux et des Volumes

      1. Création d'un Réseau Docker
      2. Exécution d'un Conteneur avec un Réseau Spécifique
      3. Création et Utilisation de Volumes

3. Orchestration des Conteneurs

   1. Introduction à Docker Compose

      1. Présentation de Docker Compose
      2. Création d'un fichier docker-compose.yml
      3. Commandes Docker Compose

   2. Introduction à Kubernetes

      1. Présentation de Kubernetes
      2. Concepts Clés de Kubernetes : Pod, Service, Deployment

4. Meilleures Pratiques et Cas d'Usage

   1. Meilleures Pratiques de la Conteneurisation

      1. Utiliser des images légères
      2. Minimiser les droits d'accès
      3. Utiliser des variables d'environnement

   2. Cas d'Usage de la Conteneurisation

      1. Microservices
      2. Développement et test en continu (CI/CD)
      3. Migration d'applications monolithiques vers des microservices