4 ms·

> 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

> 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

stavros 3y ago
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.
- progval 3y ago
  I meant backing up volumes.
  - imtringued 3y ago
    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.
    - timka 3y ago
      UID mapping?
zaptheimpaler 3y ago
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.
- progval 3y ago
  > 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 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
  - zaptheimpaler 3y ago
    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.

stavros 3y ago

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.

progval 3y ago
I meant backing up volumes.
- imtringued 3y ago
  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.
  - timka 3y ago
    UID mapping?

zaptheimpaler 3y ago

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.

progval 3y ago
> 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 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
- zaptheimpaler 3y ago
  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.