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.

> 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.

I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers. Containers per se are just various Linux namespace features, and are unrelated to e.g. distribution or immutable images. So it makes sense to mention experience with the systems that are built around containers.

The point is when you have experience with a Linux distribution that already does immutable, declarative builds and easy distribution, containers (which are also a ~2 line change to layer into a service) are a rather specific choice to use.

If you've used these things for anything nontrivial, yes systemd units are way simpler than docker run. Debugging NAT and iptables when you have multiple interfaces and your container doesn't have tcpdump is all a pain, for example. Dealing with issues like your bind mount not picking up a change to a file because it got swapped out with a `mv` is a pain. Systemd units aren't complicated.

> I mentioned k8s because when people talk about the benefits of containers, they usually mean the systems for deploying and running containers.

No, it sounds like a poorly thought through strawman. Even Docker supports Docker swarm mode and many k8s distributions use containerd instead of Docker, so it's at best an ignorant stretch to jump to conclusions over k8s.

> Containers per se are just various Linux namespace features, and are unrelated to e.g. distribution or immutable images. So it makes sense to mention experience with the systems that are built around containers.

No. Containers solve many operational problems, such as ease of deployment, setup software defined networks, ephemeral environments, resource management, etc.

You need to be completely in the dark to frame containerization as Linux namespace features. It's at best a naive strawman, built upon ignorance.

> If you've used these things for anything nontrivial, yes systemd units are way simpler than docker run.

I'll make it very simple to you. I want to run postgres/nginx/keycloak. With Docker, I get everything up and running with a "docker run <container image>".

Now go ahead and show how your convoluted way is "way simpler".

Containers do not do deployment (or set up software defined networks). docker or kubernetes (or others) do deployment. That's my point.

nix makes it trivial to set up ephemeral environments: make a shell.nix file and run `nix-shell` (or if you just need a thing or two, do e.g. `nix-shell -p ffmpeg` and now you're in a shell with ffmpeg. When you close that shell it's gone). You might use something like `direnv` to automate that.

Nixos makes it easy to define your networking setup through config.

For your last question:

    services.postgres.enable = true;
    services.nginx.enable = true;
    services.keycloak.enable = true;

If you want, you can wrap some or all of those lines in a container, e.g.

    containers.backend = {
        config = { config, pkgs, lib, ... }: {
            services.postgres.enable = true;
            services.keycloak.enable = true;
        };
    };

Though you'd presumably want some additional networking and bind mount config (e.g. putting it into its own network namespace with a bridge, or maybe binding domain sockets that nginx will use plus your data partitions).

It's just bad faith argument after bad faith argument with these contrarian folks. I have to laugh every time I see systemd mentioned as an "easier" alternative.

Find any self hosted software, the docker deployment is going to be the easiest to stand up/destroy and migrate.