This will add a Dockerfile which will build the contents into an
image and then call `tinit` to start it.
This is fairly experimental, but is a prototype for other non
LinuxKit outputs. The container will need to run as `privileged`
as `runc` needs quite a few capabilities and `containerd` needs to
mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This can be turned on if required but we'll default to leaving it off
It's been enabled in the top-level linuxkit.yml
This port is also non-standard and there doesn't appear to be a standard
port for this as yet.
Signed-off-by: Dave Tucker <dt@docker.com>
- generally people refer to a plain disk image as `raw`
- `gcp` is shorter and it is the only image type supported
- remove `img-gz` as it is not needed. It does not really save space
as you have to build the full image and compress it anyway. On
many platforms the `raw` image will be a sparse file anyway,
even on the Mac soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- Prefix platform documentation with 'platform-'
- Add/Correct links from top-level README.md
- Tweak the Azure documentation
- Move the vsudd README to platform-hyperkit.md
- Add a dummy document for qemu/kvm
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Note that this is not the latest (which was 95efd45db073 at time of writing)
but the next commit 6428b4bad0c2 merges "Port ctr to use client package" breaks
the use of `ctr run --runtime-config` (by removing that option).
This contains https://github.com/containerd/containerd/pull/954 which was
causing some services to fail to start.
All previous uses of 15541037b9 are updated to
5749f2e9e6.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This is a little ugly in terms of the validation now, but it is a move towards
splitting "build" and "package".
The "tar" output (and soon others) can output direct to a file or to stdout.
Obviously you can only build a single output format like this.
The LinuxKit output formats that build disk images cannot stream as they
have to build whole images. These allow multiple outputs.
In future we will probably change to
```
moby build | moby package
```
or similar, but that is a bit ugly, so currently have a compromise where
there are essentially two output types.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This makes it easier to identify where a new backend should be added.
It's also simpler to match help text and case statements.
Signed-off-by: Dave Tucker <dt@docker.com>
The intention with the yaml fragment is that it specifies the
set of processes that form the daemon, with minimal privileges
for each component and each running inside a separate container.
In addition to the normal container capabilities, there is also
a new field which lets a startup process establish an RPC channel,
based on a Capnp specification. This allows for extremely
unprivileged components to be started, such as the `dhcp-engine`
in this example which can only communicate with the outside world
via the `dhcp-network` (to transmit) or `dhcp-actuator` (to alter
the state of the local Linux distribution).
This is a first cut at the yaml interface and the capnp, with the
intention to refine it as we combine it with the rest of the existing
prototype (which currently doesnt have an RPC layer). Expect
more changes...
Signed-off-by: Anil Madhavapeddy <anil@docker.com>
