Rails On Docker Simplified

Docker

Before moving onto Rails & Docker setup let’s quickly understand what exact problem does docker really solve.

So we already have VMs which pretty much fulfils the purpose of setting up a separate machine with its own config. Hence docker didn’t solve the isolation problem, as that was solved by VMs. Docker solved the problem of turning existing applications into virtual uni-kernels.

When someone sends you a Java/Rails App,

1. Is the JVM or Ruby Gems installed?
2. What about runtime libraries?
3. What about additional libraries?

Docker solved the above and many other questions. It packs, ships, and runs applications as a lightweight, portable, and self-sufficient containerization tool.

In simple words it eliminates the “but it works on my machine” problem.

Until now, I always thought to setup my Rails applications on Docker but as usual didn’t had an exact idea on how and where to start. After going through multiple resources (i.e. the best one found is this article), I will explain a quick walk-through of setting up a Rails app on Docker below:

Note: I have used a sample rails project in the below explanations which can be found here.

First of all,

Download docker desktop using the below command on your Ubuntu:

sudo apt-get install docker-ce docker-ce-cli containerd.io

Second is to setup the Dockerfile in your Rails application. Your Dockerfile specifies what will be included in your application container when it is created. We will now start dockerizing an exisiting rails app from Scratch.

For that, we will need to create a file named as Dockerfile in root directory of the project. A sample Dockerfile looks like below:

Third will be to setup the Docker Compose file where we will be defining services. Using this we will be able to run multiple containers for our project.

Our sample application will need following services to run:

1. The rails app
2. Database — In our case it is PostgreSQL
3. Sidekiq
4. Redis

Create docker-compose.yml file in the root directory of your project, a sample version of the same will look like below:

Some important points to note in the above file are:

• dockerfile: This specifies the Dockerfile in your current project directory as the file Compose will use to build the application image. You can find all the images at DockerHub.
• ports: This maps port 3000 on the host to port 3000 on the container.
• depends_on: This sets up the database and redis containers first so that they are up and running before app.
• env_file: This tells Compose that we would like to add environment variables from a file called .env located in the build context.

Create this containers using below command:

docker-compose up

Run the database migrations using below command:

docker-compose exec app bundle exec rake db:setup

The docker-compose exec command allows you to run commands in your services; we are using it here to run rake db:setup

You can check the containers are running by using below command:

docker container ls

You can enter into rails console inside the docker container using below command:

docker-compose exec app bundle exec rails console

That’s it !!! Check your app is running on localhost:3000 as we had specified in docker-compose.yml file.

To stop or remove the container. use below command:

docker-compose down

There are various GUI tools where we can watch the running containers from which I prefer to use Kitematic which is open-source. We can directly start/stop containers from the tool itself. You can find the installation steps here.

A glimpse of the Kitematic running on my machine can be seen below:

Kitematic UI

Everything has their don’ts and so is for docker, refer this article which explains when not to use docker in detail.

Kubernetes In Action

Docker helps to “create” containers, and Kubernetes allows you to “manage” them at runtime. Use Docker for packaging and shipping the app. Use Kubernetes to deploy and scale your app.

Kubernetes keeps track of your container applications that are deployed into the cloud. It restarts orphaned containers, shuts down containers when they’re not being used, and automatically provisions resources like memory, storage, and CPU when necessary.

Docker can run standalone when deployed on production as containerized applications. Hence there is no mandatory requirement using kubernetes but is preferred in production. Refer this article to understand it’s advantages in detail and this article for more practical use-cases of the same.

There’s still a lot to cover but to limit the scope of this article we will have to end this article here.

Any suggestions or corrections in the article are welcomed.

Please show your support by sharing this article if you find this useful.