You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
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:
Describe alternatives you've considered
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.
The text was updated successfully, but these errors were encountered: