Le syndrome « fonctionne sur ma machine »

Développeur A : “La connexion fonctionne sur mon Mac.” Développeur B : « Cela échoue sur mon PC Windows. » Serveur : “Il plante sous Linux car la version de Node.js ne correspond pas.” Il s’agit de Dérive de l’environnement. Cela fait perdre des milliers d’heures. Docker résout ce problème. Nous n’expédions pas de “Code”. Nous expédions un « Conteneur ». Un conteneur est une machine virtuelle légère qui contient le système d’exploitation (Alpine Linux), le runtime (nœud 18), les dépendances (node_modules) et le code. Si le conteneur démarre sur votre ordinateur portable, il sera démarré sur le serveur. Garanti. C’est l’unité standard de déploiement.

Pourquoi Maison Code en parle

Chez Maison Code, nous valorisons la Reproductibilité. Si un nouveau développeur rejoint l’équipe, il ne devrait pas passer 3 jours à installer Redis, Postgres et ImageMagick. Ils devraient exécuter « docker-compose up » et coder dans 10 minutes. Nous utilisons Kubernetes (K8s) pour nos entreprises clientes qui ont besoin de capacités à grande échelle et d’auto-réparation. Nous en parlons parce que DevOps n’est pas une réflexion après coup ; c’est le fondement de la vitesse de développement.

Le Dockerfile : la recette

Le Dockerfile définit comment créer le conteneur.

# 1. Image de base (petite et sécurisée)
FROM nœud : constructeur AS 18 alpins

# 2. Définir le répertoire
RÉPERT TRAVAIL /app

# 3. Installer les dépendances (couche de cache)
COPIER le paquet*.json ./
EXÉCUTER npm ci

# 4. Copier le code
COPIE . .

# 5. Construire
RUN npm exécuter la construction

# --- Construction en plusieurs étapes (optimisation) ---
# Nous supprimons l'étape 'constructeur' et ne conservons que les artefacts de production
DE nœud : coureur AS 18 alpins
RÉPERT TRAVAIL /app
COPIER --from=builder /app/.next ./.next
COPIER --from=builder /app/public ./public
COPIER --from=builder /app/node_modules ./node_modules
COPIER --from=builder /app/package.json ./package.json

# 6. Commencez
CMD ["npm", "démarrer"]

Conseil d’optimisation : Builds en plusieurs étapes. Dans l’exemple ci-dessus, nous utilisons une étape « builder » pour compiler le code. Ensuite, nous copions uniquement le résultat à l’étape runner. Nous laissons derrière nous le “Code Source”, le “Compilateur TypeScript” et les “DevDependencies”. Résultat : utilisez une image de 100 Mo au lieu d’une image de 1 Go. Déploiement plus rapide, exécution plus sûre.

Docker Compose : orchestration locale

Vous exécutez rarement un seul conteneur. Vous exécutez une application Web, une base de données et un cache. docker-compose.yml les orchestre.

version : '3'
prestations :
  Internet :
    construire : .
    ports : ["3000:3000"]
    environnement :
      DATABASE_URL : postgres://user:pass@db:5432/myapp
  base de données :
    image : postgres : 15
    environnement :
      POSTGRES_PASSWORD : réussite
  redis :
    image : redis: alpine

Désormais, « docker-compose up » fait tourner la pile entière. Le conteneur « web » peut communiquer avec « db » simplement en utilisant le nom d’hôte « db ». DNS magique.

Kubernetes (K8s) : Le Capitaine

Docker exécute des conteneurs. Kubernetes les gère. Si vous disposez d’un serveur, utilisez Docker. Si vous disposez de 100 serveurs, utilisez Kubernetes. Poignées K8 :

Auto-réparation : “Le conteneur A est tombé en panne. Redémarrez-le.”
Auto-Scaling : “L’utilisation du processeur est élevée. Ajoutez 5 conteneurs supplémentaires.”
Mises à jour progressives : “Mettez à jour la version 1 vers la version 2. Faites-le une par une. Si les erreurs augmentent, effectuez une restauration automatique.”

L’avertissement “Surpuissance”

Kubernetes est complexe. Il a une courbe d’apprentissage abrupte (Pods, Déploiements, Services, Ingress, Helm Charts). Pour 90 % des startups, les K8 sont excessifs. Utilisez un PaaS (Platform as a Service) comme Vercel, Railway ou AWS App Runner. Ils exécutent des conteneurs pour vous sans avoir à gérer le plan de contrôle du cluster. Passez aux K8 uniquement lorsque vous en avez besoin :

