6 ms·

> 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

> 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.
- progval 3y ago
  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/ https://docs.joinmastodon.org/admin/install/
  - TeMPOraL 3y ago
    So basically, you want a Dockerfile.
  - zaptheimpaler 3y ago
    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.
    - progval 3y ago
      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-images https://github.com/sourcegraph/sourcegraph/tree/main/docker-... (though most are bazel scripts instead of Dockerfiles, but serve the same purpose)

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.

progval 3y ago
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/ https://docs.joinmastodon.org/admin/install/
- TeMPOraL 3y ago
  So basically, you want a Dockerfile.
- zaptheimpaler 3y ago
  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.
  - progval 3y ago
    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-images https://github.com/sourcegraph/sourcegraph/tree/main/docker-... (though most are bazel scripts instead of Dockerfiles, but serve the same purpose)