Tailscale Operator for Kubernetes sounds like it'd fit your second bullet point. It's has a really good experience. I've only used for my person homelab but I've been more than impressed by it.
Instead of mDNS, they could update a DNS record for a subdomain (techno00.dev.thecompany.com, preferably under a different domain than your real one) to their local IP address and then do the DNS-01 challenge on LetsEncrypt to get a valid TLS cert for the subdomain. Then the only problem is some routers block DNS responses with RFC-1918 IP addresses, but everyone is using DoT/DoH by now, right? ... right?
Docker Desktop already ran on Macs. This is specifically for the new Apple Silicon support (M1). It's not native, technically, but it feels native the way Docker Desktop works. Basically they manage the VM for you, so you don't have too.
Can you run a container of Windows on an x86 machine? The answer is no, and for the same reason it won’t work on ARM. A “container” is not a virtual machine, you can only run the same Linux executables you would on a normal Linux system.
That said, as another person commented, you can run Windows for ARM in a VM on an Apple M1.
No nested virtualisation present currently, as such no virtualization support provided to VMs, so on Windows on an M1 only WSL1 works. Docker Linux containers on Windows require WSL2 instead.
Docker Windows containers aren't available on arm64 Windows yet, but stay tuned...
Gyro, a command-line cloud automation and management tool, started as internal tool over 5 years ago. We had a vision of building one tool that would pull together several different tools (Chef, Service Discovery, Authentication, Deployments, etc) into a single interface that would greatly simplify the day to day management of our systems. This goal was very successful in transitioning to a DevOps model. Our developers are able to make configuration changes, do their own deployments, and build there own test environments without help from the operations team. And most importantly they've embraced this model because it gave them the power to make changes without waiting for an operations team and in turn it helped the operations team by reducing their work.
We decided to clean up the code and open source it. The result is Gyro (getgyro.io).
The "pluggable convergence engines" is what we've built in Gyro[1] for this very reason. We wanted to have more control over how changes are made in production.
An example is doing blue/green deployments where you want to build a new web/application layer, pause to validate it (or run some external validation), then switch to that layer and deleted the old layer. All while having the ability to quickly roll back at any stage. In Gyro, we allow for this with workflows[2].
There are many other areas we allow to be extended. The language itself can be extended with directives[3]. In fact, some of the core features like loops[4] and conditionals are just that, extensions.
It's also possible to implement the articles concept of "non-destructive prod" by implementing a plugin that hooks into the convergence engines (we call it the diff engine) events and prevents deletions[5].
We envision folks using all these extension points to do creative things. For example, it's possible to write a directive such as "@protect: true" that can be applied to any resource and would prevent it from ever being destroyed using the extension points described above.
I've found a combination of Spring Boot executable jar + a small jlink built JRE runtime packaged next to the executable jar works fairly well.
Our zipped distribution is 50mb. Uncompressed the executable is 26mb and the runtime is 75mb.
I'd love for it to be smaller but I can't complain. This also makes solving for Linux, macOS, and Windows pretty trivial. They each get their own zip with packaged runtime.
