Ma définition

Docker est une plateforme de conteneurisation qui permet de créer, déployer et exécuter des applications dans des conteneurs. Un conteneur est une unité légère et portable qui contient tout ce dont une application a besoin pour fonctionner, y compris le code, les bibliothèques, les dépendances et les fichiers de configuration. Docker permet aux développeurs de créer des applications de manière plus rapide et plus efficace, en éliminant les problèmes liés à la compatibilité des environnements de développement et de production. Avec Docker, les développeurs peuvent facilement partager leurs applications avec d'autres personnes, que ce soit pour le développement collaboratif ou pour le déploiement en production.

Docker fonctionne selon deux concepts complémentaires : les images Docker et les conteneurs Docker. Il est important de comprendre la différence entre les deux, car elles sont souvent confondues alors qu'il s'agit de la base du fonctionnement de Docker. Je précise toutefois que Docker est un outil vaste et complexe. Je n'expliquerai pas tout en détail, mais je vais tout de même expliquer, de manière simplifiée, les principes essentiels pour comprendre les images et les conteneurs.

Pour commencer, les images. Une image Docker contient tout le code, les bibliothèques, les dépendances et parfois un système minimal nécessaire pour exécuter l'application. Pour créer l'image d'une application, on choisit une image de base adaptée, puis on ajoute le code, on installe les dépendances et on configure l'environnement nécessaire au bon fonctionnement de l'application. Le but étant d'obtenir une image complète et autonome qui peut être exécutée sur n'importe quelle machine disposant de Docker, sans se soucier des différences d'environnement ou de configuration.

Une fois l'image créée, on peut l'exécuter dans un conteneur Docker. Peu importe que le conteneur soit lancé sur un serveur, un ordinateur Windows, Linux ou macOS, tant que Docker est installé, l'application va se comporter de la même façon. C'est l'un des principaux intérêts de Docker, car cela facilite considérablement le développement et surtout le déploiement.

Le conteneur Docker, quant à lui, est l'instance d'une image en cours d'exécution. Pour exécuter plusieurs instances d'une application, il suffit de lancer plusieurs conteneurs à partir de la même image. Chaque conteneur fonctionne de manière isolée, avec sa propre configuration et ses propres données. Cela rend la gestion d'instances multiples simple et fiable.

En bref, l'image décrit l'état de votre application (fichiers, dépendances, configuration) tandis que le conteneur est l'environnement d'exécution créé à partir de cette image. L'image est la base, le conteneur est l'instance en fonctionnement.

Toutes les données que l'application enregistre (fichiers, etc.) peuvent être écrites dans le conteneur. Vous pouvez arrêter puis redémarrer un conteneur : l'application retrouvera généralement le même état si des volumes persistants sont utilisés. En revanche, si vous supprimez un conteneur sans avoir externalisé les données grâce à des volumes, vous allez perdre ces données. Les volumes sont des fichiers ou des répertoires sur l'hôte qui sont rendus accessibles au conteneur. Ils permettent de stocker les données de manière persistante, même si le conteneur est supprimé ou recréé.

En plus de ses avantages fonctionnels, Docker apporte un niveau d'isolation qui contribue à la sécurité. Un conteneur isole l'application du système d'exploitation hôte. En cas de faille, l'attaque reste confinée au conteneur et n'affecte pas directement l'hôte ou les autres conteneurs. Cette isolation réduit les risques, mais ne doit pas remplacer d'autres bonnes pratiques de sécurité.

Mes éléments de preuve

Docker est, au même titre que Git, un outil incontournable pour de nombreux développeurs. Aujourd'hui, il est difficile d'envisager le déploiement sans Docker. Pour ma part, je l'ai utilisé sur absolument tous mes projets, en développement comme en production, car il est à la fois puissant et pratique pour créer des environnements reproductibles.

Pour être plus précis, j'utilise Docker Compose, un outil qui permet de définir et de gérer des applications multi-conteneurs. Autrement dit, il permet de décrire plusieurs services (base de données, serveur web, frontend, etc.) qui fonctionnent ensemble pour former une application complète. C'est très pratique pour orchestrer un ensemble de conteneurs.

