1. I got hurt by Docker.
2. I don't want to learn Docker.
3. I got hurt by Docker more.
4. I don'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't try to explain Docker to me.
Why would I want to transition to Docker or Podman?
Edit: "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."
There is an 8...
8. Docker doesn't provide complete separation
And a 9...
9. Just use PaaS
> If your VM is slower, why are you emulating?!
Which I think refers to this part of the article:
> They’re slower to set up, and start up a little slower too
If you don't like the submission then downvote and carry on.
That failed. Miserably.
Developers always assumed things like "well naturally, if you're playing in the XYZ space, you've already got meson installed. What, do you expect me to teach you basic arithmetic in this README too?" Developers across the board, across programming subcultures, showed themselves unable to get past this sort of thing.
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't omit any steps or the container won't work on their machine.
It sucks that this Hegelian situation calls for such a draconian solution, but that's where we're at. Developers as a whole can't be trusted to handle this on their own. If you don't have a better solution to this problem, I'm not sure there's much point in complaining.
Docker excels at bundling up all the dependencies of a piece of software for deployment.
Devcontainers definitely work these days, but I miss vagrant.
Yes, sometimes the vagrant-configure thing had a few lines, but most people shipped an iso with stuff installed. It could have been done, but wasn't being done.
It is for nearly all intents and purposes functionally equivalent to docker, and it’s pretty trivial to port to Dockerfile in minutes. I use docker plenty for work and am fully aware of its benefits. Like the OP, I just dislike Docker’s iptables fuckery and CLI design as a matter of personal preference.
Of course, context is king, and I only do this for things I’m designing and running myself - but the larger point I’m trying to make is that you can do the whole “unambiguous file that describes the exact shell steps required to get the piece of software running, starting from a base distro”-thing without Docker in the picture.
Dockerfiles were an excellent way of sysadmins getting developers to write down their build steps.
The fact that they're not deterministic was helped by the fact that we can just copy/paste tarballs around (all a docker image is, is just a pile of tarballs in a tarball after all).
It should be possible to improve the containerization experience by providing a better UI and maybe even a different syntax for docker files.
As a tangent… do you mean „developers of open source software available for free download”?
This is particularly common with CLI tools written in some languages. I was looking at Antora the other day (not intending to single this project out, it's just the one that came to mind). I found two ways to run it:
1. By installing Node: https://docs.antora.org/antora/latest/install-and-run-quicks...
2. By running it in a Docker container: https://docs.antora.org/antora/latest/antora-container/.
The amount of complexity here is shocking. This is a tool that could just as well be a single binary, with the only dynamic linkage being to libc and maybe OpenSSL.
This also means that if something goes wrong, black-box debugging tools like system call tracers are much harder to use. I rely on system call tracers all the time, and it really sucks when they stop working.
Hell, even if you're paying customer, if a product has only Docker as installation method and seller is not interested for providing .deb's and .rpm's, go find another solution.
LXD containers solved a lot of the problems inherit to virtual machines for me, though I don't like their reliance on global configs (something like Docker compose for LXD containers would be ideal).
> 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.
> 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.
This person is actually insane, but huge respect for doing things differently!
This showed me how great and easy and well designed Docker was as an abstraction layer though. I know purists don't like it, but it made reliable deployments standard and easier than the alternative of not using Docker.
I wonder if the author could elaborate here.
It's kinda badly described and unintuitive. The amount of people who were surprised by the firewall rules messing up their existing firewall setup is very high. And it also just grabs a subnet and you have to dig why it would use that one and not another. Not sure about conflicts. But it's a bit of "it works until it doesn't".
I didn't have many "wtf just happened?" moments with docker, but 100% of them were network-related and half of them were hard to troubleshoot.
While I agree that developers should support and have documentation for hosting without Docker, I think the arguments in the article are very poor.
It's completely fine to dislike a technology - hell if I don't! - but here it seems like they are arguing against Docker just for the sake of it.
`cmd containers` does nothing, `cmd images` does `cmd image ls`,
`cmd rm` does `cmd container rm`, `cmd ls` does nothing, its of course `cmd ps`,
`cmd rmi`, no `cmd lsi`,
no easy way to extract the resultant hash from a `cmd build`, can use a tag I suppose
Maybe I'm in the minority, but I've never used those commands... I'd rather write `docker container ls` than an obscure short-hand alias.
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've used systemd-nspawn before. I didn't find it notably simpler and did find lots of weird edge cases where things didn't work (most recently something between ~249 and ~253 giving 'permission denied' errors on mounting /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.
People don't seem to be noting this here yet but if this is why you "prefer" a VM to a container, you dont really understand what containers are used for
I love orbstack however. Every container gets his own ip and host, no need to map ports.
It feels like the docker people didn’t really understand the complete network stack.
I kind of abused docker/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 https://github.com/jrz/container-shell
So I fully agree with TFA. It's a nuisance, but certain niche situations that are unavailable to most webstuff devs are exceptions.
> 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.
Then I will simply tell you don't understand virtual machines well either, like you said you did. I was going to explain Podman to you, but I won't. I might not understand virtual machines well either FWIW, but I haven't claimed that I do.
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'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:
- Podman rootless tutorial https://github.com/containers/podman/blob/main/docs/tutorial...
- With a socket activated container, you can have a container listen on a socket while having a --network of none https://www.redhat.com/en/blog/socket-activation-podman
- Using Buildah to build images in a rootless OpenShift container https://github.com/containers/buildah/blob/main/docs/tutoria...
You get the performance of containers without the complexity of micro services.
Also port forwarding in Docker (and Podman!) still bypasses ufw/other firewalls, which is really annoying and surprising (though it doesn't in rootless).
It's ok to struggle to learn Docker, I'll admit took me a while to understand the benefits.
Also no need for the font to be bold, we can read normal font.
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.
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).
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.
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.
Just as a FYI, This is only an issue running on Windows or Mac. They setup a vm behind the scenes to run docker on and the vm doesn't have direct access to the filesystem. On linux, it's just namespaces and it's native performance.
lol wtf? This tells me everything I need to know. If that’s what “docker” is to you, sounds like a major skill issue.
subversion intended to be a better version of CVS
which it certainly delivered, but no-one really stopped to think if that was such a good thing in the first place
Just dedicate one physical machine for one application. Problem solved ;)
>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.
Because that reads like a skill issue to me
The question is not if it's a skill issue or not, but if the complexity of the solution matches the complexity of the problem domain. And also: if there are easier and clearer ways to reach the same goals.
Instead of providing a set of separate tools to be glued together with a proper shell or a full programming language, they designed this nonsense that can't even do 1/10th of what busybox is able to do, and have been in the business of adding the missing pieces (like `COPY --chmod`) for the past 10+ years.
It has taken them about a decade to add HEREDOC support, for example. Most dockerfiles still use
RUN foo && \
bar && \
baz
RUN <<END
set -eu
foo
bar
baz
END
Here's the official example of building a lighttpd container:
https://github.com/containers/buildah/blob/92015b7f4301d7eb8...
You can eschew bash and call these commands however you want — from a python script, or Go, or even assembly.
liw is Lars Wirzenius, so I assume we can rule that out.