您当前的位置是:  首页 > technology > Corporate communications > Abstracts >
当前位置:首页 > technology > Corporate communications > Abstracts > How to implement application deployment management across the cloud

How to implement application deployment management across the cloud

2018-05-15 09:48:12 Author: Source:CTI ForumComment:0  Click:


Today, cloud computing has been adopted by most companies for its flexibility, scalability, and ease of maintenance, and cloud management will become the next hotspot for enterprise cloud strategy. Cloud has many advantages, but also brings challenges, such as complex management. In a cloudy environment, users want to shield the complexity of the underlying resources and have a service platform that can uniformly manage various applications to reduce the complexity of operation and maintenance and management.
OpenPitrix is ​​a cloud-based application management system. The goal is to run Any Any at Any Scale on Any Infrastructure (any application can be deployed on any infrastructure at any scale). It can manage all types of applications in the enterprise, allowing users to Focus on the core business layer.
The content was compiled by Chi Lian QingCloud Application Platform Consultant Engineer Chi Lianyi at the 2018 QCon Global Software Development Conference Beijing station. (Text Total: 9087 Words 15 Figures, Estimated Reading Time: 23 minutes)
The following is the content of this sharing
Cloudy Multiple Runtime refers to the service application management platform of multiple cloud service providers. The difference from the general cloud management platform (CMP) is that the general cloud management platform is the basic resource for managing the cloud, which is what we commonly call IaaS. The management platform is a management application. These applications can be single-node, multi-node, multi-role, and nodes need to cooperate with resources such as network, load balancer, and storage. This is also known as PaaS.
Cloud deployment and management are trends
Why do we want to do a cloudy application management platform.
In January of this year, in an annual cloud status survey report published by the renowned cloud service provider RightScale, companies using cloudy management accounted for 81% of respondents. This fully shows that cloudiness is a major trend of cloud in the future.
There are many benefits of cloudiness. One important factor is that it can be prevented from being bound by a single cloud service provider. Hundreds of cloud service providers can hedge risks. Furthermore, each cloud service provider has its own advantages and disadvantages, such as some clouds. Strong storage capabilities, some cloud database products are more stable, and the use of cloudy can make full use of its superior products.
When using a single cloud architecture, you can use the mature management tools or management interfaces provided by the cloud provider directly. However, in a cloudy environment, users want to have a unified interface to manage multiple cloud services to reduce the need for transportation. The complexity of peacekeeping management.
The application is the closest to the demand, so a cloudy application management system has more market demand, so that the user can focus more on the core business layer. At the same time, enterprises may have various types of applications that need to be managed, including traditional applications such as databases, Tomcat, Hadoop, and applications based on microservices architectures, and the recent rapid development of Serverless applications. Companies need a one-stop management platform that can manage different types of applications.
As the saying goes, “how big the structure is and how big the achievements are,” and so is the project. Since we are doing a “cloudy application management platform,” our goal is to create an application market ecosystem where various corporate developers can Develop apps that they are good at, and provide online operation and maintenance and help conveniently. These developed apps are available for use by other corporate users. Developers can make profits. Users can skip manual build and maintenance processes and use off-the-shelf products. .
In order to achieve the ecological goal, the project was started from the beginning in an open source way, including discussions, design, and code were all completed on GitHub.
There is also a major reason why we started to develop applications on the cloud platform a few years ago. The first official version of the AppCenter was released in May 2015, and AppCenter 2.0 was released in early 2017, with the aim of giving developers the lowest The cost of learning is to deploy the application to the cloud platform for a few days. This platform provides cloud computing basic features such as application awareness, elastic scaling, and configuration changes. But also for developers to provide convenient management, logging, monitoring, finance, work orders and other functions, the end user in the application market is very convenient to find the various applications they need, through a key deployment to use.
Since the AppCenter platform was released in March of last year, it has gradually launched more than one hundred apps developed by developers from different companies, covering applications in various fields such as big data, AI, containers, and blockchain. However, AppCenter is only compatible with TsingCloud IaaS. Our private cloud users also have AppCenter requirements. However, private cloud generally has multiple cloud deployment environments. Therefore, customers have asked AppCenter to be compatible with other cloud vendors.
Cloud + Application + Open Source
This is the origin of the cloudy application management platform. The name we gave him was: OpenPitrix, a set of cloudy, application management, and open source projects. The origin of this name, Pitrix is ​​a collection of three words PaaS + IaaS + Matrix (matrix), this is actually the name of the project inside Albatron. We used it. Adding Open in front of it means that the project is open source and it also shows our open mind.
What OpenPitrix wants to achieve is Run any application at any scale on any infrastructure. That is, the OpenPitrix platform can deploy any type of application to any kind of infrastructure. For developers, Build Once, Run Anywhere.
There are 4 main functions that OpenPitrix can provide.
The first is the support of cloudy platforms.
The cloud platform can be AWS. OpenStack can be either VM-based or container-based. It can be a public cloud or a private cloud. For the platform provider, OpenPitrix will provide the corresponding ProviderPlugin plug-in to call the corresponding cloud platform provider's API to manage the applications running on it.
The second is multi-application support.
Various types of applications will support it. Many enterprises use traditional applications. They want to apply their applications to the cloud without changing their existing architecture, so these traditional applications need to be supported.
These traditional applications can be either typical three-tier architecture-based software or distributed software: the master-slave architecture of Hadoop, the Peer to Peer structure of ZooKeeper, and the patch architecture of Redis Cluster can all be used by OpenPitrix. Managed.
Microservice architecture is a big trend, so we will also support the application of microservice types. Microservice applications are often containerized. In terms of container organization, the open source project Kubernetes is already a de facto standard. Therefore, OpenPitrix will support Kubernetes. Helm is a very good Kubernetes package manager that provides features such as packaging and deployment. In the first release of OpenPitrix, we used Helm as a deployment tool for Kubernetes applications to provide deployment of microservice type applications.
We will also support Serverless applications, but at present, because there is not a unified standard for Severless applications, the first version will not be supported temporarily and will continue to focus on its development.
The third feature is highly extensible and pluggable.
Including both cloud platform support and application type support, no matter what new cloud service providers appear in the future or new application types, it can support it by adding corresponding plug-ins.
The fourth is commercial operation.
We maximize the decoupling of applications and applications running on the cloud environment, on the one hand to allow developers to easily develop applications, while the platform for its management and operation and maintenance, measurement and accounting, viewing reports and statistical information, applications can be placed in the public The market, or proprietary market, goes on sale. On the other hand, users can deploy the corresponding App on their own cloud operating environment. Any application based on OpenPitrix can be sold on any OpenPitrix-based application management platform.
OpenPitrix architecture
At the very beginning of its design, OpenPitrix decided to develop the microservices framework. Microservices have many advantages over single applications, such as reducing complexity, and can be independently developed, deployed, upgraded, and extended.
In OpenPitrix, we split out five microservices: Repo, App, Runtime, Cluster, Pilot.
  • App is a service that provides application development, registration, and other functions;
  • There are many App, App groups on Repo, similar to the concept of market.
  • Runtime is a specific cloud runtime environment, which can be a zone of a public cloud, or a zone of a private cloud.
  • The Cluster service is a service that manages the lifecycle of application instances deployed in a certain runtime, including creation, upgrade, expansion, and deletion.
  • Pilot This service provides the ability for OpenPitrix to deploy requests to an application instance in a Runtime request in both directions.
