Add optional embedding of container images #239
Conversation
|
Hey @rpardini. If you have a few cycles, i'd love to get your review/opinions on this. Thanks! |
|
FYI, i missed cross platform support in the |
Latest commit has cross platform support and documentation. |
|
Very interesting stuff @jacobweinstock We could maybe take this as opportunity to introduce custom inventory entries -- a way to introduce new/custom flavors, eg, 'eks-anywhere-custom-xxx64 Btw, the |
jacobweinstock
force-pushed
the
embedded-images
branch
from
6d2a2df
to
b15c551
Compare
This version has volume support that is needed for embedding images. Signed-off-by: Jacob Weinstock <[email protected]>
Docker was warning about the case of `FROM` not matching `AS`. Signed-off-by: Jacob Weinstock <[email protected]>
This helps use cases where images already existing in the DinD cache is needed. Air gap envs, latency constrained/concerned envs, etc. Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
This makes it so that the correct architecture for the embedded images are pulled. Signed-off-by: Jacob Weinstock <[email protected]>
There is an example file already. The images.txt will be something the user creates for themselves. Signed-off-by: Jacob Weinstock <[email protected]>
This removes the need to mv the directory of embedded images. This is accomplished by bind mount (rw) the read only images location onto the /var/lib/docker directory in the Hook-docker container. This means that start up doesn't need to wait for the mv command to complete. So startup doesn't incur any delay like it was with the mv. This also means that we can embed a lot more images with having start up issue. In testing, I found that if enough images, compared to the amount of memory available, were embedded then HookOS would not boot up. It would max out on memory. It's possible with enough time that it would have booted but i didnt wait longer than about 30min. Signed-off-by: Jacob Weinstock <[email protected]>
Instead of having hook-docker know about mounting the embedded images, the images get mounted with the right permissions and made available to hook-docker at the "usual" location. This decouples this embedding process from hook-docker. This should allow the two to only be coupled by the mount point of /var/run/images. Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
It adds an unnecessary place to need to be aware of when adding or renaming files. Signed-off-by: Jacob Weinstock <[email protected]>
Allows users to specify specific versions of docker:dind to use. Signed-off-by: Jacob Weinstock <[email protected]>
This pulls images from the local docker client instead of from the DinD container. This will allow for registries that need logged into and any proxying that might be needed to occur during an image pull. Signed-off-by: Jacob Weinstock <[email protected]>
When existing images in the local Docker image cache existed for an image the `--platform` arg doesn't matter. This means that when an existing amd64 image is already in the cache the arm64 pulls will not happen. To fix this we always delete the image before pulling. Signed-off-by: Jacob Weinstock <[email protected]>
This resolves issues with needing to mount the docker.sock and needing sudo. Signed-off-by: Jacob Weinstock <[email protected]>
Because hook-docker uses the overlay2 storage driver, the local docker client using pull-images.sh must also use the overlay2 storage driver. Signed-off-by: Jacob Weinstock <[email protected]>
The host Docker storage driver actually doesn't matter at all because we use DinD. This was my mistake. Signed-off-by: Jacob Weinstock <[email protected]>
This adds the ability to remove the "source image" tag from the final embedded images. This leaves only the "additional tag". Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
As hook-docker uses the overlay2 storage driver the DinD image must use the overlay2 storage driver too. Signed-off-by: Jacob Weinstock <[email protected]>
This resolves an issue with things like apk not working in the ssh container. Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock
force-pushed
the
embedded-images
branch
from
9a36764
to
6be6b09
Compare
Remove tabs that were causing the build to fail. Signed-off-by: Jacob Weinstock <[email protected]>
Update go.mod dependencies. Check for tink-worker image and don't fail the image pull if it doesn't exist. With embedded images, the tink worker could potentially already exist in the local Docker image cache. And the image name could be something unreachable via the network (for example: 127.0.0.1/embedded/tink-worker). Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock
force-pushed
the
embedded-images
branch
from
b220c3e
to
78f2850
Compare
Hey @rpardini. I'm open to the idea. I think we might need a little more traction for embedded images first though. Now worries about the |
|
Hey @rpardini, I'm going to merge this but if you have any concerns let me know and we can iterate on it. Thanks! |
Description
This adds the optional capability to embed container images into hook-docker. This helps use cases where images already existing in the DinD cache is needed. Air gap envs, latency constrained/concerned envs, etc. Just FYI, with this change but without embedding any images the final 6.6 kernel initramfs is 171 MB. The v0.9.0 initramfs also 171 MB
Why is this needed
Fixes: #
How Has This Been Tested?
How are existing users impacted? What migration steps/scripts do we need?
Checklist:
I have: