71–80 of 90 posts
I love podman. When you write a file to a volume from a container, the user that spawned the container is the owner. This is exactly what you expect, but with docker, everything is written as root. After many years, this has not been fixed: https://github.com/moby/moby/issues/2259 This has made it impossible to use docker in scripts where root access is not available. Thank you podman!
Earlier quoted context omitted.
From what I've seen in all these Podman articles, I've come to the same conclusion as you. This is how Podman fits in: Podman (and its various components) can replace everything but parts of Docker Desktop, namely the GUI that Docker Desktop, has. For everything else, it has it's own Docker compatible CLI, an optional daemon (by default it's daemonless), there is no containerd component as it communicates directly to…
Docker Desktop isn’t really about the GUI so much as the management of, and host integration with, a Linux VM for running on non-Linux OSes. Notably, there’s no Docker Desktop for Linux, only macOS and Windows.
Looks like they are adding it https://twitter.com/glours/status/1438526841577357315
I quote: "A dream coming true for a lot of #linux users, @dieuthicao announced that we’ll start working on a #Linux version of @docker Desktop"
Earlier quoted context omitted.
Yep. Podman takes cares of those things using the `podman machine` sub-command. From what I understand, currently only macOS might be working, but Windows support will be coming if it's not already there.
AFAICT podman machine relies on VirtualBox. This would be an enormous performance and resource regression on MacOS — Docker Desktop uses the much more performant and resource-conscious native hypervisor frameworks instead.
According to a post on the podman website: "Current implementation relies on qemu which currently has some platform dependencies." [1]
I also just checked on my machine and it is indeed running on Qemu.
IIRC Qemu also has support for Apple's Hypervisor.framework.
[1] https://podman.io/community/meeting/notes/2021-04-06/#podman...
Somehow a lot of these blog posts seem to get the fine technical details of the marketing speak wrong. > Docker recently changed the license From my understanding this is related to Docker Desktop not Docker. I'm pretty sure Podman can't replace Docker Desktop. This is also what the linked website says. Or did I miss something? And in the linked Blog post it says > Docker was dropped from Kubernetes. which from my un…
> I'm pretty sure Podman can't replace Docker Desktop. Multiple siblings here have already mentioned that it absolutely can (and does for many). My question is: in what way does it not? What is Docker Desktop doing for you that podman lacks? Just UI?
Docker desktop also includes Docker-compose (a way to chain multiple docker container together)
And of course the UI.
Podman is just replacing the basic docker CLI. I would say that podman replaces about 20% of what Docker desktop offers.
Somehow a lot of these blog posts seem to get the fine technical details of the marketing speak wrong. > Docker recently changed the license From my understanding this is related to Docker Desktop not Docker. I'm pretty sure Podman can't replace Docker Desktop. This is also what the linked website says. Or did I miss something? And in the linked Blog post it says > Docker was dropped from Kubernetes. which from my un…
Podman can replace docker desktop. It doesn't have the same GUI but it does have the capability to run containers via familiar CLI commands on a variety of OSes, connecting to (and in some cases provisioning through podman machine) a VM when required I also think that it's more than safe to say that K8s is dropping Docker when they've deprecated it as a container runtime
Docker desktop also includes Docker-compose (a way to chain multiple docker container together)
And of course the UI.
Podman is just replacing the basic docker CLI. I would say that podman replaces about 20% of what Docker desktop offers.
Earlier quoted context omitted.
It seems to me that almost no one understands the difference between the various layers of "Docker" (that is to say: Desktop, CLI, daemon, containerd, runc) and which layers tools like Podman aim to replace.
From what I've seen in all these Podman articles, I've come to the same conclusion as you. This is how Podman fits in: Podman (and its various components) can replace everything but parts of Docker Desktop, namely the GUI that Docker Desktop, has. For everything else, it has it's own Docker compatible CLI, an optional daemon (by default it's daemonless), there is no containerd component as it communicates directly to…
Except for:
- Docker Compose (because podman-compose has a large amount of open issues https://github.com/containers/podman-compose/issues)
- Docker Swarm (since Docker provides a lightweight orchestrator out of the box), you'd need to use something like K3s or another Kubernetes distro
- anything that uses the Docker socket (/var/run/docker.sock), so you can forget about running anything like Portainer or any of the other tools out thereEarlier quoted context omitted.
From what I've seen in all these Podman articles, I've come to the same conclusion as you. This is how Podman fits in: Podman (and its various components) can replace everything but parts of Docker Desktop, namely the GUI that Docker Desktop, has. For everything else, it has it's own Docker compatible CLI, an optional daemon (by default it's daemonless), there is no containerd component as it communicates directly to…
> For everything else... Except for: - Docker Compose (because podman-compose has a large amount of open issues https://github.com/containers/podman-compose/issues) - Docker Swarm (since Docker provides a lightweight orchestrator out of the box), you'd need to use something like K3s or another Kubernetes distro - anything that uses the Docker socket (/var/run/docker.sock), so you can forget about running anything lik…
See for example: https://www.redhat.com/sysadmin/podman-docker-compose
Earlier quoted context omitted.
> For everything else... Except for: - Docker Compose (because podman-compose has a large amount of open issues https://github.com/containers/podman-compose/issues) - Docker Swarm (since Docker provides a lightweight orchestrator out of the box), you'd need to use something like K3s or another Kubernetes distro - anything that uses the Docker socket (/var/run/docker.sock), so you can forget about running anything lik…
No longer true. Podman nowadays ships with an optional daemon that serves a Docker-compatible interface, so you can use docker-compose directly if that's what you want. See for example: https://www.redhat.com/sysadmin/podman-docker-compose
Of course, there's no Swarm support, as evidenced by that very article:
> Caveats
> One known caveat is that Podman has not and will not implement the Swarm function. Therefore, if your Docker Compose instance uses Swarm, it will not work with Podman.
Feels like people will either be pigeonholed into Kubernetes for all of their deployments, or will have to migrate over to something like Hashicorp Nomad: https://www.nomadproject.io/
Curiously, it also supports Podman as a task driver: https://www.nomadproject.io/docs/drivers/podman
Earlier quoted context omitted.
AFAICT podman machine relies on VirtualBox. This would be an enormous performance and resource regression on MacOS — Docker Desktop uses the much more performant and resource-conscious native hypervisor frameworks instead.
This doesn't seem accurate. According to a post on the podman website: "Current implementation relies on qemu which currently has some platform dependencies." [1] I also just checked on my machine and it is indeed running on Qemu. IIRC Qemu also has support for Apple's Hypervisor.framework. [1] https://podman.io/community/meeting/notes/2021-04-06/#podman...