Hacker News Reader

Comment by cabraca | Hacker News Reader

They claim "Podman provides a Docker-compatible command line front end and one can simply alias the Docker cli, `alias docker=podman`". That claim alone shows they dont know or dont care how people use container engines outside the k8s space. I know a lot of orgs that simply use docker-compose files to spin up simple setups. There is podman-compose[1] but its "still underdevelopment".

Then there is software using the docker socket.

Portainer? No Podman support [2]

Testcontainers? No Podman support [3]

Traefik? No Service discovery for you [4]

Should i go on?

yeah its rootless and i like the idea podman and buildah represent. What i dont like is the way they break at least part of the ecosystem.

[1] https://github.com/containers/podman-compose

[2] https://github.com/portainer/portainer/issues/2991

[3] https://www.testcontainers.org/supported_docker_environment/

[4] https://github.com/containous/traefik/issues/5730

View on HN

Podman supports pods, hence the name. It follows the k8s approach, and it’s nowhere close to a drop-in replacement for docker-compose, but managing multiple related containers is supported as a core feature.

To your point about the docker socket: I tried to set up Gitlab using podman, mainly for CI/CD, but it ended up being too much effort for a spontaneous hobby project. This aspect is severely lacking, I agree.

Edit to provide a relevant link: https://developers.redhat.com/blog/2019/01/15/podman-managin...

I've used gitlab and podman to build containers to give me non-privileged builds. You pretty much only need to set the following:

  variables:
    STORAGE_DRIVER: vfs

This should allow you to build within a container without the filesystem errors.

The lack of composer and Traefik support is the main reason I don't switch my personal projects to podman (work stuff is all K8s).

That and neither podman nor buildah being at least as easy to install on Ubuntu LTS then Docker.

Compose is just lovely for personal stuff. Swarm is also pretty decent (and easier to run for small clusters, if somewhat unstable networking-wise). Podman can't compare.

Have you found kompose to be a suitable replacement for compose? I’m trying to migrate my docker projects to k8s and I’m having a hell of a time.

I found kompose didn't give me a fluid experience with any project I tried using it with. I got endless API incompatibility issues for some reason. I'd have to dig through the docs and rewrite the files kompose generated. Even then they wouldn't always work.

There's a podman-compose project that implements the docker-compose functionality leveraging podman: https://github.com/containers/podman-compose

I attempted to use this for a couple very simple projects and the conversion completely fell on it's face. I tried four projects and none of them successfully converted.

I'm sure that project would benefit from your feedback. What did they say? Did they understand your issues? Were they able to fix it?

I really feel like Docker Compose and Swarm are underrated.

For running groups of related containers during development, Compose is wonderful - Compose files are simple and easy to understand even if you've never seen one before.

Swarm is also good for small-scale production deployments - it's just so simple to deploy and update. "secrets" and "configs" are also really useful, but of course I see the appeal of a centralised system such as Vault for complex deployments.

I've never tried to use Swarm it at scale, so don't know what kind of issues you might face that k8s would solve.

Can’t I just do all what docker-compose does with a Makefile and a couple of

  docker network create
  docker run

and so on? With much less magic involved?

The benefit is standardization. If every team you join has a `docker-compose.yml` to run a local development environment you know exactly what it is, how to add things to it, etc. If every team you join has a custom solution for an extremely lightweight development environment than you need to be brought up to speed every single time.

It's a similar argument to "Why do you need Makefiles when you can just write a bunch of bash files and a meta-bash file to execute each sub script based on the stat results of a list of files?"

> Can’t I just do all what docker-compose does with a Makefile

There's a lot of value in just being able to run a set of unified Docker Compose commands and have things work the same in every case with the same YAML configuration.

But technically yes you could replicate that behavior, however Docker Compose does a bunch of pretty nice things, like when you run docker-compose up it will intelligently recreate containers that changed but leave the others untouched. Then there's the whole concept of override files, etc..

It would take a fair amount of scripting to emulate all of that behavior along with getting all of the signal processing and piping multiple services to 1 terminal output acting well. Even today Docker Compose has issues with that after years of development.

You should run docker-compose with --verbose one day just to see what really happens under the hood. Compose is doing a lot. For example I wrote about this a while back. It also includes an example output of running a single service app with --verbose: https://nickjanetakis.com/blog/docker-tip-60-what-really-hap...

The recommended approach for managing groups of multiple containers with podman seems to be using pods (hence the name), which can be managed by Makefiles as you describe.

This is like asking "can't I just use a cellar + ice instead of using a fridge?".

Yes, through a lot of scripting, you can emulate docker-compose. But compose actually handles a lot of things, to the point that manual scripting doesn't really make any sense.

