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

Weekly AMI releases #997

Open
elruwen opened this issue Mar 21, 2022 · 2 comments
Open

Weekly AMI releases #997

elruwen opened this issue Mar 21, 2022 · 2 comments

Comments

@elruwen
Copy link

elruwen commented Mar 21, 2022

Is your feature request related to a problem? Please describe.
At the moment (2022-03-21) AMIs are released not very frequently. This means they are behind with security patches (see https://alas.aws.amazon.com/alas2.html), which is an obvious problem.

Describe the solution you'd like
As a minimum I would like to have the following:
You build AMIs at least weekly. The only change is yum update -y. You publish the AMI names in a JSON file which is stored in S3.
Then users like me can download the file and use the CFN parameter for specifying the AMI.
The versioning needs to be something like x.y.z-YYYYMMDD. x.y.z = stack version.

This way my installation is not changing without my (or my pipelines) doing something. But whenever I want, I get the latest and greatest version.

Bonus - integrate it somehow into the stack
Here I am not sure how to do it, here are a few thoughts, needs some brainstorming imho:

  • releasing every week a new buildkite stack version is imho too much noise
  • additional parameter to enable a feature which at deployment time looks up automatically the latest version, this would need a custom resource -> the stack gets more complicated. If the feature is disable, the current behaviour is provided.

Describe alternatives you've considered

  • Run yum update -y via bootstrap. This is not enough for kernel upgrades which require a reboot. 👎

Additional context
Add any other context or screenshots about the feature request here.

@kayneb
Copy link

kayneb commented Apr 12, 2022

We also have this need. Alternatively, publish the latest AMI to an SSM parameter. This is in alignment with what AWS does with Amazon Linux 2 (e.g. SSM param name /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id).

@hcho3
Copy link
Contributor

hcho3 commented Aug 8, 2022

publish the latest AMI to an SSM parameter

I also have this need as well. Currently I maintain a custom AMI that's created on top of the BuildKite AMI; since the BuildKite AMI changes periodically, I have to tear down my EC2 image builder pipeline and create a new one. If the BuildKite AMI ID is published at a fixed SSM parameter, I can reuse the existing image pipeline.

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

3 participants