Couldn't something like this be a few hundred lines of Ansible? Not trying to be intentionally negative but I don't really get the use case as I feel this is a pretty well established process by existing tools for server automation and provisioning.
I've been using Ansible with Docker Compose since 2015. I can set up a full server with all of the bells and whistles in about 20 lines of inventory configuration. Behind the scenes there's a bunch of portable and generic roles that work for baseline "server level" components. I've done this now for dozens of companies, it's a tried and true model with an easy way to customize things if needed.
Ansible sets up the server, Docker Compose runs the apps (stand alone `docker compose` commands, not the Ansible module) and git is used to deploy everything.
All of those example apps are deployable to production (and can be used in development) once your server has Docker installed.
[0]: https://github.com/nickjj?tab=repositories&q=docker-*-exampl...
Those examples are for running your app, not deploying it.
Zero downtime is also a loaded term.
MRSK isn't zero downtime in a way that's commonly described as zero downtime. MRSK uses Traefik's built in functionality to queue requests so if your back-end is down it won't respond with a 502. Instead the user will see a busy mouse cursor until your back-end is up.
A user will be able to automatically "resume" their request after your app reloaded which is nice, it saves them from having to see a 502 and manually reload the browser but if you have a Rails app that takes 27 seconds to boot up then the user will be waiting for 27 seconds with no feedback. You could make a case the UX there is worse than a user explicitly seeing a custom 502 page that mentions to reload in a bit.
That's much different than a true zero downtime rolling update that something like Kubernetes will give you, or if you rolled your own solution to do it without Kubernetes. I don't know if MRSK will handle that, given the direction it's going it's quite possible DHH will implement that behavior in which case that would be very useful.
Rollback is also tricky once you start introducing database migrations. I personally always roll forward.
While these are used to deploy a Scala backend and a Scala.js frontend, I have adapted them many times to work with other backends and js frontends, the logic is the same, the build scripts is what needs to be updated.
For application deployment, I use simple scripts that restart docker compose via shh that we can run from Github actions. Ansible is overkill for that.
Thanks. I made a video and blog post on why I stopped recording it here: https://nickjanetakis.com/blog/taking-an-indefinite-break-fr...
The state of the show hasn't changed since then, it's RIP'd for now. I still have the urge to do the recording bits tho, it's a cruel world!
I very strongly believe:
- Ansible is a great tool for setting up a server to get it to the point where you can run / deploy applications
- Docker Compose is a great tool for running your app
- Git is a pretty good tool for initiating deployments
In my opinion these are 3 distinct things. Trying to make Ansible do everything gets messy, you also lose feedback. For example if you git push, a post receive hook will stream the response back to your terminal but Ansible will only show output when a task is complete.
Using the raw Docker Compose commands also keeps things more consistent between dev, CI and prod. You run basically the same thing in all environments.
Also, it could be implemented using Ansible, but it has been implemented in MRSK. A serious difference if you plan to count on someone to keep it updated and supported.
I actually had a quick look at the code - and at this point it doesn't strike me as a tempting building block.
There's no developer overview i could find (birds eye guide to the MRSK code structure and concepts). There doesn't appear to be much in the way of tests?
Specially - i was wondering how hard it would be to replace traefic with caddy or haproxy, do letsencrypt via MRSK-managed parts of the deployment or drop in varnish.
As best I can tell - there's no clean or sensible way to do any of those things.
Despite that, as a simple Docker glue stick it seems quite useful.
I must say i was disappointed with one thing in the demo - hosting the app on the internet in plaintext covering it with a TLS figleaf via cloudflare. That's terrible guidance in a demo/tutorial.
I have mixed feelings towards NIH people. One bunch is the RIIR crew (ripgrep, ruff, etc.) that produces high quality re-writes with amazing performance and safety, the other bunch is who re-writing tools without any added value.
I am not sure which category MRSK fall into, there has not been enough details from them to justify this particular re-write.
You might think of it as NIH, but I didn't at the time that I wrote it. Because I saw a gap in the ecosystem that wasn't being filled. grep didn't offer the UX of a tool like ag, and ag didn't degrade gracefully to behave like a grep. (And also wasn't as fast on single file search.) That gap is what motivated me to turn ripgrep from what it was (a test bed for Rust's regex crate) into what it is now.
There's a reason why you basically never see me criticizing people about "NIH." Because it's actually quite difficult to accurately cast that criticism. Saying things are NIH is like saying things are broken. It's terribly overused.