Open Container Initiatives (OCI)

在 Docker 於 2013 年推出時，解決了許多開發人員在使用容器化技術上遇到的問題，其中包含：

A container image format
A method for building container images (Dockerfile/docker build)
A way to manage container images (docker images, docker rm , etc.)
A way to manage instances of containers (docker ps, docker rm , etc.)
A way to share container images (docker push/pull)
A way to run containers (docker run)

當時的 Docker 是一個 monolithic 系統，將所有功能包成一大包。但事實上這些功能並沒有相依性，且可以獨立實作成一個更小、更專注的工具，再將彼此整合在一起使用，並可以各自遵循一個通用格式，也就是容器化標準。

而為了避免重複造輪子、且讓容器化技術的相關開發有規範可循，於是在 2015 年，Docker、CoreOs、Google 及一些 container 相關的企業聯手定義了 Open Container Initiatives (OCI) 這份倡議，並將各自使用在容器化技術上的 code 拆散，組合成一個全新工具 —— runC，並將其開源，作為定義 OCI Spec 的實作參考。

Open Container Initiatives 包含三個主要的規範，分別為

Runtime Specification (runtime-spec)
Image Specification (image-spec)
Distribution Specification (distribution-spec)

🥸

OCI 並沒有直接規範該如何實作一個 Container runtime，而是定義和 runtime 的溝通方式

The 5 principles of Standard Containers

Standard Container 旨在將 software component 及其所有相依性套件 (dependencies) 以一個能夠可自敘 (self-describing) 且容易傳輸 (portable) 的格式封裝，讓所有符合規範的 Container runtime 都能在不需要其他相依套件、且不用顧慮機器及 Container 內容物的情況下運行其中的程式。

Define a unit of software delivery called a Standard Container. The goal of a Standard Container is to encapsulate a software component and all its dependencies in a format that is self-describing and portable, so that any compliant runtime can run it without extra dependencies, regardless of the underlying machine and the contents of the container.

1. Standard operations

定義對於 Container 能夠進行的操作，像是 Create、Run、Stop、Kill、Delete (Container Lifecycle)

Standard Containers define a set of STANDARD OPERATIONS. They can be created, started, and stopped using standard container tools; copied and snapshotted using standard filesystem tools; and downloaded and uploaded using standard network tools.

2. Content-agnostic

無論 Container 中裝的是什麼東西，都需要以相同的方式運行這個容器

Standard Containers are CONTENT-AGNOSTIC: all standard operations have the same effect regardless of the contents. They are started in the same way whether they contain a postgres database, a php application with its dependencies and application server, or Java build artifacts.

3. Infrastructure-agnostic

無論使用任何機器或在任何地方，都能夠打包、上傳、下載、且運行這個容器

Standard Containers are INFRASTRUCTURE-AGNOSTIC: they can be run in any OCI supported infrastructure. For example, a standard container can be bundled on a laptop, uploaded to cloud storage, downloaded, run and snapshotted by a build server at a fiber hotel in Virginia, uploaded to 10 staging servers in a home-made private cloud cluster, then sent to 30 production instances across 3 public cloud regions.

4. Designed for automation

基於 Content-agnostic 及 Infrastructure-agnostic 兩項原則，讓標準化容器相當適合以自動化來完成該做的工作

Standard Containers are DESIGNED FOR AUTOMATION: because they offer the same standard operations regardless of content and infrastructure, Standard Containers, are extremely well-suited for automation. In fact, you could say automation is their secret weapon.

Many things that once required time-consuming and error-prone human effort can now be programmed. Before Standard Containers, by the time a software component ran in production, it had been individually built, configured, bundled, documented, patched, vendored, templated, tweaked and instrumented by 10 different people on 10 different computers. Builds failed, libraries conflicted, mirrors crashed, post-it notes were lost, logs were misplaced, cluster updates were half-broken. The process was slow, inefficient and cost a fortune - and was entirely different depending on the language and infrastructure provider.

5. Industrial-grade delivery

標準化容器改變了過去企業交付軟體的過程，讓這個過程管線化、全自動化

Standard Containers make INDUSTRIAL-GRADE DELIVERY of software a reality. Leveraging all of the properties listed above, Standard Containers are enabling large and small enterprises to streamline and automate their software delivery pipelines. Whether it is in-house devOps flows, or external customer-based software delivery mechanisms, Standard Containers are changing the way the community thinks about software packaging and delivery.

除了 Container 之外，Spec 同時定義了 Container configuration 及執行環境

要建立一個 Container，需要提供給 runtime filesystem bundle 及 optional folder holding the future container's root filesystem，其中 filesystem bundle 必須包含一個 config.json 檔案。

config.json contains data necessary to implement standard operations against the container (Create, Start, Query State, Kill, and Delete, the Container Lifecycle). But things start getting really interesting when it comes to the actual structure of the config.json file.

這份 configuration 包含兩個 section，common 及 platform-specific。common section 包含通用的設定，像是 ociVersion, root filesystem path within the bundle, additional mounts beyond the root, a process to start in the container, a user, and a hostname；platform-specific section 則用來設置各個平台特有的參數，像是 Linux, Solaris, Windows, z/OS, 及 Virtual Machine。而熟知的 cgroups 及 namespace 的設置則被包含在 Linux-specific section 之中。

顯示只有 Linux 的 Container 需要依賴 namespace 及 cgroups 來實作，但不是所有標準化容器都是 Linux based

Open Container Initiatives 如何定義一個 Container

在 Open Container Initiatives (OCI) Spec 中提到：「container 是一個用來執行程序的環境，且此環境的獨立性及可取用資源可以經由調控加以限制。」

An environment for executing processes with configurable isolation and resource limitations. For example, namespaces, resource limits, and mounts are all part of the container environment. -- OCI Spec#container

在 runtime & Lifecycle Spec 中提到，任何使用合規 Container runtime 來建立的 Container 必須能夠使用 Spec 中定義的所有 Container Lifecycle method。

Virtual Machines are actually containers?!

VM Container 的方式和我們認知的 Linux Container 略為不同。他先虛擬畫出 VM 需要的硬體設備，接著在這個硬體上開啟完整的 OS (kernel + image)，最終組成 VM Container 的大箱子。