Notice​

The article is Chinese only P2P 加速 Docker 镜像分发(阿里 Dragonfly2 + Google jib)(基于 d7y 2.0.2)

Containerd Accepted Nydus-snapshotter​

Early January, Containerd community has taken in nydus-snapshotter as a sub-project. Check out the code, particular introductions and tutorial from its new repository. We believe that the donation to containerd will attract more users and developers for nydus itself and bring much value to the community users.

Nydus-snapshotter is a containerd's remote snapshotter, it works as a standalone process out of containerd, which only pulls nydus image's bootstrap from remote registry and forks another process called nydusd. Nydusd has a unified architecture, which means it works in form of a FUSE user-space filesystem daemon, a virtio-fs daemon or a fscache user-space daemon. Nydusd is responsible for fetching data blocks from remote storage like object storage or standard image registry, thus to fulfill containers' requests to read its rootfs.

Nydus is an excellent container image acceleration solution which significantly reduces time cost by starting container. It is originally developed by a virtual team from Alibaba Cloud and Ant Group and deployed in very large scale. Millions of containers are created based on nydus image each day in Alibaba Cloud and Ant Group. The underlying technique is a newly designed, container optimized and oriented read-only filesystem named Rafs. Several approaches are provided to create rafs format container image. The image can be pushed and stored in standard registry since it is compatible with OCI image and distribution specifications. A nydus image can be converted from a OCI source image where metadata and files data are split into a "bootstrap" and one or more "blobs" together with necessary manifest.json and config.json. Development of integration with Buildkit is in progress.

Nydus provides following key features:

• Chunk level data de-duplication among layers in a single repository to reduce storage, transport and memory cost
• Deleted(whiteout) files in certain layer aren't packed into nydus image, therefore, image size may be reduced
• E2E image data integrity check. So security issues like "Supply Chain Attack" can be avoided and detected at runtime
• Integrated with CNCF incubating project Dragonfly to distribute container images in P2P fashion and mitigate the pressure on container registries
• Different container image storage backends are supported. For example, Registry, NAS, Aliyun/OSS and applying other remote storage backend like AWS S3 is also possible.
• Record files access pattern during runtime gathering access trace/log, by which user's abnormal behaviors are easily caught. So we can ensure the image can be trusted

Beyond above essential features, nydus can be flexibly configured as a FUSE-base user-space filesystem or in-kernel EROFS with an on-demand loader user-space daemon and integrating nydus with VM-based container runtime is much easier.

• Lightweight integration with VM-based containers runtime like KataContainers. In fact, KataContainers is considering supporting nydus as a native image acceleration solution.
• Nydus closely cooperates with Linux in-kernel disk filesystem Containers' rootfs can directly be set up by EROFS with lazy pulling capability. The corresponding changes had been merged into Linux kernel since v5.16

To run with runc, nydusd works as FUSE user-space daemon:

To work with KataContainers, it works as a virtio-fs daemon:

Nydus community is working together with Linux Kernel to develop erofs+fscache based user-space on-demand read.

Nydus and eStargz developers are working together on a new project named acceld in Harbor community to provide a general service to support the conversion from OCI v1 image to kinds of acceleration image formats for various accelerator providers, so that keep a smooth upgrade from OCI v1 image. In addition to the conversion service acceld and the conversion tool nydusify, nydus is also supporting buildkit to enable exporting nydus image directly from Dockerfile as a compression type.

In the future, nydus community will work closely with the containerd community on fast and efficient methods and solution of distributing container images, container image security, container image content storage efficiency, etc.

Introducing Dragonfly Container Image Service​

Small is Fast, Large is Slow​

With containers, it is relatively fast to deploy web apps, mobile backends, and API services right out of the box. Why? Because the container images they use are generally small (hundreds of MBs).

A larger challenge is deploying applications with a huge container image (several GBs). It takes a good amount of time to have these images ready to use. We want the time spent shortened to a certain extent to leverage the powerful container abstractions to run and scale the applications fast.

