How to use a plug-in to solve the problem of serverless grayscale publishing?

Guided reading

This article is suitable for:

Students who want to know about Serverless grayscale release.

Students who think that the current serverless grayscale publishing configuration is too complicated and are looking for a simplified version of the grayscale publishing process.

Students who want to understand the relationship between Serverless Devs components and plugins.

Serverless Grayscale Release

What is Serverless?

Serverless, as the name implies, is serverless. It is a brand-new computing provision method of "use it as you come, complete functions, and leave it after use". Users can run the code without prefabricating or managing the server, and only need to deploy the code from the server on the server. , convert to deploy on the serverless platform of various manufacturers; at the same time enjoy the advantages of serverless pay-as-you-go, high flexibility, low operation and maintenance cost, event-driven, cost reduction and efficiency improvement.

What is Serverless Grayscale Publishing?

Grayscale release is also known as Canary Deployment. In the past, before the miners went down to the mine, they would put a canary into the well. If the canary did not die due to lack of oxygen or gas poisoning in the mine, the miners would go down to work. It can be said that the canary protects workers' lives.

Similarly, in the software development process, there is also a canary, that is, a gray release (Gray release): developers will first open the newly developed functions to some users, and when the new functions are available to these users After it runs smoothly and the feedback is positive, new features will be made available to all users. A canary release is a process of never releasing and then gradually transitioning to an official release.

So how should the functions deployed on the serverless platform be released in grayscale?

The following will introduce Alibaba Cloud Function Compute FC as an example.

Grayscale publishing has one process and two ways.

a process

Serverless grayscale publishing is achieved by configuring aliases. The aliases can configure the traffic ratio between the grayscale version and the main version. When calling the function, the configured alias can be used to send the traffic to the corresponding version in proportion.

The process of configuring grayscale publishing is as follows:

1. A new version is released in the Service.
2. Create or update an alias, configure the alias to associate the new version with the stable version, and the new version is the grayscale version.
3. Associate a trigger ( Trigger ) to an alias.
4. Associate a custom domain name ( Custom Domain ) to an alias.
5. Using an alias in the calling function, traffic is sent to the new and stable versions in proportion to the configuration.

Two ways of traditional practice

1. Alibaba Cloud console web interface:

a. Release version

b. Create an alias

c. Associated triggers

d. Associate a custom domain name

2. Use Serverless Devs cli

a. Release version

 s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"

b. Create alias and set grayscale

 s cli fc alias publish --region cn-hangzhou --service-name fc-deploy-service --alias-name pre --version-id 1 --gversion 3 --weight 20

c. Associated triggers

Need to go to the console configuration

d. Associate a custom domain name

You need to go to the console configuration to see that each step in the grayscale publishing process using the console or Serverless Devs needs to be operated by the user. And because of the numerous configurations, it is very error-prone. In addition to these drawbacks, another problem that customers have trouble with is that it is very inconvenient to use the grayscale publishing strategy.

There are five common grayscale publishing strategies:

1. 1. CanaryStep : Grayscale release, first grayscale the specified traffic, and then grayscale the remaining traffic after a specified time interval.
   2. LinearStep : Released in batches, each batch has a fixed flow, and the next batch is started after a specified time interval.
   3. CanaryPlans : Customize grayscale batches, set the grayscale flow and interval time for each batch, and perform grayscale according to the set flow after the interval is specified.
   4. CanaryWeight : Manual grayscale, directly set the corresponding weight to the grayscale version.
   5. FullWeight : Full release, full release to a certain version.

Among these grayscale policies, the first three items all need to configure the interval time, and the user cannot configure the interval time through the automatic program in the console or using the Serverless Devs tool, and has to remind the user to do it manually by means of an alarm clock, etc. The next step is the grayscale process, and the experience is very unfriendly. Below we introduce a plug-in that can help you publish functions in one-click grayscale: FC-Canary.

Grayscale release based on Serverless Devs plugin FC-Canary

In order to deal with the above problems, FC-Canary, a plug-in based on Serverless Devs, came into being. This plug-in can help you realize the grayscale publishing capability of functions through Serverless-Devs tools and FC components, and effectively solve the problem of complex parameter configuration and the need for development during grayscale publishing. In-person operations and few strategies available.

(Content configuration and precautions - some screenshots)

For the detailed process, please see: https://github.com/devsapp/fc-canary .

Advantages of FC-Canary

1. FC-Canary supports ultra-simple configuration

The user only needs to add 5 lines of code in s.yaml to enable the grayscale publishing function.

2. The FC-Canary configuration guide is simple and clear:

3. FC-Canary supports a variety of grayscale strategies

• Grayscale release, first grayscale the specified traffic, and then grayscale the remaining traffic after a specified time interval.

At this time, the traffic change is: 20% traffic to the new version, 100% traffic to the new version after 10 minutes

• Manual grayscale, when specifying, directly set the corresponding weight of the grayscale version.

At this point, 10% of the traffic goes to the new version and 90% to the stable version

• Customize the grayscale, and configure the grayscale change in an array.

The traffic changes at this time are: 10% to the new version -> (after 5 minutes) 30% of the traffic to the new version -> (after 10 minutes) 100% of the traffic to the new version

• Release in batches, and continuously accumulate the gray scale ratio until 100% traffic to the new version.

Change in traffic: 40% to new version -> (after 10 minutes) 80% of traffic to new version -> (after another 10 minutes) 100% of traffic to new version

• Full release, 100% traffic to the new version

The FC-Canary plug-in supports the above five grayscale strategies. Users can experience one-click grayscale publishing by selecting the desired strategy and performing simple configuration.

4. The FC-Canary grayscale prompt is clear

The plugin will show each milestone in a log, giving developers enough confidence.

5. FC-Canary supports DingTalk group robot reminder

Configure the DingTalk robot to receive relevant reminders in the group, such as:

FC-Canary Best Practices

Use the FC-Canary plugin to release the function of nodejs 12 in grayscale.

Code repository:

https://github.com/devsapp/fc-canary/tree/main/example/singleFunc-http

Initial configuration

• Code configuration

• yaml configuration

We adopt canaryWeight's grayscale strategy: after grayscale is released, 50% of the traffic goes to the new version, and 50% of the traffic goes to the old version.

make first release

1. Execute the release

Type in terminal: s deploy --use-local

2. View Results

You can see in the log output from the command line:

Since it is the first release, there is no historical version in the project, so even if the grayscale release policy is configured, the FC-Canary plugin will be released in full, that is, all traffic will be sent to version 1.

Modify the code, the second release

1. Before the second release, let's modify the code so that it throws an error.

2. Execute the release

Type in terminal: s deploy --use-local

3. result

You can see in the command line output log:

For the second release, a grayscale release strategy was applied, i.e. 50% of the traffic was sent to version 1, and 50% of the traffic was sent to version 2.

test

Obtain the domain output in the log, and view the console monitoring panel after visiting the domain 100 times.

It can be seen that the function is called 100 times, the wrong function is 49 times, and the correct function is 100 - 49 = 51 times. Both the correct and wrong functions account for about 50% of the total number of calls.

Analysis: function version 1 is the correct function, function version 2 is the wrong function, our grayscale configuration is 50% to version 1 and 50% to version 2, so during the calling process, the wrong function and the correct function should each account for 50% , the results in the figure are in line with our hypothesis, which proves that our grayscale strategy is successful.

Summarize

We can find that compared with using the console for grayscale publishing, using the FC-Canary plugin saves the user the trouble of manually creating versions, publishing aliases, associating triggers, and managing custom domain names, and it is very convenient to use.

Extended reading

Relationship between Serverless Devs components and plugins

• What are components?

According to the description in Serverless Devs Model v0.0.1, Component: is a piece of code developed and published by Package developer that conforms to the Serverless Package Model specification. Usually, this code will be referenced in the application and used in the Serverless Devs developer tool. Load and perform certain actions according to predetermined rules. For example, deploy the user's code to the serverless platform; build and package the serverless application; debug the serverless application, etc.

for example:

If you want to use Serverless Devs to manage the function computing resources of Alibaba Cloud Function Computing, you need to declare the Alibaba Cloud FC components in the yaml configuration file, and then you can use the capabilities of the Alibaba Cloud FC components.

The FC component can provide the ability to manage Alibaba Cloud function computing resources, including: management services, functions, versions, aliases and other functions. Component address: https://github.com/devsapp/fc

• What is a plugin?

Plugins complement components and provide atomic functionality of components.

for example:

1. Using the function deployment function of the FC component deploy, you can use the FC-Canary plug-in to release the deployed function in grayscale after the deployment.
2. Using the deploy function of the FC component to deploy the function, the layer-fc plug-in can be used before the deployment starts to reduce the time-consuming of uploading code during the deployment process: that is, layer-fc allows the function to directly use the dependencies in the public dependency library (remote), thereby It is no longer necessary to upload these remotely existing dependencies when deploying.

• The relationship between components and plugins?

• In the Serverless Devs Model, the component occupies the core position, and the plug-in is the auxiliary position. That is to say, the purpose of the plug-in is to improve the component's capabilities and provide some optional atomic functions to the component.
• Serverless Devs manage the life cycle of components and plugins. If it is a pre plugin, it will be executed before the component is executed. On the contrary, the post plugin will do some finishing work after the component.
• A component can use multiple plugins at the same time, where the execution order of component plugins is:

1. 1. Plug-ins are executed in yaml order, and the execution result of the previous plug-in is the input parameter of the latter plug-in
   2. The output of the last pre plugin is used as the input parameter of the component
   3. The output of the component is used as the input parameter of the first post plugin

Related concepts

• FC function (Function) is the unit of system scheduling and operation, which consists of function code and function configuration. FC functions must belong to services, and all functions under the same service share some of the same settings, such as service authorization, log configuration. For related operations of functions, see Managing Functions. Function Compute supports event functions and HTTP functions. For the difference between the two, see Function Types.
• Services can be aligned with microservices (with versions and aliases), and multiple functions can work together to form a service unit. Before creating a function, you must create a service. All functions under the same service share some of the same settings, such as service authorization and log configuration.
• The role of the trigger (Trigger) is to trigger the execution of the function. Function Compute provides an event-driven computing model. The execution of a function can be triggered by the Function Compute console or SDK, or by some other event source. You can create a trigger within a specified function, which describes a set of rules that, when an event satisfies the rules, causes the event source to fire the associated function.
• A custom domain name (Custom Domain) is the ability that Function Compute provides to bind a domain name to a web application.
• Version is a snapshot of a service, including the configuration of the service, function code and function configuration in the service, excluding triggers. When a version is released, Function Compute will generate a snapshot for the service and automatically assign a version number to it. for subsequent use.
• Alias combines versions to help Function Compute implement continuous integration and release in the software development life cycle.

Finally, everyone is welcome to contribute more open source plugins together!

Reference link:

Serverless Devs:

https://github.com/Serverless-Devs/Serverless-Devs/

FC component address:

https://github.com/devsapp/fc

For the specific information of the FC-Canary plug-in and its use, please refer to:

https://github.com/devsapp/fc-canary

FC function management:

https://help.aliyun.com/document_detail/73338.htm

FC function type:

https://help.aliyun.com/document_detail/61009.htm