distributing snapshots with most common images

[FernandoMiguel]

Hi,

In order to speed up start up of common Pods, and avoid depending on external registries, I'm planning to distribute a EBS snapshot with our mostly common used containers.

In order for this to work, I have few questions.

Can I spin a EC2 instance, attach a secondary EBS to it, pull the list of images with a containerd compatible too, detach the volume, snapshot, and then just use that as the secondary AMI of bottlerocket EKS nodes?
Will the images be in the expected location without any further config change?

Thanks in advance.

[jpculp]

Hi @FernandoMiguel, thank you for reaching out. This might be something you can accomplish with a bootstrap container, but let me double-check with the rest of the team.

[FernandoMiguel]

Thanks for the idea.
If you can provide further guidance how to store those containers so that when we mount the ebs is the dedicated mount point, it's supported by bottlerocket, I would love to move on with my task.

Thanks again!

[jpculp]

I may have actually been overthinking this one and the functionality is actually baked in. You should be able to just boot up Bottlerocket with a second volume, load up your containers, and then snapshot from there.

[FernandoMiguel]

I though about that, but wouldn't that bring the container data too, not just the boot image?

[arnaldo2792]

Could you please elaborate on what you mean with container data? The procedure @jpculp described will help you pull down the container images where you need them (that is, in the secondary volume mounted at /local).

[FernandoMiguel]

@arnaldo2792 @jpculp maybe is a misunderstanding of the process of "loading up containers"
if workloads were to be run, they would download the image, and then boot the services.
the extra data from running the containers, would live in the same volume that one would like to snapshot.

[arnaldo2792]

Ah, I see what you mean now. So you don't want to include in the snapshot anything that the containers may create in their own file system.

Going back to your original question, yes it should be possible to do what you describe, as long as the EC2 instance that you use as your "base" is a Bottlerocket node. Otherwise, you may run into trouble due to the SELinux labeling. You could do what you described through a host container, since they will run almost right after the containerd service used by the orchestrator starts. This host container will have to be superpowered, since you need access to the root filesystem. In your host container, you will have to talk to containerd through /.bottlerocket/rootfs/run/containerd/containerd.sock.