Docker in development: Episode 1
In this series, we will explore the motivation and benefits of using docker in development. We are going to give everyday tips that helped us move forward using it, focused on Ruby on Rails and React development.
This series will not explain Docker’s core concepts. If you don’t know them already, I strongly suggest you read Docker’s official documentation and then come back.
Motivation
This is a personal (and team!) experience. You might find yourself in similar situations, and this might help you move forward and take the first steps.
Until a couple of months ago, my standard setup for developing Ruby on Rails, minimalistic Ruby apps, and React apps was plain simple.
For Ruby/Ruby on Rails, I just installed chruby, ruby-install (and the Ruby versions I needed, say 2.3, 2.5, and even 2.6!), cloned the projects, installed the gems using bundler, Postgres (because we mostly use Postgres), and I was ready to go. Of course, if I needed Redis or other databases I had to install it.
Similarly, for React projects, I just installed node and installed the dependencies. This process of installing the interpreters, the dependencies, and such, with the help of homebrew (or apt-get if you use Linux) is easy but takes some time.
A month ago, I had a task to complete: fix a small bug in a Rails 3 app, on top of Ruby 1.9.3! That was a little bit harder than with new versions of Ruby. Not for the interpreter itself, but the dependencies of the project. As time goes by, older dependencies might be harder to install because of their dependencies. You might have newer versions of your dependencies dependencies in your computer, and installing older stuff might cost time.
After thinking about it for a bit, I decided to dockerize the app. To be honest, I don’t know if it took longer than fighting with the interpreter/dependencies versions, but the result paid off. Not only the bug was fixed easily, but since then I’ve decided to dockerize every app I work on (even some apps you might use daily as we’ll see later), and as of now I use docker for local development exclusively. Native setup is no longer needed.
Benefits
Some of the benefits are obvious (especially if you’re into docker already), but we’ll go through them anyway so we expose a stronger case.
Your whole project explains how’s set up from a system point of view: what database, services, etc.
New developers can easily join the project and by running just a command they’ll be ready to go.
Your app won’t change as your local env changes. Normally, for, let’s say, bundler, that won’t be a problem, but you might end up using other binaries or libraries within your system that might change over time.
Questions
These are questions I asked myself (and you might have them as well):
Won’t I have a lot of disk space occupied by docker images?
Yes, you’ll have. But if you want, you can just remove them and recreate them when you need them. It’s not a big deal. If you don’t want to build each time, you can push your images to a repository (docker hub is an example).
What about the performance? Does it consume a lot of resources?
Short answer: no. They’re regular processes, and they consume the same resources they’d consume if you installed all the requirements natively. You can look for yourself by running docker stats!
Do you have other questions? Get in touch!
Conclusion
The balance, for me, has been positive. Since I’ve been using docker, things have been the same in terms of development time, getting up and running, etc. Plus, the benefits we already mentioned.
Join us in the next episode!