J'ai procastiné Docker pendant un mois... Voici ce qui m'a débloquée

Le 8 juillet, j'ai commencé un mentorat DevOps avec Endah. J'étais motivée, pleine de bonnes résolutions, prête à attaquer le Docker comme une pro. Sauf qu'entre le 21 juillet et le 22 août, je n'ai rien publié. Mon dernier article ici datait du 29 juillet. Ce silence n'était pas de l'inaction : c'était la phase la moins visible de l'apprentissage, celle où on lit la documentation officielle, où on regarde des schémas d'architecture, où on essaie de comprendre pourquoi Docker existe avant de taper la première commande. Le déclic est venu quand j'ai arrêté de vouloir tout comprendre en théorie avant de commencer, et que j'ai accepté d'apprendre en construisant. Si tu es en train de lire cet article en te reconnaissant un peu trop, reste. Ce texte est pour toi. Le déclic : comprendre en construisant Ce qui m'a débloquée, ce n'est pas un énième tutoriel. C'est une idée toute bête : créer un conteneur qui fait quelque chose, même minuscule, pour voir concrètement ce que Docker permet de faire. J'ai appelé le projet "boxeur" ; une image basée sur Alpine qui exécute en boucle un script Bash et écrit des logs. Pas de grand plan au départ. Mais à mesure que j'avançais, les concepts clés de Docker se sont mis en place un par un : ce qu'est une image, ce qu'est un conteneur, comment ils communiquent, où vivent les données. Coder, lancer, observer ce qui casse, comprendre pourquoi c'est cette boucle qui m'a fait passer de "je regarde des vidéos sur Docker" à "je sais ce que je fais quand j'utilise Docker". C'est là que j'ai compris un principe qu'Endah n'arrêtait pas de me répéter : sortir du tutorial hell. Regarder des vidéos, c'est confortable, mais ça reste passif. Taper docker run pour la première fois, lire l'erreur que ton terminal te renvoie, et comprendre ce qu'elle signifie, c'est ça qui construit une vraie compréhension du système. Les galères (et ce qu'elles m'ont appris sur Docker) Git 403 : mon premier mur Avant même de toucher à Docker, j'ai buté sur Git. Un bête 403 Forbidden en essayant de pousser mon code. La solution : générer un Personal Access Token sur GitHub, parce que les mots de passe classiques ne suffisent plus pour l'authentification en ligne de commande. Ça m'a forcée à comprendre comment GitHub gère l'authentification aujourd'hui, pas juste à copier une commande. Des logs qui n'existaient pas docker logs boxeur... rien. Un terminal désespérément vide. J'ai mis un moment à comprendre pourquoi : mon script écrivait ses logs dans un fichier à l'intérieur du conteneur, pas sur la sortie standard. Or Docker ne capture que ce qui sort sur stdout c'est une distinction fondamentale entre "écrire un fichier de log" et "logger au sens Docker du terme". J'ai donc utilisé une autre approche : lire le fichier directement depuis l'intérieur du conteneur. docker exec boxeur_mentor cat /var/log/boxeur.log  Et là, les logs sont apparus. Cette galère m'a appris comment Docker capture réellement les flux de sortie, et pourquoi la convention "logguer sur stdout" existe dans l'écosystème des conteneurs. Alpine n'est pas Ubuntu J'ai voulu installer Nginx et j'ai tapé apt-get install nginx par réflexe. Erreur immédiate. Alpine n'utilise pas apt-get, mais son propre gestionnaire de paquets : apk. apk add --no-cache nginx Petit détail, grande leçon : chaque image de base a son propre système et son propre gestionnaire de paquets. Ça m'a poussée à comprendre ce qui différencie réellement les distributions Linux utilisées comme images de base, plutôt que de copier des commandes sans en connaître le contexte. J'ai aussi bloqué sur un fichier nginx.conf mal écrit (une erreur dès la ligne 2), qu'il a fallu déboguer et réécrire proprement pour que Nginx accepte de démarrer. La faute de frappe qui m'a coûté une heure Au moment de pousser mon image sur Docker Hub, j'ai tagué mon image avec une majuscule : Dreatech/boxeur au lieu de dreatech/boxeur. Résultat, une erreur DNS aussi cryptique que frustrante : lookup Dreatech on 127.0.0.53:53: server misbehaving Docker Hub n'accepte pas les majuscules dans les noms de dépôt ; une convention de nommage héritée du système de registres de conteneurs. Une fois comprise, la correction était triviale : docker tag boxeur:latest dreatech/boxeur:latest docker push dreatech/boxeur:latest Ce que je retiens vraiment Au-delà des commandes, ce projet m'a permis de comprendre en profondeur plusieurs concepts fondamentaux de Docker : Image vs conteneur : l'image est la recette figée ; le conteneur est l'instance qui tourne, vivante, modifiable, jetable. Cette distinction change la façon dont on pense l'architecture d'une application conteneurisée. Docker Compose comme outil d'orchestration : en faisant communiquer mon "boxeur" et un "observateur" chargé de surveiller ses logs, j'ai compris comment Compose gère les dépendances entre services et le réseau interne qu'il crée automatiquement. Les volumes et la persistance des données : un bind mount simple, mais qui illustre bien pourquoi la persistance est un problème à part entière quand les conteneurs sont par nature éphémères. Le poids des images comme critère d'architecture : Alpine pèse environ 7 Mo contre une centaine de Mo pour une image basée sur Ubuntu. Comprendre cet écart m'a fait réaliser l'impact direct du choix d'image de base sur la vitesse de build et de déploiement. Et puis, il y a eu ce moment précis : docker run -d --name boxeur_mentor dreatech/boxeur:latest Mon image, celle que j'avais mis du temps à comprendre et à construire, tournait enfin ; publiée, accessible, réelle. Le rôle du mentorat Rien de tout ça ne serait arrivé aussi vite sans l'accompagnement d'Endah, ma mentor dans le cadre du programme CloudHer, porté par Women Innovating In Cloud Africa (WIICA). Ses rappels réguliers m'ont poussée à sortir de la phase de lecture passive pour passer à la pratique ; pas en me donnant les réponses, mais en m'orientant vers les bonnes questions à me poser. Un bon mentorat, ce n'est pas qu'on fasse le travail à ta place. C'est qu'on te rappelle que tu es capable de comprendre le sujet toi-même, même quand tu doutes d'y arriver. Ce que je dirais à la moi d'il y a 30 jours Si tu débutes en DevOps et que Docker te semble être une montagne : N'attends pas de tout comprendre en théorie avant de commencer. Lance docker run hello-world, puis va lire pourquoi ça fonctionne comme ça a fonctionné. L'erreur fait partie du chemin d'apprentissage. Un 403, un apk au lieu d'un apt-get, un tag mal écrit — chaque erreur t'oblige à comprendre un mécanisme que tu aurais pu ignorer sinon. Construis quelque chose pour comprendre un concept, pas pour produire un résultat. Mon "boxeur" ne sert à rien de productif, mais c'est le projet qui m'a fait vraiment saisir ce que Docker fait et pourquoi. Entoure-toi de quelqu'un qui challenge ta compréhension. Le mentorat m'a poussée à expliquer ce que je faisais, pas juste à le faire. Pour finir Mon image est disponible sur Docker Hub : dreatech/boxeur. Le premier docker run, ce n'était pas difficile parce que la syntaxe est compliquée — mais parce qu'il faut accepter d'apprendre un système par la pratique, en tolérant de ne pas tout maîtriser dès le départ. Si toi aussi tu as un projet qui prend la poussière depuis des semaines parce que tu attends de tout comprendre avant de te lancer : prends le temps qu'il faut pour bien saisir les bases, puis lance la première commande. Tu es aussi en train d'apprendre Docker ou le DevOps ? Dis-moi en commentaire sur quoi tu bloques en ce moment;je serais ravie d'en discuter. Et si cet article t'a parlé, un partage aide énormément à faire connaître ce genre de retour d'expérience !