Introduction: During the application development process, or after the development, if the execution results do not meet our expectations, we usually need to do some debugging work. However, under the Serverless architecture, debugging work is often limited by some environmental factors. For example, the application developed locally is relatively healthy and runs in accordance with expectations, but there are some problems on the FaaS platform. Or in some special environment, there is no local way to simulate the online environment, it is difficult to carry out the development and debugging of the project?
An overview of the
This article will use Serverless Devs tools, functional computing (FC) application breakpoint debugging steps for detailed guidance, hand in hand to guide you to achieve Serverless breakpoint debugging, and from the following four aspects for you to clarify the “core debugging” steps, full of dry things:
First, the overview part introduces the importance of debugging ability, and the current Ali Cloud function computing (FC) can provide debugging ability;
The debug tour lists detailed steps for “breakpoint debugging in different ides using Serverless Devs”.
Third, the summary part objectively tell the breakpoint debugging to be improved;
Appendix iv summarizes detailed giFs of breakpoint debugging operations for developers.
Under the Serverless application architecture,Debug abilityIs often the application developers very concerned about the problem, it determines the program development efficiency. Hackernoon’s industry research report on Serverless points out that so far, Debugging is still the biggest pain point and challenge for Serverless implementation.
Report Top 5 Serverless Trends: hackernoon.com/top-5-serve…
Debugging ability mainly includes two kinds, one is the ability to run the program; Second, breakpoint debugging ability. 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 results of the program. The latter is an advanced debugging capability that helps users easily locate the location that is causing the program to go wrong or do not conform to expectations.
At present, the industry has Serverless application debugging means, mainly in the local simulation cloud execution environment for local debugging; Or deploy the application to the cloud and debug it based on logs. However, local debugging cannot simulate the cloud network environment, and cloud debugging lacks local flexibility. In order to overcome these defects and achieve Serverless application debugging out of the box, Ali Cloud function computing team has developed a set of innovative debugging tools in the industry after some exploration, providing all-round local debugging and end cloud joint debugging capabilities.
• Local debugging: Based on the local environment and network and relying on containerization technology, the Serverless application is planned to run, so as to achieve the purpose of debugging. The specific operation documents can be referred to. Github.com/devsapp/fc/…
• End-to-end cloud coordination: Based on the local environment, break through network restrictions and rely on containerization technology to carry out planned operation of Serverless applications, break through the barriers between local and cloud networks during operation, and ensure interaction with cloud resources. Please refer to the usage documents. Github.com/devsapp/fc/…
All of the native 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 steps for breakpoint debugging.
Trip to debug
The breakpoint debugging steps are summarized as follows, and I’ll take you on a breakpoint debugging journey through these four steps:
• Start Serverless application • Start breakpoint debugger • Start breakpoint debugging • End breakpoint debugging
1. Front operation
Before commissioning, some pre-operations need to be carried out, which are divided into general pre-operations and additional pre-operations for end-to-end cloud joint commissioning in this paper:
• Universal front operation:
• Install and debug ides: VSCode, Pycharm and Intellij are available;
• Install debugging tools before you start using these features: Here we need to install Serverless Devs. For details, please refer to help.aliyun.com/document_de… Familiar with the new generation of function calculation tool chain, please refer to: github.com/devsapp/fc;
• Download and install Docker: All debugging capabilities need to rely on Docker, so Docker tools need to be available in the local environment. For installation methods, please refer to docs.docker.com/get-docker/
• Finally, you need to register an Ali Cloud account and use Serverless Devs to configure an Ali Cloud account. For details, please refer to here. Help.aliyun.com/document_de…
• Prepare an Aliyun account. Since The deployment and deletion of auxiliary resources are involved in The end-to-end cloud syndication, if the account is a sub-account, you need to add some specified permissions for the sub-account. For the specific permission set, please refer to it. Github.com/devsapp/fc/…
2. Parameter introduction
With these prerequisites in place, let’s take a look at the parameters associated with breakpoint debugging:
-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/'
Copy the codeWhen debugging with breakpoints, the –config argument and –debug-port argument are necessary:
• config specifies the IDE environment for breakpoint debugging. Currently VSCode, Pycharm and Intellij are supported.
• –debug-port specifies the listening port for debugging.
In addition, the other three parameters are optional: • –debug-args will customize the debugging parameters when the program starts. If you do not specify the default debugging parameters, refer to the appendix at the end of this article. • — Debugger-path will mount the locally specified path to/TMP /debugger_file of the program’s runtime environment. • –tmp-dir will mount the local specified path to the/TMP directory in the program running environment. During debugging, the result file written to/TMP will be mapped to the local directory to verify whether the result meets expectations.
3. Practical operation drill
1) VSCode
When VSCode is used for breakpoint debugging, the process is very simple. We will divide the breakpoint debugging scenarios into Event function debugging and Http function debugging, respectively.
• Debug Event function:
Step1: start the Serverless application first, open the terminal, enter the target project, and enter the startup instruction:
$s local invoke --config vscode --debug-port3000$s proxied setup --config vscode --debug-port3000
Copy the codeAfter the startup instruction is executed, the local function calculation execution environment will be blocked, and we need to wait for the call; At the same time, the current project will generate.vscode/launch.json file, which is the configuration file for debugging based on VScode. If the file already exists, the startup instruction will print the corresponding configuration text, as shown below. This section is needed to override the existing.vscode/launch.json content.
Step2:Start the breakpoint debugger,Open the VSCode interface, then open the source code stored in codeUri in s.ml, make a breakpoint for it, then click the start debugging button, as shown below.
VSCode starts the debugger schematic
For local debugging, when the debugger is started, the program is already started and we are ready to start our breakpoint debugging. In the case of end-to-end cloud debugging, after the Debugger is started, the “Debugger Attached.” field will appear on the startup command terminal page, indicating that the Debugger has been started successfully and is waiting to be invoked. Next, proceed with the following steps.
Step3: start breakpoint debugging: open a new terminal page, input the call instruction s proxied invoke –event “hello”, the program starts, breakpoint debugging begins.
Step4: end breakpoint debugging: after debugging, actively close the breakpoint debugger. In the scenario of end-to-end cloud integration, a series of auxiliary function resources will be created. Therefore, after debugging, auxiliary resources need to be released to prevent additional costs. Just run S Proxied cleanup to release auxiliary resources.
• Debug the PHP7.2 Event function
VSCode is recommended as a native debugging IDE for php7.2 Runtime. The breakpoint debugging steps are somewhat different from those of other languages, so it is described separately. Currently, THE PHP7.2 Runtime does not support breakpoint debugging.
Step1: start the Serverless application first, open the terminal, enter the target project, and enter the startup instruction s local invoke –config vscode –debug-port 3000.
Different from the previous, the Event function will not be blocked after the execution of the startup instruction, but will directly execute successfully, and the.vscode/launch.json file will be generated under the current project, as described above.
Step2:Start the breakpoint debugger, open VSCode interface, then open the source code stored by codeUri in s. ml, set a breakpoint for it, then click the start debugging button, as shown in the picture below.
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 begins.
Step4: end breakpoint debugging: after debugging, actively close the breakpoint debugger.
• Debug Http functions
In fact, the debugging mode of Http functions in the end-to-end cloud debugging is the same as that of the Event function. Therefore, we will not repeat it. In this section, we will mainly introduce how to debug Http functions in local debugging.
Step1: To 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 and execution environment will block and wait for the call. And print the URL field that accesses the HTTP function.
Step2:Start the breakpoint debugger: open VSCode interface, then open the source code stored in codeUri in s. ml, break it, then click start debugging button, as shown in the picture. In this case, the “Debugger Attached.” field appears on the startup command terminal page, indicating that the Debugger is successfully started and waiting to be invoked.
VSCode starts the debugger schematic
Step3: start breakpoint debugging: you can access the URL of Http function by using curl command or browser. At this time, the program starts and breakpoint debugging starts.
Step4: end breakpoint debugging: after debugging, actively close the breakpoint debugger, and then execute Ctrl+C on the start command terminal page to exit the debugging process.
• Debug PHP7.2 Http functions
VSCode is recommended as a native debugging IDE for php7.2 Runtime. The breakpoint debugging steps are somewhat different from those of other languages, so it is described separately. Currently, THE PHP7.2 Runtime does not support breakpoint debugging.
Step1: Start the Serverless application first, 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, The.vscode/launch.json file will be generated under the current project, as mentioned above, and the project will be blocked, at which point you need to exit by pressing Ctrl+C.
Step2:Start the breakpoint debugger, open VSCode interface, then open the source code stored by codeUri in s. ml, set a breakpoint for it, then click the start debugging button, as shown in the picture below.
Step3: start breakpoint debugging: After opening a new terminal page and entering the startup command s local start –config vscode –debug-port 3000, the local function execution environment will block and wait for the call, and print the URL field to access the HTTP function. You can access the URL of the Http function by using the curl command or the browser. Then the program starts and the breakpoint debugging starts.
Step4: end breakpoint debugging: after debugging, actively close the breakpoint debugger, and then execute Ctrl+C on the start command terminal page to exit the debugging process.
2) Intellij
For breakpoint debugging based on Intellij, the corresponding breakpoint debugger needs to be manually configured in IDE for different languages. Because Java is the most developed language using Intellij, the only different step after IDE is “start breakpoint debugger”. So next, we’ll elaborate on the “Start breakpoint Debugger” step using the local debug Java Event function as an example.
Step1: start the Serverless application: Since Java is a compiled language, you need to package your program before you start. This example uses the MVN Package to package the function and then executes the startup instruction 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 create a new Remote JVM Debug as shown in the figure below.
Create Remote JVM Debug
Next, customize the debugger name and set the port to 3000, as shown below.
Intellij debugger configuration
Finally, open the source code stored in codeUri in S. ml, break it, and click the start debugging button, as shown in the figure.
Intellij starts the breakpoint debugger
3) Pycharm
Currently only local debugging can perform breakpoint debugging in Pycharm, supported by python2.7 and Python3. To debug breakpoints in Pycharm, you not only need to configure the breakpoint debugger in the IDE, but also need to make invasive changes to the user’s source code. Since the operation steps are different from normal ones, let’s take a look at the debugging steps in detail. Step1: start Serverless application: first, open the terminal, enter the target project, and enter the startup instruction:
$s local invoke --config pycharm --debug-port3000$s local start --config pycharm --debug-port3000
Copy the codeDifferent from before, the Event function will not be blocked after the execution of the starting instruction is completed, but will directly execute successfully. This is where you need to record“Tips for PyCharm remote debug”After recording, if it is an Http function, enter Ctrl+C to exit the startup program.
Tips for PyCharm remote Debug Content example
Step2: start the breakpoint debugger: start the breakpoint debugger consists of two parts: IDE breakpoint debugger configuration and source code update.
First, open the PyCharm screen and select Run -> Edit Configurations in the menu bar. Next, create a New Python Debug Server as shown in the figure.
Create a Python Debug Server
Then set the custom debugger name and configure the details of the IDE Host Name, Port, and Path Mappings configuration based on the information obtained in Figure 5, as shown in the figure.
Pycharm debugger configuration
Then open the source code stored in codeUri in S. ML, paste the code content in the example figure (Tips for PyCharm Remote Debug content example) to the beginning of the code, then make a breakpoint at the specified position of the source as required, and click the start debugging button. The details are shown in figure 2 (PyCharm starts the breakpoint debugger).
Tips for PyCharm remote Debug Content example
Pycharm starts the breakpoint debugger
Step3: Start breakpoint debugging: open the terminal, enter the target project, and execute the startup instruction, P.S. In this case, you do not need to take the parameters of breakpoint debugging.
$s local start = $s local startCopy the codeThe Event function will directly enter the breakpoint debugging stage after the execution of the start instruction; After the Http function startup command is executed, you can use the curl command or the browser to access the URL of the Http function. At this time, the program will start and the breakpoint debugging will begin.
Step4: ** end breakpoint debugging: ** after debugging, actively close the breakpoint debugger. For Http functions, execute Ctrl+C in the start command terminal page to exit the debugging process.
conclusion
Serverless application debugging has been criticized, but cloud vendors have not given up exploring the debugging direction. Taking Ali Cloud function computing as an example, it currently supports online debugging, local debugging, end-to-end cloud debugging and other debugging schemes. The Application debugging capabilities provided by the Serverless Devs tool are also 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 is cumbersome and requires switching between multiple pages. If the tool can be integrated into the IDE and used by all users in a plug-in form to simplify the process, the experience will be greatly improved. • Hot update capability in breakpoint debugging mode: Hot update of code is not supported during breakpoint debugging of Http functions. After modifying code each time, you need to re-execute the breakpoint debugging process, which is not smooth. • Breakpoint debugging is not fully covered by all Runtime. For example, the Custom Runtime does not support breakpoint debugging, and the PHP Runtime does not support breakpoint debugging.
Hope you found this article helpful.
The appendix
Default debugging parameters
Breakpoint debug GIF
All the following GIFs have completed the “pre-operation” steps mentioned in the article in advance. If you want to practice with specific GIFs, please first complete the relevant procedures of “pre-operation” mentioned above.
1) VSCode
The local debug Event function
Specific operation, please go to link below to view: www.bilibili.com/video/BV1Ba…
Locally debug the PHP7.2 event function
Specific operation, please go to link below to view: www.bilibili.com/video/BV1dL…
The end cloud synchronizes the Event function
Specific operation, please go to link below to view: www.bilibili.com/video/BV15S…
Debug Http functions locally
Specific operation, please go to link below to view: www.bilibili.com/video/BV1gi…
Debug PHP7.2 Http functions locally
Specific operation, please go to link below to view: www.bilibili.com/video/BV1nY…
Endcloud interworking Http function
Specific operation, please go to link below to view: www.bilibili.com/video/BV1A4…
2) Intellij
The local debug Event function
Specific operation, please go to link below to view: www.bilibili.com/video/BV1S3…
The end cloud synchronizes the Event function
Specific operation, please go to link below to view: www.bilibili.com/video/BV19L…
3) Pycharm
The local debug Event function
Specific operation, please go to link below to view: www.bilibili.com/video/BV1GF…
Debug Http functions locally
Specific operation, please go to link below to view: www.bilibili.com/video/BV1HF…
Serverlesss Devs community official website: www.serverless-devs.com/ Publishes the latest cloud native technology information, collects the most complete content of cloud native technology, holds cloud native activities and live broadcasts regularly, and releases Ali products and user best practices. Explore the cloud native technology with you and share the cloud native content you need.
Pay attention to [Alibaba Cloud native] public account, get more cloud native real-time information!