Our datacenter is set up in a way where a website being deployed has the datacenter number in its URL, e.g. https://myservice12.company.net where 12 is the datacenter number. An environment can have up to 3 datacenters.
Our current deployment method is to deploy to a drop path and copy the package onto multiple servers.
For example: I am deploying to servers in three different datacenters – the numbers are 8, 12, and 18. The hostname needs to be configured accordingly:
From what I’ve researched, I believe the Octopus team recommends a drop location configured for each server. We didn’t like this solution because we only want one deployment target pointing to that path.
My other idea is to use prompted variables. When I tried this out, I was expecting the offline deploy script to prompt me for the variable but it turns out that it’ll prompt you for a value when you deploy through the Octopus UI. This won’t work either.
My goal is to write a script where I can prompt for the variable during the offline deploy process and that input can be used to resolve my hostname variable which is set to https://#{ServiceName}#{DatacenterNumber}
Before I go on with this idea, do you have any suggestions on how to achieve this functionality?
The obvious one, do an offline drop per data center, even if that is then used on multiple machines within the data center.
Run a script step as the first step in your deployment that determines which data center the machine is running in, write that value to an output variable (https://octopus.com/docs/deploying-applications/variables/output-variables) and then use the value of that output variable in the rest of the deployment.
Ideally you’d be able to check some value on the server that lets you know which data center you are in (have a list of DNS servers used in each data center in the script, get it by convention on the server names or add it as an environment variable on the servers that you can query). Failing that you could have a simple config file that you copy over along with the deployment, and read from that.
Not the cleanest way to do it, but you’re a bit outside normal Octopus use in running the same offline drop on multiple machines.
Hey Mark, thanks for the suggestions. I was under the impression that output variables are not supported in offline deployments. Can you please confirm that your second suggestion will indeed work even with this limitation?
I’m off work right now but I’ll give the second idea a try first thing tomorrow! Thank you.
You are right of course. No output variables in offline drops, the processing to extract the values from the logs and feed them to the next step all happens server side. You could still do something similar by setting a dummy hostname in Octopus, and then updating it in a PostDeploy script that figures it out as previously suggested, then sets it in the same script (that is, make the IIS changes or whatever you need the hostname for yourself). It leaves you to do a bit more of the work in your own script though unfortunately.
I’ll keep thinking on this and let you know if I come up with anything better.
I suppose I could do a messy workaround here – Have the deployment user place the datacenter number into a file and then I’ll have a script that reads the file and replaces #{DatacenterNumber} in thevariables.json` file. This will happen first thing before the actual deployment happens.
Other than that I think that your first idea may be a possibility but I’ll need to discuss it with the team.
I’m all ears for any other suggestions you may have thanks.
And then that Hostname variable should be available for the rest of that step (as both Hostname and the normal output variable syntax of Octopus.Action[Step Name].Output.Hostname.