5 ms·

> docker There's your problem. Docker adds indirection on storage, networking, etc., and also makes upgrades difficult as you have to either rebuild the conta

by zdw 1y ago

> docker There's your problem. Docker adds indirection on storage, networking, etc., and also makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. If you stick to things that can be deployed as an upstream OS vendor package, or as a single binary (go-based projects frequently do this), you'll likely have a better time in the long run.

bluGill 1y ago
Maybe. There are pros and cons. Docker means you can run two+ different things on the same machine and update them separately. This is sometimes important when one project releases a feature you really want, while a different one just did a major update that broke something you care about. Running on the OS often means you have to update both. Single binary sometimes works, but means you need more memory and disk space. (granted much less a concern today than it was back in 1996 when I first started self hosting, but it still can be an issue)
- zdw 1y ago
  How can running a single binary under systemd need more memory/disk space than having that identical binary with supporting docker container layers under it on the same system, plus the overhead of all of docker? Conflicting versions, I'll give you that, but how frequently does that happen, especially if you mostly source from upstream OS vendor repos? The most frequent conflict is if everything wants port 80/443, and for most self-hosted services you can have them listen on internal ports and be fronted by a single instance of a webserver (take your pick of apache/nginx/caddy).
  - bluGill 1y ago
    I didn't mean the two paragraphs to imply that they are somehow opposites (though on hindsight I obviously did). There are tradeoffs. a single binary is between docker and a library that uses shared libraries. What is right depends on your situation. I use all three in my selfhosted environment - you probably should too.
    - Lvl999Noob 1y ago
      If you are using docker, do you save anything by using shared libraries? I thought docker copies everything. So every container has its own shared libraries and the OS running all those containers has its own as well.
      - kilburn 1y ago
        Not necessarily. You are still running within the same kernel. If your images use the same base container then the libraries exist only once and you get the same benefits of a non-docker setup. This depends on the storage driver though. It is true at least for the default and most common overlayfs driver [1] [1] https://docs.docker.com/engine/storage/drivers/overlayfs-driver/#page-caching https://docs.docker.com/engine/storage/drivers/overlayfs-dri...
        zdw 1y ago
        The difference between a native package manager provided by the OS vendor and docker is that in a native package manager allows you to upgrade parts of the system under the applications. Let's say some Heartbleed (which affected OpenSSL, primarily) happens again. With native packages, you update the package, restart a few things that depend on it with shared libraries, and you're patched. OS vendors are highly motivated to do this update, and often get pre-announcement info around security issues so it tends to go quickly. With docker, someone has to rebuild every container that contains a copy of the library. This will necessarily lag and be delivered in a piecemeal fashion - if you have 5 containers, all of them need their own updates, which if you don't self-build and self-update, can take a while and is substantially more work than `apt get update && reboot`. Incidentally, the same applies for most languages that prefer/require static linking. As mentioned elsewhere in the thread, it's a tradeoff, and people should be aware of the tradeoffs around update and data lifecycle before making deployment decisions.
        motorest 1y ago
        > With docker, someone has to rebuild every container that contains a copy of the library. I think you're grossly overblowing how much work it takes to refresh your containers. In my case, I have personal projects which have nightly builds that pull the latest version of the base image, and services are just redeployed right under your nose. All it take to do this was to add a cron trigger to the same CICD pipeline.
- rootnod3 1y ago
  There are more options than docker for that. FreeBSD jails for example.
- dgb23 1y ago
  I don’t understand why you would need docker for that.
