Take you hand in hand to implement Serverless breakpoint debugging

Summary

This article will use the Serverless Devs tool to provide detailed guidance on breakpoint debugging steps for functional computing (FC) applications. We will guide you through breakpoint debugging for Serverless, and clarify the context and steps of "hard core debugging" from the following four aspects. We are fully stocked:

1、 The overview section describes the importance of debugging capabilities, as well as the debugging capabilities that Alibaba Cloud Functional Computing (FC) can provide currently;

2、 The debugging tour lists the detailed steps for "using Serverless Devs to debug breakpoints in different IDEs";

3、 The summary section objectively states the areas to be improved in breakpoint debugging;

4、 The appendix summarizes a detailed diagram of breakpoint debugging operations for developers.

Under the Serverless application architecture, debugging ability is often a concern of application developers, which determines the efficiency of program development. Hackernoon's industry research report on Serverless pointed out that, so far, Debugging remains 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

Debugging ability mainly includes two types: one is the ability to run programs; The second is breakpoint debugging capability. The former is the basic ability of debugging, which can help developers judge whether the program can run normally and verify the correctness of the program operation results; The latter is an advanced debugging capability that can help users easily locate the location that causes the program to run incorrectly or does not meet expectations.

Currently, the existing serverless application debugging methods in the industry mainly simulate the cloud execution environment for local debugging; Or deploy the application to the cloud for debugging based on logs. However, local debugging cannot simulate the network environment of the cloud, and cloud debugging lacks local flexibility. In order to overcome these shortcomings and debug Serverless applications out of the box, the Alibaba Cloud functional computing team has developed a set of industry-innovative debugging tools through exploration, providing comprehensive local debugging and end-to-end cloud joint debugging capabilities.

• Local debugging: Based on the local environment and network, relying on container technology, the Serverless application is planned to run to achieve debugging purposes.

• End Cloud Joint Debugging: Based on the local environment, breaking through network constraints, relying on container technology, planning to run Serverless applications, breaking through barriers between local and cloud networks during runtime, and ensuring interaction with cloud resources. Please refer to the usage documentation.

https://github.com/devsapp/fc/blob/main/docs/zh/command/proxied.md

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

Commissioning Tour

The breakpoint debugging steps are summarized as follows. Next, I will lead you to embark on a breakpoint debugging journey around these four steps:

• Start the Serverless application

• Start the breakpoint debugger

• Start breakpoint debugging

• End breakpoint debugging

1. Front operation

Before starting debugging, some pre operations are required. This article divides pre operations into general pre operations and additional pre operations for end cloud joint debugging:

• Universal front end operation:

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

Before starting to use these features, please install the debugging tools: Here we need to install Serverless Devs.

Familiar with the use of the new generation of function calculation tool chain.

• Download and install Docker: Debugging capabilities rely on Docker, so it is necessary to have Docker tools in the local environment.

• Finally, you need to register an Alibaba Cloud account and configure the Alibaba Cloud account using Serverless Devs.

Additional front-end operations for end-to-end cloud joint debugging:

• Prepare an Alibaba Cloud account. Due to the deployment and deletion of auxiliary resources involved in end cloud joint debugging, if the account is a sub account, it is necessary to add some specified permissions to the sub account. For specific permission sets, please refer to. https://github.com/devsapp/fc/blob/main/docs/zh/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:

When using breakpoint debugging, the -- config parameter and the -- debug port parameter are necessary:

• -- config will specify the IDE environment for breakpoint debugging, and currently supports VSCode, Pycharm, and Intellij.

• -- 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. If you do not specify the default debugging parameters, please refer to the appendix at the end of the article.

• -- debugger path will mount the local specified path to the/tmp/debugger of the program running environment_ File.

• -- 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 results meet expectations.

3. Practical exercise

1）VSCode

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

• Debug Event functions:

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

#Local debugging

$ s local invoke --config vscode --debug-port 3000

#End Cloud Joint Debugging

$ s proxied setup --config vscode --debug-port 3000

