Comment by josegonzalez | Hacker News Reader

Comment by josegonzalez | Hacker News Reader

Parent Full thread

Dokku Maintainer here.

This is pretty neat. One of my gripes about docker-compose - and a major why I've been hesitant to add support for it - is that the updates are not zero-downtime. That makes it much more annoying to use for app deploys as you either have to rewrite the compose command as a docker command (defeating part of the purpose of a compose file) or accept the downtime during a deploy. I'll definitely be including this tool (or something like it) with Dokku once I actually add compose support.

Combining this with either Caddy Docker Proxy[1] or Traefik[2] could be quite nice for a very simple app deployment system.

Would be super awesome for this functionality to land in the official `compose` plugin, but for now this is a great way to dip your toes into app deployments without too much overhead.

There is a small island of productivity tools around docker-compose that would be super nice to build, and it's nice to see something like this land :)

  - https://github.com/lucaslorentz/caddy-docker-proxy
  - https://doc.traefik.io/traefik/providers/docker/

This is slightly off-topic, but does Dokku take care of host level security at all? Or do you have secure the server normally before using Dokku?

It doesn't, mostly because it's a fairly large area to have opinions about, and not everyone agrees on what is required (in fact, I know of at least two orgs using Dokku that would definitely not agree on each others requirements).

Honestly I think Dokku is complex enough as is without me trying to hamfist my idea of security onto a user's host. I don't think I know enough about the topic to make good decisions that everyone will agree upon (and will be friendly enough to users to not make them upset with Dokku).

Ah I see. That's a fair point. With Heroku you delegate both (1) the server management and (2) the deployment aspects of an application. Dokku seems to solve (2), I hope someone will come up with an automated solution to turn a linux box into a secured application runtime.

I use digital ocean apps and can't help but feel grifted, the price for what you're getting in specs is terrible compared to a VPS or a bare metal. The same is true with Render or Fly. But I just don't have the time or confidence to run my own server.

I feel like there is an opportunity for huge savings here, I just need that fictional piece of software.

Yeah that makes sense. I really liked Triton from Joyent, as it provided a neat host os that could essentially be looked at as a multi-host docker installation but didn't run much else. You could then run the Dokku docker image on top of that and only really expose `nginx` (for routing) and `openssh` (for builds and interacting with Dokku), limiting your surface area. You can do this today if you wish on top of Alpine Linux or some other small host os, but that only takes care of half the problem (the other part being firewalls and detecting intrusion attempts imo).

Any chance Dokku will ever run on OpenBSD? Its philosophy of "everything disabled unless you need it" would make it an excellent choice from a default-security perspective.

Dokku mostly uses existing "unix" tools or golang binaries, so it should in theory work (buildpacks are another matter, as they are mostly written for Linux, but a Dockerfile-based build should work). The big issue is actually interacting with the Docker daemon, as that is Linux only. If you could provide a `docker` binary on the host that was a wrapper around Jails for the commands we use, it should work just fine.

That said, I don't use BSD and wouldn't have time to investigate adding support for any of the BSDs.

what about zero downtime in batch processing services/cron jobs instead of “only” services that serve HTTP requests

Thats a bit more difficult. I don't think there is a great way for cron jobs other than triggering them and reverting if there are errors, though I haven't seen a single deployment tool that would do this.

For batch processing, Dokku checks the process uptime - if the process stops/restarts within X seconds, its likely unhealthy, and the deploy should be reverted. Some frameworks expose http endpoints that can be used to perform healthchecks as well.

At the end of the day, monitoring for errors in an error tracking service - such as Sentry - and seeing if new errors start spewing for a given deployment is probably the only better thing folks can do, although reverting code isn't always straightforward.

God, I'd love compose support in Dokku.

What exactly is the problem with short downtime during updates/deployments? A lot of people don't care if their deployment requires a few seconds of downtime. And most users of $randomwebsite don't really care if they need to hit reload button every now and then.

If you work on a site with production traffic that you care about, you won't want users to see intermittent errors.

