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