4 ms·

That usefulness of the Docker daemon has actually been acknowledged by the Podman project. That's the "socket" they're talking about in this blog. If you run `

by DCKing 5y ago

That usefulness of the Docker daemon has actually been acknowledged by the Podman project. That's the "socket" they're talking about in this blog. If you run `sudo systemctl start podman.socket` on your Podman 3.0+ & systemd system, you get a Docker daemon compatible API listening on your localhost. You can use all your Docker API compatible tools - including vanilla Docker Compose - and it will just use Podman underneath. Compatibility with Docker features may not be 100% yet (I'm not aware of major issues, but I believe they're there), but it's getting to the point that most use cases for Docker's ""legacy architecture"" can be handled by Podman. And if you don't need an API, it's default off on Linux hosts so you can just use Podman without that additional exposure until you opt in.

mindwok 5y ago
The socket doesn't give you the benefits of a long-running daemon though, namely: Healthchecks and automatic restarts, and the ability to run containers beyond rebooting. Podman can do those things but it leverages systemd timers and units. Which isn't necessarily a bad thing, but I do like that Docker does this completely self-contained.
- viraptor 5y ago
  > Which isn't necessarily a bad thing, but I do like that Docker does this completely self-contained. I don't see it as a bad thing, but definitely a weird one. With complex containers you often end up with your init running docker running s6 running the app. All with different configs, with different lifecycle management, different restart behaviour. It's tiring to deal with - I like the idea of moving as much of it to the top level init as possible.
- tvaughan 5y ago
  But how do you use docker to run a container on boot if not with systemd? One nice thing about podman is that when you stop a container you’re really stopping the container. With docker you’re just breaking the client server connection.
  - rad_gruchalski 5y ago
    > But how do you use docker to run a container on boot if not with systemd? On a mac, I do ——restart=unless-stopped and it starts automatically when Docker daemon starts. Does it not work on Linux?
    - chillfox 5y ago
      it works the same on Linux
- candiddevmike 5y ago
  Docker healthchecks don't actually do anything besides status reporting AFAIK.
  - mindwok 5y ago
    Mainly I use it for starting services in some kind of order with compose files, but other than that I believe you're correct, it only does anything at startup. It doesn't restart containers that become unhealthy it seems.
yjftsjthsd-h 5y ago
Then... why not just use docker?
- TingPing 5y ago
  It has a less clear future with the company behind it.
- coldtea 5y ago
  Because the difference is not just the socket.
  - anthropodie 5y ago
    I mentioned this in other comment here but it's relevant here too Podman: - does not mess with your iptables unlike docker. Because of this docker containers can bypass firewall rules set by ufw - does not creates bridged networks
    - remram 5y ago
      Apologies for the possibly dumb question, I couldn't find this in the Podman docs. How does it do networking without bridges? Does it still use veth devices?
      - anthropodie 5y ago
        That's a valid question. I also did not look up until you asked. Check this out[1] > One of the guiding factors on networking for containers with Podman is going to be whether or not the container is run by a root user or not. This is because unprivileged users cannot create networking interfaces on the host. Therefore, with rootfull containers, the default networking mode is to use netavark. For rootless, the default network mode is slirp4netns. Because of the limited privileges, slirp4netns lacks some of the features of networking; for example, slirp4netns cannot give containers a routable IP address. [1]: https://github.com/containers/podman/blob/main/docs/tutorials/basic_networking.md https://github.com/containers/podman/blob/main/docs/tutorial...

by DCKing 5y ago

mindwok 5y ago

The socket doesn't give you the benefits of a long-running daemon though, namely: Healthchecks and automatic restarts, and the ability to run containers beyond rebooting. Podman can do those things but it leverages systemd timers and units. Which isn't necessarily a bad thing, but I do like that Docker does this completely self-contained.

viraptor 5y ago
> Which isn't necessarily a bad thing, but I do like that Docker does this completely self-contained. I don't see it as a bad thing, but definitely a weird one. With complex containers you often end up with your init running docker running s6 running the app. All with different configs, with different lifecycle management, different restart behaviour. It's tiring to deal with - I like the idea of moving as much of it to the top level init as possible.
tvaughan 5y ago
But how do you use docker to run a container on boot if not with systemd? One nice thing about podman is that when you stop a container you’re really stopping the container. With docker you’re just breaking the client server connection.
- rad_gruchalski 5y ago
  > But how do you use docker to run a container on boot if not with systemd? On a mac, I do ——restart=unless-stopped and it starts automatically when Docker daemon starts. Does it not work on Linux?
  - chillfox 5y ago
    it works the same on Linux
candiddevmike 5y ago
Docker healthchecks don't actually do anything besides status reporting AFAIK.
- mindwok 5y ago
  Mainly I use it for starting services in some kind of order with compose files, but other than that I believe you're correct, it only does anything at startup. It doesn't restart containers that become unhealthy it seems.

yjftsjthsd-h 5y ago

Then... why not just use docker?

TingPing 5y ago
It has a less clear future with the company behind it.
coldtea 5y ago
Because the difference is not just the socket.
- anthropodie 5y ago
  I mentioned this in other comment here but it's relevant here too Podman: - does not mess with your iptables unlike docker. Because of this docker containers can bypass firewall rules set by ufw - does not creates bridged networks
  - remram 5y ago
    Apologies for the possibly dumb question, I couldn't find this in the Podman docs. How does it do networking without bridges? Does it still use veth devices?
    - anthropodie 5y ago
      That's a valid question. I also did not look up until you asked. Check this out[1] > One of the guiding factors on networking for containers with Podman is going to be whether or not the container is run by a root user or not. This is because unprivileged users cannot create networking interfaces on the host. Therefore, with rootfull containers, the default networking mode is to use netavark. For rootless, the default network mode is slirp4netns. Because of the limited privileges, slirp4netns lacks some of the features of networking; for example, slirp4netns cannot give containers a routable IP address. [1]: https://github.com/containers/podman/blob/main/docs/tutorials/basic_networking.md https://github.com/containers/podman/blob/main/docs/tutorial...