2

I have setup a Linux Srv in Azure with OMI/PSDCS and trying to deploy with VSO Release Management. I have created an Azure environment (I won't allow mw to create a Standard Env) and solved all certificate issues so far. Now it's failing because RM try to connect to the linux server using Negotiate Auth and (of course) the OMI service only supports Basic.

How can I make RM to use Basic? Or OMI to support Negotiate/NTLM? Any post or document showing ANY working VSO RM deploying to Azure without using Chef?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Andres
  • 119
  • 1
  • 4
  • I wouldn't be surprised if it's not supported. – Daniel Mann Jun 19 '15 at 13:55
  • Looks like it is possible: "•Deploy to Windows or Linux servers using PowerShell, Desired State Configuration, Chef, or Visual Studio Deployment Agent." https://www.visualstudio.com/en-us/products/release-management-for-microsoft-visual-studio-vs.aspx – MrHinsh - Martin Hinshelwood Jun 19 '15 at 18:55
  • I saw the same page... but in all demos I have seen they use Chef, and I don´t want to use Chef. Also, all examples of deploying to Linux with DSC dont´t use RM and so they can specify to use Basic authentication and ignore all certificate errors. – Andres Jun 20 '15 at 17:58

1 Answers1

2

The "Run PS/DSC task" that ships with RM does not support Linux deployments. The current implementation is quite dependent on Windows being the target. But, may I suggest a couple of workarounds?

For both of these workarounds, you should first have a PS script (with DSC configurations and Start-DSCConfiguration) that you can run from a Windows machine to target your Linux machine, without using RM or Build. You have complete control on how this script should be written including how the credentials are created, and the authentication method.

Once you have an independently tested PS script, you can do one of the following:

  1. Create a Build definition in your visualstudio.com account Build hub and use the Powershell Build step to run the above script. Note that this is the new Build system in VSO. It has the ability to run PS scripts easily. Note that you are creating a build definition here instead of a release template in RM. The new Release hub that will be available later this year in VSO will be very similar to the Build hub, and you can leverage the same PS script inside a Release definition once that is available. I tried this approach and it seems to work fine.

  2. Setup a Windows machine as a target Azure environment in RM. Create a vNext release template to then run the above PS script on the Windows machine. When that script is run, it will be able to target the Linux server. In this approach, you are using a Windows machine as a proxy to run the PS script. I have tried this using agent-based release template, and not with the vNext release template. I am hoping that it will work fine with the vNext release template as well.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
  • Thanks Vijay for your comments! I would say option #2 is closer to what I need because I want to leverage RM to have approvals and multiple deploy environments in the same workflow. This scenario would work on a pure Azure (VSO & RM Online) setup? I mention this because you say to have tried it with agent based deploys and those are not supported in vNext RM online right now, or I´m missing something? Do I need RM on-premise for this? – Andres Jun 21 '15 at 22:40
  • Yes, I tried in agent-based and on-prem RM. But, it should work with vNext templates using Azure Windows VM environment (acting as proxy) and RM online as well. Will update this thread if I get a chance to try it. - Vijay – Vijay Machiraju Jun 22 '15 at 04:01
  • Works in RM vNext templates as well. – Vijay Machiraju Jun 22 '15 at 18:01
  • Excelent! Thanks a lot Vijay! So, to make it clear, using VSO & RM online vNext templates, used a Windows machine as a proxy. So, for that proxy machine you created a PS/DSC script that is going to be executed in the proxy machine and that script contains only a Script Resource that is going to execute the REAL PS/DSC deploy scripts that connects to the Linux machine with SSL/Basic and execute the file copy actions to actually deploy the web site. I'm right? I'm missing something? – Andres Jun 28 '15 at 07:05
  • The PS/DSC script on proxy windows machine is going to directly define the desired state for the Linux machines. I do not see a need for two sets of PS/DSC scripts. The target machines for that script are defined as per "All nodes" model described here: https://technet.microsoft.com/en-us/library/dn249925.aspx. When run, this script generates the MOF files for each Linux node on the proxy machine, and then push those MOFs into the Linux nodes. See http://blogs.technet.com/b/privatecloud/archive/2014/05/19/powershell-dsc-for-linux-step-by-step.aspx for an example of such a driver script. – Vijay Machiraju Jun 30 '15 at 15:44
  • Thanks again Vijay! Will try that. I really appreciate you time. – Andres Jul 01 '15 at 16:43