Skaffold: (Feature request) Support docker buildx build

Created on 15 Jul 2019  路  5Comments  路  Source: GoogleContainerTools/skaffold

We're currently using skaffold with buildkit enabled. We found a bug in buildkit (https://github.com/moby/buildkit/issues/1072#issuecomment-511468942) and they've since fixed it, but now we need to use the new version of buildkit in our infrastructure.

The recommended way of using a newer version of buildkit than the one DOCKER_BUILDKIT=1 provides is docker buildx: https://github.com/docker/buildx

We use skaffold for our builds, so in order to use buildx, we need skaffold to be able to use it as an alternative to docker build.

arebuild buildocker kinfeature-request prioritp3

Most helpful comment

@balopat @nkubala Mind reopening this? I see huge benefits from support buildx and its --cache-to feature: as opposed to plain DOCKER_BUILDKIT=1 execution, buildx can upload the cache for all parts of a multi-stage build and would therefore save lots of time (and the environment).

All 5 comments

Closing this for now as apparently you can use newer versions of Buildkit by just using the # syntax feature: https://github.com/moby/buildkit/issues/1072#issuecomment-511487993

@balopat @nkubala Mind reopening this? I see huge benefits from support buildx and its --cache-to feature: as opposed to plain DOCKER_BUILDKIT=1 execution, buildx can upload the cache for all parts of a multi-stage build and would therefore save lots of time (and the environment).

This would be great to re-open for that exact issue above - we've tested using docker buildx build using the caching and it works a treat, it would shave literally hours off of our builds and would be a massive boon to our work

So you can configure Docker so that docker build uses buildx by default with docker buildx install. If you combine that with useDockerCLI: true then you'll be using buildx.

Adding support for --cache-to is a bit more difficult. Docker labels buildx as an experimental feature that may change without notice. So I'm a bit leery about adding adding dedicated fields for builder options that may be changed, renamed, or removed聽without notice. Perhaps we should incorporate the Kaniko builder's now-removed AdditionalFlags.

I think any way we can add extensibility to the API so we can leverage these features would be great. AdditionalFlags sounds great, I understand not creating specialised fields.

Was this page helpful?
0 / 5 - 0 ratings