The Dokku Trap | Hacker News Reader

The Dokku Trap

edouard.peller.in

23 pointsedp22 comments

I'm not too sure the fault here lies with Dokku. In their defense they use herokuish [0] which in turn uses Heroku build packs and apparently, from the commit, it's more of a build pack issue. However you can fork the build pack and revert the changes to suit your environment. Have a gander of this section in the Dokku docs [1] on how to specify a custom build pack.

Don't throw away the convenience Dokku brings to the table :-)

Y'a t'il une raison pour laquelle puka n'a pas de site en anglais?

[0] https://github.com/gliderlabs/herokuish

[1] http://dokku.viewdocs.io/dokku/deployment/buildpacks/

You're right, the root of the issue is with the buildpack and we could fork it to have a "stable" environment. I wrote dokku as a shortcut to encompass these types of PaaS. For now we'll be using tomcat and a war package, dokku is really interesting but there are too much unknowns on our end.

The marketing website of puka is only in french right now (this will be our primary market), but the application itself is fully translated in english. You'll find a link in the top right corner "Accéder à l'application".

It sounds like you'd want to lock to a specific version of the java buildpack, before 94276a, which dokku supports, according to the docs provided in the GP comment:

> You may also wish to use a specific version of a buildpack, which is also simple

    # using v87 of the nodejs buildpack
    # replace APP with the name of your application
    dokku config:set APP BUILDPACK_URL=https://github.com/heroku/heroku-buildpack-nodejs#v87

http://dokku.viewdocs.io/dokku/deployment/buildpacks/

Tomcat could have a bug change under you as well. I don't see how its different. Maybe more stable? Boring?

Sure there is that, but nothing fundamental about Dokku is different-- its just newer.

Yes, but in my case tomcat is provided by the distribution and I'll see when an update is coming (and to be honest, like you said, tomcat is pretty boring, which is good in my opinion). By default, dokku/herokuish will download the latest version of a buildpack, that's what got me this time. As other commenters pointed out, I could lock down a specific commit for the buildpack, I'll try that in the future.

As I've commented on your reddit thread, dokku/herokuish don't automagically upgrade themselves. Herokuish is pegged to specific buildpack versions, and you would have to manually upgrade it - or have automatic system updates for non-security releases - in order to have newer versions of the buildpacks automatically installed.

Other than the fact that you happen to be running dokku, nothing about this problem is dokku-specific, and you would have hit the same issue with heroku.

As with almost every software in the world, silent version changes may break things. This is why npm, bower, rubygems, maven, python's requirement.txt and almost every other package management system allows you to specify the exact version of a dependency and begs you to use it in production. This is also why you need a staging environment that is as close as possible mirror of production.

Seems like you failed to RTFM

All our dependencies in maven and bower are locked down. However, even though you can do the same with a buildpack, this is not exactly what heroku and dokku will do by default. The documentation [0] specifies a way to do so with a git based system, but all commands given on that page won't specify a tag. Note that this was not in production, like I said in the article, it was an internal release.

[0] https://devcenter.heroku.com/articles/buildpacks

Dokku/herokuish do indeed lock down to specific buildpacks [1]. You just happened to use a method that allowed you to use any version of that buildpack (multi-buildpack, which is provided by Heroku itself).

[1] https://github.com/gliderlabs/herokuish/tree/master/buildpac...

Disclaimer: I used to work on Cloud Foundry buildpacks, several of which are soft forks of Heroku's.

So obviously, my recommendation is to switch to Cloud Foundry. Each release has a single, fixed set of components which are predictable. You can also upgrade buildpacks independently of the overall CF installation.

The problem is that switching to CF from Dokku is a tremendous increase in complexity. I've been exploring open source/self-hosted PaaS systems for the company I work for, since the manual installs are getting hairy.

While trying CF, I first had to get the BOSH cli, then vagrant, then create a VM for the BOSH director, then I had to generate a CF manifest for BOSH (which apparently tries to install Ruby gems, and so fails without root), then out of the sudden a new concept - "stemcells" - appeared, so I choose one that seems appropriate. I couldn't continue, since by then my drive was full (I only had 4GiB free, and though it'd be enough for a bare installation). And at then end, it seems like one gets a system with a whole bunch of moving parts at various layers.

I don't doubt that CF is a good tool, but moving from Dokku - essentially an extremely thin layer over Docker - to it is like upgrading directly from a 12v solar panel in your backyard to a small nuclear reactor.

You're right. But it's complex because this is an irreducibly complex problem space. Making distributed systems Just Work can't be made simpler.

So there are two alternatives: first is to use a hosted CF. There are several. My company has one in Pivotal Web Services. IBM BlueMix is a Cloud Foundry instance. There are others around.

The second alternative is MicroPCF. It's a new project specifically intended to allow you to run a full CF on your laptop.

https://github.com/pivotal-cf/micropcf

You're right. But it's complex because this is an irreducibly complex problem space. Making distributed systems Just Work can't be made simpler.

Yeah, but that's my point: I want a PaaS for the ease of deployment and upgrade, but I don't actually need a distributed system; all our servers work isolated from each other, only receiving occasional commands from our office.

Unfortunately, it seems I have to choose between barebones deployment helpers like Dokku and systems designed to deploy Twitter and Whatsapp. We're more like WPEngine - where's the PaaS for them?

I'll look into MicroPCF, but is it production-ready? Sounds too focused to the development phase.

To repurpose an old joke: You might not believe in the problems of distributed systems, but they believe in you.

It sounds like your problem is more IAASy. For which you might tinker with BOSH. Or if you just need to run remote commands, there are a lot of systems that'll piggyback on SSH for you.

In dokku's case, he is also pegged to a fixed set of components. Installing herokuish - which is installed via a package - will install an exact version of each buildpack. If it is upgraded, then new versions are pulled in.

The same exact issue would have been seen with Cloud Foundry.

I stand corrected. Thanks.

I use dokku, but instead of using buildpacks I just write Dockerfiles directly. That way you'd never experience a problem, really.

Wait until you run out of disk while running PostgreSQL with dokku. That's an adventure I don't want to have to repeat.

You can run out of disk space using anything. Might be worth setting alerts on Disk/Memory/CPU for your servers in the future (New Relic has that).

Dokku is currently meant to manage the application deployment lifecycle, not everything related to server management.

Lol completely abanding dokku over having to disable ssl seems overkill... Not to mention... Shouldn't you be using Sal anyways?

You missed the point, it wasn't about ssl, just the fact that something changed the runtime behaviour of the application and I didn't see it coming (which was a failure on my part).

I think Dooku was a terrible character in a terrible movie.

Reply on news.ycombinator.com