This is the basic template for a Docker-based Rails application, for development on a Mac.
To get started, you'll need to do the following:
The folder needs to be within ~/ in order to support NFS volume sharing with the container.
The project folder contains two folders
/docker, which contains helper scripts and server config files/webapp, which contains the rails application
This is how we access Docker via a Mac. Since we can't directly map Docker onto Mac, but need to run it in a VM, Dinghy wraps that abstraction layer to give us nicer, faster containers (mainly through NFS support).
If you already have Docker installed, it's preferable to first delete any existing Docker machines, such that you're only running one VM. Having more than one causes SSL problems depending on the order of machine startup (docker/machine#531).
The basic sets of commands to install Docker and Dinghy are
$ brew update
$ brew install docker
$ brew install docker-machine
$ brew tap codekitchen/dinghy
$ brew install dinghy
$ eval $(dinghy env)
To save yourself the effort of having to run dinghy env every time you open a terminal, you can put its output into ~/.bash_profile.
- Navigate to your project directory
- Build the container with
docker/build. This will take a while the very first time as it needs to download the containers' base images, install applications from APT, and install rubygems. These files are then cached for future builds. - Once
docker/buildcompletes successfully, it will automatically place you into the container's bash prompt - Start the app with
./server - Visit it at http://my_app.docker
- Stop your app with
Ctrl-C - Start the app with
./server - Visit it at http://my_app.docker
- Stop your app with
Ctrl-C - Exit the container with
exit - Rebuild the container with
docker/build - Start the app with
./server - Visit it at http://my_app.docker
-
From the project directory, build your Base container with
docker build -t local/my_app:latest docker -
Build your Production container with
docker build -t local/my_app:latest -f docker/Dockerfile.prod . -
Run your Production container with the following environment variables
- RAILS_ENV=production
- DATABASE_URL
- RAILS_RESQUE_REDIS
- SECRET_KEY_BASE
You can generate a SECRET_KEY_BASE with
require 'securerandom'
SecureRandom.hex(64)
This application template comes with the default self-signed certificate and key that was generated by running
$ openssl genrsa -des3 -passout pass:x -out server.pass.key 2048
$ openssl rsa -passin pass:x -in server.pass.key -out server.key
$ openssl req -new -key server.key -out server.csr
$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
You might choose to replace these files in your lower environments, but at the very least, the Production container will remove these files.
The preferred method is to map a local volume on your Production server to /etc/ssl on your Production container, containing server.crt and server.key.
If you want to force ALL requests to go through SSL, you can uncomment the option in application.rb
# config.force_ssl = true
or specify it in each of development.rb, test.rb, and production.rb.
On Postgres, in development, we automatically map $APP and $APP_test as our database names. This makes it relatively easy to run multiples of applications, as long we name the applications differently to begin with.
On Redis, we DO NOT have a corresponding mapping to separate our applications. Redis does not have database names, but rather has database numbers (from 0 to 15, by default). Since there is no obvious hasing from $APP to an integer, we set the database number to 0, and leave it as an exercise to the user to change it for each application.