Shulou(Shulou.com)05/31 Report--

This article will explain in detail the example analysis of open source PaaS Rainbond architecture and implementation. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Reviewing the development of cloud computing industry technology, the gradual maturity of IaaS layer virtualization has solved the coupling problem between resource providers and users faced by physical computing clusters in the past, and reduced the threshold for delivering applications and creating business value to a certain extent, but it is not so good in terms of technical difficulties in development and operation and maintenance.

Subsequently, the container technology represented by Docker and Kubernetes is becoming more and more popular, which paves the way for the creation and delivery of large-scale business systems. However, container management alone is not enough to achieve our vision of enterprise IT-just focus on the business, without spending a lot of time and effort on the underlying technology and infrastructure.

Therefore, we put forward the concept of "application management", which focuses on the application and presents two product services: serverless PaaS and cloud native SaaS.

The value of applied management

For most enterprise IT, business value comes from two scenarios: creating applications and using applications. The traditional operation mode of the business system requires the enterprise IT to build the running environment and consider some basic setting management problems such as network, storage, configuration, load balancing, security and so on. These tasks are repeated every time the system is built, which takes up a lot of enterprise IT costs.

By adding the application management layer (serverless PaaS/ cloud native SaaS) between applications and computing resources to achieve decoupling, developers and users only focus on business logic design, coding, testing, launch and other business directly related work, and the complex work between source code and cloud operation is left to the application management layer to complete automatically.

From another point of view, developers and users will not have to face the complexity of the management of the underlying computing resources, relieving the development of the dependence on operation and maintenance, while the operation and maintenance personnel only need to maintain the stability of the resource pool on the basis of platform automated resource management. When the responsibility between the development and operation and maintenance is clear and the boundary is clear, the DevOps workflow is also naturally landed.

Service model of application management

Application management is the core design idea of Rainbond, including north-oriented application abstract management and south-oriented computing resource management.

The two-tier application abstract model is suitable for most enterprise IT systems and basic applications, including Internet applications, industry applications, physical network applications and big data technology applications and so on.

On this basis, the support for micro-service architecture, including out-of-the-box Service Mesh, plug-in governance function extension, compatibility with mainstream micro-service architectures such as spring cloud, api gateway, dubbo, can realize the large-scale integration of multi-type single applications, new and old applications, and supporting standards and complete functional features.

Of course, different applications may have different advanced requirements, such as Mysql hot backup, firewall for external network access applications, and so on. Rainbond correspondingly designs the application plug-in system to expand the application functions differently and non-invasively.

In terms of computing resource management, Rainbond uniformly pools different computing resources and provides standard computing services through software-defined infrastructure settings. Public cloud computing resources, IDC vendors, and enterprise private x86-64 architecture computing resources are all accessed as Rainbond data centers.

In summary, the service model of Rainbond can be described as that users run any application on any computing resource, combine it flexibly on demand, and provide it to end users in the form of SaaS services.

Application-centered product design

Rainbond's application-centric (app-centric) product design philosophy is embodied in:

In the application production phase, Rainbond supports the construction of production applications from various types of software sources, including various programming language source codes, container images, DockerCompose files, etc., and defines the application level elements in the form of a production line-- input code, output application

In the application running phase, Rainbond manages storage, network, computing and other resources in a software-defined way, and runs App-Runtime on this basis to provide unified and rich services for applications and build a high-performance architecture.

In the application propagation phase, Rainbond is built and used everywhere as a delivery bridge to realize the application. Even if it is a micro-service architecture service containing hundreds of independent applications, enterprises can also deliver it to end users through Rainbond for one-click deployment.

Rainbond hopes to use products as a link to build a complementary whole composed of all users-in the interconnected application management ecosystem, some people create applications, some people exert the maximum value of applications, and others provide great resource guarantee for applications.

Technical Architecture of Rainbond

Rainbond is a complete PaaS platform solution, including a data center technology architecture composed of application control, application runtime and cluster control, as well as a best policy application console and resource console across data centers.

Key components include:

Chaos (application build / CI)

Worker (Application deployment / CD)

Entrance (load balancing / LB)

Eventlog (log processing)

Webcli (Container Control)

Monitor (cluster monitoring)

Node (Cluster Node Management and Service Mesh)

MQ (message)

App-UI

Resource-UI

Grctl (command line tool)

Chaos (application build / CI)

Rainbond Application Building (CI) component-Chaos is mainly used to process input media (source code, Docker image) and generate Rainbond application abstract media.

