2

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

iomdesign
  • 73
  • 2
  • 9
  • If your build-agents are in the DMZ and have connectivity to the internal-servers, what’s the issue? What can’t your pipeline do? – bryanbcook Jan 06 '22 at 12:59

4 Answers4

1

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.

James K.
  • 11
  • 2
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Aug 24 '22 at 10:50
0

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.

Jason
  • 510
  • 5
  • 27
  • Thanks @Jason we have currently got a CI/CD (build server, build-agents, deployment server and deployment target agents) solution running on-prem but quite liked the idea of an opportunity to reduce the overhead of managing all this, especially given that we were already using Azure DevOps for code repos, wiki, etc. Seems a shame that there doesn't seem to be a way to register deployment targets via our devops build-agents in our DMZ as this would massively reduce our CI/CD app footprint. – iomdesign Jan 06 '22 at 09:44
0

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.

bryanbcook
  • 16,210
  • 2
  • 40
  • 69
  • Thanks for your comment @bryanbcook. We use Azure DevOps Services in the cloud (for most situations this is ideal for us) and have on-prem build-agents running on our DMZ build servers - so build pipelines are fine. The only issue is the releases to the internal boxes. Seems a shame that there doesn't seem to be a way to register deployment targets via our DMZ build-agents. I have considered Azure Devops Server as a potential option but ideally we'd like to reduce our application management overhead if possible. – iomdesign Jan 06 '22 at 09:37
  • I've revised my answer to reflect your recent responses – bryanbcook Jan 06 '22 at 16:22
0

"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.

Conrad Albrecht
  • 1,976
  • 2
  • 15
  • 19
  • Thanks @Conrad Albrecht - indeed I should have clarified "deploy". Currently our CD covers all sorts from IIS sites with config, post deploy powershell scripts and certs to TopShelf Services to Docker Containers so more than dropping files. I was thinking in terms of yaml deployment jobs but maybe better to think along Releases and Deployment Groups. – iomdesign Jan 06 '22 at 10:22
  • From https://learn.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups/?view=azure-devops#set-up-agents-on-deployment-groups "Every target server in the deployment group requires a deployment agent." – iomdesign Jan 06 '22 at 10:22