9 ms·

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 sho

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 https://github.com/containers/podman-compose [2] https://github.com/portainer/portainer/issues/2991 https://github.com/portainer/portainer/issues/2991 [3] https://www.testcontainers.org/supported_docker_environment/ https://www.testcontainers.org/supported_docker_environment/ [4] https://github.com/containous/traefik/issues/5730 https://github.com/containous/traefik/issues/5730

zaro 7y ago
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.
- windexh8er 7y ago
  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.
  - zaro 7y ago
    > 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.
rcarmo 7y ago
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.
- Conan_Kudo 7y ago
  There's a podman-compose project that implements the docker-compose functionality leveraging podman: https://github.com/containers/podman-compose https://github.com/containers/podman-compose
  - wronglebowski 7y ago
    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.
    - ipbabble 7y ago
      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?
- wronglebowski 7y ago
  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.
  - steve_adams_86 7y ago
    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.
windexh8er 7y ago
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.
- mceachen 7y ago
  What bits are outdated? Can docker run rootless now or without a daemon? (I'm actually asking, I'm not a docker expert)
  - windexh8er 7y ago
    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-docker-416c9ad8c0d6 https://medium.com/@tonistiigi/experimenting-with-rootless-d...
    - ipbabble 7y ago
      dockerd/containerd ¯\_(ツ)_/¯
- freedomben 7y ago
  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
  - windexh8er 7y ago
boardwaalk 7y ago
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.
kawsper 7y ago
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 https://github.com/pascomnet/nomad-driver-podman
- justincormack 7y ago
  Work is ongoing (in runc mainly) to support that, and it should be available soon.
akerro 7y ago
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/ 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.
- lima 7y ago
  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.
- ecnahc515 7y ago
  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 https://github.com/quay/quay, but you can use any registry you want.
morpheuskafka 7y ago
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.
thinkmassive 7y ago
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-managing-containers-pods/ https://developers.redhat.com/blog/2019/01/15/podman-managin...
- ownagefool 7y ago
  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.
seba_dos1 7y ago
The main use case for containers for me are SDKs and build environments and Podman works pretty much as a drop-in replacement there.

zaro 7y ago

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.

windexh8er 7y ago
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.
- zaro 7y ago
  > 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.

rcarmo 7y ago

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.

Conan_Kudo 7y ago
There's a podman-compose project that implements the docker-compose functionality leveraging podman: https://github.com/containers/podman-compose https://github.com/containers/podman-compose
- wronglebowski 7y ago
  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.
  - ipbabble 7y ago
    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?
wronglebowski 7y ago
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.
- steve_adams_86 7y ago
  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.

windexh8er 7y ago

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.

mceachen 7y ago
What bits are outdated? Can docker run rootless now or without a daemon? (I'm actually asking, I'm not a docker expert)
- windexh8er 7y ago
  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-docker-416c9ad8c0d6 https://medium.com/@tonistiigi/experimenting-with-rootless-d...
  - ipbabble 7y ago
    dockerd/containerd ¯\_(ツ)_/¯
freedomben 7y ago
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
- windexh8er 7y ago

boardwaalk 7y ago

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.

kawsper 7y ago

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 https://github.com/pascomnet/nomad-driver-podman

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

akerro 7y ago

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

lima 7y ago
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.
ecnahc515 7y ago
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 https://github.com/quay/quay, but you can use any registry you want.

morpheuskafka 7y ago

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.

thinkmassive 7y ago

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-managing-containers-pods/ https://developers.redhat.com/blog/2019/01/15/podman-managin...

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

seba_dos1 7y ago

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