6 ms·

I kinda feel bad for Docker. The prevailing wisdom seems to be that you shouldn't be using Docker anymore, use Podman. Often the reasons for this is that Podman

I kinda feel bad for Docker. The prevailing wisdom seems to be that you shouldn't be using Docker anymore, use Podman. Often the reasons for this is that Podman is daemonless, supports rootless containers, etc. But I feel this is misplaced: - The Docker daemon is actually really useful. It can run containers as other users, perform a bunch of mounting and networking stuff you can't do as rootless (or at least requires some hacky workarounds), and can monitor/maintain your containers. Podman can do lots of this as well, but requires the use of systemd. So in those cases you've just swapped one daemon for another. - For most of my use cases, I don't really care about rootless. On servers I run all my docker containers as non-root anyway, and if I'm on a workstation I have privileges and don't need rootless. - Although Podman claims compatibility with Docker, I've always found issues with trying to use it even up to a few months ago, prior to this release. Mostly when trying to use compose, although it does improve every release. I basically just view the Docker daemon as an init system like systemd. It's a privileged daemon that runs other processes. But for some reason it seems to have been made into a bogeyman.

zzzeek 5y ago
from my experience I often find myself waiting for a hung docker daemon to give me the answer to a query. I dont know much about how it works but it feels monolithic and fragile the way a single container seems to be able to hang the whole thing and I can't even do a "docker ps" to see what's going on. Podman doesnt have any issues like that, it responds quickly at all times regardless of individual container status in my experience.
jiehong 5y ago
One thing that is actually nicer is that podman can run kubernetes pods from the kubernetes yaml file description (mostly) directly. This avoids having to use kubernetes in production, and something different (like docker-compose) in local. Being able to search in multiple container registries is very nice, and docker doesn't allow you to do that (to the best of my knowledge). It's very useful if you have a company container registry for example.
- mindwok 5y ago
  Yeah, I do agree about the pods. IMO pods are a better primitive than a single container, so its cool Podman supports them.
- benatkin 5y ago
  Why not just use Minikube or microk8s in a VM with multipass?
  - metadat 5y ago
    > Why not just ... Podman comes with the ability to directly run Kubernetes YAML files, so the aforementioned non-standard addon things become unnecessary. Ever tried getting a team of 100+ engineers to agree between minikube vs docker-compose? It's not fun and produces nothing interesting. Thankfullyy, with Podman such discussions are no longer needed. Docker should've implemented this about 4-5 years ago, if they wanted to make their product The Best. Instead they became hostile to cool new product ideas, stopped on the ease of use front, and went all-in with Docker Desktop, which is just another non-standard kludge.
    - adra 5y ago
      To be fair they were fighting for docker swarm which ended up losing, so it's not surprising that they're on the back foot.
      - KronisLV 5y ago
        Currently still using Docker Swarm, i wish it was more popular, because it's oftentimes the logical next step when moving from running Docker containers manually or Docker Compose locally. It is pretty simple to use (especially with Portainer), not as resource intensive as most Kubernetes distros and the Compose format now matches what you'd run locally (with extra options, e.g. on which host to run things) vs the spammy format of Kubernetes manifests or even Helm charts. I actually wrote more about it on my blog: https://blog.kronis.dev/articles/docker-swarm-over-kubernetes https://blog.kronis.dev/articles/docker-swarm-over-kubernete... Though it's essentially inevitable that Swarm will be abandoned some day, so being able to migrate over to either Hashicorp Nomad or some Kubernetes distro is probably paramount, which is when tools like Kompose come in, when that's finally necessary. The problem of what cluster to run on still remains for all of the folks who are stuck with on-prem deployments, since most orgs can't pay for a team to manage a cluster or for bunches of hardware resources to run the full Kubernetes. In that regard, the best option that i've found so far is either K3s with Portainer, or K3s with Rancher (RKE and probably RKE2 will still be somewhat heavyweight).
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.
    - 5y ago
mbreese 5y ago
> For most of my use cases, I don't really care about rootless. See, and in almost all of my use-cases, I really do. I do HPC computing, which is almost always a multi-tenant environment. This makes using Docker really hard to use, security wise. Unfortunately, more and more software/workflows are getting distributed as Docker containers (for very good reasons). This makes my life difficult. So, if I can set it up so that users can more easily work with containers on my HPC compute nodes, I'd be very happy. If the defacto solution ends up as podman (and rootless), then I'm happy. (Yes, I use Singularity too, but it would be nicer to be able to not have to convert containers). Now, I do very little with networking and containers, so those types of requirements... I don't care as much about. But I know that is a big feature set for a lot of people here.
- elmolino89 5y ago
  Docker is not an option on HPC clusters I have been using so far. For me it is easier to just put SIF file where all users can run it/programs from it. There are issues in really closed evironments (no sudo on any machine) when one has to jump hoops to tweak=> build=>SIF transfer, but this is nuisance, not a problem. BTW, are there out there any on premises multi-user HPC clusters with Docker running on the nodes?
  - AitchEmArsey 5y ago
    > BTW, are there out there any on premises multi-user HPC clusters with Docker running on the nodes? The vendor ClusterVision (EMEA, went bankrupt then returned to life) used to offer a cluster deployment option based on OpenStack+Docker; OpenStack for defining the cluster boundary on top of your hardware then Docker serving as the "image" on each compute node layered on top of the regular OS. Not at all a typical use-case for HPC containers, and with hindsight it is fairly obvious how that Byzantine stack resulted in too much complexity for them to support cost-effectively.
