My Experience with Docker
For a while, I have been hearing about Docker and why everyone should be using Docker for development, most of the reasons were pointing towards team projects, therefore, I felt it wasn’t necessary for individual projects that I worked on myself and for the teams that I had worked with, there was always a DevOps engineer and I always thought it was their role to decide whether or not to use Docker. Therefore, I just added Docker to my Todo list until I had to accept the inevitable.
What is Docker and its benefits?
Docker is a tool for running applications in an isolated environment.
If it works on your computer, then it works on someone else’s computer and also on the server. It will always behave in the same way. Therefore, when properly set up, it solves the problem of, “It works on my computer but not theirs.”
Makes it easier to get an existing project setup on your machine. You don’t need to install any of the dependencies of the project in your local machine like Postgres, Redis or even the language being used like Ruby, etc. They are all bundled within the Image. All you have to do is fire up the container. A container is simply a running instance of an image. Therefore, you can have multiple instances of the same image running on your machine. An Image is simply all the libraries, code and operating system bundled together. An image is created by building a Dockerfile.
Dockerfile
You do not have to build your Image from scratch, you can build it on top of an already existing image, so for example, if you are dockerizing a ruby app, then you could start by using the official ruby Image from the Docker Hub (repository containing public images).
You can have multiple containers interacting together in one application as services, for instance, one can be the database interacting with the actual application. You can use a docker-compose to manage all the services running/interacting with the application.
Experience
My actual experience with Docker wasn’t the best, to begin with,
I had read how much faster docker was compared to other ways of firing up the application, for instance, using a virtual machine. This raised my expectations but when it came to actually trying it out, you have to first build the application and this has to download all the dependencies like the base images (ruby, Postgres, etc) and that takes a while depending on your internet connection though (Mine took over an hour). This has to happen regardless of whether you have ruby or Postgres or any other of the dependencies installed on your machine. Thankfully, this is only a one-time build since the subsequent ones will use the existing image. After this has built, starting the app was considerably faster than the alternatives.
To me, I felt like Docker has a steep learning curve, it is tricky to understand it and custom your own Dockerfile, and therefore it took me a while a have it working the way I wanted. When it came to deploying my image to Heroku, I faced a problem with the assignment of ports, in my Dockerfile, I was explicitly specifying a port to run on (9292 since I was building the app in Sinatra and that is the default port it runs on), and Heroku also dynamically assigns a port at run time, so I was in a state where the app was running locally but not on Heroku, which was a direct conflict about some of the solutions Docker was promising to solve. (It works on my computer but not theirs’).
To be fair, this was my error, in not understanding how Heroku works.
Conclusion
As much as my experience with Docker wasn’t the best, in the end when I finally figured it out and could play around with some of its’ capabilities, I began to really appreciate it, for instance, when I shared my Github repo with a teammate, he didn’t need to install any of the dependencies and yet was running the app fine.
Docker is definitely a technology any developer should be willing to get on board with. As it offers a wide range of features that improve or make the development of projects easier especially in a team.