Container Technology: Container Image
Created#More Posted time:Jul 21, 2021 15:41 PM
The Concept of Container Image
The container image is officially analogized as a common container in an environment. With different specifications, the container itself is immutable with different contents.
For images, the immutable parts include all the elements required to run an application, such as MySQL. Developers can use some tools, such as Dockerfile, to build container images and upload them to the Internet after signing. Then, people that need to run the software can specify names, such as _example.com/my-app_, to download, verify, and run these container images.
Container Initiative (OCI) Image Format Specification
Before the OCI Image Format project, there were two sets of widely used image format specifications, AppC and Docker 2.2. However, these two specifications have gradually assimilated with each other in their respective development. So, the OCI organization launched OCI Image Format Spec (based on Docker 2.2), specifying images that meet the specification. By doing so, developers can run a container on all container engines with the container packaged and only signed once.
This specification defines an OCI image:
This specification defines an OCI Image, consisting of a manifest,
an image index (optional), a set of filesystem layers, and a configuration.
A typical container workflow starts with the developers creating a container image (BUILD in the figure), uploading it to the image storage center (SHIP in the figure), and finally, deploying it in a cluster (RUN in the figure).
Problems in the Development of Container Image Technology
The design of the container image is very brilliant. First of all, it contains the excellent idea of a complete operating system is a package, which takes everyone outside the box of the installation packages. Also, it proposed killer features that improves the developer experience, such as Dockerfile, and can use a hierarchical structure to save time and space.
However, an excellent design does not necessarily equal excellent practice. The following section describes the specific problems.
Problems for Container Image Users
Problems for Container Image Providers
The provider refers to the image center of the container service.
Thoughts and Discussions on Container Images
Attempts by the Industry
Considering the problems mentioned above, small and large companies in the industry have had an all-hands-on-deck. Here are a few typical projects:
Discussions in OCI Community
Since 2019, complaints about the images have increased gradually and lasted for more than a year. Starting from June 2020, the OCI community took more than a month to discuss the defects of the current OCI image format specification and the requirements for the OCIv2 image format (*).
(*): OCIv2 is just a name for promotion here. OCIv2 is an improvement of the current OCI image format specification, not a completely new one.
Defects of the OCI Image Format Specification
After discussion, two main defects were concluded:
After the tar format is compressed by gzip, seeking is not supported. Therefore, image layers of targz must be downloaded and decompressed before running the container, and on-demand data file loading is not available.
Format Requirements for Next-Generation Images
This time, the image format is discussed starting from one e-mail and a copy of a shared document, contributing to many online OCI community discussion meetings simultaneously. The conclusion is also very encouraging. This shared document explains the detailed description of the requirements for the OCIv2 image format, which are classified below:
[table=787.987,#ffffff,,1][tr][td]Efficiency[/td][td]Ease of Use[/td][td]Security[/td][/tr][tr][td]- Less duplicate data
- Unambiguous less filesystem metadata (*)
- On-demand load image data
- Less uploaded data[/td][td]- Changeable image format
- Filesystem format that can be mounted
- Scalability[/td][td]- Image content list
- Verifiable and/or repairable
- Works on untrusted storage[/td][/tr][/table](*): It is unnecessary for the Metadata that works on a specific machine, such as file timestamp, to exist in the images.
These requirements make it clear that container images should focus on user-friendliness, efficiency, and security to achieve collaborative optimization in the build, ship, and run phases.
Thoughts of Alibaba Cloud on Container Images
Alibaba Cloud has been actively promoting and developing the cloud-native ecosystem, providing the infrastructure, Alibaba Cloud Container Registry (ACR), as the first stop of users' cloud-native containerization. ACR provides container images, OCI Artifacts management, such as Helm Chart management and distribution services. Meanwhile, Alibaba Cloud is now deepening its understanding of container image formats based on the status quo in the container business. By doing so, Alibaba Cloud aims to constantly summarize container image formats that meet development needs. The summary is listed below. The new image formats need to:
Image Acceleration of Alibaba Cloud Sandbox Containers
Different from the discussion in the community, Alibaba Cloud focuses on the design of a set of optimized full-procedure image solutions for customers to put into production.
After clarifying the preceding requirements during technological development, a new image format named Rafs was designed for Alibaba Cloud sandbox containers. At the same time, the container image service was introduced for the Dragonfly project under CNCF, reducing the image download time. What's more, by providing consistent validation of end-to-end image data, users can manage container applications securely and quickly.
Rafs: Image Format
Rafs divides a container image into two layers, metadata and data:
Nydus: Container Image Service of Dragonfly
In addition to using the image format of Rafs, Nydus includes a FUSE user-state filesystem process responsible for container image parsing.
Nydus parses the FUSE or virtiofs protocol to support the traditional runc container or Alibaba Cloud sandbox container. Container repositories, Object Storage Service (OSS), Network Attached Storage (NAS), and the supernodes and peer nodes of Dragonfly can be used as image data sources of Nydus. Moreover, Nydus configures a local cache to avoid pulling data from a remote data source in each startup.
Based on this design architecture, Nydus provides optimizations respectively in build, ship, run, and compatibility:
[table=787.987,#ffffff,,1][tr][td]Build[/td][td]Ship[/td][td]Run[/td][td]Compatibility[/td][/tr][tr][td]- Block-level image data deduplication minimizes storage resources for users.[/td][td]- With different image backends, image data can be stored in the image repository, NAS, and object storage like Simple Storage Service.
- Integrates with Dragonfly's p2p capabilities well[/td][td]- Container images are downloaded on-demand, enabling users to start containers without downloading the complete images.
- The image only has the data that is finally available, and there is no need to save or download expired data.
- Consistency validation of end-to-end data provides users with better data protection.[/td][td]- Compatible with OCI distribution and artifacts standards with ready-to-use capabilities[/td][/tr][/table]
Reasons for the Design Based on Files
At the beginning of the design, Nydus chose a file-based design instead of a block-based design. Why?
The main reason is that additional container functions were supposed to be implemented based on image acceleration. This is based on the acquisition of file metadata from the images. However, the block-based design only uses disk LBA and cannot obtain information on its upper layer (the file system.)
With file metadata, the following additional functions are realized easily: