Basically Everyone Should Be Avoiding Docker
I am a well known Docker-non-respecter.
I want to explain why I don’t use Docker (so much as possible)
The Real vs. Fake Reasons
I admire the candidness of the developer of BTCPay
here. He says that he chose to use
Docker to deploy his project because he was a Windows person doing .NET and
didn’t want to read up on how to use Linux/Unix.
There are basically only two “real” reasons to use Docker or containerization
more generally:
1. People who do not know how to use Unix-based operating systems or
specifically GNU/Linux.
2. People who are deploying a program for a corporation at a massive enterprise
scale, don’t care about customizability and need some kind of guarantor of
homogeneity.
Granted, class 1 should be a temporary state in an ideal world, but we don’t
live in an ideal world at all.
I would estimate that of those two categories, substantially more than 95% of
people are in the first. If you look at sites and users that endorse Docker or
list reasons for using it, they are nearly always for this.
So for my purposes, when I’m instructing people on how to set up email servers,
personal websites, little services, federated social media, etc., the only
reason to use Docker is if you want to make things harder for yourself by having
this extra and totally unnecessary layer of abstraction.
People watching my videos already know how to do at least basic Unix things.
Doing things the Docker way is a departure from that, while without doing, you
can do things the more familiar way.
I don’t give recommendations for people who are professionals deploying
enterprise-level homogenous software and I’ve never pretended to do that. Please
do not email me telling me you need Docker for some large-scale implementation.
I know you do. That’s not what I do personally, and it’s not what people
following me do, so I don’t do it.
How does containerization make your life miserable?
On BTCPay, there was a period when I was running a BTCPay server and
begrudgingly used Docker as recommended. This did make setting up all the
working parts to BTCPay extremely easy as it can be mostly automated.
But then I ran into some complications:
1. I wanted to change the Monero wallet I had set up with the program.
2. I had set up the system with Ethereum support as well just to have it, but
decided later I didn’t want it.
3. After three months, certbot certificates failed to renew and redeploy.
If I had not been using Docker, all three of these typical issues could’ve
been solved in several seconds. Even if I were someone who didn’t immediately
know how to renew a Certbot certificate, it would be easy to look that up.
But since I was using Docker, which is like running a computer video-game inside
your computer, they became extremely difficult. To solve the Monero issue,
since there was no GUI option to delete the old wallet, I figured out all I
needed to do is delete the wallet file on the Docker container. That sounds
easy, right?
Well, if you’re expecting Docker to have a file-system easily accessible, you’re
wrong—in fact, that’s “the point.” I can’t use typical commands like
updatedb/locate/find to find what I need. I have to run a command
with a massive prefix specific to that container. I don’t have tab completion
when running Docker container commands, so when I inevitably mistype while
searching for the file or attempting to delete it, I have to re-edit a
multi-line command. After a while, I did, however, delete the file, which
allowed me to change the wallet I was using.
You might say that doing such a little operation becomes easier after being more
familiar with containerization—I’m sure that’s true, absolutely. But ultimately
all I needed to do is delete a single file!—That shouldn’t be something you
need to train to do!
I will admit that the other two problems proved insoluble. The only way to turn
off Ethereum support from what I could tell is reinstall the whole thing. Don’t
expect to have a config file for a Docker container. Actually, if you did, you
should expect it to be impossibly difficult to edit.
While other people on the internet had had issues similar to the Certbot
problem, mine was clearly different and no solutions worked.
All I needed was to run the equivalent certbot renew --nginx; systemctl reload
nginx, but that proved too difficult when acting through the impenetrable
wall of Docker.
In my old video on why I don’t use
Macs, I described them as
“smart-people proof.” Docker is the same way. It’s Common Core for technology:
it reduces the good of knowing how to use your operating system to zero. This
might actually increase the convenience to tech-ignorant users accidentally,
because developers now have to answer “dumb” questions about Docker, including
saying “No, sorry, you can’t change that.” for most things you can indeed change
if you weren’t using Docker.
Containerization makes software an opaque box where you are ultimately at the
mercy of what graphical settings menus have been programed into the software. It
is the nature of containers that bugs can never been fixed by users, only the
official development team.
Fake Reasons
Containers are more secure.
The reality:
Scripts that compromise containerized software/data are no more difficult to
write than those that compromise non-containerized software/data. They are
merely different.
Containerization places more reliance on developers to keep software,
including libraries used up to date.
People mistake “It’s unintuitive for me to interact or interface with this
containerized program.” with it being secure.
People might know flatkill.org, which sums this up
briefly, but it’s very true.
Containers are easier to set up.
The reality:
It’s no easier to setup a Docker file than a installation shell script, even
one that runs on multiple platforms.
When containerization seems easier, you are getting freetime up-front by
paying with hours of headache later on managing the software.
Especially when we’re talking about “Installing on Linux” this is silly. If a
program can be easily installed on Debian and (nowadays) installed on Arch
Linux, that covers basically all Linux users.
Containers are easier to manage.
Containers can only be “easier to manage” when they strip away all of the user’s
ability to manage in the normal unix-way, and that is relatively unmissed.
A Third Reason
Let me add a sympathetic third reason:
3. You want to export security to a party that might know better than you.
Again, let’s use BTCPay as an example, since it’s a payment processor. Granted,
normally a BTCPay server only has access to your public keys, but none the less,
there are substantial liabilities with anything related to money.
So if you set something like BTCPay up without Docker, assembling the
required interacting programs yourself, there’s a chance you might do something
wrong or create a security flaw inadvertently.
Using Docker is a panacea, but it lets you rely on the security acumen of
whoever is putting together the Docker image, who in many cases might know more
than you. (In some cases, maybe many, he might know less though, or be less
willing to update security protocols, and you’ll put yourself in a precarious
position!)
Conclusion
Ergo, I don’t use Docker and containerization, I’m annoyed by them and I don’t
do tutorials on them. They are not for me or for people who want to do basic
personal sysadmining. I think enterprise sysadmins would definitely do better
doing more for their personal life outside of things like Docker, but again,
there are reasons people use these things for many professional use-cases.