Une seule image Docker pour la production et les devcontainers - la méthode propre

Cet article est le fruit d'une intense réflexion : comment définir une image Docker destinée au déploiement en production de la manière la plus propre possible et, tout en évitant au maximum les copier/coller et autres répétitions, créer une image pour le développement en devcontainer.

Autrement dit : je veux créer l'image la plus légère et la plus sécurisée possible pour le déploiement en production, mais je dois évidemment pouvoir développer cette image dans mon environnement VSCode. Et pour cela, il me faut mes outils de développement, un utilisateur Linux spécifique pour synchroniser les fichiers avec mon host et éviter les problèmes de permissions, etc.

Après plusieurs tentatives, voici ce à quoi je suis arrivé, et qui semble répondre à ce besoin.

Que signifie une séparation parfaite des environnements ?​

Notre premier réflexe devrait toujours être : avons-nous besoin de ceci (utilitaire, configuration, utilisateur, etc.) dans l'image Docker que nous allons déployer sur le serveur ?

Quelques exemples :

• Les outils de développement tels qu'un linter, un formateur, un outil de qualité de code, un débogueur, etc. n'ont pas leur place dans l'image qui sera déployée.
• La création d'un utilisateur qui permettra la synchronisation des fichiers avec l'host n'a pas sa place dans l'image qui sera déployée.
• ...

Notre image doit être propre, aussi efficace et légère que possible... Nous devons minimiser ce qu'on appelle la « surface d'attaque », c'est-à-dire réduire le nombre d'outils installés afin de réduire les risques de sécurité.

Tout ce dont nous avons besoin pour notre développement devra donc faire partie d'une seconde image Docker, celle que nous utiliserons quand nous activerons la fonctionnalité devcontainer dans VSCode. C'est là que nous créerons notre utilisateur, ajouterons les outils de développement et activerons certaines configurations comme le débogage, etc. Si vous n'en avez jamais mis en place, le développement PHP dans un devcontainer avec des outils de qualité de code préinstallés détaille un devcontainer complet, de zéro.

Le résultat​

Un seul Dockerfile, pas de copier-coller, et les deux images se construisent à partir exactement des mêmes instructions : un container de production minimal et rootless, et un devcontainer qui l'étend avec les outils nécessaires au développement.

Voici le container de production qui répond sur http://localhost:8000 :

Les étapes ci-dessous construisent exactement cela, à partir d'un dossier vide, puis l'étendent en devcontainer.

Étape 1 - Créer l'image Docker de production​

Créez un nouveau dossier dans votre dossier temporaire pour notre exemple.

$ mkdir -p /tmp/docker-prod-devcontainer && cd $_▋

Créons nos fichiers de production​

Créons quelques fichiers (rappelez-vous, pour l'image Docker de production).

Le fichier .env de production​

Pour cet article, nous allons créer un script Python : il faudra donc préciser la version de Python souhaitée.

C'est juste pour l'exemple mais, dans votre cas, ce .env servira à y placer tous les paramètres que vous voulez pour votre propre image de production.

Donc, même si vous ne voyez pas encore pourquoi utiliser ce fichier dans votre cas, gardez-le, même si vous n'avez aucune variable à y mettre.

APP_HOME="/app"
PYTHON_VERSION=3.13?
TIMEZONE="Europe/Brussels"?

Le fichier Dockerfile de production​

Le fichier fourni est un exemple réutilisable. Dans cet article, à titre d'exemple, nous allons créer un petit script Python pour illustrer certaines choses.

# cspell:disable

# Production Dockerfile

ARG DOCKER_APP_HOME="/app"?
ARG PYTHON_VERSION=3.13?
ARG TIMEZONE="Europe/Brussels"

FROM python:${PYTHON_VERSION}-slim?

ARG TIMEZONE?

ENV TZ=${TIMEZONE}?

RUN --mount=type=cache,target=/var/cache/apt,rw \?
    set -eux \?
    && printf "\e[0;105m%s\e[0;0m\n" "Install required Linux binaries..." \
    && apt-get update -yqq \
    && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
        locales \
        tini \
    && echo "en_US.UTF-8 UTF-8" > /etc/locale.gen \
    && locale-gen en_US.UTF-8 \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

ENV LANG=en_US.UTF-8 \
    LANGUAGE=en_US:en \
    LC_ALL=en_US.UTF-8

ARG DOCKER_APP_HOME

WORKDIR "${DOCKER_APP_HOME}"

COPY requirements.txt .

RUN --mount=type=cache,target=/root/.cache/pip \?
    set -eux \
    && printf "\e[0;105m%s\e[0;0m\n" "Install Python prod dependencies..." \
    && pip install -r requirements.txt

# Make sure installed dependencies are in the PATH
ENV PATH="/root/.local/bin:$PATH"

COPY . .

ENTRYPOINT ["/usr/bin/tini", "--"]?

ENV PYTHONPATH="${DOCKER_APP_HOME}/src"?

CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "--worker-class", "uvicorn.workers.UvicornWorker", "main:app"]?

