Build images on the node directly #1253
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some k8s flavours place "unix://" in front of the path.
This commit does two things: - it reworks the argo workflow into a pod. The reason is that the containers that argo injects share the volumes of the container we specify, and, when using bidirectional mounting, it leads to errors because said mounting requires a privileged container, and it's currently not possible to specify such an option for the containers that argo injects. We ended up not needing to use bidirectional mounting at the builder level but I've decided to still go with this since it would take time to revert and we might need bidirectional mountin at the builder level in the future. - adds support for a buildkit worker by changing what worker is used based on the container runtime and adjusting the logging sidecar In hindsight the commit should probably have been split in two.
fruttasecca
added
new feature request
services/orchest-controller/pkg/controller/orchestcomponent/node_agent.go
Show resolved
Hide resolved
services/orchest-controller/pkg/controller/orchestcluster/cluster_utils.go
Outdated
Show resolved
Hide resolved
services/orchest-controller/pkg/controller/orchestcomponent/buildkit_daemon.go
Outdated
Show resolved
Hide resolved
|
From my high-level understanding of what is being done in this PR, I think it looks good. The exact impact/requirement of the mounts I can only vaguely guess, but overall I don't see anything wrong with the approach. 😸 |
Sticking with spaces instead of tabs
Write to JupyterLab user settings during custom Jupyter server build
fruttasecca
force-pushed
the
feat/build-images-on-the-node-directly
branch
from
232f44d
to
1e8644b
Compare
nhaghighat
reviewed
Sep 13, 2022
services/orchest-controller/pkg/controller/orchestcomponent/buildkit_daemon.go
Show resolved
Hide resolved
Base automatically changed from
feat/env-builds-parallelism
to
improv/change-image-digest-management
September 13, 2022 16:06
nhaghighat
approved these changes
Sep 13, 2022
Base automatically changed from
improv/change-image-digest-management
to
improv/change-built-image-distribution-model
September 14, 2022 05:02
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Makes it so that all image builds (environment and custom jupyter) are built directly on the node. This allows a faster build since the image doesn't need to be pushed to the registry to consider the build complete, and allows starting steps or other pods that depend on the new image right away.
To accomplish this, we distinguish between our two supported container runtimes (
dockerandcontainerd) and use a different builder for a different runtime,buildxandbuildkitrespectively. In the case ofbuildkit+containerd, bidirectional mounting is needed, and, given the introduced risk, thebuildkitdaemon is not run ephemerally as part of the builder pod but runs as a daemonset. This is to reduce the risk of issues when it comes to the daemonset having to remove temporary mounts etc.When using
buildx, we mount the container runtime socket into the builder pod, which will use thedocker buildxCLI to communicate with the runtime and build. Withbuildkit, we mount the socket of thebuildkitdaemon into the builder pod; thebuildkitdaemon (and daemonset) will mount the socket of the container runtime.This PR introduces 3 new Orchest images:
buildx-builderbuildkit-builderbuildkit-daemonAs a result of this change the way changes to base images are tested has been simplified.