After starting the execution of instructions, the local function calculation execution environment may be blocked to some 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 the file already exists, the startup command will print the corresponding configuration text, as shown in the following figure. You need to use this part of content to overwrite the existing. vscode/launch.json content.

Sample updated content for. vscode/launch.json

Step 2: Start the breakpoint debugger, open the VSCode interface, and then open the source code stored in codeUri in s.yml. Set a breakpoint for it. Then click the Start Debugging button, as shown in the following figure.

Schematic diagram of VSCode startup debugger

For local debugging, after starting the debugger, the program has already started, and now we can start our breakpoint debugging work. In the case of end-to-end cloud joint debugging, after starting the debugger, the "Debugger attached." field will appear on the startup instruction terminal page, indicating that the debugger has also been started successfully and is waiting to be called. Next, we can continue with the following steps.

Step 3: Start breakpoint debugging: Open a new terminal page, enter the call instruction s proxied invoke -- event "hello", and the program starts. Breakpoint debugging starts.

Step 4: End breakpoint debugging: After debugging, actively close the breakpoint debugger. In the end-to-end cloud joint debugging scenario, a series of auxiliary function resources will be created. Therefore, after debugging is completed, auxiliary resources need to be released here to prevent additional costs. Simply execute the "proxied cleanup" to release auxiliary resources.

• Debugging the php7.2 Event function

The local debugging IDE for php7.2 runtime recommends using VSCode. The breakpoint debugging steps are somewhat different from other languages, so they will be described separately. Currently, the PHP 7.2 runtime does not support end-to-end cloud joint debugging breakpoint debugging.

Step 1: 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.

Unlike before, after the execution of the Event function startup instruction is completed, there will be no blocking, but the execution will directly succeed. At the same time, a. vscode/launch.json file will be generated under the current project, as described earlier.

Step 2: Start the breakpoint debugger, open the VSCode interface, and then open the source code stored in codeUri in s.yml. Set a breakpoint for it. Then click the Start Debugging button, as shown in the following figure.

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

Step 4: End breakpoint debugging: After debugging, actively close the breakpoint debugger.

• Debug Http functions

In end cloud joint debugging, the debugging method for Http functions is actually the same as that for Event functions, so we won't repeat it. In this section, we mainly introduce how to debug Http functions locally.

Step 1: Start the Serverless application. First, open the terminal, enter the target project, and enter the startup command s local start -- config vscode -- debug port 3000. After the startup command is executed, the local function calculation execution environment will block waiting calls, and print the URL field for accessing the http function.

Step 2: 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, the "Debugger attached." field will appear on the startup instruction terminal page, indicating that the debugger has successfully started and is waiting to be called.

Schematic diagram of VSCode startup debugger

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

Step 4: End breakpoint debugging: After debugging is completed, actively close the breakpoint debugger, and then execute Ctrl+C on the startup instruction terminal page to exit the debugging process.

• Debug php7.2 Http functions

The local debugging IDE for php7.2 runtime recommends using VSCode. The breakpoint debugging steps are somewhat different from other languages, so they will be described separately. Currently, the PHP 7.2 runtime does not support end-to-end cloud joint debugging breakpoint debugging.

Step 1: First start the Serverless application, open the terminal, enter the target project, and enter the startup command s local start -- config vscode -- debug port 3000. After the startup command is executed, a. vscode/launch.json file will be generated under the current project. As mentioned earlier, the project will be blocked, and you need to execute Ctrl+C to exit.

Step 2: Start the breakpoint debugger, open the VSCode interface, and then open the source code stored in codeUri in s.yml. Set a breakpoint for it. Then click the Start Debugging button, as shown in the following figure.

Step 3: Start breakpoint debugging: Open a new terminal page, and input the startup command s local start -- config vscode -- debug port 3000 again. After that, the local function calculation execution environment will block waiting calls, and print the URL field of the http function. You can access the URL of the Http function through curl commands, browsers, and other methods. At this point, the program starts, and breakpoint debugging begins.

Step 4: End breakpoint debugging: After debugging is completed, actively close the breakpoint debugger, and then execute Ctrl+C on the startup instruction terminal page to exit the debugging process.

2）Intellij

