Tout d'abord, rappelons ce que sont les agents Azure DevOps. Lorsque vous exécutez votre pipeline, il ne s'exécute pas "dans le cloud", mais sur une machine spécifique. Cette machine peut être gérée soit par Microsoft (agents hébergés par Microsoft), soit sur votre réseau, à la fois dans le cloud et localement. Ces machines sont appelées agents.

En fait, tout le travail est effectué par un logiciel spécial qui doit être installé sur votre machine. Ce logiciel se connecte à Azure DevOps et lorsque le pipeline est lancé, il exécute des jobs et des tasks.

Il est important de souligner que le logiciel se connecte à Azure DevOps, et non l'inverse. Cela est fait pour des raisons compréhensibles. Cela vous permet de ne pas ouvrir de ports inutiles sur vos machines, ce qui augmente la sécurité.

Ainsi, dans mon cas, pour une raison inconnue, ce logiciel a perdu la capacité de se connecter à Azure DevOps. En me basant sur les journaux, j'ai compris qu'il y avait un problème de connexion à l'adresse de point de terminaison visualstudio.com/_apis/connectionData. Il était intéressant de noter qu'il était possible de se connecter à ce point de terminaison à partir du navigateur sans aucun problème.

Quelque chose bloquait la connexion sortante. J'ai tout vérifié : firewall local, paramètres NSG (il s'agissait d'une machine dans Azure), accès à Internet, etc. J'ai même vérifié les paramètres du proxy. Tout était en ordre.

J'ai dû faire appel à l'aide de collègues - des ingénieurs réseau. Nous avons vérifié ensemble le trafic et découvert que le logiciel Agent envoyait la requête à la mauvaise adresse de proxy. Il s'est avéré que récemment, l'adresse IP du serveur proxy pour l'accès à Internet depuis le réseau interne avait été modifiée et les paramètres correspondants avaient été mis à jour dans la configuration Windows. Mais pour une raison quelconque, le logiciel Agent continue d'utiliser l'ancien proxy.

Mais au moins maintenant, il était clair où creuser. Donc... Lorsque vous ajoutez un agent, Azure DevOps vous fournit un script PowerShell qui fera presque tout pour vous.

Ce script fonctionne bien avec une configuration réseau normale mais cesse de fonctionner lors de l'utilisation d'un proxy. Pourquoi ? Parce que le logiciel de notre agent ne sait pas comment extraire automatiquement les paramètres de proxy du système d'exploitation et il doit spécifier manuellement les paramètres nécessaires. Cela se fait en utilisant le paramètre --proxyurl pour le config.cmd du logiciel de l'agent, qui est appelé à la fin du script PowerShell.

Vous pouvez en savoir plus sur la configuration du proxy pour les agents ici.

Il semble que c'est tout - une fin heureuse à l'histoire, mais ce n'était pas le cas. Pendant que je me débattais avec le problème, j'ai décidé de réinstaller le logiciel de l'agent. Pour ce faire, vous devez supprimer l'ancien et installer le nouveau avec un script PowerShell. De plus, en général, il peut y avoir plusieurs agents sur la machine qui fonctionneront parfaitement en parallèle les uns avec les autres.

Comment supprimer un agent est écrit ici. Pour ce faire, utilisez la commande .\config remove

Mais le problème est qu'en utilisant cette commande pour supprimer complètement l'agent, vous devez disposer d'un jeton d'accès personnel actif pour un compte qui a le droit d'ajouter des agents à AzureDevOps. Le jeton avec lequel l'agent a été créé a expiré il y a longtemps, et mon compte n'avait pas suffisamment de droits. De plus, du côté Azure DevOps, l'agent peut être facilement supprimé, mais il est tout simplement impossible de désactiver correctement le logiciel de l'agent sans le PAT approprié. Vous pouvez uniquement arrêter le service Windows correspondant et l'empêcher de redémarrer.

En fin de compte, j'ai dû demander l'aide d'un devops qui avait les droits appropriés pour ajouter des agents et lui demander de créer un PAT temporaire, avec lequel j'ai réussi à supprimer complètement l'ancien logiciel de l'agent et à installer un nouveau avec la configuration correcte du serveur proxy.

C'est ce que nous devons apprendre tout le temps. Vous ne saurez jamais où vous rencontrerez un problème…