mirrord VS asdf

Here is a quick start guide link. Want to talk to an actual human? Then hop in our Discord (no chatbots here, I promise). Prefer more asynchronous communication? Open up an issue or a discussion on GitHub. We love feedback, don’t be shy!

So, you've been using mirrord to simplify your development process (if you haven’t, go here!). Naturally, you want the traffic from the app you're debugging to go through the cluster environment, so your app can communicate with its clustery pals. There is a problem though: your latest change adds some new columns to the database, and you don’t want to modify the database in the cluster and affect everyone else working on it. You do have a local instance of the database that you can modify, so your app can use that, but you still want it to talk to all the other components in the cluster. So what now? The new outgoing traffic filter feature is here to solve exactly this type of problem!

if you are interested in k8s, iptables, hooking libc, asm etc https://github.com/metalbear-co/mirrord

Finished working on medschool, which is a tool to extract Rust docs into a markdown file. Still very rough around the edges and produces a markdown that is probably only useful for our own project. We want to maybe expand this to be more generally useful later (hoping that there is interest in the community for such a tool).

Turns out supporting node.js in IntelliJ plugins is not as easy as you would expect (mostly because the extension point we are extending is not documented. With documentation this could have been simple), but we did it! I'm the JetBrains fan of the team, so I'm happy we're extending our support for IntelliJ. You can now run and debug node.js applications with the mirrord IntelliJ plugin. mirrord let's you run your application locally, but with one foot in your kubernetes cluster, and it's open source. This is what it looks like:

In version 3.39.0 of the mirrord plugin for IntelliJ we added support for running and debugging node.js applications from IntelliJ with mirrord. This was quite a challenge as JetBrains' SDK for that is closed source, undocumented, and was recently changed, but at the end we managed to extend our plugin's support to node.js. Here is a gif of what it looks like:

You can read about mirrord on our website or on GitHub, since it's open source.

We use https://github.com/metalbear-co/mirrord to run changes in the context of the cloud environment without actually deploying thus eliminating most of the testing/debugging time

I'm biased but we develop https://github.com/metalbear-co/mirrord so you can just run the process locally in the context of the remote cluster - be it a locally kind cluster or a cloud provided one.

Or if you need to manage more than just node, asdf has been around for over a decade and works great. You can use a .tool-versions to change runtimes for each project you have, in addition to managing your global runtime versions

https://asdf-vm.com/

https://asdf-vm.com/ ASDF is better because it works with many more languages, other than only Python, like Rust, Go, Node, etc, and other tools, such as AWS/Google/Firebase/Azure CLIs.

Why not just use a tool like asdf (https://asdf-vm.com/) or mise (https://mise.jdx.dev/)?

These tools have the advantage of not being multi-taskers and can manage version for all your tools. You wouldn’t need pyenv and npm and rvm and…

We’ve even started committing the .mise.toml files for projects to our repos. That way, since we work on multiple projects that may need multiple versions of the same tool, it’s handled and documented.

The purpose of a version manager is to help you navigate or install any tools for development easily. Version Manager can be one tool for each dependency (e.g. NVM, g) or One tool for all dependencies (e.g. asdf, mise).

Secondly, our development environments must not drift, because then code may behave differently and a change could pass on our machine but fail in production. There are many tools for locking down environments, e.g nix, pkgx, asdf, containers, etc., and they all share the common goal of being able to lock down dependencies for an environment accurately and deterministically. And that needs to be enforced in our local workflow so we don't have to rely on CI environments for correctness. All developers must have environments that are effectively identical to what runs in CI (which itself should be representative of the production environment).

There are many ways this can be done (e.g nix, pkgx, asdf, containers, etc.), and we won’t get into which specific tools to use, because we'll instead cover the essential essence of preventing environment drift:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.13.1

I've really been enjoying asdf, which is a program that allows you to install specified versions of dev utilities as well as dynamically manage them via shims and .tool-versions files.

I use the asdf version manager.