Comment by progval | Hacker News Reader

Comment by progval | Hacker News Reader

Parent Full thread

> Whats the alternative to running a big project like say Sourcegraph through a docker compose instance? You have to get set up ~10 services yourself including Redis, Postgres, some logging thing blah blah. I do not believe this is ever easier than `docker compose up -d`.

Even with Docker, it's not as easy as `docker compose up -d`.

You need to setup backups too. How do you backup all these containers? Do they even support it? Meanwhile I already have Postgres and Redis tuned, running, and backuped. I'd even have a warm Postgres replica if I could figure how to make that work.

Then you need to monitor them for security updates. How are you notified your Sourcegraph container and its dependencies' containers need to be updated and restarted? If they used system packages, I'd already have this solved with Munin's APT plugin and/or Debian's unattended-upgrades. So you need to install Watchtower or equivalent. Which can't tell the difference between a security update and other updates, so you might have your software updated with breaking changes at any point.

Alternatively, you can locate and subscribe to the RSS feed for the repository of every Dockerfile involved (or use one of these third-party services providing RSS feeds for Dockerhub) and hope they contain a changelog. If I installed from Debian I wouldn't need that because I'm already subscribed to debian-security-announce@lists.debian.org

Long lived data is stored as a volume which is just a directory on the host. You just backup the directory like you would any other.

I feel like people are misunderstanding.. containers are a wrapper. You can run whatever APT plugin or unattended-upgrades on the container as well its just linux. You can then even snapshot this new state of the container into a new image if you want to persist them. Like you can fully simulate the usual workflow of a regular server if you really want. They don't take away any functionality.

Another thing is docker is not necessarily the be-all end-all way to deploy things especially in production. If I was running Sourcegraph seriously in production, I might not use it. But it does make it so much easier to just try things out or run them as a hobbyist.

> You can run whatever APT plugin or unattended-upgrades on the container as well its just linux.

Only if the software inside was installed with APT. When you just do `docker compose up -d` you have no idea how software inside is installed so you need to poke around as if you had installed it without docker.

> Another thing is docker is not necessarily the be-all end-all way to deploy things especially in production. If I was running Sourcegraph seriously in production, I might not use it.

But containers are increasingly the only supported method, because developers assume every production's constraints/preferences look like their own. For example https://docs.sourcegraph.com/admin/deploy only lists the following options:

* VMs

* "install script" unsuitable for use outside a dedicated VM: (re)installs k3s (as a one-off without updates as far as I can tell), overwrites existing config files, disables firewall

* k8s

* Docker-Compose

> But it does make it so much easier to just try things out or run them as a hobbyist.

Sure, I definitely agree with that

I really don't know what other production methods you would expect to find before docker.. install scripts and READMEs is pretty much all there is or ever was for complex software with many interlocking components. I don't really think there's ever been a way to install an entire stack like that from a single apt command. It's always been bespoke scripts and procedures with a lot of manual steps.

What I expect is a list of dependencies I can install myself, instructions to compile the code, and a description of config files to write/edit, eg. to point the main software to its dependencies' URLs. Like this, for example: https://docs.joinmastodon.org/admin/install/

Yes this is called a Dockerfile. Better yet, its not just a list, its working code so you don't have to run through the list manually.

While a readable Dockerfile can work as documentation, there are a few caveats:

* the application needs to be designed to work outside containers (so, no hardcoded URLs, ports, or paths). Also, not directly related to containers, but it's nice if it can be easily compiled in most environments and not just on the base image.

* I still need a way to be notified of updates; if the Dockerfile just wgets a binary, this doesn't help me.

* The Dockerfiles need to be easy to find. Sourcegraph's don't seem to be referenced from the documentation, I had to look through their Github repos to find https://github.com/sourcegraph/sourcegraph/tree/main/docker-... (though most are bazel scripts instead of Dockerfiles, but serve the same purpose)

So basically, you want a Dockerfile.

I don't back up containers, why would you? I back up the attached volumes, or, more often, their state is fully in a database, which isn't in a container (it doesn't need to be), so I just back the database up.

I meant backing up volumes.

Number one advice for using docker volumes: Don't use docker volumes. Just mount directories or files from the host file system. I have never had a situation where I didn't regret docker volumes but where I regretted host FS mounts.

How do you backup a directory? You tell me, because I have to use a multi gigabyte software package that, mind you, is a pain to install since it consists of like two dozen packages.

UID mapping?

Reply on news.ycombinator.com