Dependencies/layers?

[derekchiang]

As of right now, it doesn't appear that the spec contains any notion of dependencies/layers; that is, something akin to the base image (FROM) in Docker, or dependencies in ACI. Is this something that will be added to the spec eventually?

[crosbymichael]

@derekchiang Not really. In this initial spec we are only dealing with a single container so specifying dependencies are out of scope at this point.

[vbatts]

@derekchiang presently we are starting with the foundation of runtime. As the project moves forward the notion of dependencies and layering will be covered. There are logical dependencies needed to build on, like hashing and standard layering. Where as the current runtime (runc) needs only the rootfs that it is running at, and the run configuration. So distribution and layering of images is orthogonal to this.

[wking]

On Wed, Jul 22, 2015 at 10:48:29AM -0700, Vincent Batts wrote:

As the project moves forward the notion of dependencies and layering
will be covered… So distribution and layering of images is
orthogonal to this.

Can we keep distribution and layering in higher-level probjects, and
not push them into these specs? As it stands, runc is a great fit for
images distributed via a single tarball (or via IPFS, etc., etc.)
because it doesn't use Docker's layer approach. I'd rather not have
to worry about the complexity of layers if I don't have to, and
keeping that stuff in a separate, higher-level project would make it
easy for me to ignore it while also making it easy for folks to use
that additional functionality if they want it.

[vbatts]

@wking correct. That's what I meant by it being orthogonal. If the rootfs of the runtime is a layered or whatever, that ought not matter for this runtime.

Were we to have any specifications around "supported layering", that would be outside of the runtime specification.

[stuartpb]

👍 to keeping layers out of this spec, though it'd be great for somebody to make a project capable of instantiating layers from Docker. Can anybody point me to some documentation around how Docker save its layers? (I'd like to keep Docker around as, essentially, a package manager for downloading images for use with runc + some layering tool.)

Alternately, is there a package manager that just downloads layers from the Docker repository (to, say, a given object store) and saves a basic manifest of what layers make up what images? How difficult would it be to create such a tool?

And what solutions does Docker implement for layering? Is there a liblayer component abstracting it akin to how libcontainer abstracts away KVM?

[stuartpb]

Also, looking at the sample JSON in https://github.com/opencontainers/runc, wouldn't it be possible to do this with a series of aufs mount rules in the container configuration?

[wking]

On Fri, Aug 14, 2015 at 09:39:24AM -0700, Stuart P. Bentley wrote:

Alternately, is there a package manager that just downloads layers
from the Docker repository and saves a basic manifest of what layers
make up what images?

The v2 registry does this with the manifest's fsLayers 1, and you
can pull the referenced layers independently 2.

[wking]

On Fri, Aug 14, 2015 at 09:55:54AM -0700, Stuart P. Bentley wrote:

Also, looking at the sample JSON in
https://github.com/opencontainers/runc, wouldn't it be possible to
do this with a series of aufs mount rules in the container
configuration?

Yeah, you can probably write a tool to translate the Docker manifest
and set of fetched files into a runC config. I think Docker does
something like this internally, but it's using the libcontainer
interface and not shelling out to runC (as far as I know), so it may
not have code that spits out the config file directly.

[stuartpb]

But, like, Docker works on systems that don't support AUFS mounts, right? So there should be something container users can point to, in the best practices, that explains how you can do things like layering in all the ways Docker does it.

[stuartpb]

Also, per the discussion above, is it fair to say that the best practice for containers is to do your layering outside of the container's JSON config manifest, listing only the root and system-internal mounts (like cgroups) in the manifest?

Moreover, where should the line be drawn between mounts handled by the host environment and mounts handled by the manifest? How much are manifests meant to be portable?

[wking]

On Fri, Aug 14, 2015 at 03:21:29PM -0700, Stuart P. Bentley wrote:

Also, per the discussion above, is it fair to say that the best
practice for containers is to do your layering outside of the
container's manifest, listing only the root and system-internal
mounts (like cgroups) in the manifest?

Doing a bit of layering inside your container can help with things
like restricting read/write access. For example, see my read-only
rootfs 1 with a read/write /root workspace 2. But I agree that
you'll probably want to flatten Docker layers ahead of time in many
cases to get a more efficient OCI bundle.

Moreover, where should the line be drawn between mounts handled by
the host environment and mounts handled by the manifest? How much
are manifests meant to be portable?

This sounds like #88 (see 3).

[vbatts]

I would there to be general practices available around layering, but for now the OCI is expecting of a rootfs. The setup that provides that rootfs may utilize layering (e.g. docker).
There is some breakage in the concepts of a distributable OCI bundle and that of docker images though, and it will be up to docker to reconcile that while maintaining OCI support and providing their layering.

There may be a form of asserting the representation of a rootfs, so that we differentiate from how that rootfs was distributed. That way docker layering can produce a validatable rootfs with layering, or an exported tarball of that flattened rootfs. Same representation, vastly different arrivals.

The appc/spec has a semantic for dependencies. See
https://github.com/appc/spec/blob/master/spec/aci.md#image-manifest
which gives a fully qualified name to find/derive the additional pieces of the image.
I like that this does not dictate a lot of the "how" but allows application containers a semantic to express that they "can" be a collection. And lets these decentralized components be individually validated.
Though this is still lacking the algorithms of how the components are properly layered (e.g. whiteouts / file removals).