Générateur de Dockerfile
Générez un Dockerfile prêt pour la production pour Node.js, Python, Go, Java, .NET, Rust ou un site statique : builds multi-étapes, utilisateur non root et .dockerignore associé.
En production, épinglez des versions ou des digests d’image précis et reconstruisez régulièrement pour récupérer les correctifs de sécurité.
Outils Connexes
Voir ToutQu'est-ce que Générateur de Dockerfile ?
Créez un Dockerfile conforme aux bonnes pratiques actuelles pour Node.js, Python, Go, Java (Maven), .NET (ASP.NET Core), Rust ou un site statique servi par Nginx. Les options comprennent les builds multi-étapes pour des images plus petites, l'exécution avec un utilisateur non root, la version du runtime, le port et la commande de démarrage ; l'outil produit aussi un .dockerignore correspondant.
Comment utiliser Générateur de Dockerfile
- Choisissez le Langage / stack.
- Définissez la Version du runtime (tag d’image), le Port et le fichier de démarrage, le module, le JAR ou le nom du binaire.
- Laissez cochées les options Build multi-étapes (image plus légère) et Exécuter avec un utilisateur non root sauf raison contraire.
- Téléchargez le Dockerfile et le .dockerignore à la racine de votre projet et lancez
docker build -t myapp ..
Exemple
Node.js 22, port 3000, start file dist/index.js, multi-stage, non-root, npm run build
# syntax=docker/dockerfile:1 # ---- dependencies (production only) ---- FROM node:22-alpine AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --omit=dev # ---- build ---- FROM node:22-alpine AS build WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build # ---- runtime ---- FROM node:22-alpine ENV NODE_ENV=production WORKDIR /app COPY --from=deps --chown=node:node /app/node_modules ./node_modules COPY --from=build --chown=node:node /app/dist ./dist COPY --chown=node:node package.json ./ # The official Node images ship an unprivileged "node" user USER node EXPOSE 3000 CMD ["node", "dist/index.js"]
Quand utiliser Générateur de Dockerfile
Utilisez-le pour conteneuriser rapidement un service web ou une API typique avec des valeurs par défaut raisonnables. Relisez le fichier généré pour votre projet : les commandes de build, dossiers de sortie et points d'entrée varient, et les dépendances natives peuvent nécessiter des paquets système supplémentaires. Épinglez des versions exactes ou des digests d'images pour des builds de production reproductibles.
Comment fonctionne Générateur de Dockerfile
Chaque stack a un modèle écrit pour ses images officielles. Les builds multi-étapes installent et compilent dans une image SDK complète et ne copient que le résultat dans un runtime allégé : Node installe les dépendances de production avec npm ci --omit=dev dans une étape séparée ; Python construit un virtualenv et le copie dans python:<ver>-slim ; Go compile un binaire statique (CGO_ENABLED=0, -trimpath -ldflags="-s -w") dans distroless/static:nonroot ; Java copie le JAR dans une image Temurin JRE seule ; .NET publie dans l'image runtime aspnet et utilise son utilisateur intégré $APP_UID ; Rust copie le binaire de release dans debian:bookworm-slim. Le mode non root utilise l'utilisateur sans privilèges de l'image (node, nonroot, app) ou en crée un avec l'UID 10001. Les manifestes de dépendances sont copiés avant le code source pour que le cache de couches de Docker évite de réinstaller quand seul le code change.
Cas d'utilisation courants
- Conteneuriser une API Node.js ou Python pour le déploiement
- Réduire l'image d'un service Go avec un runtime distroless
- Servir un build React/Vue/Astro avec Nginx non root
- Enseigner ou relire les bonnes pratiques de Dockerfile
Note de Sécurité
Ne faites jamais de COPY de fichiers .env ou d'identifiants dans une image ; transmettez les secrets à l'exécution ou avec les montages de secrets BuildKit.
Questions Fréquentes
Pourquoi utiliser un build multi-étapes ?
Les compilateurs, dépendances de développement et fichiers sources restent dans l'étape de build : l'image finale est plus petite, démarre plus vite et contient moins de paquets susceptibles d'avoir des vulnérabilités.
Pourquoi exécuter avec un utilisateur non root ?
Si l'application est compromise, l'attaquant n'obtient pas root dans le conteneur, ce qui limite les dégâts et bloque certaines techniques d'évasion de conteneur.
À quoi sert .dockerignore ?
Il exclut des fichiers comme node_modules, .git et .env du contexte de build, ce qui accélère les builds et garde les secrets hors de l'image.