5 ms·

Containerization and container orchestration platforms are only partly about scalability. The primary appeal for me is ease of deployment and reproducibility.

Containerization and container orchestration platforms are only partly about scalability. The primary appeal for me is ease of deployment and reproducibility. This is why I develop everything in Docker Compose locally. Maybe the equivalent here would be something like Guix or Nix for declaratively writing the entire state of all the desired system packages and services + versions but honestly (without personal experience using these) they seem harder than containers.

tomberek 6y ago
Nix/NixOS for this purpose is very nice.
ralmeida 6y ago
Exactly! Other non-scalability concerns they address (specifically talking about Kubernetes here) is a primitive amount of monitoring/observability; no-downtime updates (rolling updates); liveness/readiness probes; primitive service discovery and load balancing; resiliency to any one single host failing (even if the total compute power could easily fit into a single bigger server).
- dsr_ 6y ago
  Which of these are things you want on your house server? That's what the article author is writing about, and what I am writing about. I do not need an octopus conducting a herd of elephants.
  - p_l 6y ago
    I recently ended up setting up "classic" server again after a significant time keeping mostly containerized infrastructure on k8s. Never again, the amount of things that are simply harder in comparison is staggering.
    - Scramblejams 6y ago
      Sorry to sound pedantic, but what was harder? Containerized infra or a classic server? I assume the former but wanted to be sure.
      - arcticfox 6y ago
        To me it sounds like the latter, a classic server, which I agree... After getting comfortable with containerized deployment, "classic" servers are a huge pain
        cecja 6y ago
        it honestly sounds just like you don't know what you are doing and docker was made for you
      - p_l 6y ago
        "Classic" approach turned out to be maddeningly harder. Everything, even inside single "application", going slightly off the reservation. Services that would die in stupid ways. Painful configuration that would have been abstracted out were I running containers on k8s (some benefits might be realized with Docker compose, but docker on its own is much more brittle than k8s). So much SSH-ing to a node to tweak things. apt-get fscking the server. Etc. Oh, and logging being shitshow.
  - gavinray 6y ago
    I can agree that the idea of reaching for Kubernetes to set up a bunch of services on a home server sounds a bit absurd. "How did we get here?" I'm not an inexperienced codemonkey by any means of the term, but I am a shitty Sysadmin. And despite being a Linux user from early teens, I'm not a greybeard. As sorry a state as it may sound, I have more faith in my ability to reliably run and maintain a dozen containers in k8s than a dozen standard, manually installed apps + processes managed by systemd. Whether this is a good thing or a bad thing you can likely find solid arguments both ways for.
    - henryfjordan 6y ago
      You only have to learn 1 interface (albeit a complicated one) to use Docker/k8s compared with 1 interface per service to run them manually.
      - klodolph 6y ago
        Hm, these days I feel like I only have to learn systemd. Reload config? View logs? Watchdog? Namespaces? It’s all systemd. If you are running on one machine, what does Docker/k8s give you that you do not already have?
        nineteen999 6y ago
        > If you are running on one machine, what does Docker/k8s give you that you do not already have? That feeling that you are part of a special, futuristic club.
        vineyardmike 6y ago
        Nothing, but its pretty common to have the home server plus a desktop/laptop where you do most of the work (even for home server), that may not be linux - in which case containers are the easiest way
  - threentaway 6y ago
    Having zero downtime updates is quite nice. For example, I can set FluxCD to pin to a feature release of Nextcloud, and it will automatically apply any patch updates available. Because of the zero downtime updates, this can happen at any time and I won't have any issues, even if I'm actively using Nextcloud as it's happening.
  - ralmeida 6y ago
    Fair enough, my point was more about using k8s to deploy applications rather than “house server” stuff, where it’s indeed unneeded more often than not.