Even if you are OK with the occasional error like that, if your deployment system DOES produce intermittent errors, you'll deploy less often... which can become a significant drag on your overall culture of shipping new code.

You'll end up wanting to bundle fixes together and deploy them once a twice a week, where the same team with zero-downtime deploys might happily ship new code to production several times an hour.

So I see zero-downtime deploys as a very impactful way to encourage a healthy culture around shipping code often.

They're also one of those things that's relatively easy to engineer into a system early on, but ferociously difficult to add to a system years down the line when it's already serving large amounts of production traffic and has lots of existing code already built for it.

Honestly, I have a slightly different answer than most; because there shouldn't be.

Docker already goes through great pains to achieve much of what it can do, and it would be bizarre to go through the effort to use it and then not take advantage of some of the core things it can enable. Even without Docker, service managers like systemd can be used to implement zero downtime deployments too.

At this point it'd feel weird and broken if a service management tool just had no support for a "gapless" deployment. I'd feel uneasy using it.

The way I see it, what Kubernetes does with health and liveness checks is actually just good hygiene irrespective of how many requests you can tolerate dropping, or if your container even serves requests to begin with. Tools that manage services should strive to provide similar functionality where possible.

Dokku is in use in production by a large number of companies. Those companies might setup Dokku on a single, large host - perhaps collocated somewhere - and not want to have downtime for their product(s). Others host a swarm of Dokku installations and also want to avoid downtime during deployments.

I suspect that "most users" will actually bounce if a site is down for more than a few seconds, or at least become frustrated with the availability of the site they are accessing.

Aside, I'd rather not field support requests from folks about how one of the main features Dokku promotes doesn't work when they configure it one way or another.

I guess if you have great ambitions about "web scale" and client retention, a few seconds downtime on your website might mean a loss on a significant amount of potentially new customer.

As for me, I actually like downtimes. We have data migrations to do anyway on most major updates (they are automatic when the new container boots but the app is unavailable), which can sometimes take hours, and that leaves us notifying our customers for updates and gives us time to do some sanity checks before handing them over control.

Compose is a great tool for single (and probably few) VM(s) deployments. I used to love swarm for slightly bigger ones as well since it's a lot easier to manage than kube and can easily be tailored to ones need, still sad it's being deprecated.

Classic Swarm was deprecated and hardly anyone has been using it.

Swarm mode, which everyone usually is talking about is not being deprecated. Docker 23.0.0 shipped with new features for Docker Swarm.

https://docs.docker.com/engine/release-notes/23.0/

The apps that I build (and use dokku to deploy - thank you josegonzalez, it's a great tool) are critical to their users.

While ten, twenty, thirty seconds isn't much in the grand scheme of things, if it happens just as someone is doing an important update, it reduces trust in the software. If it happens a couple of times, they're going to report back to their boss that the system is unreliable and fails just when they need it most.

And with international users, I can't be sure that I'm picking a time to do a deployment where no-one is going to be using it.

Zero downtime deployments are just a side effect of doing any kind of A/B deployment.

The same features can help you avoid longer downtime. I use dokku at home to run a little web portal. I have a CHECKS file in the repo that has

  WAIT=1
  TIMEOUT=1
  ATTEMPTS=10
  / Portal
  ...

If I try to update to a new version and the site doesn't come up at all (or a GET for / doesn't have "Portal" in the response), the update is aborted and requests never fail.

It depends on the site.

If there are a lot of users and you need to deploy an update during the middle of the day, even a little downtime could be disruptive.

If you have a global audience then maybe there's no safe "after hours" time to deploy.

Zero downtime deployments are fairly critical for a lot of Continuous Delivery / Deployment workflow, so more solutions the merrier as far as I'm concerned.

Why few seconds? Some java applications can easily take minutes to initialize.

But that's a bug that could be fixed.

In the Java world very long start-up times are a feature, not a bug

People might not care, but APIs do.

I'd say it's the other way around. Any sane API client would retry for 503. But people might not.

Reply on news.ycombinator.com