Softonic

Générateur de Dockerfile

Étape 1 / 2 Dockerfile
Résultats

Un Dockerfile fait partie de ces fichiers qui semblent courts jusqu’à ce qu’on se rappelle les détails : l’ordre des couches compte pour le cache, COPY package.json se place avant RUN npm install, et les langages compilés gagnent à utiliser un build multi-étapes. Ce générateur écrit un Dockerfile prêt à l’emploi pour la technologie choisie, avec un schéma de cache déjà correct.

Comment générer un Dockerfile

  1. 1

    Choisissez la technologie

    Node.js, Python, PHP, Go ou Rust. Chaque modèle utilise une image de base adaptée au langage et la bonne commande d'installation des dépendances.

  2. 2

    Définissez le répertoire de travail et le port

    Choisissez le WORKDIR et le port sur lequel votre application écoute ; les deux sont inscrits dans le fichier généré.

  3. 3

    Relisez le Dockerfile

    Vérifiez que la ligne EXPOSE et la commande de démarrage correspondent à votre application. Les modèles Go et Rust utilisent un build multi-étapes.

  4. 4

    Copiez le Dockerfile

    Copiez le résultat et collez-le à la racine de votre dépôt, puis construisez l'image.

Pourquoi les builds multi-étapes

Un Dockerfile naïf installe toute la chaîne d’outils du compilateur dans l’image finale. Les builds multi-étapes offrent une étape “builder” qui compile et une étape finale qui ne transporte que l’artefact compilé :

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

L’image finale supprime toutes les dépendances de développement, les fichiers sources et le cache de build, réduisant souvent sa taille de 60 à 80 pour cent.

Variantes d’image de base

Les modèles utilisent des images slim ou alpine quand c’est possible. Si vous ajustez l’image de base vous-même, voici les options typiques :

Variante Taille typique Quand la choisir
full 300-900 Mo Images de développement, dépendances système inhabituelles
slim 80-200 Mo Standard de production pour la plupart des langages
alpine 30-100 Mo Petites images, attention aux problèmes glibc vs musl
distroless 20-80 Mo Sécurité maximale ; pas de shell, pas de gestionnaire de paquets

Règles de mise en cache des couches

Docker met en cache chaque ligne ; dès qu’une couche change, tout ce qui est en dessous est reconstruit. Ordre du moins au plus volatil :

  1. Image de base FROM (change rarement).
  2. Paquets système (apt-get install), changements rares.
  3. Manifests de dépendances (package.json, requirements.txt, composer.json).
  4. Étape d’installation des dépendances. Ne s’exécute que lorsque le manifest change.
  5. Copie du code source. La couche la plus active ; tout ce qui suit est reconstruit à chaque commit.
  6. Compilation et CMD final.

Briser cet ordre est la cause la plus fréquente des builds CI lents.

Liste de contrôle de sécurité

  • Exécuter en non-root. Placez USER appuser (ou USER 1000) vers la fin.
  • Épingler les versions. python:3.12.7-slim bat python:3.12 qui bat python:latest.
  • Définir un WORKDIR explicite plutôt que de compter sur /.
  • Utiliser COPY et non ADD pour les fichiers locaux ; ADD a des effets secondaires d’auto-extraction.
  • Ajouter un HEALTHCHECK pour que les orchestrateurs détectent un processus bloqué.
  • Nettoyer les caches de paquets dans la même ligne RUN : apt-get install ... && rm -rf /var/lib/apt/lists/*.

Questions fréquentes

Slim est un choix par défaut plus sûr car il repose toujours sur glibc, comme la plupart des wheels précompilés des bibliothèques. Alpine utilise musl et provoque parfois d’étranges bugs d’exécution en Python (pandas, numpy) ou Node (modules natifs node-gyp). Choisissez alpine quand la taille de l’image est critique et que vous avez testé la pile.

Oui, ajoutez-en un à votre projet. Sans lui, Docker envoie tout votre dépôt au daemon comme contexte de build : historique git, node_modules, fichiers .env locaux, tests. C’est lent, gaspille le cache et fuit des secrets.

Oui. Utilisez docker buildx avec l’option --platform pour compiler pour les deux architectures en même temps. Les images de base utilisées par les modèles publient des variantes arm64.

Non. La technologie, le répertoire de travail et le port choisis servent uniquement à générer le Dockerfile sur cette page ; rien n’est stocké ni partagé.

Outils similaires

Référence de la table ASCII

Table ASCII complète de 0 à 127 avec décimal, hexadécimal, octal, binaire et référence numérique HTML pour chaque caractère, y compris les codes de contrôle comme NUL, LF et DEL.

Référence des caractères HTML

Liste consultable des entités HTML, de leurs codes nommés et numériques, et un copier-coller en un clic pour les caractères et symboles spéciaux.

Générateur de carte CSS

Créez le CSS d’un conteneur de carte : fond, bordure, rayon des angles, espacement intérieur et ombre douce, avec aperçu immédiat et code à copier-coller.

Référence des raccourcis clavier

Recherchez les raccourcis par défaut documentés de VS Code, Chrome et Bash avec GNU Readline sous macOS, Windows et Linux.

Générateur d’accordéon CSS

Créez un accordéon de trois sections avec details et summary. Personnalisez textes, couleurs, espacements, icône et ouverture, puis copiez ou téléchargez le code.

Recherche de nom de couleur

Trouvez la couleur nommée CSS standardisée la plus proche d’une valeur HEX, RGB ou HSL grâce à l’écart CIEDE2000.

Outil disponible dans d’autres langues