On Pausing Containers – how we built, and why we deprecated, our container paus

metalbear.co

28 points·todsacerdoti··5 comments

> mirrord lets developers run local code in the context of a remote Kubernetes pod. This lets them test their code in cloud conditions without going through CI and deployment. In most cases, stealing or mirroring incoming traffic from the remote pod to the local process is good enough. However, when you have applications that consume tasks and do more than react to incoming requests, the user might want to pause the remote application completely , so that it doesn’t compete with their local process for tasks.

That sounds like an audit/compliance nightmare. For example, if the infrastructure is within scope of PCI-DSS you're making not just the developer's laptop, but all of the network they're on now part of the audit scope, and it all needs to be up to scratch for security.

Combine that with the risk of using it to sniff/exfiltrate PII etc. I'm astounded that this was even built as a feature. It's a hacker's best friend, surely?

If it's too hard to test your code, fix your test environments, don't make production, or test, come to your laptop.

the cons listed at the end basically invalidate those solution as a mirrored test env too.

all in all, this seems like a very sketchy way to deal with prod debugging. there's a reason cicd pipelines exist and why dev teams don't run prod services from their workstations.

mirrord is a dev tool for dev environments. One can use it for production but that's not the use case we encourage.

This seems a lot more fraught with peril than fixing the code

The issue is that pausing that way isn't really fixable mostly because of systemd priniciples. One would have to interact with it AFAIK which makes it way more complex, and still there are the usability issues. (I wrote the blogpost)

Reply on news.ycombinator.com