New Rails Apps with Docker Compose

Following on from the Docker & docker-compose guides, it is possible to use docker-compose to build a Rails application that uses a PostgreSQL database without even installing Ruby on your local machine by instead using containers!
This becomes a very useful option to have if you work from many different workstations and don't want to ensure they are all equipped with the correct Ruby and Rails dependencies, or if you wish to use a version of Ruby / Rails not supported by your operating system (for example, Ubuntu 20.04 only allows provides up to Ruby 2.7 in its apt cache).

In fact, Rails 7 added native support for Docker, such that it generates almost all of the default files we need for us!
This comes with its problems and, I won't lie, updating this post to work with Rails 7 (it was previously written for Rails 6) has been a colossal pain and features a bit of hackery. However it is ultimately a good thing, and having Rails do more of the work for us is definitely a net positive!

This section will therefore create a new Rails app, which we will lovingly call dockerific_rails_app, purely inside Docker containers, using the very latest options available to us at time of writing:

As always, we are using an Ubuntu 22.04 workstation as a base for this - your mileage may vary.

  1. Prerequsities
  2. Temporary Setup
  3. Building the Image
  4. Database Creation and Final Checks
  5. Closing Notes

 

 

As mentioned before, all we need to get started are the necessary Docker packages, the Git packages and a text editor so we can build our initial config files and then develop the application afterwards.
This will be different for each operating system and, as always, we will focus on the Ubuntu/Linux way of achieving this - Google will provide installation instructions for other OS's: 

$ sudo apt install docker.io docker-compose docker-buildx git-core vim

  • If you want a slightly nicer, GUI-driven text editor, many are available and I encourage you to shop around (RIP Atom). A fairly prolific standard in the industry is vscode, which is available for free in most OS app stores - for Ubuntu we can install it via its snap: 

    $ sudo apt install snapd
$ sudo snap install code --classic

We'll also need to perform the minor hax to allow Docker to run from our user (and not have to use with sudo every time): 
$ sudo groupadd docker
$ sudo usermod -aG docker $USER
$ newgrp docker  ## run this in each new terminal until you reboot
Remember that you'll need to run that last command in any new terminal window you open until you log out or reboot.

 

 

Now, as mentioned above, Rails 7 comes with a lot of default stuff for Docker that is worth using (especially when initialising Rails with database, CSS and JS options), which culminates in it overwriting the initial configuration we give it (much like gem config).
This means that we'll need to provide some sacrificial config for Docker to allow us to run our rails new generator in a container. Their sacrifice will almost certainly be worth it, though.

Before we worry about any of this, though, let's start with the basics - a home for our future rails app's codebase and some temporary gem config. Let's set up our workstation's local directory for our app: 

$ mkdir -p ~/projects/dockerific_rails_app  ## create the app dir
$ cd !$                                     ## change into the directory (!$ means last argument)
and use our text editor to put a basic Gemfile in it so we can install Rails in the container: 
Gemfile

source 'https://rubygems.org'
gem 'rails', '~> 7.1.3'
In order to use this file in a container, we'll need to tell Docker where to use it - we do this via a Dockerfile. We'll specify the latest available ruby image, create a temporary directory on the container to put the Gemfile in and install Rails via bundler: 
Dockerfile

## set latest ruby image
FROM ruby:3.3

## update package repos 
RUN apt-get update

## copy local Gemfile into container
ADD Gemfile /dockerific_rails_app/Gemfile

## set temp dir as default
WORKDIR /dockerific_rails_app

## install rails via bundler
RUN bundle install
Again, this file is only a temporary configuration and will be overwritten by Rails when it generates the basic application codebase.

With this done, we can move onto our final sacirifical config file; docker-compose.yml. All we need to do here is set our local app directory as the build context and link it with the temporary directory we've set up on the container in our Dockerfile: 

docker-compose.yml

version: "3.1"                   ## set version with best Docker compatibility
services:
  app:                           ## container reference
    build:
      context: .                 ## use current dir (local app dir)
      dockerfile: Dockerfile     ## use our sacrifical Dockerfile
    volumes:
      - .:/dockerific_rails_app  ## link local app dir with container temp dir

 

 

Now for the clever bit - with our (temporary) prerequisite config files in place, we can run rails new with any options we need inside the container we've configured by passing it through docker-compose run: 

