Hacker News Reader

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.

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.

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.

> 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?

it works the same on Linux

> 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.

Docker healthchecks don't actually do anything besides status reporting AFAIK.

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.

Then... why not just use docker?

Because the difference is not just the socket.

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

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?

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/tutorial...

Thanks! It seems that netavark uses macvlan to avoid creating bridge devices. Although it can also use bridges, and Docker added macvlan support too: https://github.com/moby/libnetwork/blob/master/docs/macvlan.... That page also gives a lot of background on the different methods and their pros/cons.

I guess at this point the difference is only the defaults of each system.

It has a less clear future with the company behind it.

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.

I use docker, too, and it's absolutely trivial to add the .repo file for the official docker repo to /etc/yum.repos.d/. "Yanked away" is pretty strong and unwarranted, IMO.

The issue with this is that it's no longer covered by Red Hat's support and lifecycle, which is why most people pay for RHEL anyway.

You can pay docker for business licences to get commercial support. At the level where you think about getting it, I honestly can't feel bad about the extra cost to the company.

Adding repos from third parties is not always allowed due to political/security considerations. Besides when paying for Redhat based on it being better/more "stable" then them breaking all your stuff by removing it is absolutely an issue.

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.

AFAIK the main points of contention were:

* Systemd integration 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

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.

But Docker was not ready and was causing problems. If it wasn't, there would be no point for Podman in the first place. Otherwise, it would delay development of RHEL for years (see the Cgroup v2 issue, for example).

I'm no Redhat fan, but they do have point here. They are not the baddy here.

> 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.

> See, and in almost all of my use-cases, I really do. I do HPC computing, which is almost always a multi-tenant environment.

Maybe you need firecracker with something along the lines of https://github.com/combust-labs/firebuild?

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?

> 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.

Yeah fair enough, if you're in a situation where you have several unprivileged users sharing a VM or something than it makes sense. I haven't come across that yet personally.

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.

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.

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.

Yeah, I do agree about the pods. IMO pods are a better primitive than a single container, so its cool Podman supports them.

Why not just use Minikube or microk8s in a VM with multipass?

> 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.

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.

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-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).

Agreed. I never really got hooked on Docker itself, but Swarm is well-scoped and easy to use without sacrificing too much; I'd argue the vast majority of k8s users would be better off with something simpler, and Swarm fits the bill nicely. Maybe Nomad does too, but IMO Hashicorp do a really bad job of documenting the progression from a localhost test to a production setup; the docs for each of their tools can be summarised as "draw the rest of the fucking owl".

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.

Docker is open source though... How is this different to Red Hat and Podman?

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.

> 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.