The Technical Oversight Board (TOB) for the Open Container Initiative (OCI) today announced it has approved a new Artifacts project that will extend the reach of a single repository to encompass multiple artifacts such as Kubernetes deployment files, Helm Charts and other evolving formats alongside containers.
Cloud Native Computing Foundation (CNCF) CTO Chris Aniszczyk, who oversees OCI development efforts, says this approach will reduce much of the operational overhead associated with managing different classes of artifacts in containerized environments. Going forward, the TOB will evaluate and approve what classes of artifacts will be included under the OCI distribution spec.
The OCI distribution spec was originally submitted to the TOB for OCI by Docker Inc. to provide a vendor-neutral, cloud-agnostic spec to share, secure and deploy container images. Using the OCI manifest and OCI index definitions, new artifact types can be stored and served using the OCI distribution spec without changing the actual distribution spec.
By streamlining the process through which multiple types of artifacts are stored and shared, DevOps processes within containerized application environments become easier to manage. Whenever any continuous integration/continuous deployment (CI/CD) platform builds and deploys a container image, that image invariably gets pushed to a registry. When a container host such as Kubernetes is requested to run an image, scale a pod or replace a failed node, it pulls the image from a registry. As such, registries are now a critical element of any DevOps workflow, notes Aniszczyk.
Going forward, the TOB plans to employ the OCI Artifact repository to provide artifact owners with additional information about how to author types. Registry operators also will be provided with a means to discover well-known artifact types to provide a better browsing, securing and deployment experience across all artifact types.
For all the success containers have had, there are many developers who still shy away from them because they still are perceived as cumbersome to build and manage. By enabling a single repository to house multiple registries, the OCI is taking another step toward eliminating complexity. For every developer who has embraced containers, there are at least six that have not. The challenge the OCI faces now is making containers less intimidating to the average developer.
In the meantime, as OCI continues to exercise more influence over container standards, there’s a subtle shift in the nomenclature occurring. Rather than referring to Docker containers, more vendors are starting to refer to either OCI-compatible containers or the Kubernetes Container Runtime Interface (CRI) to enable using OCI-compatible runtimes, otherwise known at CRI-O. A CRI-O compatible container runs natively on Kubernetes to eliminate the need to recompile Docker containers.
It may take a while for the container community to fully explain the relationship between all these container formats to the average enterprise IT team. However, there soon will be a wide variety of containers running in enterprise IT environments.