Skip to content
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

Merged
merged 6 commits into from
Jul 2, 2021
Merged

Multi-OS Support for RKE2 runtime and binary builds (Adding Windows) #1212

merged 6 commits into from
Jul 2, 2021

Conversation

rosskirkpat
Copy link
Contributor

@rosskirkpat rosskirkpat commented Jun 29, 2021

Proposed Changes

Add windows binary build scripts via cross platform builds (no Windows build hosts are required at this time)
Add windows runtime image build
Add a `dockerfile.windows` for the windows runtime
Add manifest support for runtime images
Change runtime-image reference in build-binary to use the `*-linux-amd64` image as part of new manifest support 
Update makefile to reflect multi-OS state of rke2
Add windows airgap support via crane

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.0 With 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

Copy link
Member

@brandond brandond left a 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.

scripts/build-images Outdated Show resolved Hide resolved
Co-authored-by: Brad Davidson <[email protected]>
@rosskirkpat rosskirkpat removed the request for review from jenting June 30, 2021 19:52
@rosskirkpat rosskirkpat requested a review from briandowns July 1, 2021 15:49
Comment on lines 24 to 26
# 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.
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Member

@brandond brandond Jul 2, 2021

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.

Copy link
Contributor Author

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.

Copy link
Member

@brandond brandond Jul 2, 2021

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.

mkdir -p dist/artifacts

# 1809
crane pull --platform windows/amd64 ${REGISTRY}/${REPO}/${PROG}-runtime:${DOCKERIZED_VERSION}-windows-amd64 rke2-windows-1809-images.tar.gz
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

@rosskirkpat
Copy link
Contributor Author

@dweomer @briandowns Could I get another review on this?

@rosskirkpat rosskirkpat merged commit c5ca9ca into rancher:master Jul 2, 2021
rosskirkpat added a commit that referenced this pull request Jul 14, 2021
[backport 1.21] Merge pull request #1212 from rosskirkpat/add-windows
@rosskirkpat rosskirkpat linked an issue Jul 16, 2021 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/windows kind/feature A large new piece of functionality
Projects
None yet
3 participants