1 Architecture Docker, isolation et microservices

1.1 Pourquoi isoler une application ?

Une application dépend de son code, de bibliothèques, de paramètres et de ressources du système.

Problèmes potentiels :

1. Lorsque plusieurs applications partagent une machine, leurs dépendances peuvent entrer en conflit.
2. Le passage du poste de développement au serveur peut également révéler des différences d’environnement.

L’isolation vise à limiter ces interactions, et bien qu’elle rende le déploiement plus prévisible, elle ne garantit pas à elle seule la sécurité, la disponibilité ou l’absence de conflits.

Pourquoi utiliser Docker ?

Docker permet d’empaqueter une application avec les dépendances nécessaires à son exécution dans une image, puis de la lancer dans un conteneur isolé.
On obtient ainsi un environnement plus reproductible entre le développement, les tests et la production, tout en facilitant le déploiement et la gestion des applications.

1.2 Monolithe et microservices

• Le monolithe regroupe plusieurs fonctions métier dans une application déployée comme un ensemble.
• Les microservices répartissent les responsabilités entre des services autonomes qui communiquent au moyen d’interfaces définies, souvent des API.

Les microservices offrent une liberté de choix technologique et la possibilité de déployer indépendamment certains composants.

En contrepartie, ils complexifient les échanges, la cohérence des données, l’observabilité et les opérations.

Docker n’impose pas les microservices : un monolithe peut être conteneurisé, et un microservice peut s’exécuter sans Docker.

1.3 Virtualisation et conteneurisation

En bref :

• Une machine virtuelle (VM) exécute son propre système d’exploitation installé au-dessus d’une couche de virtualisation.
• Un conteneur Linux est constitué de processus isolés qui partagent le noyau Linux du système hôte avec les autres conteneurs fonctionnant sur ce même noyau.

Ce partage du noyau est une différence fondamentale avec la virtualisation classique.
Il faut le garder à l’esprit pour la sécurité : une isolation entre conteneurs ne signifie pas que chacun possède son propre noyau.

Machine virtuelle                  Conteneurs Linux
┌──────────────────────┐           ┌──────────────────────┐
│ Application          │           │ App A   │ App B      │
│ Bibliothèques        │           │ Dépend. │ Dépend.    │
│ OS invité + noyau    │           ├─────────┴────────────┤
├──────────────────────┤           │ Docker Engine        │
│ Hyperviseur          │           ├──────────────────────┤
│ Hôte / matériel      │           │ Noyau Linux de l’hôte│
└──────────────────────┘           └──────────────────────┘
          

La comparaison décrit les principes, pas toutes les implémentations.

1.4 Comment Linux isole les conteneurs

1.4.1 Contexte Linux

Quand une application fonctionne, Linux exécute un ou plusieurs processus : ce sont ses programmes en cours d’exécution.
Le noyau est la partie du système qui leur donne accès au processeur, à la mémoire, aux fichiers et au réseau.

Deux applications lancées sur le même Linux utilisent donc le même noyau et les ressources de la même machine.
Un conteneur Linux ne démarre pas un nouveau noyau comme une machine virtuelle.

Pour séparer ces applications, deux questions se posent :

• Quelles ressources du système chaque application peut-elle voir ?
  → Les namespaces séparent les vues des ressources.
• Quelle quantité de ressources chaque application peut-elle consommer ?
  → Les cgroups participent au suivi et au contrôle de cette consommation.

1.4.2 Les namespaces

Pourquoi séparer ce que voient les processus ?

Sur une machine Linux, plusieurs applications utilisent le même noyau. Pour faire fonctionner une application dans un conteneur, on veut lui donner son propre environnement : elle ne doit pas voir directement tous les processus ou toutes les interfaces réseau de la machine.

Un namespace Linux est un mécanisme du noyau qui donne à un groupe de processus une vue séparée de certaines ressources du système.

Les ressources ne sont pas toutes copiées dans une nouvelle machine. C’est leur visibilité qui est organisée : un processus voit les ressources accessibles dans ses namespaces.

Un exemple : le même processus, deux numéros

Le numéro d’un processus est appelé PID. Avec un namespace de processus, le processus principal d’un conteneur peut avoir le PID 1 dans le conteneur et un autre PID sur l’hôte.

Le PID 1 de A et le PID 1 de B ne se confondent pas : ils appartiennent à deux namespaces différents. Le processus de A ne voit pas les processus de B dans sa liste de processus.

Docker combine plusieurs namespaces

Le mécanisme existe aussi pour d’autres ressources. Docker en combine plusieurs pour construire l’environnement d’un conteneur.

Ce tableau présente les principaux exemples. La séparation dépend de la configuration : Docker permet aussi de partager certains namespaces.

1.4.3 Le cgroup

Pourquoi contrôler les ressources ?

Les conteneurs partagent le processeur et la mémoire de la machine. Une application qui consomme trop de mémoire ou sollicite fortement le processeur peut donc perturber les autres applications.

Les namespaces séparent les vues des ressources, mais cette séparation ne fixe pas à elle seule une limite de mémoire ou de CPU. Pour contrôler la consommation, Linux dispose d’un autre mécanisme : les cgroups.

Un cgroup (control group, ou groupe de contrôle) regroupe des processus pour mesurer et contrôler leur consommation de ressources, notamment la mémoire et le CPU.

Docker utilise ce mécanisme pour appliquer les limites configurées à un conteneur. Ces limites concernent l’ensemble de ses processus, pas chacun séparément.

Un exemple : trois processus, une limite commune

