Guest24897
/
DockerCLI
mirror of https://github.com/docker/cli.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

vendor: bump buildkit 4f4e03067523b2fc5ca2f17514a5e75ad63e02fb 

full diff: f7042823e3...4f4e030675

no changes to vendored files

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2020-01-07 09:39:44 +01:00
parent dff269b5e4
commit ece71412c0
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
3 changed files with 228 additions and 136 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
vendor.conf
View File

@ -45,7 +45,7 @@ github.com/Microsoft/go-winio 6c72808b55902eae4c5943626030
github.com/Microsoft/hcsshim b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2
github.com/miekg/pkcs11 cb39313ec884f2cd77f4762875fe96aecf68f8e3 # v1.0.2
github.com/mitchellh/mapstructure f15292f7a699fcc1a38a80977f80a046874ba8ac
github.com/moby/buildkit f7042823e340d38d1746aa675b83d1aca431cee3 # v0.6.1-71-gf7042823
github.com/moby/buildkit 4f4e03067523b2fc5ca2f17514a5e75ad63e02fb
github.com/modern-go/concurrent bacd9c7ef1dd9b15be4a9909b8ac7a4e313eec94 # 1.0.3
github.com/modern-go/reflect2 4b7aa43c6742a2c18fdef89dd197aaae7dac7ccd # 1.0.1
github.com/morikuni/aec 39771216ff4c63d11f5e604076f9c45e8be1067b

360
vendor/github.com/moby/buildkit/README.md generated vendored
View File

