It is quite confusing that from the host or another container that
binds `/containers` you cannot see the bind mounts, you have to enter
the container namespace. I think `rshared` is a better default. You
can always be explicit and add `private` if you want a private bind mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds a namespace field to override the LinuxKit containerd
default namespace, in case you want to run a container in another
namespace.
Needs a patch in LinuxKit to implement this that I will open soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Annotations do not do anything by default but get passed through to the runtime,
which can be useful. I never metadata I didn't like...
Also fix sysctl to be a map in the validation, not an array. I can't see any
examples using this in LinuxKit, but this matches OCI so is correct.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This prepends 'ucode.cpio' to the initrd if present. Padding
should not be necessary as the ucode.cpio should be padded
to the right size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
For now the backends for the different formats do not yet
use the extracted ucode cpio archive, but '// TODO' are
placed for the backends which should eventually handle it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This extends the kernel filter to also look for the CPU microcode
file if specified in the YAML. If found, the ucode cpio archive
is placed into the intermediate tar file as '/boot/ucode.cpio'.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This optional option will allow users to specify a CPU
microcode cpio archive to be prepended to the initrd file.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
User specified mounts should be able to rely on the rootfs being mounted, in
particular for a writeable container they should expect the writeable overlay
to already be in place.
Signed-off-by: Ian Campbell <ijc@docker.com>
This was introduced by #191 but somehow did not trigger either for me in local
testing or in CI.
It did trigger in initial CI of https://github.com/linuxkit/linuxkit/pull/2811
which can be seen at https://linuxkit.datakit.ci/linuxkit/linuxkit/pr/2811?history=1637690296123e9a15307b3a41b290da6e27e7cc
The error is:
Failed to docker rm container «...»: «...»: aufs: unmount error after retries: «...»: device or resource busy
No doubt because we were still holding an open fd while trying to remove the
container.
Unclear why this didn't repro for me (docker 17.11.0-ce with overlay2) or
whatever CI uses.
Signed-off-by: Ian Campbell <ijc@docker.com>
Since that bumps to gogo protobuf v0.5 too do the same.
Note that there are no actual containerd changes here, although there are some
gogo proto ones.
Signed-off-by: Ian Campbell <ijc@docker.com>
Rather than queueing up into a `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) compared with the previous patch from 2.8G to 110M. The
tar output case goes from 2.1G to 110M also. Overall allocations are ~715M in
both cases.
Signed-off-by: Ian Campbell <ijc@docker.com>
All of the `output*` functions took a `[]byte` and immediately wrapped it in a
`bytes.Buffer` to produce an `io.Reader`. Make them take an `io.Reader` instead
and satisfy this further up the call chain by directing `moby.Build` to output
to a temp file instead of another `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) from 6.7G to 2.8G and overall allocations from 9.7G to
5.3G. When building a tar (output to /dev/null) the Maximum RSS fell slightly
from 2.2G to 2.1G. Overall allocations remained stable at around 5.3G.
Signed-off-by: Ian Campbell <ijc@docker.com>
Following https://golang.org/pkg/runtime/pprof/. When attempting to build
images in https://github.com/linuxkit/kubernetes CI the process is mysteriously
being SIGKILL'd, which I think might be down to OOMing due to the resource
limits placed on the build container.
I haven't done so yet but I'm intending to use these options to investigate and
they seem potentially useful in any case, even if this turns out to be a
red-herring.
Signed-off-by: Ian Campbell <ijc@docker.com>
The syntax used for the yaml definitions is changed by the need to include the
substruct in the struct literal.
For the label switch to `ImageConfig` directly, which is actually more correct
in that it avoids spurious `name` and `image` fields in the label.
Signed-off-by: Ian Campbell <ijc@docker.com>
Where "config-related" here means "ones you might find in the
"org.mobyproject.config" label on an image.
By making this new struct an anonymous member of the existing Image struct the
Go json parser does the right thing (i.e. inlines into the parent) when parsing
a complete image (from a yml assembly) by default. The Go yaml library which we
use requires a tag on the anonymous field to achieve the same.
Signed-off-by: Ian Campbell <ijc@docker.com>