Regardez le script fourni :

Le fichier compose.yaml de production​

Le fichier compose.yaml est utilisé par Docker compose (qui fait partie de Docker) pour savoir comment construire votre image et comment créer votre container.

C'est un fichier très important puisque nous y définirons toutes les configurations requises, nous y spécifierons notre fichier .env pour que Docker puisse traduire les variables en valeurs, ...

Nous dirons aussi à Docker quel port du container en cours d'exécution doit être partagé avec notre host, ...

name: my_sample

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:?
        - DOCKER_APP_HOME=${APP_HOME:-/app}?
        - PYTHON_VERSION=${PYTHON_VERSION:-3.13}
        - TIMEZONE=${TIMEZONE:-Europe/Brussels}
    image: my_sample_prod:latest
    container_name: app
    env_file: .env
    ports:
      - "8000:8000"?
    user: "1001:1001"?
    security_opt:
      - no-new-privileges:true?

Le fichier requirements Python de production​

Nous avons vu une mention de ce fichier dans notre Dockerfile : comme nous utilisons Python comme exemple pour ce billet, nous avons besoin d'un fichier requirements.txt pour déclarer les dépendances dont notre script a besoin. Dans notre exemple, il nous faut les dépendances FastAPI :

fastapi
gunicorn
uvicorn[standard]

Si votre cas d'usage n'est pas un script Python, vous ne devez évidemment pas créer ce fichier requirements.txt (mais, dans ce cas, mettez aussi à jour le Dockerfile et supprimez cette partie).

Le script Python de production​

Et enfin, pour la démo, nous allons créer un script Python FastAPI qui renverra une simple réponse JSON ; assez direct :

from fastapi import FastAPI

app = FastAPI()?

@app.get("/")?
def read_root():
    return {"message": "Hello, FastAPI - PRODUCTION!"}?

Récapitulatif des fichiers de production​

À ce stade, notre projet ressemble à ceci, soit cinq fichiers.

Création de l'image Docker de production​

Ouvrez une console Linux et exécutez la commande ci-dessous pour voir si tout va bien, c'est-à-dire s'il n'y a pas d'erreur et si, par exemple, notre fichier .env où nous avons spécifié la version de Python est bien récupéré et utilisé.

$ docker compose config▋

Vous obtiendrez quelque chose comme ceci :

name: my_sample
services:
  app:
    build:
      context: /tmp/docker-prod-devcontainer?
      dockerfile: Dockerfile
      args:?
        APP_HOME: /ap
        PYTHON_VERSION: "3.13"
        TIMEZONE: Europe/Brussels
    container_name: app
    environment:?
      APP_HOME: /ap
      PYTHON_VERSION: "3.13"
      TIMEZONE: Europe/Brussels
    image: my_sample_prod:latest
    networks:
      default: null?
    ports:
      - mode: ingress?
        target: 8000
        published: "8000"
        protocol: tcp
    security_opt:
      - no-new-privileges:true
    user: 1001:1001?
networks:
  default:
    name: my_sample_default

Maintenant, nous allons construire et créer le container en exécutant la commande ci-dessous.

$ docker compose build▋

Lancer un container de production​

Nous pouvons maintenant créer un container si nous le souhaitons, en exécutant la commande ci-dessous :

$ docker compose up --detach▋

Comme notre projet de démo est une application Python FastAPI, lancez simplement un navigateur et allez à l'adresse http://localhost:8000 pour voir le message de FastAPI. La sortie est au format JSON :

