I’m sorry to hear that you are having trouble configuring the AzureVMExtension. Thank you for providing your logs as well.
In case you may have missed it on our documentation pages - The use of AzureVMExtension has been deprecated for awhile now. Due to that, I will not be able to help too much with the troubleshooting of the AzureVMExtension but I’d be more than happy to help you with any issues you might hit, when migrating across to the recommended solution of DSC.
Getting a tentacle installed on a VM (or physical endpoint) can happen in a lot of different ways. It all depends on your ecosystem and what you feel comfortable using.
Just to clarify this new Octopus Deploy Tentacle agent is a replacement of “OctopusDeployWindowsTentacle” correct ?
Essentially yes, however I believe the VM extension was it’s own thing, and lacked some customization options, that the current Tentacle installation contains, which you would get from a DSC install.
If you were only targeting a single endpoint and you didn’t want to dig into configuring DSC, you could achieve a similar outcome by downloading and installing the tentacle directly. You wouldn’t have the protection that Desired States offer - but you would have the same tentacle.
I know I’ve probably over-analysed the question - but I’ll throw one more link your way. If you weren’t dead set on using Azure VMs but still wanted to use the Azure ecosystem, you could do some reading on the other Azure services we integrate with.
Thank you very much for all the inputs Dane. We are going with the DSC option .
In our current setup we are having our ARM Template in a Zip file and it is located in the library of the octopus. When the pipeline runs it uses the file present in library and creates the VM along with the tentacle in Azure.
We have now added the OctopusTentacle zip folder as recommended in the document and we have added the custom ARM template into our build json file. “Pasted below” . Just wanted to know what needs to replaced in the link which is under configuration ?
I’m just stepping in for Dane as he’s offline for the day.
After looking into this a bit, I do not believe you will be able to use the Octopus server as the location for your .zip package. The doc mentions below that the package needs to be in a public location, or a private location that can be shared with the VM via a SAS token.
Upload the zip file to a location accessible during VM provisioning. You can either use a public location, or a private location protected with a SAS token.
The Octopus package repo is not publicly available and would require authentication with an API key which won’t work in this application. You could use an Azure Storage Account to host the package and use a private endpoint that the VM has access to in your ARM template.
Please let me know if this helps or if you have any other questions for us.
We are in the process of creating a Azure Storage Account and proceeding with the step, just wanted to know that our Octopus expired recently, will that be a blocker to install the Octopus extension ? Please advice.