eyalbukchin
|
1 year ago
|
on: Mirrord Mirrord on the wall, who's most processed of them all
Not only do more bugs reproduce in staging than locally (for obvious reasons), but mirrord also saves you the trouble of figuring out how to run your stuff locally in the first place.
Previously, before you could add a single line of code to your microservice, you had to be able to run it and all of its dependencies on your local machine. This is such a huge challenge in some cases that people actually prefer to git push and deploy to the cloud for every little change.
With mirrord you can just clone the repo and debug.
eyalbukchin
|
3 years ago
|
on: Fun with macOS's Sip
Ideally! And it can be run on a Linux machine if the user prefers. But if you code on a Mac, mirrord still lets you go through a good number of test iterations (by letting your process run with network input/output, file content and environment variables from the cloud) before having to deploy your code to a Linux machine for that (hopefully) final round of testing.
eyalbukchin
|
3 years ago
|
on: Show HN: I “wrote” a kid's book with ChatGPT and Midjourney
It's initially the parent who'll pick the book though (or the critic? the people who decide what to put in the front window of the bookstore? probably not the four year old though), so the uncanniness could come into play.
eyalbukchin
|
3 years ago
|
on: Fun with macOS's Sip
This is detailed in the post, but the security feature i.e. preventing injected libraries access to entitlements isn't actually bypassed here. Rather the binary is run without these entitlements (which aren't required anyway for mirrord's use case).
eyalbukchin
|
3 years ago
|
on: Fun with macOS's Sip
Maybe, we haven't looked into that option for the following reasons:
a. It would require that we maintain a potentially pretty big list of self-compiled binaries
b. It would be an alteration of what the user's running, which we try to keep to a minimum, as mirrord's commonly used as a testing tool
eyalbukchin
|
3 years ago
|
on: Fun with macOS's Sip
The part of mirrord that's affected by SIP is the client. This is meant to be run by users on their development machines (we could ask them to disable SIP, but would rather not for obvious reasons).
eyalbukchin
|
3 years ago
|
on: Mirrord 3.0 – Mirror a pod's network traffic and file system accesses locally
It does work with any k8s cluster, no operator needed. It indeed relies on kubectl's config to talk to the k8s API. All that's needed is permissions to run privileged pods (or if you've configured mirrord to use ephemeral containers, not even that).
We're currently working on a more enterprise-oriented version where you would have a persistent operator in the cluster, and it would let you properly manage RBAC, rather than relying on each user's kubectl.
Thanks for pointing all of this out! We'll try to make this info more easily accessible.
eyalbukchin
|
3 years ago
|
on: Mirrord – mirror production traffic to your development environment
So there are a bunch of use cases, but the main one we think is during day to day development. mirrord can give you access to “cloud conditions” while you code, without having to go through CI and actually deploying, which a. makes your feedback loops a lot tighter and b. reduces the likelihood you’ll deploy something broken to the cloud (i.e. staging/production) environment and break it for other developers in the organization.
We wrote about it a bit more here if you’re interested:
https://metalbear.co/blog/reintroducing-mirrord/
eyalbukchin
|
3 years ago
|
on: Mirrord – mirror production traffic to your development environment
First of all, mirrord runs on the process level. Telepresence either runs on your local machine, changing its network behavior or in a container making development less smooth than running a local process.
Second, mirrord's default is to duplicate traffic and not intercept it, so useful when you don't want to disrupt the cloud environment, want to work concurrently with other developers on the same service, etc.
eyalbukchin
|
3 years ago
|
on: Mirrord – mirror production traffic to your development environment
Our agent sniffs traffic in the same network namespace as the pod whose incoming traffic we mirror, so in most cases that would be after the HTTPS traffic is decrypted (by e.g. a load balancer, or a service mesh)
eyalbukchin
|
3 years ago
|
on: Mirrord – mirror production traffic to your development environment
Up to you: you’re going to be able to configure what works locally vs what works with the cloud environment. So for example, you could configure all read functionality (incoming traffic, DB reads) to work with the cloud, and all write functionality to work locally.
Further down the line, we’re planning to support Copy On Write for databases - so you’d read from the cloud, write locally, then read the records you wrote locally (and records you haven’t written, from the cloud).
Disclaimer: we’re still pretty early in the roadmap, so currently only support mirroring incoming traffic. But we’re moving fast :)
eyalbukchin
|
3 years ago
|
on: Mirrord – mirror production traffic to your development environment
Yes! This is actually in development at the moment so should be out really soon. Along that same line, we're also planning to support routing of outgoing traffic back to the cloud environment. We're obviously thinking of both those features as more suitable for use with a staging environment rather than production.