Cela m'est utile car chacune de mes applications repose généralement sur trois conteneurs : frontend, backend et base de données. Grâce à Docker Compose, je peux définir ces conteneurs dans un seul fichier et les lancer simultanément avec une commande, ce qui me fait gagner beaucoup de temps et simplifie la configuration.

La première fois que j'ai réellement utilisé Docker en profondeur, c'était pour Econoris, lors de la mise en production. Auparavant, je n'avais fait que lancer des conteneurs existants. Pour Econoris, j'ai dû créer moi-même les images Docker et les configurer pour la production. Cette expérience m'a permis de comprendre réellement comment Docker fonctionne et comment l'utiliser efficacement pour le développement et le déploiement.

Le premier concept que j'ai appris concerne évidemment les images. J'ai appris à créer des images optimisées en partant d'images de base légères et en n'incluant que les dépendances nécessaires. Le Dockerfile d'Econoris, que nous présentons ci-dessous, illustre ces bonnes pratiques. Il a d'ailleurs servi de base pour d'autres projets comme FlorAccess et Genesis.

1
# Étape 1 : Build avec TypeScript
2
FROM node:24-alpine AS builder
3
WORKDIR /app
4

5
# Copier le code source
6
COPY tsconfig.json ./
7
COPY package*.json ./
8
COPY ./src ./src
9
COPY ./public ./public
10

11
# Supprimer les fichiers sensibles s'ils existent
12
RUN rm -f .env* public/.env* src/.env*
13

14
# Installer les dépendances
15
RUN npm ci
16

17
# Build TypeScript → JavaScript
18
RUN npm run build
19

20
# Étape 2 : Image finale
21
FROM node:24-alpine AS runner
22
WORKDIR /app
23

24
# Copier uniquement les fichiers nécessaires à l'exécution
25
COPY package*.json ./
26
RUN npm ci --omit=dev
27

28
COPY --from=builder /app/dist ./dist
29
COPY --from=builder /app/public ./public
30

31
# Ajout d'un utilisateur non-root avec UID/GID fixes
32
# Utiliser les options longues pour éviter les ambiguïtés entre différentes variantes d'adduser/addgroup
33
RUN addgroup --gid 1800 --system econorisgroup &&   adduser --uid 1800 --system --ingroup econorisgroup --disabled-password --gecos "" --no-create-home econorisuser
34
USER econorisuser
35

36
# Par défaut : lance le serveur
37
CMD ["node", "dist/server.js"]

Cet exemple est relativement simple, mais il montre à quel point Docker est puissant et flexible pour créer des images optimisées et sécurisées.

Le Dockerfile bien fait est souvent séparé en deux étapes. L'étape de build et l'étape de production. La première installe les dépendances, compile le projet, exécute éventuellement des tests et peut contenir des secrets nécessaires au build. La seconde crée l'image finale destinée à la production. Elle ne contient que les fichiers nécessaires à l'exécution et est optimisée pour la sécurité, la performance et la fiabilité.

Cette architecture multi-étapes est puissante car tout ce qui se passe dans l'étape de build est supprimé de l'image finale. On peut donc utiliser des outils de build et inclure des secrets temporaires sans les intégrer à l'image finale. En copiant uniquement l'essentiel dans l'étape de production, on obtient une image plus légère, plus rapide à démarrer et moins exposée aux risques de sécurité.

Vous remarquerez aussi que, dans l'étape de production, j'exécute l'application avec un utilisateur non-root (sans privilèges). Cette bonne pratique réduit les risques de sécurité. Si l'application est compromise, l'attaquant n'obtient pas automatiquement des droits d'administrateur au sein du conteneur, ce qui lui rend plus difficile l'exploitation de la faille.

1
# Étape 1 : Builder Flutter Web
2
FROM dart:stable AS builder
3
WORKDIR /app
4

5
# Installer Flutter SDK (branche stable) et précharger le SDK web
6
ENV CI=true     FLUTTER_SUPPRESS_ANALYTICS=true     PUB_ENVIRONMENT=docker
7

