Shulou(Shulou.com)06/03 Report--

PouchContainer is Alibaba Group's open source efficient, lightweight enterprise-level rich container engine technology, with strong isolation, high portability, low resource consumption and other features. It can help enterprises to quickly realize the containment of inventory business, and at the same time improve the utilization of physical resources in super-large-scale data centers. It has helped Alibaba Group to realize 100% containerization of online business, and the scale of double 11 containers has reached one million.

PouchContainer volume is a mechanism specifically used to solve the data persistence of containers. If you want to understand the mechanism of volume, you need to understand the mirroring mechanism of PouchContainer. PouchContainer, like Docker, implements the layered mechanism of mirroring. The so-called image layering mechanism means that the image of the container is actually superimposed by multiple read-only mirror layers (layer), so that different images can reuse the image layer, which greatly speeds up the efficiency of image distribution and reduces the startup time of the container. When the container needs to be started, pouchd (pouchd mentioned below all refer to PouchContainer daemon) will add a read-write layer to the top layer of the boot image, and all subsequent read and write operations of the container will be recorded in this read-write layer. This also introduces a problem, which is the persistence of container data. If we delete the container, the previous changes made by the container will be lost when we start through the mirror again, which is fatal for stateful applications such as databases.

Volume bypasses the mirroring mechanism and allows the data in the container to exist on the host in the form of normal files or directories. When the container is stopped or deleted, it will not affect the data in volume, thus achieving data persistence, and volume data can be shared among different container.

The overall architecture of PouchContainer volume

This section may involve the volume source code implementation of PouchContainer.

At present, the overall architecture of PouchContainer volume is mainly composed of the following parts:

VolumeManager: this structure is the entry point for volume-related operations.

Core:Core is the core module of volume, which contains the business logic of volume operation.

Store: responsible for storing volume metadata, which is currently stored in a local boltdb file.

Driver:volume driver interface, abstracting the basic functions of volume-related drivers

Modules: specific volume driver. At present, there are four volume drivers: local, tmpfs, volume plugin and ceph.

Pouch_volume_arch.png | center | 747x624

VolumeManager is the storage component in PouchContainer (other components include ContainerManager, ImageManager, NetworkManager, etc.), it is the entrance to all volume operations, and currently provides Create/Remove/List/Get/Attach/Detach interfaces. Core contains the core logic of volume operation, which is responsible for calling the underlying specific volume driver, realizing the creation, deletion, attach, detach and other operations of volume, and calling Store at the same time to achieve volume metadata management. The Store module is specifically responsible for the metadata management of volume, and the relevant states of volume are stored through Store. The reason why metadata management is used as a module is to facilitate expansion in the future. At present, volume metadata is stored in boltdb, and it may also be stored in etcd in the future. Driver abstracts the interfaces that volume driver needs to implement. A specific volume driver needs to implement the following interfaces:

Type Driver interface {

/ / Name returns backend driver's name.

Name (Context) string

/ / StoreMode defines backend driver's store model. StoreMode (Context) VolumeStoreMode / / Create a volume. Create (Context, * types.Volume, * types.Storage) error / / Remove a volume. Remove (Context, * types.Volume, * types.Storage) error / / Path returns volume's path. Path (Context, * types.Volume) (string, error)

}

Volume types supported by PouchContainer

At present, PouchContainer supports three specific volume types, namely local, tmpfs and ceph, and supports more third-party storage through a general storage plug-in mechanism such as volume plugin.

2.1 local volume

Local volume is the default volume type of PouchContainer, which is suitable for storing data that needs to be persisted, and its life cycle is independent of the life cycle of the container.

When you create a volume, if the driver type is not specified, the default local is the driver type. Local volume is essentially a subdirectory created under the pouchd to / var/lib/pouch/volume directory. Compared to docker,PouchContainer 's local volume, there are more practical features, including:

Specify mount directory to create volume

You can specify the volume size

