Azure Devops deploy to on-prem servers with no internet access

Viewed 571

With Azure Pipelines, is it possible to deploy an artifact to on-prem internal servers, that have no internet access does anyone know?

The internal servers don't currently and won't likely ever have internet access. We've got a self-hosted devops agent running on our build server in DMZ and the build server has connectivity to internal servers.

We currently use another continuous deployment tool that has deployment agents running on all our target servers and then a listener, running on our build server, to register those agents. We had hoped that we would be able to do something similar with Azure Pipelines e.g. use the self-hosted agent to register deployment targets - it doesn't look like this is possible. From what I've seen, if we want to deploy to an on-prem server it needs internet access to communicate back to our Azure Devops url to be registered.

Many thanks

4 Answers

I believe Azure Pipelines always needs to talk to azure. Even self hosted ones.

Have you looked at Ansible for this? You can apply settings to servers without a need for an internet connection on all the servers, with Ansible you can have the Ansible server go out and get the files and then deploy those updates and settings securely using ssh.

You can then just take most of your YAML file code change relevant parts and then deploy.

We've got a self-hosted devops agent running on our build server in DMZ and the build server has connectivity to internal servers.

Then your pipeline shouldn't have issues communicating with the internal servers, it's a matter of what you want your pipeline to use.

The IISWebAppDeploymentOnMachineGroup task unfortunately won't work for you because it requires that your pipeline is running in a classic pipeline that executes in a Deployment Group, which also requires internet connectivity. Deployment Groups act like a stand-in for build-agents and operate in the same manner as build-agents. If you won't allow outbound internet connectivity from these machines, you'll need a different option.

One option is to use the Microsoft-provided marketplace extension that allows you to deploy using WebDeploy using Windows Remoting. This extension includes tasks that allow you to manage the IIS sites, deploy the web app, and deploy SQL databases using a WinRM session.

You can also use Powershell on Target Machines task to execute deployment scripts that can install software components, etc. This task includes logic to copy files onto the machine prior to execution.

Our team ended up writing a custom azure devops extension to bundle our powershell scripts with a custom service connection. The custom service connection has the username and password details and the custom task unpacks the credentials from service connection to establish a PSRemoting Session. Once you're in a PowerShell session you can do pretty much anything that you can do locally.

"is it possible to deploy an artifact to on-prem internal servers, that have no internet access"

Taking your Q at face value, yes. Your self-hosted agent can copy files to your internal servers over an internal network (no Internet to internal servers required). Depending on what you mean by "deploy" I guess. I don't know why the internal servers would need to run deployment agents.

I had a similar problem. When I tried to deploy the "deployment group" agent it would fail with the error "The remote name could not be resolved: 'vstsagentpackage.azureedge.net'". Turned out it was trying to download the vsts-agent-win-x64-2.153.1.zip file from a remote site. I was able to use a computer with internet connectivity and manually downloaded the file. I placed the file on one of my local web servers and adjusted the script to reference my local web site (rather than the remote one) so it would "download" from the local web server. After that the agent installed and worked as expected.

Related