There is a podman-compose which works almost as drop-in replacement.

Almost because most common commands work, but I have not check all.

And almost, because for some docker-compose.yaml which you downloaded/LLM generated you may need to prepend `docker.io/` to the image name

Podman 4.7 supports both the ordinary compose (Go implementation) and older Python podman-compose. But personally I moved to quadlets and didn't look back.

The core of docker needs to be free. The docker registry can charge corporate customers for storage and such, but besides being the default registry, there's not much money there because it's a commodity service, not anything unique.

There's just not much money to be made there, especially considering that docker is a pretty thin wrapper built on top of a bunch of other free technology.

When somebody can make a meaningful (though limited) clone of your core product in 100 lines of bash, you can't make much of a business on top of it [1]

Docker suffers from being useful in the open source space but having no reasonable method to make revenue.

https://github.com/p8952/bocker

They have the second problem that `container` [1] will eat up a ton of their business when it ships properly in a month or two.

[1]: https://github.com/apple/container

Fedora is rather aggressive in pushing Podman. They have their Cockpit control panel for Fedora Server, and they've simply made the Cockpit Docker plugin unavailable when it was working fine, because "use Podman integration plugin instead".

> you just SSH in to a box, patch it

Oh god. I can’t imagine how I could build reliably software if this is what I was doing. How do you know what “patches” are needed to run your software?

Containers and container orchestrators are complex tools. The constant cost of using them is pretty high compared to bash scripts. However the scale / maintenance factor is significantly lower, so for a 100 boxes simplicity of bash scripts might still win out over the containers. At 1000 machines it is highly likely that simplest and least maintenance overall solution will be using an orchestrator.

I couldn't agree more.

It's really not that hard, folks are just trading Linux knowledge for CI/CD knowledge.

Its React but for DevOps

Well... yeah? If you exist in as an individual or part of a group which is integrated (shared trust, goals, knowledge etc.) then yeah, obviously you do not have the problem (tragedy of the commons) that splitting things up (including into containers, but literally any kind of boundary) solves for.

The container split is often introduced because you have product-a, product-b and infrastructure operations teams/individuals that all share responsibility for an OS user space (and therefore none are accountable for it). You instead structure things as: a host OS and container platform for which infra is responsible, and then product-a container(s) and product-b container(s) for which those teams are responsible.

These boundaries are placed (between networks, machines, hosts and guests, namespaces, users, processes, modules, etc. when needed due to trust or useful due to knowledge sharing and goal alignment.

When they are present in single-user or small highly-integrated team environments, it's because they've been cargo-culted there, yes, but I've seen an equal number of environments where effective and correct boundaries were missing as I've seen ones where they were superfluous.

I've had similar issues using kubectl to access some tools that made a lot of requests (polling, which is something argocd does I believe).

Setting this environment variable helped a lot: KUBECTL_PORT_FORWARD_WEBSOCKETS=true

Note: because Google's quality is falling you won't be able to find this variable using their search, but you can read about it by searching Bing or asking an LLM.

At a high level, Docker and Podman implement the same standard for containers, but my understanding is that Podman implements more of said standard (more/newer features) and in a more standards compliant way.

This can be a good or a bad thing—good because it's better, but bad because the popularity of Docker sometimes means things aren't compatible and require some tweaking to get running.

Podman is daemonless while docker is a client/server pair. Podman also shipped with support for rootless containers, though Docker now has that capability as well.

The podman CLI is nearly a drop-in replacement for docker such that `alias docker=podman` works for many of the most common use cases.

If you don't care about the security implications of running containers as root via a client/server protocol, then by all means keep using Docker. I've switched to podman and I'm happy with my decision, but to each their own.

Keep using docker, who cares. The article is concerned about CVEs, etc, but this doesn't matter for development very much.

If you use k8s for anything, podman might help you avoid remembering yet another iac format.