A self-hosted instance of the broker that provides the necessary functionality for online debugging can be installed on your own AWS account using our CloudFormation template or you can perform a manual installation using the Docker image we provide.
You can configure the self-hosted broker with different access settings as described in 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.
SSL Certificate Preparation If you want to enable a secure connection via HTTPS, you will need an SSL certificate signed for the domains you are planning to use as the debugger endpoints. If you don’t have an available SSL certificate on AWS Certificate Manager, you can upload your existing certificate or request a new one by following this guide.
Create a CloudFormation stack by providing the following parameters using the template:
Thundra License Key
Please contact us for the license key at [email protected]
Debug Broker Instance
The debugger version you want to deploy. Click here to see available versions
Amazon EC2 Instance Type
Type of Amazon EC2 instance in which the broker will be run.
SSH IP Address Range
IP address range that could be used for SSH access to the broker EC2 instance
SSH Key Name
EC2 KeyPair to enable SSH access to the broker EC2 instance
⚠Please remember that both the Lambda functions you want to debug and your debugging environment should have access to the broker instance installed with these configurations.
The VPC you want to deploy the debug broker
⚠Two subnets in different AZs under the selected VPC should be selected. Otherwise, the installation cannot be completed. Also, subnets should be able to connect to the internet so they can use the public endpoint.
SSL Certificate ARN
ARN of the SSL certificate you have on AWS Certificate Manager
Hosted Zone Name
AWS Route53 hosted zone name for the automatic DNS configuration. You will need to write the host name without a period at the end (e.g., “thundra.io”).
Subdomain for Public Broker Endpoint
The subdomain where the public broker will be served.
Subdomain for Internal Broker Endpoint
The subdomain where the private broker will be served
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.
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.
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.
The official Thundra debugging broker Docker images can be accessed in this Docker Hub repository.
You will need to pass the Thundra license key to the container on run. This can be done two ways:
Pass it as an environment variable named THUNDRA_LICENSE_KEY:
$ docker run -p 4444:4444 -p 5555:5555 --env THUNDRA_LICENSE_KEY=$THUNDRA_LICENSE_KEY thundraio/thundra-debug-broker-onprem:$BROKER_VERSION
Mount the folder containing .thundra_license_key file to bind the user home directory in the container:
$ docker run -p 4444:4444 -p 5555:5555 -v $PATH_TO_LICENSE_KEY_FOLDER:/root thundraio/thundra-debug-broker-onprem:$BROKER_VERSION
You should replace $THUNDRA_LICENSE_KEY with the license key you get from Thundra console for debugging. You can also put it in a file and use it as described in the second option.
$BROKER_VERSION can be replaced with any available version in the Docker Hub repository. You can also use "latest" to get the latest stable version.