The traditional complete CI process includes: design, coding, packaging, testing, Release. With Docker gradually becoming a new form of application code packaging, and the maturity of existing CI products such as Jenkins and Gitlab in source code testing and Pipline, Rainbond implements the pre-processing of source code or Docker image, which can be directly connected to third-party services, which complete source code or mirror processing by third-party services, and then abstract the application of Rainbond-Chaos modules.

Chaos supports Git protocol code repository and Docker image repository. For the source code, Chaos intelligently judges the source code types, such as Java, PHP, Python, Dockerfile, etc., and selects the corresponding BuildingPack to compile the source code according to different source code types. At the same time, it identifies the parameters such as ports and environment variables defined in the source code to form an abstract configuration prototype. The source code types other than Dockerfile will be compiled into application code environment package (SLUG) and stored in distributed storage, while other source code will generate Docker local image and stored in the image warehouse in the data center, combined with all kinds of attribute information of the application to form the application abstract package.

For BuildingPack compiled by source code, please refer to the supporting documentation for each language.

The Chaos component supports multipoint high availability deployment, which acquires application construction tasks from MQ.

Worker (Application deployment / CD)

Application deployment (CD) component-Worker instantiates the abstraction of the application built by Chaos, configures all kinds of resources needed for the application to run, and completes the running part of the application life cycle (start-stop, upgrade, rollback, etc.).

Different types of applications require different control strategies, for example, stateless applications can carry out unordered rolling upgrades, while the upgrade control strategies of stateful applications will be more complex.

Application operation needs the support of various external environments, such as allocation of network resources (tenant IP, ports, etc.), application allocation of persistent storage resources, allocation of storage directories and block storage based on various plug-ins, establishment of service discovery according to application dependency attributes and provision of mesh plug-ins by load balancing strategy, etc.

The scheduling policy generated according to the application attributes is scheduled to run by calling the Kubernetes cluster. Currently, Rainbond involves Kubernetes resource types such as ReplicationController, Deployment, Statefulset, Service, Pod and so on. However, for Rainbond users, there is no need to understand these concepts, these concepts in Rainbond products only as a carrier to run applications, there is no complexity in the use of these concepts.

The function of Worker component is divided into stateful part and stateless part. In order to realize the cluster deployment of worker components, worker elects the master node, and the service of the elected master node will start an additional gRPC service to provide data services such as application status.

Entrance (load balancing / LB)

The load balancing (LB) component, Entrance, is a key component of a running application.

When the Rainbond application runs, each tenant is assigned a subnet, and the network between the tenants is isolated, so the applications running in the cluster cannot be directly accessed through the external network, and the IP address changes each time the application starts, and there is no direct access between the application and the application within the tenant.

Therefore, Rainbond designs the service control at the application port level, which has two service levels: internal service and external service. Open the corresponding service level, and the application runtime will generate the corresponding service discovery policy and load balancing policy.

The direct internal access of the application and the application is completed by ServiceMesh, while the load balancing of external access of the application. Because different applications provide services of different protocols (http, mysql, mongo, websocket, etc.), and existing load balancers (nginx, haproxy, etc.) have different support for different protocols, Rainbond is designed in addition to layer 4 protocol support to implement the application-level load balancer selection.

The Entrance module needs to connect different load balancers. Aiming at this abstraction of resources such as pools, nodes and router rules, different adapter adapts to different load balancers. According to the state changes and online policies of the application runtime and the application in the cluster, the load balancer is operated in real time to achieve application-level LB.

Entrance cluster deployment achieves global resource consistency through etcd, preventing repeated operations on the same resource.

Eventlog (log processing)

Rainbond needs to deal with log and message information such as user asynchronous operation log, application build log, application run log and so on.

For the operation log, the final state of each operation needs to be tracked distributed, which is judged by the Eventlog component according to the log aggregation of each operation. Other components send process log records to the eventlog cluster through the gRPC message flow while processing asynchronous tasks.

Rainbond recommends that there are two types of application logs: system logs from standard output and error output and business logs (access logs) output to persistent files.

For the standard output logs, Rainbond customizes the docker log processing driver plug-in, which is based on TCP data flow communication to send the container logs of all computing nodes to Eventlog components in real time according to the aggregation of application level, so as to store and push to UI in real time.

With the larger the size of the cluster, the more applications are running, and the amount of log processing is very large, so we have implemented the Eventlog cluster, and the logs of each application will be sent to the eventlog service node before transmission, similar to data partition. Balanced allocation has been done in the selection process. For example, there are currently 10000 applications and 3 eventlog service nodes, so that each eventlog node will handle about 3000 application logs respectively.

