Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Depuis plusieurs mois, la communauté Kubernetes s'agite autour de Geteway API, et de différentes annonces de dépréciation des Ingress. On nous vente les mérites de la Gaeway API. On nous explique comment déclarer les Gateway, et les routes. Mais rarement on répond aux questions du monde réel.

Mon constat

À force d’en discuter, je me suis rendu compte qu'il y avait quelques sujets qui n'étaient pas clairs pour tout le monde.

Par exemple :

• Oui, on peut faire cohabiter Ingress, et Gateway API.
• Oui, il y a des produits qui fournissent à la foi Ingress, et GateWay API.
• Non, les Ingress ne vont pas disparaitre (du moins cela n'a pas encore été annoncé).
• Non, la totalité des templates Helm ne supporte pas Gateway API (cela risque de prendre un peu de temps avant que la communauté ne change ses habitudes… et ce, même pour les projets maintenus par de grands éditeurs).
• Non, tous les contrôleurs ne supportent pas tout Gateway API.

En pratique

Personnellement, j'ai opté pour une démarche s'inscrivant dans le temps (oui, désolé, je ne maintiens plus de cluster pro, juste mes clusters pour mes usages personnels, RKE2 /AKS). Ne pouvant passer un temps fou à gérer la bascule, et ne pouvant la faire en une foi, j'ai opté pour une démarche par itérations sur plusieurs mois. La totalité des applications reste disponible durant toute la durée des opérations.

1. Installer un cluster de test pour valider la cohabitation Ingress / Gateway API, et choisir l'outil idéal (le nouveau contrôleur d'Ingress dans un premier temps).
2. Tester, tester, tester (galérer, galérer, galérer jusqu'à trouver le contrôleur d'Ingress qui fait aussi très bien de la Gateway API).
3. Installer la solution miracle sur le cluster de production.
4. Basculer les Ingress existants vers le nouveau contrôleur d'Ingress.
5. Supprimer l'ancien contrôleur d'Ingress.
6. Déclarer une, ou plusieurs Gateway.
7. Basculer progressivement les applications d'Ingress vers HttpRoute (utiliser une solution GitOps comme Argo CD, pour se simplifier la vie).
8. Identifier les templates Helm qui ne supportent pas Gateway API. Supprimer les Ingress intégrés aux templates, et déclarer des Ingress custom (là encore GitOps "est ton ami"). Personnaliser les Ingress si besoin (pour l'authentification par exemple), puis les remplacer par des routes.

Dans mon cas, j'ai choisi Traefik. Venant de Haproxy, je n'étais pas concerné par la problématique de dépréciation de nginx. Mais j'ai préféré Traefk pour une raison simple : contrairement aux autres contrôleurs d'Iingress qui privilégient les annotations, Trafik sait utiliser des CRD (middleware). Ces middlewares peuvent être utilisés avec Ingress, et Gateway API. Autre avantage, les middlewares peuvent être partagés entre Ingress, et namspaces. J'ai donc créé quelques middlewares pour inclure une authentification, et pour personnaliser quelques entêtes HTTP.

Après avoir compris comment convertir une annotation du contrôleur d'Ingress précédent vers le middleware, il n'y avait plus rien à faire. Horsmis binder les middlewares vers mes nouveaux Ingress. Lors de la migration, le middleware était conservé, et associé à la nouvelle route. Seul l'Ingress disparaissait.

Conclusion

Il y a certainement d'autres approches possibles. Celle-ci me semble intéressante, car elle privilégie la stabilité, la sécurité, et la confiance. À aucun moment on ne peut ressentir l'impression d'avoir une épée de Damoclès au-dessus de soi. À aucun moment, on ne court le risque de perdre une fonctionnalité qui n'est pas encore supportée par Gateway API. Plus important encore, à aucun moment on ne reste avec un contrôleur d'Ingress déprécié en production.

La qualité de code a toujours été un sujet épineux. Nombre de sociétés qui ne s'y sont jamais vraiment intéressées, et qui veulent soudainement sauter le pas, passent d'un outillage quasi inexistant à un outillage qui finit par décourager les développeurs.

Dans une démarche DevOps, ceci n'est pas envisageable. Heureusement, il existe un juste milieu. Du moins, un bon outil dédié à la qualité de code est censé nous permette d'avoir le contrôle sur les règles appliquées (sélection, affichage, documentation, aide à la résolution...). Avant de mettre en place un tel outil, il faut donc prendre un peu de temps pour découvrir ses possibilités, et vérifier qu'elles sont bien en adéquation avec le besoin. Ceci ne se fait pas en 5 minutes, car plus on a de projets, et de technologies différentes, et plus on a de prérequis à valider.

La solution 100% .net

En attendant, pour les développeurs .net il est possible d'améliorer la qualité de son code sans installer quoi que ce soit. Il suffit de configurer Code Analysis. La fonctionnalité n'est pas nouvelle, mais je suis toujours étonnée de rencontrer des développeurs ne la connaissant pas.

En pratique

Pour profiter de Code Analysis pour la totalité des projets d'une solution, le plus simple consiste créer un fichier Directory.Build.props à côté de sa solution, et d'y glisser les propriétés suivantes (pour forcer l'analyse lors de la build) :

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
<AnalysisMode>minimum</AnalysisMode>

On peut ensuite jouer avec la propriété AnlasysisMode comme spécifié ici : Code analysis in .NET | Microsoft Learn

La documentation peut aussi vous permettre de choisir des règles à appliquer au cas par cas.

Pour aller un peu plus loin

Si vous n'avez jamais utilisé Code Analysis, il ne faut pas avoir peur de procéder par paliers. Dans un premier temps on peut choisir un niveau minimum. Dès que la solution est conforme, on peut passer au niveau suivant.

Personnellement, je préfère ne pas casser la build alors qu'une équipe adopte Code Analysis. J'opte donc pour une solution en deux temps :

1. La compilation en mode Release doit se faire avec un niveau de règle accepté par tous.
2. La compilation en mode Debug peut se faire avec un mode un peu plus exigeant.

De la sorte, lors de leur travail quotidien, les développeurs ont un IDE qui leur remonte des warnings pour les encourager à améliorer le niveau de qualité du projet. Attention : on parle de quelques warnings, pas des milliers. Il ne faut pas décourager les développeurs.

Exemple de configuration possible pour cela :

<PropertyGroup Condition="$(Configuration)=='Debug'">
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisMode>recommended</AnalysisMode>
</PropertyGroup>
<PropertyGroup Condition="$(Configuration)=='Release'">
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  <AnalysisMode>minimum</AnalysisMode>
</PropertyGroup>

Les plus téméraires voudront peut-être ajouter un EnforceCodeStyleInBuild. C'est une histoire de gouts. Mais attention, il faut que l'équipe adhère à cette pratique. Il ne faut pas qu'elle le subisse. Faute de quoi, le niveau de qualité ne pourra pas augmenter.

<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>

Migrer une ferme Azure DevOps d'un domaine à l'autre, demande un peu de doigté. Surtout pour ce qui concerne la gestion des utilisateurs.

Heureusement, la CLI permet de déplacer les utilisateurs  d'un domaine à l'autre. Cela est plutôt bien expliqué dans la documentation que l'on peut consulter ici.

Mais il arrive que cela ne fonctionne pas pour quelques utilisateurs (petites différences dans le login, nom changé… etc…).

Pour cela, on peut compter sur la commande qui suit :

# Mapping de l'utilisateur
.\TFSConfig Identities /change /fromdomain:AncienDomaine/todomain:NouveauDomaine /account:AncienLogin /toaccount:NouveauLogin

Malheureusement, dans le cas d'une migration d'un domaine vers un workgroup, cela ne fonctionne pas. On lance les diverses commandes, mais les utilisateurs ne récupérèrent pas leurs droits, espaces de travail, requêtes, tableaux de bord, branches, etc.

Fort heureusement, il suffit de faire un petit tour dans la base de données de configuration pour corriger cela (par défaut, il s'agit de la base TFS_Config)

Dans un premier temps, il faut identifier les lignes relatives aux différentes identités de notre utilisateur. Exemple :

SELECT *
FROM tbl_Identity
WHERE AccountName LIKE '%NouveauLogin%'

En même temps, on peut utiliser powershell pour recouper ces informations avec le nouveau SID de l'utilisateur.

# Vérification du SID Windows de l'utilisateur local
Get-LocalUser -Name "NouveauLogin" | Select Name, SID

Avec ces informations, vous devriez pouvoir identifier :

• L'ancien ID
• L'ancien SID
• Le nouvel ID
• Le nouveau SID

Ensuite, pour intervertir les identités, il suffit d'échanger les ID.

Personnellement, j'opte pour une solution simple en trois étapes:

1. Affecter un faux ID à la ligne contenant le nouveau SID.
2. Affecter le nouvel ID à la ligne contenant l'ancien SID.
3. Affecter l'ancien ID à la ligne contenant le nouveau SID.

Exemple :

UPDATE tbl_Identity
SET [id]='F5331C74-6F8F-40C2-8F8E-000000000000'
WHERE [sId]='S-1-5-12-383200802-4186732323-4104849335-7817'
 
UPDATE tbl_Identity
SET [id]='AF9C2B4C-E4A4-43A9-B5E4-E9337DA9D900'
WHERE [sId]='S-1-5-33-2491080940-717456908-2923986041-1018'
 
UPDATE tbl_Identity
SET [id]='F5331C74-6F8F-40C2-8F8E-F3F943EF99A5'
WHERE [sId]='S-1-5-12-383200802-4186732323-4104849335-7817'

Aujourd'hui, le support des Builds Tools 2026 avec Azure Devops est un peu déroutant. Des projets .net 10 tournant sans problèmes, et certains projets .net Framework remontent des erreurs datant du passage de .net Framework 3.5 à 4.0.

Contrairement à leurs habitudes, les équipes de Microsoft ne semblent pas très synchronisées :

• Les agents de builds détectent bien les fonctionnalités de VS 2026, et les builds Tools 2026.
• Les taches ne détectent pas toutes les fonctionnalités de VS 2026, et les builds Tools 2026.

On se retrouve donc dans une situation où l'agent dit : "j'ai les bons outils, tu peux t'exécuter ici",  et les tâches "je ne trouve pas les outils dont j'ai besoin, je vais faire avec ce que je trouve".

La solution simple, et sans modification des pipelines

Sur un serveur de build disposant des Builds Tools 2026, et 2022, on ne se rend compte de rien. Une solution temporaire peut donc consister à utiliser les deux versions de ses outils. La version 2026 étant indispensable pour utiliser .net 10.

La solution temporaire, avec modification des pipelines

Une solution ne s'appuyant que sur les Build Tools 2026 consiste à spécifier les chemins vers les binaires (ex: msbuildLocation pour MSBuild@1, et vstestLocation pour VSTest@3).

Je ne suis pas du tout fan de cette solution. Quand on est habitué à utiliser des produits de Microsoft, on aime que tout fonctionne sans avoir à tout retoucher à chaque montée de version de l'outillage.

Remarque : Le fait de mettre des chemins vers des binaires, en dure dans une build, n'est pas une bonne pratique. Il faut cependant noter que cette approche est utilisée par nombre de solutions concurrentes comme GitLab, ou Jenkins...

Ce qui est une solution temporaire "peu optimale" pour DevOps, est une solution permanente pour d'autres.

Aujourd'hui, je vous propose d'aborder un sujet très peu documenté. Je dispose d'un serveur Azure DevOps qui ne fait pas partie d'un domaine (ne cherchez pas la raison, c'est une contrainte avec laquelle je dois faire).

Par défaut les agents ne sont pas en mesure de s'enregistrer auprès du serveur.

L'habituelle authentification Windows par défaut via NTLM ou Kerberos ne passe pas. Pour résoudre le problème, il faut modifier la configuration du site IIS hébergeant DevOps afin d'utiliser Negociate. La procédure est documentée ici : Azure Devops Docs · GitHub.

Il faut ensuite adapter les arguments passés au script config.md comme ceci (en adaptant les identifiants, le nom de l'agent, et l'URL de la collection DevOps) :

.\config.cmd  --auth negotiate --userName "login" --password "password" --pool Default --agent build1 --acceptTeeEula --runasservice --work '_work' --url 'http://serveur.devops/collection'