Dans cette note, je souhaite présenter ma doctrine de mise à jour d'OS de serveurs.

Je ne traiterai pas ici de la stratégie d'upgrade pour un Cluster Kubernetes.

La mise à jour d'un serveur, par exemple, sous un OS Ubuntu LTS, peut être effectuée avec les commandes suivantes :

• sudo apt upgrade -y
• ou sudo apt dist-upgrade -y (plus risqué)
• ou sudo do-release-upgrade (encore plus risqué)

L'exécution d'un sudo apt upgrade -y peut :

• Installer une mise à jour de docker, entraînant une interruption des services sur ce serveur de quelques secondes à quelques minutes.
• Installer une mise à jour de sécurité du kernel, nécessitant alors un redémarrage du serveur, ce qui entraînera une coupure de quelques minutes.

Une montée de version de l'OS via sudo do-release-upgrade peut prendre encore plus de temps et impliquer des ajustements supplémentaires.

Bien que ces opérations se déroulent généralement sans encombre, il n'y a jamais de certitude totale, comme l'illustre l'exemple de la Panne informatique mondiale de juillet 2024.

Sachant cela, avant d'effectuer la mise à jour d'un serveur, j'essaie de déterminer quelles seraient les conséquences d'une coupure d'une journée de ce serveur.

Si je considère que ce risque de coupure est inacceptable ou ne serait pas accepté, j'applique alors la méthode suivante pour réaliser mon upgrade.

Je n'effectue pas la mise à jour le serveur existant. À la place, je déploie un nouveau serveur en utilisant mes scripts automatisés d'Infrastructure as code / GitOps.

C'est pourquoi je préfère éviter de nommer les serveurs d'après le service spécifique qu'ils hébergent (voir aussi Pets vs Cattle). Par exemple, au lieu de nommer un serveur gitlab.servers.example.com, je vais le nommer server1.servers.example.com et configurer gitlab.servers.example.com pour pointer vers server1.servers.example.com.

Ainsi, en cas de mise à jour de server1.servers.example.com, je crée un nouveau serveur nommé server(n+1).servers.example.com.

Ensuite, je lance les scripts de déploiement des services qui étaient présents sur server1.servers.example.com.

Idéalement, j'utilise mes scripts de restauration des données depuis les sauvegardes des services de server1.servers.example.com, ce qui me permet de vérifier leur bon fonctionnement. Ensuite, je prépare des scripts rsync pour synchroniser rapidement les volumes entre server1.servers.example.com et server(n+1).servers.example.com.

Je teste que tout fonctionne bien sur server(n+1).servers.example.com.

Si tout fonctionne correctement, alors :

• J'arrête les services sur server(n+1).servers.example.com ;
• J'exécute le script de synchronisation rsync de server1.servers.example.com vers server(n+1).servers.example.com ;
• Je relance les services sur server(n+1).servers.example.com
• Je modifie la configuration DNS pour faire pointer les services de server1.servers.example.com vers server(n+1).servers.example.com
• Quelques jours après cette intervention, je décommissionne server1.servers.example.com.

Cette méthode est plus longue et plus complexe qu'une mise à jour directe de l'OS sur le server1.servers.example.com, mais elle présente plusieurs avantages :

• Une grande sécurité ;
• L'opération peut être faite tranquillement, sans stress, avec de la qualité ;
• Une durée de coupure limitée et maîtrisée ;
• La possibilité de confier la tâche en toute sécurité à un nouveau DevOps ;
• La garantie du bon fonctionnement des scripts de déploiement automatisé ;
• La vérification de l'efficacité des scripts de restauration des sauvegardes ;
• Un test concret des scripts et de la documentation du Plan de reprise d'activité.

Si le serveur à mettre à jour fonctionne sur une Virtual instance, il est également possible de cloner la VM et de tester la mise à niveau. Cependant, je préfère éviter cette méthode, car elle ne permet pas de valider l'efficacité des scripts de déploiement.

#JaiLu

Rich Harris explains this clearly. JSDoc for writing a lib. TypeScript for writing an app. (from)

Ce conseil entre en opposition avec ce que j'ai écrit en octobre 2023 :

Si je dois coder et publier une librairie sur npm alors, je choisis TypeScript.
Quand je dis librairie, je parle de librairie qui contient des classes, des fonctions ou des composants importés par d'autres projets.