It is generally necessary to automatically analyze the business logs output to the persistent directory (for example, interfacing with the ELK system), so install the log processing plug-in in the plug-in system, collect the log files from the persistent directory and send them to the third-party log analysis service.

Due to the need of various real-time push, the eventlog component implements the websockt service.

Webcli (Container Control)

In order to facilitate users to enter the container space for command line operation, Rainbond provides Webcli components. Through websocket communication with UI, users can simulate Web terminals to send all kinds of shell commands.

Webcli executes the command in the container through the exec mode provided by kubernets and returns the result to the Web terminal.

Webcli is a stateless component that naturally supports multipoint and highly available deployments.

Monitor (cluster monitoring)

Rainbond includes multi-dimensional monitoring, such as application business performance level, application container resource level, cluster node level, management service level and so on.

The cluster monitoring component Monitor is packaged on the basis of monitoring alarm project Prometheus, which can automatically find all kinds of monitoring objects described above and complete the configuration, and bring all the above monitoring targets into the scope of Prometheus monitoring. Each component of Rainbond also realizes the exporter end exposure monitoring index of Prometheus.

Prometheus itself has a single point of performance handicap. When there are a large number of monitoring targets for a single node service, memory usage and disk usage will become very large. In order to solve this problem, the Monitor component establishes a cluster query mechanism on top of prometheus and realizes the multi-point data partition operation of Prometheus.

In terms of alarm, Monitor can automatically configure some default alarm rules (custom alarm rules are supported in the background of resource management), and will also support command line control in the future.

In actual operation, Prometheus will send alarm messages to Monitor, and send mail, Wechat and internal alarm letters to users according to the level after completing the operations such as de-duplicating and ignoring.

Node (Cluster Node Management and Service Mesh)

Node is the basic component of the Rainbond cluster and runs on all nodes. When Node runs on the management node, it will have the role of master to maintain the status and health check of all nodes.

In terms of monitoring, Node exposes all kinds of indicators at the operating system level of nodes (integrated promethes node-exporter), and regularly checks all kinds of service status and network status running on nodes with different attributes. Node will try to solve the monitoring problems automatically, which is one of the sources of cluster automation operation and maintenance capabilities.

The Node services run by all computing nodes work together to form the running environment support for running applications in the tenant network, especially ServiceMesh support.

Node provides global configuration discovery support for envoy. The envoy plug-in bound to the application jumps out of the tenant network through the host network and accesses the Node service to obtain global service network governance configuration information. Other application plug-ins can dynamically obtain configuration and application running information from node services through the same mechanism.

MQ (message)

Considering that the design of message middleware which can provide distributed message consistency is very heavy, Rainbond does not choose to use the existing message middleware service, and implements lightweight distributed, message persistence and consistent message middleware MQ based on etcd, which is used to maintain asynchronous task messages, provide publish and subscribe capabilities of multiple topics, and provide gRPC and http interfaces to implement pub/sub.

Guaranteed execution of asynchronous message tasks is the next iterative direction for MQ components

App-UI

The UI component of the application console is the key module of Rainbond application-centered abstraction. Based on the Django+Ant design front-end separation architecture design, the application console component provides interactive experience for application abstraction, application group abstraction, data center abstraction and application market abstraction. At present, App-UI components implement a complete process of application creation, management, application delivery and sharing.

Resource-UI

Resource-UI (Resource console UI) components are designed for operation and maintenance personnel, providing Rainbond cluster resource management, focusing on node physical resources, cluster resources, management service resources, application actual use resources, tenant resources and other management, which is the key platform for Rainbond automated operation and maintenance capabilities. Resource-UI currently belongs to the Rainbond Enterprise Edition function module, and it is planned to support the resource management capability of interfacing IaaS in the future.

Grctl (command line tool)

Grctl command line tools provide some interesting and practical application management functions and cluster operation and maintenance functions, which are convenient for open source users to carry out cluster management and operation and maintenance without ResourceUI.

About Rainbond

Rainbond is an application-centric open source PaaS, independently developed by Haoyu based on Docker, Kubernetes and other container technologies. It can be used as an application delivery platform, DevOps platform, automated operation and maintenance platform and industry cloud platform in public or private cloud environments, or as an enterprise-level hybrid cloud management tool, Kubernetes container management tool or Service Mesh micro services architecture governance tool.

This is the end of the sample analysis on the open source PaaS Rainbond architecture and implementation. I hope the above content can be of some help and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.