Why you need to start using Docker, today

If you’ve not been living under a rock, chances are that you’ve heard about Docker.

Docker is a containerization platform that allows developers to package, ship, and run applications in containers that are lightweight, portable, and scalable, enabling efficient and consistent deployment of software across various environments.

Well, those sure are a lot of words.

To put it more simply, Docker lets you pack your application into a special box which can be moved around easily and be used on different computers without having to bother with pesky versioning and configuration.

Why Should You Care About Docker

If you’ve some experience with developing web applications, you probably know all too well that dependency management can be a nightmare.

When I first started working, I thought grappling with the nastiness of dependencies was part and parcel of being a web developer - something you just had to accept as part of the job. I spent countless hours doing things like-

• Managing multiple nodejs versions via nvm
• Maintaining lists of npm registries each to be used for a specific repo
• Running npm install -f to beat different library packages into submission
• Creating documentation around this sort of thing to let newcomer devs hit the ground running etc.

What really pushed me over the edge with this whole concept was a double blow coming from the most recent application we were working on. It made both setting local development configurations and deploying code so difficult that a significant chunk of time went into these activities instead of actually building stuff.

The first thing was about npm registries.

The npm registries used at the time of npm install were different for people on different networks and locations. This meant that every time a new library was added for a new functionality, some users needed to change the registry names in the ‘package-lock.json’ file for npm install to be successful, since configuring their registry via npm config set registry <...> did not work.

The second issue had to do with deployment.

There was a CI/CD pipeline setup for deploying both the frontend and the backend applications to the dev, qa, and prod servers managed by another team. We had limited visibility and access to these servers. It so happened that we upgraded our Angular application from version 13 to 15, then from 15 to 17. Both times when the npm install command was run in the server it messed with the server’s configuration somehow causing other running applications to error out. We needed the server maintainers’ involvement which ultimately rendered the CI/CD pipeline moot.

With these issues causing blockers frequently our client made a decision to containerize both applications and put them behind a reverse proxy created especially for this purpose. It was by no means a trivial task. We had to learn a lot of stuff really quickly on the go, and the expectation that ‘done’ is better than ‘perfect’ was a big help and motivator.

After several sprints of gruelling, repeated failures peppered with sporadic but catapulting moments of success we finally deployed the new setup to our dev environment. It was a truly cathartic experience since it gave us a degree of autonomy which I hitherto had not experienced.

Great, how do I start?

You can start using Docker today by following this three-step plan -?

1. Watch a tutorial on YouTube to get a fundamental understanding of what it is and how it is used. There are tons of videos available online teaching how to use Docker from scratch. If you’re like me and get decision fatigue, you can get started with this one - Docker Crash Course for Absolute Beginners [NEW] (youtube.com). If you have a windows PC, install Docker desktop to get access to docker in the terminal; but consider switching to Linux or at least running WSL on your windows machine.
2. Once you’ve gone through with a beginner’s intro course video and had some hands-on practice on your personal computer, get in touch with your deployment team. You will now try to implement what you have learned into the dev environment - serving your application through a container instead by installing Docker in your dev server (will likely need admin privileges). Regardless of how you end up implementing the final pipeline, having once done a git pull of your code, building the Docker image, and then finally running a container from it provides a tremendous boost in morale.
3. Lastly, learn about and start using docker compose for local development with docker. If you’re working on a Linux or Mac OS, this likely will not be a problem. If you’re using windows OS at work, you might need to ask for access to the WSL terminal from IT. In the worst case where you are not able to get this permission, you can still continue to develop your app locally and deploy it using docker - building the image via something like GitHub actions, GitLab CI/CD, or something self-hosted like Jenkins.

And that’s it. With these three steps you can get started reliably on taking advantage of this powerful technology. Happy shipping!

Conclusion

This article just scratches the surface of the vast functionality provided by the Docker engine. Eventually, you will learn to configure environment variables, secrets, mount volumes for persisting logs and much more as you continue through on this path.

If you find working with Docker rewarding, you may also want to focus more towards core DevOps as a career, learning about Kubernetes for load balancing and high availability.

Like always, I hope you found something valuable here and wish you the best on your journey going forward.