Larvitz  1d ago

Running Podman  in production for years now, and I don't miss the Docker daemon one bit.

I just published a deep dive on managing OCI containers the Unix way: daemonless, rootless, and natively integrated with systemd via Quadlets.

I cover:
- Real secrets management
- Auto-updates via systemd timers
- The Docker compatibility layer

This is the guide I wish I had when making the switch.

Read it here: https://blog.hofstede.it/podman-in-production-quadlets-secrets-auto-updates-and-docker-compatibility/

#Podman #Linux #DevOps #Systemd #Homelab #Sysadmin #Containers

Podman in Production: Quadlets, Secrets, Auto-Updates, and Docker Compatibility

An opinionated production-ops guide to Podman on Linux servers - why I prefer it over Docker, how Quadlets replace Compose files, and practical patterns from real deployments including secrets mana...

Larvitz Blog
Show threadArtemis
@Larvitz Interesting.
For me, the poor Compose support is one of the reasons I'm still sticking with Docker for development. Although, I think, the advantage of Compose files is simplicity (not having to commit to the whole systemd units system).
9:34amWeb
Show threadLarvitz  13h ago
@art_codesmith You can use the original docker-compose with Podman, by enabling the compatibility socket. I run one application in production like that, where the author only maintains a (rather complex) compose file.
Show threadArtemis13h ago
@Larvitz I might be wrong but, don't you lose basically all advantages of Podman by doing so? Having to give up daemonless and rootless.
Show threadLarvitz  13h ago
@art_codesmith Not really. Podman containers still spawn as their own forked processes, even when rootful. The socket isnt't a daemon, but just executing a fresh container context. In my opinion still a cleaner architecture than dockerd.
Show threadArtemis13h ago
@Larvitz Thank you. I might have to dig a bit further into this.