A common scenario we see is customers want to use Auto-Scaling groups to keep their cloud costs as low as possible. Keep only the minimal amount of VMs needed to handle an expected load. For example, you expect to have 1000 requests a second. You set up the necessary VMs to handle 1200 requests a second. When the number of requests gets to 900/second you add on some additional machines to handle that load.
When that happens, how can you add a machine using Auto Scaling groups, get the lastest code deployed and add that machine into a load balancer? What about when you no longer need the machine? How can you handle that?
There are few items to consider when using auto-scaling groups with Octopus Deploy.
-
Machine registration. Tentacles can be installed and registered from the command line. https://octopus.com/docs/infrastructure/deployment-targets/windows-targets/automating-tentacle-installation
-
Deployment target triggers. When a new machine is registered you will want to deploy to it. You can leverage machine target triggers to accomplish that. https://octopus.com/docs/deployment-process/project-triggers/automatic-deployment-triggers
-
Skipping steps. When you are automatically scaling out chances are you will not want to run specific steps in your deployment process. For examples, in this process, we only want to run step 4 when a new web server is added.
Using run conditions (https://octopus.com/docs/deployment-process/conditions#run-condition) will allow you to skip a step. To stop that from happening, this run condition: #{unless Octopus.Deployment.Trigger.Name}True#{/unless} will work. It is a bit of a double negative. If the deployment was triggered manually by a person, or through a service account by a build server, the step will run. If it is triggered by a trigger the step will be skipped.
- Scaling down. With AWS you will get a two minute warning when a machine is going to be removed. Not enough time to manually remove the machine from Octopus. However, you can run an AWS Lambda function. https://aws.amazon.com/blogs/compute/using-aws-lambda-with-auto-scaling-lifecycle-hooks/. That Lambda function can invoke the Octopus API to remove the machine. Here is an example script written in PowerShell, but should give you an idea. https://github.com/OctopusDeploy/OctopusDeploy-Api/blob/master/REST/PowerShell/Workers/DeleteWorkerDuringDeployment.ps1
Check out our Octopus Samples instance to see an example of AWS auto scaling using Terraform.
https://samples.octopus.app/app#/Spaces-48/projects/dynamic-worker-army/deployments
Hi Shawn, the link appears no longer valid?
"Sorry, the Space (Spaces-48) could not be found
The space may not exist, or you may not have access to the Space. Contact the Space Manager to request access."
Is the example still available at some other URI?
My sincere apologies @bob.hardister, apparently we hadn’t granted Guest access to that Space. It should be fixed now.
