Créer une image avec un fichier Dockerfile

Ici, vous créez une image à partir d’une application Flask et la testez avec docker run. Vous avez terminé lorsque l’application répond et que vous avez vérifié que le fichier local .env est exclu de la nouvelle image. L’application de test ne nécessite ni GitHub ni une API externe.

Avant de construire

Vous devez créer une image et vérifier qu’un conteneur issu de cette image répond correctement. Vous avez besoin de Docker installé et savoir démarrer et inspecter un conteneur, comme indiqué dans Exécution et inspection d’un conteneur. Si vous n’avez pas d’application Flask, utilisez l’application de test ci-dessous. Travaillez dans le dossier projet sur la machine virtuelle Linux, où se trouvent à la fois app.py, les éventuels modèles et autres fichiers du projet.

Si le projet est situé dans un dépôt de code, Git dans le terminal montre comment le cloner vers la machine virtuelle. Vous pouvez également créer les fichiers dans l’éditeur de texte de la machine virtuelle. Utilisez pwd et ls pour vérifier que vous êtes dans le bon dossier. Ne construisez pas depuis un dossier vide ou depuis le shell de l’hôte Proxmox.

from flask import Flask
app = Flask(__name__)

@app.route("/")
def index():
    return "Bonjour depuis le conteneur !"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Créez le fichier requirements.txt dans le même dossier. Il répertorie les paquets Python à installer dans l’image. Pour la simple application de Flask 1, qui n’utilise que Flask, le contenu est :

Flask

Si l’application utilise d’autres bibliothèques tierces, elles doivent également y être listées avec leurs noms corrects, par exemple requests. Les fichiers tels que .venv ne sont pas copiés pour installer les paquets ; Docker les réinstalle à partir de cette liste. Les versions peuvent être verrouillées, par exemple avec nom_du_paquet==version, une fois que vous avez vérifié quelles versions votre application utilise.

Créez également un fichier .dockerignore avant la première construction. Il empêche la copie dans l’image des secrets locaux, de l’historique Git et de l’environnement Python local :

.env
.git
__pycache__/
.venv/
app-data/

