Why would Alpine need systemd? Why would you need it in a container?

Why would you assume Alpine is only used for containers? I use it for my own local home server, as it's very lightweight and easy to tweak to how I want it.

Not to mention every postmarketOS-running phone and tablet.

I don't think there are many of those...

I'm not a fan of using Alpine in containers.

Use it baremetal for your servers and desktops, then use Debian/CentOS containers on top when something is missing.

Sadly when playing the CVE game, Debian containers are no contest to alpine. For CentOS in a container I can see absolutely no reasons except if the SW is only tested against it.

To make sure that once services are up and running, they keep running and are restarted automatically? To have good, centralized logging? To manage in-container services the same way you do on the container host?

There's plenty of good reasons for one to want to do so.

I think it is counter to best practices to run multiple services in a single container. Although maybe you just need to with some proprietary software.

No, it's just another way how to do things.

None of those things are actually needed in a container.

If you're actually doing those things inside one, you're literally doing it wrong

Yes you might have some special cases where some of this is needed but I'd use anything besides systemd

Some use-cases do require an init-providing process of some sort but you likely want to use tini.

See for more details: https://github.com/krallin/tini/issues/8#issuecomment-146135...

a) Starting all your services and shims and mocks inside a CI/CD tests container is not "doing it wrong"; in fact, it's the only correct way to do it.

b) systemd is the only thing that can start services cleanly and correctly. Every other solution is in various states of brokenness.

All of the cheap Linux container hosting services are doing it wrong, I guess.

Many of them offer k8s out of the box.

I still think that orchestration should live outside containers, whether within one box or several. BTW systemd has some vestiges of container orchestration built in.

OTOH there are other approaches; say, LXD directly assumes an ecosystem of processes within a container, more akin to a VM than to a single chroot-ed / jailed service process.

> OTOH there are other approaches; say, LXD directly assumes an ecosystem of processes within a container, more akin to a VM than to a single chroot-ed / jailed service process.

Those are what I had in mind. Basically cheaper VPS like service but built on Linux container tech instead of full virtualization. Maybe they are less of a rage these days, when fully virtualized KVM/Vmware VPS are so cheap. But about 5 years ago I did run my email server, webserver and database on such a container for $1-1.5$/mo. When I was able to switch to full virtualization at similar price point, I did. But there's nothing weird about runing multiple different processes in a "container" :)