eddythompson80 1y ago
I completely disagree. > Docker adds indirection on storage, networking, etc., What do you mean by "indirection"? It adds OS level isolation. It's not an overhead or a bad thing. > makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. Literally the entire selfhost stack could be updated and redeployed in a matter of: docker compose pull docker compose build . docker compose up -d Self hosting with something like docker compose means that your server is entirely describable in 1 docker-compose.yml file (or a set of files if you like to break things apart) + storage. You have clean separation between your applications/services and their versions/configurations (docker-compose.yml), and yous state/storage (usually a NAS share or a drive mount somewhere). Not only are you no longer depended on a particular OS vendor (wanna move your setup to a cheap instance on a random VPS provider but they only have CentOS for some reason?), but also the clean seperation of all the parts allows to very easily scale individual components as needed. There is 1 place where everything goes. With the OS vendor package everytime you need to check is it in systemd unit? is it a config file in /etc/? wth? Then next time you're trying to move the host, you forget the random /etc/foo.d/conf change you made. With docker-compose, that change has to be stored somewhere for the docker-compose to mount or rebuild, so moving is trivial. It's not Nixos, sure. but it's much much better than a list of APT or dnf or yum packages and scripts to copy files around
- zdw 1y ago
  Tools like Ansible exist and can do everything you mention on the deploy side and more, and are also cross platform to a wider range of platforms than Linux-only Docker. Isolation technologies are also available outside of docker, through systemd, jails, and other similar tools.
  - motorest 1y ago
    > Tools like Ansible exist and can do everything you mention on the deploy side and more (...) Your comment is technically correct, but factually wrong. What you are leaving out is the fact that, in order to do what Docker provides out of the box, you need to come up with a huge custom Ansible script to even implement the happy path. So, is your goal to self host your own services, or to endlessly toy with the likes of Ansible?
