Join us
@ismail ă» Apr 07,2022 ă» 5 min read ă» 3310 views
Serverless is pretty cool but native debugging has always been a burden for developers. In this article, I looked into a tool which makes it possible to debug AWS Lambda functions written in Node.js and Python runtimes live in production. To give just a bit more context, this VSCode plugin allows you to put a breakpoint in your Lambda code and get the stack trace without adding an overhead or breaking the full flow of the application.
Serverless is pretty cool but native debugging has always been a burden for developers. There have been many attempts to debug Lambdas, including simulating the cloud environment and mocking managed services. However, these solutions lack two crucial capabilities. They can not simulate the security permissions of AWS Lambda functions and they can not keep up with the authenticity of event data flowing between resources. In other words, they can not help you debug Lambdas in production.
In this article, I looked into a VSCode plugin which makes it possible to debug AWS Lambda functions live on AWS. It is possible to put breakpoints in your Lambdas and debug just one invocation while not blocking the whole flow. This way, you will have the exact debugging data because you debug on the real AWS environment with the real authentic data. It doesn't require adding code, mocking your resources, or simulating the app.
Start online debug sessions while the AWS Lambda functions run on AWS Cloud. The debugger sets up an easy and secure connection between your AWS Lambda functions and VSCode. You can debug your serverless applications natively with their permissions. When you have an erroneous invocation, you can put breakpoints and pause the execution of the Node.js and Python functions to see the stack trace.
To use the AWS Lambda Debugger, you need to complete all installation steps.
THUNDRA_AGENT_LAMBDA_DEBUGGER_AUTH_TOKEN
. If you've already signed up, you can get your auth token from the start page.1. Open the Command Palette (â§âP)
and select Thundra: Edit Configuration command to paste the auth token to the authToken
field.
2. Go to your AWS Console and set your auth token value with the THUNDRA_AGENT_LAMBDA_DEBUGGER_AUTH_TOKEN
key as your environment variable.
Thundra: Start Debugger
to start the debugger with the current profile's settingsThundra: Start Debugger (with a session name)
to start the debugger with the given session nameThundra: Change active profile
to change the active profile to the one given in your config fileThundra: Edit configuration
to edit the JSON file containing your debugger configurationYou can access all of the above commands from the command palette (Cmd+Shift+P or Ctrl+Shift+P).
A self-hosted instance of the broker that provides the necessary functionality for online debugging can be installed on your AWS account using our CloudFormation template or our CDK application.
You can configure the self-hosted broker with different access settings as described in the below image:
The Amazon CloudFormation template provides all the required resources for setting up the online debugging broker. You can easily install it on your own AWS account following the steps below. You will have both a public and an internal endpoint for the broker as the output. You can choose to have DNS mappings done automatically as subdomains under a Route53 hosted zone that you specify.
This configuration is created automatically if you have provided a âHosted Zone Nameâ parameter.
This configuration is not mandatory if you donât provide an SSL certificate. Without the certificate, you can directly use the endpoints in the âOutputsâ section.
You will see two URLs named BrokerInternalURL and BrokerPublicURL under the âOutputâ section after the stack creation is completed. You will need to update your DNS records to direct your reserved domains for the Thundra debugging broker to these endpoints.
For example: thundra-debugger-public.yourdomain.com -> BrokerPublicURL thundra-debugger-internal.yourdomain.com -> BrokerInternalURL
Your debugging environment most likely has access to the internet and the best option at this point is to configure it to connect to the public broker endpoint. A secure connection is provided if you have an SSL certificate for the installation. If this is not the case or you want to use the internal endpoint anyway, you can access it from the debugging environment as long as it is connected to your VPC via a VPN tool.
You can use values under the âOutputâ section of the stack for the Thundra debugging client configuration. Use âBrokerPubliclUrlâ or âBrokerInternalUrlâ in order to debug with the public endpoint or the internal endpoint. Use âBrokerPortâ as the broker host parameter.
Please note that if you make a manual DNS configuration, you should use the respective DNS record values as the broker host parameter instead of the values under the âOutputâ section.
Using the public endpoint is also the best option for your Lambda functions if they have internet access, but this may not be possible all the time. If you need to configure your Lambda functions to connect to the internal endpoint, you also need to be sure that you have an appropriate security configuration in order to access the debugging broker from your Lambda functions.
Join other developers and claim your FAUN account now!
Influence
Total Hits
Posts
Only registered users can post comments. Please, login or signup.