Hacker News Reader

Comment by stavros | Hacker News Reader

This looks good, and Dokku has been very solid for me, but removing the Docker dependency means that now I'm beholden to my OS's choices. For apps that might run for years without maintenance, that's not ideal, as you'll quickly find you need a specific version of the OS for them.

View on HN

A different niche than Piku but I will give Dokku another vote.

I've upgraded my dokku install over 3-4 Ubuntu LTS so far and it's been problem free for my use case of hosting little side projects on a VPS.

Have you tried cloud native buildpacks? I posted a link to a tutorial on the top level.

Sometimes docker is overkill and I'm so glad something exists that doesn't require it.

You can use docker with it - I have a couple of things with "docker run" statements in the procfile, but of course it’s not designed for that.

Most of the deployments I got wind of are on extremely stable distros - typically LTS versions where you will not need to upgrade your runtime every six months (and my website has been running in it for at least two Ubuntu LTS releases…)

But you can trivially use pyenv/nvenv/etc. by just setting environment variables. My home automation system now needs two different Node versions, and I have one set per app.

Oh yes, I definitely use LTS distros, but my longest-running apps are from 2008, so even LTS won't cover that.

At -some- point you actually need to update things. If you're using a 2008 docker container you have all manner of bugs and security issues.

But at least the attack vectors are limited

yes, limited to those that work 100%!

I agree. But 2008 is old enough that exploits may be lost in time. I recently pentested a client, and had great problems connecting to an old service still using SSL (i think it was 2.0). Every modern tool straight up refused to connect, there was no method to override that, oldest static curl binaries i could find were still too new, I couldn't easily compile curl from source because dependencies also changed in the meantime. Finally I've found sn acient docker image that worked.

The service was ironically so old that no modern vulnerability scanner or programming language would be able to connect!

This made me seeiously ponder the fleeting nature of modern world - SSL support was everywhere 15 years ago, and now I, as an expert, had great problems using it. What chance do we have in 100 years?

That depends on your tech stack. I have Perl CGI and Java apps that have been running unchanged for two decades. And the only thing I ever had to change on Debian over that time was adding HTTPS (Let's Encrypt) and SPF/DMARC for email.

Yeah, but my point is that you have to upgrade your OS. If you never change anything, obviously you don't need to worry.

My point is that OS upgrades don’t have to break tech stacks, and don’t tend to with runtimes that care a lot about backwards compatibility like Perl and Java. I did regularly upgrade Debian across those two decades.

IMO that quality should be the default, and I would choose my OS and tech stacks accordingly.

Don't they link against static libraries? How do they do that?

The runtimes are part of the Linux distribution and get upgraded along with it (and receive continuous security updates along with it), while maintaining backwards compatibility for the application code (Perl scripts or Java bytecode). Tools like needrestart will notify when a process needs to be restarted to take advantage of the update.

Ah, all your dependencies are in the language you're using? Some of mine use dependencies that are written in compiled languages.

Not necessarily, but they are part of the Linux distribution.

Well, I don't know about you, but my dependencies have often been built against a static library from a different version of the OS, so they wouldn't work on mine.

OS updates are important sometimes. Security and all...

Question - how can dependency hell be solved when using such a tool?

It seems so elegant and I love the "it just works" attitude, and I do understand that docker can't be used everywhere due to its technical (and mental) overhead, but I love it because it allows to isolate everything, freeze everything in time so running a container 5 years for now "just works".

In my humble workflow, I'm using lazydocker to manage the containers, gitlab workflow (action?) for deployment on push and a small VPS to build and push the containers to gitlab registry and to run it, on the same VPS. It's a little bit overkill - I could use a combination of a Dockerfile and a compose.yml with docker compose build. Also, I didn't figure out scaling yet. Good thing I don't need it! Otherwise I would swap docker for k8s and lazydocker for k9s.

(I'm open to suggestions. I just got into devops, and I love it!)

Personally I use the same approach to piku, but instead rebuild my Nixos config on push. My projects use nix flakes, so I get both something that I know will run on my server and on my local machine with the full development environment. No containers needed technically, but I use systemd nspawn to run the software in its own sandboxed namespace.

My entire server is then managed declaratively, so if I want to add a new project, it’s like 3-5 lines of Nginx config and push, that’s all. Something goes wrong? Just revert the commit.

This sounds super interesting! Do you have an example of such a config somewhere, that you can share?

I did a write-up of setting up nixos with git deploys here: https://mccd.space/posts/git-to-deploy/.

As far as the nixos config is concerned, there is nothing crazy in it. It is just a regular nix config with nginx (https://nixos.wiki/wiki/Nginx). You can see there that adding nginx is just four lines of code, ~eight with ssl. Use it to proxy to your applications that are setup as systemd services (https://wiki.nixos.org/wiki/Systemd/User_Services).

Edit: btw I'm a big fan of asciinema! ty for making it. :)

Question, could one use piku for that? (Would it be able to rebuild nixos on each commit?)

I use docker compose + traefik. It's nicer than dokku for me because there are less magical abstractions.

I use nix via jetify devbox. Maybe something like that could help here.

Nix would actually be fantastic for this, but I've never been able to get it to work (including with Devbox and a few other such solutions). I might try again, thank you.

Reply on news.ycombinator.com