4 ms·

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 t

• 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!