Ajoutez également .env à .gitignore si vous utilisez Git. Si les fichiers d’ignorance contiennent déjà des éléments, ajoutez les règles manquantes au lieu de remplacer les fichiers. Utilisez [[Git dans le terminal Niveau 5 - gitignore et secrets|.gitignore et les secrets`] pour contrôler le suivi avant de partager votre code.

Créer une image avec un fichier Dockerfile

docker build crée le paquet. docker run crée et démarre un conteneur à partir du paquet. La construction seule ne démarre pas l’application. Consultez [[Niveau 0 de Docker - Qu’est-ce que Docker ?|Niveau 0]] si vous devez distinguer à nouveau une image d’un conteneur.

Un fichier Dockerfile décrit les étapes qu’utilisera Docker pour construire une image. Chaque ligne effectue quelque chose de spécifique :

The provided Dockerfile contains no comments to translate. The code remains unchanged as per your instructions.

FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 5000
CMD ["python", "app.py"]

Docker exécute la construction par étapes. Les instructions COPY et RUN peuvent ajouter des couches au système de fichiers, tandis que notamment CMD décrit comment le conteneur doit être démarré. Docker peut réutiliser les résultats de constructions précédents depuis un cache intermédiaire (cache de build). Lorsqu’une étape doit être reconstruite, les étapes suivantes doivent également être exécutées à nouveau.

C’est pourquoi nous copions uniquement requirements.txt avant COPY . . : l’installation fastidieuse est effectuée avant le code source, qui change fréquemment :

flowchart TB
    L1["Image de base : python:3.12-slim"] --> L2["Dossier de travail : /app"]
    L2 --> L3["Copier requirements.txt"]
    L3 --> L4["Installer les paquets avec pip"]
    L4 --> L5["Copier le code source"]

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

Si requirements.txt est modifié, Docker doit réinstaller les paquets. C’est souhaitable : le nouveau paquet doit bien être inclus dans l’image. Si seul le code source change, Docker peut utiliser la couche d’installation existante et continuer à construire depuis COPY . ..

Lorsque Docker publie un port, il achemine le trafic vers le programme au sein du conteneur. Le programme doit donc écouter sur le réseau du conteneur, pas uniquement sur 127.0.0.1, qui signifie « ce conteneur ». Si le programme n’écoute que sur 127.0.0.1, les autres machines ne peuvent pas y accéder via le port publié par Docker.

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000, debug=False)

Ceci est un environnement de développement utilisant le serveur de développement Flask. Avant d’être utilisée en production, l’application doit être exécutée avec un serveur WSGI approprié ; voir Flask : configuration pour la production.

EXPOSE 5000 décrit le port utilisé par l’application ; il ne publie pas le port à lui seul. C’est ce que fait -p 127.0.0.1:5000:5000 dans la commande ci-dessous. Construire et démarrer :

docker build -t min-app:latest .
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app:latest
docker logs -f min-app

Appuyez sur Ctrl+C pour arrêter l’affichage du journal (log). Le conteneur continue de s’exécuter.

Test depuis la machine virtuelle elle-même :

curl http://127.0.0.1:5000

Vous devriez obtenir le contenu de la route principale de l’application. Dans -p 127.0.0.1:5000:5000, 127.0.0.1:5000 signifie le port 5000 sur le serveur, mais uniquement pour les programmes situés sur le serveur lui-même. Le dernier nombre est le port à l’intérieur du conteneur. Si cela ne fonctionne pas, vérifiez d’abord docker ps, les journaux et que le port soit correctement publié.

Avec 127.0.0.1 en préfixe, le port est fermé au réseau, donc aucune autre machine ne peut accéder à l’application pendant que vous développez et testez. C’est une norme sûre pour une application en développement. Sans 127.0.0.1 (-p 5000:5000), le port écoute sur toutes les interfaces réseau du serveur. Vous n’en avez besoin qu’une fois qu’une autre machine ou un proxy doit accéder à l’application, dans Level 3.

Point de contrôle : L’image fonctionne

La commande curl http://127.0.0.1:5000 doit afficher la page d’accueil de l’application. Pour l’application de test, la réponse est Bonjour depuis le conteneur !. Expliquez ce que docker build a créé et ce que docker run a démarré. En cas d’erreur, consultez les journaux avant de continuer.

Vérifier que .env est exclu

Vous n’avez pas besoin d’une vraie clé pour vérifier cela. Si le projet ne dispose déjà pas de fichier .env, vous pouvez le créer avec PIGGY_TEST=valeur_de_test_inoffensive. Conservez un fichier existant ; n’écrasez pas vos valeurs.

1. Assurez-vous que .env figure à la fois dans .dockerignore et .gitignore.
2. Utilisez-vous Git ? Exécutez les vérifications de l’exercice [[Git dans le terminal Niveau 5 - gitignore et secrets|de l’exercice sur .gitignore]]. Un fichier ignoré ne doit également pas avoir été suivi auparavant.
3. Reconstruisez l’image et vérifiez ce chemin de fichier sans afficher son contenu :

docker build -t min-app:latest .
docker run --rm --entrypoint sh min-app:latest -c 'test ! -e /app/.env && echo ".env n'existe pas dans /app"'

Le résultat attendu est « .env n’existe pas dans /app ». Si le message ne s’affiche pas, vérifiez le fichier d’ignorance avant de partager l’image. Cela contrôle le chemin de fichier dans le système de fichiers final de la nouvelle image. Il ne met à jour ni les anciennes images, ni d’autres fichiers secrets, ou des valeurs écrites directement dans le code ou le Dockerfile. Remplacez d’abord une vraie clé si elle a été partagée auparavant.

En cas d’échec de la construction ou de l’application

En cas de ModuleNotFoundError, vérifiez requirements.txt et reconstruisez. Pour les erreurs lors du téléchargement de l’image de base ou des paquets Python, testez le réseau avec [[Feilsokingsmetode Level 1 - Systematisk feilsiking|Méthode de dépannage]]. Si aucune réponse HTTP n’est reçue, consultez docker logs min-app et vérifiez l’adresse Flask ainsi que le mappage des ports.

Étapes suivantes

Affichez la réponse de l’application et vérifiez le fichier .env. Expliquez ce que décrit le Dockerfile, ce qui est créé lors de la construction, et ce qu’il se passe avec docker run. Poursuivez avec Docker - Publier une application. Si vous souhaitez décrire le démarrage et les mises à jour dans un fichier Compose, Exécuter et mettre à jour l’application avec Compose constitue une approfondissement facultatif.

Compose et la mise à jour sont désormais traités dans Exécuter et mettre à jour l’application avec Compose.

Le stockage est expliqué dans Conserver des données hors du conteneur; l’utilisation de Compose figure dans Exécuter et mettre à jour l’application avec Compose.

La procédure d’API se trouve maintenant dans Variable d’environnement et clé API et est facultative.