Modifying machines in environments to support AWS autoscaling

Legacy Uncategorised
1

Hi there

I’m currently trialing Octopus deploy in an AWS EC2 auto-scaling environment (not Elastic Beanstalk or CloudFormation). For the most part it’s working well, but the fact that we use autoscaling means that the machines in a given environment will vary over time.

To support this, my project has two build steps:

  1. Refresh AWS instances
  2. Deploy site

The first build step in the deploy queries AWS for the current instances in the specified environment. It will create a new machine in Octopus for any new instances, and delete any machines whose AWS counterpart is no longer there.
All of that is fine, but the annoying part is that the changes to the machines in the environment during build step 1 are not reflected in build step 2 where the nuget package is deployed. That build step still attempts to deploy to the machines that were originally there. This causes the deployment to fail if one of machines no longer exists.

I’d like to use the powershell cmdlets to modify the current DeploymentResource to include the new/exclude the old machines, but there is no Modify option on $repository.Deployments

Does anyone have any other suggestions of how this can be acheived without having two separate Projects?

Thanks very much

2

Hi,

Thanks for getting in touch! Unfortunately when we start a deployment, at that point the machines to deploy to are set. They cannot be modified after a deployment has been created to start.
Placing this in it’s own Project may be the only way forward for such a scenario currently.

We do have the following UserVoice suggestion which you should vote and comment on as it may help in your scenario. Also as we will need to understand features people need, building apon this suggestion will help us to determine how to best build AWS features.

Vanessa

3

I released a long post that may be helpful yesterday.
It covers how to add / auto deploy to your systems as they come up in an AWS Auto scaling group, and how to remove/deregister them from octopus when they go down. Once it’s in place, it makes everything very simple, seamless, and automatic.

Check it out and let me know if you have any questions :slight_smile:

4

FYI to anyone that runs into this thread:

We started working on a feature for this called “Multitenancy”. More info about this over here:

Part 1: https://octopus.com/blog/rfc-multitenancy
Part 2: https://octopus.com/blog/rfc-multitenancy-take-two