An open and reliable container runtime https://github.com/containerd/containerd
Find a file
Michael Crosby efed5a918e Talk about SD and scheduling
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
2016-11-02 15:05:07 -07:00
api Merge container.protos 2016-09-22 11:29:20 -07:00
containerd Add supervisor config 2016-09-20 15:30:35 -07:00
containerd-shim Fix monitor with process events 2016-10-06 15:06:34 -07:00
content content: initial implementation of content store 2016-11-01 18:43:15 -07:00
ctr Fix wrong field name 2016-07-14 17:06:01 +08:00
docs Refactoring minor fix 2016-06-30 23:13:04 -04:00
epoll Rename archutils to epoll 2016-09-22 14:08:41 -07:00
example Move runtime and Mounts to container config 2016-10-28 15:51:31 -07:00
hack vendor: update grpc to v1.0.1-GA 2016-09-12 11:36:39 -07:00
integration-test Add grpc health check service 2016-09-09 13:14:47 -07:00
monitor Fix monitor with process events 2016-10-06 15:06:34 -07:00
oci Implement live restore with shim 2016-10-06 15:18:26 -07:00
osutils Move cputicks into osutils package 2016-09-20 11:20:17 -07:00
runtime Refactor epoll monitor for generic use 2016-09-22 14:03:45 -07:00
shim Move runtime and Mounts to container config 2016-10-28 15:51:31 -07:00
specs Add golint to test (#255) 2016-06-03 15:00:49 -07:00
supervisor Refactor epoll monitor for generic use 2016-09-22 14:03:45 -07:00
testutils Add golint to test (#255) 2016-06-03 15:00:49 -07:00
vendor/src vendor: update grpc to v1.0.1-GA 2016-09-12 11:36:39 -07:00
.gitignore Use interfaces for container creation 2016-10-03 15:48:39 -07:00
container.go Move runtime and Mounts to container config 2016-10-28 15:51:31 -07:00
CONTRIBUTING.md Move sign off instructions to CONTRIBUTING.md 2016-04-06 14:14:51 -07:00
Dockerfile Update runc to version cc29e3dded8e27ba8f65738f40d251c885030a28 (#267) 2016-06-15 15:08:09 -07:00
execution.go Move runtime and Mounts to container config 2016-10-28 15:51:31 -07:00
Jenkinsfile Initial jenkinsfile (#306) 2016-08-26 10:24:30 -07:00
layers.go containerkit: layer manipulator overlay poc 2016-09-26 21:43:58 -07:00
layers_test.go containerkit: layer manipulator overlay poc 2016-09-26 21:43:58 -07:00
LICENSE.code Update readme and version to 0.1.0 2016-03-21 13:01:28 -07:00
LICENSE.docs Update copyright and license 2015-12-18 00:08:16 +01:00
MAINTAINERS Add tonis and mickael as maintainers 2016-03-21 13:16:12 -07:00
Makefile Fix position of $(TESTFLAGS) in Makefile 2016-09-07 10:30:02 -07:00
mount.go containerkit: layer manipulator overlay poc 2016-09-26 21:43:58 -07:00
NOTICE Update readme and documentation for release 2015-12-16 12:15:22 -08:00
process.go Move runtime and Mounts to container config 2016-10-28 15:51:31 -07:00
README.md Talk about SD and scheduling 2016-11-02 15:05:07 -07:00
version.go containerkit: change package name of root package 2016-09-26 18:16:00 -07:00

containerkit

containerkit is a collection of components for building a fully featured container runtime, storage, and distribution layers in high level projects.

Scope and Principles

Having a clearly defined scope of a project is important for ensuring consistency and focus. These following criteria will be used when reviewing pull requests, features, and changes for the project before being accepted.

Components

containerkit is a collection of components. These components can be used independently or together. They should not have tight dependencies on each other so that they are unable to be used independently but should be designed in a way that when used together the components have a natural flow to the APIs.

An example for this design can be seen with the overlay filesystems and the container execution layer. The execution layer and overlay filesystems can be used independently but if you were to use both, they share a common Mount struct that the filesystems produce and the execution layer consumes to start a container inside a root filesystem.

Primitives

containerkit should expose primitives to solve problems instead of building high level abstractions. A common example of this is how build is implemented. Instead of having a build API in containerkit we should expose the lower level primitives that allow things like build to work. Breaking up the filesystem APIs to allow snapshots, copy functionality, and mounts allow people implementing build at the higher levels more flexibility.

Extensibility and Defaults

For the various components in containerkit there should be defined extension points where implementations can be swapped for alternatives. The best example of this is that containerkit will use runc from OCI as the default runtime in the execution layer but for other runtimes conforming to the OCI Runtime specification they can be easily added to contianerkit.

containerkit will come with a default implementation for the various components. These defaults will be chosen my the maintainers of the project and should not change unless better tech for that component comes out. Additional implementations will not be accepted into the core repository and should be developed in a separate repository not maintained by the containerkit maintainers.

Scope

The following table specifies the various components of containerkit and general features of container runtimes. The table specifies whether or not the feature/component is in or out of scope.

Name Description In/Out Reason
execution Provide an extensible execution layer for executing a container in
cow filesystem Built in functionality for overlay, aufs, and other copy on write filesystems for containers in
distribution Having the ability to push, pull, package, and sign images in
networking Providing network functionality to containers along with configuring their network namespaces in
build Building images as a first class API out Build is a higher level tooling feature and can be implemented in many different ways on top of containerkit
volumes Provide primitives for volumes and persistent storage

containerkit is scoped to a single host. It can be used to builds things like a node agent that launches containers but does not have any concepts of a distributed system.

Also things like service discovery are out of scope even though networking is in scope. containerkit should provide the primitives to create, add, remove, or manage network interfaces for a container but ip allocation, discovery, and DNS should be handled at higher layers.

Copyright © 2016 Docker, Inc. All rights reserved, except as follows. Code is released under the Apache 2.0 license. The README.md file, and files in the "docs" folder are licensed under the Creative Commons Attribution 4.0 International License under the terms and conditions set forth in the file "LICENSE.docs". You may obtain a duplicate copy of the same license, titled CC-BY-SA-4.0, at http://creativecommons.org/licenses/by/4.0/.