a5c9d6d41b
This is a first pass at the metadata required for supporting an image store. We use a shallow approach to the problem, allowing this component to centralize the naming. Resources for this image can then be "snowballed" in for actual implementations. This is better understood through example. Let's take pull. One could register the name "docker.io/stevvooe/foo" as pointing at a particular digest. When instructed to pull or fetch, the system will notice that no components of that image are present locally. It can then recursively resolve the resources for that image and fetch them into the content store. Next time the instruction is issued, the content will be present so no action will be taken. Another example is preparing the rootfs. The requirements for a rootfs can be resolved from a name. These "diff ids" will then be compared with what is available in the snapshot manager. Any parts of the rootfs, such as a layer, that isn't available in the snapshotter can be unpacked. Once this process is satisified, the image will be runnable as a container. Signed-off-by: Stephen J Day <stephen.day@docker.com> |
||
|---|---|---|
| .. | ||
| content | ||
| execution | ||
| images | ||
| rootfs | ||
| shim | ||