Techniques avancées du Dockerfile

Introduction

Dans ce laboratoire, nous approfondirons les techniques de Dockerfile en explorant des concepts avancés qui vous aideront à créer des images Docker plus efficaces et flexibles. Nous aborderons en détail les instructions Dockerfile, les builds multi-étapes et l'utilisation des fichiers.dockerignore. Nous explorerons également le concept crucial des couches (layers) dans les images Docker. À la fin de ce laboratoire, vous aurez une compréhension complète de ces techniques avancées de Dockerfile et pourrez les appliquer à vos propres projets.

Ce laboratoire est conçu pour les débutants, en fournissant des explications détaillées et en répondant aux points potentiellement sources de confusion. Nous utiliserons WebIDE (VS Code) pour toutes nos tâches d'édition de fichiers, ce qui facilitera la création et la modification de fichiers directement dans le navigateur.

Skills Graph

Comprendre les instructions et les couches (layers) du Dockerfile

Commençons par créer un Dockerfile qui utilise diverses instructions. Nous allons construire une image pour une application web Python utilisant Flask, et au passage, nous explorerons comment chaque instruction contribue aux couches de notre image Docker.

1. Tout d'abord, créons un nouveau répertoire pour notre projet. Dans le terminal de WebIDE, exécutez :

mkdir -p ~/project/advanced-dockerfile && cd ~/project/advanced-dockerfile

Cette commande crée un nouveau répertoire appelé advanced-dockerfile à l'intérieur du dossier project, puis se déplace dans ce répertoire.

