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

Experimental BuildKit support #37151

Merged
merged 37 commits into from
Jun 12, 2018
Merged

Conversation

tonistiigi
Copy link
Member

@tonistiigi tonistiigi commented May 25, 2018

This PR adds experimental support for using moby/buildkit as a backend for docker build. #32925 #34227

The support is only enabled in the experimental daemon, and user needs to opt-in in docker/cli to start using it.

# in daemon
dockerd -D --experimental

# in Docker CLI
export DOCKER_BUILDKIT=1
docker build .

Docker CLI branch with BuildKit support enabled is in https://github.com/tonistiigi/docker-cli/tree/experimental-buildkit

In the API, version field allows switching between different build backends.

This enables lots of new capabilities, including parallel build steps and requests, skipping unused stages, efficient incremental builds, build context file detection, remote cache support, graceful cancellation, build cache issues, etc. It also enables using experimental Dockerfile features without requiring to update Moby by using the BuildKit frontend images.

The technical side of this integration is a temporary (and somewhat limited) solution as BuildKit is based on containerd storage and that has not been integrated into Moby yet. The current solution provides adapters to some components to provide compatibility between things like containerd snapshots and Moby layerstore/storage drivers or image store. When containerd storage support lands in Moby, all these adapters should be removed entirely, and BuildKit can use containerd directly. This temporary solution allows us to get feedback before we feel comfortable to move it out of experimental.

The tests will not currently use BuildKit in the PR as it requires opt-in and a new CLI binary. We have run the tests manually. Some of them need to be reworked for output change or a side-effect removal. We will continue addressing some of the test results that we are still investigating.

Known issues (some of them will not make it into 18.06 release):

  • no automatic GC (manual system df and system prune work)
  • pulling schema1 images during build
  • automatic path detection in dockerfile doesn't detect unused symlinks
  • resource limitation and --net options: execution completely bypasses the daemon, net is host.
  • windows support (depending on containerd runtime integration)
  • --pull (currently existing images in image store always take precedence)
  • USER doesn't set additional groups
  • --iidfile is not enabled in CLI
  • No way to export remote build cache. Build cache exported with standalone BuildKit can be imported with --cache-from.

@tiborvass @AkihiroSuda

depends on #36895

asciicast

var _ snapshot.SnapshotterBase = &snapshotter{}

// NewSnapshotter creates a new snapshotter
func NewSnapshotter(opt Opt) (snapshot.SnapshotterBase, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we split this to a separate package that wraps Moby graphdriver as a containerd snapshotter?

cc @dmcgowan

Copy link
Member Author

@tonistiigi tonistiigi May 25, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, the issue is that containerd mounts are stateless while some graphdrives can't produce stateless mounts. @dmcgowan has a plan for that for Moby integration that is somewhat similar to the buildkit/snapshot.Mountable abstraction.

@@ -0,0 +1,179 @@
package containerimage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I couldn't use it directly was that buildkit uses the blobsum-diffid pairs here while Moby doesn't yet have an understanding of managing layer blobs. But with a careful refactor, some parts of it can definitely be shared.

BuilderV1 BuilderVersion = "1"
// BuilderBuildKit is builder based on moby/buildkit project
BuilderBuildKit = "2"
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: can we just use strings rather than numbers? e.g. legacy and buildkit

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AkihiroSuda I don't like the word legacy (which is what it was initially). With all the respect I have for buildkit, with time everything becomes legacy and eventually you'll have to differentiate between legacy legacy and legacy. This problem is solved with versions, so I believe it's a better tradeoff this way. Happy to hear your concerns though.

@@ -181,8 +181,20 @@ type ImageBuildOptions struct {
Target string
SessionID string
Platform string
Version BuilderVersion
BuildID string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add godoc?

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On high level, definitely Design LGTM 😻

In this PR it seems it's not possible to choose a different frontend yet right ? if yes, is it something we plan to allow before going out of experimental ?
I see the gateway.v0 frontend is there so it seems it's already possible to use custom images as frontend (which is awesome 💓) but I'm not sure how to specify it from the API standpoint.

Also, should we open a PR in docker/cli to discuss the cli design in parallel ; and also easily have a docker binary built to make manual testing easier (without having to clone and build the cli)

@tonistiigi
Copy link
Member Author

In this PR it seems it's not possible to choose a different frontend yet right ? if yes, is it something we plan to allow before going out of experimental ? I see the gateway.v0 frontend is there so it seems it's already possible to use custom images as frontend (which is awesome 💓) but I'm not sure how to specify it from the API standpoint.

Custom Dockerfile implementations can be used with a Dockerfile directive moby/buildkit#384 but generic frontends (or raw LLB) is not currently enabled in HTTP API. As this would be a new feature, it probably makes sense to do discuss/PR that separately. It may definitely happen in experimental is maintainers agree.

Also, should we open a PR in docker/cli to discuss the cli design in parallel ; and also easily have a docker binary built to make manual testing easier (without having to clone and build the cli)

There's still some cleanup stuff that needs to happen there. You can expect a PR early next week.

@codecov
Copy link

codecov bot commented May 26, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@0c4ed4e). Click here to learn what that means.
The diff coverage is 2.77%.

@@            Coverage Diff            @@
##             master   #37151   +/-   ##
=========================================
  Coverage          ?   35.33%           
=========================================
  Files             ?      609           
  Lines             ?    45000           
  Branches          ?        0           
=========================================
  Hits              ?    15901           
  Misses            ?    26947           
  Partials          ?     2152

@cpuguy83
Copy link
Member

Design LGTM

Copy link
Contributor

@tiborvass tiborvass left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tiborvass
Copy link
Contributor

It's really unfortunate to have all these unrelated CI issues.

Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if the regression is fixed now.

@tiborvass
Copy link
Contributor

@AkihiroSuda yes, regression was on docker CLI.

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🦁

@tiborvass
Copy link
Contributor

CI for powerpc and s390x are known to have issues /cc @andrewhsu @seemethere.

@tiborvass tiborvass merged commit c752b09 into moby:master Jun 12, 2018
@lowenna
Copy link
Member

lowenna commented Jun 13, 2018

This has broken master on Windows:

PS C:\> dockerd
INFO[2018-06-13T09:04:23.208583500-07:00] Windows default isolation mode: process
INFO[2018-06-13T09:04:23.294671100-07:00] Loading containers: start.
INFO[2018-06-13T09:04:23.298646300-07:00] Restoring existing overlay networks from HNS into docker
INFO[2018-06-13T09:04:23.399254200-07:00] Loading containers: done.
INFO[2018-06-13T09:04:23.402261600-07:00] Docker daemon                                 commit=692df4699c graphdriver(s)=windowsfilter version=0.0.0-dev
INFO[2018-06-13T09:04:23.405258500-07:00] Daemon has completed initialization
failed to find git binary: exec: "git": executable file not found in %PATH%
PS C:\>

@tiborvass
Copy link
Contributor

@jhowardmsft Thanks. Sorry about that. Windows CI was green :(

@lowenna
Copy link
Member

lowenna commented Jun 13, 2018

@tiborvass Yes, the CI servers have (and need) git installed :/

@@ -8,10 +8,12 @@ import (
"github.com/docker/docker/api/types"
"github.com/docker/docker/api/types/backend"
"github.com/docker/docker/builder"
buildkit "github.com/docker/docker/builder/builder-next"

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.