We've been using it for a couple of years running and managing hundreds of containers per server - no feeling of flakiness whatsoever. It's virtually zeroconf and even supports GPUs for those who need it. It's like docker but better, IMO.
Hope it gets a popularity boost from CNCF. Rooting for it.
The Podman ecosystem has given me a strong disliking of the Docker ecosystem, so I'm also rooting for it.
I use Drone, but instead of using the Docker plugin I start a detached (background) Caddy server to work as a proxy to DOCKER_HOST. That lets me proxy to the local Docker socket to take advantage of caching, etc. while I'm iterating, but gives the option of spinning up docker-in-docker to get a clean environment, without any caching, and running a slower build that virtually identical to what happens on the CI server.
I find that having the daemon available solves a ton of issues that most of the CI provided builder plugins have. For example, with the builder plugins I'd always end up with a step like build-and-tag-and-push which didn't work very well for me. Now I can run discreet build steps like build, test, tag, push and it feels far more intuitive, at least to me.
Past versions of podman were flaky, but since version 4, which is now a couple of years old, I haven't had any issues whatsoever. I'd recommend anyone using containers on linux to try it out instead of installing docker out of habit.
But Compose doesn’t mesh well with the overall NixOS configuration system. So I ended up building a custom tool that can convert your existing Compose project into a NixOS config.
Note that Linux allows you to mount overlay within a user namespace if you are root within the user namespace.
In other words, if you are root within a container; even though it is not root on the host; Linux accepte ton mount overlay filesystems (most filesystems are not allowed). `man user_namespace`
podman system reset
You may need to set
[storage]
driver = "overlay"
https://docs.podman.io/en/stable/markdown/podman-system-rese...
And assuming my own comment is high up, this is the env variable we automatically load:
> DOCKER_HOST=unix:///run/user/1000/podman/podman.sock
I wanted to say something funny about "rooting" and "rootless", but it's probably too silly. :)
I'd love to get the benefits of Docker without the battery drain and the Docker software, but I'm not sure if Podman would help much with either.
Edit: .. because the runner is not needing to run as root
[0]: https://docs.docker.com/reference/cli/docker/#environment-va...
[1]: https://podman-desktop.io/docs/migrating-from-docker/using-t...
Is that "docker-compose" (with a dash) or "docker compose" (with a space)?
See ref: https://docs.docker.com/compose/install/#scenario-two-instal...
No root necessary :)
Also networking in rootless containers still suck.
The end result is just go bakc to docker with less hassle and better stability.
https://docs.redhat.com/en-us/documentation/red_hat_enterpri...
I write this to say, "This is not them dumping abandonware." To me, it's them putting these technologies under the supervision of a neutral third party to encourage adoption.
If two OCI images share the same file, they'll be de-duplicated on disk and only be downloaded once.
Look: I'm probably ignorant, but from the outside the similarities seem striking.
Please explain why I'm wrong. I'm humble on this one.
I'm we can all think of some projects "abandoned" to foundations through the years, but in general, I'd call getting core infrastructure out of the control of a single company and into a place with more transparent and democratic governance a good thing.
https://keycloak.devstats.cncf.io/d/1/activity-repository-gr...
CNCF has probably 20x the funding of the ASF and is a different organization that spends millions of dollars on security audits, events and more, you can read about it in our annual report: https://www.cncf.io/reports/cncf-annual-report-2023/
Also we actively remove/prune projects that aren't active... we will probably archive ~10 this year https://www.cncf.io/project-metrics/
But sure, unfortunately if not enough different companies and individiuals are maintaining stuff it gets abandoned.
Well, clearly not.
I could go back to docker but why?
On Fedora w/ SELinux that led to quite a bit of compatibility issues for a while with lots of quirky things that didn't behave the same.
I think their implementations have gotten pretty stable and improved in compatibility since then
I use it together with systemd in my home lab. It's Kubernetes for single node and without the bloat. I love it!
https://www.redhat.com/en/blog/kubernetes-workloads-podman-s...
The only downside is that some things are not yet supported in quadlets, and that things don't map 1 to 1 between quadlets and the command line.
podman-compose never worked very well for me, so I'm running with the podman.socket systemd service and the standalone version of docker-compose. That is however working flawlessly.
What I really like about podman (and which to be fair docker might have since catched up on) is that rootless containers work so well. Gone are the days where bind-mounting a project folder into a container would mess with your file permissions.
In my experience podman also feels easier and less invasive to install, although I can't say if the latter is really the case.
Otherwise it honestly is great and preferable over Docker.
[0] https://github.com/compose-spec/compose-spec?tab=readme-ov-f...
I think version 4 was where podman became a reliable tool, whereas I found it to be flaky and unreliable in previous versions.
I don't use vs code extensions for managing my containers, so I can't say much about those, but I wonder if many of them won't work fine with an alias for docker and maybe the podman-socket running.
I teach various Linux training courses. One of which is Containers. It always shocks several people per-class how Docker just blatantly ignores and rewrites existing firewall rules. And there's no real option to prevent that unless you want to manually configure ALL network routing.
For me personally, that was one of the big issues the pushed me over to Podman.
Also, Docker's insistence on "forcing" and preventing the disabling of using the malware-ridden Docker Hub didn't help me appreciate their security practices.[]
[]
https://jfrog.com/blog/attacks-on-docker-with-millions-of-ma...
https://www.infosecurity-magazine.com/news/malicious-contain...
https://www.bleepingcomputer.com/news/security/millions-of-d...
https://www.bleepingcomputer.com/news/security/docker-hub-re...
https://sysdig.com/blog/analysis-of-supply-chain-attacks-thr...
... ETC ...
My workaround has been to bind all docker port forwards to localhost and only ever expose them externally via reverse proxy. Which is annoying because that means I can't run the reverse proxy itself in docker.
Yeah. Many times I've mentioned that to people, and they just don't believe it's a thing which Docker does. Including here on HN. :/
On the other:
> The Docker compose CLI plugin has no stable output format (see for example https://github.com/docker/compose/issues/10872 ), and for the main operations also no machine friendly output format. The module tries to accomodate this with various version-dependent behavior adjustments and with testing older and newer versions of the Docker compose CLI plugin. Currently the module is tested with multiple plugin versions between 2.18.1 and 2.23.3. The exact list of plugin versions will change over time. New releases of the Docker compose CLI plugin can break this module at any time.