Hardcore Debugging Practice | Hands-on with you to implement Serverless breakpoint debugging - 阿里巴巴云原生

Introduction: During the application development process, or after the development is completed, if the execution result does not meet our expectations, it is usually necessary to carry out certain debugging work. However, under the serverless architecture, debugging work is often limited by some environmental factors. For example, the developed application is relatively healthy locally and runs as expected, but on the FaaS platform, there are some problems; or in some In a special environment, there is no way to simulate the online environment locally, and it is difficult to develop and debug the project?

Overview

This article will use the Serverless Devs tool to provide detailed guidance on the breakpoint debugging steps of function computing (FC) applications, walk you through the implementation of serverless breakpoint debugging, and clarify the context steps of "hard-core debugging" from the following four aspects. , full of dry goods:

1. The overview section introduces the importance of debugging capabilities and the debugging capabilities currently provided by Alibaba Cloud Function Compute (FC);

2. Debugging tour lists the detailed steps on "Using Serverless Devs to Debug Breakpoints in Different IDEs";

3. Summarize part of the objective to tell the improvement of breakpoint debugging;

Fourth, the appendix summarizes the detailed animations of breakpoint debugging operations for developers.

Under the serverless application architecture, the debugging capability is often a concern of application developers, which determines the development efficiency of the program. Hackernoon pointed out in the industry research report on Serverless: So far, Debugging is still the biggest pain point and challenge in the implementation of Serverless.
在这里插入图片描述

Report "Top 5 Serverless Trends":
https://hackernoon.com/top-5-serverless-trends-in-2020-wd1m3t8g

There are mainly two kinds of debugging capabilities, one is the ability to run programs; the other is the ability to debug breakpoints. The former is the basic ability of debugging, which can help developers to judge whether the program can run normally, and verify the correctness of the running results of the program; the latter is the advanced ability of debugging, which can help users to easily locate the error that causes the program to run incorrectly or does not meet expectations. Location.

At present, the existing serverless application debugging methods in the industry are mainly to simulate the cloud execution environment locally for local debugging; or to debug based on logs after deploying the application to the cloud to run. However, local debugging cannot simulate the cloud network environment, and cloud debugging lacks local flexibility. In order to overcome these defects and enable out-of-the-box debugging of serverless applications, the Alibaba Cloud function computing team has developed a set of innovative debugging tools in the industry after some exploration, providing all-round local debugging and device-cloud joint debugging capabilities.

• Local debugging : Based on the local environment and network, relying on containerization technology to run the serverless application to achieve the purpose of debugging, please refer to the specific operation document. https://github.com/devsapp/fc/blob/main/docs/en/command/local.md

• Device-cloud joint debugging : Based on the local environment, break through network restrictions, rely on containerization technology, run serverless applications, break through the barriers between local and cloud networks during runtime, and ensure interaction with cloud resources. Please refer to the documentation.
https://github.com/devsapp/fc/blob/main/docs/en/command/proxied.md

The local debugging tools mentioned in this article all provide breakpoint debugging capabilities and are fully compatible with serverless application development specifications. Let's take a look at the specific operation steps for breakpoint debugging.

Debugging Tour

The steps of breakpoint debugging are summarized as follows. Below, I will lead you to start a breakpoint debugging journey around these four steps:

• Start serverless application • Start breakpoint debugger • Start breakpoint debugging • End breakpoint debugging

1. Pre-operation

Before starting debugging, some pre-operations need to be performed. This article divides the pre-operations into general pre-operations and pre-operations additional to the device-cloud joint debugging :

• Generic Pre-Operation:

• Install and debug IDE: There are three optional IDEs: VSCode, Pycharm and Intellij;

• Then, before starting to use these functions, please install the debugging tools : Here we need to install Serverless Devs, please refer to the documentation for the specific installation method:
https://help.aliyun.com/document_detail/195474.html ;

         熟悉新一代函数计算工具链的使用方式，可参考：

https://github.com/devsapp/fc ;

