Tutorial
Speedscale Installation from Speedscale on Vimeo.
In this guide we're going to use this repo's example app in the java
directory to capture, transform and replay traffic with mocks.
Prerequisites
- Speedctl is installed
- Clone https://github.com/speedscale/demo
- Java is present
- Make sure
JAVA_HOME
is set correctly (on MacOS you can run/usr/libexec/java_home
to find the correctJAVA_HOME
) - Install
jq
andmake
if not already on your desktop (brew install jq
andbrew install make
on MacOS for example)
The App
The app is a Java Spring Boot web server with authenticated endpoints that makes requests out to a few external services. The project README (at java/README.md
) shows ways to run the app locally, in Docker and in Kubernetes. Speedscale can be configured to be compatible with whichever way you choose to deploy the app. Note that for this test run we'll disable DLP but you can find instructions on how to enable it near the end.
Capture
Make sure you navigate to the java
subdirectory within the demo
repository.
- Kubernetes
- Docker
- Local
- Install the operator
- Run:
make kube-capture
This should start generating traffic that you can see in the Speedscale UI within a couple of minutes.
- Generate a jks for the Java app:
docker run --rm -v ~/.speedscale/certs:/speedscale openjdk bash -c 'keytool -importcert -noprompt -cacerts -storepass changeit -alias speedscale -file /speedscale/tls.crt && cp ${JAVA_HOME}/lib/security/cacerts /speedscale/cacerts.jks'
- Run:
speedctl install
Choose the Docker
option and then the Capture
option (option 1). You can name the service anything you want, the default port setting of 8080
is necessary.
- Run the following to bring up the Speedscale capture components:
docker compose --file speedscale-docker-capture.yaml up -d
- Run in your current terminal window:
make compose-capture
- Open a new terminal window and run:
make client-capture
This should start generating traffic that you can see in the Speedscale UI within a couple of minutes.
- Generate local certs by running the following command:
speedctl create certs --jks --output-dir ~/.speedscale/certs
- Run in a separate terminal window:
speedctl capture java-server 8080
- Run in your original terminal window:
make local-capture
- Run
make client-capture
This should start generating traffic that you can see in the Speedscale UI within a couple of minutes.
Analyze
Exploring Speedscale Traffic Viewer from Speedscale on Vimeo.
After a few minutes you should be able to see your traffic in the Speedscale dashboard. Make sure to select the the same service name that you entered in speedctl install
from the traffic dropdown. You should be able to see the inbound and outbound calls for this app as shown below.
You can also drill down into specific requests-response pairs (RRPairs). For eg. we see the request we make to our app to get the max interest rate for treasuries.
And we can also see the outbound request our app makes to the Treasury API to fulfill this request.
You can and inspect it further or you can skip ahead to running a replay which will also create a snapshot as a side effect.
Replay
We're now going to run a replay for this captured traffic.
- Kubernetes
- Docker
- Local
Click the Replay as Tests/Mocks
button on the top right and walk through the wizard. All the default settings are ok here. You can also do this outside of the UI with more instructions here.
- Click the
Save to Tests/Mocks
button in the top right. All the default settings are ok here. You can find more detailed instructions in the Create a Snapshot section. - Once you see the Snapshot summary, copy the snapshot ID from the URL or by clicking the
Copy Snapshot ID
option from the three dot menu. - Run:
speedctl install
Choose the Docker
option and then Replay
(option 3).
- Select your service and the standard test config. Make sure you select the same service name you entered during the capture phase.
- Input the Snapshot ID from step 1, the port should still be
8080
- Run in one terminal window:
make compose-replay
- Run in another window to start the replay:
export TEST_REPORT_ID=$(uuidgen | tr '[:upper:]' '[:lower:]'); docker compose --file speedscale-docker-replay.yaml up -d && echo "Your test report can be found at: https://app.speedscale.com/reports/${TEST_REPORT_ID}"
- Click the
Save to Tests/Mocks
button in the top right. All the default settings are ok here. You can find more detailed instructions in the Create a Snapshot section. - Once you see the Snapshot summary, copy the snapshot ID from the URL or by clicking the
Copy Snapshot ID
option from the three dot menu. - Run:
make local-replay
- Replace
SNAPSHOT_ID
and run:
speedctl replay SNAPSHOT_ID --test-config-id=standard --custom-url='http://localhost:8080'
Making sense of a Replay
If you are already viewing the Snapshot you recorded, you can see your replay appear in the Replay
tab. Alternatively, you can find a report for your Replay in the dashboard. It should look something like this.
We can see that all the requests our app makes to third party APIs were mocked out with 100% accuracy. For eg. we can see the request our app made to the Treasury API that was actually mocked out which is great for isolation during tests but we can also do this for other parts of our development cycle as detailed here.
You can also see that the accuracy isn't 100%. We can drill down into a specific assertion to see why.
Transform
The JWT we get from the login request is different which is expected. If we were replaying in a different environment, we might need different credentials entirely for the login request. Another pattern might be a set of traffic where we don't have a login request and instead we need to resign the JWT from our captured traffic. This is where Transforms come into play and we can edit our captured data to parameterize parts of it. As an example, we can transform our snapshot to edit the password.
When you find the request in the transform editor, you can click the pencil icon next to the field you want to edit which in our case is the password.
For now we'll just replace it with a constant but there are all sorts of options that can be chained together.
We just did a transform for the traffic coming into our app during a replay. We can also use transforms for mocks in case we have to parameterize fields like session ids, dates, etc. Check out this guide for a deep dive.
Assertions
Another assertion that failed in our report is for the /spacex/ship
endpoint.
Our app returns a different ship ID every time we make a request so this is an expected failure. We can edit the test config for our Report to account for this.
Click the pencil next to the HTTP Response Body
assertion and we can add ship_id
as a json path to ignore.
After saving, we can reanalyze the report and we see much better results!
Overview
In this demo we:
- Captured some traffic
- Analyzed it in the Traffic Viewer
- Optionally configured DLP
- Ran a replay and created a snapshot
- Used auto generated mocks during the replay
- Transformed some snapshot traffic
- Edited the assertions
- Reanalyzed the report for a higher accuracy
Next Steps
This is just a small subset of things you can do with Speedscale, other things to try out could be:
- Capture traffic from one of your own apps
- Replay traffic from one cluster into another
- Run a load test
- Integrate with CI/CD
Uninstall
If you'd like to remove the demo from your environment follow these instructions:
- Kubernetes
- Docker
make kube-clean
docker compose -f speedscale-docker-capture.yaml down
(Optional) Data loss Protection
If we drill down into a request, we can also see data we may not want to leave our environment.
You can enable DLP to redact certain fields from an RRPair at capture time. Note that this will cause your replays to have low accuracies because necessary information will be masked. Check out the dlp section for more information on DLP configuration. As a starter, you cna follow the instructions below.
- Kubernetes
- Docker
- Local
Run:
speedctl infra dlp enable
Edit speedscale-docker-capture.yaml
to add the following two environment variables.
services:
forwarder:
environment:
- SPEEDSCALE_REDACT=true
- SPEEDSCALE_DLP_CONFIG=standard
Run the speedctl capture
command with the additional flag --dlp-config standard
.
Now we see the authorization header is redacted and never makes it to Speedscale.
For more complex DLP configuration you can use this guide.