I don't like Docker or Podman

<p><pre><code> 1. I got hurt by Docker. 2. I don&#x27;t want to learn Docker. 3. I got hurt by Docker more. 4. I don&#x27;t trust DockerHub. 5. Podman is just like Docker. 6. I prefer VMs because I understand them, even though I know they are slower. 7. Don&#x27;t try to explain Docker to me. </code></pre> A rant, nothing to see here, move along.

So here&#x27;s the thing: Docker is the best way we have to document how to set up a project&#x2F;application in a way that can be repeated on arbitrary computers. The alternative was &quot;have a README where you list all of the things you need to do&#x2F;install in order to get this project running&quot;.<p>That failed. Miserably.<p>Developers always assumed things like &quot;well naturally, if you&#x27;re playing in the XYZ space, you&#x27;ve already got meson installed. What, do you expect me to teach you basic arithmetic in this README too?&quot; Developers across the board, across programming subcultures, showed themselves unable to get past this sort of thing.<p>So now we have Docker. You may not like it, but this is what peak install guide looks like. An unambiguous file that describes the exact shell steps required to get the piece of software running, starting from a base distro. The developer can&#x27;t omit any steps or the container won&#x27;t work on their machine.<p>It sucks that this Hegelian situation calls for such a draconian solution, but that&#x27;s where we&#x27;re at. Developers as a whole can&#x27;t be trusted to handle this on their own. If you don&#x27;t have a better solution to this problem, I&#x27;m not sure there&#x27;s much point in complaining.

All of the author&#x27;s complaints are correct, of course, but the question is simply whether the juice is worth the squeeze. For the most part, I think, it is.

The most evil pattern is when application developers force users to install Docker to use their applications.

I like your post, I still prefer zones and jails over anything in the Linux ecosystem. Building and admining an on-prem k8s cluster has only enforced this opinion.

Posts where the author proclaims they don&#x27;t even want to try and understand why something is the way it is just lose all credibility to me.

&gt; I prefer to use virtual machines. They’re slower to set up, and start up a little slower too [...]<p>LXD containers solved a lot of the problems inherit to virtual machines for me, though I don&#x27;t like their reliance on global configs (something like Docker compose for LXD containers would be ideal).

&gt; Docker is very popular software to build Linux container images and running software in them. I don’t like it.<p>&gt; Podman is a re-implementation of the concept, command line interface, and file formats that is very close to identical to Docker. I don’t like that either.<p>&gt; I’ve used *systemd-nspawn* fairly extensively to run things in containers. It’s a much simpler container system than Docker, and I do not find it objectionable. I built a CI engine on top of it. But I don’t use it either, any more.<p>This person is actually insane, but huge respect for doing things differently!

&gt; The command line interface is really badly designed. It’s ugly, hard to learn, difficult to remember, illogical, inconsistent, and just makes no sense to me at all.<p>I wonder if the author could elaborate here.

Podman beeing mostly compatible with docker was a wise choice. If you run rootless no way to break fw&#x2F;network like docker can.<p>With podman in mind, one ought to try buildah and skopeo. Again, buildah can run Dockerfiles, but you are not constrained to the weird Dockerfile syntax.

I agree with the general point - there are a bunch of things I don&#x27;t like about Docker much. (Podman inherits the same issues but it is just copying the interface). Definitely agree on the licensing thing. It&#x27;s quite a trap if you have some copyleft surprise and they could do more - like just require an SPDX identifier on each repository &#x2F; image.<p>I&#x27;ve used systemd-nspawn before. I didn&#x27;t find it notably simpler and did find lots of weird edge cases where things didn&#x27;t work (most recently something between ~249 and ~253 giving &#x27;permission denied&#x27; errors on mounting &#x2F;proc into new sub-namespaces within it, boy was that not a fun or easy time to try to work out). Maybe that makes their final point a fair one, that VMs avoid a lot of this without so many awkward subtleties.

&gt; I prefer to use virtual machines...They also behave more like a real Linux system running on bare metal hardware than containers do.<p>People don&#x27;t seem to be noting this here yet but if this is why you &quot;prefer&quot; a VM to a container, you dont really understand what containers are used for

You know, I don’t like it either. I don’t like the network config, or the way the commands work. But I do love the overlayfs, and the somewhat ease of documenting the installation.<p>I love orbstack however. Every container gets his own ip and host, no need to map ports.<p>It feels like the docker people didn’t really understand the complete network stack.<p>I kind of abused docker&#x2F;orb stack to create easy adhoc chrooted containers. They let me just try out stuff, and they get shutdown when I’m not on there anymore. Check <a href="https:&#x2F;&#x2F;github.com&#x2F;jrz&#x2F;container-shell">https:&#x2F;&#x2F;github.com&#x2F;jrz&#x2F;container-shell</a>

Containers shine when you are deep into enterprise territory and testing one application means booting five more and like four Postgres and three Oracle DB and a JMS node with plumbing and so on. You don&#x27;t want to figure that out with VM:s, and you&#x27;re likely to deploy to application servers or something Kube-like anyway.<p>So I fully agree with TFA. It&#x27;s a nuisance, but certain niche situations that are unavailable to most webstuff devs are exceptions.