dsr_ 6y ago
I'm not deploying; this is the server. I do backups, and I keep config in git. Reproducibility? This is the server. I will restore from backups. There is no point in scaling. If you want to argue that containerization and VMs are portable and deployable and all that, I agree. This is not a reasonable place to do that extra work.
- awill 6y ago
  Not sure about reproducibility. If the HD fails, sure, restore from backup. But what if the motherboard fails, and you buy/build a completely new machine. Does a backup work then, even if all the hardware is different? That's where a container makes restoring easier.
  - aflag 6y ago
    Why wouldn't it? Unless you are changing architecture after a component of your system dies, there's no reason your old binaries would not work.
    - OJFord 6y ago
      Drivers, config you missed/didn't realise was relevant/wasn't needed before, IDs (e.g. disks), etc. Nix or aconfmgr (for Arch) help. I still like containers for this though. Scalability doesn't mean I'm fooling myself into thinking hundreds of thousands of people are reading my blog, it means my personal use can outgrow the old old PC 'server' it's on and spill into the new old one, for example. Or that, for simplicity of configuration, each disk will be (the sole disk) mounted by a Pi.
      - aflag 6y ago
        There's more than one way to skin a cat. If you're running something as simple and low profile as OP suggested, all you need to backup from the system are the packages you installed and a handful of configurations you changed in /etc. That could be in ansible, but it could be just a .sh file, really. You'll also need a backup of the actual data, not the entire /. Although, even if all you did was backup the entire / there's a good chance it would work even if you try to recover it in new hardware. The services metioned by OP don't need to talk to each other, they are all things that work out of the box by just running apt-get install or equivalent. You don't need anything really fancy and you can set up a new box with part of the services if they are ever taking too much resources (which, for a small setup, will likely never really happen. At least in my experience)
ansible 6y ago
> This is why I develop everything in Docker Compose locally. For a small setup like this, just having a docker compose file in version control is more than sufficient. You can easily leverage services someone else has set up, and the final config is easy to get going again if you need to rebuild the machine due to hardware failure.
GordonS 6y ago
Reproducibility is the key reason I use Docker. Some stuff is really tricky to setup too - like postfix with working TLS, DKIM etc. Before Docker I'd eventually get stuff like this working, then a couple of years something would break and I'd have no clue how to fix it because I hadn't touched it for so long. With Docker (and Compose and Swarm), everything is codified in scripts and config files, all ready to be deployed anywhere.

tomberek 6y ago

Nix/NixOS for this purpose is very nice.

ralmeida 6y ago

Exactly! Other non-scalability concerns they address (specifically talking about Kubernetes here) is a primitive amount of monitoring/observability; no-downtime updates (rolling updates); liveness/readiness probes; primitive service discovery and load balancing; resiliency to any one single host failing (even if the total compute power could easily fit into a single bigger server).

dsr_ 6y ago
Which of these are things you want on your house server? That's what the article author is writing about, and what I am writing about. I do not need an octopus conducting a herd of elephants.
- p_l 6y ago
  I recently ended up setting up "classic" server again after a significant time keeping mostly containerized infrastructure on k8s. Never again, the amount of things that are simply harder in comparison is staggering.
  - Scramblejams 6y ago
    Sorry to sound pedantic, but what was harder? Containerized infra or a classic server? I assume the former but wanted to be sure.
    - arcticfox 6y ago
      To me it sounds like the latter, a classic server, which I agree... After getting comfortable with containerized deployment, "classic" servers are a huge pain
      - cecja 6y ago
        it honestly sounds just like you don't know what you are doing and docker was made for you
    - p_l 6y ago
      "Classic" approach turned out to be maddeningly harder. Everything, even inside single "application", going slightly off the reservation. Services that would die in stupid ways. Painful configuration that would have been abstracted out were I running containers on k8s (some benefits might be realized with Docker compose, but docker on its own is much more brittle than k8s). So much SSH-ing to a node to tweak things. apt-get fscking the server. Etc. Oh, and logging being shitshow.
