3. Docker Meetup Next Month
• We need someone to organize the meeting for February 21st
• Otherwise we will not have a meeting
• InfoSiftr Team will be at the Container World Conference, February
21st through the 23rd at the Santa Clara Convention Center
• We will send out email invites with Discount Codes
4.
5. Las Vegas Docker Meetup Group is Now
300 Plus Members and Growing!
20. containerd Roadmap - Phase 1
• GRPC API
• Documents:
• We are going from a top down design for filling out this missing pieces of containerd and
design of the API.
• Design
• Documents:
• The high level design work is needed so that the architecture of containerd stays consistent
throughout the development process.
• Build & Test Process
• Documents:
• We need to have a simple build and test process for new developers to bootstrap their
environments. Because containerd will be the base of many high level systems we need to
have a simple build process that does not require high level tooling.
• Status: In Progress
21. containerd Roadmap - Phase 2
Phase 2 includes most of the design and development work for the execution and storage
layers of containerd. It will include porting over existing "graph drivers" from Docker Engine
and finding a common model for representing snapshots for layered filesystems.
This will also include moving the existing execution code support OCI's Runtime Spec and
the existing containerd execution code.
• Runtime
• The runtime layer is responsible for the creation of containers and their management, and
supervision of the processes inside those containers.
• Storage
• Documents: https://github.com/docker/containerd/blob/master/design/snapshots.md
• The current graph drivers were built when we only had overlay filesystems like aufs. We forced the model to be
designed around overlay filesystems and this introduced a lot of complexity for snapshotting graph drivers like
btrfs and devicemapper thin-p. Our current approach is to model our storage layer after snapshotting drivers
instead of overlay drivers as we can get the same results and its cleaner and more robust to have an overlay
filesytem model snapshots than it is to have a snapshot filesystem model overlay filesystems.
• Status: In Design
22. containerd Roadmap - Phase 3
This phase includes getting support for the OCI Image spec built into
containerd.
• Status: Not Started
23. containerd Roadmap - Phase 4
Phase 4 involves graduating to version 1.0, and shifting the focus from
features to maintenance. Graduating to 1.0 implies:
• Completing all of the above phases.
• Covering the functionalities required by a majority of container-centric
platforms.
• Offering feature parity, to the extent of technical possibilities, across Linux
and Windows.
• Demonstrating that containerd fulfills the requirements of at least one higher-
level platforms through its complete integration as an upstream.
• Status: Not Started
24. Top questions Docker, Inc. received
following this announcement
Q. Are you planning to run docker without runC ?
• A. Although runC is the default runtime, as of Docker 1.12, it can be
replaced by any other OCI-compliant implementation. Docker will be
compliant with the OCI Runtime Specification
Q. What major changes are on the roadmap for swarmkit to run on
containerd if any?
• A. SwarmKit is using Docker Engine to orchestrate tasks, and Docker
Engine is already using containerd for container execution. So
technically, you are already using containerd when using SwarmKit.
There is no plan currently to have SwarmKit directly orchestrate
containerd containers though.
25. Top questions Docker, Inc. received
following this announcement….
Q. Mind sharing why you went with GRPC for the API?
• A. containerd is a component designed to be embedded in a higher level system,
and serve a host local API over a socket. GRPC enables us to focus on designing
RPC calls and data structures instead of having to deal with JSON serialization and
HTTP error codes. This improves iteration speed when designing the API and data
structures. For higher level systems that embed containerd, such as Docker or
Kubernetes, a JSON/HTTP API makes more sense, allowing easier integration. The
Docker API will not change, and will continue to be based on JSON/HTTP.
Q. How do you expect to see others leverage containerd outside of Docker?
• A. Cloud managed container services such as Amazon ECS, Microsoft ACS, Google
Container Engine, or orchestration tools such as Kubernetes or Mesos can
leverage containerd as their core container runtime. containerd has been
designed to be embedded for that purpose.
26. Top questions Docker, Inc. received
following this announcement….
Q. How did you decided which feature should get into containerd? How
did you came up with the scope of the future containers?
• A. We’re trying to capture in containerd the features that any container-
centric platform would need, and for which there’s reasonable consensus
on the way it should be implemented. Aspects which are either not widely
agreed on or that can trivially be built one layer up were left out.
Q. How integrate with CNI and CNM?
• A. Phase 3 of the containerd roadmap involves porting the network drivers
from libnetwork and finding a good middle ground between the CNM
abstraction of libnetwork and the CNI spec.
27. Links to containerd Project
and Other Information
containerd Livestream Recap
• https://blog.docker.com/2017/01/containerd-livestream-recap/
containerd web page
• https://containerd.io
GitHub containerd Page
• https://github.com/docker/containerd
containerd Roadmap
• https://github.com/docker/containerd/blob/master/ROADMAP.md
Slack Channel for containerd
• https://community.docker.com/registrations/groups/4316
28. Q&A and Open Discussion
• Questions about containerd
• Questions about your Docker/container projects
• Findings and Tips for the Group
• General Open Discussion about the ecosystem