No description
Find a file
2025-10-16 15:41:40 +02:00
src feat: first version 2025-10-09 15:20:30 +02:00
.gitignore feat: first version 2025-10-09 15:20:30 +02:00
Containerfile feat: first version 2025-10-09 15:20:30 +02:00
Containerfile_multi feat: first version 2025-10-09 15:20:30 +02:00
README.md fix: readme 2025-10-16 15:41:40 +02:00
requirements-dev.txt feat: first version 2025-10-09 15:20:30 +02:00
requirements.txt feat: first version 2025-10-09 15:20:30 +02:00

I - Conteneurisation avec Docker

Ce projet contient une application simple en python que nous voulons conteneuriser dans le but de la publier.

L'application python peut-être lancée indépendemment via les commandes suivantes (qu'il est conseillé de lancer dans un environnement virtuel (virtualenv) python) :

cd src
pip install -r requiremenst-dev.txt
fastapi dev src/main.py

La page web servie par l'application est alors disponible à l'adresse suivante : http://127.0.0.1:8000.

1. Conteneur simple

Le fichier Containerfile permet de construire une première image pour publier cette application. Celle-ci est basée sur une image publique python, et peut être construite ainsi :

docker buildx build -t demofastapi:simple -f ./Containerfile .

Une fois l'image construite, on peut lancer l'application via :

docker run --rm -p 8001:8000 demofastapi:simple

L'application est alors accessible à l'adresse suivante : http://127.0.0.1:8001/.

Cette façon de construire est suffisante pour un projet simple, il faut cependant faire attention à l'ordre des instructions dans le Containerfile en ayant conscience de leur impact sur les layers de l'image finale.

2. Conteneur multi-stage

Le fichier Contanierfile_multi permet de construire une autre image avec cette même application, cette fois en se basant sur une image publique Debian. Le fichier est découpé en trois image, ou trois stages :

  • Le premier permet de compiler et installer python, mais a le désavantage de contenir énormément d'outils de compilations qu'on ne désire pas dans l'image finale (par souci de place mais aussi de sécurité) ;
  • Le second permet de récupérer uniquement le résultat de l'insallation depuis l'image précédente ;
  • Le troisième reprend la seconde image mais limite les possibilités de l'image une fois lancée.

Il n'est pas nécessaire de construire le premier stage, mais les deux suivants peuvent être construits ainsi :

docker buildx build -t demofastapi:release -f ./Containerfile_multi --target release_stage .
docker buildx build -t demofastapi:secure -f ./Containerfile_multi --target secure_stage .

Dans chacune de ses commandes, l'option --target permet de choisir quel stage est visé par la commande.

Les deux images permettent de servir l'application, via les commandes suivantes :

docker run --rm -p 8002:8000 demofastapi:release
docker run --rm -p 8003:8000 demofastapi:secure

Et les pages web respectives sont disponibles aux adresses http://127.0.0.1:8002/ et http://127.0.0.1:8003/.

Cette façon de construire les images est plus adaptée si vous ne faites pas confiance aux images python publiques, ou si vous voulez partir d'une image que vous utilisez déjà pour d'autres projets (par exemple une image qui a déjà été hardennée dans votre entreprise).

3. Pour aller plus loin

Pour aller plus loin dans la construction et la sécurisation des images docker :

  • l'ANSSI propose des recommandations sur la publication d'application conteneurisées ;
  • La communauté CIS propose des benchmarks complets sur la sécurisation d'OS et du démon Docker ;
  • Docker a implémenté un audit basé sur le benchmark CIS pour le démon Docker.