Chapitre 07
Déploiement Docker

1. Docker Compose : la stack en un fichier

Plutôt qu'une série de docker run à rallonge, on décrit toute la stack edge dans un fichier compose.yml — versionné, relisable, reproductible. Le nôtre, dans /opt/edge/ :

# /opt/edge/compose.yml
services:
  gateway:
    image: registry.local/edge:1.8.2      # ← version PRÉCISE, jamais :latest
    container_name: edge-gateway
    restart: unless-stopped
    depends_on:
      - mqtt
    ports:
      - "8080:8080"
    volumes:
      - gateway-data:/data                # données persistantes
      - ./gateway.yml:/cfg/gateway.yml:ro # config en lecture seule
    environment:
      - OPCUA_ENDPOINT=opc.tcp://192.168.0.1:4840
    healthcheck:
      test: ["CMD", "/healthcheck.sh"]
      interval: 30s
      timeout: 5s
      retries: 3
    logging:
      driver: json-file
      options: { max-size: "20m", max-file: "5" }

  mqtt:
    image: eclipse-mosquitto:2.0.18
    container_name: edge-mqtt
    restart: unless-stopped
    volumes:
      - mqtt-data:/mosquitto/data

volumes:
  gateway-data:
  mqtt-data:

Les commandes de base de la stack, exécutées depuis /opt/edge/ :

maint@edge-cell12:/opt/edge$ docker compose ps        # état de la stack
maint@edge-cell12:/opt/edge$ docker compose up -d      # (re)crée ce qui doit l'être, en arrière-plan
maint@edge-cell12:/opt/edge$ docker compose logs -f    # logs agrégés de la stack
maint@edge-cell12:/opt/edge$ docker compose down       # arrête et retire les conteneurs (PAS les volumes)

2. Les tags : pourquoi :latest est un piège

Une image est identifiée par un tag (edge:1.8.2). Le tag spécial :latest ne veut pas dire « la plus récente en permanence » : c'est juste un nom par défaut, qui pointe vers une image figée au moment du pull. Sur un edge, il pose deux problèmes graves :

• Tu ne sais plus ce qui tourne. Deux edges « en :latest » peuvent exécuter des images différentes selon la date de leur dernier pull. Impossible de reproduire un incident ou de garantir un parc homogène.
• Le rollback devient impossible. Sans numéro de version, on ne peut pas désigner « la version d'avant » pour y revenir.

3. Le registry : d'où viennent les images

Les images sont stockées dans un registry — public (Docker Hub) ou, en OT, souvent un registry privé de l'usine (registry.local), accessible depuis l'edge. On récupère une image avec pull :

maint@edge-cell12:~$ docker pull registry.local/edge:1.9.0
1.9.0: Pulling from edge
a1b2c3: Pull complete
d4e5f6: Pull complete
Digest: sha256:7f3a...c1
Status: Downloaded newer image for registry.local/edge:1.9.0

4. Mettre à jour proprement

La mise à jour est un simple changement de tag suivi d'un up -d. Compose ne recrée que ce qui a changé (le service gateway), et laisse le broker tranquille.

# 1. Récupérer la nouvelle image AVANT de toucher au service en marche
maint@edge-cell12:/opt/edge$ docker pull registry.local/edge:1.9.0

# 2. Mettre à jour le tag dans compose.yml : image: registry.local/edge:1.9.0
maint@edge-cell12:/opt/edge$ sudoedit compose.yml

# 3. Appliquer : seul « gateway » est recréé (nouvelle image), « mqtt » reste en place
maint@edge-cell12:/opt/edge$ docker compose up -d
[+] Running 2/2
 ✔ Container edge-mqtt     Running
 ✔ Container edge-gateway  Started

# 4. VÉRIFIER immédiatement que ça remonte bien
maint@edge-cell12:/opt/edge$ docker compose ps
maint@edge-cell12:/opt/edge$ docker logs --tail 20 -f edge-gateway

5. Rollback : revenir en arrière en une minute

La nouvelle version se comporte mal (le healthcheck vire unhealthy, les logs crachent des erreurs, la supervision ne reçoit plus). On revient à la version précédente — d'où l'importance d'avoir gardé son image et noté son tag.

# 1. Constat : la 1.9.0 est mauvaise
maint@edge-cell12:/opt/edge$ docker logs --tail 10 edge-gateway
2026-07-04T10:12:03Z FATAL schema mismatch: expected v3, got v4

# 2. Remettre le tag précédent dans compose.yml : image: registry.local/edge:1.8.2
maint@edge-cell12:/opt/edge$ sudoedit compose.yml

# 3. Ré-appliquer : l'image 1.8.2 est toujours en local, redéploiement immédiat
maint@edge-cell12:/opt/edge$ docker compose up -d
 ✔ Container edge-gateway  Started
maint@edge-cell12:/opt/edge$ docker ps --format '{{.Names}}\t{{.Image}}\t{{.Status}}'
edge-gateway   registry.local/edge:1.8.2   Up 4 seconds (health: starting)

6. Politiques de redémarrage

La clé restart: du compose dit à Docker quoi faire quand un conteneur s'arrête :

Pour un service edge, unless-stopped est le bon défaut : il redémarre le conteneur après un crash et après un reboot de l'edge, tout en te laissant l'arrêter volontairement pour une maintenance sans qu'il ressuscite tout seul.

7. Compose ou systemd ? Les deux

On a vu deux mécanismes de résilience : la politique restart: de Docker (chapitre 7) et l'unité systemd edge-gateway.service (chapitre 3). Ils ne s'excluent pas :

• Docker enabled au boot (systemctl enable docker) + restart: unless-stopped dans le compose : suffit à ce que la stack revienne seule après un reboot. C'est l'approche la plus simple.
• Une unité systemd qui pilote docker compose up (chapitre 3) : ajoute un interrupteur clair (systemctl start/stop edge-gateway), des logs dans journald, et des dépendances explicites. C'est l'approche la plus « administrable ».

Récapitulatif

Exercices

$ docker pull registry.local/edge:1.9.0   # 1. pull d'abord (ancienne toujours en marche)
# 2. éditer compose.yml : image: ...edge:1.9.0 (NE PAS supprimer l'image 1.8.2 locale)
$ docker compose up -d                     # 3. bascule brève
$ docker compose ps && docker logs -f edge-gateway   # 4. vérifier healthcheck + remontée