00 - Pourquoi Docker change tout
Ce que tu vas apprendre
- Pourquoi Docker est devenu incontournable pour les devs
- Le vrai problème que Docker resout (et non, c'est pas juste "ca marche sur ma machine")
- Ce que cette serie couvre en 33 articles
- A qui elle s'adresse
Prerequisites
Aucun. Tu sais ouvrir un terminal, ca suffit.
Le déploiement qui m'a vaccin
Septembre 2021. Je livre une API Node.js chez un client. L'appli tourne sur ma machine, tous les tests passent, la CI est verte. On deploie sur le serveur de staging. Rien ne marche.
Le serveur tourne sur Ubuntu 18.04 avec Node 14. Mon poste, c'est un Mac M1 avec Node 18. Les versions de sharp ne sont pas les memes, bcrypt ne compile pas pareil, et le node-gyp du serveur refuse de cooperer. J'ai passe deux jours a debugger des problèmes qui n'avaient rien a voir avec mon code.
Deux jours. Pour un ecart d'environnement.
C'est ce jour-la que j'ai compris que "ca marche sur ma machine" n'est pas une blague de dev. C'est un symptome d'un vrai problème : on développé dans un contexte et on deploie dans un autre.
Le problème, c'est l'environnement
Avant Docker, la liste des trucs qui pouvaient diverger entre ta machine et la prod etait longue :
- La version de l'OS
- La version du runtime (Node, Python, Java...)
- Les librairies système installees (openssl, libpng, ffmpeg...)
- Les variables d'environnement
- La configuration réseau
- Les droits fichiers
Chaque point est une source potentielle de bug invisible. Tu peux écrire le code le plus propre du monde, si ton environnement de prod ne correspond pas a ton environnement de dev, tu vas souffrir.
Les solutions d'avant Docker existaient. Les machines virtuelles, les scripts Ansible, les Vagrantfile. Mais elles etaient lourdes, lentes, et souvent maintenues par une équipe ops séparée.
Docker, c'est quoi en une phrase
Docker te permet de packager ton application avec tout son environnement dans un conteneur. Ce conteneur tourne de manière identique sur ta machine, sur le serveur de staging, et en production. Meme OS, memes librairies, meme configuration.
C'est pas une VM. C'est plus leger que ca. On en parlera en détail dans l'article suivant, mais retiens l'idee : un conteneur partage le noyau Linux de la machine hote. Il isole ton application sans dupliquer tout un système d'exploitation.
Pour qui est cette serie
Cette serie s'adresse aux devs qui utilisent Docker au quotidien sans vraiment comprendre ce qui se passe sous le capot. Ou a ceux qui n'ont jamais touche Docker et veulent s'y mettre proprement.
Tu es dev frontend et tu veux comprendre le docker-compose.yml de ton projet ? Ca va t'aider. Tu es dev backend et tu veux optimiser tes images Docker qui font 2 Go ? Aussi. Tu veux déployer tes projets perso sans te battre avec des serveurs ? On couvre ca.
Sur paltemps.fr, Docker fait partie de la stack de base. Chaque projet démarré avec un Dockerfile et un compose.yml. Cette serie explique pourquoi et comment.
Ce qu'on va couvrir
| # | Article | Sujet |
|---|---|---|
| 00 | Introduction | Pourquoi Docker, vue d'ensemble |
| 01 | Containers vs VMs | Ce qu'est vraiment un conteneur |
| 02 | Architecture | Daemon, client, images, registries |
| 03 | Desktop & Engine | Docker Desktop, Colima, Podman |
| 04 | Dockerfile | Écrire son premier Dockerfile |
| 05 | Layers & cache | Comprendre les couches et le cache |
| 06 | .dockerignore | Maitriser le build context |
| 07 | Multi-stage | Réduire la taille de ses images |
| 08 | Images de base | Alpine, slim, distroless, laquelle choisir |
| 09 | Compose - bases | Orchestrer plusieurs services |
| 10 | Compose - avance | Profiles, extends, overrides |
| 11 | Volumes | Persistance et partage de donnees |
| 12 | Networking | Communication entre conteneurs |
| 13 | Variables d'env | Configuration et secrets |
| 14 | Healthchecks | Verifier que ton app est vivante |
| 15 | Logs & debug | Diagnostiquer les problèmes |
| 16 | exec & attach | Entrer dans un conteneur |
| 17 | Tags & versions | Versionner ses images |
| 18 | Docker Hub | Publier et partager ses images |
| 19 | Registries prives | GitHub, GitLab, AWS ECR |
| 20 | Sécurité | Bonnes pratiques et scanning |
| 21 | Rootless & non-root | Réduire la surface d'attaque |
| 22 | BuildKit | Le builder moderne |
| 23 | Build args & secrets | Passer des secrets au build |
| 24 | CI/CD avec Docker | GitHub Actions, GitLab CI |
| 25 | Dev containers | VS Code et environnements de dev |
| 26 | Hot reload | Developper dans Docker sans friction |
| 27 | Tests dans Docker | Lancer les tests dans des conteneurs |
| 28 | PostgreSQL & Redis | Bases de donnees en conteneur |
| 29 | Reverse proxy | Nginx et Traefik devant Docker |
| 30 | Monitoring | Prometheus, Grafana, cAdvisor |
| 31 | Docker en prod | Ce qui change par rapport au dev |
| 32 | Alternatives | Podman, containerd, nerdctl |
Chaque article est independant, mais ils sont penses pour etre lus dans l'ordre si tu debutes.
Ce que Docker ne resout pas
Docker ne remplace pas une bonne architecture. Il ne rend pas ton code meilleur. Il ne gere pas l'orchestration de dizaines de services en production (ca, c'est le job de Kubernetes, et c'est une autre serie).
Docker resout un problème precis : la coherence de l'environnement d'exécution. Et il le fait bien.
Un premier contact
Si tu n'as jamais lance Docker, voici ce que ca donne :
bashdocker run hello-world
Cette commande telecharge une petite image, créé un conteneur, l'exécuté, et affiche un message. C'est tout. Pas de configuration, pas de setup. Ca prend 5 secondes.
Hello from Docker!
This message shows that your installation appears to be working correctly.Si ca marche, tu es pret pour la suite.
Résumé
- Docker resout le problème de l'ecart entre les environnements de dev et de prod
- Un conteneur embarque l'application et tout son environnement
- Cette serie couvre Docker de A a Z en 33 articles
- Chaque article est lisible indépendamment, mais l'ordre aide si tu debutes
Suivant : 01 - Containers vs VMs