When debugging breakpoints based on Intellij, it is necessary to manually configure corresponding breakpoint debuggers in the IDE for different languages. Since the language most developed using Intellij is Java, and after replacing the IDE, the only different step is "Start breakpoint debugger." Therefore, we will take the local debugging of Java Event functions as an example to provide a detailed description of the "Start breakpoint debugger" step.

Step 1: Starting the Serverless application: Because Java is a compiled language, it is necessary to package the program before starting. This example uses the mvn package to package the functions, and then executes the startup command s local invoke -- config intellij -- debug port 3000.

Step 2: Start the breakpoint debugger: Open the Intellij interface, and select Run ->Edit Configurations from the menu bar.

Then, as shown in the following figure, 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 following figure.

Intellij Debugger Configuration

Finally, open the source code stored in codeUri in s.yml, mark a breakpoint for it, and then click the Start Debugging button, as shown in the figure.

Intellij Launch Breakpoint Debugger

3）Pycharm

Currently, only local debugging can perform breakpoint debugging operations in Pycharm, and there are two supported runtimes: python 2.7 and python 3. When performing breakpoint debugging in Pycharm, you not only need to configure a breakpoint debugger in the IDE, but also need to make intrusive modifications to the user's source code. Due to the differences between the operation steps and the regular content, let's explain the debugging steps in this section in detail.

Step 1: Start the Serverless application: First, open the terminal, enter the target project, and enter the startup command:

#Event function

$ s local invoke --config pycharm --debug-port 3000

#Http function

$ s local start --config pycharm --debug-port 3000

Unlike before, after the execution of the Event function startup instruction is completed, there will be no blocking, but the execution will directly succeed. At this point, it is necessary to record the "Tips for PyCharm remote debug" content. The specific content example is shown in the figure. After recording, if it is an Http function, enter Ctrl+C to exit the startup program.

Tips for PyCharm remote debug content example

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

First, open the pychart interface and select Run ->Edit Configurations from the menu bar.

Next, as shown in the figure, create a new Python Debug Server.

Create a new Python Debug Server

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

Pychar debugger configuration

Then open the source code stored in codeUri in s.yml, paste the code content in the example diagram (Tips for PyCharm remote debug content example) to the beginning of the code, and then click the breakpoint at the specified location of the source code as required. Then click the Start Debugging button, as shown in the figure (Starting the breakpoint debugger for PyCharm).

Tips for PyCharm remote debug content example

Pychar m starts the breakpoint debugger

Step 3: Start breakpoint debugging: Open the terminal, enter the target project, and execute the startup command. At this time, p.S. may not need to bring the relevant parameters for breakpoint debugging.

#Event function

$ s local invoke

#Http function

$ s local start

The Event function will directly enter the breakpoint debugging phase after executing the startup instruction; After the Http function startup instruction is executed, you can first access the URL of the Http function through the curl instruction, browser, and other methods. At this point, the program will start, and breakpoint debugging will begin.

Step 4: End breakpoint debugging: After debugging is completed, actively close the breakpoint debugger. For Http functions, you need to execute Ctrl+C on the startup instruction terminal page to exit the debugging process.

epilogue

Although the debugging of Serverless applications has been criticized, various cloud vendors have not abandoned their continuous in-depth exploration in the direction of debugging. Taking Alibaba Cloud functional computing as an example, it currently supports multiple debugging schemes such as online debugging, local debugging, and end-to-end cloud joint debugging. The application debugging capabilities provided by the Serverless Devs tool are also very comprehensive.

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

• Breakpoint debugging steps are cumbersome and require switching back and forth across multiple pages. If you can integrate tools into the IDE, provide them to all users in a plug-in form, and simplify the process, the experience will greatly improve.

• Hot update capability in breakpoint debugging mode: During breakpoint debugging of Http functions, code hot updates are not supported. After each code modification, the breakpoint debugging process needs to be executed again, resulting in a less smooth experience.

• Breakpoint debugging capabilities currently do not fully cover all runtimes, such as custom runtime that does not support breakpoint debugging, and php runtime that does not support end-to-end cloud joint debugging.