Et, pour être sûr, vérifions qui est l'utilisateur courant en PROD​

Optionnel : exécutons une commande paramétrée dans le container pour voir qui est l'utilisateur courant :

$ docker compose exec app /bin/sh -c 'echo "Container user ID is $(id -u) and his group ID is $(id -g)"'
Container user ID is 1001 and his group ID is 1001▋

Ceci, juste pour confirmer : lors de l'exécution de notre container, celui-ci tournera avec un utilisateur non privilégié grâce à notre fichier d'orchestration compose.yaml.

Étape 2 - Override (ou extension) de l'image de production pour obtenir une image prête pour le devcontainer​

Créons nos fichiers devcontainer​

Créez maintenant un sous-dossier appelé .devcontainer avec les fichiers ci-dessous.

Le fichier .devcontainer/.env​

Au cas où nous aurions besoin d'éléments de configuration supplémentaires, créons le fichier .devcontainer/.env (même vide).

Le fichier .devcontainer/Dockerfile​

L'un des fichiers les plus importants est le .devcontainer/Dockerfile, où nous ajouterons des éléments supplémentaires (dépendances Linux, bibliothèques Python, ...) pour nous offrir une meilleure expérience de développement.

# syntax=docker/dockerfile:1.6?

# .devcontainer/Dockerfile

ARG OS_USERID=1000?
ARG OS_GROUPID=1000
ARG OS_USERNAME="vscode"
ARG DOCKER_APP_HOME="/app"

FROM my_sample_prod:latest

ENV PYTHONDONTWRITEBYTECODE=1 \?
    PYTHONUNBUFFERED=1

USER root

#! If you get an error during the execution of this block, make sure the "my_sample_prod"
#! image isn't running with a non-root user. It should be "root". Rebuild the image to be sure.
RUN --mount=type=cache,target=/var/cache/apt,rw \?
    set -eux \?
    && printf "\e[0;105m%s\e[0;0m\n" "Install required Linux binaries for devcontainer..." \
    && apt-get update -yqq \
    && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
        bash \
        bash-completion \
        git \
        curl \
        ca-certificates \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# --- Create non-root user ---

ARG OS_USERID
ARG OS_GROUPID
ARG OS_USERNAME

RUN set -eux \
    && if ! id -u "${OS_USERNAME}" >/dev/null 2>&1; then \?
        printf "\e[0;105m%s\e[0;0m\n" "Create devcontainer user ${OS_USERNAME} (${OS_USERID}:${OS_GROUPID})..." \
        && groupadd -g ${OS_GROUPID} "${OS_USERNAME}" \
        && useradd -u ${OS_USERID} -g ${OS_GROUPID} -m --shell /bin/bash --create-home "${OS_USERNAME}" \
        && chown -R "${OS_USERNAME}":"${OS_USERNAME}" "/home/${OS_USERNAME}"; \?
    fi

# Ensure vscode home folders exist and are writable. The .vscode-server folder is used by
# VSCode while installing extensions in the container. That folder has to be owner by our user; not root.
RUN set -eux \
    && mkdir -p "/home/${OS_USERNAME}/.vscode-server/bin" \?
    && mkdir -p "/home/${OS_USERNAME}/.vscode-server/extensions" \
    && mkdir -p "/home/${OS_USERNAME}/.vscode-server/data" \
    && chown -R "${OS_USERNAME}":"${OS_USERNAME}" "/home/${OS_USERNAME}/.vscode-server"

# ---------- Shell and history setup -----------------------------------------
# Configure bash to use this file
RUN echo "export HISTFILE=/home/${OS_USERNAME}/.bash_history" >> "/home/${OS_USERNAME}/.bashrc" && \?
    echo 'export HISTSIZE=10000' >> "/home/${OS_USERNAME}/.bashrc" && \
    echo 'export HISTFILESIZE=10000' >> "/home/${OS_USERNAME}/.bashrc" && \
    echo 'shopt -s histappend' >> "/home/${OS_USERNAME}/.bashrc"

# Set up the shell prompt
RUN set -eux && \?
    echo "PS1='\n\e[0;33m🐳 \e[0;36m\$(whoami)\e[0m \w # '" >> "/home/${OS_USERNAME}/.bashrc"

