Docker VS toxiproxy

I'm not touching anything Docker anymore.

Here's the scenario: you're the unfortunate soul who received the first M1 as a new employee, and nothing Docker-related works. Cue multi-arch builds; what a rotten mess. I spent more than a week figuring out the careful orchestration that any build involving `docker manifest` needs. If you aren't within the very fine line that buildx assumes, good luck pal. How long has `docker manifest` been "experimental?" It's abandonware.

Then I decided it would be smart to point out that we don't sign our images, and so I had to figure out how to combine the `docker manifest` mess with `docker trust`, another piece of abandonware. Eventually I figured out that the way to do it was with notary[1], another (poorly documented) piece of abandonware. The new shiny thing is notation[2], which does exactly the same thing, but is nowhere near complete.

At least Google clearly signals that they are killing something, Docker just lets projects go quiet.

How long before this project lands up like the rest of them? Coincidentally, we were talking about decoupling our CI from proprietary CI, seeing this was a rollercoaster of emotions.

[1]: https://github.com/notaryproject/notary

On the same vibes as https://github.com/Shopify/toxiproxy

https://github.com/Shopify/toxiproxy is a perfect solution for that. I used it quite successfully years ago and it looks like it's still pretty active.

I also tried toxiproxy but it doesn’t support TLS which is also important to me.

Looking at the toxiproxy you mentioned, it seems like it should do what you want though? TLS is generally over TCP anyway, so it should still be able to throttle those connections - it just wont understand the encryption. I also saw a pull request for having it act as a TLS man-in-the-middle proxy: https://github.com/Shopify/toxiproxy/pull/270

That's unfortunate. My next idea was if you have a spare raspberry pi lying around, you could connect it to a wifi network, connect your Jetson to the raspberry via ethernet, and then setup routing rules on the raspberry to route packets between the wifi and ethernet interfaces, essentially using the raspberry pi to connect the jetson to the router, allowing the raspberry pi to be in the middle of all the traffic - then you could use tc to control the traffic on the raspberry pi... assuming tc works on the raspberry pi. Warning I haven't done this either, though I've had some interest in rigging up a raspberry pi this way for stuff similar to this. Looking at the toxiproxy you mentioned, it seems like it should do what you want? TLS is generally over TCP anyway, so it should still be able to throttle those connections - it just wont understand the encryption. I also saw a pull request for having it act as a TLS man-in-the-middle proxy: https://github.com/Shopify/toxiproxy/pull/270 But again, that would only be necessary if you need it to understand the encryption - SSL/TLS MITM proxies pretend to be t he site you are trying to connect to and even present a generated certificate which you will generally have to accept, which allows them to decrypt your connection and then they setup their own SSL/TLS connection to the actual site and proxy between them. Other popular SSL/TLS mitm proxies include mitmproxy and Zed Attack Proxy, but not sure if they have traffic shaping/controlling abilitiies.

I've used toxiproxy [1] to imitate various network problems (slowness, lost packets, dropping connections, etc). It works pretty well, and is even amenable to running during functional / integration tests.

[1]: https://github.com/shopify/toxiproxy

Might be overkill but we use https://github.com/Shopify/toxiproxy for doing all sorts of evil network simulations.

Shopify released a tool just a few days ago that I think could handle this. ToxiProxy