I don't understand how people manage multiple related containers -without- compose. It makes things so much easier.

Among other responsibilities, I currently manage a Docker Swarm deployment that serves between 10k and 100k users. I can’t compare to k8s since I lack experience with k8s, but I can say that ops on this service take approximately 1% of my time per month. After the initial learning curve, Swarm has proven quite stable and easy to work with. 10/10 would deploy with again (in fact, I will within the next week).

> Compose is just lovely for personal stuff

We use it for production, spinning up hundreds of identical setups. We just baked an AMI with a docker-compose.yml with restart: always and it is very dependable.

It’s not even dependable for us on local setups; a “docker-compose up” that has to pull images will almost always throw an HTTP timeout exception from inside The Python client.

Almost guaranteed that's not a Docker compose issue.

Hard to say. Our whole team experiences it, there are a dozen related issues in the issue tracker, and the docker-cli and Go bindings work fine while docker-compose is timing out. Based on the issues we’ve had and those files in their issue tracker, there are lots of related issues including some where the docker daemon (or perhaps the docker for mac VM) is unresponsive; we’ve definitely seen that, but as previously mentioned, we’ve also seen this issue while the daemon responds to other clients.

Fair points. Work is ongoing with a podman-compose. I haven't used it myself. Most of the routing work for our initial users are focused on is around Kubernetes/okd/OpenShift (and not Swarm) and so that's where those routing issues are solved.

I know someone worked on a Ubuntu build but I'm not sure who is maintaining that. It would be a great place for people to contribute.

I think that removing the docker socket is a feature of podman. I never really understood the need for the docker daemon anyway, especially when you are building container.

If you are only building a container then you can use BuildKit. But there are plenty of instances where having the socket is extremely useful. For example I've seen plenty of test suites run in a container on a unique host that uses Docker socket to build containers on many other hosts.

The Docker daemon used to be required. It has always done a lot of things. I don't understand your comment given the fact minimizing Docker today is easy because functions of container operations have been broken out into unique tools over time. Part of Dockers success, I believe, is that you could do everything in a single install.

> But there are plenty of instances where having the socket is extremely useful. Of course there are plenty of cases where the socket is useful, but you can have the daemon on top of non daemon requiring tools. Which BTW is the direction docker is going in now, when it is an industry standard.

>The Docker daemon used to be required. It has always done a lot of things.

But initially docker was doing two things only, build a container and run a container. And for both daemon is not required.

> Part of Dockers success, I believe, is that you could do everything in a single install. Single install has to do only with packaging, not the architecture or docker.

Also Docker doesn't support the newest version of Fedora because they've switched to cgroups version 2.

Another project that doesn't support Podman is Nomad from Hashicorp, someone have tried to make a driver, but it is far from production ready: https://github.com/pascomnet/nomad-driver-podman

Work is ongoing (in runc mainly) to support that, and it should be available soon.

Just as a single data point, and I'm not too deep in the ecosystem obviously, I haven't used any of these things and I've only heard of traefik.

I wonder if one could build a API gateway that will expose podman commands as a socket in a docker API compatible way.

And I'm not sure why the OPs link is relevant. If you look at the blog post it's all old architecture and most of the first round of points of "why not Docker" (a favorite way of RHEL employees to have a conversation about containers) are completely outdated and wrong as it stands today. It's actually a pretty entertaining read given most of the points no longer apply.

What bits are outdated? Can docker run rootless now or without a daemon?

(I'm actually asking, I'm not a docker expert)

The entire architecture in the blog post is wrong and thereby most of the bulleted reasons the author claims. The container runtime is now containerd and, yes, there have been many strides to run rootless [0].

[0] https://medium.com/@tonistiigi/experimenting-with-rootless-d...

dockerd/containerd ¯\_(ツ)_/¯

I don't disagree with you, but two things worth considering:

1. Perhaps it's blog posts like these and innovation in RH tools that spurred docker into action making things better?

2. You've got to remember the target market where RH operates: huge scale, and often extremely high security. To you a daemon may not be a big deal, but to a bank that's an attack surface that is scary. You might not find the "docker has an unnecessary daemon" argument compelling, but many in the high security field definitely do.

Disclaimer: I work for Red Hat

Docker architecture isn't reflective of that blog post anymore. Considering containerd is now the runtime, the arguments outlined initially for "why Docker isn't good in Redhats eyes" are no longer valid in the case of how the argument is laid out.

I don't feel Docker was incented to do anything based on RH's blog posts. I worked for Docker and the joke internally was how hard RH went out of their way in a "me too" fashion to compare their homegrown products, that weren't offering any upside and offering a lot of replacements that weren't nearly with feature parity. Dan Walsh was the butt of many jokes with his tirades about how one should never say Docker, and in turn probably exposed more people to Docker than he turned away.

