The git repo of github.com/containerd/stargz-snapshotter now has two go.mod modules:
- github.com/containerd/stargz-snapshotter
- github.com/containerd/stargz-snapshotter/estargz
So we need to have the following `replace` directive in `go.mod`:
```
github.com/containerd/stargz-snapshotter/estargz => github.com/containerd/stargz-snapshotter/estargz <VERSION>
```
Otherwise `go mod tidy` fails with the following error:
```
go: github.com/containerd/stargz-snapshotter@v0.2.1-0.20201217071531-2b97b583765b requires
github.com/containerd/stargz-snapshotter/estargz@v0.0.0-00010101000000-000000000000: invalid version: unknown revision 000000000000
```
ref: https://github.com/containerd/stargz-snapshotter/pull/195
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This is a workaround for
https://github.com/golang/go/issues/35305
which makes it possible to successfully push to a local registry
using
$ docker buildx build --push --tag localhost:5000/foo .
assuming, of course, that the builder instance currently in use
has been created using
$ docker buildx create --driver-opt network=host
The workaround is no longer going to be necessary once Go 1.16
is used for builds.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
QEMU usermode emulation is robust enough for running `apk add --no-cache
git xz`, so can we can safely remove the pre-built git stage.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Currently moby/buildkit image misses fuse dependency (fusermount) so currently
stargz support doesn't work on that image. This commit fixes this issue.
Signed-off-by: ktock <ktokunaga.mail@gmail.com>
Current stargz snapshotter pkg doesn't contain registry configuration and the
client of that pkg needs to pass it to that pkg. So this commit includes changes
of propagating buildkitd's registry configuration to stargz snapshotter.
But this is a partial integration of registry logic between buildkitd and stargz
snapshotter because buildkitd's session-based authentication logic is still not
applied to stargz snapshotter. This means private images that require
`~/.docker/config.json` creds can't be lazily pulled yet.
Signed-off-by: ktock <ktokunaga.mail@gmail.com>
This is the shim used by the containerd Runtime V1 on Linux,
which was the default under containerd 1.2 and earlier.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This is the shim used by the containerd Runtime V2 on Linux, per the
default setting of `io.containerd.runc.v2`.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
* Existing releases v0.3.0...v0.7.1 use newuidmap dynamically linked with musl
* #1405 attempted to link newuidmap statically with glibc, but it was actually dynamically linked by accident and was never used as the external base.
Switching from musl (Alpine) to glibc (Debian) is just because we don't have `cross.sh` for Alpine.
We could fix the script to link the binary statically, but statically linked binary doesn't work on Alpine because of "Cannot determine your user name." error.
* This commit reverts #1405 for newuidmap, and build the stage with `--platform=$TARGETPLATFORM`.
In future we should port over `cross.sh` to Alpine and use `--platform=$BUILDPLATFORM`.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
By default, Ubuntu or Debian based "apt" or "apt-get" system installs recommended but not suggested packages .
By passing "--no-install-recommends" option, the user lets apt-get know not to consider recommended packages as a dependency to install.
This results in smaller downloads and installation of packages .
Refer to blog at [Ubuntu Blog](https://ubuntu.com/blog/we-reduced-our-docker-images-by-60-with-no-install-recommends) .
Signed-off-by: Pratik Raj <rajpratik71@gmail.com>
While real overlayfs is available only in Ubuntu and Debian kernels,
fuse-overlayfs is universally available for kernel >= 4.18.
For dockerized deployment, `--device /dev/fuse` needs to be added to
`docker run` flags.
Kubernetes deployment needs a custom device plugin that enables
`/dev/fuse`, e.g. https://github.com/honkiko/k8s-hostdev-plugin
Instead of a device plugin, the device can be also enabled by setting
`securityContext.privileged` to `true`.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>