DevOps

La suite de tests est au vert depuis trois semaines. Aujourd’hui, npm test échoue sur une assertion qui n’a rien à voir avec ce que vous venez de modifier, et git log v1.4.0..HEAD affiche 340 commits de quatre personnes depuis la dernière release dont quelqu’un était sûr qu’elle fonctionnait. Lire chaque diff vous coûte une journée entière. Faire des checkouts de commits au hasard va plus vite, mais ce n’est toujours pas un plan. ...

Ce que le DNS fait vraiment à chaque requête Chaque requête vers example.com commence par une recherche qui n’a rien à voir avec votre application : il faut d’abord transformer ce nom en adresse IP avant qu’un seul paquet TCP ne quitte la machine. Cette traduction, c’est le DNS, le Domain Name System, et elle intervient à chaque requête, que le client soit un navigateur, curl, ou un service backend qui en appelle un autre par son hostname. ...

Ce que TLS protège vraiment sur une connexion HTTPS Chargez une page en http:// en clair sur un réseau que vous ne contrôlez pas, un aéroport ou le routeur d’un café, et tout ce que vous envoyez circule en texte lisible. Le chemin de l’URL, les cookies, les champs du formulaire, le mot de passe dans un POST de connexion : n’importe qui sur ce réseau avec un sniffer de paquets les lit au passage. TLS, Transport Layer Security, est le protocole qui bloque cela. Il se place entre TCP et le protocole applicatif, si bien que quand HTTP commence à parler, la connexion est déjà chiffrée et rattachée à une identité serveur vérifiée. HTTPS, c’est HTTP exécuté sur cette connexion au lieu d’une connexion en clair. ...

Un endpoint de checkout qui redimensionne l’image d’un produit, envoie un email de confirmation et met à jour un moteur de recommandation avant de répondre 200 OK n’est jamais plus rapide que son étape la plus lente. Si l’une d’elles dépasse le délai, toute la requête échoue. Une file de messages permet à l’endpoint de confier ce travail sous forme de messages et de répondre immédiatement, pendant que des workers séparés les traitent à leur propre rythme. ...

Chaque ressource cloud que vous avez déjà créée en cliquant dans une console web (une VM, un load balancer, un enregistrement DNS) peut aussi être décrite dans un fichier texte et créée en une seule commande. Le fichier vit dans git, passe par une pull request, et reproduit le même setup sur un second compte sans que personne ait à se souvenir des neuf réglages changés à la main. C’est ce que fait Terraform. ...

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. ...