Docker et TypeScript : conteneurisation avancée d'applications

Docker et TypeScript : conteneurisation avancée d'applications

La conteneurisation d'applications TypeScript avec Docker ne se limite pas à empaqueter du code dans une image. À un niveau avancé, c'est un art d'optimisation, de sécurité et d'automatisation. Dans cet article, nous verrons comment créer des images Docker efficaces pour TypeScript, gérer l'environnement et intégrer la conteneurisation dans un pipeline CI/CD. Vous apprendrez à réduire la taille de l'image de 5 à 10 fois, accélérer la construction et améliorer l'isolation des dépendances.

1. Builds multi-étapes (Multi-stage builds) pour TypeScript

Le problème classique des images Docker pour TypeScript est l'inclusion dans l'image finale de tous les outils de développement : compilateur TypeScript, dépendances de développement, fichiers sources. Cela conduit à des tailles énormes (souvent > 1 Go). La solution est le build multi-étapes.

L'idée est simple : la première étape (build) compile le TypeScript en JavaScript et installe toutes les dépendances. La deuxième étape (production) copie uniquement le JavaScript prêt et les dépendances de production.

# Étape 1 : Build\nFROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --only=development\nCOPY . .\nRUN npm run build\n\n# Étape 2 : Production\nFROM node:20-alpine AS production\nWORKDIR /app\nCOPY --from=builder /app/dist ./dist\nCOPY --from=builder /app/package*.json ./\nRUN npm ci --only=production\nEXPOSE 3000\nCMD ["node", "dist/index.js"]

Cette approche réduit la taille de l'image d'environ 800 Mo à environ 150 Mo. Notez les options --only=development et --only=production — ce sont des drapeaux clés pour séparer les dépendances.

2. Optimisation de la mise en cache des couches Docker

Chaque instruction dans un Dockerfile crée une couche. Docker met en cache les couches si elles n'ont pas changé. L'ordre correct des instructions est crucial pour la vitesse des reconstructions.

Mauvais exemple (casse le cache) :

FROM node:20-alpine\nWORKDIR /app\nCOPY . .\nRUN npm ci\nRUN npm run build\nCMD ["node", "dist/index.js"]

Ici, toute modification du code source (même dans README.md) réinitialise le cache pour npm ci et le build.

Bon exemple (conserve le cache) :

FROM node:20-alpine AS builder\nWORKDIR /app\nCOPY package*.json tsconfig.json ./\nRUN npm ci --only=development\nCOPY src ./src\nRUN npm run build

Pourquoi cela fonctionne-t-il ? Les dépendances changent rarement, tandis que le code source change souvent. En copiant package*.json séparément, nous garantissons que la couche avec npm ci n'est reconstruite que lorsque ces fichiers changent.

3. Gestion des variables d'environnement et des secrets

Pour les applications TypeScript sur Node.js, l'utilisation de variables d'environnement est la norme. Cependant, Docker présente des particularités.

Erreur typique : transmettre des données sensibles (clés API, mots de passe) via ENV dans le Dockerfile. Cela laisse les secrets dans l'historique des couches de l'image.

Approche correcte :

\n
• Utilisez --env-file lors du lancement du conteneur
\n
• Pour la production, utilisez Docker Secrets (dans Swarm) ou Kubernetes Secrets
\n
• Pour le développement local, utilisez un fichier .env avec docker-compose
\n

Exemple de docker-compose.yml :

version: '3.8'\nservices:\n  app:\n    build: .\n    ports:\n      - "3000:3000"\n    env_file:\n      - .env.production\n    volumes:\n      - ./logs:/app/logs

Dans le code TypeScript, utilisez la bibliothèque dotenv pour charger les variables :

import dotenv from 'dotenv';\nimport { resolve } from 'path';\n\ndotenv.config({ path: resolve(__dirname, '../.env') });\n\nconst config = {\n  port: parseInt(process.env.PORT || '3000', 10),\n  dbUrl: process.env.DATABASE_URL,\n  apiKey: process.env.API_KEY\n};\n\nexport default config;

Important : ne committez jamais les fichiers .env réels