Install Toxiproxy via brew
Disclaimer: All steps done with toxiproxy v2.1.2
To keep matters simple, I chose Wordpress as an example application to take toxiproxy for a test drive. I use a classic docker setup consisting of a docker-compose.yml with a vanilla wordpress and a mysql service and then added toxiproxy in between.
Application [wordpress] --> Toxiproxy [proxy] --> Database [mysql]
Before we get into the details, quickly install the toxiproxy server and client in OSX with (we’ll only need the client):
brew tap shopify/shopify brew install toxiproxy
Since toxiproxy is the man in the middle it needs to be initialized before our application can connect to its database. The docs say:
When your application boots, it needs to make sure that Toxiproxy knows which endpoints to proxy where. The main parameters are: name, address for Toxiproxy to listen on and the address of the upstream.
This code needs to run as early in boot as possible, before any code establishes a connection through Toxiproxy
The official toxiproxy docker image consists of alpine plus toxiproxy server and client. Since I didn’t want to modify the official image I added an init service to the docker-compose file.
When the stack is started the init container exits after configuring our proxy container. This can be verified with:
$ toxiproxy-cli list Name Listen Upstream Enabled Toxics ====================================================================================== tox_wordpress_mysql_db [::]:3306 mysql:3306 enabled None
After finishing the wordpress setup via http://localhost:8080, we log in and can see the default website and the wordpress dashboard.
Time to get the toxics ☠️
Toxics manipulate the way traffic passes through toxiproxy. The docs say:
Toxics manipulate the pipe between the client and upstream. They can be added and removed from proxies using the HTTP api. Each toxic has its own parameters to change how it affects the proxy links.
Adding a toxic uses the following syntax:
usage: toxiproxy-cli add <proxyName> --type <toxicType> --toxicName <toxicName> \ --attribute <key=value> --upstream --downstream
So adding a latency toxic with random jitter looks like this:
$ toxiproxy-cli toxic add tox_wordpress_mysql_db --type latency --toxicName myToxic --attribute latency=300 --attribute jitter=150 # or shorter: # toxiproxy-cli toxic add tox_wordpress_mysql_db -t latency -n myToxic -a latency=300 -a jitter=150 Added downstream latency toxic 'myToxic' on proxy 'tox_wordpress_mysql_db' $ toxiproxy-cli list Name Listen Upstream Enabled Toxics ====================================================================================== tox_wordpress_mysql_db [::]:3306 mysql:3306 enabled 1 $ toxiproxy-cli inspect tox_wordpress_mysql_db Name: tox_wordpress_mysql_db Listen: [::]:3306 Upstream: mysql:3306 ====================================================================== Upstream toxics: Proxy has no Upstream toxics enabled. Downstream toxics: myToxic: type=latency stream=downstream toxicity=1.00 attributes=[ jitter=150 latency=300 ]