Each microservice has its own service process, has its own database, and a service database can not be directly accessed by other services, because each service is independently developed, this can ensure that the table structure modification of a single service will not affect other service.
The DBR of the persistence framework is chosen because the framework has no other dependencies and the code is simple and easy to maintain.
Database migration tools, selected Flyway, can build a database and table structure before sub-service startup, and can handle subsequent database migrations.
DashBoard and command line tool CLI are provided externally. External access is through the Restful API via the unified API Gateway. The Api Gateway forwards the request to a specific microservice through an internal route. The communication between each service belongs to internal communication. It is implemented through GRPC. GRPC is selected and Restful is not used because it is a binary protocol compared to Restful. The performance of the HTTP protocol is higher.
A uniform set of ETCD services will be used between each service. This service provides configuration updates, global locks, and message queues.
With microservice design, OpenPitrix can be easily containerized, deployed in container platforms such as Kubernetes, and enjoy the microservice management functions provided by Kubernetes, such as service discovery, monitoring, and load balancing.
Decouple applications and their running cloud environment
Look at the lower right corner. Runtime is the runtime environment of the cloud. There is a Provider attribute, which is the cloud provider. According to the Provider, you can use a specific ProviderPlugin to operate. Runtime can tag Labels.
Each App can be described using an application configuration package. The contents of this configuration package are described later. The application configuration package is located on the App Repo. The App Repo can be GitHub, or it can be an object store provided by a cloud service provider.
App Repo can also be tagged. For example, Sorftware = DataBase indicates that the App on this Repo is database-related, and App Repo has a Provider attribute. This is to mark the runtimes of the current Provider that the App on the current Repo can be deployed to. Selector is a property that can be retrieved for a Label of a Runtime.
For example, developers are developing a MySQL application. The state in development is not a stable version. The developer uploads the App to a second App Repo. Label is Sorftware = DataBase. The Provider property of this Repo is OpenStack and AWS has the same relationship with Key as or. Different Keys are related to and can be deployed in the Runtime of these two providers. Selector is Env=Developing.
At this time, if the end user wants to deploy the App, the system will automatically select available Runtimes based on the Provider information and the Repo Selector and Runtime labels of the application. In the right Runtimes, only the last one meets the condition and can be deployed. App.
Repo subservice
After reviewing the overall architecture, the next section focuses on the architecture of several subservices.
Repo subservices are loosely coupled and are divided into three components: Repo Manager, Repo Indexer, and App Repo.
The middle part of the figure is the App Repo, which can be either Google's Storage or QingCloud's QingStor® object storage. The above is a single application configuration package.
On the left is the Repo Manager, which is responsible for the addition, deletion, and review functions of Repo. It has its own database, records information such as the address stored by Repo, credentials used for login, and visibility, and can be public, private, or a specific user group. Share within.
The right-most Repo Indexer periodically scans the registered Repos and discovers any updates to the configuration packages on the Repo, and synchronizes the App information to the App subservices.
We can see that Repo's storage is independent of the OpenPitrix platform, so the applications stored in the warehouse can be shared and used by any OpenPitrix-based application management platform.
App Subservice
The App subservice controls the life cycle of an application and a specific version of an application. Here, we divide the application version into multiple states. The state switch will trigger the corresponding API. OpenPitrix has full lifecycle management of applications.
Only the App whose Repo visibility is Public must be reviewed by the administrator. This also ensures that the apps used by end users are all available apps.
Cluster & Pilot Subservice
Next, we will introduce the architecture of the Cluster subservice and the Pilot subservice, which is the core of the OpenPitrix architecture and the most complex one.
Before looking at the implementation and architecture, let's look at a few issues that need to be addressed during deployment and the solutions we use to answer why we designed the Cluster subservice and the Pilot subservice.
The first issue is the specification issue. How well identify an application, for example, to develop Kubernetes application to learn the writing format of his Yaml file, OpenPitrix let developers develop applications on this platform, and also need a set of Easy to learn standard.
We are using the well-defined application development model on the Qingyun App Center. This is a standard configuration package directory structure. It is a WordPress application with these fixed-name configuration files. The suffix name identifies the file type:
  • Package.json records some application metadata, such as Version information, Description information, developer information, icon information, etc.
  • Cluster.json.tmpl defines the specific application architecture, lifecycle management, monitoring alarms and other information, that is, this application contains which roles, each role in the start of what commands need to be executed, what commands are executed when closed, how to monitor the application instance Health status and other information;
  • Config.json defines some information that users need to fill in and select when deploying an application instance, such as CPU, Memory, and the application's own environment variables.
  • There are also some Option files, such as License, Readme, and language packs.
