This article is NOT good advice and should be completely disregarded by any serious sysadmins.
You absolutely should not remote into the web server box from the agent box! This goes entirely against the grain of how modern Azure DevOps pipelines deployments are designed to work... hence the security issue that the hapless blogger is trying to unnecessarily solve.
The correct approach is to install the DevOps Agent directly onto the IIS web hosts, linking them to a named Environment such as "Production Web App Farm A" or whatever. See: https://learn.microsoft.com/en-us/azure/devops/pipelines/pro...
In your pipelines, you can now utilise Deployment Jobs linked to that named environment: https://learn.microsoft.com/en-us/azure/devops/pipelines/pro...
Deployment jobs have all sorts of fancy built-in capabilities such as pre-deployment tasks, rolling and canary strategies, post-deployment tasks, health checks, etc...
They're designed to dynamically pick up the current "pool" of VMs linked to the environment through the agents, so you don't need to inject machine names via pipeline parameters. Especially when you have many apps on a shared pool of servers, this cuts down on meaningless boilerplate.
All of the above works even with annoying requirements such as third-party applications where active-passive mode must be used for licensing reasons. (I'm looking at you ESRI and your overpriced software). The trick is to 'tag' the agents during setup, which can then be used later in pipelines to filter "active" versus "passive" nodes.
You absolutely should not remote into the web server box from the agent box! This goes entirely against the grain of how modern Azure DevOps pipelines deployments are designed to work... hence the security issue that the hapless blogger is trying to unnecessarily solve.
The correct approach is to install the DevOps Agent directly onto the IIS web hosts, linking them to a named Environment such as "Production Web App Farm A" or whatever. See: https://learn.microsoft.com/en-us/azure/devops/pipelines/pro...
In your pipelines, you can now utilise Deployment Jobs linked to that named environment: https://learn.microsoft.com/en-us/azure/devops/pipelines/pro...
Deployment jobs have all sorts of fancy built-in capabilities such as pre-deployment tasks, rolling and canary strategies, post-deployment tasks, health checks, etc...
They're designed to dynamically pick up the current "pool" of VMs linked to the environment through the agents, so you don't need to inject machine names via pipeline parameters. Especially when you have many apps on a shared pool of servers, this cuts down on meaningless boilerplate.
All of the above works even with annoying requirements such as third-party applications where active-passive mode must be used for licensing reasons. (I'm looking at you ESRI and your overpriced software). The trick is to 'tag' the agents during setup, which can then be used later in pipelines to filter "active" versus "passive" nodes.