&gt; I prefer to use virtual machines. They’re slower to set up, and start up a little slower too, but they’re convenient for me, and I understand them well. They also behave more like a real Linux system running on bare metal hardware than containers do. There are fewer limitations that get in my way.<p>&gt; This blog post is not a request for you try to explain Docker, Podman, or containers to me, or for you to tell me how I can learn more about them. I am not interested.<p>Then I will simply tell you don&#x27;t understand virtual machines well either, like you said you did. I was going to explain Podman to you, but I won&#x27;t. I might not understand virtual machines well either FWIW, but I haven&#x27;t claimed that I do.<p>For anyone else reading this, Podman has a nice, clean design, that unlike Docker is free from a required daemon or something like Docker Hub. However it can be tricky to use, because it gives you a choice between rootless and rootful as well as non-remote or remote. However, once you get going, it is quite likable, and it&#x27;s quite impressive how powerful rootless containers are. I recommend trying them on Fedora or Rocky Linux with SELinux, and reading some articles. Here are a few:<p>- Podman rootless tutorial <a href="https:&#x2F;&#x2F;github.com&#x2F;containers&#x2F;podman&#x2F;blob&#x2F;main&#x2F;docs&#x2F;tutorials&#x2F;rootless_tutorial.md">https:&#x2F;&#x2F;github.com&#x2F;containers&#x2F;podman&#x2F;blob&#x2F;main&#x2F;docs&#x2F;tutorial...</a><p>- With a socket activated container, you can have a container listen on a socket while having a --network of none <a href="https:&#x2F;&#x2F;www.redhat.com&#x2F;en&#x2F;blog&#x2F;socket-activation-podman" rel="nofollow">https:&#x2F;&#x2F;www.redhat.com&#x2F;en&#x2F;blog&#x2F;socket-activation-podman</a><p>- Using Buildah to build images in a rootless OpenShift container <a href="https:&#x2F;&#x2F;github.com&#x2F;containers&#x2F;buildah&#x2F;blob&#x2F;main&#x2F;docs&#x2F;tutorials&#x2F;05-openshift-rootless-build.md">https:&#x2F;&#x2F;github.com&#x2F;containers&#x2F;buildah&#x2F;blob&#x2F;main&#x2F;docs&#x2F;tutoria...</a>

Sysadmin, the old way.

If encapsulating an entire operating system into a single file is more comfortable (ISO, VDI, VMDK, VHD, HDD) then a potential compromise might be SIF: <a href="https:&#x2F;&#x2F;github.com&#x2F;apptainer&#x2F;sif">https:&#x2F;&#x2F;github.com&#x2F;apptainer&#x2F;sif</a><p>You get the performance of containers without the complexity of micro services.

I always wonder what kind of setups people have where docker destroys their network config. I have used Docker on so many systems over so many years and several distros and not once have I encountered that. Same with people who say that systemd made their system implode and wayland makes their baby cry. What are these people doing?

Big part of the reason of Docker&#x27;s existence is that it&#x27;s more lightweight than running a VM. That&#x27;s like on the first page of a Docker tutorial.<p>It&#x27;s ok to struggle to learn Docker, I&#x27;ll admit took me a while to understand the benefits.<p>Also no need for the font to be bold, we can read normal font.

I had to use Docker at a job or two, I think around 2018. I hated it.<p>One class of issue: It made interacting with the file system slower, sometimes by orders of magnitude. Stuff like watching files, or statting a large number files, didn’t have the same performance characteristics. So you have a situation where you (probably) already have too many components that are too complicated or poorly understood to install them all on a developer’s machine, but they work on this exact machine snapshot, but now you have to figure out what process dared to stat a few thousand files.<p>Docker was also just always… there. In the menu bar. Doing stuff. Running system-wide. Updating itself, constantly. Like it’s Steam or Battle.net (which for some reason downloads updates to Warcraft III, an old game, multiple times a day on my kids’ PC, and sometimes breaks and you can’t play the game; this is the level of enshittification we are at).<p>The command-line experience… similar to git (that is, poor). There’s an underlying conceptual model that’s sort of half abstracted away by the tools and hard to find a good explanation of.<p>Developer tools like this have a tax: You spend at least half a day a week Googling for issues with them, forever. Same with NPM. All it takes is five such tools in your stack and every weekday morning is gone. And that’s disregarding the fact that you were probably in the middle of actually trying to get something done.

I find that although docker is heavier that it integrates well with everything and is far more practical to use so I stick with it. Trying to switch gave me a lot of headaches and burned a lot of time.

podman very much reminds me of subversion<p>subversion intended to be a better version of CVS<p>which it certainly delivered, but no-one really stopped to think if that was such a good thing in the first place

It’s like r&#x2F;linux all over again. For some reason people really think others want to hear their failed journey. It’s weird.

Don&#x27;t use any containers or even VMs then.<p>Just dedicate one physical machine for one application. Problem solved ;)

Don&#x27;t like Docker either. Why? As an absolutely unnecessary entity, it doesn&#x27;t correspond with Occam&#x27;s Razor. It&#x27;s overengineered. It&#x27;s clumsy and slow. It utilizes a lot of resources and leaves a lot of garbage in the filesystem. It&#x27;s not secure. It&#x27;s overhyped. docker-compose is an abomination. The same goes for Kubernetes.

OP&#x27;s next post title: 10 techniques I used to make it to HN front page

Who cares? Not every software must be likeable for everyone.

Cool story but at least try to give some argumentation when you say stuff like:<p>&gt;The design of the language in Dockerfile is ad hoc in a bad way. It’s difficult to understand, for me, and easy to make mistakes.<p>Because that reads like a skill issue to me

Honestly, the title should be &quot;I don&#x27;t like Docker because I don&#x27;t know how to do certain things, so I prefer to do things the way I know better&quot;.