Ultimate doll 2.0 | cloud native delivery package

I always like some metaphors , In this way, we can understand things more vividly .

Erda It's a PaaS platform , The underlying technologies have been used from marathon + mesos Switch to the current K8s, They are generally considered to be “ Container layer ”.Erda stay “ Container layer ” It's stacked again CI/CD Pipeline、 Cluster and deployment management 、 Application monitoring 、 Automated testing and so on , The embodiment of such layering is very similar to the layering of the network , Each layer performs its own functions , But I prefer to compare it to 「 programing language 」.

Encapsulation is to reduce “ error ”

A high-level programming language has a grammar that is more in line with human understanding , It runs by compiling into assembly or machine code , Or compile it into a low-level language and then compile it again .

A similar ,Erda Through to “ Container layer ” Encapsulation , For our users, it presents “Erda idea ” Function design and use experience . And so called The most important thing about encapsulation is to reduce artificial “ error ”, It's like high-level languages through restricted and elegant syntax 、 Intelligent compilation tips and rich class libraries , Greatly reduce the mental burden of developers , You can easily write robust code . And the programming method above it 、 Best practices , Provide theoretical support for high-speed delivery .

What is a product

Erda Your body bones are made of 「 application 」 For the center , hypothesis Erda If there is only one function left , That is the application “ deliver ”.

Delivery can be very simple , I call it **“ Two steps ”**：

1. Compile the code into an application installation package
2. Install the application in the environment required by the customer

The actual situation will be a little complicated , But it will not change the core steps , It's probably a matter of taking more steps .

If you want to pursue the details , These two steps can be carried out all the way down .Erda The thing to do is to keep users from delving into these details , Just like we don't need to know the encoding when watching video on a personal computer 、 The process of transmission and decoding , There is no need to know the difference between damage and damage .

Of course , Making such a metaphor does not mean Erda Deliberately prevent users from conducting in-depth exploration , On the contrary, if you understand the underlying principles , Better understanding of Erda Understanding of functional design ！

To be specific ,Erda Standardizes what can be delivered on the cloud “ Software installation package ” Format , Such an installation package is called **“Erda products ”**（ Hereinafter referred to as “ products ”）, Let's briefly list the characteristics of the products , In this way, we can have a general impression ：

1. The product is right docker Further abstraction of the image , similar docker-compose.yml, Covers multiple mirrors （ service ） General description of , And the dependencies between them
2. Artifacts are statements of the application delivery environment （ structured 、 Software installation and deployment instructions that can be recognized by the system ）, Not only declare the resource limit of each image service , You can also declare the required middleware （ such as mysql）

It needs to be added , because Erda It is a multi application architecture （ The main library of the core erda、 The front-end application erda-ui、 Monitoring related telegraf、fluentbit etc. ）, therefore Erda When delivering, multiple applications are delivered together , We call it the project artifact . Project artifacts include multiple application artifacts and support batch deployment and other features .

This is a Erda Own products （ Project products ）：

Erda Project artifacts Multiple application artifacts are included by grouping （erda、erda-ui etc. ）

Manufactured Addons details among rds and MySQL They can replace each other

Let's focus on Erda Inside the product of the main application , That is, grouping Group 3 Medium erda Application products of the main library .

because Erda The main application is micro service architecture （ Multi service ）, So we can see a list of microservice containers ：

If the application has multiple services Every service has docker image

And the core ​​dice.yml​​：

Log in and copy

      
      

       
       version: "2.0"
       
       

       
       
envs:
       
       
  ETCDCTL_API: "3"
       
       

       
       
services:
       
       
  cluster-agent:
       
       
    cmd: /app/cluster-agent
       
       
    deployments:
       
       
      replicas: 1
       
       
    envs:
       
       
      DEBUG: "false"
       
       
    resources:
       
       
      cpu: ${request_cpu:1}
       
       
      max_cpu: 1
       
       
      max_mem: 1024
       
       
      mem: ${request_mem:1024}
       
       

       
       
addons:
       
       
  mysql:
       
       
    plan: mysql:basic
      
      
      
      

       
       
