I've been running docker in production for about 3 years. Almost every time I've hit a problem, it has had nothing to do with docker (though everyone likes to

I've been running docker in production for about 3 years. Almost every time I've hit a problem, it has had nothing to do with docker (though everyone likes to blame it). 99% of the time the issues I've encountered are due to docker configuration (and yes the learning curve is steep) or the app itself crashing. The one time I've encountered an issue with docker with databases (used elasticsearch) was a kernal issue (where the host kernal was out of date). That was the only time I had to care about the host OS in debugging a docker issue. One thing that I recommend for anyone getting into docker - use docker-compose for everything. Don't use the docker CLI. One of the major problems I have with docker is that (especially for beginniners) the docker command line tool can cause unintended consequences. Every time you run docker run <image> you are technically creating a new container from an image. Once that finishes, the container still exists on disk. Using the --rm flag will cause the container to actually be removed after running it. I sort of wish docker would emphasize that flag, because often when developers are debugging or trying things, they will continue to run docker run <image> multiple times - not realizing that they are creating a ton of containers. Yes, the containers are usually very light, but it caused a lot of confusion for me when I started out. And part of my superstitious self believes that the less dead containers you have the less likely you'll have filesystem issues. A second source of confusion for new devs I've noticed is that the concept of volumes are somewhat confusing. "Why would I ever do COPY in my docker file if I can just volume it?" Once you've worked with Docker, like any tool, you become more adept at avoiding a lot of the mistakes mentioned in this article. Which leads me to a point I can't disagree with the OP about - upgrading docker is annoying as hell. Almost everytime I upgrade docker I end up having some obscure error. When I look on docker github I notice I'm not the only one, and often times the issues are just a few hours old. But, what the OP didn't seem to realize, is that to avoid these issues you need to lock your docker version in production to one that you know works. Additionally, you need to not build your dockerfile in production. Build your docker containers with a build system and upload them as artifacts. You can either use an internal docker hub or do docker save to save them as a .tar. Building while in production is a real no-no, even though it may seem more attractive than moving around 300-500MB images. You never know if that one dependency you apt-get in your dockerfile is offline for some reason. And you can't always depend on devs of dockerfiles properly versioning them anyway.