Tentacle URL set to machine name instead of fully qualified doimain name

Heyo,

I’m installing a listening tentacle on a new VM using the Azure Resource Manager template extension as demonstrated here: https://octopus.com/docs/installation/installing-tentacles/azure-virtual-machines/via-an-arm-template

Everything runs OK, but the resulting Tentacle URL is set to the machine name, when I need to provide a fully qualified domain name.

Please see attached screenshot.

Ok, thanks Damo and Matt for having a quick look and coming up with the following doco: https://octopus.com/docs/installation/installing-tentacles/azure-virtual-machines/configuration-structure

This explains what’s going on, but I’d like to add a feature request: Please add a new property to the configuration that allows me to set the tentacle domain name.

To add a little more context, my octopus server and my tentacle live in different worlds (different subscriptions, let alone networks), so I can’t setup any networking rules to just point to a machine name.

For now the solution will have to be polling tentacles :slight_smile:

Hi Ben

I’ve just pushed live a new version (2.0.65) that allows you to specify the PublicHostNameConfiguration ie, how the Server should address the Tentacle.

Valid options are PublicIP (the default), FQDN, ComputerName and Custom. If you specify Custom, you can provide the CustomPublicHostName as whatever you like.

Have a try of that and let me know how it goes.

Regards,
Matt

Awesome cheers, I’ll check it out and let you know :slight_smile:

Hey Matt,

This has worked a treat! I tried to use the FQDN setting first, however I don’t think the Azure VM had the right info on the machine itself (it just put the machine name and then a dot eg “my-machine.”.

Next I tried the Custom setting and that worked perfectly. For clarity for anyone else landing here, I used the following config:

{
“type”: “extensions”,
“name”: “OctopusDeployWindowsTentacle”,
“apiVersion”: “2015-05-01-preview”,
“location”: “[resourceGroup().location]”,
“tags”: {
“displayName”: “Install Octopus Tentacle”
},
“dependsOn”: [
"[concat(‘Microsoft.Compute/virtualMachines/’, variables(‘virtualMachines_pinch_processing_name’))]"
],
“properties”: {
“publisher”: “OctopusDeploy.Tentacle”,
“type”: “OctopusDeployWindowsTentacle”,
“typeHandlerVersion”: “2.0”,
“autoUpgradeMinorVersion”: “true”,
“settings”: {
“OctopusServerUrl”: “[parameters(‘octopus_server_url’)]”,
“Environments”: [
“Processing Test”
],
“Roles”: [
“Processing Server”
],
“CommunicationMode”: “Listen”,
“Port”: 10933,
“PublicHostNameConfiguration”: “Custom”,
“CustomPublicHostName”: “[reference(concat(‘Microsoft.Network/publicIPAddresses/’, variables(‘publicIPAddresses_pinch_processing_name’)), ‘2016-03-30’).dnsSettings.fqdn]”
},
“protectedSettings”: {
“ApiKey”: “[parameters(‘octopus_api_key’)]”
}
}
}

Cheers :smiley:

Hi Ben

Glad to hear it worked.

The FQDN mode works off the machine name combined with the domain name - so it will work well for domain joined machines, but unfortunately its not that easy to determine, especially as it can be behind a load balancer etc. I might add a note about this to the docs.

Happy deployments!

Cheers,
Matt

Hi Ben

Just a quick note to say I’ve added this to https://octopus.com/docs/installation/installing-tentacles/azure-virtual-machines/configuration-structure, so that its clearer for other people hitting the same issue.

Cheers,
Matt