1.
       
       
2.
       
       
3.
       
       
4.
       
       
5.
       
       
6.
       
       
7.
       
       
8.
       
       
9.
       
       
10.
       
       
11.
       
       
12.
       
       
13.
       
       
14.
       
       
15.
       
       
16.
       
       
17.
       
       
18.
       
       
19.
       
       
20.
       
       
21.
      
      

For convenience of reading, we only list the key information , If you need to see the complete ​​dice.yml​​, Can be found in open source code ：​ ​https://github.com/erda-project/erda/blob/master/erda.yml​​

In this case （ That is to say Erda Own application products ）, You can fully feel Erda How will “ Software delivery ” Encapsulated .

Thanks to the docker Yes “ execution environment ” Encapsulation , And then put it together ​​dice.yml​​ On the service / Multi application integration “ Delivery environment ” Encapsulation （ The number of instances 、 environment variable 、 resource consumption 、 Middleware dependency ）, We can say with confidence ：“ Developers only need to care about what they need to know , The platform is responsible for others ”.

Delivery of products

Although I have just introduced the context of the product , We still want to review the key components of the product ：

1. Image list （docker images）
2. ​​dice.yml​​ Each service is declared （ The image list corresponds to ） Resources required for deployment , And the required middleware

Mirror image （docker） For the time being, let's press ,“ Developers only need to care about what they need to know ” And only ​​dice.yml​​ The syntax specification and configuration of .

understand Erda The implementation of the , You can know that when the platform deploys the artifacts , Read ​​dice.yml​​ Content , And it turns into “ Container layer ” The structure of cognition （ If it is K8s It is Deployment、Service、Ingress, as well as StatefulSet perhaps Operator）, And then turn to “ Container layer ” Deploy . be familiar with K8s Will know , If you let users write these configurations manually , You need to understand a lot of knowledge that you don't know （ Most of them are related to operation and maintenance ）, also It's easy to make mistakes .

PS： But aim at Addons（ Or middleware ） The deployment mechanism of is relatively complex , Consider, for example Rds And other external capabilities provided by cloud manufacturers ,Erda A separate set of deployment and expansion capabilities is provided

As the opening chapter said ,​​dice.yml​​ It seems to be a “ High level language ”, and K8s yml It is “ Low level language ”（ We are referring to high-order and low-order , Not that “ Higher order ” It must be “ good ” and “ correct ” Of , But for the convenience of human cognition , It is easier to understand and prevent mistakes , And exactly “ The low order ” In performance 、 Flexibility 、 Control and correct logic are more advantageous ）,Erda After a complicated “ compile ”, Will the user （ Let's say business R & D personnel ） Easier to understand configuration and declaration format or syntax , Into actual deployed workloads （Workload） And endogenous or external services （Addons）.

So much talk , It's easy to come to the conclusion that Erda Is the conclusion of how to deliver the product ： One key deployment .

Just select the product , You can create a deployment form with one click , Wait for the result

Of course, the deployment of real production environment is relatively complex , But it will not change the core one click deployment process .Erda In addition, many additional processes and functions have been developed ： For example, artifacts can be exported and imported , We also developed Gallery（ Market ） Facilitate the dissemination of products （Gallery It also carries Addons as well as Pipeline Of Action）; Products are also built migration The ability of , Be able to migrate data during deployment ; wait .

Of course, the most important thing is Pipeline That is, the ability of the assembly line , Through the core of its arrangement CI/CD Logic ：“ Code -> products -> Deploy ”, Be able to control the production environment from the process （ It also includes testing or other environments ） Access to ,Pipeline Of Action The extension mechanism makes it possible to easily connect external process nodes , Of course Erda Built in provides a lot of out of the box capabilities, such as quality scanning 、 unit testing 、 Automated testing, etc .

Last

This article is only from a small side ： products , Tells the story of Erda How to deliver yourself , It also includes how to deliver various other software , but “ products ” Again Erda The most important and core concept in , You could say Erda So far the same “ idea ”. This is a Erda The starting point of the 、 origin , before Erda No body bones , It's just an anonymous internal packaging and deployment platform ; thereafter Erda Numerous boats gather , It doesn't end there .