Créer un Dockerfile optimisé pour la production
Créez un Dockerfile multi-stage optimisé pour la production avec sécurité maximale, image légère et meilleures pratiques.
Coller dans votre IA
Collez ce prompt dans ChatGPT, Claude ou Gemini et personnalisez les variables entre crochets.
Tu es un expert Docker et DevOps spécialisé dans l'optimisation des conteneurs pour la production. Je dois créer un Dockerfile optimisé pour l'application suivante :
Type d'application : [EX: API Node.js, application Python Flask, application Go, frontend React]
Version du runtime : [EX: Node.js 20, Python 3.12, Go 1.22]
Dépendances : [EX: PostgreSQL client, Redis, librairies système spécifiques]
Variables d'environnement sensibles : [LISTER_LES_VARS_SANS_VALEURS]
Commande de démarrage : [EX: npm start, gunicorn app:app, ./binary]
Crée un Dockerfile de production qui respecte toutes les meilleures pratiques :
- Multi-stage build : sépare les étapes de build et de runtime pour minimiser la taille de l'image finale.
- Image de base : choisis l'image de base la plus légère et sécurisée appropriée (Alpine, Distroless, Slim).
- Utilisateur non-root : crée et utilise un utilisateur sans privilèges pour des raisons de sécurité.
- Optimisation du cache : ordonne les instructions pour maximiser l'utilisation du cache Docker.
- Gestion des secrets : utilise des build args pour les secrets de build, jamais de secrets dans les layers.
- Health check : ajoute une instruction HEALTHCHECK appropriée.
- Métadonnées : ajoute les labels LABEL standards (maintainer, version, description).
Fournis également un fichier .dockerignore adapté et une commande docker build et docker run de test.
Personnaliser ce prompt avec Léa
Léa réécrit ce prompt pour ton métier et ton objectif précis — 3 questions suffisent.
Pourquoi ce prompt fonctionne
<p>Ce prompt cible les quatre axes d'optimisation Docker les plus importants en production : la taille de l'image (multi-stage, Alpine), la sécurité (utilisateur non-root, pas de secrets dans les layers), les performances de build (optimisation du cache) et la fiabilité (health checks).</p><p>La demande d'un .dockerignore en plus du Dockerfile est souvent négligée mais cruciale : un .dockerignore mal configuré peut inclure accidentellement des fichiers sensibles (node_modules, .env) ou gonfler inutilement le contexte de build.</p><p>En spécifiant le type d'application et le runtime dès le départ, l'IA peut choisir les images de base optimales (par exemple Distroless pour Go, Node Alpine pour Node.js) plutôt que de proposer un Dockerfile générique peu adapté au contexte réel.</p>
Cas d'usage
Résultat attendu
Un Dockerfile multi-stage complet, un .dockerignore adapté et les commandes de build et run avec explications.
Améliorez ce prompt
Passez ce prompt dans l'Optimiseur pour renforcer le contexte, les contraintes et le format attendu.
Améliore ce prompt avec l'OptimiseurCommentaires
- LéaIA
Astuce : pour Node.js, remplacez `npm install` par `npm ci` dans le stage de build. Cela force l'utilisation exacte du `package-lock.json` (installations reproductibles) et est plus rapide. Ajoutez `--production` pour exclure les devDependencies. Copiez d'abord `package*.json` puis les dépendances avant le code source pour maximiser le cache Docker.
Termes du glossaire
📬 Recevez de nouveaux prompts chaque semaine
Rejoignez notre newsletter et ne manquez aucun prompt.
Pour aller plus loin
Prompts similaires
Concevoir un cadre de conformité en tant que code
Automatiser les contrôles de conformité
Implémenter la Clean Architecture en pratique
Implémentez la Clean Architecture en pratique avec couches, ports et adaptateurs, use cases et tests unitaires sans infrastructure.
Prompt pour maîtriser le SSR et l'hydratation avec Next.js
Prompt complet pour diagnostiquer, implémenter et optimiser le Server-Side Rendering et l'hydratation dans une application Next.js, avec gestion des erreurs courantes.
Stratégie de scheduling avancée
Optimiser le placement des pods