Dragonfly has been doing well at distributing container images. However, users still have to download an entire container image before creating a new container. Another big challenge is arising security concerns about container image.

Conceptually, we pack application's environment into a single image that is more easily shared with consumers. Image is then put into a filesystem locally on top of which an application can run. The pieces that are now being launched as nydus are the culmination of the years of work and experience of our team in building filesystems. Here we introduce the dragonfly image service (codename nydus) as an extension to the Dragonfly project. It's software that minimizes download time and provides image integrity check across the whole lifetime of a container, enabling users to manage applications fast and safely.

nydus is co-developed by engineers from Alibaba Cloud and Ant Group. It is widely used in the internal production deployments. From our experience, we value its container creation speedup and image isolation enhancement the most. And we are seeing interesting use cases of it from time to time.

Nydus: Dragonfly Image Service​

The nydus project designs and implements an user space filesystem on top of a container image format that improves over the current OCI image specification. Its key features include:

• Container images are downloaded on demand
• Chunk level data duplication
• Flatten image metadata and data to remove all intermediate layers
• Only usable image data is saved when building a container image
• Only usable image data is downloaded when running a container
• End-to-end image data integrity
• Compactible with the OCI artifacts spec and distribution spec
• Integrated with existing CNCF project dragonfly to support image distribution in large clusters
• Different container image storage backends are supported

Nydus mainly consists of a new containier image format and a FUSE (Filesystem in USErspace) daemon to translate it into container accessible mountpoint.

The FUSE daemon takes in either FUSE or virtiofs protocol to service POD created by conventional runc containers or Kata Containers. It supports pulling container image data from container image registry, OSS, NAS, as well as Dragonfly supernode and node peers. It can also optionally use a local directory to cache all container image data to speed up future container creation.

Internally, nydus splits a container image into two parts: a metadata layer and a data layer. The metadata layer is a self-verifiable merkle tree. Each file and directory is a node in the merkle tree with a hash aloneside. A file's hash is the hash of its file content, and a directory's hash is the hash of all of its descendents. Each file is divided into even sized chunks and saved in a data layer. File chunks can be shared among different container images by letting file nodes pointing inside them point to the same chunk location in the shared data layer.

How can you benefit from nydus?​

The immediate benefit of running nydus image service is that users can launch containers almost instantly. In our tests, we found out that nydus can boost container creation from minutes to seconds.

Another less-obvious but important benefit is runtime data integration check. With OCIv1 container images, the image data cannot be verified after being unpacked to local directory, which means if some files in the local directories are undermined either intentionally or not, containers will simply take them as is, incurring data leaking risk. In contrast, nydus image won't be unpacked to local directory at all, what's more, given that verification can be enforced on every data access to nydus image, the data leak risk can be completely avoided by forcing to fetch the data from the trusted image registry again.

The Future of Nydus​

The above examples showcase the power of nydus. For the last year, we've worked alongside the production team, laser-focused on making nydus stable, secure, easy to use.

Now, as the foundation for nydus has been laid, our new focus is the ecosystem it aims to serve broadly. We envision a future where users install dragonfly and nydus on their clusters, run containers with large image as fast they do with regular size image today, and feel confident about the safety of data on their container image.

For the community​

While we have widely deployed nydus in our production, we believe a proper upgrade to OCI image spec shouldn’t be built without the community. To this end, we propose nydus as a reference implementation that aligns well with the OCI image spec v2 proposal [1], and we look forward to working with other industry leaders should this project come to fruition.

FAQ​

Q: What are the challenges with oci image spec v1?​

• "The Road to OCIv2 Images: What's Wrong with Tar?" written by Aleksa Sarai covers all the challenges with OCIv1, a quick summary of his article is that tar is legacy and doesn't fit well to be a container image format.

Q: How is this different than crfs?​

• The basic idea of the two are quite similar. Deep down, the nydus image format supports chunk level data deduplication and end-to-end data integraty at runtime, which is an improvement over the stargz format used by crfs.

Q: How is this different than Teleport of Azure?​

