Before a summary

On August 13, Docker updated its service Agreement, stating that it prohibits prohibited countries and organizations and individuals listed on the “U.S. Entities List” from using Docker and all related websites linked to the service Agreement. This update agreement quickly aroused wide attention and discussion in the industry, and the discussion about “Docker is banned” arose one after another.

What are the products and services that are actually restricted?

In conjunction with clauses 1.1, 1.2 and 2.5, it is clear that:

  • Docker prohibits the use of Docker Business Edition Docker-EE and other Docker services, such as Docker Hub, by enterprises listed in the “Us Entity List” list.

  • Free users will be limited in the number of images, pull/push frequency and other aspects when using Docker Hub. For example, the free account is limited to 200 downloads within 6 hours. While an enterprise will typically deploy its own private image repository internally, this limitation may still apply when building or using the underlying image.

  • Docker open source container engine Moby, which is widely used in the industry, is not affected by this because it adopts the Apache License 2.0 protocol, that is, the open source version of Docker-CE is not affected by this.

For prevention and risk reduction, fat containers are an option

BoCloud, as one of the first cloud computing manufacturers using container open source technology in China, is also keeping a close eye on this incident. According to the Linux Foundation’s “Understanding U.S. Export Controls on Open Source Projects,” it is clear that “publicly published” and “open source” projects are not affected by the Export Control Terms of Service. Cloud BeyondContainer uses the open source community version of Docker docker-CE, which is “publicly released” and “open source”. Therefore, the open source version of Docker-CE will not be affected. In addition, this term affects the use of Docker Hub, the public image warehouse, and The clients of Boyun use the private image warehouse, which will not be affected by the restrictions of Docker Hub. Although the open source version of Docker is not affected and restricted, open source does not mean unregulated. In the long run, companies also need to think ahead to other strategies to prevent further restrictions. To prevent and reduce risks, enterprises can consider using container versions maintained by domestic container cloud vendors, or choose container cloud products that support multiple open source container runtimes simultaneously. At the end of 2019, BeyondVM released a self-developed and self-maintained container version: BeyondVM Fat Container (compatible with traditional applications, Storage edge Cloud — Bo Yun fat Container solution). BeyondVM fat containers provide a relatively complete process tree container environment and system service, has better isolation, support for business at the same time as the container and the virtual machine running experience, without changing the code migration to the container platform can be realized, help customers quickly container stock application, rapid progressive hug cloud native technology. Using BeyondVM fat Container technology, you can achieve:

  • The experience of using native containers and VMS is compatible.

  • Lighter resource allocation capability than VMS, facilitating rapid resource application and flexibility.

  • Similar to virtual machine experience, you can log in, can install any component.

  • There is a fixed IP address. The IP address of the fat container remains unchanged from the time it is created to the time it is deleted.

  • You can log in to the system remotely through SSH.

  • Strict resource isolation, such as CPU, memory, etc.

  • The resources seen by the JVM, the monitoring tools, are not the resources of the entire physical machine, but the resources actually allocated for use by the fat container.

On July 29, China Academy of Information and Communications Technology released the first ecological picture of cloud native technology in China at the trusted Cloud Conference 2020. BeyondVM fat container was selected as the container technology section of the picture. At present, BeyondVM fat container has been tested for large-scale production applications. If there is a limit, BeyondVM fat container can be directly used to replace Docker without upgrading the version, and it can obtain better isolation and provide stronger support for stateful applications.

Support for multiple container runtimes, avoiding a single technology binding

Container runtime is the key software supporting Kubernetes node. In recent years, with the further development of Kubernetes, a variety of container runtimes have been born in the industry. Currently, when talking about container runtime, we have to mention two protocols in the community: OCI and CRI. These two different protocols have different standard implementations in their respective domains.

The OCI specification (Open Container Initiative Open Container Standard) focuses on two parts: the Container Runtime Spec and the Container Image Spec. Among them, the typical OCI compliant projects are RUNC, KATA, etc. (BeyondVM fat containers are OCI compliant and can be flexibly integrated with Kubernetes clusters.)

Container Runtime Interface (CRI) is a standard interface proposed by Kubernetes for interworking with various Container runtime interfaces. The CRI consists of two parts: The first is the container RuntimeService RuntimeService, which manages the pod and container lifecycle. The other is the ImageService ImageService, which manages the life cycle of images. Among them, the typical implementation of CRI is Docker, Containerd, etc.

Although docker-based container runtime is still the current kubernetes default choice, thanks to the CRI interface proposed by Kubernetes, users have more container runtime choices. BeyondContainer cloud will also soon provide support for multiple container runtimes in addition to Docker to help enterprise users avoid the risks of a single technology binding.