Re:On the joy of podman and auto-updates (2022)
by nine_k on Tuesday February 07, 2023 @07:55AM
(#34692095)
The key difference is that systemd is system-wide orchestration, and docker-compose controls a specific set of containers connected in a specific day, and likely otherwise isolated from the system. The latter allows to "ship" entire configurations that work together, as one unit.
[ Parent
| on HN ]
Re:On the joy of podman and auto-updates (2022)
by mariusor on Tuesday February 07, 2023 @09:22AM
(#34693096)
I think that existing tooling on nix environments can work much better than docker compose to aggregate a set of containers and resources.
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.*
Re:On the joy of podman and auto-updates (2022)
by scns on Tuesday February 07, 2023 @10:13AM
(#34693799)
More expressive? I think so too. Less convenient? I think so. Sadly history shows that convenience wins.
Re:On the joy of podman and auto-updates (2022)
by sitkack on Tuesday February 07, 2023 @11:34AM
(#34694929)
If you have to roll your own, you now own it. This should be a huge bar, and better isn’t enough.
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.
Re:On the joy of podman and auto-updates (2022)
by Jnr on Tuesday February 07, 2023 @01:49PM
(#34697200)
The thing with docker-compose.yml is that it is well known, well documented and relatively easy to learn and get running even for more complex configurations.
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.