Hi,
I have many VMs running on Azure which I want to deploy to with Octopus. Right now I use TeamCity to start the VM running, then upload a new release into Octopus and start the deployment.
What I want to do, is deploy to multiple targets at once, meaning I’ll need Octopus to start the VMs as Teamcity will only start the VM the TeamCity agent is on.
Can I add a step at the start of the deployment job, set to run on server, that can start the additional target machine VMs, then wait for their tentacle to connect before continuing with the deployment?
I know I could schedule the VM to come on at set times, but these are on-demand builds that could run at any time of day, and leaving VMs running all day is not an option.
This is definitely possible in Octopus, and you are on the right path with needing a script step. You will also need to configure your Project to deploy to empty environments, and allow the project to “skip” unhealthy targets rather than fail the deployment entirely. We have some good information over on our elastic environments support page which should help get you started.
As a pseudo deployment process it will look something like this
Azure script to launch VM
Wait for VM to launch (either via sleep or script that polls for a 200OK from hitting the Tentacle endpoint via HTTPS)
Healthcheck step
Deployment
I’ll also quickly link to this Microsoft page for the powershell command to start an AzureVM which you can run in an Azure Powershell step in Octopus. I’m sure you’re all over it but since I looked it up I thought I should include it.
Thanks for the reply Alex, I’ve managed to get the VM to launch as part of a first step on the deployment. It currently waits 3 minutes before continuing, but your idea of waiting for a 200OK response would be better.
Are there any plans for Octopus to natively support managing Azure VMs as deployment targets in future? It would save having to add these steps in if Octopus could identify a target as a cloud VM in advance then take the appropriate actions on deployment.
Sorry, I missed your second question here when it first came in.
Better management of cloud targets (Azure, AWS etc) has been discussed internally for quite a while, and it definitely something that we will be working on in future. The issue (as it stands) is that re-imaging targets requires a lot of careful planning as it touches every part of Octopus, including licensing so while we recognise that our current model has it’s weaknesses we are treading very carefully here.
If there is anything else that I can help you with please let me know!