• Download and install Docker : Debugging capabilities all depend on Docker, so you need to have Docker tools in your local environment. Please refer to here for the installation method:
https://docs.docker.com/get-docker/

• Finally, you need to register an Alibaba Cloud account and use Serverless Devs to configure the Alibaba Cloud account. For the specific configuration method, please refer to here.
https://help.aliyun.com/document_detail/295894.html

• Additional pre-operations for device-cloud joint debugging:
• Prepare an Alibaba Cloud account . Since the device-cloud joint debugging involves the deployment and deletion of auxiliary resources, if the account is a sub-account, you need to add some specified permissions to the sub-account. For specific permission sets, refer to. https://github.com/devsapp/fc/blob/main/docs/en/command/proxied.md#%E6%9D%83%E9%99%90%E4%B8%8E%E7%AD%96 %E7%95%A5%E8%AF%B4%E6%98%8E

2, parameter introduction

After completing the preparation of the above preconditions, let's first understand the specific parameters related to breakpoint debugging in the debugging instructions:

 -c, --config [vscode/pycharm/intellij]   [Required] Select which IDE to use when
                                       debugging and output related debug
                                       config tips for the IDE. value:
                                       vscode/pycharm/intellij
                                     
-d, --debug-port number              [Required] Specify the local function
                                       container starting in debug mode, and
                                       exposing this port on localhost
                                     
--debug-args string                  [Optional] Additional parameters that
                                       will be passed to the debugger
                                     
--debugger-path string               [Optional] The path of the debugger on
                                       the host
                                     
--tmp-dir string                     [Optional] The temp directory mounted to
                                       '/tmp' , default:
                                       './.s/tmp/invoke/serviceName/functionName/'

When debugging with breakpoints, the --config parameter as well as the --debug-port parameter are necessary:

• --config will specify the IDE environment for breakpoint debugging. Currently, VSCode, Pycharm, and Intellij are supported.

• --debug-port specifies the listening port for debugging.

In addition, the remaining three parameters are optional:
• --debug-args will customize the debugging parameters when the program starts. For the default debugging parameters if not specified, please refer to the appendix at the end of this article.
• --debugger-path will mount the local specified path to /tmp/debugger_file in the program running environment.
• --tmp-dir will mount the local specified path to the /tmp directory in the program running environment. During debugging, the result file written by the program to /tmp will be mapped to the local directory to verify whether the result conforms to the expected.

3. Practical exercises

1) VSCode

When using VSCode for breakpoint debugging, the process is very simple. Below we divide the breakpoint debugging scenarios into two types: Event function debugging and Http function debugging, which will be introduced separately.

• Debug the Event function:

step1: First start the Serverless application , open the terminal, enter the target project, and enter the startup command:

 # 本地调试
$ s local invoke --config vscode --debug-port 3000
# 端云联调
$ s proxied setup --config vscode --debug-port 3000

After the startup command is executed, the local function computing execution environment will be blocked to a certain extent, and we need to wait for the call; at the same time, the current project will generate a .vscode/launch.json file, which is a configuration file for debugging based on VSCode. If it already exists, the startup command will print the corresponding configuration text, as shown in the figure below, which needs to be used to overwrite the existing content in .vscode/launch.json.

在这里插入图片描述
.vscode/launch.json update content example

step2: Start the breakpoint debugger, open the VSCode interface, then open the source code stored in codeUri in s.yml, set a breakpoint for it, and then click the start debugging button, as shown in the following figure.
在这里插入图片描述

VSCode startup debugger diagram

For local debugging, after starting the debugger, the program has been started, and we can start debugging with breakpoints. If it is the device-cloud joint debugging, after the debugger is started, the "Debugger attached." field will appear on the startup command terminal page. At this time, the debugger has also been successfully started and is waiting to be called. Next, we continue with the following steps That's it.

Step3: Start breakpoint debugging: Open a new terminal page, enter the calling command s proxied invoke --event "hello", the program starts, and breakpoint debugging begins.

