You may think that other workflows are better, but there is a chunk of the engineering population that is happy with the tools they have for managing a set of bare processes on a machine.
Setting resource limits using cgroups, isolating users/paths/networks using the capabilities of systemd and all together used from a common shell script seems more expressive and more versatile than using docker/docker compose and requiring an extra daemon to deal with everything.*
This is the same flexibility trap as C++ build systems. Whereas in Cargo, adding a dependency is a single line.
Knowledge and practices that are pulled from the ecosystem compose, and can be ephemeral in ways that hand rolled solutions are not.
I would not want to go through that common shell script for every new project because it would probably look very different from project to project.
If anything its better and more standardized.
Anyways, this article is old and managing podman containers with systemd is much easier and more idiomatic since last week's podman update.
I am not scared of systemd and I use it extensively but this does not sound like a convenient way to manage multiple containers.
Podman supports generating systemd units for “Pods” (groups of containers).
The unit files podman generates are portable. Rather than version controlling your compose.yml, you would version control your unit defining your pod.
Using a makefile you could handle installing/updating/etc your unit file.
It is an equally convenient way to manage your containers, but it does require learning and understanding how everything fits together, compose is nice because it abstracts a lot.
Before that I used Makefiles.
Youre supposted to have podman generate systemd for you. With the recent update, your systemd unit will have a [Container] section which will be easy to configure manually if you want.
https://github.com/containers/podman/blob/db505ed5dce7a868b8...
`Requires=`? Systemd unit files are configuration files, not object code. While podman(1) can generate them for you, that doesn't mean that you should be treating the results as opaque artifacts. They're more like a project skeleton. You're meant to commit those, and hand-maintain them; and you're meant to read them in order to understand "how things currently are." Unit files are to systemd as YAML resource manifest files are to Kubernetes: the canonical description of the resource, that you can "do GitOps to."
> You then have to symlink those services to the right place, enable them
Those are the same thing. `systemctl enable` creates symlinks "to the right place". Also, it's not necessary to `systemctl enable` a service in order to merely `systemctl start` it; `systemctl enable`-ing a service specifically binds it to start automatically on startup (or on whatever other .target units it has specified), by putting an entry for that service in a directory named after that target. Just like how SysV runlevels work with rcN.d directories, but not limited to the system being at exactly one runlevel at a time.
> Instead of having single simple docker-compose.yml file which you can add to the git repo
Why wouldn't you still have a docker-compose.yml file in the repo? I think you're misunderstanding the whole point here.
Docker-compose files are a development and testing technology. You run them to stand up an ephemeral deployment of a complex set of components, on your own workstation or maybe in CI, so you (or the E2E test harness) can poke at it. Docker-compose files are maintained by developers, to serve the needs of developers; and never reach the hands of ops staff, let alone customers.
Systemd unit files are a production deployment technology. They're something you create to include in a Deb or RPM package. These are maintained by release engineers, with bug reports on how they work submitted by your own ops staff, or even by the ops staff of customers who have either on-prem deployments of your software, or who have shell access to hosted dedicated enterprise deployments of your software. (Yes, that's a thing that happens.)
Importantly, systemd unit files are often created by someone external to the project, who was handed an opaque Docker image (or other kind of opaque binary), and must now make that software run robustly on their system, without being able to change it. Systemd is full of ways to accomplish that. Docker-compose, meanwhile, assumes that those sorts of things — e.g. tweaking sysctls, capturing PID after pre-forking, touching log files and setting their ownership at start, running as root for a bootstrap phase and then as non-root for steady-state, etc — are the domain of the contained software, and if the developer doesn't like them, they should just change their software. Which, if you're some SRE deploying `foocorp/foo-core:latest`, you really can't.
There are concerns that are only relevant to production. And there are concerns that are only relevant to development. Usually these concerns form two pretty orthogonal classes, where it doesn't even make sense to have a single file format that can express both. In fact, often the only concern shared by the two, is the set of image names and tags referenced by the files. Everything else is environment-type specific. So it makes a lot more sense to have two entirely distinct sets of config files — one to drive development tooling, and one to drive production tooling — than to try to bring them together. This means you need one more line in your bump-release-version script to write the new image tag to one more file. Other than that, you'll likely never find yourself updating both sets of files for a single concern. (At least, I personally never do.)
docker compose was a step forward, this is certainly going back and I will probably never use it no matter how many times someone says that this is the canonical way to do things, because it isn't, no one does that.
It seems almost as if someone is deliberately crippling open source container tooling just to increase sales of cloud provider container management tools. It most likely isn't true but I still wonder about it because I haven't seen actually good contributions and innovation in this area for some years now.