5 Steps to Take before Moving Your Applications into Docker
You've done your research and decided that you're going to embrace Docker, but how do you begin the migration process?
So here you are. You’ve just spent the last 3 days binge watching Docker videos and reading all sorts of success stories. You have no idea how to use Docker yet, but you know you want to use it.
This article is going to concentrate on what I like to call the “pre-Docker Dockerization steps”. These are things you should do before learning how to use Docker and it will make it much easier for you to Dockerize your apps later on.
All of the steps below can be applied to any application written with any technology stack.
When you finish this article, you’ll have an actionable list of things to research and do, so I recommend writing those things down. Now’s a good time to grab a piece of paper and a pen, or use whatever you want to jot down a few notes. 1 sheet of paper will suffice.
# 1. What Languages Make up Your Application?
For example, if your app is a Ruby on Rails application, then as you probably
know, you’re using the Ruby language. So go ahead and make a list of
all of the languages that your app uses.
Also, be aware of language dependencies too. For example, if you happened to have a Rails app, you likely also depend on NodeJS to compile your assets.
# 2. What 3rd Party Services Does Your App Need?
What I mean by services here are things that your application requires to run properly, and does not belong to your code base. For example, what database are you using? What about cache back-ends, or web servers?
What I don’t mean are 3rd party hosted solutions that you might use, such as Stripe’s API.
These are things you need to set up in your current development environment. Whether or not they are being managed by Vagrant or something else isn’t important.
Nobody knows your application better than you, so start cranking out this list. Write down every single service that your app depends on.
For example, in a typical Ruby on Rails application that would be at least
PostgreSQL and Redis. In a LAMP stack it might be Apache and MySQL.
# 3. What Else Does Your Application Start Up?
We covered 3rd party services in step 2, but now let’s list out additional services that your application depends on. For example, this could be your app server, background workers, or anything else that makes sense.
In a fairly standard “real world” Ruby on Rails application, that might include
things like Puma (web server), Sidekiq (background worker), and maybe even
ActionCable (websocket server).
Technically you could label these as 3rd party services since you didn’t write them, but at a conceptual level I think of them as being in a different class than PostgreSQL and Redis.
The thing that makes them different to me is that PostgreSQL and Redis can be used in all major programming languages where as Puma, Sidekiq and ActionCable are tied into Ruby.
Go ahead and list all of yours out.
# 4. What OS-level Dependencies Does Your App Have?
This step might be a little harder than the others to complete because I tend to find that most developers who aren’t using Docker often get mixed up here because they have depended on having a whole bunch of libraries installed on their development machine for years and have simply forgotten about them (I know this because I had the same issues).
This usually becomes apparent when you try to deploy your app because suddenly you get dependency errors. Perhaps that’s even the reason why you’ve decided to look into Docker.
In any case, the OS-level dependencies I’m talking about here are packages that
let your application talk to PostgreSQL or MySQL. These could be libraries like
libpq-dev or libmysqlclient-dev if you’re familiar with Ubuntu.
Maybe your app happens to transform images, so you need imagemagick too.
Perhaps you need to install nodejs to pre-compile assets, etc..
Take a few minutes and trace through your application’s dependency resolution
file (Gemfile, requirements.txt, package.json, etc.) and look through
everything. Maybe seeing a package name will cause you to think back to what
you had to install on your system to get it to work.
Take as much time as you need here, and remember, by doing this you’re saving a lot of time in the future because most applications written with the same web framework share similar OS-level dependencies so you can re-use this step.
# 5. Do a Preliminary Hunt on the Docker Hub
The Docker Hub is the official place to go to find pre-made Docker images. For now you can think of these images as self contained packages that will let you install and run a service very easily.
That’s not a classic definition of what a Docker image is, but right now you probably have no knowledge of Docker, so I’m keeping this at a very high level.
Anyways, do a search on https://hub.docker.com/ for your languages of choice. Then do a search for all of your third party services. Make a list of their URLs for later.
The goal here isn’t to learn how to use them, but just check to see if they exist. When making your list, always try to find “official” versions of the image. For example, here’s the official nginx image. Notice how it says “official repository” above it.
# Taking the Next Step
Now that you have a few notes that clearly defines your application’s architecture and dependencies, you can sink your teeth into learning Docker.
You have 2 options when it comes to learning Docker.
There’s the slow and painful road where you spend the next 3 months researching hundreds of blog posts, watching dozens of hours of videos on Youtube, and slamming your head against the wall as you run into issue after issue, or…
You can let me hand feed you Docker so that you can become an expert in a few hours.