- gavinray 6y ago
  I can agree that the idea of reaching for Kubernetes to set up a bunch of services on a home server sounds a bit absurd. "How did we get here?" I'm not an inexperienced codemonkey by any means of the term, but I am a shitty Sysadmin. And despite being a Linux user from early teens, I'm not a greybeard. As sorry a state as it may sound, I have more faith in my ability to reliably run and maintain a dozen containers in k8s than a dozen standard, manually installed apps + processes managed by systemd. Whether this is a good thing or a bad thing you can likely find solid arguments both ways for.
  - henryfjordan 6y ago
    You only have to learn 1 interface (albeit a complicated one) to use Docker/k8s compared with 1 interface per service to run them manually.
    - klodolph 6y ago
      Hm, these days I feel like I only have to learn systemd. Reload config? View logs? Watchdog? Namespaces? It’s all systemd. If you are running on one machine, what does Docker/k8s give you that you do not already have?
      - nineteen999 6y ago
        > If you are running on one machine, what does Docker/k8s give you that you do not already have? That feeling that you are part of a special, futuristic club.
      - vineyardmike 6y ago
        Nothing, but its pretty common to have the home server plus a desktop/laptop where you do most of the work (even for home server), that may not be linux - in which case containers are the easiest way
- threentaway 6y ago
  Having zero downtime updates is quite nice. For example, I can set FluxCD to pin to a feature release of Nextcloud, and it will automatically apply any patch updates available. Because of the zero downtime updates, this can happen at any time and I won't have any issues, even if I'm actively using Nextcloud as it's happening.
- ralmeida 6y ago
  Fair enough, my point was more about using k8s to deploy applications rather than “house server” stuff, where it’s indeed unneeded more often than not.

dsr_ 6y ago

I'm not deploying; this is the server. I do backups, and I keep config in git. Reproducibility? This is the server. I will restore from backups. There is no point in scaling. If you want to argue that containerization and VMs are portable and deployable and all that, I agree. This is not a reasonable place to do that extra work.

awill 6y ago
Not sure about reproducibility. If the HD fails, sure, restore from backup. But what if the motherboard fails, and you buy/build a completely new machine. Does a backup work then, even if all the hardware is different? That's where a container makes restoring easier.
- aflag 6y ago
  Why wouldn't it? Unless you are changing architecture after a component of your system dies, there's no reason your old binaries would not work.
  - OJFord 6y ago
    Drivers, config you missed/didn't realise was relevant/wasn't needed before, IDs (e.g. disks), etc. Nix or aconfmgr (for Arch) help. I still like containers for this though. Scalability doesn't mean I'm fooling myself into thinking hundreds of thousands of people are reading my blog, it means my personal use can outgrow the old old PC 'server' it's on and spill into the new old one, for example. Or that, for simplicity of configuration, each disk will be (the sole disk) mounted by a Pi.
    - aflag 6y ago
      There's more than one way to skin a cat. If you're running something as simple and low profile as OP suggested, all you need to backup from the system are the packages you installed and a handful of configurations you changed in /etc. That could be in ansible, but it could be just a .sh file, really. You'll also need a backup of the actual data, not the entire /. Although, even if all you did was backup the entire / there's a good chance it would work even if you try to recover it in new hardware. The services metioned by OP don't need to talk to each other, they are all things that work out of the box by just running apt-get install or equivalent. You don't need anything really fancy and you can set up a new box with part of the services if they are ever taking too much resources (which, for a small setup, will likely never really happen. At least in my experience)

ansible 6y ago

> This is why I develop everything in Docker Compose locally. For a small setup like this, just having a docker compose file in version control is more than sufficient. You can easily leverage services someone else has set up, and the final config is easy to get going again if you need to rebuild the machine due to hardware failure.

GordonS 6y ago

Reproducibility is the key reason I use Docker. Some stuff is really tricky to setup too - like postfix with working TLS, DKIM etc. Before Docker I'd eventually get stuff like this working, then a couple of years something would break and I'd have no clue how to fix it because I hadn't touched it for so long. With Docker (and Compose and Swarm), everything is codified in scripts and config files, all ready to be deployed anywhere.