Conformité (hébergement sur site).
Optimisation des coûts à grande échelle.
Maillages de réseau complexes.

7. Helm : le gestionnaire de packages pour les K8

Les fichiers YAML de K8 sont verbeux. deployment.yaml (50 lignes). service.yaml (20 lignes). ingress.yaml (30 lignes). Multipliez par 3 environnements (Dev, Staging, Prod). C’est ingérable. Solution : Heaume. Les graphiques de barre sont des modèles. helm install mon-app ./charts/my-app --set image.tag=v2 Il remplace les variables dans le modèle et déploie les manifestes. Il s’agit du “NPM pour Kubernetes”.

8. GitOps (ArgoCD) : La vérité est dans Git

N’exécutez jamais kubectl apply -f file.yaml depuis votre ordinateur portable. Cela crée une « dérive de configuration ». Solution : GitOps.

Stockez tous les YAML dans un Git Repo (« infra-repo »).
Installez ArgoCD dans le cluster.
ArgoCD surveille le Git Repo.
Si vous transmettez une modification à Git, ArgoCD l’applique automatiquement au cluster.
Si quelqu’un pirate manuellement le cluster, ArgoCD détecte la différence et l’annule (configuration d’auto-guérison). L’état du cluster correspond toujours à Git.

10. Images sans dispersion : la sécurité par le minimalisme

Alpine Linux est petit (5 Mo). Mais il a un shell (/bin/sh). Si un pirate informatique pénètre, il peut exécuter des commandes. Solution : Images Google “Distroless”. Ils contiennent uniquement votre application et ses dépendances. Pas de coque. Pas de gestionnaire de packages. Pas de « ls ». Si un hacker exploite une vulnérabilité, il vérifie “Je suis partant !”… et ensuite il ne peut rien faire. Utilisez gcr.io/distroless/nodejs.

11. Budgets de perturbation des pods (PDB)

Vous disposez de 3 répliques de votre API. Kubernetes souhaite mettre à niveau le nœud (OS Patch). Cela draine le nœud. Il tue les 3 répliques en même temps. Le site tombe en panne. Correction : définissez un PDB. minDisponible : 2. K8s est obligé d’en tuer un, d’attendre que le nouveau démarre, puis de tuer le suivant. Cela garantit Déploiements sans temps d’arrêt, même pendant la maintenance de l’infrastructure.

12. Le point de vue du sceptique

“Docker est lent sur Mac.” Contre-point : C’est vrai. Il s’exécute dans une VM. Mais le débogage « Pourquoi « bcrypt » échoue-t-il sous Linux » prend plus de temps que l’atteinte des performances de 5 %. Cohérence > Vitesse brute.

##FAQ

Q : Docker contre machine virtuelle (VM) ? R : Une machine virtuelle capture le matériel (lourd). Un conteneur capture l’espace utilisateur du système d’exploitation (Light). Vous pouvez exécuter 100 conteneurs sur un serveur ne pouvant contenir que 5 VM.

Q : Docker est-il sécurisé ? R : Par défaut, oui (isolement). Mais si vous exécutez en tant que « root » à l’intérieur du conteneur et qu’il y a un exploit du noyau, l’attaquant peut s’échapper. Meilleure pratique : créez un utilisateur générique (RUN adduser app) et basculez vers celui-ci (USER app) au plus profond du Dockerfile.

Conclusion

Les conteneurs sont les conteneurs d’expédition du code. Avant les conteneurs maritimes standards, le chargement d’un navire était un véritable chaos (barils, sacs, cartons). Désormais, tout rentre dans une boîte standard. La grue ne se soucie pas de ce qu’il y a à l’intérieur. Docker fait de votre code une boîte standard. AWS est la grue. Emballez-le correctement et vous pourrez l’expédier n’importe où.

Des cauchemars de déploiement ?

Si vos déploiements sont instables, “ça a fonctionné sur ma machine”, Maison Code peut Dockeriser votre pile. Nous mettons en œuvre des pipelines CI/CD qui créent, testent et expédient automatiquement des conteneurs.

Des maux de tête liés au déploiement ?

Nous conteneurisons les applications à l’aide de Docker et les orchestrons avec Kubernetes pour des déploiements à toute épreuve. Embauchez nos architectes.