8
RUN apt-get update && apt-get install -y --no-install-recommends     git curl unzip xz-utils ca-certificates
9
RUN git clone --branch stable --depth 1 https://github.com/flutter/flutter.git /flutter
10
RUN chmod -R a+rX /flutter
11
RUN /flutter/bin/flutter config --no-analytics
12
RUN /flutter/bin/flutter --suppress-analytics --version
13
RUN /flutter/bin/flutter --suppress-analytics precache --web
14

15
# Activer Flutter Web et mettre le PATH
16
ENV PATH="/flutter/bin:/flutter/bin/cache/dart-sdk/bin:${PATH}"
17
RUN flutter --suppress-analytics config --enable-web
18

19
# Copier le code source de l'application dans le repertoire courent (/app)
20
COPY . .
21

22
# Suppression des fichiers inutiles pour le build
23
RUN rm -rf .env .git .github .vscode .idea .dart_tool build
24

25
# Installer les dépendances du projet de manière déterministe
26
RUN flutter --suppress-analytics pub get
27

28
# Build web
29
RUN flutter --suppress-analytics build web --release
30

31
# Étape 2 : Image finale avec NGINX
32
FROM nginx:alpine
33

34
# Remove default nginx website
35
RUN rm -rf /usr/share/nginx/html/*
36

37
# Copier le build Flutter web
38
COPY --from=builder /app/build/web /usr/share/nginx/html
39

40
# Optionnel : config nginx custom
41
COPY nginx.conf /etc/nginx/conf.d/default.conf
42

43
# Ajout d'un utilisateur non-root avec UID/GID fixes
44
RUN addgroup -g 1800 -S econorisgroup && adduser -u 1800 -S econorisuser -G econorisgroup     && mkdir -p /run/nginx /var/cache/nginx /var/run /var/log/nginx     && chown -R econorisuser:econorisgroup /var/cache/nginx /var/run /var/log/nginx /run/nginx     && chmod 0755 /run/nginx
45
USER econorisuser

Nous pouvons également voir ci-dessus le Dockerfile de l'application frontend d'Econoris, qui est une application Flutter. Ce Dockerfile permet de créer une image optimisée pour exécuter une application Flutter web en production, en utilisant NGINX comme serveur web pour servir les fichiers statiques de l'application Flutter web.

Vous pouvez voir que le Dockerfile est également séparé en deux étapes. La première étape va copier le code source de l'application, installer les dépendances et build l'application Flutter web pour générer les fichiers statiques qui seront servis par NGINX. La deuxième étape va utiliser une image NGINX légère pour servir les fichiers statiques de l'application Flutter web, et elle est également configurée pour être optimisée pour la production, avec des bonnes pratiques de sécurité, de performance et de fiabilité.

Ce qui est intéressant dans le Dockerfile de l'application frontend d'Econoris, c'est l'utilisation d'images différentes entre l'étape de build et l'étape de production. Par ailleurs, on peut créer autant d'étapes que nécessaire, seule la dernière étape est conservée dans l'image finale.

Un autre point important est l'optimisation du build. Le build peut être long, plusieurs minutes. Docker dispose donc d'un mécanisme de cache efficace. En ajoutant le code source relativement tard dans le Dockerfile, on maximise l'utilisation du cache pour les étapes précédentes qui changent rarement. Ainsi, lors d'un changement de code, Docker n'a pas à réexécuter toutes les instructions et peut éviter de réinstaller Flutter depuis Internet, ce qui permet de gagner plusieurs minutes par build.

Sur l'aspect sécurité, si un attaquant parvenait à compromettre l'application depuis le conteneur, l'impact reste limité au conteneur. De plus, la configuration (par exemple, l'exécution en read-only, l'impossibilité d'augmentation de privilèges) limite la capacité d'escalade des privilèges, ce qui renforce grandement la sécurité en production.

Grâce à Docker et à une configuration soignée, on ajoute plusieurs niveaux d'isolation en complément des sécurités applicatives, ce qui renforce la fiabilité et la sécurité pour la production. C'est en partie pour ces raisons que j'utilise systématiquement Docker pour le déploiement.

Voyons maintenant Docker Compose, qui permet de paramétrer tous les conteneurs d'une application et de les lancer simultanément avec une seule commande. C'est un outil puissant pour gérer les services d'une application, en développement comme en production.

1
services:
2
  # Econoris Database #
3
  econoris-db:
4
    image: florobart/econoris-db:latest
5
    restart: always
6
    env_file:
7
      - ./config/.env.econoris_db
8
    volumes:
9
      - econoris_db_data:/var/lib/postgresql/econoris_db_data
10
    networks:
11
      - econoris-net
12
    security_opt:
13
      - no-new-privileges:true
14
    healthcheck:
15
      test: ["CMD-SHELL", "pg_isready -U ${ECONORIS_DB_USER} -d ${ECONORIS_DB_NAME} || exit 1"]
16
      interval: 5s
17
      timeout: 30s
18
      retries: 5
19

20
  # Econoris Server #
21
  econoris-server:
22
    image: florobart/econoris-server:latest
23
    working_dir: /app
24
    restart: always
25
    env_file:
26
      - ./config/.env.econoris_server
27
    depends_on:
28
      econoris-db:
29
        condition: service_healthy
30
    networks:
31
      - flower-garden-net
32
      - econoris-net
33
    ports:
34
      - ${ECONORIS_SERVER_PORT:-}:80
35
    security_opt:
36
      - no-new-privileges:true
37
    cap_drop:
38
      - ALL
39
    cap_add:
40
      - NET_BIND_SERVICE
41
    read_only: true
42
    user: "1800:1800"
43
    tmpfs:
44
      - /tmp:exec,nosuid,nodev
45
    healthcheck:
46
      test: ["CMD-SHELL", "wget -q --spider http://econoris-server:80/ || exit 1"]
47
      interval: 10s
48
      timeout: 5s
49
      retries: 5
50

51
  # Econoris App Web #
52
  econoris-app-web:
53
    image: florobart/econoris-app-web:latest
54
    restart: always
55
    env_file:
56
      - ./config/.env.econoris_app
57
    volumes:
58
      - ./config/.env.econoris_app:/usr/share/nginx/html/assets/.env:ro
59
    networks:
60
      - flower-garden-net
61
    ports:
62
      - ${ECONORIS_APP_PORT:-}:80
63
    depends_on:
64
      econoris-server:
65
        condition: service_healthy
66
      floraccess-server:
67
        condition: service_healthy
68
    security_opt:
69
      - no-new-privileges:true
70
    cap_drop:
71
      - ALL
72
    cap_add:
73
      - NET_BIND_SERVICE
74
      - CHOWN
75
      - SETGID
76
      - SETUID
77
    read_only: true
78
    user: "1800:1800"
79
    tmpfs:
80
      - /tmp:exec,nosuid,nodev,uid=1800,gid=1800
81
      - /run:rw,mode=0755,uid=1800,gid=1800
82
      - /run/nginx:rw,mode=0755,uid=1800,gid=1800
83
      - /var/cache/nginx:rw,uid=1800,gid=1800
84
      - /var/cache/nginx/client_temp:rw,uid=1800,gid=1800
85
      - /var/cache/nginx/proxy_temp:rw,uid=1800,gid=1800
86
      - /var/cache/nginx/fastcgi_temp:rw,uid=1800,gid=1800
87
      - /var/cache/nginx/uwsgi_temp:rw,uid=1800,gid=1800
88
      - /var/cache/nginx/scgi_temp:rw,uid=1800,gid=1800
89
    healthcheck:
90
      test: ["CMD-SHELL", "wget -q --spider http://econoris-app-web:80/ || exit 1"]
91
      interval: 10s
92
      timeout: 5s
93
      retries: 5

Vous pouvez voir ci-dessus le Docker Compose complet d'Econoris. Chaque service est un conteneur (base de données, backend, frontend). Les conteneurs sont configurés pour la production : healthchecks, volumes pour la persistance, réseaux internes pour la communication entre services, et options de sécurité visant à limiter les privilèges.

Je ne vais pas passer en revue l'ensemble du fichier de configuration, mais voici quelques points intéressants, notamment sur la sécurité. J'ai défini des réseaux personnalisés pour limiter la communication aux services nécessaires. Par exemple, un réseau partagé avec le reverse-proxy ("flower-garden-net") permet d'exposer le backend via un nom de domaine, tandis qu'un réseau privé ("econoris-net") permet au backend de communiquer avec la base de données sans exposer cette dernière sur Internet.

Seuls le backend et la base de données sont présents sur le réseau privé "econoris-net", ce qui évite d'exposer la base de données sur Internet et limite l'accès à cette dernière. De plus, certains conteneurs sont configurés en read-only, de sorte qu'un attaquant ayant compromis un conteneur ne puisse pas modifier ses fichiers, ce qui renforce encore la sécurité.

En résumé, grâce à Docker et à une configuration adaptée, mes applications évoluent dans des environnements isolés. Même si une vulnérabilité applicative est exploitée, l'impact reste limité. Il est impossible d'écrire dans le conteneur, d'escalader les privilèges ou d'accéder à l'hôte ou à d'autres conteneurs. Le code source étant généralement public, l'accès aux fichiers ne suffit pas à compromettre l'infrastructure.

L'attaquant pourrait éventuellement accéder au fichier d'environnement contenant des secrets (clés d'accès), mais si la base de données n'est pas exposée et si les accès sont correctement restreints, ces secrets restent difficilement exploitables depuis le conteneur compromis.

Autrement dit, même si l'application fait l'objet d'attaques ciblées et sophistiquées, la configuration et l'isolation limitent considérablement l'accès aux données, ce qui protège les utilisateurs et les données sensibles.

Mon autocritique

J'ai choisi Econoris comme exemple car c'est le premier projet pour lequel j'ai appliqué systématiquement les bonnes pratiques Docker. Cela m'a permis d'acquérir une solide expérience. J'ai appliqué des pratiques similaires sur d'autres projets, qu'il soit personnel ou professionnel, notamment sur Genesis, où j'ai pu présenter les automatisations et mesures de sécurité mises en place sur Econoris à d'autres développeurs plus expérimentés qui travaillent sur Genesis.

Ils ont pu vérifier ce que j'avais réalisé et me donner des conseils pour aller plus loin, notamment sur l'utilisation du cache Docker. Au final, la configuration de mes images et conteneurs s'est révélée de très bonne qualité, hormis l'utilisation du cache, j'avais appliqué des techniques d'optimisation et de sécurité pertinentes, comme la séparation d'une étape de build permettant d'inclure des secrets sans les intégrer à l'image finale.

Grâce à cette expérience, j'ai une bonne maîtrise de Docker. Maintenant, pour continuer de progresser, je compte m'intéresser à Kubernetes. Kubernetes reprend les concepts d'images et de conteneurs, mais ajoute une couche d'orchestration pour gérer les déploiements à grande échelle. Il propose un gestionnaire de secrets, souvent chiffrés, et des fonctionnalités d'auto-scaling pour adapter automatiquement les ressources en fonction de la charge. C'est la prochaine étape logique pour approfondir la conteneurisation.

Attention toutefois, pour aborder Kubernetes il faut maîtriser Docker, car Kubernetes repose sur les mêmes concepts, mais il est plus complexe et nécessite une bonne connaissance préalable des images et conteneurs, ce qui le rend plus facile à apprendre avec Docker.

Mon évolution dans cette compétence

Pour moi, Docker fait partie du trio d'outils parfait avec Git et Linux. Je compte continuer à l'utiliser sur mes projets actuels et futurs, en développement comme en production. Même si j'estime avoir une bonne maîtrise, je resterai attentif aux nouveautés et aux bonnes pratiques pour l'utiliser de façon toujours plus efficace et sûre.

Je compte également me former à Kubernetes, qui représente selon moi l'évolution logique après Docker pour le déploiement à grande échelle, notamment grâce à son gestionnaire de secrets et à ses fonctionnalités d'auto-scaling. Pour cela, je vais suivre des formations en ligne, lire la documentation officielle et expérimenter Kubernetes sur les trois serveurs de test que j'ai mis en place chez moi.