2. Maintenant, créons notre fichier d'application. Dans l'explorateur de fichiers de WebIDE (généralement sur le côté gauche de l'écran), faites un clic droit sur le dossier advanced-dockerfile et sélectionnez "Nouveau fichier". Nommez ce fichier app.py.

3. Ouvrez app.py et ajoutez le code Python suivant :

from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def hello():
    return f"Hello from {os.environ.get('ENVIRONMENT', 'unknown')} environment!"

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

Il s'agit d'une simple application Flask qui répond avec un message de salutation, incluant l'environnement dans lequel elle s'exécute.

4. Ensuite, nous devons créer un fichier requirements.txt pour spécifier nos dépendances Python. Créez un nouveau fichier nommé requirements.txt dans le même répertoire et ajoutez le contenu suivant :

Flask==2.0.1
Werkzeug==2.0.1

Ici, nous spécifions des versions exactes pour Flask et Werkzeug afin d'assurer la compatibilité.

5. Maintenant, créons notre Dockerfile. Créez un nouveau fichier nommé Dockerfile (avec un 'D' majuscule) dans le même répertoire et ajoutez le contenu suivant :

## Use an official Python runtime as the base image
FROM python:3.9-slim

## Set the working directory in the container
WORKDIR /app

## Set an environment variable
ENV ENVIRONMENT=production

## Copy the requirements file into the container
COPY requirements.txt.

## Install the required packages
RUN pip install --no-cache-dir -r requirements.txt

## Copy the application code into the container
COPY app.py.

## Specify the command to run when the container starts
CMD ["python", "app.py"]

## Expose the port the app runs on
EXPOSE 5000

## Add labels for metadata
LABEL maintainer="Your Name <[email protected]>"
LABEL version="1.0"
LABEL description="Flask app demo for advanced Dockerfile techniques"

Maintenant, décomposons ces instructions et comprenons comment elles contribuent aux couches de notre image Docker :

• FROM python:3.9-slim : C'est toujours la première instruction. Elle spécifie l'image de base à partir de laquelle nous construisons. Cela crée la première couche de notre image, qui inclut le runtime Python.
• WORKDIR /app : Cela définit le répertoire de travail pour les instructions suivantes. Elle ne crée pas une nouvelle couche, mais affecte le comportement des instructions suivantes.
• ENV ENVIRONMENT=production : Cela définit une variable d'environnement. Les variables d'environnement ne créent pas de nouvelles couches, mais elles sont stockées dans les métadonnées de l'image.
• COPY requirements.txt. : Cela copie le fichier de dépendances de notre hôte dans l'image. Cela crée une nouvelle couche contenant uniquement ce fichier.
• RUN pip install --no-cache-dir -r requirements.txt : Cela exécute une commande dans le conteneur pendant le processus de construction. Elle installe nos dépendances Python. Cela crée une nouvelle couche qui contient tous les packages installés.
• COPY app.py. : Cela copie notre code d'application dans l'image, créant une autre couche.
• CMD ["python", "app.py"] : Cela spécifie la commande à exécuter lorsque le conteneur démarre. Elle ne crée pas de couche, mais définit la commande par défaut pour le conteneur.
• EXPOSE 5000 : En réalité, il s'agit simplement d'une forme de documentation. Elle indique à Docker que le conteneur écoutera sur ce port à l'exécution, mais ne publie pas réellement le port. Elle ne crée pas de couche.
• LABEL... : Ces instructions ajoutent des métadonnées à l'image. Comme les instructions ENV, elles ne créent pas de nouvelles couches mais sont stockées dans les métadonnées de l'image.

Chaque instruction RUN, COPY et ADD dans un Dockerfile crée une nouvelle couche. Les couches sont un concept fondamental dans Docker qui permet un stockage et un transfert efficaces des images. Lorsque vous apportez des modifications à votre Dockerfile et que vous reconstruisez l'image, Docker réutilisera les couches mises en cache qui n'ont pas changé, accélérant ainsi le processus de construction.

6. Maintenant que nous comprenons ce que fait notre Dockerfile, construisons l'image Docker. Dans le terminal, exécutez :

docker build -t advanced-flask-app.

Cette commande construit une nouvelle image Docker avec l'étiquette advanced-flask-app. Le . à la fin indique à Docker de chercher le Dockerfile dans le répertoire actuel.

Vous verrez une sortie montrant chaque étape du processus de construction. Remarquez comment chaque étape correspond à une instruction dans notre Dockerfile, et comment Docker mentionne "Using cache" pour les étapes qui n'ont pas changé si vous exécutez la commande de construction plusieurs fois.

7. Une fois la construction terminée, nous pouvons exécuter un conteneur basé sur notre nouvelle image :

docker run -d -p 5000:5000 --name flask-container advanced-flask-app

Cette commande effectue les opérations suivantes :

• -d exécute le conteneur en mode détaché (en arrière-plan)
• -p 5000:5000 mappe le port 5000 de votre hôte sur le port 5000 du conteneur
• --name flask-container donne un nom à notre nouveau conteneur
• advanced-flask-app est l'image que nous utilisons pour créer le conteneur

Vous pouvez vérifier que le conteneur est en cours d'exécution en vérifiant la liste des conteneurs en cours d'exécution :

docker ps

8. Pour tester si notre application fonctionne correctement, nous pouvons utiliser la commande curl :

curl http://localhost:5000

Vous devriez voir le message "Hello from production environment!"

Si vous avez des problèmes avec curl, vous pouvez également ouvrir un nouvel onglet de navigateur et visiter http://localhost:5000. Vous devriez voir le même message.

Si vous rencontrez des problèmes, vous pouvez vérifier les journaux du conteneur en utilisant :

docker logs flask-container

Cela vous montrera tous les messages d'erreur ou de sortie de votre application Flask.

Builds multi-étapes

Maintenant que nous comprenons les instructions de base du Dockerfile et les couches (layers), explorons une technique plus avancée : les builds multi-étapes. Les builds multi-étapes vous permettent d'utiliser plusieurs instructions FROM dans votre Dockerfile. Cela est particulièrement utile pour créer des images finales plus petites en copiant uniquement les artefacts nécessaires d'une étape à l'autre.

Modifions notre Dockerfile pour utiliser un build multi-étapes qui aboutit en réalité à une image plus petite :

1. Dans WebIDE, ouvrez le Dockerfile que nous avons créé précédemment.
2. Remplacez tout le contenu par le suivant :

## Build stage
FROM python:3.9-slim AS builder

WORKDIR /app

COPY requirements.txt.

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

## Final stage
FROM python:3.9-slim

WORKDIR /app

## Copy only the installed packages from the builder stage
COPY --from=builder /root/.local /root/.local
COPY app.py.

ENV PATH=/root/.local/bin:$PATH
ENV ENVIRONMENT=production

CMD ["python", "app.py"]

EXPOSE 5000

LABEL maintainer="Your Name <[email protected]>"
LABEL version="1.0"
LABEL description="Flask app demo with multi-stage build"

Analysons ce qui se passe dans ce Dockerfile multi-étapes :

1. Nous commençons par une étape builder :

   • Nous utilisons l'image Python 3.9-slim comme base pour garder les choses petites dès le départ.
   • Nous installons nos dépendances Python à cette étape en utilisant pip install --user. Cela installe les packages dans le répertoire personnel de l'utilisateur.

2. Ensuite, nous avons notre étape finale :

   • Nous repartons de zéro avec une autre image Python 3.9-slim.
   • Nous copions uniquement les packages installés de l'étape builder, plus précisément depuis /root/.local où pip install --user les a placés.
   • Nous copions notre code d'application.
   • Nous ajoutons le répertoire bin local au PATH afin que Python puisse trouver les packages installés.
   • Nous configurons le reste de notre conteneur (ENV, CMD, EXPOSE, LABEL) comme précédemment.

L'avantage clé ici est que notre image finale n'inclut aucun des outils de build ou des caches du processus d'installation de pip. Elle ne contient que les artefacts finaux nécessaires. Cela devrait aboutir à une image plus petite.

3. Construisons cette nouvelle image multi-étapes. Dans le terminal, exécutez :

docker build -t multi-stage-flask-app.

4. Une fois la construction terminée, comparons les tailles de nos deux images. Exécutez :

docker images | grep flask-app

multi-stage-flask-app         latest     7bdd1be2d1fb   10 seconds ago   129MB
advanced-flask-app            latest     c59d6fa303cc   10 minutes ago   136MB

Vous devriez maintenant voir que l'image multi-stage-flask-app est plus petite que l'image advanced-flask-app que nous avons construite précédemment.

5. Maintenant, exécutons un conteneur avec notre nouvelle image plus légère :

docker run -d -p 5001:5000 --name multi-stage-container multi-stage-flask-app

Notez que nous utilisons un port hôte différent (5001) pour éviter les conflits avec notre conteneur précédent.

6. Testez l'application :

curl http://localhost:5001

Vous devriez toujours voir le message "Hello from production environment!"

7. Pour mieux comprendre les différences entre nos images mono-étapes et multi-étapes, nous pouvons utiliser la commande docker history. Exécutez ces commandes :

docker history advanced-flask-app
docker history multi-stage-flask-app

Comparez les sorties. Vous devriez remarquer que le build multi-étapes a moins de couches et des tailles plus petites pour certaines couches.

Les builds multi-étapes sont une technique puissante pour créer des images Docker efficaces. Elles vous permettent d'utiliser des outils et des fichiers dans votre processus de build sans gonfler votre image finale. Cela est particulièrement utile pour les langages compilés ou les applications avec des processus de build complexes.

Dans ce cas, nous l'avons utilisé pour créer une image d'application Python plus petite en ne copiant que les packages installés nécessaires et le code d'application, laissant de côté tout artefact de build ou cache.

Utilisation du fichier.dockerignore

Lors de la construction d'une image Docker, Docker envoie tous les fichiers du répertoire au démon Docker. Si vous avez des fichiers volumineux qui ne sont pas nécessaires pour construire votre image, cela peut ralentir le processus de construction. Le fichier .dockerignore vous permet de spécifier les fichiers et les répertoires qui doivent être exclus lors de la construction d'une image Docker.

Créons un fichier .dockerignore et voyons comment il fonctionne :

1. Dans WebIDE, créez un nouveau fichier dans le répertoire advanced-dockerfile et nommez-le .dockerignore.
2. Ajoutez le contenu suivant au fichier .dockerignore :

**/.git
**/.gitignore
**/__pycache__
**/*.pyc
**/*.pyo
**/*.pyd
**/.Python
**/env
**/venv
**/ENV
**/env.bak
**/venv.bak

Analysons ce que ces motifs signifient :

• **/.git : Ignorez le répertoire .git et tout son contenu, où qu'il apparaisse dans la structure du répertoire.
• **/.gitignore : Ignorez les fichiers .gitignore.
• **/__pycache__ : Ignorez les répertoires de cache de Python.
• **/*.pyc, **/*.pyo, **/*.pyd : Ignorez les fichiers Python compilés.
• **/.Python : Ignorez les fichiers .Python (souvent créés par les environnements virtuels).
• **/env, **/venv, **/ENV : Ignorez les répertoires d'environnement virtuel.
• **/env.bak, **/venv.bak : Ignorez les copies de sauvegarde des répertoires d'environnement virtuel.

Le ** au début de chaque ligne signifie "dans n'importe quel répertoire".

3. Pour démontrer l'effet du fichier .dockerignore, créons quelques fichiers que nous souhaitons ignorer. Dans le terminal, exécutez :

mkdir venv
touch venv/ignore_me.txt
touch.gitignore

Ces commandes créent un répertoire venv avec un fichier à l'intérieur, et un fichier .gitignore. Ce sont des éléments courants dans les projets Python que nous ne souhaitons généralement pas inclure dans nos images Docker.

4. Maintenant, construisons à nouveau notre image :

docker build -t ignored-flask-app.

5. Pour vérifier que les fichiers ignorés n'ont pas été inclus dans le contexte de construction, nous pouvons utiliser la commande docker history :

docker history ignored-flask-app

Vous ne devriez voir aucune étape qui copie le répertoire venv ou le fichier .gitignore.

Le fichier .dockerignore est un outil puissant pour garder vos images Docker propres et votre processus de construction efficace. Il est particulièrement utile pour les projets plus importants où vous pourriez avoir de nombreux fichiers qui ne sont pas nécessaires dans l'image finale.

Instructions avancées pour les Dockerfile

Dans cette étape finale, nous allons explorer quelques instructions supplémentaires pour les Dockerfile et les meilleures pratiques qui peuvent aider à rendre vos images Docker plus sécurisées, maintenables et plus faciles à utiliser. Nous nous concentrerons également sur la résolution de problèmes et la vérification de chaque étape du processus.

1. Dans WebIDE, réouvrez le fichier Dockerfile.

2. Remplacez le contenu par le suivant :

## Build stage
FROM python:3.9-slim AS builder

WORKDIR /app

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

## Final stage
FROM python:3.9-slim

## Create a non-root user
RUN useradd -m appuser

## Install curl for healthcheck
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

WORKDIR /app

## Dynamically determine Python version and site-packages path
RUN PYTHON_VERSION=$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")') && \
    SITE_PACKAGES_PATH="/home/appuser/.local/lib/python${PYTHON_VERSION}/site-packages" && \
    mkdir -p "${SITE_PACKAGES_PATH}" && \
    chown -R appuser:appuser /home/appuser/.local

## Copy site-packages and binaries using the variable
COPY --from=builder /root/.local/lib/python3.9/site-packages "${SITE_PACKAGES_PATH}"
COPY --from=builder /root/.local/bin /home/appuser/.local/bin
COPY app.py.

ENV PATH=/home/appuser/.local/bin:$PATH
ENV ENVIRONMENT=production

## Set the user to run the application
USER appuser

## Use ENTRYPOINT with CMD
ENTRYPOINT ["python"]
CMD ["app.py"]

EXPOSE 5000

HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:5000/ || exit 1

ARG BUILD_VERSION
LABEL maintainer="Your Name <[email protected]>"
LABEL version="${BUILD_VERSION:-1.0}"
LABEL description="Flask app demo with advanced Dockerfile techniques"

Analysons les nouveaux concepts introduits dans ce Dockerfile :

• RUN useradd -m appuser : Cette commande crée un nouvel utilisateur nommé appuser dans le conteneur. Exécuter des applications en tant qu'utilisateur non-root est une bonne pratique de sécurité, car cela limite les dommages potentiels en cas de compromission de l'application. Le flag -m crée un répertoire personnel pour l'utilisateur.
• RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* : Cette commande installe le paquet curl, qui est nécessaire pour que l'instruction HEALTHCHECK fonctionne. Nous nettoyons également le cache apt pour réduire la taille de l'image.
• RUN PYTHON_VERSION=$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")') &&... : Cet ensemble de commandes détermine dynamiquement la version de Python dans le conteneur et crée le répertoire site-packages correct pour l'utilisateur appuser. Il définit également les bonnes permissions pour le répertoire local de l'utilisateur.
• COPY --from=builder /root/.local/lib/python3.9/site-packages "${SITE_PACKAGES_PATH}" : Cette instruction copie les paquets Python installés depuis l'étape builder vers le chemin site-packages déterminé dynamiquement dans l'image finale, garantissant que les paquets sont placés au bon endroit pour que l'utilisateur appuser puisse les utiliser.
• COPY --from=builder /root/.local/bin /home/appuser/.local/bin : Cette commande copie les scripts exécutables installés par pip (comme l'interface en ligne de commande de Flask, le cas échéant) depuis l'étape builder vers le répertoire bin local de l'utilisateur appuser.
• ENTRYPOINT ["python"] avec CMD ["app.py"] : Lorsqu'ils sont utilisés ensemble, ENTRYPOINT définit l'exécutable principal du conteneur (dans ce cas, python), et CMD fournit les arguments par défaut pour cet exécutable (app.py). Ce modèle offre de la flexibilité : les utilisateurs peuvent exécuter le conteneur et exécuter app.py par défaut, ou ils peuvent remplacer CMD pour exécuter d'autres scripts Python ou commandes.
• HEALTHCHECK : Cette instruction configure un contrôle d'intégrité pour le conteneur. Docker exécutera périodiquement la commande spécifiée (curl -f http://localhost:5000/) pour déterminer si le conteneur est en bonne santé. Les flags --interval=30s et --timeout=3s définissent respectivement l'intervalle de vérification et le délai d'attente. Si la commande curl échoue (renvoie un code de sortie non nul), le conteneur est considéré comme en mauvaise santé.
• ARG BUILD_VERSION : Cela définit un argument de construction nommé BUILD_VERSION. Les arguments de construction vous permettent de passer des valeurs dans l'image Docker au moment de la construction.
• LABEL version="${BUILD_VERSION:-1.0}" : Cela définit une étiquette nommée version sur l'image Docker. Il utilise l'argument de construction BUILD_VERSION. Si BUILD_VERSION est fourni lors de la construction, sa valeur sera utilisée ; sinon, il prend la valeur par défaut 1.0 (en utilisant la syntaxe de valeur par défaut :-).

3. Maintenant, construisons cette nouvelle image en spécifiant une version de construction :

docker build -t advanced-flask-app-v2 --build-arg BUILD_VERSION=2.0.

Le flag --build-arg BUILD_VERSION=2.0 nous permet de passer la valeur 2.0 pour l'argument de construction BUILD_VERSION lors du processus de construction de l'image. Cette valeur sera utilisée pour définir l'étiquette version dans l'image Docker.

4. Une fois la construction terminée, vérifions que l'image a été créée avec succès :

docker images | grep advanced-flask-app-v2

Vous devriez voir la nouvelle image advanced-flask-app-v2 répertoriée dans la sortie de la commande docker images, ainsi que son étiquette, son ID d'image, sa date de création et sa taille.

5. Maintenant, exécutons un conteneur avec la nouvelle image :

docker run -d -p 5002:5000 --name advanced-container-v2 advanced-flask-app-v2

Cette commande exécute un conteneur en mode détaché (-d), mappe le port 5002 de votre hôte sur le port 5000 du conteneur (-p 5002:5000), nomme le conteneur advanced-container-v2 (--name advanced-container-v2) et utilise l'image advanced-flask-app-v2 pour créer le conteneur.

6. Vérifions que le conteneur est en cours d'exécution :

docker ps | grep advanced-container-v2

Si le conteneur s'exécute avec succès, vous devriez le voir répertorié dans la sortie de la commande docker ps. Si vous ne voyez pas le conteneur répertorié, il peut avoir été arrêté. Vérifions s'il y a des conteneurs arrêtés :

docker ps -a | grep advanced-container-v2

Si vous voyez le conteneur répertorié dans la sortie de docker ps -a mais qu'il n'est pas en cours d'exécution (le statut n'est pas "Up"), nous pouvons vérifier ses journaux pour détecter les erreurs :

docker logs advanced-container-v2

Cette commande affichera les journaux du conteneur advanced-container-v2, ce qui peut aider à diagnostiquer les problèmes de démarrage ou les erreurs d'exécution de votre application Flask.

7. En supposant que le conteneur soit en cours d'exécution, après avoir laissé un peu de temps au conteneur pour démarrer, nous pouvons vérifier son statut de santé :

docker inspect --format='{{.State.Health.Status}}' advanced-container-v2

Après un court délai (pour permettre au contrôle d'intégrité de s'exécuter au moins une fois), vous devriez voir "healthy" comme sortie. Si vous voyez "unhealthy" au départ, attendez 30 secondes supplémentaires (l'intervalle de contrôle d'intégrité) et exécutez à nouveau la commande. Si le statut reste "unhealthy", vérifiez les journaux du conteneur en utilisant docker logs advanced-container-v2 pour détecter d'éventuels problèmes avec votre application Flask. Si il n'y a pas de problèmes évidents, vous pouvez ignorer le statut "unhealthy".

8. Nous pouvons également vérifier que l'étiquette de version de construction a été correctement appliquée :

docker inspect -f '{{.Config.Labels.version}}' advanced-flask-app-v2

Cette commande récupère la valeur de l'étiquette version de l'image advanced-flask-app-v2 et l'affiche. Vous devriez voir "2.0" comme sortie, ce qui confirme que l'argument de construction BUILD_VERSION a été correctement utilisé pour définir l'étiquette.

9. Enfin, testons notre application en lui envoyant une requête :

curl http://localhost:5002

Vous devriez voir le message "Hello from production environment!" dans la sortie. Cela indique que votre application Flask s'exécute correctement à l'intérieur du conteneur Docker et est accessible sur le port 5002 de votre hôte.

Ces techniques avancées vous permettent de créer des images Docker plus sécurisées, configurables et prêtes pour la production. L'utilisation d'un utilisateur non-root améliore la sécurité, le HEALTHCHECK facilite l'orchestration et la surveillance des conteneurs, et les arguments de construction permettent de construire des images plus flexibles et versionnées.

Résumé

Dans ce laboratoire, nous avons exploré des techniques avancées de Dockerfile qui vous aideront à créer des images Docker plus efficaces, sécurisées et maintenables. Nous avons couvert les points suivants :

1. Instructions détaillées du Dockerfile et leur impact sur les couches (layers) de l'image : Nous avons appris comment chaque instruction contribue à la structure de notre image Docker, et comment la compréhension des couches peut nous aider à optimiser nos images.
2. Builds multi-étapes : Nous avons utilisé cette technique pour créer des images finales plus petites en séparant notre environnement de build de notre environnement d'exécution.
3. Utilisation des fichiers.dockerignore : Nous avons appris à exclure les fichiers inutiles du contexte de build, ce qui peut accélérer les builds et réduire la taille des images.
4. Instructions avancées du Dockerfile : Nous avons exploré des instructions supplémentaires telles que USER, ENTRYPOINT, HEALTHCHECK et ARG, qui nous permettent de créer des images plus sécurisées et flexibles.

Ces techniques vous permettent de :

• Créer des images Docker plus optimisées et plus petites
• Améliorer la sécurité en exécutant les applications en tant qu'utilisateurs non-root
• Mettre en œuvre des contrôles d'intégrité pour une meilleure orchestration des conteneurs
• Utiliser des variables au moment de la construction pour une construction d'images plus flexible

Tout au long de ce laboratoire, nous avons utilisé WebIDE (VS Code) pour éditer nos fichiers, ce qui a facilité la création et la modification des Dockerfiles et du code d'application directement dans le navigateur. Cette approche permet une expérience de développement fluide lorsque vous travaillez avec Docker.