Qu'est-ce que Docker et pourquoi les développeurs devraient-ils l'apprendre ?

Docker apparaît constamment dans les offres d'emploi et les guides de configuration, et si vous n'avez jamais utilisé de conteneurs, cela peut sembler être un obstacle à franchir avant d'avoir le droit d'écrire du vrai code. Ce n'est pas si compliqué une fois qu'on dépasse le vocabulaire.

Ce qu'est réellement un conteneur

Un conteneur empaquette votre application avec tout ce dont elle a besoin pour s'exécuter : le code, le runtime, les bibliothèques système et les fichiers de configuration. Ce n'est pas une machine virtuelle. Une VM virtualise un système d'exploitation entier, noyau compris, ce qui signifie que le démarrage peut prendre une minute et consommer plusieurs gigaoctets de RAM. Un conteneur partage le noyau de la machine hôte et isole uniquement le processus, donc il démarre en moins d'une seconde et utilise généralement des dizaines de mégaoctets au lieu de gigaoctets.

Cette différence explique pourquoi Docker a pris le contrôle du développement local et des pipelines CI si rapidement. Vous pouvez lancer une base de données Postgres, un cache Redis et votre serveur d'application sur un seul ordinateur portable sans installer l'un d'eux directement sur votre système d'exploitation.

Les éléments essentiels à connaître

Il y a quatre termes qui couvrent la plupart de ce avec quoi vous travaillerez au quotidien :

• Image : un modèle en lecture seule construit à partir d'un Dockerfile. Pensez à cela comme un instantané d'un système de fichiers plus des métadonnées sur la façon de l'exécuter.
• Conteneur : une instance en cours d'exécution d'une image. Vous pouvez démarrer, arrêter et supprimer des conteneurs sans toucher à l'image dont ils sont issus.
• Dockerfile : un fichier texte avec des instructions pour construire une image, ligne par ligne.
• Registre : l'endroit où les images sont stockées et récupérées, le plus souvent Docker Hub.

Un Dockerfile minimal pour une application Node.js ressemble à ceci :

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Construisez-le avec docker build -t my-app . et exécutez-le avec docker run -p 3000:3000 my-app. Le drapeau -p mappe un port sur votre machine à un port à l'intérieur du conteneur, ce qui vous permet d'accéder réellement à l'application depuis votre navigateur.

Les commandes que vous utiliserez constamment

Une poignée de commandes couvre la plupart du travail quotidien :

• docker ps — lister les conteneurs en cours d'exécution
• docker ps -a — lister tous les conteneurs, y compris les arrêtés
• docker images — lister les images sur votre machine
• docker logs <container> — vérifier la sortie d'un conteneur en cours d'exécution ou arrêté
• docker exec -it <container> sh — ouvrir un shell à l'intérieur d'un conteneur en cours d'exécution
• docker rm / docker rmi — nettoyer les conteneurs et les images dont vous n'avez plus besoin

Cette dernière paire est plus importante que les gens ne le pensent. Docker laissera volontiers l'espace disque disparaître dans d'anciennes images et des conteneurs arrêtés. Exécuter docker system prune de temps en temps récupère une quantité surprenante d'espace.

Pourquoi docker-compose change le flux de travail

La plupart des projets réels nécessitent plus d'un conteneur : un serveur d'application, une base de données, peut-être un cache. Écrire des commandes docker run pour chacun devient rapidement fastidieux. docker-compose.yml vous permet de définir l'ensemble de la pile dans un seul fichier :

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: devpassword
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Exécutez docker compose up et les deux services démarrent ensemble, en réseau pour que web puisse atteindre db par nom de service. C'est la configuration que vous verrez dans le README de presque chaque dépôt open-source, et la comprendre signifie que vous pouvez cloner un projet et le faire fonctionner en minutes au lieu d'installer manuellement Postgres, Redis et tout ce dont l'application a besoin.

Où les gens accrochent au début

Les volumes confondent presque tout le monde au départ. Sans volume, tout ce qui est écrit à l'intérieur d'un conteneur disparaît quand le conteneur est supprimé, ce qui est un problème pour les bases de données. La section volumes dans le fichier compose ci-dessus mappe un volume nommé à un chemin à l'intérieur du conteneur pour que les données survivent aux redémarrages.

Une autre erreur courante est de copier node_modules ou .git dans l'image car il n'y a pas de fichier .dockerignore. Ajoutez-en un comme un .gitignore :

node_modules
.git
.env

Cela accélère les constructions et réduit la taille des images, ce qui compte une fois que vous poussez des images vers un registre ou que vous déployez sur Kubernetes.

Où aller après les bases

Une fois que construire et exécuter des conteneurs semble normal, les compétences suivantes utiles sont les constructions multi-étapes pour des images de production plus petites, comprendre les modes de réseau Docker et lire une sortie docker inspect quand quelque chose ne se connecte pas correctement. Rien n'est difficile, c'est juste peu familier la première fois.

Pour en savoir plus sur la conteneurisation d'applications réelles et leur connexion aux pipelines de déploiement cloud, consultez les segments DevOps et Cloud sur Korra Studio.