-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-OS Support for RKE2 runtime and binary builds (Adding Windows) #1212
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theres a lot here, but LGTM. One minor consistency nit in the image list.
Co-authored-by: Brad Davidson <[email protected]>
scripts/package-windows-images
Outdated
# We reorder the tar file so that the metadata files are at the start of the archive, which should make loading | ||
# the runtime image faster. By default `docker image save` puts these at the end of the archive, which means the entire | ||
# tarball needs to be read even if you're just loading a single image. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you've got the comment here but appear to be missing the bsdtar steps to actually do what the comment is describing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the windows tar.gz files are built by crane. I don't plan on trying to reorder them as that may break/alter the functionality of the tarballs when extracted. I removed the comment in my latest push
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an optimization to improve the startup speed when looking for the runtime image in multiple tarballs. Removing this will significantly slow down initial startup in airgap environments. Reordering the files within the tar stream is safe regardless of platform. I'd recommend not dropping it unless you can confirm that it causes problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The windows image tarballs will each have 2 images in them at this time - the windows runtime and the correct pause image for the Windows build version. Crane is packaging up the tar.gz and the contents would look like this:
tar -tf rke2-windows-images.tar.gz
sha256:f5c4a8f6b60caff371d121a0df1945f320d3899835e1088376800d77dba1efb2
cf46e160c188a31a9dd458b9284c495d1b14b30049433efc65a4d7b08ca22f43.tar.gz
f7c28887ef2c26a36b1fa523c3103ad50b38f35458f8e24acab69d62ab6f484a.tar.gz
5ec615e8678d3f48a46ad22dcabd1cf4324e5ba046cce99060c076b0892f955f.tar.gz
e586d89f6fb22f6643b8147da761295447cb70863709aed0001cf86aa8d308b7.tar.gz
manifest.json
Each of the tarballs for the build versions will be compressed with zstd and then the original tar.gz will simply be copied to dist/artifacts/
like so.
rke2-windows-1809-images.tar.gz
rke2-windows-2004-images.tar.gz
rke2-windows-20H2-images.tar.gz
Once k8s 1.22 drops and we have privileged containers and host processes, we would need to add the optimization back in as we would have tarballs for all of our components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's the issue - crane and docker both put the manifest (the list of images and layers contained by the tarball) at the very end of the stream, which means that the entire tarball needs to decompressed and read to see if it contains the image we're looking for. Using bsdtar to move that to the front of the tar stream means that we can very quickly determine if it does or does not have what we're looking for, and move on to the next archive if necessary.
scripts/package-windows-images
Outdated
mkdir -p dist/artifacts | ||
|
||
# 1809 | ||
crane pull --platform windows/amd64 ${REGISTRY}/${REPO}/${PROG}-runtime:${DOCKERIZED_VERSION}-windows-amd64 rke2-windows-1809-images.tar.gz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is crane the only way to do this? It'd be nice if we could use the same tooling for exporting all the images; if you're going to use crane for Windows we might as well use it for linux as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, crane is the only way we can pull windows images on linux drone hosts. I was actually investigating how crane could replace all of the existing docker cli usage for non-windows builds and simplify the build-images and package-images process.
This change was required due to the need for Windows airgap support and discussion that took place on the best possible way to achieve it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened a new issue for tracking migrating to crane #1243
@dweomer @briandowns Could I get another review on this? |
[backport 1.21] Merge pull request #1212 from rosskirkpat/add-windows
Proposed Changes
Big Picture: These changes are required for the RKE2 Windows release as part of 2.6.0
Documentation will need updating to indicate that RKE2 will support Windows on 2.6.0/1.21.x. We will also need to document the guard rails for initial windows support on rke2.
Additionally, Air-gap will work for rke2 on windows in 2.6.0.
but it will require it's own script to pull the images on a Windows host. The pause images for windows would require running 3 Windows drone nodes (1809/2004/20H2) and we decided that documenting this and providing a script for pulling the Windows air-gap images would meet requirements for 2.6.0With the use of crane, we are able to pull windows images as tarballs on linux build hosts.Types of Changes
New Feature
Linked Issues
#1166