$ docker-compose run app rails new . -f -d postgresql
Here we are running an instance of the app service as defined in our docker-compose config and initialising a new Rails app within it in the directory that is linked to our local app folder - this means that all the lovely files created by the generator are accessible to us locally!
We can check this by just running ls in our local app directory: 
$ ls

Note that we are passing a couple of important options to the rails new generator:

  • -f forces any file overwrites, allowing Rails to overwrite the Gemfile & Dockerfile.
  • -d allows us to specify the database type, providing a lot of automatic configuration for PostgreSQL and meaning we can start as we mean to go on by using something that isn't sqlite!
We can also potentially configure the default CSS and / or JavaScript usage by passing options with -c and -j respectively - I haven't done so here as it's beyond the scope of what we're trying to achieve in this post.

Before we make any edits to our codebase to get it ready for its first real image, we'll want to quickly clean up the temporary containers that Docker generated to run our rails new generator - we can do this by simply running: 

$ docker-compose down
We should see it removing the temporary container and network it set up for us: 
Removing dockerific_rails_app_app_app_run_977d3aef4866 ... done
Removing network to_do_list_default
We can check if the container has been removed by listing all the Docker containers: 
$ docker ps -a
If, for whatever reason, docker-compose down did not remove the container, we can manually remove it by passing either the container ID or name to docker rm. i.e. 
$ docker ps -a
CONTAINER ID   IMAGE                      COMMAND                  CREATED              STATUS                          PORTS   NAMES
3ff0eb62c202   dockerific_rails_app_app   "rails new . -f -d p…"   About a minute ago   Exited (0) About a minute ago           dockerific_rails_app_app_run_977d3aef4866
$ docker rm 3ff0eb62c202
3ff0eb62c202
The final bit of cleanup will be to remove the image that Docker generated, as we will shortly have no use for it. We can see the list of images that Docker is holding onto with: 
$ docker images
REPOSITORY                 TAG       IMAGE ID       CREATED          SIZE
dockerific_rails_app_app   latest    cb7f89e7a007   37 minutes ago   1.07GB
ruby                       3.3       dddf6b6befbf   2 weeks ago      989MB
postgres                   16.2      b9390dd1ea18   3 weeks ago      431MB
and save ourselves a good gigabyte of storage by deleting the offending image, again passing either the repository or image ID to docker image rm: 
$ docker image rm dockerific_rails_app_app
With the cleanup done, and the basic codebase available to us, we need to make a couple of edits before we set about building our first proper container image.

First on our list is the docker-compose.yml, which we'll need to overhaul in order to use the new Dockerfile generated by Rails for our app container, as well as set up the container using the latest postgres image for the database and some persistent storage for it: 

docker-compose.yml

version: "3.1"
services:
  db:                                                                                  ## database container ref
    image: postgres:16.2                                                               ## use latest PostgreSQL container image
    volumes:
      - postgres:/var/lib/postgresql/data                                              ## set persistent database storage
    environment:                                                                       ## pass login details into container env
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
  app:                                                                                 ## application container ref
    build:
      context: .                                                                       ## use local app dir
      dockerfile: Dockerfile                                                           ## use local Dockerfile generated by rails
    command: bash -c "rm -f /tmp/pids/server.pid && bundle exec rails s -b '0.0.0.0'"  ## start rails server
    volumes:
      - .:/rails                                                                       ## default rails container app dir
    environment:
      RAILS_ENV: development                                                           ## set development env
    ports:
      - "8008:3000"                                                                    ## allow us to access app on port 8008
    depends_on:
    - db                                                                               ## link to db container
volumes:
  postgres:                                                                            ## setup persistent db storage volume
The only other edit we need to make is to the database configuration (config/database.yml), where we'll need to provide the host and authentication details we've set up above in order for the application to be able to interact with the database container: 
config/database.yml

default: &default
  adapter: postgresql
  encoding: unicode
  host: db
  username: postgres
  password: password
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: dockerific_rails_app_development

test:
  <<: *default
  database: dockerific_rails_app_test

production:
  <<: *default
  database: dockerific_rails_app_production
  username: dockerific_rails_app
  password: <%= ENV['DOCKERIFIC_RAILS_APP_DATABASE_PASSWORD'] %>