- moonbug 5y ago
  No lover of Docker, but I'd have much more confidence in the quality of the docker Daemon code than any hpc batch system's local execs.
chillfox 5y ago
Podman got introduced in the typical RedHat fashion... Which basically boils down to "F... you, I am taking your toys away, here's how you are going to do it from now on. Oh doesn't work, well F... you then." I was a sysadmin managing primarily RedHat servers when they yanked Docker away and replaced it with Podman which was capable of handling absolutely zero of our use cases (they all relied on the docker daemon). It couldn't even build our simplest containers from Dockerfiles.
- vetinari 5y ago
  Well, it was somewhat more nuanced than 'f... you, I'm taking your toys away'. The Docker attitute wrt to cooperation with Redhat might explain somewhat more. Some Docker folks even wore t-shirts, that explain why Redhat did what they did.
  - dralley 5y ago
    AFAIK the main points of contention were: * Systemd integration https://lwn.net/Articles/676938/ https://lwn.net/Articles/676938/ * CGroupsv2 - Docker was slow on adopting it, which was dragging down the ecosystem because no distros wanted to unilaterally break Docker by enabling it - so a Docker compatible replacement (ie. Podman) became a blocker for a lot of container functionality in CGroupsv2 that RH wanted to enable for customers. * Support for rootless / daemon-less containers (enabled by CGroupsv2) * A lot of enterprise customers wanted support for purely local, private container registries, Docker wanted people to be integrated with DockerHub and were reluctant (disclaimer: I work for Red Hat, but not on anything container-related, and I was still in college when all that drama was happening, so I don't have much insider perspective here) https://news.ycombinator.com/item?id=28430167 https://news.ycombinator.com/item?id=28430167
    - chillfox 5y ago
      I wouldn’t have been upset if they had introduced Podman alongside Docker as a choice, then replaced it when it was ready, but they didn’t. They pushed it hard as a replacement before it was anywhere close to production ready. The way it was handled pretty much burned what remained of my trust in Redhat to the ground for me. Most of Redhats selling point is that it’s supposed to be stable and as dependable as a bag of hammers, except that’s a lie.
geerlingguy 5y ago
I think the Podman-good-Docker-bad thing is/was amplified in certain corners, but by and large the number of users running Podman seems at least anecdotally to be a small fraction of those running Docker either on servers where K8s/other orchestrators aren't involved or Docker Desktop for Mac/PC.
isatty 5y ago
I don't want core technology that I use on my machine to be at the mercy of a private company. Container technology and the most popular way to use it _should_ be open source.
- mindwok 5y ago
  Docker is open source though... How is this different to Red Hat and Podman?
u801e 5y ago
> I basically just view the Docker daemon as an init system like systemd. Interestingly enough, systemd has a feature called nspawn that can be used to run application containers.

zzzeek 5y ago

from my experience I often find myself waiting for a hung docker daemon to give me the answer to a query. I dont know much about how it works but it feels monolithic and fragile the way a single container seems to be able to hang the whole thing and I can't even do a "docker ps" to see what's going on. Podman doesnt have any issues like that, it responds quickly at all times regardless of individual container status in my experience.

jiehong 5y ago

One thing that is actually nicer is that podman can run kubernetes pods from the kubernetes yaml file description (mostly) directly. This avoids having to use kubernetes in production, and something different (like docker-compose) in local. Being able to search in multiple container registries is very nice, and docker doesn't allow you to do that (to the best of my knowledge). It's very useful if you have a company container registry for example.

mindwok 5y ago
Yeah, I do agree about the pods. IMO pods are a better primitive than a single container, so its cool Podman supports them.
benatkin 5y ago
Why not just use Minikube or microk8s in a VM with multipass?
- metadat 5y ago
  > Why not just ... Podman comes with the ability to directly run Kubernetes YAML files, so the aforementioned non-standard addon things become unnecessary. Ever tried getting a team of 100+ engineers to agree between minikube vs docker-compose? It's not fun and produces nothing interesting. Thankfullyy, with Podman such discussions are no longer needed. Docker should've implemented this about 4-5 years ago, if they wanted to make their product The Best. Instead they became hostile to cool new product ideas, stopped on the ease of use front, and went all-in with Docker Desktop, which is just another non-standard kludge.
  - adra 5y ago
    To be fair they were fighting for docker swarm which ended up losing, so it's not surprising that they're on the back foot.
    - KronisLV 5y ago
      Currently still using Docker Swarm, i wish it was more popular, because it's oftentimes the logical next step when moving from running Docker containers manually or Docker Compose locally. It is pretty simple to use (especially with Portainer), not as resource intensive as most Kubernetes distros and the Compose format now matches what you'd run locally (with extra options, e.g. on which host to run things) vs the spammy format of Kubernetes manifests or even Helm charts. I actually wrote more about it on my blog: https://blog.kronis.dev/articles/docker-swarm-over-kubernetes https://blog.kronis.dev/articles/docker-swarm-over-kubernete... Though it's essentially inevitable that Swarm will be abandoned some day, so being able to migrate over to either Hashicorp Nomad or some Kubernetes distro is probably paramount, which is when tools like Kompose come in, when that's finally necessary. The problem of what cluster to run on still remains for all of the folks who are stuck with on-prem deployments, since most orgs can't pay for a team to manage a cluster or for bunches of hardware resources to run the full Kubernetes. In that regard, the best option that i've found so far is either K3s with Portainer, or K3s with Rancher (RKE and probably RKE2 will still be somewhat heavyweight).

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.
  - 5y ago