Pourquoi est-ce que je choisis d'utiliser TypeScript pour les librairies ?

• Je permets aux développeurs qui utilisent TypeScript dans leur projet, de pouvoir bénéficier de la documentation, l'autocomplétion, la détection des erreurs… de la librairie que j'aurais mise à disposition ;
• Je n'ai pas vérifié, mais je pense que le typage de TypeScript permet à des outils d'auto générer une grande partie de la documentation d'une librairie.

Ce conseil entre aussi en opposition avec ce second élément que j'ai écrit en octobre 2023 :

Si je dois coder une application web, alors pour le moment, je choisis JavaScript.
Le code implémenté dans une application web, n'est généralement pas utilisé par des utilisateurs "externes". Par conséquent, je ne trouve pas très important de mettre à disposition une documentation aux autres développeurs. Je pense qu'à petite taille, l'effort ne vaut pas la peine. Ma réponse est peut-être différente si 10, 20… développeurs contribuent à la même base code 🤔.

• Généralement, le code d'une application web est plutôt simple, beaucoup de CRUD et peu de librairie complexe.
• Pour le moment, je pense que l'effort d'ajouter le boilerplate code de typage TypeScript (importer les types, d'ajouter le typage dans le code) ne sera pas compensé par les fonctionnalités de détection d'erreurs , d'autocomplétions et de refactoring que permet TypeScript.

Je pense qu'il serait bon que je revoie ma doctrine d'artisan développeur sur ce sujet.

Cela fait depuis décembre 2023 que je souhaite traduire l'article The Platinum Rule de Shawn Wang (dit swyx), c'est chose faite :

Voici la Traduction de "The Platinum Rule" 🙂.

Pourquoi avoir traduit cet article ?
Parce que quand je l'ai lu, il m'a fait beaucoup réfléchir parce que j'ai réalisé que j'ai été depuis tout petit très conditionné par la règle d'or. J'essayais au maximum de la respecter et j'imaginais que si tout le monde la respectait, tout irait pour le mieux… mais avant de lire cet article, c'est bête à dire, mais je n'avais pas réalisé qu'en pratique, cela ne fonctionnait pas.

En lisant cet article, je pense qu'il est bon de garder à l'esprit que Shawn Wang (dit swyx) est un développeur et je pense qu'il a écrit cet article en rapport à des difficultés de travailler en équipe sur des projets de développement.

Pensez, par exemple, aux conventions de coding style et à bien d'autre sujets !

N'hésitez pas à venir échanger avec moi pour me partager votre avis sur le sujet, cela m'intéresse 🙂.

#JaiLu l'article Don’t Build A General Purpose API To Power Your Own Front End.

TL;DR YAGNI, unless you’re working in a big company with federated front-ends or GraphQL.

It’s popular in web dev nowadays to build a backend that serves JSON, and a frontend that renders the app. This is fine. I’m not the biggest fan, but it’s really okay. Except it’s not okay if you think that your backend needs to be designed like a generic public API. This will not save you time.

Je partage à 100% cette opinion.

Ma traduction de l'article The Platinum Rule de Shawn Wang (dit swyx) avec quelques modifications et ajouts qui me permettent — peux-être à vous aussi — de mieux comprendre l'article.

La traduction commence ici ⬇️

---

Vous avez entendu parler de la la règle d'or : « Traiter les autres comme on voudrait être traité » ou « Ne fais pas aux autres ce que tu ne voudrais pas qu'on te fasse ».

Je pense qu'elle est incomplète. Je pense que les gens fonctionnent en réalité selon une norme plus élevée. Je propose la Règle de Platine : Traiter les autres comme ILS veulent être traités.

La Règle de Platine

Pour comprendre comment j'en suis arrivé là, il faut savoir que j'ai des traits de personnalité particuliers qui rendent la règle de Platine pertinente pour moi. Je préfère la franchise. Mon seuil pour considérer quelque chose comme "terminé" est plus bas que le vôtre. J'aime les personnes conscientes d'elles-mêmes et l'humour. Je préfère l'amour vache.

Cela signifie que je préfère livrer une chose imparfaite et itérer plutôt que de mettre de l'ordre dans mes affaires. Cela signifie que je dis les choses sans les adoucir pour les rendre plus agréables à entendre. Cela signifie que je me moque de moi-même et de tout ce à quoi je m'identifie fortement, ce qui peut parfois inclure les personnes avec lesquelles je travaille. Cela signifie que je suis souvent trop dur à l'égard de quelque chose qui me tient à cœur.

En lisant ce paragraphe — ci-dessus — certains d'entre vous ont sans doute pensée « ok, et alors ? » sans voir ce qu'il ne va pas dans ce comportement. Voici ce qui ne va pas.

Pourquoi la règle d'or pose problème ?

Imaginons que nous simplifions les préférences humaines en deux catégories : « plus particulières » et « moins particulières ».
Et supposons que les interactions humaines se résument à deux aspects : « comment vous traitez les autres » et « comment vous voulez être traité ».
La règle d'or — traiter les autres comme vous voulez être traité — suggère que les personnes plus particulières devraient traiter les autres selon leurs propres standards élevés — peu importe comment vous définissez ces standards.
C'est une bonne chose car cela rend les personnes particulières très prévenantes. Cependant, si les personnes moins particulières appliquaient cette règle et traitaient les autres comme elles veulent être traitées, elles paraîtraient vraiment désagréables aux yeux des personnes plus particulières, qui ne pourraient pas travailler avec elles.

Par exemple, imaginez quelqu'un qui aime que tout soit toujours bien rangé et organisé. Cette personne, très particulière sur la propreté, pourrait être très attentive à maintenir un environnement propre et ordonné pour tout le monde.
Cependant, si une personne qui ne se soucie pas autant du rangement appliquait la règle d'or et traitait les autres comme elle veut être traitée (c'est-à-dire sans se soucier de l'ordre), elle semblerait désordonnée et négligente aux yeux de la personne qui apprécie l'ordre. Cela créerait des tensions, car la personne qui aime l'ordre se sentirait frustrée et incapable de travailler efficacement avec l'autre.

Dans cet exemple, la règle d'or ne fonctionne pas bien, la personne qui aime l'ordre traite l'autre comme elle aimerait être traité, mais son souhaite ne se réalise pas !

Les nombres relatifs de personnes plus particulières et de personnes moins particulières n'ont pas d'importance - si ces personnes doivent travailler ensemble, elles doivent coexister dans le cadre d'un contrat social différent.

La règle de platine ?

Pour essayer de résoudre ce problème, je propose que la règle de platine soit ce contrat : traiter les autres comme ils veulent être traités.

D'un côté, cela semble relever de la plus simple politesse : bien sûr, il faut tenir compte des sentiments des autres. Utilisez leurs pronoms. Respecter leur autonomie et leur liberté.

D'un autre côté, cela peut sembler beaucoup trop accommodant - que faire si les gens abusent du système et veulent être traités de manière déraisonnable ? Il y a deux poids, deux mesures partout lorsqu'il s'agit d'intérêt personnel. Il faut bien tracer une ligne quelque part.

Elle est imparfaite, mais il est probable que le bon équilibre entre vous et moi se situe quelque part entre la Règle d'Or (empathie extrêmement centrée sur soi) et la Règle de Platine (accommodement extrêmement centré sur les autres).

---

La Règle d'Argent

En réfléchissant à cela dans un avion, j'ai également pensé à une belle conclusion pour ce message. Si la règle de platine est "meilleure" que la règle d'or, à quoi ressemblerait une règle d'argent ? (j'aime étendre les idées comme celle-ci, j'ai pris cela de Brian Chesky).

Une règle d'argent serait quelque chose qui est souvent considéré comme secondaire par rapport aux autres, mais qui reste important et précieux. Et sous la forme suivante : « Traitez x comme X veut être traité ».

Voici ma proposition pour une règle d'argent : Traitez-vous comme vous traitez les autres. Une belle inversion de la règle d'or.

Le framework des quatre tendances de Gretchen Rubin divise les gens en fonction de la façon dont ils répondent aux attentes intérieures et extérieures, ce qui semble tout à fait approprié à ce sujet. Les profils "Questioners" ont le plus besoin de la Règle de Platine. Mais les "Obligers" ont probablement le plus besoin de la Règle d'Argent.

Le souci de soi ne doit pas céder la place au sacrifice de soi.