Préparer Docker pour la production : registry, tags et sécurité
Dernier volet de la série Docker : on sort du cadre purement local pour parler prod.
Objectif : que ce que tu fais sur ta machine soit déjà pensé pour une mise en production propre, que ce soit sur un simple VPS, une stack Swarm, ou un cluster Kubernetes.
Registry privé : où pousser tes images
Pour la prod, tu ne veux pas dépendre uniquement de Docker Hub public.
Options courantes :
-
GitHub Container Registry (
ghcr.io)
Pratique si ton code est sur GitHub. -
GitLab Container Registry
Intégré au pipeline CI/CD GitLab. -
Registry auto‑hébergé (Harbor, registry Docker, etc.)
Utile pour environnements sensibles / clients.
Exemple avec GitHub Container Registry :
echo $GITHUB_TOKEN | docker login ghcr.io -u likedevGit --password-stdin
docker build -t ghcr.io/likedevGit/mon-api:1.0.0 .
docker push ghcr.io/likedevGit/mon-api:1.0.0
Stratégie de tags
Évite le tout-latest. Quelques conventions utiles :
1.2.3: version exacte (build reproduisible).1.2: dernière patch de la 1.2.prod,staging,test: dernier build déployé sur tel environnement.
Workflow classique :
- CI pousse une image versionnée :
1.2.3. - Après validation, tu mets à jour le tag
prod→1.2.3. - Ta config de déploiement utilise
:prod(ou directement la version, selon ta préférence).
Sécurité minimale dans les images
Tu ne vas pas devenir expert sécurité en un article, mais tu peux éviter les gros pièges.
1. Ne pas tourner en root
Dans ton Dockerfile :
RUN addgroup -S app && adduser -S app -G app
USER app
Ensuite, ton process applicatif tourne avec cet utilisateur plutôt que root.
2. Réduire la surface d'attaque
- Utilise des images de base minimales (alpine, distroless, slim).
- N'installe que ce dont tu as besoin.
- Nettoie les caches de paquets (
rm -rf /var/lib/apt/lists/*).
3. Ne pas embarquer les secrets
Jamais de secrets dans :
- le Dockerfile,
- le code versionné,
- les images.
À la place :
- variables d'env,
- fichiers montés,
- secrets Docker/Kubernetes.
Intégration avec Kubernetes (aperçu)
Quand tu passeras sur Kubernetes, tes images Docker seront consommées par des Deployments :
apiVersion: apps/v1
kind: Deployment
metadata:
name: mon-api
spec:
replicas: 3
selector:
matchLabels:
app: mon-api
template:
metadata:
labels:
app: mon-api
spec:
containers:
- name: api
image: ghcr.io/likedevGit/mon-api:1.2.3
ports:
- containerPort: 3000
Si tes Dockerfile sont propres, tes déploiements Kubernetes seront déjà beaucoup plus simples.
Résumé de la série Docker
On a vu :
- Images vs conteneurs et le cycle de vie de base.
- Installation propre de Docker (Linux, macOS, Windows/WSL).
- Volumes et réseaux pour les données et la communication entre services.
- docker-compose pour décrire un environnement complet en YAML.
- Optimisation des Dockerfile et réduction de la taille des images.
- Préparation de la prod : registry privé, tags, sécurité, lien avec Kubernetes.
Avec ça, tu as un socle solide pour aborder la suite : Kubernetes.