Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow spot requests in multiple availability zones #76

Closed
declension opened this issue Jun 3, 2019 · 3 comments
Closed

Allow spot requests in multiple availability zones #76

declension opened this issue Jun 3, 2019 · 3 comments

Comments

@declension
Copy link
Contributor

declension commented Jun 3, 2019

Background

At $WORK, we have a pre-defined VPC, and one subnet within that (but want more to avoid any further capacity issues) for Gitlab & runners.

Having multiple AZs is entirely possible, as the spot request wizard has checkboxes for each:

image

Proposal

  • Multiple availability zones (via aws_zone) can be specified as parameters, or
  • Multiple subnets (via a new subnet_ids_runners perhaps?) in various AZs, with the AZ inferred automatically, so deprecating aws_zone perhaps?

Notes

I don't know if this necessarily makes sense, but am definitely keen to find ways to improve our capacity-not-available problems (not pricing), and this seems like one major cause

@declension
Copy link
Contributor Author

declension commented Jun 3, 2019

Hmm, docker/machine#4701 (and docker/machine#4588) looks quite relevant / concerning...

@npalm
Copy link
Collaborator

npalm commented Jul 26, 2019

@declension you can spin now a runner in multiple zones, would this help see #77 and PR #96

@declension
Copy link
Contributor Author

Thanks @npalm, we'll try this soon. Closing for now

kayman-mk added a commit that referenced this issue Apr 21, 2023
… us to use multiple instance types and AZs (#777)

## Description

The
[fork](https://gitlab.com/cki-project/docker-machine/-/tree/v0.16.2-gitlab.19-cki.2)
of docker-machine used in this module has released a version that
supports [AWS Spot
Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
3 months ago.

In our case, spot fleets are useful when using spot instances because it
fixes the issue when there is no capacity available for a certain
instance type in a certain AZ. With spot fleets, we can use multiple
instance types and AZ so when there is no capacity on one instance type,
AWS will take the next instance type and so on.

This fixes issues
[#76](#76)
[#435](#435)
[#77](#77)
and
[#474](#474)

## Migrations required
NO our solution is backward compatible so if you don't plan to use spot
fleets, no migration is required.
YES if you want to use spot fleets you will have to do the following
changes:
`docker_machine_instance_type` to `docker_machine_instance_types`
`subnet_id` to `subnet_ids`

You also have to put these 2 new parameters:
`use_fleet` and `key_pair_name` 

### Important
We have seen that the
[fork](https://gitlab.com/cki-project/docker-machine/-/tree/v0.16.2-gitlab.19-cki.2)
of docker-machine this module is using consume more RAM using spot
fleets.
For comparison, if you launch 50 machines in the same time, it consumes
~1.2GB of RAM. In our case, we had to change the `instance_type` of the
runner from `t3.micro` to `t3.small`.

## Verification

```hcl
  docker_machine_instance_types = ["r5a.xlarge", "r5.xlarge", "r5ad.xlarge", "r5d.xlarge", "m5a.2xlarge"]
  use_fleet                     = true
  key_pair_name                 = "<key-pair-name>"
```
We are using this solution in production for a week now with 150+
developers and over 20 000 jobs a day without any issue for now.

---------

Signed-off-by: François Bibron <francois.bibron@polyconseil.fr>
Co-authored-by: François Bibron <francois.bibron@polyconseil.fr>
Co-authored-by: Marvin Wichmann <marvin@fam-wichmann.de>
Co-authored-by: Matthias Kay <github-public@matthiaskay.de>
Co-authored-by: kayma <kayma@hlag.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants