Innovative Launch | Serverless Debugging Killer: Device-Cloud Joint Debugging

Author: Xi

background

Speaking of the most popular technology at present, it is inevitable to discuss a concept: Serverless. As a new type of application architecture, Serverless frees us from the tedious maintenance of infrastructure. We only need to upload code packages or images to get a service that is flexible, highly available, free of operation and maintenance, and low-cost.

Serverless, which sounds beautiful, does have some pain points in the actual development process. For example, in the process of using Serverless, you must have the following problems:

• Using Function Compute Custom Runtime/Container If you want to migrate applications of various language frameworks such as SpringBoot, Python Flask, and ThinkPHP with one click, you need to access other services in the cloud environment (such as database or registry) during instance startup. When the application fails to start, how can I troubleshoot the cause?
• The application adopts a microservice architecture and involves multiple services. Is it possible to quickly perform end-to-end testing after local code development is complete?
• Event-driven applications trigger functions through event sources. There are many links and long links. Can the entire link be quickly tested locally?
• ……

Industry research reports (hacknoon serverless report [1] ) also show that debugging is the biggest obstacle to the implementation of Serverless. At present, the existing serverless application debugging methods in the industry mainly use the local simulation cloud execution environment for local debugging; while the applications running in the remote environment mainly rely on logs. Since the real cloud environment cannot be simulated locally, local debugging cannot solve the above problems. For this reason, we have launched the industry's innovative device-cloud joint debugging function to solve the problem of serverless application debugging.

Device-cloud joint debugging

The core idea of Serverless Devs' end-cloud joint debugging [2] function is to make the local development environment break through the limitations of the network and integrate with the cloud environment. Through device-cloud joint debugging, developers can start instances locally, seamlessly connect with the cloud environment, and quickly conduct tests and problem debugging. Device-cloud joint debugging can help developers:

1. Change the code, view the results in real time, and debug the iteration with the shortest closed loop. For example, the service to be developed is depended on by other services. When the local code development is completed, it is best to initiate an end-to-end test to see if the change has broken the caller service. If the traditional method is used, the code needs to be deployed to the remote end and the test can be initiated, and the process is very lengthy.
2. It can reuse the rich local development and debugging tools with the highest efficiency. For example, to investigate the failure of test cases in the remote environment, we can only rely on logs in the past. Wouldn't it be cool if we could import production traffic to instances in the local environment and use various IDEs on the local environment for debugging?

As shown in the figure below, the device-cloud joint debugging establishes a secure tunnel connection between the local development machine and the VPC environment of the cloud application. The traffic accessing the cloud application will be automatically forwarded to the local development machine; at the same time, the external network traffic accessed by the local instance will also be automatically forwarded to the VPC environment of the cloud application. For example, when a local instance accesses an RDS database instance in the cloud, if developers debug and develop locally, they can only open the public network access of the RDS instance or purchase VPN services to achieve local access to the online VPC. With device-cloud joint debugging, you can directly access the RDS instance through the intranet without any configuration changes.

Enable device-cloud joint debugging

As long as the user executes s proxied setup in the s.yaml directory, this command does the following:

1. Create an auxiliary Service/Function according to your s.yaml vpc configuration and other information, and reserve 1 instance for the auxiliary function. The role of this helper function is to act as a proxy service through which all incoming and outgoing traffic of the local instance will pass.
2. Start the proxy container instance of the local environment, and establish a two-way communication TCP tunnel with the FC network proxy container instance in 1 through the channel service.
3. Start the local function container instance. For example, if you use Custom Runtime to run the SpringBoot application directly, start the local function container instance of SpringBoot and the proxy container instance in 2 to share the network. The springboot application can already access online VPC resources on the intranet.
4. When the local function container instance is successfully launched, you can start debugging, directly use s proxied invoke or curl custom domain name to call the auxiliary Service/Function, the traffic will be sent back to the local function container instance through the proxy service, and the local IDE will start the application in the instance. Debug with breakpoints.

