Weekly AMI releases
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 -yvia bootstrap. This is not enough for kernel upgrades which require a reboot. :-1:
Additional context Add any other context or screenshots about the feature request here.
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).
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.