5 ms·

Nice post, but I really dislike the idea of creating unit files for each container. docker compose was a step forward, this is certainly going back and I will

by Jnr 4y ago

Nice post, but I really dislike the idea of creating unit files for each container. 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.

Already__Taken 4y ago
user space container unit files kind of stuck to use and edit, I have to have notes to always add the socket too else I can't see what's running. just use k8s it's easier in the long run
rkangel 4y ago
This is certainly a canonical way of doing things. Podman allows you to treat a containerised process much more like any other process. In this world systemd manages the interdependencies (including on things like the network). 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.
- nine_k 4y ago
  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.
  - mariusor 4y ago
    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.
    - scns 4y ago
      More expressive? I think so too. Less convenient? I think so. Sadly history shows that convenience wins.
    - sitkack 4y ago
      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.
    - Jnr 4y ago
      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.
IceWreck 4y ago
Why ? systemd runs docker's daemon as root which runs your container. This uses systemd (user or system)to control your container directly. 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.
- Jnr 4y ago
  Seems like you are supposed to create service for each container and then somehow else manage service dependencies, network and other aspects which are trivial when using docker compose. Instead of having single simple docker-compose.yml file which you can add to the git repo, you end up having multiple services, network definitions, firewall rules. You then have to symlink those services to the right place, enable them and do god knows what else. I am not scared of systemd and I use it extensively but this does not sound like a convenient way to manage multiple containers.
  - riolu 4y ago
    Podman’s unofficial answer to compose is “podman compose”. The official answer is kubernetes. 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.
  - IceWreck 4y ago
    Well I use ansible's podman module to setup/configure my containers and then use it to generate systemd from that. 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/db505ed5dce7a868b843d4c7ffff0dec02497e60/docs/source/markdown/podman-systemd.unit.5.md https://github.com/containers/podman/blob/db505ed5dce7a868b8...

by Jnr 4y ago

Already__Taken 4y ago

user space container unit files kind of stuck to use and edit, I have to have notes to always add the socket too else I can't see what's running. just use k8s it's easier in the long run

rkangel 4y ago

This is certainly a canonical way of doing things. Podman allows you to treat a containerised process much more like any other process. In this world systemd manages the interdependencies (including on things like the network). 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.

nine_k 4y ago
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.
- mariusor 4y ago
  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.
  - scns 4y ago
    More expressive? I think so too. Less convenient? I think so. Sadly history shows that convenience wins.
  - sitkack 4y ago
    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.
  - Jnr 4y ago
    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.

IceWreck 4y ago

Why ? systemd runs docker's daemon as root which runs your container. This uses systemd (user or system)to control your container directly. 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.

Jnr 4y ago
Seems like you are supposed to create service for each container and then somehow else manage service dependencies, network and other aspects which are trivial when using docker compose. Instead of having single simple docker-compose.yml file which you can add to the git repo, you end up having multiple services, network definitions, firewall rules. You then have to symlink those services to the right place, enable them and do god knows what else. I am not scared of systemd and I use it extensively but this does not sound like a convenient way to manage multiple containers.
- riolu 4y ago
  Podman’s unofficial answer to compose is “podman compose”. The official answer is kubernetes. 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.
- IceWreck 4y ago
  Well I use ansible's podman module to setup/configure my containers and then use it to generate systemd from that. 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/db505ed5dce7a868b843d4c7ffff0dec02497e60/docs/source/markdown/podman-systemd.unit.5.md https://github.com/containers/podman/blob/db505ed5dce7a868b8...