mbreese 5y ago

> For most of my use cases, I don't really care about rootless. See, and in almost all of my use-cases, I really do. I do HPC computing, which is almost always a multi-tenant environment. This makes using Docker really hard to use, security wise. Unfortunately, more and more software/workflows are getting distributed as Docker containers (for very good reasons). This makes my life difficult. So, if I can set it up so that users can more easily work with containers on my HPC compute nodes, I'd be very happy. If the defacto solution ends up as podman (and rootless), then I'm happy. (Yes, I use Singularity too, but it would be nicer to be able to not have to convert containers). Now, I do very little with networking and containers, so those types of requirements... I don't care as much about. But I know that is a big feature set for a lot of people here.

elmolino89 5y ago
Docker is not an option on HPC clusters I have been using so far. For me it is easier to just put SIF file where all users can run it/programs from it. There are issues in really closed evironments (no sudo on any machine) when one has to jump hoops to tweak=> build=>SIF transfer, but this is nuisance, not a problem. BTW, are there out there any on premises multi-user HPC clusters with Docker running on the nodes?
- AitchEmArsey 5y ago
  > BTW, are there out there any on premises multi-user HPC clusters with Docker running on the nodes? The vendor ClusterVision (EMEA, went bankrupt then returned to life) used to offer a cluster deployment option based on OpenStack+Docker; OpenStack for defining the cluster boundary on top of your hardware then Docker serving as the "image" on each compute node layered on top of the regular OS. Not at all a typical use-case for HPC containers, and with hindsight it is fairly obvious how that Byzantine stack resulted in too much complexity for them to support cost-effectively.
moonbug 5y ago
No lover of Docker, but I'd have much more confidence in the quality of the docker Daemon code than any hpc batch system's local execs.

chillfox 5y ago

Podman got introduced in the typical RedHat fashion... Which basically boils down to "F... you, I am taking your toys away, here's how you are going to do it from now on. Oh doesn't work, well F... you then." I was a sysadmin managing primarily RedHat servers when they yanked Docker away and replaced it with Podman which was capable of handling absolutely zero of our use cases (they all relied on the docker daemon). It couldn't even build our simplest containers from Dockerfiles.

vetinari 5y ago
Well, it was somewhat more nuanced than 'f... you, I'm taking your toys away'. The Docker attitute wrt to cooperation with Redhat might explain somewhat more. Some Docker folks even wore t-shirts, that explain why Redhat did what they did.
- dralley 5y ago
  AFAIK the main points of contention were: * Systemd integration https://lwn.net/Articles/676938/ https://lwn.net/Articles/676938/ * CGroupsv2 - Docker was slow on adopting it, which was dragging down the ecosystem because no distros wanted to unilaterally break Docker by enabling it - so a Docker compatible replacement (ie. Podman) became a blocker for a lot of container functionality in CGroupsv2 that RH wanted to enable for customers. * Support for rootless / daemon-less containers (enabled by CGroupsv2) * A lot of enterprise customers wanted support for purely local, private container registries, Docker wanted people to be integrated with DockerHub and were reluctant (disclaimer: I work for Red Hat, but not on anything container-related, and I was still in college when all that drama was happening, so I don't have much insider perspective here) https://news.ycombinator.com/item?id=28430167 https://news.ycombinator.com/item?id=28430167
  - chillfox 5y ago
    I wouldn’t have been upset if they had introduced Podman alongside Docker as a choice, then replaced it when it was ready, but they didn’t. They pushed it hard as a replacement before it was anywhere close to production ready. The way it was handled pretty much burned what remained of my trust in Redhat to the ground for me. Most of Redhats selling point is that it’s supposed to be stable and as dependable as a bag of hammers, except that’s a lie.

geerlingguy 5y ago

I think the Podman-good-Docker-bad thing is/was amplified in certain corners, but by and large the number of users running Podman seems at least anecdotally to be a small fraction of those running Docker either on servers where K8s/other orchestrators aren't involved or Docker Desktop for Mac/PC.

isatty 5y ago

I don't want core technology that I use on my machine to be at the mercy of a private company. Container technology and the most popular way to use it _should_ be open source.

mindwok 5y ago
Docker is open source though... How is this different to Red Hat and Podman?

u801e 5y ago

> I basically just view the Docker daemon as an init system like systemd. Interestingly enough, systemd has a feature called nspawn that can be used to run application containers.