First we can specify the directory to create a local volume. This feature is very practical in production. For some applications, such as databases, we need to mount special block devices to store database data. For example, operators format the block devices and mount them to the / mnt/mysql_data directory. By executing the following command, we have created a volume mounted on / mnt/mysql_data, and then we can mount the volume to the specified directory of the container and start the container.

Pouch volume create-driver local-option mount=/mnt/mysql_data-name mysql_data

Second, we can limit the size of the volume. This function depends on the quato function provided by the underlying file system. Currently, the underlying file systems supported are ext4 and xfs, and the kernel version is also required.

Pouch volume create-driver local-option size=10G-name test_quota

2.2 tmpfs volume

The data of tmpfs volume will not be persisted to the hard disk, but will only be stored in memory (if there is insufficient memory, it will be stored in swap). The access speed is fast, but when the container stops running, all the information in the volume will disappear, so tmpfs volume is only suitable for storing some temporary and sensitive data.

Tmpfs volume is stored in the / mnt/tmpfs directory by default, and you can also specify its mount path with-o mount. However, it doesn't make sense to specify the mount path of the tmpfs, because the tmpfs content is stored directly in memory.

Pouch volume create-driver tmpfs-name tmpfs_test

2.3 ceph volume

Ceph is a special type of volume. Ceph volume stores data in a ceph cluster (ceph rbd storage), so it is possible to migrate volume across physical machines.

At present, ceph volume cannot be used by the outside world. As can be seen from the PouchContainer volume architecture diagram, there is also a layer of alibaba storage controller between the ceph driver and driver layers (note: alibaba storage controller is just a pronoun), which is a set of container storage management platform within Alibaba, followed by many storage solutions such as ceph/pangu/nas. By interfacing with the container storage management platform, PouchContainer can directly use ceph to provide volume. We may open source the container storage management platform at a later stage.

2.4 volume plugin

Volume plugin is a universal volume and, to be exact, an extension mechanism for volume. At present, docker can manage a lot of third-party storage through the plug-in mechanism, and PouchContainer also implements the volume plugin mechanism, which can seamlessly connect the existing volume plugin of the original docker.

As a volume plugin, you must implement volume plugin protocol. Volume plugin is essentially a web server, and the web server implements the following services, and all requests are POST requests.

/ VolumeDriver.Create / / Volume create service

/ VolumeDriver.Remove / / Volume delete service

/ VolumeDriver.Mount / / Volume mount service

/ VolumeDriver.Path / / Volume mount path service

/ VolumeDriver.Unmount / / Volume uninstall service

/ VolumeDriver.Get / / Volume Get service

/ VolumeDriver.List / / Volume List service

/ VolumeDriver.Capabilities / / VolumeDriver competency service

Bind mounts and volumes

PouchContainer currently supports two ways of data persistence, in addition to the above volumes, you can also take advantage of bind mounts. Bind mounts, as its name implies, refers to mounting the host's directory directly into the container.

Pouch run-d-t-v / hostpath/data:/containerpath/data:ro ubuntu sh

The above command mounts the / hostpath/data directory on the host to the container's / containerpath/data directory so that it is read-only.

Bind mounts relies on the directory structure of the host file system, while volume has a special mechanism for management in PouchContainer. Volumes has the following advantages over bind mounts:

Volumes is easier to back up and manage than bind mounts.

PouchContainer provides specialized CLI and API to manage volumes

Volumes is suitable for secure sharing among multiple containers

Volumes provides a plug-in mechanism that makes it easier to interface with third-party storage.

The Future Development of PouchContainer volume

CSI, or Container Storage Interface (this project defines the storage interface between the container scheduling layer and the container), has been released in v0.2. In the future, Pouch may add a common type of driver for interfacing with storage systems that have implemented the CSI interface.

Summary

This paper introduces the volume mechanism of PouchContainer. The main purpose of volume mechanism is to solve the problem of container data persistence. PouchContainer currently supports three kinds of driver for local,tmpfs,ceph, and supports interfacing with more third-party storage in the form of volume plugin.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.