Fiche de révision : Images Docker et bonnes pratiques

📋 Plan du Cours

1. Rôle et structure du Dockerfile
2. Exemple d’image Express avec Docker
3. Instructions principales des Dockerfiles
4. Couches et cache des images
5. Choisir et organiser l’image de base
6. Sécurité et configuration de production
7. Optimiser les dépendances et le cache
8. Ports et builds multi-stage

📖 1. Rôle et structure du Dockerfile

🔑 Notions clés & Définitions

• Dockerfile : Définit les étapes nécessaires à la création d’une image Docker.

📝 Points essentiels

• La structure nominale comprend : l’image de base, l’application conteneurisée, sous forme d’exécutable ou de code à interpréter, les dépendances de l’application, les autres fichiers, le port d’écoute interne au conteneur, la commande de lancement, éventuellement extraite dans un script shell si elle est complexe

📖 2. Exemple d’image Express avec Docker

📝 Points essentiels

• L’image Express est construite avec docker build --tag express-docker:0.1.0 ., puis lancée en arrière-plan avec suppression à l’arrêt et publication du port 3000 du conteneur vers le port 3000 de l’hôte.

• L’exemple Express utilise le port 3000 et répond « Hello, Express! » à une requête GET sur la racine « / ».

• Le Dockerfile de l’exemple Express utilise FROM node, COPY . ., RUN npm install, EXPOSE 3000 et CMD ["npm", "start"].

• Le fichier .dockerignore exclut :

  • Dockerfile
  • .git/
  • node_modules/
  • npm-debug.log

💡 Astuce mémo

Définir l’image, copier les fichiers, installer les dépendances, exposer le port, lancer l’application.

📖 3. Instructions principales des Dockerfiles

★ À maîtriser

📌 RUN exécute une commande pendant la construction de l’image et cette commande doit être non interactive, car aucune entrée ne peut être fournie à Docker pendant le build.

• FROM définit l’image de base, par exemple FROM alpine:3.4.

• CMD définit la commande par défaut exécutée par un conteneur, par exemple CMD ["nginx", "-g", "daemon off;"].

Compléments

• COPY copie des fichiers du contexte de construction vers un emplacement du système de fichiers du conteneur.

• ENV définit une variable d’environnement, tandis qu’EXPOSE documente les ports réseau sur lesquels le conteneur écoute.

• Ces instructions configurent le conteneur :

  • WORKDIR définit le répertoire de travail
  • USER définit l’utilisateur des instructions RUN, CMD et ENTRYPOINT suivantes
  • LABEL ajoute des métadonnées clé/valeur

• ARG définit un paramètre de construction de l’image, tandis qu’ONBUILD ajoute une instruction déclenchée lorsque l’image sert de base à une autre construction.

• ADD copie des fichiers, répertoires ou fichiers distants dans le conteneur, peut invalider les caches et est à éviter au profit de COPY.

📖 4. Couches et cache des images

📝 Points essentiels

• Chaque instruction d’un Dockerfile crée une nouvelle couche de l’image Docker, comparable à un instantané à un moment donné.

• Les couches favorisent la mise en cache et le partage des données.

💡 Astuce mémo

Visualiser l’image comme une pile d’instantanés réutilisables.

📖 5. Choisir et organiser l’image de base

★ À maîtriser

📌 Il faut choisir une image de base spécifiée au moins jusqu’à une version mineure, comme node:20.8-alpine, afin de stabiliser la construction et d’éviter des ruptures dues aux mises à jour en amont.

• Une petite image de base réduit la taille de l’image, accélère sa création et sa publication, et réduit la surface d’attaque.

Compléments

📌 Le répertoire de travail est la racine (/) par défaut, mais il convient de le définir ailleurs selon les conventions du langage et du framework afin de réserver un emplacement à l’application.

💡 Astuce mémo

Image de base plus petite → image plus légère, build et publication accélérés, surface d’attaque réduite.

📖 6. Sécurité et configuration de production

★ À maîtriser

📌 Définir un utilisateur non-root ajoute une couche de défense en profondeur, en complément de la protection que les espaces de noms utilisateur peuvent fournir entre les utilisateurs root du conteneur.

• La variable NODE_ENV=production modifie le comportement de certains composants et augmente ainsi les performances de l’application Node.js.

📌 npm ci assure un état reproductible, contrairement à npm install, et l’option --only=production empêche l’installation des dépendances de développement non nécessaires.

Compléments

• Dans l’exemple, USER node sélectionne l’utilisateur non-root et COPY --chown=node:node attribue les fichiers copiés à node:node.

📖 7. Optimiser les dépendances et le cache

★ À maîtriser

📌 Copier les fichiers de dépendances, tels que package*.json, puis installer les dépendances avant de copier le code permet de préserver leur couche en cache lorsque seul le code de l’application change.

Compléments

• Un montage RUN --mount=type=cache,target=/usr/src/app/.npm peut accélérer l’installation en réutilisant un cache local des dépendances déjà disponibles.

💡 Astuce mémo

Copier d’abord les fichiers de dépendances → les changements de code préservent leur cache.

📖 8. Ports et builds multi-stage

🔑 Notions clés & Définitions

• Multi-stage build : Sépare les étapes d’un Dockerfile afin de fournir un environnement de développement pratique avec des dépendances de développement et le rechargement à chaud, tout en conservant une configuration adaptée à la production pour le déploiement.

★ À maîtriser

• EXPOSE documente le port sur lequel l’application est censée écouter, mais le port doit toujours être publié lors de l’exécution du conteneur.

Compléments

• Dans l’exemple multi-stage, le stage de base part de node:20.8-alpine, définit /usr/src/app comme répertoire de travail et copie package*.json.

• Dans l’exemple de production, le stage définit NODE_ENV=production, installe avec npm ci --only=production, utilise l’utilisateur node, copie src avec --chown=node:node, expose le port 3000 et lance node index.js.

💡 Astuce mémo

Le stage dev privilégie le confort de développement ; le stage de production conserve une configuration de déploiement.