I am trying to create a deployment process using chef scripts on AWS. I am using TeamCity with Octopus. I am registering my octopus tenctacle to my octopus server as written in this link.
I have N servers up and running at the time I publish a new release via TeamCity. For a fresh deployment, I am instantiating N new clean instances and installing necessary tools to these servers (Octopus tentacles, copperegg etc.) using chef scripts. By this time, I will have had 2N tentacles (N production and N waiting for the new version) connected to Octopus server. I want these N new instances to download and install the latest NuGet package from Octopus server.
If these new N tentacles share the same environment with the old ones, when I publish a new release on Octopus server, all tentacles will get the latest version at the same time, which will cause a downtime. If I setup the new instances with a new environment setting, I will need to create the new environment also on the Octopus server, which is impossible with http api, so it won’t be a trivial task to do.
What is your suggestion at this point for a deployment without downtime?
This is an interesting scenario and one that we want to support. I think you’ll have more luck making this work with our beta version of Octopus 2.0 (download it here: https://github.com/OctopusDeploy/Issues).
Using Octopus 2.0, which has a very comprehensive API, you’d:
Spin up your new AWS instances
Install Tentacle etc. on them
Register them with Octopus
Disable the old machines in Octopus
Trigger the deployment
At the end of the deployment, point the load balancers/whatever you need to do
All of this is possible via the Octopus REST API in Octopus 2.0 and we’ll be making a C# library available to do it. In fact it’s a demo I want to put together early next year when we aren’t so busy with Octopus 2.0.
Let me know if you’d like to try this against 2.0 and if you’d like access to the 2.0 C# REST API client.
I just came across this looking for something else.
We are doing exactly this with Octopus 1.0. We implement BlueGreen deployment to new AWS environments, and use DNS to switch out environments for go live. This way each new stack is isloated form the original and we can push releases to the new enviornment without affecting the first. The environments in Octopus are just fixed as Blue and Green and we automate the alternating between the 2 via Route53.
I guess it should be a lot easier with 2.0. Looking forward to trying that out soon!
