Easiest/most straightforward way to "cache" some additional, custom Docker images into the AMI Build?

[armenr]

Question:

Is there an easy/simple way to feed a list of additional container images to the AMI builder or builder scripts?

Use-case:

Using something like Keda, we want to rapidly scale "worker" pods up and down, based on some message being published to a queue somewhere in redis or rabbit.

The constraint on our use-case:

• We need those pods to scale up as quickly as possible, and our worker images are BIG
• Unfortunately there's no way around resizing the images - there's no practical path to making those images smaller, due to the codebase being legacy
• ~30second latency in queued job processing is acceptable, but when you have an 8GB Docker image to pull, it takes about ~30s for the node to be ready to serve workloads + ~2-3 minutes to pull and create the massive worker image.

The solution I'm contemplating:

Using the EKS-AMI builder, as it is, totally vanilla, but changing only 2 things:

1. Increase the size of the root volume on the AMI (to accommodate the space needed by our gigantic images)
2. Pass an additional list of those images to the builder so that it can do that in this stretch of the builder script: https://github.com/awslabs/amazon-eks-ami/blob/e39d71f6832221409cd9990ad85e870f6d621698/scripts/install-worker.sh#L435

Bonus (kind of a feature request)

It would be really cool to allow users/consumers of this repo to have some simple way to pass in a text file, or a comma-separated list of additional images that the "Cache Images" section of the install-worker.sh script 😬

Environment:

• AWS Region: NA
• Instance Type(s): NA
• EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion): NA
• Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): NA
• AMI Version: NA
• Kernel (e.g. uname -a): NA
• Release information (run cat /etc/eks/release on a node): NA