Recently, the EXPLORATION and Development Dream Cloud (E&P Cloud) platform V1.0 of CNPC’s independent intellectual property rights was released in Beijing. As the only container PaaS supporting the landing of Dream Cloud and the partner in the field of cloud native technology, With strong technical strength and excellent service capacity, Linchback assisted CNPC Ruifei to participate deeply in the construction of Dream Cloud PaaS platform.
At the annual open source technology event KubeCon+CloudNativeCon held not long ago, Chen Kai, CTO of Linqiyun and Chi Hui, senior architect of CNPC Refei, delivered a speech themed “Big Oil on Kubernetes and DevOps”. The exploration and development dream cloud platform project is described.
The speech was divided into three parts: First, Chen Kai introduced the background of the project; Secondly, Chi Hui introduces the design ideas and schemes of the unified technology platform based on advanced technologies and concepts such as Kubernetes, microservices and DevOps. Finally, back to the products and technologies, Chen Kai introduced how Linquyun assisted CNPC Ruifei to successfully implement the cloud native technology. The following is a transcript of the speech:
Hello, everyone. I am Chen Kai, CTO of Linqiyun. Today, I would like to share with you the case of linqiyun building enterprise-level PaaS platform for the largest energy enterprise in China. It is my great honor to invite Chi Hui, who is in charge of DevOps in CNPC Ruifei, to share with you how CNPC landed in Kubernetes and DevOps.
For an enterprise with the size of CNPC, you can imagine the complexity of its business environment and the enormity of its scale. Complex business segments face many challenges, such as a dozen fields without a unified plan, each running its own IT system, so the data is scattered all over the place, there is no way to connect and share, so you can’t really use the data. From the perspective of platform level, each oilfield will not be a unified IT platform, so IT is difficult to provide unified support for the above businesses.
The e&P Dream Cloud, which Linqiyun helps CNPC Ruifei to build, is a response to these challenges. At the bottom level, we will establish a unified database to get through all kinds of data scattered in each oil field and gather them together to manage the data. In the middle is the unified technology platform, which is the Kubernetes-based PaaS platform we mainly talk about today, which mainly covers three scenarios: container, DevOps and microservice governance, which are the three core elements of the whole cloud native.
The ultimate goal of the project is to establish a unified data lake and a unified technology platform on which to solve the general business of the entire CNPC.
Now let’s welcome Chi Hui from CNPC Ruifei to introduce the technology and overall construction ideas and plans of CNPC project.
CNPC Rui Fei Chi Hui:
The DevOps platform of petrochina mainly consists of three modules, the first module is DevOps, the second module is microservices, and the third module is container platform.
We divide DevOps into eight systems, namely, project management, knowledge sharing, continuous construction and testing, continuous delivery, certification and improvement, learning and training, operational statistics, and operational monitoring.
In the whole tool chain support system, there are 15 tools involved, most of which are open source.
Here are some achievements of the platform construction. In the process of doing this project, 14 roles, 8 responsibilities and 5 rights groups were formed. On the right side are all the certification systems. In this certification system, we have prepared 6 test scenarios and 4 courseware. After receiving new projects, we will conduct targeted training for them and finally assess their maturity.
Chen Kai:
Let’s go back to the product and technical level and discuss how DevOps can be built for CNPC’s complex business scenarios using Lingquyun’s platform.
Let’s take a brief look at the products of Linchpin Cloud. Linchpin has two main product lines. One is the Alauda Container Platform(ACP), which is a highly standardized enabling Platform focused on cloud native application management scenarios. It covers three scenarios, namely Container Platform, DevOps and microservices, which are also the three cores of our cloud native technology.
Another product line is Alauda Cloud Enterprise (ACE), which is aimed at a unified PaaS platform for large enterprises. The petrochina platform I just shared is very much in line with this scenario.
ACE itself contains all the capabilities of ACP, on top of which there are some enhancements to the ability to build unified PaaS platform scenarios for large enterprises. To cite a few examples, ACE’s customers often have complex infrastructure environments, often with multiple data centers. When some customers start experimenting with public clouds, they end up with a heterogeneous, hybrid, cross-cloud infrastructure rather than just one product or service. We set up multiple K8s clusters in each data center, or each public cloud vendor, according to its usage needs. That is, managing these heterogeneous, complex infrastructures and supporting multiple clusters is the core capability of ACE.
In terms of cluster management, not only can we use ACE to deploy a Lark provided K8s cluster (also known as ACP), we can also let users import a K8s cluster they already have, and we already have some practice in this area.
Another scenario for a large enterprise to unify the PaaS platform is a common requirement within the enterprise. Generally speaking, there are several categories of functional users in an enterprise. The platform department that we directly cooperate with is the cloud platform provider and service Team for the business department within the enterprise.
On top of this, the typical USE scenario for ACE is usually several thousand developers or more. They also need to be divided into different tenants according to different projects or departments. There are requirements for intra-team collaboration among tenants, and there are some authority isolation and resource isolation among tenants, which is another problem that ACE needs to solve.
Back to today’s topic, DevOps. DevOps is a core module of ACE. When we talked to enterprise customers about DevOps, each of them was already using some tools and had their own processes. We need to improve the existing system rather than provide a closed product to replace the tools used before.
So the ACE enterprise overall train of thought, is to provide an open conversation tool chain integration and scheduling platform, through the integration of customers have been using before, and need the new tools into a tool chain, and then by orchestrating these tools and platforms into a whole, finally can be applied throughout the whole life cycle management. The core value of ACE is to extract DevOps best practices into an automated platform service that can be delivered to users.
DevOps toolchain integration requires, on the one hand, that each tool be integrated with our container platform through the API, and, on the other hand, that user rights for each tool and platform need to be unblocked. Every enterprise-level tool has its own tenant model, which needs to interact and correspond with the tenant model of the platform itself. So that the thousands of engineers on the platform, sharing these tools across different projects, will have certain specifications. In ACE, some of the main tools for core scenarios, we will do deep integration. In this case, more than 80% of the usage scenarios can be done on the platform itself.
As mentioned just now, ACE is used to build a unified PaaS platform in large enterprises, which is divided into two types of users: one is the platform department, responsible for building and maintaining the platform and providing support and services to other business departments, and he is the platform administrator; The other is the business department, which can be understood as some projects within the enterprise, namely the tenants on the platform. In terms of usage, the general process is as follows: the platform department prepares the infrastructure, needs to deploy and prepare some existing clusters, and then creates tenants on the platform and sets up an administrator who can distribute the resources of the cluster to tenants. After obtaining resources, the tenant administrator can create an environment in the cluster and allocate resources to the lower level.
For DevOps implementations, administrators can deploy and integrate tools, which can then be published for tenants to subscribe to. It can also create resources for each tool and proactively assign those resources to tenants. There are three ways to get resources for DevOps tools from root administrators: they are actively assigned by administrators, developers subscribe to libraries published by administrators, or developers can deploy a tool on the platform themselves.
Due to the lack of time, I would like to share with you here today. If you want to know more about the product practice of Ringsparrow cloud in various industries, you can communicate with us after the meeting. Thank you!