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:
- People who do not know how to use Unix-based operating systems or specifically GNU/Linux.
- 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:
- I wanted to change the Monero wallet I had set up with the program.
- I had set up the system with Ethereum support as well just to have it, but decided later I didn’t want it.
- 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:
- 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.