The first three files are files that an application configuration package must have, and the last three are optional. Of these, cluster.json.tmpl and config.json are particularly closely related to the application. The definition may seem long, but it is very easy to understand.
The above example of a config.json records the resource definition of the role of MySQL in this app. The CPU Default is 1, which is the default is 1 core, Range defines its optional configuration, it can be 1 core, 2 cores , 4 cores, 8 cores, 16 cores.
The default value of Memory is 2048, which is 2G. Range defines the optional configuration of Memory. When the user creates an instance of this application, DashBoard renders the page according to the definition in config.json, which is the screenshot on the right. It allows the user to select the type of application instance he wants to create based on the configuration provided by the developer.
The above figure is an example of cluster.json.tmpl. The double curly braces are the values ​​referenced from config.json. When a key is created, the default value of the variable in config.json is used, of course, if the user creates it. The command line or DashBoard changes the value of the variable, then renders and creates the new value.
This defines the application has a role called ZK, this role is created using Docker's Image, the following Service section describes the application creation, deletion and other life cycle instructions need to be executed, such as the definition of the creation of Executed Init and Start instructions.
The developer completes the development of the application by simply configuring the package definition, which can be deployed and used by users of different cloud platforms through OpenPitrix.
The second question: How does a developer's application image be distributed to a cloudy environment?
In fact, the application of the container class does a good job in image distribution. There can be a unified container image repository, and when it starts, it goes to the warehouse Pull Image, so the microservice application application does not have the problem of image distribution.
Traditional applications are usually deployed in virtual machines. When traditional applications are deployed in a cloud, they face the problem of image distribution. Developers define the image ID in the application package and how to distribute it to a cloudy environment.
We know that every public cloud will have a lot of Regions and Zones. If you let developers upload or create images in each of them, it is a very difficult task. To solve this problem, we have many solutions, but It's not yet mature.
For example, let the developer write the script of VM Image's production process, need some software packages, and download it from the public network. This way, when the user creates the application instance for the first time, the OpenPitrix platform will automatically create this Image and then will Image migrates to other Zones and shares it with users to make sure they can launch applications.
In the first version of the traditional application, we will first use the VM to run the Docker to solve the image distribution problem.
The third question, how to operate the cloud host to execute commands is a network problem.
OpenPitrix itself can be deployed anywhere. The applications that end users want to deploy are IaaS resources that run on various cloud environments. How do they communicate with each other and send instructions?
Our solution is through the public Internet, that is, the two through the public network, the current cloud platform host resources are generally run in a proprietary network, which is located below the VPC, our OpenPitrix will also The application instance is deployed to the VPC by default. The specific solution is to define 3 components in the OpenPitrix framework and the application instance host under the VPC: Pilot, Frontgate, and Drone.
The meaning of the Pilot Pilot is a service used by OpenPitrix when deploying a VM type application. The role is to issue commands to the instance of the Runtime that is deployed in a specific cloud service provided by a provider.
Drone, drone, is running on the host where the application is located. This component is composed of Agent and Confd. Confd is an open source project that can automatically complete the update of the App service configuration file and trigger specific changes when the configuration changes. The operation. The Agent is responsible for accepting the instructions sent by the OpenPitrix framework and reporting the execution status of the instructions.
Pilot can't directly send instructions to Drone, because one is on OpenPitrix and the other is on a specific Runtime. The environment is different and there is no direct communication, so we need a Proxy to forward the request. This function is provided by Frontgate.
In Frontgate, literal translation is the front door, that is, the outermost door. There is a Frontgate in the VPC with application running. All application clusters in the VPC share the Frontgate.
This component contains Proxy and ETCD. Proxy functions as a relay function. When the Frontgate host is created, it will write the address of the Pilot. When the Frontgate is started, it can establish a bidirectional Grpc Stream with the Pilot. After this connection is established, the two components are Can communicate freely.
The back Pilot can issue commands to Frontgate. Frontgate and Drone are in the same VPC and belong to the intranet. They can send requests to Drone and execute them. The execution result can also be reported to Pilot via Frontgate.
The ETCD in Frontgate stores the meta data information of the application deployment instance. The Confd in Drone also implements service discovery and automatic configuration changes through the Watch ETCD.
It is necessary to say here that since Pilot is just a service that issues commands, it is isolated from the Cluster for flexible extensibility. The amount of hosts in the Pilot Cloud-based VM Based Runtime will increase.
In the first version, we did not consider the layout of a cloud application, such as a Kafka on AWS and a ZooKeeper deployed on OpenStack. However, since Pilot can interact with any of the Runtimes, we can use the Pilot to do the layout of cloudy applications.
Now suppose that a user wants to deploy an application on OpenPitrix. He chooses the application, selects Runtime, fills in the resource information and environment variables necessary for the application, and clicks Create. How does OpenPitrix work?
First, send the API to the API Gateway, which will forward it to the Cluster subservice;
Then, after receiving the request, the Cluster subservice first parses the configuration package, registers the database information of the Cluster, and then encapsulates the request as a JOB, and puts it into the JOB message queue to wait for scheduling execution, and the JOB Controller will asynchronously resolve the JOB. Divided into multiple layers of Task, each layer of Task can be executed in parallel, multi-layer Task is dependent on the need to perform the order, this will be a JOB parsed into the Task's workflow, Task Controller can be scheduled to run Task, guarantee the order of dependencies.
Second, the Task is executed according to the Provider Plugin of the current Runtime Provider. There are several types of Task:
One is to call the API of the cloud service to perform the operations of RunInstance and CreateVolume. If it is the application of the container class, Task will send the request to the Server of Helm, and Tiller will execute it. This will be introduced later.
If it is a VM-based application, some Tasks need to be delivered to Drone via the Pilot. These task dependent Tasks will complete the pre-order work.
That is, create a Frontgate and establish a two-way Grpc Stream connection with Pilot. Through the interaction between them, the metadata registration that follows the creation step is completed, the Confd service is started, and the developer-defined Init and Start instructions are executed.
OpenPitrix also supports container type applications. The first version of the K8S Provider Plugin was implemented by the Helm Client, and the container application was deployed to the Kubernetes cluster through Helm.
At present, Helm's server Tiller only supports deploying instances of Chart to a single Kubernetes. Therefore, Tiller needs to be installed in the Runtime of Kubernetes.
OpenPitrix application practice
Just introduced OpenPitrix's features and technical architecture, then look at the main application of OpenPitrix.
Since the OpenPitrix Runtime can be either a public cloud or a private cloud, the most common scenario is to provide a one-stop application management platform for enterprises adopting a cloud or hybrid cloud system so that employees can Care about the IaaS layer, use the application directly, and use only one set of management interfaces.
Another is some cloud management platform, only the management of cloudy IaaS resources, which can be integrated into OpenPitrix, thereby increasing the cloudy application management capabilities.
The third is that OpenPitrix can be used as an application management system for Kubernetes.
OpenPitrix and Helm are fundamentally different. Although OpenPitrix uses Helm to deploy Kubernetes applications at the bottom, OpenPitrix focuses on the application's life cycle management. For example, in the enterprise, it is usually classified according to the state of the application, such as development, testing, Preview, production, etc., as well as application market management functions, which Helm does not have.
Future development of OpenPitrix
The OpenPitrix project was launched in August of last year and completed the design and discussion of various modules and started development on February 24 this year. At present, most of the functions of the first version have been completed. We are now on the official website:
Openpitrix.io
Hope that interested friends join us to jointly build the ecology of this cloudy application management platform. In the future, OpenPitrix hopes to gradually develop a comprehensive solution for application management systems in a cloudy environment.
 
[Disclaimer] This article only represents the author's own opinion and has nothing to do with the CTI Forum. The CTI Forum maintains its neutrality in the presentation of statements and opinions, and does not provide any express or implied warranty for the accuracy, reliability or completeness of the contents contained therein. Readers are for reference only, and please bear full responsibility for yourself.

Topics