High security? As I understand it RH doesn't have a way to guarantee containers that are requested to be run have been signed by appropriate release control. Docker can.

Since you're a RH employee maybe you can share the innovative reasoning why RH removed all Docker bits (that they could) from the OS and started telling customers Docker on RHEL wasn't supported? Sounds very anti-innovative to me, but would love your feedback.

Thanks for sharing your perspective, I appreciate it!

> Since you're a RH employee maybe you can share the innovative reasoning why RH removed all Docker bits (that they could) from the OS and started telling customers Docker on RHEL wasn't supported? Sounds very anti-innovative to me, but would love your feedback.

I don't work on any of the podman/buildah/etc stuff so I can't speak about any of that as an employee since I have no special insight. (I just disclosed my employer previously so people can judge for themselves if my opinions/thoughts reflect a conflict of interest).

But speaking just as a fan of docker (and of podman too), I actually agree that removing the docker bits from RHEL isn't cool. I've used Fedora as my workstation for over 10 years now and were I still working for various start ups I'd have a harder time since I used Docker for containerizing and deploying our apps. I'd probably have to run Ubuntu in a VM so I could use "real" docker, which would make me sad.

As I understand it tho it wasn't a decision they reached lightly. There were compatibility issues (such as cgroups v2) that would have held back other things. Sorry I can't be any more specific. I just don't know enough about the background.

I do think the real or perceived animosity tho is counter-productive, and I agree the Dan Walsh stuff was a bit on the silly side. I mean, "docker" and "containers" really did become synonymous in many developer minds, but I don't see why that was a big deal (and it certainly wasn't unfairly earned).

Can you comment about the Docker closed API stuff? As I understand it, Docker (the company) never released the API to the community (or CNCF, etc) and that is part of the reason why RH didn't want to support it for reasons of legal ambiguity and not wanting to be on the hook for a specific vendor's implementation.

I think it's a shame there isn't more collaboration between the RH people and Docker people. The rift may not be reparable now, but I hope we don't end up with a huge divide in the community where all RH/Fedora people have to use podman and Ubuntu/Debian people use Docker, and each OS doesn't support the either. That would be bad for everyone.

Sorry this comment is going on forever, but lastly since you worked for docker, thank you! Docker revolutionized the way I did things and has made my life better. Regardless what happens, Docker will have a warm place in my heart.

I regret to inform you that you are not understanding this point regarding the daemon correctly. The containerd process is a replacement for the dockerd. It's just a new daemon I apologize I didn't address this clearly in the blog - I was a bit flippant in using dockerd only when I should have mentioned containerd.

I agree that when you're working within the Docker Swarm type community there was probably little incentive to to anything based on RHs blog post.

I'm very sorry to hear that Dan Walsh was the butt of many jokes at Docker. Dan Walsh did so much for the Docker community at the start - SELinux work being just one area of his many important contributions to making Docker successful.

We removed it because we have decided to support one OCI based container toolset in RHEL. Just like we switched from our home grown open source cartridge approach and dropped it to Dockers homegrown based approach in RHEL and OpenShift we had to do the same. We did this with our Gear versus Kubernetes versus Swarm versus Mesos approach. All of these are really good technologies. I myself advocated some support for Mesos at one time. It was about engineering and support focus. It wasn't about killing innovation. It's about focus. This is certainly my personal opinion of our business decision but it is shared by others I work with.

Was just about to post a comment pointing this out, autoconfiguration based on information obtained from the docker socket is a killer feature for a lot of software like Traefik.

The main use case for containers for me are SDKs and build environments and Podman works pretty much as a drop-in replacement there.

Yes, let's go on:

>Podman provides a Docker-compatible command

- not when you're using docker-compose and have custom scripts for docker-compose

- lack of support from Linux distributions - only Fedora switched to Podman a few weeks ago and a few people at work where abandoned with their problems so they switched to Ubuntu and Arch

- still don't know how to self-host podman/quay repository locally - only paid services available - even for homelab - https://quay.io/plans/

- k8s/k3s integration - broken (for me?), never managed to make it work locally in homelab

I see absolutely no reason to ever switch to podman and quay as it's in current state.

Quay is unrelated to podman (and has been open sourced last week, I think).

podman is not intended to be used by k8s/k3s, it's only for interactive container usage. k8s uses cri-o.

Podman is just a OCI compliant container runtime. You can use any registry, and any images you want that you used with Docker.

Reguarding Quay, it was literally open sourced this week: https://github.com/quay/quay, but you can use any registry you want.

Reply on news.ycombinator.com