With our edits made, we can now finally trigger the first legitimate container image build of our app via docker-compose: 

$ docker-compose build
Once finished, we can check and see the benefit of using Rails' own Dockerfile (a solid half gigabyte storage saving): 
$ docker images
REPOSITORY                 TAG       IMAGE ID       CREATED          SIZE
dockerific_rails_app_app   latest    420e6a50d744   17 seconds ago   502MB
and know that, when we run our container from this image, we'll have the best possible version of our application to develop on.

 

 

The last thing we'll need to do before testing our barebones Rails app is create the database inside the container we created for the purpose. Because we've already configured the containers to be able to interact, and set up the application to use PostgreSQL inside the database container, we just need to run the usual db:create job using a similar run of docker-compose as we've used before: 
$ docker-compose run app bundle exec rails db:create
We'll know this has worked if we get output similar to the following: 
Creating network "dockerific_rails_app_default" with the default driver
Creating volume "dockerific_rails_app_postgres" with default driver
Creating dockerific_rails_app_db_1 ... done
Creating dockerific_rails_app_app_run ... done
Attaching to dockerific_rails_app_db_1, dockerific_rails_app_app_1
Created database 'dockerific_rails_app_development'
Created database 'dockerific_rails_app_test'
Note that docker-compose handles all of the dependent acitivities for us, such as the network for the containers as well as the storage volume for the database container, as well as creating and linking the containers themselves.

This works in reverse as well, which we'll do now quickly to tidy up and set the stage for our first grand test: 

$ docker-compose down
Finally, with all the pieces in place, let's create our development containers: 
$ docker-compose up
and navigate to our locally bound port to see that our efforts have worked!
http://localhost:8008

Rails default root
The terminal will also display the STDOUT of the containers, meaning we can see all of the output created by rails server that will be a great help during future debugging efforts!
If you want a clean terminal to work from, you can instead bring up the containers in a detached state using: 
$ docker-compose up -d
and simply use docker-compose down to bring them back down when needed.

 

 

With this done and our app ready to see some love, it is definitely a good idea to push to a GitHub project! 

$ git add -A
$ git commit -m "Initialised Rails 7 app in Docker"
$ git branch -M main
$ git remote add origin git@github.com:{{USER}}/{{PROJECT}}.git
$ git push -u origin main

From here you are good to carry on developing the app as you would normally, but remembering to run any installations or rails commands via docker-compose, e.g.: 

$ docker-compose run app bundle exec rails generate scaffold Things name:string description:text
$ docker-compose run app bundle exec rails db:migrate
$ docker-compose run app yarn add materialize-css material-icons
Note that any file edits can be done regularly, but anything that would normally require a restart of the rails server will (or any installations such as with yarn will also require a rebuild before they will display correctly - again, a shorthand for that is happily provided by the utility: 
$ docker-compose down
$ docker-compose up --build

 
 

Back

Comments

Post a Comment

Popular posts from this blog

[ToDoList] Basic Pages

Image
Well that was fun. However all we’ve really done is spooked someone called Bob, without actually creating anything remotely resembling a web application. Let’s rectify this and create some pages one would normally find on a website; a Home page and an About page. Home & Away About Helpful Links [Insert Beatles Reference]     Because we already learned a bit about MVC, we know that we will need a controller and at least one view to display these pages (we won’t need to worry about models until we’re handling real data). As before, we’ll need to add a route configuration so Rails knows where to go, too. Rails provides a fair bit of magic to streamline this process in the form of generators . However, because we’re learning, we’re going to do this manually for now and learn what this magic entails, so we can appreciate it more later. We already created a PagesController in the...
Read more

[ToDoList] Building the App

Image
The new Generator The Rails Development Server     So we have now learned some theory about Rails and set up our development environment with the required packages and version control prerequisites. I think that’s enough preamble, let’s get developing! The next few sections will involve creating a funky little web app that contains a To-Do list that we can add, remove and edit entries from. We saw a very small snippet of the extensive file structure that Rails uses in the first section. If you thought you’d be constructing the longest mkdir -p command in the observable universe to get all of this set up, you will be pleased to know (as I was) that our first utilisation of Rails magic will be to get Rails to generate all of this for us! Feel free to set up a projects directory on your dev machine, or you can just use your home dir if you’d prefer. Whatever you choose, change into this dir n...
Read more