Configurer des VLAN avec des switchs Ubiquiti et Netgear

En 2022, la création de VLAN ne devrait pas poser de problèmes. Il y a malheureusement des fabricants dont l'interface de gestion manque de clarté et d'ergonomie. Dans le cas de Netgear, c'est pire que tout : l'interface n'est pas accessible aux personnes en situation de handicap.

Dans l'article qui suit, je vais partager avec vous la méthode à suivre afin de configurer des VLAN entre un switch Netgear GS116Ev2 et une Unify Dream Machine Pro d'Ubiquiti. Même si le matériel Netgear date un peu, l'interface de gestion ne diffère que sur le plan esthétique. La logique présentée ici reste d'actualité.

Si vous avez un peu de mal avec le vocabulaire qui suit, ou si la notions de VLAN ne vous parle pas trop, je vous conseille de lire mon article de vulgarisation : Back to the Basics : les VLA.

Pourquoi je n’installe presque aucune extension pour Azure Pipeline et Azure DevOps ?

Quand on m’interroge sur Azure Pipeline, il y a presque toujours une question relative aux extensions ou tâches que j’utilise. Aussi surprenant que cela puisse paraitre, je n’ai pas d’extensions à recommander. Je n’ai pas non plus d’extension que j’installe systématiquement.

Sérieusement ?

Dit comme cela, on peut se demander si j’utilise vraiment le produit.

Oui, j’utilise Azure Pipeline depuis ses toutes premières versions (si on compte aussi les produits qui l’ont précéder). À force de configurer des builds et pipelines de déploiements, je n’ai trouvé qu’une raison d’installer des extensions : s’interfacer avec un produit tièrs.

Le plus souvent, il s’agit de solutions liées à la qualité, la sécurité ou une API custom. Il s’agit donc d’un usage au cas par cas.

Et pour le reste ?

La marketplace Azure DevOps regorge d’extensions dédiées à la consultation, la transformation de fichiers ou encore la manipulation de configuration. Il en est aussi une multitude pour des opérations système. Mais je ne les installe pas non plus.

Il m’arrive d’en installer pour voir, et tester. Mais très souvent je me rends compte qu’il est possible de faire sans.

Exemple : pourquoi installer une tâche dédiée à vider un répertoire avant d’effectuer une copie de fichier ? Cela ne sert à rien quand on sait que la tâche de base dédiée à la copie a une option lui permettant de vider le dossier avant de procéder à la copie.

Et pour tout ce qui n’est pas possible avec les tâches de base ?

Pour tout le reste, j’utilise la tâche PowerShell. Celle-ci me permet de faire "inline", tout type d’action. Vu qu’il n’y a pas de limite à PowerShell, cette tâche peut tout faire.

Je ne m’impose que quelques règles :

  • Cette tâche ne doit jamais lancer un script ps1, psm1 ou autre. La build doit rester lisible. Le code doit donc être "inline". Il ne faut pas avoir besoin d’ouvrir un fichier externe pour savoir ce que la tâche fait réellement.
  • Cette tâche ne doit pas dépendre d’un outil tiers (la gestion des capacités doit rester de la responsabilité de l’agent Azure Pipeline).
  • Le script ne doit pas dépasser quelques lignes (la lisibilité de la build est impérative).
  • Le script ne doit pas contenir plus d’une condition (if, else, et c’est tout).
  • L’action entreprise doit être reproductible 100% du temps et toujours donner le même résultat (pour ne pas nuire à la logique "déclarative" d’Azure Pipeline).

Moralité

Si vous n’avez jamais utilisé PowerShell, prenez le temps d’y regarder avant d’installer quoi que ce soit sur Azure DevOps. Il n’est pas impossible que vous trouviez quelques lignes de scripts qui répondront à vos besoins.

Si vous respectez les quelques règles que je me suis fixées, vous ne devriez jamais vous tromper.

Jérémy Jeanson

Utiliser Visual Studio 2022 dans un Pipeline Azure DevOps Server

Actuellement, les pipelines d’Azure DevOps Server ne supportent pas directement le tooling de Visual Studio 2022 (Build Tools 2022). Plus exactement, ce sont les tâches qui ne savent pas utiliser ces outils. Même si les agents de build reconnaissent bien les capacités déployées via Visual Studio Installer 2022, les tâches sont incapables de les utiliser.

