[HN Gopher] MRSK: Deploy web apps anywhere
___________________________________________________________________
MRSK: Deploy web apps anywhere
Author : ksec
Score : 186 points
Date : 2023-04-29 14:20 UTC (8 hours ago)
(HTM) web link (mrsk.dev)
(TXT) w3m dump (mrsk.dev)
| m00dy wrote:
| """
|
| gem install mrsk
|
| """
|
| you lost me right in there.
| x3haloed wrote:
| Same.
| hstaab wrote:
| There is also a one liner to use it via Docker on the readme
| revskill wrote:
| The confusing part is, how to put a load balancer in front of
| those deployed servers ?
| alex_suzuki wrote:
| I'm also interested in this setup and have so far only had
| experience using HAProxy. Any alternatives HN can recommend?
| (software)
| datadeft wrote:
| Sorry one of the key part of deploying web applications is not
| part of the offering.
| turtlebits wrote:
| Load balancing isn't part of MRSK - all public clouds offer
| them, Digitalocean does as well. Or DIY with Haproxy, Nginx,
| Traefik, etc.
| lbotos wrote:
| If your "host servers" are known (say 4 backends) you set up
| the balancer and point it to the 4 host IPs.
|
| If you are dynamically allocating host servers and needing to
| register them with the LB you should probably consider K8s?
|
| This is designed for a "more stable" world:
|
| Have some hosts. Have an LB. Deploy containers to those hosts.
| Avoid superfluous k8s complexity that you don't need.
| leetrout wrote:
| I don't think you need K8S for that. Any decent load balancer
| (LB) is going to have some concept of origin configuration
| that weights routing with various algorithms and health
| checks. You would just update the config in the LB when you
| bring a new origin online.
| cschep wrote:
| He sets up a load balancer in his demo video? Did you watch it?
| rileymichael wrote:
| It's not immediately obvious to me how this differs from
| something like ansible which people have been using for years for
| basic deployment topologies. What am I missing?
|
| edit: after looking a bit closer, I think it's a bit misleading
| to call what this is doing "zero downtime". as far as I can tell,
| your services are essentially going to be unresponsive until they
| start, which can be brutal for slow starting ones (and that's
| assuming they start successfully)
| siliconc0w wrote:
| He mentioned partitioning bare-metal into VMs (which is a good
| idea, containers aren't a great security boundary) but it doesn't
| look like MRSK does that (yet?).
|
| I can see using this to deploy on DO or Hetzner to save a few
| bucks vs Render or Amplify- but on bare metal you're giving up a
| pretty amazing ecosystem these days. Ie. if you want to run
| stateful things like databases, logging/monitoring, NFS, object
| storage, persistent disks, complex networking, etc it's going to
| be miles easier to manage that w/ k8s. Even for that bare-
| metal/vm-partitioning goal above, there is a k8s runtime (kata-
| containers) which will automatically run containers on
| lightweight vms and handle all the plumbing to and from K8s. Plus
| if your mid-size SaaS wants to sell to the whales you're going to
| need compliance and security best practices that are much easier
| to implement and enforce w/ k8s. Finally, there are also lighter
| weight distributions these days to make it less painful to run
| yourself.
|
| That said, I do appreciate the 37signals philosophy of having
| such strong opinions they craft their own tools and I also
| applaud leaving the cloud for bare metal. Even if you need the
| burst capacity you can provision your base-load on bare-metal and
| burst to the cloud when needed.
| ricardobeat wrote:
| I had the impression k8s is still not recommended to run a DB
| or any kind of persistence. Are any large companies doing that
| in production?
|
| Regarding logging, object storage, how does kubernetes help?
| You'll have to implement these regardless of the underlying
| container infra.
| nosvince wrote:
| Ondat does that, a bunch of people are using them. And Akamai
| acquired them, probably to scale their model
| seabrookmx wrote:
| Yes. Lots of companies run things like ElasticSearch and
| Cassandra in Kubernetes. And even sharded RDBMS's are doable
| now thanks to projects like Vitess, which famously
| underpinned YouTube. Basically if there's a mature k8s
| operator for the DB in question, it's pretty straight
| forward. The "use containers/k8s for stateless stuff only"
| approach is very dated.
| sickcodebruh wrote:
| MRSK is like something pulled straight from my dreams. Longtime
| Capistrano user, loves Docker for reproducible environments but
| still hasn't mastered using it in prod because I'm a dinosaur who
| just wants servers and a load balancer.
|
| I'm gearing up to deploy a Nextjs project in the next few months
| and while I appreciate the claims of Function this and Edge that,
| I feel infinitely more comfortable with a couple small server
| instances, especially early on when my focus should be testing my
| product, not optimizing my cloud infrastructure for scale that
| might never be needed. I'm excited to give MRSK a shot and feel
| grateful to live in a time when there are so many good choices.
| Kiro wrote:
| > and a load balancer
|
| > not optimizing my cloud infrastructure for scale that might
| never be needed
|
| I don't understand why you would want a load balancer with that
| mentality. Feels like most companies will never reach a scale
| where load balancing is necessary.
| axelthegerman wrote:
| besides scalability there's also fault tolerance.
|
| sure the DB might still be a single point of failure as is
| the load balancer, but some rogue web processes hogging your
| single server or a disk failure bringing it down
| aigoochamna wrote:
| Right... there are a lot of contradictions in their comment.
| You want to focus on your product, by managing your own
| server(s)? You don't want to over engineer early on but
| you're running a load balancer and n-servers? Why not a
| single server? Or, offload the management entirely to someone
| else and focus on your product.
| sickcodebruh wrote:
| It's not contradictory if read with an understanding that
| one can be experienced and comfortable with the amount of
| server management required for a product at its current and
| likely future states. This makes the management piece less
| demanding than evaluating then learning an unfamiliar
| paradigm and the question marks that go along with that.
| lordofmoria wrote:
| > especially early on when my focus should be testing my
| product, not optimizing my could infrastructure for scale that
| might never be needed.
|
| In that case, go with managed services like render, Heroku, or
| fly. MRSK, or any DIY deployment, is not going to save you the
| hours of tinkering you will inevitably do to get the non-server
| stuff up for even a low-usage production app: 1. One-click
| Deploys, basic CI/CD 2. Redis/memcache 3. Database / migrations
| / rollback / backup 4. Logging / metrics / down detection &
| basic high availability 5. Keeping up with basic upgrades
| brightball wrote:
| Honestly, I can appreciate MRSK a little more because I'm
| anticipating running some small stuff out of my house (behind
| Cloudflare) once I finally have fiber next month.
|
| Soon as I have a couple of little home servers in place I
| think this will be a solid model for me.
| mirekrusin wrote:
| He's "dinosaur" probably meaning he knows how to work with
| linux - it'd likely take more time to learn clicking in some
| proprietary page than just doing it so that it works locally
| and remotely.
| lobstrosity420 wrote:
| > especially early on when my focus should be testing my
| product, not optimizing my cloud infrastructure for scale that
| might never be needed
|
| Not to mention vendor lock in, something that really needs to
| be talked about more with this new wave of function this and
| edge that.
| aigoochamna wrote:
| Vendor lock in? Next can be self hosted, deployed on
| AWS/Amplify/Lambda, your own hardware, etc. I wouldn't say
| it's as locked in as some other solutions out there.
| PragmaticPulp wrote:
| Avoiding vendor lock-in always sounds nice in theoretical
| discussions, but in practice it needs to be weighed against
| the cost of additional development time.
|
| In the past decade I've been on several teams that went out
| of their way to avoid vendor lock-in by refusing to use
| platform service offerings.
|
| Every single time it was a complete waste of time. We could
| have saved a lot of time by embracing platform offerings and
| then trying to port to a different vendor only if necessary.
| x3haloed wrote:
| Ugh. This still isn't quite what I want. I can't _stand_ Docker.
| It 's so damn heavy.
|
| All I want is something like the following:
|
| - Sandboxed applications
|
| - With an agent to control which ones run on a machine
|
| - A GUI to easily observe and manage deployments
|
| - Infra-as-code using a sensible file format (anything but YAML)
|
| I imagine this working best with VM-based runtimes like .NET and
| WASM. The ability to control resources consumption isn't there
| yet, but I don't see why you couldn't have a runtime that gives
| fine-grained controls over sandboxing and resource consumption.
|
| This idea came about from observing discourse on replacing
| conventional hypervisors with WASM/WASI.
|
| Forget Docker. Forget OCI. Forget Kubernetes/SWARM. We just need
| a simple system for orchestrating apps that are already VMs.
| WrtCdEvrydy wrote:
| Caprover comes close to this. You can pack your app into a zip
| file and upload it with a special file or choose pre-packaged
| apps.
| MuffinFlavored wrote:
| you hate Docker, OCI, and yaml?
|
| kind of hipster?
| sea-gold wrote:
| Related discussion: "MRSK vs Fly.io" (162 comments):
| https://news.ycombinator.com/item?id=35263886
|
| Also here is the MRSK introduction blog post:
| https://world.hey.com/dhh/introducing-mrsk-9330a267
| deedubaya wrote:
| I'm using it to deploy a dockerized nodejs app, it works great!
| rozenmd wrote:
| do you have a guide that you followed? having tried to follow
| the readme it seems like it only works on DHH's machine with a
| certain configuration of rails and linux
| deedubaya wrote:
| No, just the guide in the readme was all I needed.
| tezza wrote:
| Do not get wedded to that name...
|
| Maersk will be in touch to gently ask that MRSK desist using
| their trademark.
| dangoor wrote:
| IANAL, but my understanding is that trademark law is based on
| the idea of avoiding confusion in the marketplace. It's
| possible to have similarly named products in completely
| different industries without violating trademark law because
| they won't confuse potential buyers of the product.
|
| THAT said, I'm not sure I personally would take the gamble!
| satvikpendem wrote:
| A terminal had to change the name from Terminix to Tilix due
| to trademark issues, even though one is a terminal and the
| other is a pest killer.
|
| https://github.com/gnunn1/tilix/issues/815
| stareatgoats wrote:
| This should probably be seen in the context of this:
| https://twitter.com/dhh/status/1613508201953038337
| hardwaresofton wrote:
| Btw Traefik is an _excellent_ proxy:
|
| https://traefik.io/traefik
|
| Far too few people know about it IMO
| mattjaynes wrote:
| I'm one of the many who hadn't heard of Traefic until MRSK
| mentioned it. The marketing seems very (overly?) targetted at
| cloud microservices and container-specific tech[1]. Is that
| just marketing, or is it really not a good fit for monoliths on
| bare-metal?
|
| [1] https://github.com/traefik/traefik "Traefik (pronounced
| traffic) is a modern HTTP reverse proxy and load balancer that
| makes deploying microservices easy. Traefik integrates with
| your existing infrastructure components (Docker, Swarm mode,
| Kubernetes, Consul, Etcd, Rancher v2, Amazon ECS, ...) and
| configures itself automatically and dynamically. Pointing
| Traefik at your orchestrator should be the only configuration
| step you need."
| klabb3 wrote:
| I've been trying out many reverse proxies for stateful, low-
| traffic websocket connections, but unfortunately they all eat
| so much ram. Even nginx, with tuning, use at least 10x ram/conn
| of a well tuned naked uWebSocket deployment with TLS.
|
| Traefik was much more ram hungry than nginx, and iirc Caddy as
| well (at least 2 goroutines per conn). It's probably fine (and
| worth it) for the vast majority of request-response web apps,
| but all of these extra layers have a cost. And that's still
| nothing compared to the overhead of say k8s with all bells and
| whistles.
|
| Anyway, as someone who's been out of the loop on backend for
| many years, I am quite shocked at the level of resource waste,
| even among the projects with a strong reputation. You always
| hear the complaints about frontend bloat, but these days
| backend seem to have caught up.
| berkle4455 wrote:
| I want to learn Traefik but it yet again has another overly
| verbose config file. They could learn a lot from caddy. Is it
| better enough to deal with learning a new DSL?
| conqrr wrote:
| I'd stick to Caddy. I deprecated my old traefik reverse proxy
| and tls config which took me days to get right earlier mostly
| due to my lack of understanding, but the config and DSL is a
| little tricky too. With Caddy its literally 4 lines of code.
| Sane defaults are really powerful. I don't have any comments
| on performance etc as these are hobby projects, I did like
| traefik's dashboard though.
| tarellel wrote:
| I wish I could upvote this more!
|
| Traefik is absolutely amazing! And it seems like in the
| development community every wants to use nginx. But in my
| experience traefik is absolutely perfect for proxying with
| container deployed applications.
| razemio wrote:
| Really? I believe it is one of the most known proxies besides
| Nginx and apache. Especially in docker environments.
| whitemary wrote:
| Yes, really. I was interviewing last year and used it in one
| of the projects on my resume. Almost nobody knew what it was.
| In fact, exactly 1 out of 25-30 people I discussed the
| project with knew what Traefik was..
| razemio wrote:
| Sad days. I am fairly active in the self hosting scene.
| Traefik is a superstar there right after caddy.
| yunohn wrote:
| > fairly active in the self hosting scene
|
| Though that is probably why - Traefik is popular for
| self-hosting, while Caddy is more generally mainstream.
| ricardobeat wrote:
| Isn't it the opposite? Traefik is more common in the
| enterprise as an nginx replacement for k8s, while Caddy
| is easier to setup and great for self-hosting - I've
| never seen it used in enterprise environments.
| emptysongglass wrote:
| I am not a fan of the 37signals model. Basecamp is a _terrible_
| product. Last I used it with a partner, it still didn 't support
| inline code highlighting. They're very opinionated about
| everything but I don't see their opinions driving good products.
| Kubernetes has been getting better with every release. I'd advise
| companies thinking of doing it better to implement their
| improvements to K8s directly so it can become a scalable, easy to
| use standard for everyone.
|
| 37signals is part of a contingent of reactionary developers and
| you can see this in HEY and now MRSK. It's reactionary without
| delivering real innovative value.
| mirekrusin wrote:
| 37signals is known for sustainable, human-being focused
| development among other things.
|
| They solve problems by breaking them into first principles and
| composing them into shapes that fit them.
|
| They've created RoR which at the time brought together with
| textmate millions of developers onto mac and "programming can
| be actually pleasant and cool" side. Their hero style page was
| copied everywhere on the internet which is visible to this day.
|
| Many unicorns grew from RoR, many use it to this day.
|
| They are open source advocates.
|
| They create environment of certain kind of skepticism towards
| established tech while injecting novel approaches here and
| there.
|
| You're saying something about inline code highlighting and
| jumping onto shitting over whole company and saying something
| about kubernetes.
|
| It's hard to take it seriously even if you have a point there
| that some functionality is embarrassingly missing in one of
| their products.
| dlisboa wrote:
| I think his criticism is warranted when you think of
| 37signals without Ruby on Rails or the open source angle.
| Judging them just on their products.
|
| I don't really see people refer to them as the cream of the
| crop. Basecamp's UX is opinionated but still complicated: I
| get lost on it even though it's a simple product. It seems to
| work well for a team more similar to 37signals'.
|
| Hey.com I haven't seen take the world by storm, even though
| it does seem better than most e-mail software (and I do
| appreciate their technological solutions on it). I guess most
| people don't have that problem with e-mail that the Basecamp
| founders do.
|
| That's a bit of a trend for them: they often claim people
| should do one thing and everything else is worse, even though
| that one thing really works for them and might not work for
| anyone else. Their agile methodology, their team size, their
| tech stack, etc. they often pose themselves as the "sane"
| ones doing it simple and easy, while everyone else is chasing
| the wrong thing.
|
| So in that sense I can see why OP said they're reactionary. I
| would disagree, however, as they've been revolutionary on
| many fronts, but it's usually as part of a contrarian view
| that sometimes is more of a miss than a hit.
| madeofpalk wrote:
| > human-being focused development
|
| So human-being focused a third of their human-being employees
| quit after the CEO wrote a blog post!
| https://www.theverge.com/2021/4/30/22412714/basecamp-
| employe...
| yunohn wrote:
| Upvoted this, because opinions about an opinionated product
| should be allowed.
|
| Fully agree that 37Signals' products are very opinionated and
| often missing crucial features. I can see that they fulfil some
| use-cases, but could be more mainstream.
| LapsangGuzzler wrote:
| I don't have a problem with opinions on products, but urging
| people to "do x instead of y because standards" is such an
| intellectually lazy take, especially when the party being
| criticized has led development on some of the most
| influential open source projects in history.
|
| I'd love to see OP do anything as remotely influential in the
| industry as DHH.
| yunohn wrote:
| > I'd love to see OP do anything as remotely influential in
| the industry as DHH.
|
| I vastly prefer their appeal to standards over your appeal
| to authority.
| mirekrusin wrote:
| Their standard is rational thinking though first
| principle decomposition - if it still holds through their
| evaluation, it'll stay as standard, otherwise it's not a
| standard from their PoV.
| [deleted]
| claudiug wrote:
| inline coding == BAD company, very opinionated everything. but
| you better to use: https://kubernetes.io/ because they are good
| people. /s
| axelthegerman wrote:
| Some people like some products other people like others. There
| are tons of terrible products out there and many of them are
| also completely overengineered.
|
| 37signals and DHH did a lot right with Rails, so I'm looking
| forward to trying their approach on deployment.
|
| IMO kubernetes is quite a lot of moving pieces that are
| absolutely not needed for most deployments, if you like it
| great! I'm sure many will love the opinions guiding MRSK
| (myself included).
|
| I personally wouldn't touch K8s but I'm also not telling anyone
| not to try it.
| intelVISA wrote:
| I'm first to crap on K8s but I do agree w/ you here...
|
| Feels a bit surreal seeing a 'tool' that wraps Traefik + Docker
| Swarm be so self-aggrandizing.
| benatkin wrote:
| > I'm first to crap on K8s
|
| OK to each their own.
|
| Do you object to YAML? Kubelet?
|
| It seems like a pretty solid approach to me. Some have been
| misdirected by it because something that uses a sizable
| fraction of a CPU doesn't work for their use case, but that
| speaks more to the lack of an alternative to Docker Compose,
| which Kubernetes wasn't intended to be.
| intelVISA wrote:
| I was griping re: MRSK not so much K8s.
|
| Kubernetes is 'fine' in the sense that a sledgehammer can,
| technically, open a door...
| jfvinueza wrote:
| Except they're fast and built with care, with graphic design
| given as much importance as technology itself (as in actual
| "interface problem solving", not "the same product as everyone
| else's, but with gradients and transparency"). Navigation's
| different but it's very good. The text editor is best-in-class.
| I don't prescribe to the notion that a professional worker
| should always have 64gb RAM so both Notion and Jira can be open
| at the same time, and I for myself appreciated that whatever
| page I was on was just a single page, an slightly interactive
| html page, and whenever I needed to go somewhere else I'd
| browse there clicking on hyperlinks, and get there fast. It
| might sound dated, but compared to, say, Asana and Monday or
| dear god Microsoft or Jira's "reinventions", it's really many
| years ahead.
|
| (I have nothing to do with the company, just a happy client)
| gherkinnn wrote:
| One might or might not like 37 Signals and their products.
| Some of their ideas are fantastic, others not so much.
|
| But claiming their text editor to be best in class when it is
| literal dogshit is brave.
| c-hendricks wrote:
| Nice, this reminds me of something from a few years ago:
|
| https://github.com/mikew/b3cmd-server
|
| https://github.com/mikew/b3cmd
|
| This used docker-compose + git.
| emkrawiec wrote:
| looks nice and tries to solve a problem i had a while ago: how to
| deploy a small dockerized app to a cheap vm with declarative
| deploy (like k8s) but without k8s.
|
| anyone know a similiar tool?
| doublepg23 wrote:
| Am I missing the problem with just docker-compose?
| simo7 wrote:
| You can ship your local docker context to a remote host and
| build/run your containers there. All the docker commands you
| typically run locally you can run on the remote host.
|
| https://www.docker.com/blog/how-to-deploy-on-remote-docker-h...
| mati365 wrote:
| Why not use just podman systemd service (with quadlet)?
| emptysea wrote:
| I don't think podman systemd integration handles blue/green
| style handoff, but pod man's integration is pretty nice.
|
| Really painful to manually call a docker container from systemd
| normally, lots of edge cases to manage
| mlangenberg wrote:
| Can MRSK be used to manage deploying applications that are
| distributed as Docker images, such as Adguard Home?
|
| I see there is support for 'accessories' such as Redis. What if I
| only want to deploy an image and skip building a Dockerfile and
| pushing it to a registry?
| xrd wrote:
| This looks to me like something that has 5% of the features of
| dokku. If you want a slimmed down dokku that seems great. But I'm
| wondering if I love dokku why I would choose this. What am I
| missing?
|
| The switching to live containers and proxy integration seems like
| table stakes these days. Is traefik that much better than nginx
| in all cases?
|
| And, dokku just works with almost any kind of web app (regardless
| of the language) i throw at it. It's amazing for just git cloning
| something, create a dokku app and new git remote and then just
| push and see if it works, which it does almost all the time. It's
| super fun to experiment with something new and just see what
| happens.
| axelthegerman wrote:
| used dokku too but faced a couple of issues over time including
| very slow deploys for some reason.
|
| also fubdamentally dokku is single server whereas MRSK is
| multi-server. not that I need that but worth pointing out as a
| difference
| josegonzalez wrote:
| Dokku Maintainer here.
|
| I'd love to hear more about the issues you've faced, even if
| you're not using Dokku anymore. It helps me improve the
| project for others.
|
| Regarding multi-server support, we support Kubernetes and
| Nomad for job scheduling - and have for years - which I think
| should make us multi-server capable. Are you looking for
| something else?
| ricardobeat wrote:
| MRSK is a bit more focused on deployment and server management:
| it only needs SSH access to configure a server and deploy your
| application. Dokku still requires managing/installing servers
| manually.
| Cyph0n wrote:
| So it's trying to both tackle provisioning and deployment at
| the same time? Why not just use more powerful tools for each
| role - e.g., provision with Ansible and deploy with Dokku?
| josegonzalez wrote:
| Dokku Maintainer here.
|
| Is the issue that you only need to `gem install mrsk` locally
| vs running our bootstrap script to install Dokku on a remote
| server? I'm not sure what the difference is maintenance-wise
| between Dokku and MRSK, as at the end of the day you still
| have a server you need to maintain/upgrade for both products.
| josegonzalez wrote:
| Dokku maintainer here.
|
| For anyone wondering, Dokku supports Traefik in addition to
| Nginx, as well as Caddy and Haproxy.
| Thaxll wrote:
| It's 2023 and a dev deploying an app needs to know the physical
| IPs of a machine it's going to deploy on, really good design.
| rudasn wrote:
| Its in the same repo, yes, but don't have to care about it,
| just as you may not care about Ci artifacts or editor config
| files, or gitignore files or whatever.
|
| That info has to live somewhere, and in the same repo as the
| code doesn't sound that bad.
| tylerjl wrote:
| Slightly off-topic, but my ChatGPT instincts always tend to fire
| whenever I read copy that concludes with the formula,
| "Ultimately..." or "Overall...".
|
| I wonder how much (if any) of this landing page was GPT
| generated.
| satvikpendem wrote:
| How does it compare to Coolify?
| [deleted]
___________________________________________________________________
(page generated 2023-04-29 23:00 UTC)