I needed something that would restart containers automatically when I pushed to a branch, so I wrote a few lines of code to do it:

https://gitlab.com/stavros/harbormaster

As far as PaaSes go, it's probably the simplest, and works really well.

> It also cleanly stores data for all apps in a single data/ directory, so you always have one directory that holds all the state, which you can easily back up and restore.

Ha! I'm store my data in /data for ages. The only difference is what at first I bothered with tinkering with datadir paths in configuration files, nowadays I just symlink /var/lib/whatsitsname to /data/whatsitsname. I'm lazy and boring.

Funny I did something similar but only much easier. A cron job that ran every 5 minutes doing a git pull on the production branch and since it was a PHP stack the new version was live instantly without needing rebuild or restart of any service

It's basically a oneliner in bash. KISS

That's good when you only want updates, but I wanted to be able to launch new services on the server by just pushing a new YAML file to git. Harbormaster does it wonderfully, and it lets me see exactly what's running on the server and how with one look at the YAML.

I can also back everything up by just copying one directory, so that's great too.

This to me is boring and simple technology. Well done.

Thank you! I really like it, it's been working great for a while now, with no hiccups.

Disagree. The over-engineering rot starts with Docker. Solo devs do not need Docker. It's not a stability issue, it's an appropriateness issue.

If you produce a static binary and can copy it to the server, sure, Docker might be overkill. But how do you reproduce an ensemble of services and their exact version in prod environment? Even just having a stable dev environment by using Docker images with fixed version for database and other auxiliary services is very valuable.

You can use something like Nix or Guix for example.

Bonus: it produces OCI images also.

While this is definitely a valid option I'm not sure that introducing Nix/Guix simplifies the stack compared to using Docker. Depends on the setup and experience, I guess.

I love Docker as a solo dev:

- builds and dependency management, all in one

- works “the same” on my laptop and server

- there’s an easy way to reset services when they break

How do you `docker push` from your laptop to the server with consumer broadband? I've heard docker times out after about 50-75%. Great fun.

This might be a "person in a country with pretty fast internet connection" opinion but I don't think I ever had that issue. Might also depend on the container size, pushing > 1GB containers might be more error prone than pushing small(ish) containers.

Sounds like you need a better internet connection.

Why use Docker on a managed container service when you can just pay more to manage your own VMs, VPC, reverse proxy and blue/green deployment infrastructure?

agree at a gut level, but look how productive people are .. ps- checkout podman

Agreed.

Containers... just work? Actually, Docker just works. It is rock solid and I'm very delighted I learnt so much of it.

The only thing I'm missing about Docker is a bigger focus on on-the-fly image editing. Like, I love to have these container development environments. I'd love to give some command inside the container and make it magically appear on the Dockerfile if it was successfully executed, so I don't have to manually copy things over when I want to have reproducibility for later.

Docker is incredibly stable, and since it turns 10 years next year, OP will finally be able to migrate away from having a build step on production servers! ;-)

> I like docker-compose because it restarts containers.

Still sounds like over-engineering to me. It's trivial to make systemd supervise a service and automatically restart it on failure.

Honestly they're both easy technologies to learn and master.

Can say the same for ci/cd. Author talks about integration tests, setting a barebones "build this and deploy it" pipeline is far more trivial and skips having to do it manually every time.

It's interesting that some engineers look at docker and ci/cd and say "that's too complicated" and others look at a system without it and say "it needs to be simplified"

Inexperience or difference in experiences. I wouldn't necessarily advocate containers as my experience has been mostly "this takes far longer than the gain" (given the OP's scenario).

Meanwhile, my experience is a minimal CICD pipeline takes half an hour once you know manual deployment, and I lose far more having to SSH and run scripts myself than telling a machine to do it for me (not just time but mental satisfaction too).

Though I wouldn't call either fancy in this year. Only past that stage, where the benefits drop sharply for individuals.

Containers are more than just Kubernetes

I definitely not believe that Docker images are boring, they are full of constant issues and stuff you have to keep track on the top of the fact they are not composable in many ways.

Rootfs is the boring technology, their semantics is clear and most kernels have support for them.

Better: use systemd which has became truly boring and restarts your services automatically and if you don't like systems, plenty of alternatives such as s6 do exist.

For few of the small API-mostly apps I am particular to just embedding the statics into binary and have one blob to run and deploy, go:embed making it particularly easy.

Container with it is just a few files in etc and binary blob itself. Same with container-less deployment.