Part of #1166
What are we doing
In order to facilitate disconnected environments for Snow devices, we need to be able to store all container images needed for EKS-A in an AMI (Snow admin AMI), which will be deployed to a device and later used to populate a private registry.
The idea is that we will we use the CLI to both download and store the images and later populate the registry with them.
The CLI already provides an
import-images command. However, this one performs the pulling (downloading images from their origin) and pushing (populating the private registry) in one step. This means that internet connection is required to populate the registry. As explained previously, this won't work for Snow.
- Add a new command
- Add a sub-command
- Add a sub-command
- Deprecate the existing command
How do these command work
A couple of examples that are the most relevant to the Snow usecase:
- This will download the images from the original source (mostly ECR) and store them in a tarball. This command will require internet connection.
eksctl anywhere download images --output path/file_images.tar
- And then to populate the registry:
eksctl anywhere import images --input path/file_images.tar --registry https://djfkdks.xy/whatever
All the necessary input will be provided directly through flags and env vars and not through the cluster config file (like the current
import-image and other commands do). This is more flexible, more straight forward, easier to script and it doesn't require users to create and understand the syntax of a
Cluster object, which in my opinion belongs to a different subdomain.
Why storing images on disk
An alternative could have been to just rely on docker to store the container images. Since the "pull" command will be run before "committing" the AMI, once this one is deployed to a device and the VM is started, we should be able to just do
docker push against the private registry since the images should still be there.
While this works for the Snow design, it is a bit inflexible and it doesn't allow for other disconnected environments where the push and the pull are not run in the same machine. Using a tarball allows for easier portability.
Why a new command
The current behavior of
import-images is not flexible enough. Since the use of this command is not very extended (I don't have data to support this though), it is easier to deprecate it and create a new one, incorporating what have learned since we first introduce it. As opposed to trying to add more flags to alter how it works while keeping backwards compatibility.
Moreover, the CLI command tries to follow a
verb + resource pattern, so
import images follows this better than
import-images. Previous literature on this topic.
- The eks-a tools image needs to be imported separetly since it's needed
in order to initialize the helm executable, which is needed to push the
helm charts to the registry.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
approved lgtm size/XL