PouchContainer is Alibaba Group's open-source, efficient, lightweight, enterprise level rich-container engine technology with strong isolation, high portability and low resource consumption. It can help enterprises quickly implement the containerization of inventory services and improve the utilization of physical resources in ultra-large-scale data centers.
PouchContainer is derived from Alibaba's internal use cases. In the initial development stage, Alibaba engineers spared no effort to develop a container technology capable of safeguarding Internet applications. The engineers' devotion is evidenced by the creation of PouchContainer which features strong isolation and the rich container capabilities. PouchContainer is well tested and proven by its large-scale performance during Alibaba's Double 11 Shopping event. This Alibaba-developed container service is an inclusive technology designed to help enterprises quickly implement the containerization of their inventory services.
Alibaba had a huge volume of internal inventory services when it first came into contact with container technologies. One of the critical issues they faced was determining how to quickly containerize inventory services. Container technologies have gradually become more popular over several years of development. However, some enterprises with large inventory services are still trying to determine how to implement the containerization of their inventory services. In the cloud native field, the majority of the advanced ideas advocated by Cloud Native Computing Foundation (CNCF) are based on the containerization of services. If an enterprise falls behind in containerization of its cloud native services, it will have no way to implement subsequent open source technologies like container orchestration and Service Mesh.
Seven years of practical experience with the PouchContainer technology have proven to the industry that this rich container technology is the first choice for enterprises seeking to containerize their inventory services.
A rich container is a type of container used by enterprises to pack service applications and containerize their services. It allows IT staff in an enterprise to easily pack service applications. Using the rich container to pack service applications offers two following advantages:
From the technical perspective, the rich container provides an efficient way to help enterprises pack more content required for their services, instead of only service applications themselves, into one single container image, including O&M suites and system services. Additionally, compared to a simple single-process container, a rich container is significantly different in terms of process organization and structure—manager processes like systemd can be automatically run when the container runs. As a result, an application in a rich container can run in the same way as it would on a physical machine, without having to change any service code or O&M code. It is safe to say that the rich container is a more general application-oriented mode.
In other words, is capable of ensuring service delivery speed without intruding on development or O&M processes, which allows IT staff to focus their energy on service innovations.
Rich containers can find application in a wide variety of scenarios. It is safe to say that an enterprise can use a rich container as the preferred containerization mode for almost all of its inventory services. Before the prevalence of container technology, an enterprise's services were run in a bare metal environment or in VMs for nearly ten years. The steady operation of enterprises' services derives largely from O&M work, which specifically includes infrastructure O&M and service O&M. Running any application depends on physical resources, while the stability of all services relies on O&M systems such as monitoring systems and log services. Therefore, we have good reason to believe that enterprises shouldn't ignore O&M systems in the process of service containerization. Otherwise, critical and costly problems could occur.
The PouchContainer rich container technology is applicable to all scenarios where an enterprise needs to consider compatibility with its original O&M systems in the process of service containerization.
How does rich container technology enable a service to maintain compatibility with original O&M systems? The following diagram shows the inner-workings of rich container.
A rich container is 100% compatible with the OCI images common in the community. The container uses the image's file system as its rootfs at startup. As for running method and functionality, the container also include hook methods (prestart hook and poststop hook) which are run when the container starts or stops respectively.
The internal running process of the rich container in PouchContainer can be divided into four categories:
The most distinctive difference between the rich container and a traditional container is that the rich container internally runs an "init" process, while a traditional container (for example, a Docker container) uses the CMD specified in the container image as the pid=1 process in the container. PouchContainer's rich container can choose from three kinds of init processes:
It is well known that traditional containers, serving as an isolated running environment, have some disadvantages in the management of internal processes. For example, the failure to retrieve zombie processes causes containers to consume too many resources and additional memory. These containers' internal system service processes cannot be managed in a friendly way, leading to a lack of basic functions required for services, such as the cron and syslogd system services. Traditional containers fail to provide support for running some systems primarily because these systems need to call systemd to install the RPM package.
However, from the perspective of the O&M methodology, the init process in the rich container can resolve all of the aforementioned problems, providing a better application experience. The init process is designed to be able to wait for a killed process, easily solving the issue of Zombie processes as demonstrated by the above image. It can also manage system processes, which is one of its primary jobs. The init process handles the majority of the most basic and traditional O&M capabilities and lays a solid foundation for O&M systems.
The container image's CMD is traditionally the services that we want to run in containers. For example, when containerizing a service system in Golang and packing it into an image, a user will definitely specify the startup command for this service system as CMD in the Dockerfile to ensure that the service system will run using this CMD command when the container runs the image.
The container image's CMD represents the core applications and therefore is the core of the rich container. All O&M adaption is to ensure that service applications can run in a more stable manner.
Despite decades of development in server programming, many service system development methods are based on Linux on physical machines or in virtual environments. If things continue this way, the development method for many service applications will frequently interact with system services. For example, applications written In Java are very likely to use log4j to configure how logs are managed These applications can also redirect application logs to syslogd in the running environment by using the log4j.properties configuration.; If no syslogd is running in the running environment, it is very likely that the starting and running the services will be influenced. Consider another example: service applications need crond to manage the periodic tasks required by the services. If no crond daemon process exists in the running environment, service applications cannot configure periodic tasks using crontab. Let's consider a third example—the sshd service system in the container can help O&M engineers quickly enter the applications' running site to locate and solve problems.
PouchContainer's rich container takes into consideration applications that have numerous needs and system service delivery. The init process in the rich container is capable of comprehensively managing a variety of system service processes natively.
System services can help business operate as expected. However, this alone cannot meet an enterprise's needs in most scenarios. Enterprises also need to configure O&M components based on their infrastructure and applications. These O&M components can safeguard and support enterprise services. For example, an enterprise's O&M team needs to configure monitoring components for service applications in a unified manner. The O&M team must manage application logs in containers using their custom log agents. The O&M team must also define their basic O&M tools to make their applications' running environments compliant with internal audit requirements.
Because of the init process in the rich container, user-defined O&M components can run in a stable and healthy way as they did before, enabling smooth operations and maintenance.
The task processes running in the rich container can ensure stable and normal application runtime. However, O&M teams have a much wider range of responsibilities than only managing runtime. To put it simply, the responsibilities of O&M teams also include environment preparation before runtime and follow-up work after runtime. For applications, this involves what are commonly known as prestart hooks and poststop hooks.
PouchContainer's rich container mode allows users to conveniently specify the application's start and stop execution hooks: prestart hook and poststop hook. The prestart hook specified by the O&M team can help the application perform some initialization operations in the container that are compliant with O&M requirements before the application runs, including initializing network routing tables, getting the application's execution permissions, and downloading certificates required for runtime. The poststop hook that the O&M team specifies can help the application perform unified follow-up work when the application stops running or exits due to an exception, for example, cleaning intermediate data to provide a purified environment for the next startup. If the application exits due to an exception, the error will be immediately reported to meet O&M requirements.
As we can see, the start and stop hooks in the rich container increase O&M capability and considerably improve the ability of the O&M team to flexibly manage applications.
Tried and tested by the large volume of Alibaba's internal services, PouchContainer has helped ultra-large-scale Internet companies implement the containerization of all online services. Furthermore, rich container is undoubtedly the most useful container technology, with no intrusion into application development and O&M.
The open-source PouchContainer is expected to bring the industry huge benefits at a reasonably affordable cost. With this technology, Alibaba hopes to help many enterprises implement the containerization of their inventory services, save more time, quickly embrace cloud native technologies, and take a big stride towards digital transformation.
480 posts | 48 followers
FollowAlibaba Clouder - November 8, 2018
Amber Wang - August 6, 2018
Alibaba System Software - August 30, 2018
Alibaba System Software - August 14, 2018
Alibaba System Software - August 14, 2018
Alibaba System Software - September 3, 2018
480 posts | 48 followers
Follow
Alibaba Cloud Linux
Alibaba Cloud Linux is a free-to-use, native operating system that provides a stable, reliable, and high-performance environment for your applications.
Learn More
ACK One
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn More
Container Registry
A secure image hosting platform providing containerized image lifecycle management
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn MoreMore Posts by Alibaba Cloud Native Community
