DevOps

Une requête qui prend 200ms sur votre base de données prend toujours 200ms la millionième fois que quelqu’un l’exécute, et chacune de ces exécutions se dispute les mêmes connexions, le même I/O disque et le même CPU. Redis garde la réponse en mémoire, sur un serveur qui ne fait que ça, si bien que la millionième lecture coûte un aller-retour réseau au lieu d’un plan de requête. Ce que Redis fait réellement comme cache Redis est un magasin clé-valeur en mémoire. Les valeurs vivent en RAM, donc les lectures et écritures prennent moins d’une milliseconde, contre les dizaines ou centaines de millisecondes que coûte une requête relationnelle dès que des jointures, des index sous pression ou un pool de connexions chargé entrent en jeu. Il se place à côté de votre base de données, pas à sa place : votre application interroge d’abord Redis et ne va à la base de données que si Redis n’a pas la réponse. ...

Ce qui se trouve entre le navigateur et votre app Pointez votre navigateur vers example.com et la requête ne touche jamais le processus qui exécute votre code. Elle rencontre d’abord autre chose : un serveur qui lit la requête, décide quel backend doit répondre, la lui transmet, puis renvoie la réponse comme s’il l’avait produite lui-même. Ce serveur, c’est un reverse proxy. Nginx, Caddy, Traefik et HAProxy font tous ce travail, tout comme le load balancer placé devant un cluster Kubernetes. Le schéma ne change jamais : les clients ne parlent qu’au proxy, à rien d’autre. Les serveurs réels restent derrière, en nombre quelconque et où qu’ils tournent. ...

Vous faites un pull du dernier main et Git s’arrête avec CONFLICT (content): Merge conflict in checkout.js. Vous résolvez le conflit, et le log affiche maintenant un commit nommé Merge branch 'main' into feature/checkout, posé au-dessus des trois commits que vous aviez réellement écrits. Quatre commits, un seul changement réel. Un collègue qui lit cet historique le mois prochain ne peut pas savoir lequel est lequel. git merge et git rebase répondent à la même question : comment mettre ma branche à jour par rapport aux changements faits ailleurs. Ils laissent des traces très différentes, et choisir le mauvais sur une branche partagée cause de vrais dégâts. ...

docker build && docker push depuis votre poste fonctionne tant que personne d’autre n’a besoin de publier la même image, ou tant que cela n’a pas à se produire à chaque merge sans que vous soyez devant le clavier. GitHub Actions exécute cette build sur les runners de GitHub, tague l’image selon ce qui a déclenché le workflow, et la publie sur un registry depuis lequel votre étape de déploiement peut faire un pull. Rien ne tourne en local. ...

Exécutez kubectl run nginx --image=nginx:1.27 et Kubernetes crée un seul Pod, nommé nginx. Supprimez-le avec kubectl delete pod nginx et il disparaît pour de bon — personne ne le remarque, personne ne le remplace. Un Pod est la plus petite unité déployable dans Kubernetes : un ou plusieurs conteneurs qui partagent un namespace réseau et un ensemble de volumes, planifiés ensemble sur un seul nœud. Ce Pod isolé est une impasse en production. Si le conteneur qu’il contient plante, le kubelet le redémarre sur place. Si le nœud redémarre, ou si quelqu’un supprime le Pod, rien ne le recrée. Un Pod nu ne sait pas qu’il est censé continuer à exister. ...

Où finissent les variables d’environnement d’un conteneur Démarrez un conteneur avec -e DB_PASSWORD=hunter2 et lancez docker inspect dessus : 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Le mot de passe reste là en clair, lisible par quiconque a accès au socket Docker, par docker exec api env, et par n’importe quel processus qui tourne dans le conteneur. Ce n’est pas un bug : c’est exactement à ça que servent les variables d’environnement. Le problème, c’est de les utiliser pour des valeurs qui ne devraient jamais être aussi visibles. ...

Pourquoi une image Docker pèse dix fois plus que l’application Un service Node avec quelques centaines de kilo-octets de code source finit dans une image de plus de 1 Go. C’est le résultat normal d’un build qui fonctionne, pas une erreur sur une ligne précise. Le poids vient d’une image de base qui traîne un système d’exploitation complet, une chaîne d’outils de build que l’application en cours d’exécution n’appelle jamais, et un cache de gestionnaire de paquets que personne n’a demandé au build de supprimer. ...

Ce que vous coûte un mauvais Dockerfile 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Quatre lignes, et chacune vous coûte quelque chose. docker build relance npm install à chaque changement de code, parce que COPY . . casse le cache des couches avant même que l’étape d’installation ait une chance d’être réutilisée. L’image finale traîne toute la base Debian, l’arbre complet de node_modules avec les dépendances de développement, et tous les outils de build que npm install a récupérés pour compiler des modules natifs. Rien n’est jeté. Le conteneur tourne en root, parce que rien ne l’en empêche, et node:latest veut dire que l’image de base peut changer entre deux builds sans laisser de trace de ce que vous avez réellement livré. ...

Pourquoi deux conteneurs sur le même hôte ne se voient pas par défaut Lancez Postgres et votre API avec un simple docker run, et l’API n’arrive pas à joindre la base de données, alors que les deux conteneurs tournent sur la même machine. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Les deux atterrissent sur la bridge par défaut de Docker, celle que reçoit tout conteneur Docker sauf indication contraire. Ils obtiennent une adresse IP. Ce qu’ils n’obtiennent pas, c’est un moyen de se trouver par leur nom : l’API devrait donc coder en dur l’IP interne de la base de données, une adresse qui change à chaque redémarrage du conteneur. ...

Le problème que Compose résout Une vraie application, c’est rarement un seul conteneur. Une API web a besoin d’une base de données, la base de données a besoin d’un volume pour que ses données survivent à un redémarrage, puis vous ajoutez un cache Redis et un worker en arrière-plan. Cela fait quatre commandes docker run, chacune avec ses options pour les ports, les volumes, les variables d’environnement et un réseau partagé. Dans le bon ordre. Chaque fois que vous vous remettez au travail. ...