Voici une situation qui peut très vite devenir irritante : vous avez développé plusieurs applications web dans un même repository Azure DevOps (dans mon cas : Blazor, et WebAPI). Vous souhaitez les publier via Azure Pipeline. Vous utilisez donc le template .net core par défaut et y ajoutez une tâche [email protected] avec la commande publish. Cependant au moment de consulter les artefacts produits, vous vous rendez compte qu’une seule application est présente.

Chaque nouvelle version de .net arrive avec son lot de rumeurs et d’idées reçues. Dernièrement, j’ai lu sur Reddit qu’il était impossible de migrer de .net framework vers .net 7. Jouant avec .net depuis ses débuts, je suis choqué par cette affirmation sans véritable fondement.

Heureusement, cela n’est pas vrai.

Depuis quelques années, je joue régulièrement avec un mixe de services Azure et on-premise sous Hyper-V. Dernièrement, je suis tombé sur un problème de stabilité qui m’a dérouté.

Le problème

Un cluster Kubernetes bâti sur RKE2 perdait régulièrement des nœuds (freeze, ou reboot qui n’aboutit pas et qui oblige l’arrêt brutal de la VM). Malheureusement, les logs de mes VM ne contenaient aucune erreur.

La solution

Ce cas de figure ne m’était jamais arrivé avec les clusters que j’avais installés avec kubeadm ou kubic. J’ai donc cherché l’élément qui différait. Je me suis rendu compte que la documentation de RKE2 manquait d’une recommandation que j’ai pu trouver sur tous les cluster Kuberntes que j’avais testés. Celle-ci conseille de désactiver le SWAP.

Après désactivation du SWAP sur l’ensemble des VM constituant mon cluster, celui-ci est devenu stable (plus aucun freeze ou problème de reboot).

Oui, j’ai bien conscience que le fait d’utiliser le mot "toujours" dans ce titre va m’attirer des problèmes. S‘il vous plait, prenez bien le temps de lire l'article en entier afin de comprendre le raisonnement qui m’a conduit à choisir ce titre.

J’ai beau être développeur .net depuis longtemps, je n’ai pas toujours utilisé Azure DevOps et ses prédécesseurs. Durant les années où je faisais du consulting, ceci était une véritable force.

Au fil du temps, j’ai été amené à faire un constat que je n’attendais pas. Il y a un problème qui finit toujours par se produire une fois la migration terminée : Azure DevOps s’adapte plus rapidement aux tendances du marché. Il intègre rapidement de nouveaux produits tiers, de nouvelles méthodes de travail, et de nouvelles fonctionnalités.

La belle plateforme que l’on a choisie devient alors un frein. Il faut savoir rester lucide et honnête. J’ai rencontré des décideurs qui ne voulaient pas admettre que leur solution d’ALM, DevOps, ou gestion de projet / ticketing était dépassée. Bien souvent, ce sont les mêmes qui ne voient pas l’intérêt de déployer les mises à jour, ou d’effectuer les migrations des produits qu’ils ont eu même choisis (qui a dit Log4J?).

Pendant de nombreuses années, le marché de la virtualisation a été considéré comme étant stable.

Et puis patatras :

• Broadcom rachète VMware. Ce qui fait peur à beaucoup de monde.
• Après des années d’immobilisme, Oracle change le modèle de licence du pack d’extension (celui-ci devient payant pour les usages professionnels).

Dans ce contexte, nombre d’entreprises se posent la question de trouver une solution alternative viable.