3 ms·

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 th

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/process/environments-virtual-machines?view=azure-devops&tabs=windows 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/process/deployment-jobs?view=azure-devops 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.

Mossy9 2y ago
Thanks for the counterpoint - absolutely what I was looking for. Running the agent on the app server seemed a bit risky since it will a) drain resources from the apps and b) needs to have a route open to Azure (Devops) Apparently you have had good experiences with this? I'd be interested to learn more
- jiggawatts 2y ago
  > drain resources from the apps The resource usage is negligible. If you really need that level of high efficiency that you can't spare the tiny amounts of memory the agent uses, then you'd be better off looking into using something like Packer to build a Server Core image in your pipeline, and deploying that to an Azure Virtual Machine Scale Set. This allows "zero outbound communications" deployments also because the image build step is out-of-band and isn't done anywhere near the live infrastructure network. https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/packer-build-v1?view=azure-pipelines https://learn.microsoft.com/en-us/azure/devops/pipelines/tas... The above approach concept also works with any other imaging-based workflow such as Windows Docker containers running on App Service or Kubernetes. https://azure.github.io/AppService/windows-containers/ https://azure.github.io/AppService/windows-containers/ The packer + VMSS approach however allows the IIS workers to join an Active Directory domain "properly". Sure, Kubernetes has some limited support for this, but I wouldn't try it in production unless forced to at gunpoint. > needs to have a route open to Azure. If you're only deploying instead of running arbitrary pipeline tasks, then I believe just four firewall rules is sufficient to Azure DevOps (not "Azure"!), but you may need more depending on your requirements: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/windows-agent?view=azure-devops#for-organizations-using-the-devazurecom-domain https://learn.microsoft.com/en-us/azure/devops/pipelines/age... > Apparently you have had good experiences with this? It's pretty much the "only way" to do things in the current-gen YAML Azure DevOps pipelines. The alternatives are Kubernetes, App Service, and the like, but those generally aren't 100% compatible with traditional domain-joined IIS web servers. If you actually need the traditional Windows box "infrastructure" instead of a PaaS, then directly installed DevOps Agents would be one of the best ways to manage it. The best alternative I know of is probably Nomad, but that's only good if your org is already invested into Hashicorp tooling.
  - Mossy9 2y ago
    Thanks a lot! I'll study further and discuss these further with the IT team.
- kukkamario 2y ago
  a) resource use is minimal when deployment isn't in progress. It just idling and waiting for commands b) Agent need to be able to connect to Azure DevOps servers, but it is connection from agent to Azure DevOps servers so no need to open any extra inbound ports or anything like that. Documentation lists the domains that need to be accessible from agents. Agent permissions to Azure are restricted based on the pipeline configuration to only allow things that are used in the pipeline. So if your pipeline does not involve cloning git some private git repo, agent cannot do that. And even that gives only access to that particular resource. So you normally have a build pipeline that generates package from you application and then deployment pipeline that only has access to that generated package which is then distributed to agents configured for some particular deployment environment. I don't really have much direct experience with deployment side of things so someone else can probably provide extra info.
  - Mossy9 2y ago
    Yeah, we probably initially overestimated these issues, causing us to take a longer, more indirect route. Thanks!

Mossy9 2y ago

Thanks for the counterpoint - absolutely what I was looking for. Running the agent on the app server seemed a bit risky since it will a) drain resources from the apps and b) needs to have a route open to Azure (Devops) Apparently you have had good experiences with this? I'd be interested to learn more

jiggawatts 2y ago
> drain resources from the apps The resource usage is negligible. If you really need that level of high efficiency that you can't spare the tiny amounts of memory the agent uses, then you'd be better off looking into using something like Packer to build a Server Core image in your pipeline, and deploying that to an Azure Virtual Machine Scale Set. This allows "zero outbound communications" deployments also because the image build step is out-of-band and isn't done anywhere near the live infrastructure network. https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/packer-build-v1?view=azure-pipelines https://learn.microsoft.com/en-us/azure/devops/pipelines/tas... The above approach concept also works with any other imaging-based workflow such as Windows Docker containers running on App Service or Kubernetes. https://azure.github.io/AppService/windows-containers/ https://azure.github.io/AppService/windows-containers/ The packer + VMSS approach however allows the IIS workers to join an Active Directory domain "properly". Sure, Kubernetes has some limited support for this, but I wouldn't try it in production unless forced to at gunpoint. > needs to have a route open to Azure. If you're only deploying instead of running arbitrary pipeline tasks, then I believe just four firewall rules is sufficient to Azure DevOps (not "Azure"!), but you may need more depending on your requirements: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/windows-agent?view=azure-devops#for-organizations-using-the-devazurecom-domain https://learn.microsoft.com/en-us/azure/devops/pipelines/age... > Apparently you have had good experiences with this? It's pretty much the "only way" to do things in the current-gen YAML Azure DevOps pipelines. The alternatives are Kubernetes, App Service, and the like, but those generally aren't 100% compatible with traditional domain-joined IIS web servers. If you actually need the traditional Windows box "infrastructure" instead of a PaaS, then directly installed DevOps Agents would be one of the best ways to manage it. The best alternative I know of is probably Nomad, but that's only good if your org is already invested into Hashicorp tooling.
- Mossy9 2y ago
  Thanks a lot! I'll study further and discuss these further with the IT team.
kukkamario 2y ago
a) resource use is minimal when deployment isn't in progress. It just idling and waiting for commands b) Agent need to be able to connect to Azure DevOps servers, but it is connection from agent to Azure DevOps servers so no need to open any extra inbound ports or anything like that. Documentation lists the domains that need to be accessible from agents. Agent permissions to Azure are restricted based on the pipeline configuration to only allow things that are used in the pipeline. So if your pipeline does not involve cloning git some private git repo, agent cannot do that. And even that gives only access to that particular resource. So you normally have a build pipeline that generates package from you application and then deployment pipeline that only has access to that generated package which is then distributed to agents configured for some particular deployment environment. I don't really have much direct experience with deployment side of things so someone else can probably provide extra info.
- Mossy9 2y ago
  Yeah, we probably initially overestimated these issues, causing us to take a longer, more indirect route. Thanks!