phito 1y ago
Oh my god no, docker is so damn useful I will never return to package managers/manual installation.
- motorest 1y ago
  >>Oh my god no, docker is so damn useful I will never return to package managers/manual installation. This. These anti-containerisation comments read like something someone oblivious to containers would say if they were desperately grabbing onto tech from 30 years ago and refused to even spend 5 minutes exploring anything else.
  - ndriscoll 1y ago
    Or they have explored other options and find docker lacking. I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (which can optionally easily be wrapped into containers if you want on nixos, but there you're using containers for their isolation features, not for the ability to 'docker pull', and for many purposes you can probably e.g. just use file permissions and per-service users instead of bind-mounts into containers). Containers as practiced by many are basically static linking and "declarative" configuration done poorly because people aren't familiar with dynamic linking or declarative OS config done well.
    - motorest 1y ago
      > Or they have explored other options and find docker lacking. I don't think so. Containerization solves about 4 major problems in infrastructure deployment as part of it's happy path. There is a very good reason why the whole industry pivoted towards containers. > . I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (...) This comment is void of any credibility. To start off, you suddenly dropped k8s into the conversation. Think about using systemd to setup a cluster of COTS hardware running a software-defined network, and then proclaim it's easier. And then, focusing on Docker, think about claiming that messing with systemd units is easier than simply running "docker run". Unbelievable.
sunshine-o 1y ago
I would agree with that. Docker has a lot of use cases but self hosting is not one of them. When self-hosting you wanna think long term and the fact you will loose interest in the fiddling after a while. So sticking with software packaged in a good distribution is probably the way to go. This is the forgotten added value of a Linux or BSD distribution, a coherent system with maintenance and an easy upgrade path. The exception are things like Umbrel which I would say use docker as their package manager and maintain everything, so it is ok.
- tacker2000 1y ago
  What are you talking about? Docker is THE solution for self hosting stuff since one often has one server and runs a ton of stuff on it, with different PHP, Python versions, for example. Docker makes it incredibly easy to a multitude of services on one machine however different they may be. And if you ever need to move to a new server, all you need to do is move the volumes (if even necessary) and run the containers on the new machine. So YES, self hosting stuff is a huge use case for docker.
  - sunshine-o 1y ago
    I think your view show the success of Docker but also an over-hype and generation that only know how to do things with Docker (or and so think everything is easier with it). But before Docker there was the virtualisation hype when people sweared every software/service needs its own VM. VM or containers we end up with frankenstein systems with dozens of images on one machine. And with Docker we probably lost a lot of security. So this is fine I guess in the corporate world because things are messy anyway and there are many other contraints (hence the success of containers). But in your home, serving a few apps for a few users you actually don't need that gas factory. If you wanna run everything on your home lab with Docker or Kubernetes because you wanna build a skillset for work or reuse your professional skills, fine go for it. But everything you think is easy with Docker is actually simpler and easier with raw Linux or BSD.
    - tacker2000 1y ago
motorest 1y ago
> There's your problem. Docker adds indirection on storage, networking, etc., and also makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. None of your points make any sense. Docker works beautifully well as an abstraction layer. It makes trivially simple to upgrade anything and everything running on it, to the point you do not even consider it as a concern. Your assertions are so far off that you managed to.l get all your points entirely backwards. To top things off, you get clustering for free with Docker swarm mode. > If you stick to things that can be deployed as an upstream OS vendor package, or as a single binary (go-based projects frequently do this), you'll likely have a better time in the long run. I have news for you. In fact, you should be surprised to learn that nowadays that today you even get full blown Kubernetes distributions up and running in Linux distributions after a quick snap package install.
- movedx 1y ago
  Absolutely everything they said makes sense. Everything you're saying is complete overkill, even in most Enterprise environments. We're talking about a home server here for hosting eBooks and paperless documents, and you're implying Kubernetes clusters are easy enough to run and so are a good solution here. Madness. > I have news for you. I have news for _you_: using Docker to run anything that doesn't need it (i.e. it's the only officially supported deployment mechanism) is like putting your groceries into the boot of your car, then driving your car onto the tray of a truck, then driving the truck home because "it abstracts the manual transmission of the car with the automatic transmission of the truck". Good job, you're really showing us who's boss there. Operating systems are easy. You've just fallen for the Kool Aid.
  - motorest 1y ago
    > Absolutely everything they said makes sense. Not really. It defies any cursory understanding of the problem domain, and you must go way out of your way to ignore how containerization makes everyone's job easier and even trivial to accomplish. Some people in this discussion even go to the extreme of claiming that messing with systemd to run a service is simpler than typing "docker run". It defies all logic. > Everything you're saying is complete overkill, even in most Enterprise environments. What? No. Explain in detail how being able to run services by running "docker run" is "overkill". Have you ever went through an intro to Docker tutorial? > We're talking about a home server here for hosting eBooks and paperless documents, and you're implying Kubernetes clusters are easy enough to run and so are a good solution here. Madness. You're just publicly stating your ignorance. Do yourself a favor and check Ubuntu's microk8s. You're mindlessly parroting cliches from a decade ago.
aucisson_masque 1y ago
I run Debian on my machine, so package are not really up to date and I would be stuck, not being able to update my self hosted software because some dependencies were too old. And then, some software would require older one and break when you update the dependencies for another package. Docker is a godsend when you are hosting multiple tools. For the limited stuff I host, navidrome, firefly, nginx, .. I have yet to see single binary package. It doesn’t seem very common in my experience.
- zdw 1y ago
  FWIW, Navidrome has bare binaries, packages (apt, rpm, etc.) and docker container options: https://github.com/navidrome/navidrome/releases https://github.com/navidrome/navidrome/releases

by zdw 1y ago

bluGill 1y ago

Maybe. There are pros and cons. Docker means you can run two+ different things on the same machine and update them separately. This is sometimes important when one project releases a feature you really want, while a different one just did a major update that broke something you care about. Running on the OS often means you have to update both. Single binary sometimes works, but means you need more memory and disk space. (granted much less a concern today than it was back in 1996 when I first started self hosting, but it still can be an issue)

zdw 1y ago
How can running a single binary under systemd need more memory/disk space than having that identical binary with supporting docker container layers under it on the same system, plus the overhead of all of docker? Conflicting versions, I'll give you that, but how frequently does that happen, especially if you mostly source from upstream OS vendor repos? The most frequent conflict is if everything wants port 80/443, and for most self-hosted services you can have them listen on internal ports and be fronted by a single instance of a webserver (take your pick of apache/nginx/caddy).
- bluGill 1y ago
  I didn't mean the two paragraphs to imply that they are somehow opposites (though on hindsight I obviously did). There are tradeoffs. a single binary is between docker and a library that uses shared libraries. What is right depends on your situation. I use all three in my selfhosted environment - you probably should too.
  - Lvl999Noob 1y ago
    If you are using docker, do you save anything by using shared libraries? I thought docker copies everything. So every container has its own shared libraries and the OS running all those containers has its own as well.
    - kilburn 1y ago
      Not necessarily. You are still running within the same kernel. If your images use the same base container then the libraries exist only once and you get the same benefits of a non-docker setup. This depends on the storage driver though. It is true at least for the default and most common overlayfs driver [1] [1] https://docs.docker.com/engine/storage/drivers/overlayfs-driver/#page-caching https://docs.docker.com/engine/storage/drivers/overlayfs-dri...
      - zdw 1y ago
        The difference between a native package manager provided by the OS vendor and docker is that in a native package manager allows you to upgrade parts of the system under the applications. Let's say some Heartbleed (which affected OpenSSL, primarily) happens again. With native packages, you update the package, restart a few things that depend on it with shared libraries, and you're patched. OS vendors are highly motivated to do this update, and often get pre-announcement info around security issues so it tends to go quickly. With docker, someone has to rebuild every container that contains a copy of the library. This will necessarily lag and be delivered in a piecemeal fashion - if you have 5 containers, all of them need their own updates, which if you don't self-build and self-update, can take a while and is substantially more work than `apt get update && reboot`. Incidentally, the same applies for most languages that prefer/require static linking. As mentioned elsewhere in the thread, it's a tradeoff, and people should be aware of the tradeoffs around update and data lifecycle before making deployment decisions.
        motorest 1y ago
        > With docker, someone has to rebuild every container that contains a copy of the library. I think you're grossly overblowing how much work it takes to refresh your containers. In my case, I have personal projects which have nightly builds that pull the latest version of the base image, and services are just redeployed right under your nose. All it take to do this was to add a cron trigger to the same CICD pipeline.
rootnod3 1y ago
There are more options than docker for that. FreeBSD jails for example.
dgb23 1y ago
I don’t understand why you would need docker for that.

eddythompson80 1y ago

I completely disagree. > Docker adds indirection on storage, networking, etc., What do you mean by "indirection"? It adds OS level isolation. It's not an overhead or a bad thing. > makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. Literally the entire selfhost stack could be updated and redeployed in a matter of: docker compose pull docker compose build . docker compose up -d Self hosting with something like docker compose means that your server is entirely describable in 1 docker-compose.yml file (or a set of files if you like to break things apart) + storage. You have clean separation between your applications/services and their versions/configurations (docker-compose.yml), and yous state/storage (usually a NAS share or a drive mount somewhere). Not only are you no longer depended on a particular OS vendor (wanna move your setup to a cheap instance on a random VPS provider but they only have CentOS for some reason?), but also the clean seperation of all the parts allows to very easily scale individual components as needed. There is 1 place where everything goes. With the OS vendor package everytime you need to check is it in systemd unit? is it a config file in /etc/? wth? Then next time you're trying to move the host, you forget the random /etc/foo.d/conf change you made. With docker-compose, that change has to be stored somewhere for the docker-compose to mount or rebuild, so moving is trivial. It's not Nixos, sure. but it's much much better than a list of APT or dnf or yum packages and scripts to copy files around

zdw 1y ago
Tools like Ansible exist and can do everything you mention on the deploy side and more, and are also cross platform to a wider range of platforms than Linux-only Docker. Isolation technologies are also available outside of docker, through systemd, jails, and other similar tools.
- motorest 1y ago
  > Tools like Ansible exist and can do everything you mention on the deploy side and more (...) Your comment is technically correct, but factually wrong. What you are leaving out is the fact that, in order to do what Docker provides out of the box, you need to come up with a huge custom Ansible script to even implement the happy path. So, is your goal to self host your own services, or to endlessly toy with the likes of Ansible?

phito 1y ago

Oh my god no, docker is so damn useful I will never return to package managers/manual installation.

motorest 1y ago
>>Oh my god no, docker is so damn useful I will never return to package managers/manual installation. This. These anti-containerisation comments read like something someone oblivious to containers would say if they were desperately grabbing onto tech from 30 years ago and refused to even spend 5 minutes exploring anything else.
- ndriscoll 1y ago
  Or they have explored other options and find docker lacking. I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (which can optionally easily be wrapped into containers if you want on nixos, but there you're using containers for their isolation features, not for the ability to 'docker pull', and for many purposes you can probably e.g. just use file permissions and per-service users instead of bind-mounts into containers). Containers as practiced by many are basically static linking and "declarative" configuration done poorly because people aren't familiar with dynamic linking or declarative OS config done well.
  - motorest 1y ago
    > Or they have explored other options and find docker lacking. I don't think so. Containerization solves about 4 major problems in infrastructure deployment as part of it's happy path. There is a very good reason why the whole industry pivoted towards containers. > . I've used docker and k8s plenty professionally, and they're both vastly more work to maintain and debug than nixos and systemd units (...) This comment is void of any credibility. To start off, you suddenly dropped k8s into the conversation. Think about using systemd to setup a cluster of COTS hardware running a software-defined network, and then proclaim it's easier. And then, focusing on Docker, think about claiming that messing with systemd units is easier than simply running "docker run". Unbelievable.

sunshine-o 1y ago

I would agree with that. Docker has a lot of use cases but self hosting is not one of them. When self-hosting you wanna think long term and the fact you will loose interest in the fiddling after a while. So sticking with software packaged in a good distribution is probably the way to go. This is the forgotten added value of a Linux or BSD distribution, a coherent system with maintenance and an easy upgrade path. The exception are things like Umbrel which I would say use docker as their package manager and maintain everything, so it is ok.

tacker2000 1y ago
What are you talking about? Docker is THE solution for self hosting stuff since one often has one server and runs a ton of stuff on it, with different PHP, Python versions, for example. Docker makes it incredibly easy to a multitude of services on one machine however different they may be. And if you ever need to move to a new server, all you need to do is move the volumes (if even necessary) and run the containers on the new machine. So YES, self hosting stuff is a huge use case for docker.
- sunshine-o 1y ago
  I think your view show the success of Docker but also an over-hype and generation that only know how to do things with Docker (or and so think everything is easier with it). But before Docker there was the virtualisation hype when people sweared every software/service needs its own VM. VM or containers we end up with frankenstein systems with dozens of images on one machine. And with Docker we probably lost a lot of security. So this is fine I guess in the corporate world because things are messy anyway and there are many other contraints (hence the success of containers). But in your home, serving a few apps for a few users you actually don't need that gas factory. If you wanna run everything on your home lab with Docker or Kubernetes because you wanna build a skillset for work or reuse your professional skills, fine go for it. But everything you think is easy with Docker is actually simpler and easier with raw Linux or BSD.
  - tacker2000 1y ago

motorest 1y ago

> There's your problem. Docker adds indirection on storage, networking, etc., and also makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. None of your points make any sense. Docker works beautifully well as an abstraction layer. It makes trivially simple to upgrade anything and everything running on it, to the point you do not even consider it as a concern. Your assertions are so far off that you managed to.l get all your points entirely backwards. To top things off, you get clustering for free with Docker swarm mode. > If you stick to things that can be deployed as an upstream OS vendor package, or as a single binary (go-based projects frequently do this), you'll likely have a better time in the long run. I have news for you. In fact, you should be surprised to learn that nowadays that today you even get full blown Kubernetes distributions up and running in Linux distributions after a quick snap package install.

movedx 1y ago
Absolutely everything they said makes sense. Everything you're saying is complete overkill, even in most Enterprise environments. We're talking about a home server here for hosting eBooks and paperless documents, and you're implying Kubernetes clusters are easy enough to run and so are a good solution here. Madness. > I have news for you. I have news for _you_: using Docker to run anything that doesn't need it (i.e. it's the only officially supported deployment mechanism) is like putting your groceries into the boot of your car, then driving your car onto the tray of a truck, then driving the truck home because "it abstracts the manual transmission of the car with the automatic transmission of the truck". Good job, you're really showing us who's boss there. Operating systems are easy. You've just fallen for the Kool Aid.
- motorest 1y ago
  > Absolutely everything they said makes sense. Not really. It defies any cursory understanding of the problem domain, and you must go way out of your way to ignore how containerization makes everyone's job easier and even trivial to accomplish. Some people in this discussion even go to the extreme of claiming that messing with systemd to run a service is simpler than typing "docker run". It defies all logic. > Everything you're saying is complete overkill, even in most Enterprise environments. What? No. Explain in detail how being able to run services by running "docker run" is "overkill". Have you ever went through an intro to Docker tutorial? > We're talking about a home server here for hosting eBooks and paperless documents, and you're implying Kubernetes clusters are easy enough to run and so are a good solution here. Madness. You're just publicly stating your ignorance. Do yourself a favor and check Ubuntu's microk8s. You're mindlessly parroting cliches from a decade ago.

aucisson_masque 1y ago

I run Debian on my machine, so package are not really up to date and I would be stuck, not being able to update my self hosted software because some dependencies were too old. And then, some software would require older one and break when you update the dependencies for another package. Docker is a godsend when you are hosting multiple tools. For the limited stuff I host, navidrome, firefly, nginx, .. I have yet to see single binary package. It doesn’t seem very common in my experience.

zdw 1y ago
FWIW, Navidrome has bare binaries, packages (apt, rpm, etc.) and docker container options: https://github.com/navidrome/navidrome/releases https://github.com/navidrome/navidrome/releases