step4: End breakpoint debugging: After debugging, automatically close the breakpoint debugger. In the device-cloud joint debugging scenario, a series of auxiliary function resources will be created. Therefore, after the debugging is completed, auxiliary resources need to be released here to prevent additional costs. Just execute s proxied cleanup to release auxiliary resources.

• Debug php7.2 Event functions

The local debugging IDE of php7.2 runtime is recommended to use VSCode, and its breakpoint debugging steps are different from other languages, so they are introduced separately. Currently, php7.2 runtime does not support device -cloud joint debugging and breakpoint debugging.

step1: First start the serverless application , open the terminal, enter the target project, and enter the startup command s local invoke --config vscode --debug-port 3000.

The difference from before is that after the execution of the Event function startup command is completed, there will be no blocking, but it will be executed directly. At the same time, the .vscode/launch.json file will be generated under the current project, as described above.

step2: Start the breakpoint debugger , open the VSCode interface, then open the source code stored in codeUri in s.yml, set a breakpoint for it, and then click the start debugging button, as shown in the following figure.
在这里插入图片描述

Step3: Start breakpoint debugging : Open a new terminal page and enter the startup command s local invoke --config vscode --debug-port 3000 again, the program starts and breakpoint debugging starts.

step4: End breakpoint debugging : After debugging, automatically close the breakpoint debugger.

• Debug HTTP functions

The debugging method of the Http function in the device-cloud joint debugging is actually the same as that of the Event function, so I won't go into details. In this section, we mainly introduce how to debug the Http function in local debugging.

step1: Start the serverless application . First, open the terminal, enter the target project, and enter the start command s local start --config vscode --debug-port 3000. After the start command is executed, the local function computing execution environment will block waiting for the call, and Print the url field of the accessed http function.

step2: Start the breakpoint debugger : Open the VSCode interface, then open the source code stored in codeUri in s.yml, set a breakpoint for it, and then click the start debugging button, as shown in the figure. At this time, on the startup command terminal page, the "Debugger attached." field will appear, indicating that the debugger has been successfully started and is waiting to be called.
在这里插入图片描述

VSCode startup debugger diagram

Step3: Start breakpoint debugging: You can access the URL of the Http function through curl instructions, browsers, etc. At this point, the program starts and breakpoint debugging begins.

Step4: End breakpoint debugging: After debugging, close the breakpoint debugger actively, and then execute Ctrl+C on the startup command terminal page to exit the debugging process.

• Debug php7.2 Http functions

step1: First start the serverless application , open the terminal, enter the target project, enter the startup command s local start --config vscode --debug-port 3000, after the startup command is executed, .vscode/launch.json will be generated under the current project file, as mentioned above, and the project will be blocked at the same time. At this time, you need to execute Ctrl+C to exit.

step3: Start breakpoint debugging: Open a new terminal page and enter the start command s local start --config vscode --debug-port 3000 again, the local function computing execution environment will block waiting for the call, and print the access to the http function. url field, you can access the URL of the Http function through curl instruction, browser, etc. At this time, the program starts and the breakpoint debugging starts.

Step4: End breakpoint debugging: After debugging, close the breakpoint debugger actively, and then execute Ctrl+C on the startup command terminal page to exit the debugging process.

2) Intellij

When performing breakpoint debugging based on Intellij, you need to manually configure the corresponding breakpoint debugger in the IDE for different languages. Since Java is the most developed language using Intellij, after changing the IDE at the same time, the only different step is "Start the breakpoint debugger" ”, so next we will take the local debugging of the Java Event function as an example to describe the step of “Starting the Breakpoint Debugger” in detail.

step1: Start the serverless application : Since Java is a compiled language, the program needs to be packaged before starting. The example in this article will use mvn package to package the function, and then execute the startup command s local invoke --config intellij --debug-port 3000 .

step2: Start the breakpoint debugger : Open the Intellij interface and select Run -> Edit Configurations in the menu bar.

Then, as shown in the figure below, create a new Remote JVM Debug.

在这里插入图片描述

New Remote JVM Debug

Next, customize the debugger name and set the port to 3000, as shown in the image below.
在这里插入图片描述

Intellij debugger configuration

