This guide walks you through using aadvanced request routing to the all-in-one-demo application. Review the Quickstart before getting started. This guide starts after the incremental release example, in order to show what other release routing capabilities are possible with tbnproxy deployed. The all-in-one-demo client and server should now be running in your enviroment.

Browser overrides

Let’s test our yellow dev version before we release it to customers. tbnproxy allows you to route to service instances based on headers set in the request. Navigate to app.turbinelabs.io, log in and select the zone you’re working with (all-in-one-demo by default). Click "Settings" -> "Edit Routes", and select all-in-one-demo:80/api from the top left dropdown. You should see the following screen

Click “Add Rule” from the top right, and enter the following values:

IF Header: X-Tbn-Version & version Send 1 to all-in-one-server.

This tells the proxy to look for a header called X-Tbn-Version. If the proxy finds that header, it uses the value to find servers in the all-in-one-server cluster that have a matching version tag. For example, setting X-Tbn-Version: blue on a request would match blue production servers, and X-Tbn-Version: yellow would match yellow dev servers.

The all-in-one client converts a X-Tbn-Version query parameter into a header in calls to the backend; if you navigate to localhost?X-Tbn-Version=yellow you should see all yellow boxes. Meanwhile going to localhost without that parameter still shows blue or green based on the release state of previous steps in this guide.

This technique is extremely powerful. New software was tested in production without customers being affected. You were able to test the new software on the live site before releasing to customers. In a real world scenario your testers can perform validation, you can load test, and you can demo to stakeholders without running through a complicated multi-environment scenario, even during another release.

Testing latency and error rates

In order to demo what errors and latency issues may look like in a production environment, we implemented a few parameters that can be set to illustrate these scenarios. By default, each of the demo servers returns a successful (status code 200) response with its color (as a hex string) as the response body.

URL parameters passed to the client web page at can be used to control the mean latency and error rate of each of the different server colors.

An example

The following URL will show an error rate and delayed response for green and blue servers.

http://<your external IP>/?x-blue-delay=25&x-blue-error=.001&x-green-delay=10&x-green-error=.25

This will simulate a bad green release, and a need to rollback to a known good blue release.

Parameter effect

These parameters can be modified in the above example as follows:

  • x-color-delay: sets the mean delay in milliseconds.
  • x-color-error: sets the error rate, describe as a fraction of 1 (e.g., 0.5 causes an error 50% of the time).

The latency and error rates are passed to the demo servers as HTTP headers with the same name and value as the URL parameters described. You can use these parameters to help you visualize the effects of a bad release, or an issue with the code in a new version of your application, which would be cause to step-down the release and return traffic to a known-good version.

Driving synthetic traffic

If you'd like to drive steady traffic to your all-in-one server without keeping a browser window open, you can add ALL_IN_ONE_DRIVER=1 to the environment variables in your docker run invocation. You can also add error rates and latencies for various using environment variables:

$ docker run -p 80:80 \
  -e "TBNPROXY_API_KEY=<signed_token>" \
  -e "TBNPROXY_API_ZONE_NAME=all-in-one-demo" \
  -e "TBNPROXY_PROXY_NAME=all-in-one-demo-proxy" \
  -e "ALL_IN_ONE_DRIVER=1" \
  -e "ALL_IN_ONE_DRIVER_LATENCIES=blue:50ms,green:20ms" \
  -e "ALL_IN_ONE_DRIVER_ERROR_RATES=blue:0.01,green:0.005" \
  turbinelabs/all-in-one:0.14.2

Conclusion

These examples show some of the many ways the Envoy-based tbnproxy can help your team release, observe, and iterate your software. If you still have questions, or have a proxy idea that you want to implement, let us know!