Podman and Buildah for Docker Users
developers.redhat.com
developers.redhat.com
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/
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.
>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.
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.
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.
docker network create
docker run
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?"
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...
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.
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.
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'm actually asking, I'm not a docker expert)
[0] https://medium.com/@tonistiigi/experimenting-with-rootless-d...
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
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.
> 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 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.
I wonder if one could build a API gateway that will expose podman commands as a socket in a docker API compatible way.
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
>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.
podman is not intended to be used by k8s/k3s, it's only for interactive container usage. k8s uses cri-o.
Reguarding Quay, it was literally open sourced this week: https://github.com/quay/quay, but you can use any registry you want.
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...
variables:
STORAGE_DRIVER: vfs
http://crunchtools.com/docker-support/
http://crunchtools.com/why-no-docker/
I work for Red Hat, but I find myself pretty centrist on this issue. There's good arguments on all sides. Red Hat isn't doing podman and buildah etc because they want to crush or destroy docker. There are legitimate arguments and they have been open about them.
One big one is security. You may think it's overly paranoid to be concerned about having a daemon (especially one running as root, tho rootless docker is either here or near), but keep in mind different people have different requirements. If you're a bank securing billions of dollars, that attack surface is scary.
Are there things that would be better with a different model then the runc:containerd? Sure. But is that really the primary factor here? I very much doubt it.
Red hat and google wanted docker gone, and have spent the capital to do so. Good business move for open shift, GKE and RHEL, but not necessarily in the long term interest of the open source community.
But same applies to Docker (the company). In the end, their decisions are also business moves, and they are not necessarily better for the open source community. And they have also proven that they don't always work in the interest of the community - remember the "I don't accept systemd patches" ?
I'm a skeptical person in general, but I try to give the benefit of the doubt and not always assume the worst.
I guess that would be for the Windows and macOS support as it should make things easier implement in a cross platform way when you can just proxy the cli commands to a daemon running in a Linux VM even when you are on Windows or macOS?
The first reason was to reduce privileges of the client interface. This would provide the possibility to reduce privileges and restrict what unprivileged could do later on. The communication over the socket is just http, which allows for remote management of docker containers.
A second reason was to build a strong contact between the client and server. The client became syntactic sugar for the rest calls, which helped stabilize docker. This would ultimately lead to enabling osx and win support via a VM on the host.
Another major goal was to enable the docker in docker use case which helped significantly when developing on docker itself.
Source: I was there. :)
I should review the comment a bit more carefully sometimes.
I rebooted a box one time, and some sort of tracking for the podman networking decided that my listening port was still in use even though no container was running. The only way I fixed it was to uninstall the networking tool podman uses (I forget it's name; slirp4ns or something) and podman itself then reinstall and start again.
I use docker daily, professionally, it has it's issues, but a lack of docker-compose like files and anecdotal reliability issues I've seen, I can't see it taking over from, or even competing with Docker for some time yet.
1) Go to Red Hat’s cloud site (linked on GitHub) and download the latest CRC release and your pull secret.
This does require having at least an empty Red Hat account, which may bother some.
2) Extract the release and run `crc setup` and let it do it’s thing.
3) Run `crc start -p /path/to/pull/secret` and wait for it to finish getting up and running. First time this may take 10 minutes, follow up starts 4. You can pass other options as well as needed.
4) Run `eval $(crc oc-env)` and start working with developer:developer credentials (or the provided kubeadmin creds). Use `crc console` to get to the WebUI.
We use this on Linux and macOS here just fine for local development and testing. As always, though, YMMV. CRC still has some other quirks that need to be ironed out, but it is generally useable. So far for us the weird parts are the limited self-signed certs and lack of cluster metrics, but both are known issues to the project. And that you can’t have a VPN process running as the startup will restart network services on your system.
Could someone who knowa more summarize any other benefits over docker?
I was wondering if those that have actually worked with podman had more insights.
First I want to mention a couple of things:
1) My blog didn't recognize the diversity of meanings for "Docker" to the Docker community. This is a problem when there is confusion over Docker company, Docker community, Docker as a collective of products, Docker as a single command line project/product. My blog was specifically focused on Docker CLI users. The Docker command line tool that so many of us grew to love. To say I "don't know our care how people use containers" is an unfortunate conclusion to make. I'm sorry of my restricted use made it seem that way. I will say I wrote all of the original Docker CLI manual pages. So I can claim a very deep knowledge of the Docker CLI. I had to test almost every aspect of the CLI in order to write those manual pages. As a result I filed several bugs too. But I do understand the the Docker CLI is just one part of the tooling that many Docker community users take advantage of. My definition of Docker was limited in my blog. It did not address projects like docker-compose etc.
2) It is unfair to say that Red Hat employees set out to destroy/ruin/whatever Docker. Very early on we wanted to help the Docker community. Red Hat provided a lot of validation to the Docker community by jumping on board and providing a lot of technical expertise and including it in RHEL and OpenShift. People like Dan Walsh and others tried very hard to explain both enterprise features required by risk averse users and also how to build a sustainable inclusive community model. Unfortunately much of our enthusiasm to help make Docker successful, based on our proven track record, fell on deaf ears. Perhaps their was s suspicion that were were looking after our own self interests but it really was a genuine effort to share our experiences in the community. Our open source first approach is always in the interest of the community and our customers and we know that that benefits us too. We know that strong inclusive communities benefit everyone. We sometimes get this wrong. But most times it works out - consider out move from our OpenShift cartridges technology to Docker. We didn't try to kill Docker, we knew it had the right approach. We wanted to make it better through open source community contributions. And we invested in Docker very heavily. Eventually some of our customer concerns with security could not be met with Docker's daemon approach (btw dockerd or containerd) and so wehad to address those requirements.
I have continued to talk about the value of Docker to the container community and how they revolutionized the industry because of their unique value add on Linux containers.
3) There are areas that Podman still needs to address. Some hare been worked on - podman-compose and a Mac client etc. Plenty of work to be done. If you're interested then please consider contributing to Podman (libpod) Podman-Compose etc. at https://github.com/containers
-ipbabble
Large users usually build their own, and small users are lazy to chase incremental improvements (if they do change they'll move to public build services).
https://metadata.ftp-master.debian.org/changelogs//main/g/go... https://bugs.debian.org/930440