Close the device-cloud joint debugging

Because there will be an auxiliary function reserved for 1 instance, after debugging, you can manually clean up resources to avoid unnecessary charges.

1. In the terminal where the end-cloud joint debugging is enabled, directly CTRL + C to interrupt
2. Or in another terminal, execute s proxied cleanup in the same directory

You can use one of the methods 1 or 2 above. If you are worried, you can execute s proxied cleanup multiple times.

Even if you forget to clean up, if the local developer shuts down or disconnects from the network, the channel session will be automatically closed and the reserved resources will be automatically cleaned up.

Examples of actual combat scenarios

Take a real enterprise customer of Alibaba Cloud Function Computing as an example: Xiao Wang is a developer of a business-driven company. In order to improve the efficiency of business iteration, the company has evolved its technical architecture towards a comprehensive cloud-native approach, reducing the management and operation and maintenance of basic facilities. The structure is roughly as follows:

Xiao Wang migrates the most frequently iterated external front-end and back-end projects to the Custom Runtime of Function Compute with one click, in which SpringBoot projects need to be able to use various VPC intranet addresses to access downstream services (such as registry or other microservice interfaces) ), at this time, the end-cloud joint debugging [3] provided by Serverless Devs can come in handy. You only need to execute it in the directory where s.yaml (the VPC configuration where the function is defined in s.yaml) is located:

$ s proxied setup

This command will establish a secure network channel with the cloud VPC environment and start the application instance locally. At this time, the local instance can seamlessly access the resources in the cloud VPC environment, such as using the intranet address to access the registry, RDS, Kafka, etc. This means that your application configuration does not require any changes to interact with resources within the on-premises and cloud environments.

At the same time, directly using the custom domain name on the Function Compute FC corresponding to this SpringBoot backend project, the traffic will be routed to the local application instance. For example, the function name of your front-end project deployed to FC is frontend, and the corresponding custom domain name is frontend.abc.com. The function name of the backend service that the frontend depends on deployed on the FC is backend, and the corresponding custom domain name is backend.abc.com. At this time, you open fronted.abc.com directly in the browser and perform operations with back-end requests. The traffic is automatically routed from the online to the local SpringBoot instance, and the SpringBoot logs are displayed in real time on the terminal. Point to debug traffic from the line.

Assuming that the instance of the SpringBoot backend project fails to be started locally, the possible reasons include the incorrect VPC configuration of Function Compute, the whitelist restriction of the corresponding downstream service, and so on. At this point, you can reproduce the same startup process as the cloud environment instance locally, which is extremely helpful for troubleshooting instance startup issues. As shown below:

We can clearly locate the reason from the startup process information of the local instance that Nacos cannot access. We need to check whether the function is correctly configured with the VPC information where Nacos is located, or whether Nacos has whitelist restrictions and so on.

Summarize

Finally, we simply use a table to summarize the differences between local debugging and device-cloud joint debugging:

Serverless, as the default computing paradigm of cloud computing in the next ten years, is currently one of the biggest challenges for serverless debugging. Compared with other competitors that only provide local debugging capabilities, Alibaba Cloud Function Computing innovatively proposes device-cloud joint debugging. And through tools to achieve a good developer experience, greatly improve the development efficiency and happiness of serverless application developers, life is too short, I use Serverless!

Related Links

[1] hacknoon serverless report：https://hackernoon.com/top-5-serverless-trends-in-2020-wd1m3t8g

[2] End-cloud joint debugging: https://github.com/devsapp/fc/blob/main/docs/zh/command/proxied.md

[3] Device-cloud joint debugging: https://help.aliyun.com/document_detail/195642.html

refer to

Spring Boot Serverless combat | Serverless application monitoring and debugging https://mp.weixin.qq.com/s/ToDSQXB1b6q5CMXpcWvrBw

Poke here , jump to Serverless Devs~