Finally, open the source code stored in codeUri in s.yml, set a breakpoint for it, and then click the start debugging button, as shown in the figure.

在这里插入图片描述

Intellij start breakpoint debugger

3) Pycharm

Currently, only local debugging can perform breakpoint debugging in Pycharm, and the supported runtimes are python2.7 and python3. When performing breakpoint debugging in Pycharm, it is not only necessary to configure the breakpoint debugger in the IDE, but also to make intrusive modifications to the user's source code. Since the content of the operation steps is different from the regular content, let's explain this part in detail. debugging steps.
step1: Start the serverless application: First, open the terminal, enter the target project, and enter the startup command:

 # event 函数
$ s local invoke --config pycharm --debug-port 3000
# http 函数
$ s local start --config pycharm --debug-port 3000

The difference from before is that after the execution of the Event function startup instruction is completed, there will be no blocking, but it will be executed directly. At this point, you need to record the content of "Tips for PyCharm remote debug" . The specific content example is shown in the figure. After the recording is completed, if it is an Http function, enter Ctrl+C to exit the startup program.
在这里插入图片描述

Tips for PyCharm remote debug Content example

step2: Next , start the breakpoint debugger : Starting the breakpoint debugger mainly includes two parts: IDE breakpoint debugger configuration and source code update.

First, open the pycharm interface and select Run -> Edit Configurations in the menu bar.
Next, as shown in the figure, create a new Python Debug Server.
在这里插入图片描述

New Python Debug Server

Then set the custom debugger name, and configure the details of the three debugger configurations of IDE host name, Port, and Path mappings based on the content obtained in Figure 5, as shown in the figure.

在这里插入图片描述

pycharm debugger configuration

Then open the source code stored in codeUri in s.yml, paste the code content in the example picture (Tips for PyCharm remote debug content example) to the beginning of the code, then set a breakpoint at the specified location of the source code as needed, and then click the start debugging button, The specific operation is shown in the figure (pycharm starts the breakpoint debugger).

在这里插入图片描述

Tips for PyCharm remote debug Content example
在这里插入图片描述

pycharm start breakpoint debugger

Step3: Start breakpoint debugging: Open the terminal, enter the target project, and execute the startup command. At this time, pS can not bring the relevant parameters of breakpoint debugging.

 # event 函数
$ s local invoke
# http 函数
$ s local start

After the Event function start command is executed, it will directly enter the breakpoint debugging stage; after the Http function start command is executed, you can first access the URL of the Http function through the curl command, browser, etc. At this time, the program will start, and the breakpoint debugging will begin.

step4: End breakpoint debugging: After debugging is completed, automatically close the breakpoint debugger. For Http functions, on the start command terminal page, you need to execute Ctrl+C to exit the debugging process.

Epilogue

Although the debugging of serverless applications has been criticized, various cloud vendors have not given up their continuous in-depth exploration in the direction of debugging. Taking Alibaba Cloud Function Compute as an example, it currently supports various debugging solutions such as online debugging, local debugging, and device-cloud joint debugging. The application debugging capabilities provided by Serverless Devs tools are also very comprehensive.

The above is some practical experience I shared, but I also found some points to be improved in the process, such as:

• Breakpoint debugging steps are cumbersome, and you need to switch back and forth between multiple pages. If you can integrate the tool into the IDE and use it in a plug-in form for all users to simplify the process, the experience will be greatly improved.
• Hot update capability in breakpoint debugging mode: During the breakpoint debugging of the Http function, the code hot update is not supported. After each code modification, the breakpoint debugging process needs to be re-executed, and the experience is not very smooth.
• The breakpoint debugging capability has not yet fully covered all runtimes. For example, custom runtime does not support breakpoint debugging, and php runtime does not support device-cloud joint debugging breakpoint debugging.

Hope this article is of some help to you.

appendix

Default debug parameters

在这里插入图片描述

Breakpoint debugging animation

The following animation tutorials have completed the "pre-operation" steps mentioned in the article in advance. If you want to practice with reference to the specific animation, please complete the relevant process of the above "pre-operation".