> You don't have to depend on it either - you can still use chroot instead of you want, but it's more work that way.
How so? If I need filesystem isolation, I'll use the simplest tool that provides it. In this case probably a container runtime. Note that none of your criticism about Docker applies to Podman.
Why would I ever want to use containers with a tool that forces (OK, strongly suggests...) me to use it as an init system, logging system, network manager, DNS resolver, and whatever other aspect of my Linux system its authors think it should manage?
I apologize for retreading the same discussion on this topic, but like others mentioned, adopting an incredibly complex tool doesn't mean you're simplifying. You're just working at a higher level of abstraction, which can be comforting, but simplifying would be to use the underlying systems directly or using a tool that only focuses on a single aspect of what you need (i.e. containerization).
> You don't need them. Everything from the post is defined in simple environment variables. For example socket activation is maybe 3 extra lines when done from scratch.
Great, then the article shouldn't import systemd bindings... My point is that the program is now tied to systemd systems. Containers don't impose such restrictions.
> Note that none of your criticism about Docker applies to Podman.
It's not a criticism of docker. It's "docker does the same thing", because there are good reasons to abstract that functionality. I'm not familiar with podman internals.
> Why would I ever want to use containers with a tool that ...
Because you have to deal with those things always. You can do them yourself, you can do them with other services, or your can do them in the currently-most-common framework of systemd. You can still pick and choose from those elements as you want.
> You're just working at a higher level of abstraction, which can be comforting, but simplifying would be to use the underlying systems directly or using a tool that only focuses on a single aspect
I don't really see the namespaces and service management as different things. They're pretty much one idea these days.
It's also simplifying things because I can write my own script with the necessary unshare / mount / ip stuff. But the common patterns are repeating so much, I'd rather use a single option for it.
> Great, then the article shouldn't import systemd bindings
They're not bindings, just abstraction. Why should that be treated differently from "shouldn't import fmt, just concatenate strings", "shouldn't use rand, just open /dev/urandom"?
> My point is that the program is now tied to systemd systems.
Only in these examples. Actual apps normally autodetect the relevant variables and not rely on activation if it's not available. You're never tied to systemd activation / keep alive notification unless you choose to do it.
It's not really a binding. It doesn't link to anything in systemd, it's just aware of the convention used by systemd to pass the file descriptors into the process. The actual code being executed from that repository is around 60 lines, I guess:
I just used that rather than writing it myself because it felt like it didn't add much to the story. Also the code was actually written on macOS, it still runs fine without systemd.
Edit: I'd be quite interested to see if passing file descriptors in this way would be a goal in, for example, the proposed Alpine service manager. A quick scan of the proposal didn't show me anything obvious, but I'll go and read it in more detail.
How so? If I need filesystem isolation, I'll use the simplest tool that provides it. In this case probably a container runtime. Note that none of your criticism about Docker applies to Podman.
Why would I ever want to use containers with a tool that forces (OK, strongly suggests...) me to use it as an init system, logging system, network manager, DNS resolver, and whatever other aspect of my Linux system its authors think it should manage?
I apologize for retreading the same discussion on this topic, but like others mentioned, adopting an incredibly complex tool doesn't mean you're simplifying. You're just working at a higher level of abstraction, which can be comforting, but simplifying would be to use the underlying systems directly or using a tool that only focuses on a single aspect of what you need (i.e. containerization).
> You don't need them. Everything from the post is defined in simple environment variables. For example socket activation is maybe 3 extra lines when done from scratch.
Great, then the article shouldn't import systemd bindings... My point is that the program is now tied to systemd systems. Containers don't impose such restrictions.