• Azure Teleport is like the current OCI image format plus a SMB-enabled snapshotter. It supports container image lazy-fetching and suffers from all the Tar format defects. OTOH, nydus deprecates the legacy Tar format and takes advantage of the merkle tree format to provide more advantages over the Tar format.

Q: What if network is down while container is running with nydus?​

• With OCIv1, container would fail to start at all should network be down while container image is not fully downloaded. Nydus has changed that a lot because it goes with lazy fetch/load mechanism, a failure in network may take down a running container. Nydus addresses the problem with a prefetch mechanism which can be configured to
• run in background right after starting a container.

[1]：OCI Image Specification V2 Requirements​

In the mean time, the OCI (Open Container Initiate) community has been actively discussing the emerging of OCI image spec v2 aiming to address new challenges with oci image spec v1.

Starting from June 2020, the OCI community spent more than a month discussing the requirements for OCI image specification v2. It is important to notice that OCIv2 is just a marketing term for updating the OCI specification to better address some use cases. It is not a brand new specification.

The discussion went from an email thread (Proposal Draft for OCI Image Spec V2) and a shared document to several OCI community online meetings, and the result is quite aspiring. The concluded OCIv2 requirements are:

• Reduced Duplication
• Canonical Representation (Reproducible Image Building)
• Explicit (and Minimal) Filesystem Objects and Metadata
• Mountable Filesystem Format
• Bill of Materials
• Lazy Fetch Support
• Extensibility
• Verifiability and/or Repairability
• Reduced Uploading
• Untrusted Storage

For detailed meaning of each requirement, please refer to the original shared document. We actively joined the community discussions and found out that the nydus project fits nicely to these requirements. It further encouraged us to opensource the nydus project to help the community discussion with a working code base.

Notice​

The article is deprecated and Chinese only 阿里 Dragonfly 体验之私有 registry 下载(基于0.3.0)

Notice​

The article is deprecated and Chinese only 使用 Dragonfly 加速 Docker 镜像分发(基于0.3.0)

Notice​

The article is deprecated and Chinese only 睿云智合基于 Dragonfly 支持docker proxy https

Notice​

The article is deprecated and Chinese only 在 Kubernetes 上部署 Dragonfly

Dragonfly adoption in DCOS of China Mobile Group Zhejiang Co., Ltd​

In November 2018, Dragonfly, a cloud-native image distribution system from Alibaba, was on display at KubeCon Shanghai and has become a CNCF sandbox level project since then.

Dragonfly mainly resolves the image distribution problems in Kubernetes-based distributed application orchestration systems. In 2017, open source became one of Alibaba's most central infrastructure technologies. A year after Alibaba adopted open source as a core technology, Dragonfly has been used in a variety of industrial fields.

DCOS is the container cloud platform at China Mobile Group Zhejiang Co., Ltd. Currently, 185 application systems are running on this platform, including core systems such as the China Mobile service mobile app and the CRM application. This article mainly describes Dragonfly's implementation in the container cloud platform (DCOS) at China Mobile Group Zhejiang Co., Ltd to resolve problems in the large-scale cluster scenario, such as low distribution efficiency, low success rate, and difficult network bandwidth control. In addition, Dragonfly upgraded its features and established high availability deployment based on feedback from the DCOS platform to the community.