Avec Azure DevOps, il n’y a pas de problème. Ce souci est propre à la version on premise.

Des solutions ?

Visual Studio étant sorti il y a déjà quelques mois, il existe de nombreuses solutions de contournement. La plus efficace consiste à pousser manuellement des tâches compatibles. Bien évidemment, les agents de build doivent aussi être mis à jour (voir mon article sur le sujet).

Même si j’ai testé l’approche (et qu’elle fonctionne), il y a quelques détails qui me dérangent :

  • Quid du comportement du serveur lors de l’installation du prochain patch. J’ai déjà été bloqué avec un serveur incapable de migrer automatiquement. Je ne veux pas revivre la même aventure.
  • Les tâchent évoluent régulièrement, et Visual Studio installer pousse régulièrement des mises à jour. Comment être certain d’avoir toujours des versions compatibles ?
  • Je ne suis pas super chaud pour modifier un serveur qui fonctionne bien alors que des solutions plus simples existent.

Comment faire plus simple

Comme souvent avec les produits de Microsoft, le fait de connaitre l’historique d’un produit aide beaucoup. Dans le cas présent, il faut se souvenir qu’avant d’avoir les tâches .net core CLI, et Visual Studio Build, nous avions le bon vieux MS Build.

La tâche MS Build a l’avantage de pouvoir être paramétrée très finement. Il est entre autres possible de spécifier le chemin à utiliser pour trouver MS Build.

Pour un pipeline YAML, il suffit d’utiliser la propriété msbuildLocation.

# MSBuild
# Build with MSBuild
- task: [email protected]
  inputs:
    solution: '$/$(projectDirectory)/build.xml' 
    msbuildLocation: 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\amd64\'


Pour un pipeline Classic, il suffit de sélectionner l’option "Specify Location", et renseigner le champ "Path to MSBuild"

Option "Specify Location" selectionner, et "Path to MSBuild" renseigné

Conclusion

Dans quelques mois, nous devrions pouvoir utiliser les Builds Tools 2022 plus facilement.
En attendant : c’est dans les vieux pots que l’on fait les meilleures soupes ;)

Jérémy Jeanson

S’authentifier automatiquement à Azure DevOps Server avec Edge

Par défaut, si vous tentez de vous connecter à un site Azure DevOps Server, une boite de dialogue s’ouvre pour vous demander de vous authentifier.

Boite de dialogue d'authentification Windows


Ceci se produit, quelle que soit votre configuration. Que votre PC fasse partie du même domaine que le serveur, ou non. Que vous soyez sur le même réseau que le serveur, ou non.

Edge ne participe pas automatiquement à l’authentification Windows.

Pour résoudre le problème, il existe deux tonnes d’articles aux approches plus ou moins complexes et hasardeuses. Il existe pourtant une solution simple : retrouver la notion de zone intranet et liste des sites intranet. Cela prend moins de 5 minutes à faire, et la solution fonctionne dans 100% des cas.

Forcer la mise à jour d’un agent Azure Pipeline utilisé avec Azure DevOps Server / TFS

Si vous utilisez Azure DevOps et sa version on premise (de TFS 2015 à Azure DevOps Server), vous avez peut-être remarqué qu’il existait un décalage entre les agents distribués par chaque plateforme. On premise, l’agent Azure Pipeline est plus ancien.

Heureusement, celui-ci peut être mis à jour.

La procédure à appliquer est relativement simple et rapide :

  • Télécharger la toute dernière version de l’agent via GitHub (https://github.com/Microsoft/azure-pipelines-agent)
  • Déposer l’agent sur le serveur Azure DevOps. Le zip doit être déposé dans le répertoire %ProgramData%\Microsoft\Azure DevOps\Agents. Si vous utilisez plusieurs serveurs pour la couche applicative, l’agent doit être déployé sur chaque serveur.
  • Attendre que les agents se mettent à jour. Ou forcer la mise à jour via la liste des pools d’agents. La commande pour forcer la mise à jour se trouve en haut à droite "Update all agents"

La commande pour forcer la mise à jour pourte le nom "update all agents" et se trouve à côté de la commande "New agent", en haut à droite de l'écran

Note : Pour éviter tout problème, il est préférable de ne laisser qu’une version de l’agent dans le répertoire %ProgramData%\Microsoft\Azure DevOps\Agents.

Jérémy Jeanson