Un conteneur possède trois processus et une limite mémoire de 512 Mio. Les consommations comptabilisées dans son cgroup s’additionnent : chaque processus ne dispose pas de 512 Mio pour lui seul.

Que se passe-t-il lorsqu’une limite est atteinte ?

Une limite n’est pas une réservation : fixer un plafond de 512 Mio ne signifie pas que 512 Mio sont immédiatement occupés ou garantis au conteneur. Le comportement dépend aussi des réglages, notamment de l’utilisation du swap.

1.4.4 Pourquoi Docker utilise les deux

Un besoin : faire cohabiter plusieurs applications

Imaginons deux sites web, chacun exécuté par NGINX dans son conteneur. Ils tournent sur la même machine Linux et partagent son noyau, son processeur et sa mémoire.

Pour les faire cohabiter, il faut répondre à deux questions : quel environnement chaque application voit-elle ? et combien de ressources peut-elle consommer ?

Deux mécanismes pour deux besoins

1. Les namespaces construisent des vues séparées. Dans cet exemple, chaque conteneur possède son namespace de processus et son namespace réseau. Chacun peut donc avoir un PID 1 et écouter sur son port interne 80 sans se confondre avec l’autre.
2. Les cgroups contrôlent la consommation. Nous configurons une limite mémoire de 512 Mio pour le conteneur A et de 256 Mio pour le conteneur B. Chaque limite s’applique à l’ensemble des processus de son conteneur.

Si A consomme trop de mémoire, sa limite permet au noyau d’agir sur les processus de son groupe. C’est le cgroup qui intervient ; la séparation de ses processus et de son réseau provient des namespaces.

Pour accéder aux sites depuis l’extérieur, il faudra aussi configurer leur accès réseau, par exemple en publiant leurs ports sur des ports différents de l’hôte. Deux ports internes 80 ne signifient pas deux publications sur le même port de l’hôte.

Les permissions et les mécanismes de sécurité complètent cette isolation. Le noyau reste partagé : un conteneur ne possède pas son propre noyau comme une machine virtuelle.

1.4.5 Vérifier ce que l’on a compris

Répondez à chaque question avec vos propres mots, puis ouvrez la réponse pour vérifier votre compréhension.

1.5 Les composants de Docker

Docker adopte une architecture client/serveur :

• Le client transmet des demandes au daemon Docker ( dockerd ), qui gère les images, conteneurs, réseaux et volumes.
• Les images peuvent provenir d’un registre (public ou privé).

Utilisateur
    │
    ▼
Client Docker (CLI, interface, SDK)
    │   API Docker / socket ou connexion distante
    ▼
Docker Engine — daemon dockerd
    ├── Images ──────────────── Registre d’images
    ├── Conteneurs
    ├── Réseaux
    └── Volumes
          

Une image sert de modèle en lecture seule.
Un conteneur est une instance d’une image.
Un registre distribue des images, mais ne conserve pas les données produites par les conteneurs pendant leur exécution : celles-ci relèvent du stockage des conteneurs et des volumes.

1.6 Patterns : service principal, sidecar et initialisation

Dans une application distribuée, certains composants ont un rôle métier et d’autres remplissent une fonction auxiliaire ou préparatoire.

Ces patterns d’architecture aident à reconnaître les responsabilités des conteneurs.

      Phase de préparation
       [ Init container ]
                │ fin réussie
                ▼
        ┌──────────────────┐
        │ Application      │◄──►[ Sidecar ]
        └──────────────────┘
           fonctionnement
          

Un sidecar est un rôle architectural : il accompagne une application en assurant une fonction auxiliaire, comme la collecte de logs ou un proxy. Son fonctionnement dépend des besoins de l’application et des mécanismes offerts par l’environnement d’exécution.

Un init container est un conteneur chargé de préparer ou de vérifier les conditions nécessaires au démarrage d’une application. Ce modèle est notamment utilisé dans Kubernetes.

Lien avec Docker Compose

Un service de préparation peut exécuter une tâche avant le lancement de l’application. Compose peut attendre sa réussite avec depends_on et la condition service_completed_successfully, ou attendre qu’un service soit prêt grâce à service_healthy et un healthcheck.
On retrouve ainsi l’objectif d’un init container, sans que Compose fournisse exactement le même objet ni les mêmes garanties de cycle de vie que Kubernetes.

1.7 Exemple : une application web et ses services

Imaginons une application de réservation comprenant :

• Un service web : reçoit les requêtes HTTP ;
• Une API : applique les règles métier ;
• Une base de données : conserve les réservations ;
• Un composant de collecte : transmet les journaux à un système de supervision.

1.7.1 Expliquons ce qui se passe dans notre architecture

1. Le navigateur reçoit une page HTML du service Web.
2. Le service Web échange des données JSON avec l’API.
3. L’API interroge la base de données pour lire ou enregistrer les réservations.
4. Le composant de monitoring collecte les journaux de l’API et de la base de données.
   Il ne participe pas directement au traitement d’une réservation.

1.7.2 Les besoins techniques de notre architecture Docker

Pour faire fonctionner cette architecture, plusieurs éléments sont à prendre en compte :

• Le service web et l’API peuvent être déployés dans des conteneurs distincts.
• La base de données a besoin d’un stockage persistant.
• Le composant de collecte peut jouer un rôle auxiliaire de type sidecar selon l’architecture retenue.

Cette séparation rend les responsabilités visibles, mais elle implique des communications réseau, une gestion des accès et une stratégie de diagnostic.

1.8 Ce qu’il faut retenir