Why I like Docker as a Developer

I recently made an attempt at something which I hadn't tried in a while and which I had failed at many times prior; taking someone else's app or source which didn't have an official Docker image and turning it into one.

Most of my past failures were likely due to my lack of understanding on the topic. But, going through this experience reminded me of one reason that I like Docker. And it fits rather perfectly with why I also think CI/CD pipelines are so valuable to developers and teams of any size; they serve to validate and document your processes.

Not everything makes sense as a Docker app. So, it may not suit your particular use case.

In this case, the project was TrinityCore, a private WoW Server. I got an older image up and running to test something out. But it was QUITE old and I was intrigued to see if I could build one from scratch, on my own. Also, I wanted to see if I could split the services out. The images I could find all ran 2 services + the DB on the same image. I rather hate when people do this. I've actually selected projects to use in the past based on whether or not they follow this practice. I don't need 20 different contains all spinning up their own MySQL or Postgres DBMS. And I don't need logically disparate services all running at the same time.

But, the details aren't too important here. Just that I was interested to see if I could. And I was indeed able. The reason was; the team behind the project had a well defined process. And the fact that I could so easily build a Docker image to implement their installation process proves that out. My only gripe is something Docker specific. They don't detail which ports are used by which services. Since their guide is on how to setup a local dev environment and I'm instead running this on 3 containers ... this is a rather self-inflicted harm.

So, yes, their process is well documented. However, documentation is often the first thing to fall behind. And this is why I prefer things like CI/CD and Docker.

It can make these processes part of the build pipeline. And then the "documentation" becomes a part of the code. If the processes needed to change at a point in time due to new dependencies, etc... then that is part of that branch. And if I can see that the pipelines passed in that branch and they included a step to build the docker image (or perform some installation steps as a part of a CI/CD pipeline) then I should be able to easily setup an environment for any branch, at any point in time.

Because the problem is fundamentally the same as my CI/CD argument, it holds up for a lot of the same reasons as well. I switch languages, computers, frameworks, etc... on a fairly regular basis. A good docker image, like a good CI/CD pipeline, accurately describes what you need to do to perform a build or get the software up and running and has that info in one place.

And, a lot of times you don't even WANT to get a new environment setup. A lot of times all you need is a deployment Docker image.

For instance, while I may change environments often, I use a lot of the same tools. Getting the development environment up and running is often the easiest part. Or, I just need to make a 1 line change in a 5 year old project and don't even need a debugger. But, I still need to be able to deploy it again. If I have a Docker image, I can bypass the burden of setting up a complete environment. And I'll still be able to validate that it builds and runs from that 5 year old Docker file.

I think a big problem a lot of developers and companies have is that a lot of them have not been using Docker long enough yet to experience the benefits first hand.

But as more and more companies do, I think it will become increasingly common to integrate docker into pipelines. And not just for companies deploying to a cloud service.