@ -1,6 +1,6 @@
[![asciicinema example](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU.png)](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU)
## BuildKit
# BuildKit
[![GoDoc](https://godoc.org/github.com/moby/buildkit?status.svg)](https://godoc.org/github.com/moby/buildkit/client/llb)
[![Build Status](https://travis-ci.org/moby/buildkit.svg?branch=master)](https://travis-ci.org/moby/buildkit)
@ -25,49 +25,107 @@ Read the proposal from https://github.com/moby/moby/issues/32925
Introductory blog post https://blog.mobyproject.org/introducing-buildkit-17e056cc5317
Join `#buildkit` channel on [Docker Community Slack](http://dockr.ly/slack)
:information_source: If you are visiting this repo for the usage of experimental Dockerfile features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`, please refer to [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experimental.md).
### Used by
:information_source: [BuildKit has been integrated to `docker build` since Docker 18.06 .](https://docs.docker.com/develop/develop-images/build_enhancements/)
You don't need to read this document unless you want to use the full-featured standalone version of BuildKit.
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Used by](#used-by)
- [Quick start](#quick-start)
- [Starting the `buildkitd` daemon:](#starting-the-buildkitd-daemon)
- [Exploring LLB](#exploring-llb)
- [Exploring Dockerfiles](#exploring-dockerfiles)
- [Building a Dockerfile with `buildctl`](#building-a-dockerfile-with-buildctl)
- [Building a Dockerfile using external frontend:](#building-a-dockerfile-using-external-frontend)
- [Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`](#building-a-dockerfile-with-experimental-features-like-run---mounttypebindcachetmpfssecretssh)
- [Output](#output)
- [Registry](#registry)
- [Local directory](#local-directory)
- [Docker tarball](#docker-tarball)
- [OCI tarball](#oci-tarball)
- [containerd image store](#containerd-image-store)
- [Cache](#cache)
- [Garbage collection](#garbage-collection)
- [Export cache](#export-cache)
- [Inline (push image and cache together)](#inline-push-image-and-cache-together)
- [Registry (push image and cache separately)](#registry-push-image-and-cache-separately)
- [Local directory](#local-directory-1)
- [`--export-cache` options](#--export-cache-options)
- [`--import-cache` options](#--import-cache-options)
- [Consistent hashing](#consistent-hashing)
- [Expose BuildKit as a TCP service](#expose-buildkit-as-a-tcp-service)
- [Load balancing](#load-balancing)
- [Containerizing BuildKit](#containerizing-buildkit)
- [Kubernetes](#kubernetes)
- [Daemonless](#daemonless)
- [Opentracing support](#opentracing-support)
- [Running BuildKit without root privileges](#running-buildkit-without-root-privileges)
- [Building multi-platform images](#building-multi-platform-images)
- [Contributing](#contributing)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Used by
BuildKit is used by the following projects:
- [Moby & Docker](https://github.com/moby/moby/pull/37151)
- [Moby & Docker](https://github.com/moby/moby/pull/37151) (`DOCKER_BUILDKIT=1 docker build`)
- [img](https://github.com/genuinetools/img)
- [OpenFaaS Cloud](https://github.com/openfaas/openfaas-cloud)
- [container build interface](https://github.com/containerbuilding/cbi)
- [Knative Build Templates](https://github.com/knative/build-templates)
- [Tekton Pipelines](https://github.com/tektoncd/catalog) (formerly [Knative Build Templates](https://github.com/knative/build-templates))
- [the Sanic build tool](https://github.com/distributed-containers-inc/sanic)
- [vab](https://github.com/stellarproject/vab)
- [Rio](https://github.com/rancher/rio)
- [PouchContainer](https://github.com/alibaba/pouch)
- [Docker buildx](https://github.com/docker/buildx)
### Quick start
## Quick start
Dependencies:
:information_source: For Kubernetes deployments, see [`examples/kubernetes`](./examples/kubernetes).
BuildKit is composed of the `buildkitd` daemon and the `buildctl` client.
While the `buildctl` client is available for Linux, macOS, and Windows, the `buildkitd` daemon is only available for Linux currently.
The `buildkitd` daemon requires the following components to be installed:
- [runc](https://github.com/opencontainers/runc)
- [containerd](https://github.com/containerd/containerd) (if you want to use containerd worker)
The following command installs `buildkitd` and `buildctl` to `/usr/local/bin`:
The latest binaries of BuildKit are available [here](https://github.com/moby/buildkit/releases) for Linux, macOS, and Windows.
```bash
$ make && sudo make install
[Homebrew package](https://formulae.brew.sh/formula/buildkit) (unofficial) is available for macOS.
```console
$ brew install buildkit
```
You can also use `make binaries-all` to prepare `buildkitd.containerd_only` and `buildkitd.oci_only`.
To build BuildKit from source, see [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md).
#### Starting the buildkitd daemon:
### Starting the `buildkitd` daemon:
You need to run `buildkitd` as the root user on the host.
```bash
buildkitd --debug --root /var/lib/buildkit
$ sudo buildkitd
```
To run `buildkitd` as a non-root user, see [`docs/rootless.md`](docs/rootless.md).
The buildkitd daemon supports two worker backends: OCI (runc) and containerd.
By default, the OCI (runc) worker is used. You can set `--oci-worker=false --containerd-worker=true` to use the containerd worker.
We are open to adding more backends.
#### Exploring LLB
The buildkitd daemon listens gRPC API on `/run/buildkit/buildkitd.sock` by default, but you can also use TCP sockets.
See [Expose BuildKit as a TCP service](#expose-buildkit-as-a-tcp-service).
### Exploring LLB
BuildKit builds are based on a binary intermediate format called LLB that is used for defining the dependency graph for processes running part of your build. tl;dr: LLB is to Dockerfile what LLVM IR is to C.
@ -76,49 +134,23 @@ BuildKit builds are based on a binary intermediate format called LLB that is use
- Efficiently cacheable
- Vendor-neutral (i.e. non-Dockerfile languages can be easily implemented)
See [`solver/pb/ops.proto`](./solver/pb/ops.proto) for the format definition.
See [`solver/pb/ops.proto`](./solver/pb/ops.proto) for the format definition, and see [`./examples/README.md`](./examples/README.md) for example LLB applications.
Currently, following high-level languages has been implemented for LLB:
Currently, the following high-level languages has been implemented for LLB:
- Dockerfile (See [Exploring Dockerfiles](#exploring-dockerfiles))
- [Buildpacks](https://github.com/tonistiigi/buildkit-pack)
- [Mockerfile](https://matt-rickard.com/building-a-new-dockerfile-frontend/)
- [Gockerfile](https://github.com/po3rin/gockerfile)
- (open a PR to add your own language)
For understanding the basics of LLB, `examples/buildkit*` directory contains scripts that define how to build different configurations of BuildKit itself and its dependencies using the `client` package. Running one of these scripts generates a protobuf definition of a build graph. Note that the script itself does not execute any steps of the build.
### Exploring Dockerfiles
You can use `buildctl debug dump-llb` to see what data is in this definition. Add `--dot` to generate dot layout.
Frontends are components that run inside BuildKit and convert any build definition to LLB. There is a special frontend called gateway (`gateway.v0`) that allows using any image as a frontend.
```bash
go run examples/buildkit0/buildkit.go \
| buildctl debug dump-llb \
| jq .
```
During development, Dockerfile frontend (`dockerfile.v0`) is also part of the BuildKit repo. In the future, this will be moved out, and Dockerfiles can be built using an external image.
To start building use `buildctl build` command. The example script accepts `--with-containerd` flag to choose if containerd binaries and support should be included in the end result as well.
```bash
go run examples/buildkit0/buildkit.go \
| buildctl build
```
`buildctl build` will show interactive progress bar by default while the build job is running. If the path to the trace file is specified, the trace file generated will contain all information about the timing of the individual steps and logs.
Different versions of the example scripts show different ways of describing the build definition for this project to show the capabilities of the library. New versions have been added when new features have become available.
- `./examples/buildkit0` - uses only exec operations, defines a full stage per component.
- `./examples/buildkit1` - cloning git repositories has been separated for extra concurrency.
- `./examples/buildkit2` - uses git sources directly instead of running `git clone`, allowing better performance and much safer caching.
- `./examples/buildkit3` - allows using local source files for separate components eg. `./buildkit3 --runc=local | buildctl build --local runc-src=some/local/path`
- `./examples/dockerfile2llb` - can be used to convert a Dockerfile to LLB for debugging purposes
- `./examples/gobuild` - shows how to use nested invocation to generate LLB for Go package internal dependencies
#### Exploring Dockerfiles
Frontends are components that run inside BuildKit and convert any build definition to LLB. There is a special frontend called gateway (gateway.v0) that allows using any image as a frontend.
During development, Dockerfile frontend (dockerfile.v0) is also part of the BuildKit repo. In the future, this will be moved out, and Dockerfiles can be built using an external image.
##### Building a Dockerfile with `buildctl`
#### Building a Dockerfile with `buildctl`
```bash
buildctl build \
@ -136,22 +168,7 @@ buildctl build \
`--local` exposes local source files from client to the builder. `context` and `dockerfile` are the names Dockerfile frontend looks for build context and Dockerfile location.
##### build-using-dockerfile utility
For people familiar with `docker build` command, there is an example wrapper utility in `./examples/build-using-dockerfile` that allows building Dockerfiles with BuildKit using a syntax similar to `docker build`.
```bash
go build ./examples/build-using-dockerfile \
&& sudo install build-using-dockerfile /usr/local/bin
build-using-dockerfile -t myimage .
build-using-dockerfile -t mybuildkit -f ./hack/dockerfiles/test.Dockerfile .
# build-using-dockerfile will automatically load the resulting image to Docker
docker inspect myimage
```
##### Building a Dockerfile using [external frontend](https://hub.docker.com/r/docker/dockerfile/tags/):
#### Building a Dockerfile using external frontend:
External versions of the Dockerfile frontend are pushed to https://hub.docker.com/r/docker/dockerfile-upstream and https://hub.docker.com/r/docker/dockerfile and can be used with the gateway frontend. The source for the external frontend is currently located in `./frontend/dockerfile/cmd/dockerfile-frontend` but will move out of this repository in the future ([#163](https://github.com/moby/buildkit/issues/163)). For automatic build from master branch of this repository `docker/dockerfile-upsteam:master` or `docker/dockerfile-upstream:master-experimental` image can be used.
@ -168,7 +185,7 @@ buildctl build \
--opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org
```
##### Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`
#### Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`
See [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experimental.md).
@ -176,24 +193,26 @@ See [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experi
By default, the build result and intermediate cache will only remain internally in BuildKit. An output needs to be specified to retrieve the result.
##### Exporting resulting image to containerd
The containerd worker needs to be used
```bash
buildctl build ... --output type=image,name=docker.io/username/image
ctr --namespace=buildkit images ls
```
##### Push resulting image to registry
#### Registry
```bash
buildctl build ... --output type=image,name=docker.io/username/image,push=true
```
If credentials are required, `buildctl` will attempt to read Docker configuration file.
To export and import the cache along with the image, you need to specify `--export-cache type=inline` and `--import-cache type=registry,ref=...`.
See [Export cache](#export-cache).
##### Exporting build result back to client
```bash
buildctl build ...\
--output type=image,name=docker.io/username/image,push=true \
--export-cache type=inline \
--import-cache type=registry,ref=docker.io/username/image
```
If credentials are required, `buildctl` will attempt to read Docker configuration file `$DOCKER_CONFIG/config.json`.
`$DOCKER_CONFIG` defaults to `~/.docker`.
#### Local directory
The local client will copy the files directly to the client. This is useful if BuildKit is being used for building something else than container images.
@ -222,70 +241,150 @@ buildctl build ... --output type=tar,dest=out.tar
buildctl build ... --output type=tar > out.tar
```
##### Exporting built image to Docker
#### Docker tarball
```bash
# exported tarball is also compatible with OCI spec
buildctl build ... --output type=docker,name=myimage | docker load
```
##### Exporting [OCI Image Format](https://github.com/opencontainers/image-spec) tarball to client
#### OCI tarball
```bash
buildctl build ... --output type=oci,dest=path/to/output.tar
buildctl build ... --output type=oci > output.tar
```
#### containerd image store
### Exporting/Importing build cache (not image itself)
#### To/From registry
The containerd worker needs to be used
```bash
buildctl build ... --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
buildctl build ... --import-cache type=registry,ref=localhost:5000/myrepo:buildcache
buildctl build ... --output type=image,name=docker.io/username/image
ctr --namespace=buildkit images ls
```
#### To/From local filesystem
To change the containerd namespace, you need to change `worker.containerd.namespace` in [`/etc/buildkit/buildkitd.toml`](./docs/buildkitd.toml.md).
```bash
buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir
```
The directory layout conforms to OCI Image Spec v1.0.
## Cache
#### `--export-cache` options
- `mode=min` (default): only export layers for the resulting image
- `mode=max`: export all the layers of all intermediate steps
- `ref=docker.io/user/image:tag`: reference for `registry` cache exporter
- `dest=path/to/output-dir`: directory for `local` cache exporter
#### `--import-cache` options
- `ref=docker.io/user/image:tag`: reference for `registry` cache importer
- `src=path/to/input-dir`: directory for `local` cache importer
- `digest=sha256:deadbeef`: digest of the manifest list to import for `local` cache importer. Defaults to the digest of "latest" tag in `index.json`
### Other
#### View build cache
To show local build cache (`/var/lib/buildkit`):
```bash
buildctl du -v
```
#### Show enabled workers
To prune local build cache:
```bash
buildctl debug workers -v
buildctl prune
```
### Running containerized buildkit
### Garbage collection
BuildKit can also be used by running the `buildkitd` daemon inside a Docker container and accessing it remotely. The client tool `buildctl` is also available for Mac and Windows.
See [`./docs/buildkitd.toml.md`](./docs/buildkitd.toml.md).
We provide `buildkitd` container images as [`moby/buildkit`](https://hub.docker.com/r/moby/buildkit/tags/):
### Export cache
BuildKit supports the following cache exporters:
* `inline`: embed the cache into the image, and push them to the registry together
* `registry`: push the image and the cache separately
* `local`: export to a local directory
In most case you want to use the `inline` cache exporter.
However, note that the `inline` cache exporter only supports `min` cache mode.
To enable `max` cache mode, push the image and the cache separately by using `registry` cache exporter.
#### Inline (push image and cache together)
```bash
buildctl build ... \
--output type=image,name=docker.io/username/image,push=true \
--export-cache type=inline \
--import-cache type=registry,ref=docker.io/username/image
```
Note that the inline cache is not imported unless `--import-cache type=registry,ref=...` is provided.
:information_source: Docker-integrated BuildKit (`DOCKER_BUILDKIT=1 docker build`) and `docker buildx`requires
`--build-arg BUILDKIT_INLINE_CACHE=1` to be specified to enable the `inline` cache exporter.
However, the standalone `buildctl` does NOT require `--opt build-arg:BUILDKIT_INLINE_CACHE=1` and the build-arg is simply ignored.
#### Registry (push image and cache separately)
```bash
buildctl build ... \
--output type=image,name=localhost:5000/myrepo:image,push=true \
--export-cache type=registry,ref=localhost:5000/myrepo:buildcache \
--import-cache type=registry,ref=localhost:5000/myrepo:buildcache \
```
#### Local directory
```bash
buildctl build ... --export-cache type=local,dest=path/to/output-dir
buildctl build ... --import-cache type=local,src=path/to/input-dir,digest=sha256:deadbeef
```
The directory layout conforms to OCI Image Spec v1.0.
Currently, you need to specify the `digest` of the manifest list to import for `local` cache importer.
This is planned to default to the digest of "latest" tag in `index.json` in future.
#### `--export-cache` options
- `type`: `inline`, `registry`, or `local`
- `mode=min` (default): only export layers for the resulting image
- `mode=max`: export all the layers of all intermediate steps. Not supported for `inline` cache exporter.
- `ref=docker.io/user/image:tag`: reference for `registry` cache exporter
- `dest=path/to/output-dir`: directory for `local` cache exporter
#### `--import-cache` options
- `type`: `registry` or `local`. Use `registry` to import `inline` cache.
- `ref=docker.io/user/image:tag`: reference for `registry` cache importer
- `src=path/to/input-dir`: directory for `local` cache importer
- `digest=sha256:deadbeef`: digest of the manifest list to import for `local` cache importer.
### Consistent hashing
If you have multiple BuildKit daemon instances but you don't want to use registry for sharing cache across the cluster,
consider client-side load balancing using consistent hashing.
See [`./examples/kubernetes/consistenthash`](./examples/kubernetes/consistenthash).
## Expose BuildKit as a TCP service
The `buildkitd` daemon can listen the gRPC API on a TCP socket.
It is highly recommended to create TLS certificates for both the daemon and the client (mTLS).
Enabling TCP without mTLS is dangerous because the executor containers (aka Dockerfile `RUN` containers) can call BuildKit API as well.
```bash
buildkitd \
--addr tcp://0.0.0.0:1234 \
--tlscacert /path/to/ca.pem \
--tlscert /path/to/cert.pem \
--tlskey /path/to/key.pem
```
```bash
buildctl \
--addr tcp://example.com:1234 \
--tlscacert /path/to/ca.pem \
--tlscert /path/to/clientcert.pem \
--tlskey /path/to/clientkey.pem \
build ...
```
### Load balancing
`buildctl build` can be called against randomly load balanced the `buildkitd` daemon.
See also [Consistent hashing](#consistenthashing) for client-side load balancing.
## Containerizing BuildKit
BuildKit can also be used by running the `buildkitd` daemon inside a Docker container and accessing it remotely.
We provide the container images as [`moby/buildkit`](https://hub.docker.com/r/moby/buildkit/tags/):
- `moby/buildkit:latest`: built from the latest regular [release](https://github.com/moby/buildkit/releases)
- `moby/buildkit:rootless`: same as `latest` but runs as an unprivileged user, see [`docs/rootless.md`](docs/rootless.md)
@ -295,11 +394,17 @@ We provide `buildkitd` container images as [`moby/buildkit`](https://hub.docker.
To run daemon in a container:
```bash
docker run -d --privileged -p 1234:1234 moby/buildkit:latest --addr tcp://0.0.0.0:1234
export BUILDKIT_HOST=tcp://0.0.0.0:1234
docker run -d --name buildkitd --privileged moby/buildkit:latest
export BUILDKIT_HOST=docker-container://buildkitd
buildctl build --help
```
### Kubernetes
For Kubernetes deployments, see [`examples/kubernetes`](./examples/kubernetes).
### Daemonless
To run client and an ephemeral daemon in a single container ("daemonless mode"):
```bash
@ -335,21 +440,7 @@ docker run \
--local dockerfile=/tmp/work
```
The images can be also built locally using `./hack/dockerfiles/test.Dockerfile` (or `./hack/dockerfiles/test.buildkit.Dockerfile` if you already have BuildKit). Run `make images` to build the images as `moby/buildkit:local` and `moby/buildkit:local-rootless`.
#### Connection helpers
If you are running `moby/buildkit:master` or `moby/buildkit:master-rootless` as a Docker/Kubernetes container, you can use special `BUILDKIT_HOST` URL for connecting to the BuildKit daemon in the container:
```bash
export BUILDKIT_HOST=docker-container://<container>
```
```bash
export BUILDKIT_HOST=kube-pod://<pod>
```
### Opentracing support
## Opentracing support
BuildKit supports opentracing for buildkitd gRPC API and buildctl commands. To capture the trace to [Jaeger](https://github.com/jaegertracing/jaeger), set `JAEGER_TRACE` environment variable to the collection address.
@ -360,14 +451,15 @@ export JAEGER_TRACE=0.0.0.0:6831
# any buildctl command should be traced to http://127.0.0.1:16686/
```
### Supported runc version
During development, BuildKit is tested with the version of runc that is being used by the containerd repository. Please refer to [runc.md](https://github.com/containerd/containerd/blob/v1.2.1/RUNC.md) for more information.
### Running BuildKit without root privileges
## Running BuildKit without root privileges
Please refer to [`docs/rootless.md`](docs/rootless.md).
### Contributing
## Building multi-platform images
See [`docker buildx` documentation](https://github.com/docker/buildx#building-multi-platform-images)
## Contributing
Want to contribute to BuildKit? Awesome! You can find information about contributing to this project in the [CONTRIBUTING.md](/.github/CONTRIBUTING.md)

2
vendor/github.com/moby/buildkit/go.mod generated vendored
View File

@ -9,7 +9,7 @@ require (
github.com/codahale/hdrhistogram v0.0.0-20160425231609-f8ad88b59a58 // indirect
github.com/containerd/cgroups v0.0.0-20190717030353-c4b9ac5c7601 // indirect
github.com/containerd/console v0.0.0-20181022165439-0650fd9eeb50
github.com/containerd/containerd v1.3.0
github.com/containerd/containerd v1.4.0-0.20191014053712-acdcf13d5eaf
github.com/containerd/continuity v0.0.0-20190827140505-75bee3e2ccb6
github.com/containerd/fifo v0.0.0-20190816180239-bda0ff6ed73c // indirect
github.com/containerd/go-cni v0.0.0-20190813230227-49fbd9b210f3