The mission of the Open Container Initiative (OCI) is to promote a set of common, minimal, open standards and specifications around container technology.
The mission of the OCI is intentionally limited in scope; in particular please take a look at the OCI Scope Table in the charter for more information. We are not trying to define a large stack, become a big marketing organization or throw large conferences. We are focused on the container image format and runtime, areas where stability and standardization are more important, so that we can allow innovation to happen around us. To use an analogy, we are agreeing on the width of the train tracks, so we can all go off individually and try to build the fastest engines.
In the past few years, there has been rapid growth in both interest in and usage of container-based solutions. Almost all major IT vendors and cloud providers have announced container-based solutions, and there has been a proliferation of start-ups founded in this area as well. While the proliferation of ideas in this space is welcome, the promise of containers as a source of application portability requires the establishment of certain standards around format and runtime. While the rapid growth of the Docker project has served to make the Docker image format a de facto standard for many purposes, there is widespread interest in a single, open container specification, which is:
Users can fully commit to container technologies today without worrying that their current choice of any particular infrastructure, cloud provider, devops tool, etc. will lock them into any technology vendor for the long run. Instead, their choices can be guided by choosing the best tools to build the best applications they can. Equally important, they will benefit by having the industry focus on innovating and competing at the levels that truly make a difference. To use an analogy, why argue about the width of train tracks, when you can worry about laying track and building the best possible engines? Ultimately, we want to make sure that the original promise of containerization—portability, interoperability, and agility—aren’t lost as we move to a world of applications built from multiple containers run using a diverse set of tools across a diverse set of infrastructures.
The individuals behind the appc effort have joined the technical leadership of the OCI, and our intention is to work towards both a common format that is compatible with existing container formats as well as to work on a future spec that combines the best elements of all the existing container efforts.
You will note that a lot of these are directly adopted from the appc founding values. We want to make sure that this effort combines the best ideas from all existing efforts in this space.
Docker has donated both a draft specification for the base format and runtime and the code associated with a reference implementation of that specification, to the OCI. Docker has taken the entire contents of the libcontainer project, including nsinit, and all modifications needed to make it run independently of Docker, and donated it to this effort. This codebase, called runc, can be found at https://github.com/opencontainers/runc
Docker initially seeded runc to help form the OCI build the runtime specification. Recently, Docker announced that it is spinning out its core container runtime functionality into a standalone component, incorporating it into a separate project called containerd, and will be donating it to a neutral foundation early next year. Furthermore, containerd will include full OCI support, including the extended OCI image specification.
Details on specific contributions to the project are available here: https://oci.biterg.io/. See also OCI Member Spotlights posted to the OCI blog, which includes Q&A with individual members.
First off, the TOB is responsible for managing conflicts, violations of procedures or guidelines and any cross-project or high-level issues that cannot be resolved in the TDC for OCI Projects. Furthermore, the the technical leadership depends on the OCI project, which is who is listed in a MAINTAINERS file across OCI projects:
For a history of OCI project creation, you can view project proposals in the TOB README.
You can follow the TOB on GitHub (https://github.com/opencontainers/tob) and their respective mailing list, but their responsibilities are:
Traditional standards groups are generally architect-driven and usually code comes after the specifications are defined. Standards are built first, and then all products must adhere to those standards. The OCI seeks rough consensus and running code first. The OCI projects are being developed by the community, and independent implementations of tools are encouraged to ensure that the same container can be run consistently. The goal is to have multiple implementations and do thorough testing while the specification evolves over time.
A standard needs to live in a neutral place and is typically developed according to a specified set of rules and procedures providing consensus among many parties. Standards are often used as a reference design. Specifications are generally works in progress, often developed by one entity which may use content from one or more standards and may alter said content to meet different needs. Specifications are usually specific to one scenario and can cover multiple areas and topics, whereas a standard is typically more general and usually narrow in focus. Specifications can also include non-standard materials and can be easily revised. As we created the OCI, we wanted to be sure to have a trailing specification with leading implementations and to make things as lightweight as possible. The OCI is run more like a traditional open source project than a standards body, with a focus on running code through consensus. The OCI is providing a form and canvas for organizations to settle on rules for a variety of specs.
The OCI has purposefully been limited in scope, see the OCI Scope Table for more information. In the future, the scope may slightly expand to discuss other items related to containers.
The v1.0.0 release came out on 7/19/17. There are specific details in the RELEASES file in how releases are managed. For example, major specification releases must release at least three release candidates spaced a minimum of one week apart. This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself. Minor and patch releases will be made on an as-needed basis.
The OCI Certification Program is a work in progress and being built by the Certification Working Group within the OCI. The goal is the program is to build a certification process that allows OCI specification implementations to support a vendor-neutral process and requirements, including specifically, the ability for solutions to be certified on multiple operating systems and usable in multiple environment implementations.
Basically any popular technology that runs a container has been on its way to adopting OCI technology as we have been evolving the specifications. For example, the Cloud Foundry community has been an early consumer of OCI by embedding runc via Garden as the cornerstone of its container runtime technology. The Kubernetes project is incubating a new Container Runtime Interface (CRI) that adopts OCI components via implementations like CRI-O and rklet. The rkt community is adopting OCI technology already and is planning to leverage the reference OCI container runtime runc in 2017. The Apache Mesos community is currently building out support for the OCI image specification. Also, AWS announced that is supporting the OCI image format in its Amazon EC2 Container Registry (ECR).
Any container that runs in these environments is taking advantage of OCI efforts.
Yes. For example, take a look at the runtime-specification configuration where it mentions example Linux, Windows and Solaris configurations. There are also multiple implementations of the runtime-specification that you can take a look at.
A container runtime is just one component of the cloud native technical architecture but the container runtime itself is out of initial scope of CNCF (as a CNCF project), see the charter Schedule A for more information. A more detailed view of the landscape can be viewed in the Cloud Native Landscape by CNCF, in particular the “container runtime” section: https://github.com/cncf/landscape
How do I join the OCI as an official member? It’s very simple, first read the charter for more information and then find the right membership level for you based on company size. Email info@opencontainers.org for more information.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。