Challenges Faced by the DCOS Container Cloud in the Production Environment {#challenges-faced-by-the-dcos-container-cloud-in-the-production-environment}​

As the DCOS container cloud platform continuously improves and hosts more and more applications (nearly 10,000 running containers), it has become increasingly difficult for distribution service systems using traditional C/S (client-server) architecture to meet requirements in scenarios such as publishing code packages and transmitting files in large-scale distributed applications due to the following reasons:

• Downloading code packages fail due to factors like computing node network exceptions, eventually influencing the integrity and consistency of application code packages.
• Terabytes of data may need to be transmitted in multiuser and highly-concurrent scenarios. However, the single-node performance bottlenecks prolong application publishing time.

What Is Dragonfly? {#what-is-dragonfly}​

P2P (peer-to-peer) is a node-to-node network technology that connects individual nodes and distributes resources and services in networks among individual nodes. Information transmission and service implementation are carried out directly across nodes to avoid single-node performance bottlenecks that may otherwise occur in traditional C/S architecture.

Dragonfly is a CNCF open-source file distribution service solution based on the P2P and CDN technologies and suitable for distributing container images and files. Dragonfly can efficiently resolve low file and image distribution efficiency, low success rate, and network bandwidth control problems in an enterprise's large-scale cluster scenarios.

Core components of Dragonfly:

• SuperNode: Downloads files from a file source in a passive CDN manner and produces seed data blocks.
• In a P2P network, a supernode serves as a network controller to schedule block data transmission among nodes.
• dfget proxy: Deployed on computing nodes and responsible for downloading data blocks to P2P nodes
• and sharing data among nodes.

Dragonfly distribution principle (take image distribution, for example): Unlike ordinary files, container images consist of multiple storage layers. Downloading container images is also performed at a layer level instead of downloading a single file. Images in each layer can be divided into data blocks and serve as seeds. After container images are downloaded, the unique IDs of images in each layer and the sha256 algorithm are used to combine downloaded images into complete images. Consistency is ensured during the downloading process.

The following diagram shows how images are downloaded in Dragonfly.

1. The dfget-proxy intercepts the image download request (docker pull) from the docker client and converts it into the dfget download request targeting the SuperNode.
2. The SuperNode downloads images from the image source warehouse and divides them into multiple seed data blocks.
3. The dfget downloads data blocks and openly shares the downloaded data blocks. The SuperNode records information about downloading data blocks and guides the subsequent requests to download data blocks across nodes in a P2P manner.
4. The Docker daemon uses its image pull mechanism to combine image files into complete images.

Based on the preceding Dragonfly characteristics and the actual production conditions, China Mobile Group Zhejiang Co., Ltd decided to introduce the Dragonfly technology into its container cloud platform to reform its existing code package publishing model, share the transmission bandwidth bottleneck on a single file server by using a P2P network, and ensure the consistency of image files throughout the publishing process.

Solution: Unified Distribution Platform {#solution-unified-distribution-platform}​

Functional Architecture Design {#functional-architecture-design}​

Functional Architecture Design​

Based on the Dragonfly technology and the production practices of China Mobile Group Zhejiang Co., Ltd, the unified distribution platform has the following overall design objectives:

• Use Dragonfly and the file download verification feature to resolve the inconsistency during the process publishing application code and the long publishing time problems in the current publishing process;
• Provide support for interface-based clients, block background command details, and simplify the process to achieve higher efficiency;
• Support distribution in various cloud environments, including Mesos, K8s, Host, and VM, implement self-discovery of clusters, and enable users to manage target clusters via the unified distribution platform;
• Add the user permission control and task bandwidth restriction features and support multi-tenant and multitask distribution;
• Optimize the P2P Agent deployment models and enable faster P2P networking of computing nodes.

Based on these objectives, the overall architecture design is as follows:

• The P2P network layer is a distribution network that consists of multiple computing nodes and allows different heterogeneous clusters (host clusters, K8s clusters, and Mesos clusters) to be connected;
• As the core architecture of the entire universal distribution system, the distribution service layer consists of the functional modules and the storage modules. Among them, the user access authentication module provides the system login verification feature; based on Dragonfly, the distribution control module implements task distribution in a P2P manner; the traffic control module enables tenants to configure bandwidth for different tasks; the configuration info database is responsible for recording basic information, such as target clusters in the network layer and task status; the status query module enables users to closely monitor the distribution task progress;
• The user action layer consists of any number of interface-based clients.

Technical Architecture Implementation​

According to the preceding platform design objectives and architecture analyses, the DOCS container cloud team conducted secondary development of the platform features based on the open-source components, including the following:

• Use of interface-based clients;
• Addition of the open source image warehouse "Harbor" to store images and the "Minio" Object Storage Service to store files;
• Use of MySQL and Redis as CMDBs and the ability of MySQL manage data, such as cluster status and user information, to support "one-click" creation of tasks targeting clusters. Use of Redis to save status information about distribution tasks and provide highly concurrent and low-latency status query services;
• Both the core service layer (Docktrans) of the platform and the API gateway service layer (Edgetrans) are stateless, cluster-oriented, and dynamically scalable core groups:
  • The API gateway encapsulates the internal system architecture and is responsible for receiving and forwarding task requests sent by clients, authenticating user access to individual functional modules, and providing customized API calls to external services;
  • The core service layer is the engine that processes business logic for all functional modules on the platform. During the distribution process, the core service layer sends the download request to the P2P proxy node via unified remote calls and completes the "one-to-many" client/task cluster distribution.
  • Both df-master and df-client are Dragonfly components. df-master is the SuperNode in Dragonfly, and df-client is the peer-to-peer node proxy (dfget proxy) in a P2P network.

Technical Characteristics {#technical-characteristics}​

• df-client implements container mirroring. The lightweight container deployment improves networking efficiency. The cluster host nodes that are newly added to the network layer can start P2P Agent nodes in a few seconds by downloading and starting images.
• The core interface layer (Docktrans) screens the command-line details at the bottom layer of dfget and provides interface-based features to simplify user operations. Distributing to multiple P2P task nodes via unified remote calls eliminates the need for users to perform download operations, like dfget, node by node and simplifies the "one-to-many" task launching model.

Core Functional Modules: Interaction Process of Distribution Control Interfaces {#core-functional-modules-interaction-process-of-distribution-control-interfaces}​

The following figure shows how the core modules of the unified distribution platform distribute tasks.

1. A user uses the client to create an image or file distribution task.
2. The distribution module judges whether the user has the distribution permission by using the authentication feature provided by the API service gateway (Edgetrans).
3. After the user passes authentication, sets parameters for the distribution task, and provides the cluster ID, the platform reads cluster configuration information from the MySQL database to implement the self-discovery of the cluster nodes. The user can also specify multiple node IPs as custom cluster parameters.
4. Depending on the distribution type, the distribution module in the core service layer (Docktrans) converts front-end distribution requests into dfget (for files) or Docker pull (for images) commands, and distributes commands down to multiple node df-clients for processing by remotely calling the Docker Service.
5. During the process of performing the task, task progress and task transaction logs are written to the Redis database and the MySQL database, respectively, to enable users to query task status.

Production Environment Reformation Results {#production-environment-reformation-results}​

Currently, over 200 business systems and over 1,700 application modules that are currently running in the production environment have been optimized to use the image publishing model. The time consumption for publishing and the publishing success rate have significantly improved. After the P2P image publishing method is adopted, the monthly success rate of publishing multiple applications at a time is steady at 98%.

After April, the container cloud platform began using the P2P image publishing method in place of the code package publishing model in traditional distribution systems. After the platform is reformed, publishing multiple applications intensively at once significantly reduces time consumption (by 67% on average).

n the meantime, the container cloud platform selects multiple application clusters to test the efficiency in publishing a single application's P2P images after the transformation. As we can see, the time consumption for publishing a single application is significantly reduced (by 81.5% on average) compared with consumption by the platform before reformation.

Subsequent Utilization Plans {#subsequent-utilization-plans}​

The unified file distribution platform has resolved the efficiency and consistency problems faced by China Mobile Group Zhejiang Co., Ltd when using its DCOS platform to publish code and has become a key component of the platform. The unified file distribution platform also supports efficient file distribution in larger-scale clusters. This distribution platform can be consecutively applied to batch-distribute cluster installation media and batch-update cluster configuration files.

Community Co-Construction: Interface Function Display {#community-co-construction-interface-function-display}​

Community Requirements Resulting from Directly Introducing Dragonfly {#community-requirements-resulting-from-directly-introducing-dragonfly}​

• Lack of graphical interfaces contributes to high cost for users and low operation efficiency;
• The user permission management and distribution audit features are not available, and the distribution control cannot be implemented;
• The "one-to-many" cluster operation model is not supported. In the cloud environment, users usually need distribution to multiple clusters at the same time as management takes place, but the current model only supports distribution on a single node;
• The traditional Agent application package deployment is too inefficient to implement fast scalability of large-scale clusters. Serving as the system software increases the level of intrusion into host systems.

Currently, the interface-based client is almost developed and is in production testing and deployment. The four planned core features of the distribution platform are Task Management, Target Management, Permission Management, and System Analysis. Currently, the first three features are available.

Permission Management {#permission-management}​

Permission Management (namely, user management) is designed to provide customized permission management features targeting different users, as listed below:

• It supports the creation, deletion, and modification operations for various user roles (super administrator, task cluster administrator, and task administrator);
• It supports the customized combination of collections with different permissions (role creation) and allows user permissions to be granted;
• It supports access from external system users and allows permissions to be granted to external system users (not yet available).

Target Management {#target-management}​

Target Management enables users to manage target cluster nodes when distributing tasks and manage P2P cluster networking, as well as cluster node status and health, as described below:

• It supports the creation and deletion operations on various user clusters;
• In the user-managed clusters, it supports automated container agent deployment, fast addition or deletion of P2P network nodes, and node status monitoring;
• It enables different types of clusters, such as host (physical machine and virtual machine), K8s, and Mesos clusters, to access the network. It also supports directly reading of K8s and Mesos cluster node info and batch access of the P2P network layer.

Task Management {#task-management}​

Task Management enables users to create, delete, and stop file or image distribution tasks and perform other operations, as detailed below:：

• It supports the image warm-up mode (enabling users to set scheduled distribution tasks and distribute images or files to nodes in advance);
• This feature supports the distribution of files in various formats, such as container images;
• It makes it possible to "one-click" create, perform, delete, and stop tasks on multiple nodes in a specified task cluster, as well as copy executed tasks;
• It supports the creation, deletion, and management of the published file versions;
• It supports viewing distribution task status and task logs.

System Analysis (coming soon) {#system-analysis-coming-soon}​

The system analysis feature is expected to be released later to provide platform administrators and users with statistical graphs showing information such as task distribution time consumption, success rate, and task execution efficiency and facilitate platform intelligence via data statistics and prediction.

Community Co-Construction: High-Availability Deployment of Production {#community-co-construction-high-availability-deployment-of-production}​

Active-standby mirror database disaster tolerance ensures data consistency between the active and standby databases through image synchronization.

• The P2P publishing method consists of df-master and df-client (in blue). The df-master pulls images from the mirror database to form P2P seeds, and two df-masters are configured in each data center;
• P2P distribution is only performed in local data centers to avoid traffic across data centers;
• Two mirrors (standby mirror databases) are configured in each data center. In the event of P2P distribution exceptions, computing nodes automatically go to the mirrors to download images.
• Mirrors implement high availability through load balancing.

We currently plan to contribute interface feature displays to the CNCF Dragonfly community to further enrich community content. We hope that more people join and help to improve the community.

Authors:

Chen Yuanzheng Cloud Computing Architect at China Mobile Group Zhejiang Co., Ltd

Wang Miaoxin Cloud Computing Architect at China Mobile Group Zhejiang Co., Ltd

Dragonfly Community Sharing {#dragonfly-community-sharing}​

Tai Yun, a contributor in the Dragonfly community, said during a Dragonfly Meetup：

Dragonfly is now a CNCF sandbox project with 2700+ stars. Many enterprises are using Dragonfly to resolve various problems they have encountered when distributing images and files. We will continuously improve Dragonfly to provide a more powerful and simpler distribution tool for cloud-native applications.I look forward to working with you to make Dragonfly a CNCF 'graduated' project as soon as possible.

Official GitHub page {#official-github-page}​

https://github.com/dragonflyoss/Dragonfly

Dragonfly Roadmap {#dragonfly-roadmap}​

https://github.com/dragonflyoss/Dragonfly/blob/master/ROADMAP.md