# Welcome message and tips (make sure the message isn't yet in the file)
RUN set -eux; \
    BASHRC="/home/${OS_USERNAME}/.bashrc"; \?
    MARKER="# DEV CONTAINER WELCOME MESSAGE"; \
    grep -qxF "$MARKER" "$BASHRC" || cat <<EOF >> "$BASHRC"?
$MARKER
echo -e "\n📘 Welcome to the Dev Container!"
echo -e "Below are some useful commands:"
echo -e ""
echo -e "  ✨ \e[32mpython -m debugpy --listen 0.0.0.0:5679 -m uvicorn main:app --host 0.0.0.0 --port 8000 --reload\e[0m  Start a hot-reloading preview in your browser."
EOF

ARG DOCKER_APP_HOME

# Important: in the production image, the folder "DOCKER_APP_HOME" (/app most probably) is
# owned by the root user. Here, for the devcontainer, the folder has to be owned by our
# current user.
RUN set -eux \
    && chown -R "${OS_USERNAME}":"${OS_USERNAME}" "${DOCKER_APP_HOME}"

USER "${OS_USERNAME}"

COPY requirements.txt .

RUN --mount=type=cache,target=/home/${OS_USERNAME}/.cache/pip \?
    set -eux \
    && cat requirements.txt \?
    && printf "\e[0;105m%s\e[0;0m\n" "Install Python dev dependencies..." \
    && python -m pip install -r requirements.txt

WORKDIR "${DOCKER_APP_HOME}"?

Regardez le script fourni encore une fois :

Cette dernière étape n'est donc nécessaire que pour illustrer ce billet. Utilisez les vôtres.

Le fichier .devcontainer/requirements.txt​

Ce petit fichier est là uniquement à titre d'illustration. Dans ce billet, nous créons une petite application Python FastAPI et, dans le .devcontainer/requirements.txt, nous ajouterons quelques dépendances Python supplémentaires pour le dev, comme l'installation de l'outil Debugpy, c'est-à-dire le débogueur Python de Microsoft.

debugpy

Bien sûr, si votre projet n'est pas en Python, ce fichier peut être supprimé et, dans ce cas, supprimez aussi les lignes associées du .devcontainer/Dockerfile.

Le fichier .devcontainer/compose.yaml​

Comme pour l'image de production, nous devons ici dire à Docker comment l'image doit être construite et comment le container (celui de dev) doit être créé.

services:
  app:
    build:
      context: ./.devcontainer
      dockerfile: Dockerfile
      args:
        - DOCKER_APP_HOME=${APP_HOME:-/app}?
        - OS_USERID=${LOCAL_UID:-1000}?
        - OS_GROUPID=${LOCAL_GID:-1000}
        - OS_USERNAME=${LOCAL_USER:-vscode}
    container_name: my_sample_devcontainer_app
    ports:
      - 5679:5679  # Debugpy port
    env_file:
      - .env
      - .devcontainer/.env
    volumes:
      - .:${APP_HOME:-/app}?
      - vscode-extensions:/home/${LOCAL_USER:-vscode}/.vscode-server/extensions?
      - ./.devcontainer/history/.bash_history:/home/${LOCAL_USER:-vscode}/.bash_history:rw?

    command: sleep infinity?

volumes:
  vscode-extensions:

Si vous regardez ce fichier .devcontainer/compose.yaml, nous configurons plusieurs choses :

• La liste des arguments de build (args) doit mentionner l'id utilisateur, l'id de groupe et le nom de notre utilisateur. C'est important : quand nous travaillerons dans le devcontainer, tous les fichiers créés dans le container appartiendront à cet utilisateur spécifique. Si nous utilisons johndoe avec 1001 pour l'id utilisateur et l'id de groupe, les fichiers seront synchronisés ainsi sur votre host ; appartenant à johndoe, pas à vous. Si vous êtes l'utilisateur 1000:1000 localement, vous comprenez que les fichiers ne seront pas les vôtres et que vous aurez des problèmes de permissions. C'est quelque chose à éviter. Pour cela, nous devons configurer correctement le fichier .devcontainer/compose.yaml.

