Our love for Rails, Docker and Kubernetes is no secret! In this post, I wanted to share some of our experience on how to deal with Rails 6 assets that use webpacker in Docker in a production environment.
What are we trying to achieve?
By the end of this post, we are going to run a Rails 6 application with compiled assets from inside of a Docker container under Production environment.
What do you need?
A Rails 6 application. You can use this sample app if you want: https://github.com/cloud66-samples/rails6-mysql
NOTE: If you use this example repository, all the files mentioned in this post are already created for you.
You'd also need to have Docker installed on your machine.
Basic understanding of using Docker command line and Dockefile format is also required.
While ultimately we are going to run this on a Kubernetes cluster (or Minikubes), the setup is the same and this post is going to focus on the tips of running Rails 6 in a containerized environment rather than focusing on the details of Kubernetes. For this reason, we're going to use Docker Compose instead of Kubernetes to make things simpler as the Rails settings are the same in both environments.
Let's get started
Running in Dev
First, let's run our application in development mode to make sure everything it runs with no errors and we have the basics configured correctly.
To get going, create a file called
Dockerfile in the application root directory like this one:
This installs the latest version of Ruby. If you want to change that, you can do so on the first line of the file. This might be needed if you explicitly have specified a ruby version in your
Gemfile. Also here you see I am installing version 2.1.2 of Bundler gem. Feel free to use the version your
Gemfile is compatible with (Rails 6 defaults to Bundler 2).
Our example app, like many others, uses MySQL as a database. To run both Rails and MySQL in docker on our laptop, we can use Docker Compose. Create a file called,
docker-compose.yml in your application root directory like this one:
Please mind that this is only for development purposes and that's why you can see the password in clear text in this file!
To make sure Rails can see the database, we need to make sure our
database.yml is configured correctly:
These is one last thing to do before we can run the app: create the database. This is needed only once unless you wipe the MySQL image off your laptop.
$ docker-compose run web rake db:create
Now we can start the app:
$ docker-compose up
On your laptop, visit http://localhost:3000 and you should see the app running.
Running in Production
You might have noticed that like any other Rails app running in
development the application compiles the assets upon the first call. In production, we would want this to happen during the image build to speed things up.
To make this change, we're going to add the following line to our
dockerfile as the last line:
RUN RAILS_ENV=production bundle exec rake assets:precompile
This will run the asset precompilation and adds the compiled assets to the image.
Let's run the application again, this time in production. To run the application in production, change the value of
production in your
Visiting http://localhost:3000 you will notice none of the assets are served correctly. This is because Rails by default doesn't serve static assets in production. This is done with the assumption that your web server (nginx, Apache, etc) is going to take care of the static assets before they hit the Rails stack to speed things up.
A note on secrets
A new Rails 6 application, won't run in production environment, unless you configre a
secret_key_base for it and use the Rails 6's Master key. This can be done by doing the following:
- Generate a new secret by running
rake secretcopy the output
rails credentials:edit --environment productionand enter the value from step 1 as the value of the
secret_key_basekey in the file.
- Make sure
RAILS_MASTER_KEYis passed in as a variable to your container. This is used by Rails to decrypt
Once you close the editor, the content of the file will be encrypted and written to
config/credentials. Rails also adds
production.key to your
.gitignore file to avoid leaking secrets into your git repo. You also need to make sure
master.key is not commited into your git repo either, agian, by adding it to
Subnote on VS Code and Rails Credentials Editor
If you're using Visual Studio Code (or similar editors like Sublime or Atom) as your default editor, you might need to set the value of
EDITOR environment variable to make sure the secrets editor still works:
$ export EDITOR=code -w
In case of VS Code,
-w ensures the editor process stays up until the file is closed so it can be encrypted and written back to the disk.
Serving Static Assets in Production in Kubernetes
In a containerized environment, it is possible to run nginx in front of your Rails application and share a volume between the 2 containers (Rails and nginx) with changes in the nginx configuration to serve the static assets using nginx and not Rails. However, when running in a real production environment (as opposed to only setting
production on our laptop), if you're running your application on Kubernetes, you're also probably running it behind an Ingress Controller, which most probably means your nginx is shared between multiple applications. This means we need to make Rails serve static assets itself.
To make that change set
true in your
docker-compose.yml and run the application again:
web: build: . ports: - "3000:3000" links: - db environment: MYSQL_ROOT_PASSWORD: root MYSQL_ADDRESS: db RAILS_ENV: development RAILS_SERVE_STATIC_FILES: 'true' db: image: library/mysql:5.6.22 ports: - "13306:3306" environment: MYSQL_ROOT_PASSWORD: root
This time, running
docker-compose up will start Rails and serves the static assets.
Where are my logs?
Rails by default logs to log files in production. In a containerized environment, you'd want to make sure logs are written to
stderr instead so they can be collected by your orchestrator (like Kubernetes or in this example, Compose). To make that change, set
true in your
web: build: . ports: - "3000:3000" links: - db environment: MYSQL_ROOT_PASSWORD: root MYSQL_ADDRESS: db RAILS_ENV: production RAILS_SERVE_STATIC_FILES: 'true' RAILS_LOG_TO_STDOUT: 'true' db: image: library/mysql:5.6.22 ports: - "13306:3306" environment: MYSQL_ROOT_PASSWORD: root
Now you should see your logs!
In summary, to run Rails 6 in production in a containerized environment like Kubernetes, you need to do the following:
- Make sure
yarnis installed in your Docker image (see the Dockerfile example above)
- Install Bundler 2 and above. Most Docker Ruby base images come with Bundler 1.
yarn install --check-filesin your Dockerfile
RAILS_ENV=production bundle exec rake assets:precompilein your Dockerfile.
trueif you would like to see the logs.
- Make sure you either have a credentials file in production or set the
SECRET_KEY_BASEvariable in production and during the image build phase.
Can it be made simpler?
If this looks too much, you can always use Cloud 66 Skycap to run your Rails applications on any Kubernetes cluster. Skycap understands Rails: it connects to your git and generates the needed Dockerfile, environment variables and all of the needed Kuberentes configuration files you'd to run your Rails app in production on Kubernetes in a simple few steps.