Working with Docker is generally a good experience for me. I’ve got enough of the tools down, I know most of the command line parameters that I need, and I can look up what I don’t have memorized yet.
But that doesn’t mean Docker is completely painless.
For example, I was recently recording a WatchMeCode episode and I wanted to suggest a simple way to help reduce the need to remember so many command-line options. Well, it didn’t go quite the way I wanted.
If something as “simple” as which command-line options are needed can be a huge source of problems, imagine how many issues can come up when editing a Dockerfile, configuring an image and generally trying to make your Docker image builds work.
The list is endless, and I’ve run into just about every single problem you can image.
- missing “EXPOSE” instructions for TCP/IP ports
- forgetting to “RUN” a “mkdir” to create the folder for the app
- telling the Dockerfile to set the “USER” before you have the right folder permissions in place
- leaving out critical environment variables, such as “NODE_ENV=production”
- and more!
The problems are the bane of a developer’s life, in Docker. They are things we are not accustomed to dealing with. We write code, after all, not server configuration and deployment automation. But here we are, in this new world where we have become a critical part of the infrastructure and deployment process.
And while we truly are better off for this – we have a more consistent development and deployment experience, with far fewer (i.e. zero) “Works On My Machine” problems – we do have a few new frustrations to deal with.
Announcing the Debugging Docker Images webinar
Stop the endless cycles of debugging failed Docker image builds.
No more tweaking a Dockerfile – hoping to get it right – building, testing, watching it fail again, and then repeating the process… over, and over, and over, and over again.
Join me and the other 50+ developers that have registered, so far, for a live webinar on February 27th, 2017 at 20:00 UTC (2PM CST).
I’ll show you the tools and techniques that I use, to cut image build cycles down to a single “docker build” in most cases.
You’re guaranteed to see some techniques that will help you reduce the debugging cycles for your failed Docker image builds.