Regardez la syntaxe : ${LOCAL_UID:-1000}. Par défaut, le fichier assignera 1000 (qui est souvent le bon ID). Mais d'abord, Docker vérifiera si une variable appelée LOCAL_UID existe sur l'host. Si c'est le cas, cette valeur sera utilisée. Donc, si l'exécution de id -u (ou id -g pour l'id de groupe) ne donne pas 1000 sur votre host, veillez à créer la variable LOCAL_UID ou LOCAL_GID dans votre fichier .bashrc et à leur assigner la bonne valeur.

• Comme notre exemple porte sur Python, nous exposons aussi le port standard de DebugPy grâce à la ligne 5679:5679 pour que, au démarrage d'une session de débogage, le container fonctionne.

• Nous référençons aussi deux fichiers .env, celui du dossier racine (utilisé pour l'image Docker PROD) et celui du dossier .devcontainer

• Nous ajoutons quelques volumes :

  • .:${APP_HOME:-/app} montera (= partagera) les fichiers de notre projet (dans VSCode) avec le dossier ${APP_HOME:-/app}, c'est-à-dire là où les fichiers sont stockés dans l'image Docker PROD. Ainsi, les fichiers déjà copiés dans l'image Docker PROD seront simplement écrasés par ceux de notre session de dev (=> c'est là que la magie opère)
  • Nous demandons aussi à Docker de créer un volume auto-géré pour les vscode-extensions. Grâce à cette ligne, la première fois que nous créerons le devcontainer, VSCode installera les extensions mais, la fois suivante, grâce à cette ligne, VSCode ne les réinstallera pas, elles sont déjà présentes. Ce vscode-extensions sert à la persistance des données.
  • Et la ligne pour ./.devcontainer/history/.bash_history conservera l'historique de vos lignes de commande (dans la console) dans votre projet. Ainsi, la prochaine fois que vous travaillerez dans le devcontainer, l'historique CLI sera déjà rempli avec ce que vous avez fait par le passé.

Le fichier .devcontainer/devcontainer.json​

Et, enfin, le fichier de configuration pour VSCode.

Dans VSCode, pour pouvoir exécuter une commande Devcontainer: (depuis la Command Palette (CTRL+SHIFT+P)), le fichier .devcontainer/devcontainer.json doit être présent et indiquer à VSCode quoi faire.

{
    "name": "MySample Devcontainer",
    "dockerComposeFile": [?
        "../compose.yaml",
        "compose.yaml"
    ],
    "service": "app",
    "workspaceFolder": "/app",
    "remoteUser": "vscode",
    "containerUser": "vscode",
    "containerEnv": {
        "GIT_SSH_COMMAND": "ssh -i /home/vscode/.ssh/id_ed25519 -o 'UserKnownHostsFile=/dev/null'"?
    },
    "initializeCommand": "mkdir -p .devcontainer/history && touch .devcontainer/history/.bash_history && echo '.bash_history' > .devcontainer/history/.gitignore",?
    "customizations": {
        "vscode": {
            "settings": {
                "files.autoSave": "onFocusChange",
                "window.title": "${dirty}${rootName} ${separator} [DevContainer]",
                "workbench.colorTheme": "Visual Studio Light"
            },
            "extensions": [
                "ms-python.debugpy"
            ]
        }
    }
}

La structure de notre projet à ce stade​

À ce stade, notre projet ressemble à ceci, soit dix fichiers.

Création de l'image Devcontainer​

Cette partie est purement optionnelle, c'est juste pour vérifier si tout est correctement rempli.

Allez dans le dossier .devcontainer (cd .devcontainer) et exécutez cette commande :

$ docker compose -f ../compose.yaml -f compose.yaml config▋

Vous obtiendrez quelque chose comme ceci :

name: my_sample
services:
  app:
    build:
      context: /tmp/docker-prod-devcontainer/.devcontainer?
      dockerfile: Dockerfile
      args:?
        APP_HOME: /ap
        OS_GROUPID: "1000"
        OS_USERID: "1000"
        OS_USERNAME: vscode
        PYTHON_VERSION: "3.13"
        TIMEZONE: Europe/Brussels
    command:?
      - sleep
      - infinity
    container_name: my_sample_devcontainer_app
    environment:
      APP_HOME: /ap
      PYTHON_VERSION: "3.13"
      TIMEZONE: Europe/Brussels
    image: my_sample_prod:latest?
    networks:
      default: null
    ports:
      - mode: ingress?
        target: 8000
        published: "8000"
        protocol: tcp
      - mode: ingress
        target: 5679
        published: "5679"
        protocol: tcp
    security_opt:
      - no-new-privileges:true
    user: 1001:1001?
    volumes:
      - type: bind?
        source: /tmp/docker-prod-devcontainer
        target: /ap
        bind:
          create_host_path: true
      - type: volume?
        source: vscode-extensions
        target: /home/vscode/.vscode-server/extensions
        volume: {}
      - type: bind
        source: /tmp/docker-prod-devcontainer/.devcontainer/history/.bash_history
        target: /home/vscode/.bash_history
        bind:
          create_host_path: true
networks:
  default:
    name: my_sample_default
volumes:
  vscode-extensions:
    name: my_sample_vscode-extensions

Vous avez eu une erreur ? Si oui, vous pouvez la lire et la gérer plus facilement maintenant.

Vous pouvez regarder la configuration pour voir si tout semble correct, c'est-à-dire si vos variables ont bien été remplacées par les valeurs provenant des fichiers .env.

Ouvrir le container avec VSCode​

Il est temps d'ouvrir le projet avec la fonctionnalité Devcontainer de VSCode.

$ cd /tmp/docker-prod-devcontainer && code .▋

Si vous regardez en bas à droite de votre écran, vous verrez probablement cette popup :

Cliquez simplement sur le bouton Reopen in Container ou, deuxième méthode, appuyez sur CTRL+SHIFT+P pour ouvrir la Command palette et sélectionnez l'option "Dev Containers: Rebuild Without Cache and Reopen in Container".

VSCode fermera le projet et le rouvrira. Cela prendra plus de temps (la première fois) parce qu'il doit d'abord créer le container Docker.

Si vous voyez l'image ci-dessus, vous êtes dans le container. J'ai configuré un thème clair juste pour faire la distinction nette entre l'host (thème noir) et le devcontainer (thème clair).

En bas à droite, vous pouvez créer un nouveau Terminal :

Dans ce projet de démo, vous pouvez voir ce message ; une seule fois :

L'idée est donc de fournir une aide contextuelle au développeur et de lui indiquer, ici, comment démarrer le serveur FastAPI avec le hot reload et Debugpy activé.

Testons​

Si nous retournons à l'URL http://localhost:8000, nous obtenons toujours la réponse JSON (le container tourne donc bien).

Mais maintenant, dans VSCode, si vous éditez le script src/main.py et mettez à jour le message Hello comme ci-dessous :

Il vous suffit d'enregistrer la modification, de revenir à la fenêtre du navigateur et de rafraîchir la page :

Déboguons​

Dans ce projet de démo, nous avons ajouté la dépendance Debugpy.

Il nous suffit d'ajouter un fichier supplémentaire pour VSCode.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: FastAPI",
            "type": "debugpy",?
            "request": "attach",?
            "connect":  {
                "host": "localhost",
                "port": 5679,
            },
            "justMyCode": true,?
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}/src",?
                    "remoteRoot": "."?
                }
            ]
        }
    ]
}

Pour être sûr que l'extension fonctionne correctement, fermez VSCode et rouvrez-le. Rouvrez aussi le DevContainer (maintenant, vous pouvez simplement choisir "Reopen in Devcontainer").

Une fois dans votre devcontainer, ouvrez le fichier src/main.py. Cliquez n'importe où sur la ligne de retour (ligne 7) et appuyez sur F9 pour ajouter un point d'arrêt.

Appuyez sur F5 pour démarrer la session de débogage.

Retournez au navigateur, rafraîchissez la page et VSCode s'arrêtera sur cette ligne précise.

Pour aller plus loin​

L'exemple ci-dessus utilise Python ; exactement la même approche à deux images est utilisée, langage par langage, dans Docker - Python devcontainer et le développement PHP dans un devcontainer avec des outils de qualité de code préinstallés. Et si le devcontainer reste une notion abstraite pour vous, commencez par Docker - Explique-moi comme si j'avais cinq ans - À quoi sert Docker ?.