Shopify / toxiproxy

:alarm_clock: :fire: A TCP proxy to simulate network and system conditions for chaos and resiliency testing
https://github.com/shopify/toxiproxy
MIT License
10.81k stars 448 forks source link

Add persistence layer #249

Open DaCAPNcrunch opened 5 years ago

DaCAPNcrunch commented 5 years ago

Dealing with a server restart isn't a big deal for simple deployments of Toxiproxy with a couple proxies and toxics. However, as the environment grows to dozens of proxies things become problematic as a restart will take down every API until they are all setup again. The /populate endpoint takes care of a lot of this since it can be called when starting, but someone needs to maintain that JSON array.

I would like to propose a persistence layer that will save all proxies and toxics and populate them on application start to eliminate all manual work of maintaining the JSON. My thoughts on implementation would be to have an interface and create an implementation for MySQL where others could follow with additional implementations as required. The selection of the implementation would be done on application start and could have a predefined schema for RDBMS implementations.

What are your thoughts on this project? Are you all interested or have any special requirements?

I am willing to be the author for this issue.

Edit: clarity

jpittis commented 5 years ago

Thanks for opening an issue @DaCAPNcrunch. I may be misunderstanding your problem so feel free to clarify. :)

Dealing with a server restart

I don't fully understand what you're referring to. Generally we populate Toxiproxy once on boot in development (on docker-compose up or whatever) or once on CI container boot.

a restart will take down every API

Generally we don't restart Toxiproxy until we shutdown our development environment or finish running a CI container. At this point there is no API to take down if you get what I mean.

Persistence

I'm generally against the idea of having a MySQL persistence layer but I don't see anything wrong with persisting configuration to a file and passing it as a parameter to Toxiproxy on boot. (I feel like that's been discussed before.)

It's important to remember that different users have different needs when configuring Toxiproxy. Some might really benefit from persistent file load. Other large apps (many at Shopify) dynamically generate Toxiproxy configuration programatically which means persistence is less useful.

If we do add a persistence layer, it might be cool to also add /dump endpoint which would return an auto generated persistence layer based on the current state of the proxy. We could add a feature to the cli tool which would hit this endpoint and populate the file.