These are easier to create than cgroupv1 cgroups as they are only a
single mkdir.
Detect which mode we are in by looking for the presence of the
cgroupv2-only cgroup.controllers file.
Signed-off-by: David Scott <dave@recoil.org>
- use the mkimage hashes that we had in LinuxKit as more up to date than tool.
- update docs
- move the code from moby under src/cmd/linuxkit
Signed-off-by: Justin Cormack <justin@specialbusservice.com>
This is similar to ae64ab6b82 from #2849 which
did the same for runtime.mkdir.
This makes it possible to specify both host (absolute) or container (relative)
paths.
Signed-off-by: Ian Campbell <ijc@docker.com>
Implements https://github.com/moby/tool/pull/181
Design for things like Kubernetes setup that requires some cgroups to
exist when the service starts but it is not running in these, other
services are, so there would be a race if they are not created in each.
Essentially it is just a sugared `mkdir` in all the cgroup dirs.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes all the code that had knowledge of how to do read only
and read write container mounts, and just uses the runtime config.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This could be used in LinuxKit now, as there are some examples, eg
https://github.com/linuxkit/linuxkit/blob/master/blueprints/docker-for-mac/base.yml#L33
which are creating containers to do a mount.
The main reason though is to in future change the ad hoc code that generates
overlay mounts for writeable containers with a runtime config which does
the same thing; this code needs to create both tmpfs and overlay mounts.
See https://github.com/moby/tool/pull/145
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds support for a runtime configuration file that can do:
- `mkdir` to make a directory at runtime, eg in `/var` or `/tmp`, to avoid workarounds
- `interface` that can create network interfaces in a container or move them
- `bindNS` that can bind mount namespaces of an `onboot` container to a file so a service can be started in that namespace.
It merges the `service` and `onboot` tools (in `init`) to avoid duplication. This also saves some size for
eg LCOW which did not use the `onboot` code in `runc`.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
