Hacker News Reader

Comment by mdasen | Hacker News Reader

For me, one of the big catches is that you have a single point of failure. Dokku doesn't run over multiple VMs you have. It's on a VM. If that VM goes down, you're down.

I think one of the selling points of Heroku is that if the box you're running on goes down, your service will just be started on another box and traffic will be routed there and you don't need to do anything.

View on HN

One way to overcome that might be to use ansible to automate:

  1. Dokku setup on a new server 
  
  2. Deploy your app from a git repository

  3. Restore your database from backup

If you aren't comfortable with ansible you can use Fabric [0] or Sup [1]. I think there's even an ansible guide for Dokku deployment on their blog [2].

[0] https://www.fabfile.org/

[1] https://github.com/pressly/sup

[2] https://dokku.github.io/general/automating-dokku-setup

If you want a much more highly available open source Heroku, there is Cloud Foundry which is used as the basis for a few public PaaS like IBM Bluemix and SAP Cloud Platform. The smallest HA set up is about 50 VMs though, and it's complicated to deploy so not really worth it if you have fewer than 1,000 or so developers to support.

Super complicated, tried it several times over the years.

One would think it will get better in newer versions.

But nope..

Didn't try it the last 2 or 3 years though

If the box you are running in is a VM, the VM host is already providing hardware redundancy. It’s not full redundancy but in practice it’s sufficient for dog photo sharing sites.

As far as I know only Google Cloud does ‘hardware redundancy’[0]. I’ve had single-instance outages in AWS and they don’t seem to really care if something goes wrong with your instance, although maybe they have more maintenance events than they let on and they might happen transparently to the user thanks to some form of live migration.

0: https://cloud.google.com/compute/docs/instances/live-migrati...

I’m not talking about live migration - the instance will go down and there will be a brief outage while the instance restarts on another hypervisor. The same is true of a single dyno Heroku app.

For AWS, nothing involved there is automatic; you have to stop it* and then restart it. It will just stay broken until you restart it yourself. "Brief outage" suggests it might be automatic but in AWS it's not.

* Possibly multiple times. Instances on degraded hosts have a tendency to get stuck and you have to stop, and then stop again to force stop it, and then sometimes even that doesn't work and you have to just wait.

Source: have received lots of "EC2 Instance Retirement" emails

Not any more. https://aws.amazon.com/about-aws/whats-new/2022/03/amazon-ec... In theory. But yes, sometimes detaching resources can take a long time on a degraded host.

This is what autoscaling groups are for, right? If set the autoscaler to keep one instance running it will spin another one when they retire the one you’re using.

“Weeks of reading AWS documentation will save you hours of learning about infrastructure”

the topic is here is ease of use.

Comparing Heroku to VMs and correctly configured ASGs is fine for me as a sysadmin, but they’re not targeting the same simplicity.

Yep, and if you know enough to set that up, you probably don't need Dokku.

An ASG isn’t nearly as difficult as setting up, securing, and running dokku. There’s even examples and such for setting up the ASG. If you get stuck, all accounts have free support and stack overflow is a few clicks away. The idea that one needs to switch to dokku to avoid setting up ASGs is just silly.

My suggestion was the opposite: don't use Dokku, because you probably don't need it if you're capable of dinking around with AWS.

Dokku has official support for k8s and Nomad if you want multiple-host support. The caveat, of course, is that you have to run the cluster.

Oh, hey! I used Dokku back in the ... I want to say 2012-2013 ? and missed multi-node stuff a bit (nothing that couldn't be scripted around) so this looks cool.

I do see that it shouts 'EXPERIMENTAL!', so I guess it's 'experimental, but official'.

Dokku Maintainer here:

The warning there is more that if the scheduler plugins land in the core (which I hope to do some day), the official usage may change.

For instance, I'd love to abstract our ingress plugin such that it plays nicely with Kubernetes and Nomad (Nomad in particular, since there is no notion of ingress there at all) but that may mean that the ingress controlling functionality in the Kubernetes plugin changes signficantly.

Dokku _also_ has no notion of autoscaling at the moment, though both Kubernetes and Nomad have autoscaling tooling. It would be great to expose this officially somehow vs the plugin-specific method that is exposed in Kubernetes.

Note that at least the Kubernetes plugin is in active usage - even in at least two commercial products being actively sold.

Dokku maintainer here.

The catch you mentioned has a few caveats:

    - You can host the data for the install on a mounted volume, and replace the underlying instance at will (if you're using something like AWS or GCP).
    - We support alternative schedulers (Kubernetes and Nomad, with others like Compose, Lambda, and Swarm coming soon). In the case of using an alternate scheduler, your apps won't go down if the build server goes down.
    - Since it is self-hosted, your Dokku install's uptime is pegged to your infrastructure's uptime. So yeah, if you are installing it on a Raspberry PI whose uptime is decided by a light switch that is next to your kitchen and you accidentally switch it off every once in a while due to not being able to see the switch at night (very specific example, I know), then yeah, you'll be down for a little while.

Redundancy is kinda your responsibility...

I may have read your comment wrong but it would be wholly unfair to expect Dokku to provide everything and the kitchen sink gratis.

If a service is marketed as an "alternative" to any competitor, I think it's generally reasonable to assume that service covers most of the basic features offered by that competitor.

I've seen tons of "Heroku alternatives" pop up over the past couple months, but they all seem to have (rather large, IMO) downsides of "it does A and B like Heroku, but not X, Y, and Z" (where again, IMO, X, Y, and Z are typically rather core features like redundancy/failover). I know everyone uses services for different reasons, but the general appeal of Heroku that I've seen has been the basically-zero-devops-ever-necessary-for-anything approach they've taken.

If you are looking for a HA alternative, Qovery is the one. It's a Heroku like platform running on AWS built for running production workload. It's multi AZ by design.

(I am co-founder)

Can it be licensed and run on bare-metal?

Reply on news.ycombinator.com