こんにちは、鈴木です。

前回、前々回は Docker の基本を解説しました。

今回は Rails の開発環境を Docker 上に作り上げてみようと思います。

 

全体的な構成

全体的な構成は以下の通りです。

• アプリケーション名は hello とする。
• データベースには PostgreSQL を使用する。
• データベース用のコンテナと開発用のコンテナを作成する。
• 開発用のコンテナには SSH で接続する。

データベース用のコンテナを作成する

まずはデータベース用のコンテナを作成します。

Docker Hub で PostgreSQL のイメージが提供されているので、それを使います。

イメージを取得して起動するだけです。

コンテナはデタッチモードで動かしたいので -d オプションを指定しています。また、コンテナには名前を付けておくと便利なので --name で「postgres」という名前を付けました。

ポイントは環境変数として「-e LC_ALL=C.UTF-8」を指定しているところです。これは initdb でデータベースクラスタを初期化するときのエンコーディングを UTF-8 とするためです（デフォルトでは SQL_ASCII になります）。

Rails 開発用のイメージを作成する

次に Rails 開発用のイメージを作成します。

PostgreSQL は既存のイメージをそのまま使用しましたが、今度は個人用の開発環境を作りたいのでそうもいきません。

Dockerfile を書いて自分用のイメージを作成することにしました。

まとまりごとにコメントを記載しましたので、順番に見ていきましょう。

(1) の apt-get update ではパッケージのインデックスを更新しています。このような一般的な処理は Dockerfile の先頭のほうに記述しておくと良いでしょう。そうすることで、試行錯誤しながら Dockerfile を修正＆ビルドを繰り返すときの作業時間を短くすることができます。というもの、Dockerfile をビルドする時は 1 行 1 行が順番に実行され、中間イメージとしてコミットされます。中間イメージはキャッシュされるため、Dockerfile の最後のほうを修正してビルドしなおした場合、既にあるキャッシュが流用され、変更した部分移行が新たにビルドされるためです。反対に Dockerfile の先頭の方を変更すると、ほとんどキャッシュを流用することができないため、ビルド時間はあまり短縮できません。

(2) では一般的なパッケージをインストールしています。他に必要なパッケージがあれば、ここに追加しましょう。

(3) では SSH サーバをインストールし、必要な設定を行っています。

(4), (5) はそれぞれ RVM (Ruby Version Manager) と Ruby のインストールに必要なパッケージをインストールしています。

(6) では開発用のユーザとして rails という名前のユーザを作成しています。パスワードは「password」としているので、適宜変更してください。また、パスワード無しで sudo できるように設定していますが、開発用の環境だからセキュリティ上の問題は無いという前提で行っています。

(7) では rails にユーザを変更しています。(8), (9) で RVM と Ruby-2.1.2 をインストール、(10) で gem をインストールするときにドキュメントを生成しないための設定を行い（ドキュメントもインストールしたいという方はコメントアウトしてください）、そして (11) で Rails-4.1.4 をインストールしています。

(12) では作業用のディレクトリとして ~/workspace を作成しています。後ほど hello という名前の Rails プロジェクトを ~/workspace/hello に作成します。

(13) では root ユーザに戻していますが、これは SSH サーバを root 権限で動かすためです。

(14) ではコンテナ外に出すポートとして 22 (SSH) と 3000 (Rails) を指定しています。

(15) では外部からマウントする場所として /home/rails/workspace を指定しています。こコンテナ内で開発したコードは git や subversion リポジトリにチェックインするので外部とファイルを共有する必要が無いという場合は不要ですが、コンテナ内のファイルをコンテナ外から簡単に取り出せるようにしておきたかったので、指定しています。

(16) ではコンテナを起動したときに実行するコマンドを指定しています。今回はコンテナには ssh 接続するので、ssh のデーモンを指定しています。

Dockerfile を作成したら、ビルドします。

ビルドにはしばらく時間がかかりますが、完了すると work:0.0.0 というイメージが出来上がるはずです。

Rails 開発用のコンテナを起動する

コンテナを起動する前に、コンテナ内にマウントするディレクトリを作成します。

次にコンテナを起動します。

オプションが多いので一つずつ説明します。

-d はコンテナをデタッチモードで起動するオプションです。コンテナで動かすのは ssh のデーモンなのでデタッチモードを選びました。bash 等のインタラクティブに操作するプロセスを起動する場合はアタッチモードで起動します。

--name work はコンテナに work という名前を付けます。名前を付けておくことで、コンテナの停止/再開を docker stop work や docker start work のように名前で指定することが出来るので便利です。使い捨てではないコンテナ（しばらく動き続けるコンテナ）には --name で名前を付けておくと良いでしょう。

--publish 80:3000 はホストの 80 ポートとコンテナ内の 3000 ポートをマッピングします。これで rails server でアプリケーションを起動すればホスト側の 80 ポートでアクセスできるようになります（3000 ポートは rails server で起動したときのデフォルトポートです）。--publish 10022:22 はホスト側の 10022 ポートとコンテナ内の 22 ポートをマッピングします。22 ポートは ssh のデフォルトポートですが、ホスト側の 22 ポートを使用すると困る（ホスト自身に外部から ssh 接続している）場合もあるので、10022 にマッピングしています。

--link postgres:db は最初の方で起動した PostgreSQL が動くコンテナとリンクするためのものです。これは postgres という名前のコンテナを db という名前で参照できるようにするという意味です（起動したコンテナ内の /etc/hosts にエントリが追加されます）。

--volume ~/workspace:/home/rails/workspace はホスト側の ~/workspace とコンテナ内の /home/rails/workspace をマウントします。

--privileged は --volume と関連するオプションです。デフォルトではコンテナ内でマウント領域に対する機能は制限されているため、ファイルの作成などを行おうとすると「Permission Denied」とエラーになってしまいます。--privileged オプションを指定すると、ホスト側と同じ権限を与えることができます。

最後の work:0.0.0 はコンテナの作成に使用するイメージです。

コンテナ内に SSH 接続する

コンテナ内に SSH で接続してみましょう。

コンテナ内の 22 ポートはホスト側の 10022 ポートにマッピングしているため、このようになります。

接続するとパスワードを求められますが、Dockerfile 内で設定した「password」と入力すれば OK です。

これでコンテナ内で作業できるようになりました。

コンテナ内を探索する

コンテナ内を探索してみましょう。

/etc/hosts の中を見ると、--link オプションで指定したとおり db というエントリが追加されていることを確認できます。

db サーバに接続できるか確認してみましょう。

接続できれば OK です。

データベースユーザを作成する

Rails プロジェクトを作成する前に、接続用のデータベースユーザを作成します。

rails という名前で作成しました。

Rails プロジェクトを作成する

hello という名前の Rails プロジェクトを作成しましょう。

プロジェクトを作成したら、データベースの接続先を設定します。

database.yml を開き、「host: db」を追加します。

次はデータベースを作成します。

アプリケーションを起動する

長い道のりでしたが、アプリケーションを起動してみましょう。

無事に起動できれば、ホスト側の「http://localhost/」でアクセスできるはずです。

思ったこと、考えたこと、試行錯誤したこと

ここまでやるのに色々と試行錯誤したので、その道のりを簡単にまとめます。

Dockerfile を作り上げるのは大変だ

Dockerfile を作る時は試行錯誤の連続でした。少し書いてはビルドして、エラーが出たら修正して・・の繰り返しになるので、ものすごく時間がかかりました。特に「このパッケージも必要だった！ → Dockerfile の始めのほうに追加 → ほとんどキャッシュが効かないのでビルド時間がすごくかかる・・」ということも多々ありました。

「すごく時間がかかる・・」と気付いてから、ベースとするイメージで bash を起動し、そこでコマンドを打ちながら Dockerfile に転記していくやり方に変更しました。ある程度書き上げてから一気にビルドすればトータルの時間は短くなると思います。

開発用のコンテナで bash を動かすべきか sshd を動かすべきか（sshd にした）

開発用のコンテナ（今回の例では work）で bash を動かすべきか、sshd を起動して ssh 接続するか迷いました。最初は bash を動かすようにしていたのですが、Ctrl+p で一つ前のコマンドを出せない（デタッチするための Ctrl+p Ctrl+q とかぶっているため、一つ前のコマンドを出すには Ctrl+p Ctrl+p と 2 回入力する必要がある）ため、最終的に ssh 接続するやり方を採用しました。

開発用のコンテナでは --volume でマウントした場所に Rails プロジェクトを作成した

開発用のコンテナで Rails プロジェクトを作成しましたが、そのファイルは --volume で外部からマウントしたディレクトリに置くようにしました。そうしたことでコンテナを気軽に破棄して作り直すことができるようになりました。頻繁に作り直す可能性のあるコンテナについては、データを外出ししておいた方が良さそうです。

インストールパッケージのバージョンを厳密に指定するべきか（指定しなかった）

Dockerfile 内で「RUN apt-get install -y openssh-server」のように記述しましたが、「RUN apt-get install -y openssh-server=1:6.6p1-2ubuntu2」のようにバージョンを厳密に指定するべきか迷いました。なぜ迷ったのかというと、同じ Dockerfile でもビルドした時期によって出来上がるイメージが異なってしまう可能性があるのはどうよと思ったからです。結局「そこまで神経質にならなくても良い」と思い、バージョンは指定しないようにしました。

PostgreSQL のデータディレクトリを --volume で指定するべきか（指定しなかった）

PostgreSQL のコンテナを作成するときに --volume でデータディレクトリを指定するかどうかです。間違って PostgreSQL のコンテナを削除してしまった場合にデータが失われるリスクを考えたのですが、気にしすぎ（本番環境だったらバックアップするだろうし、手元の環境のように全部まとめて削除のようなことはしないはず）という結論になりました。

オフィシャルリポジトリはありがたいけれど、情報が少ない

オフィシャルリポジトリは非常にありがたい存在なのですが、まだ情報が少ないと感じます。起動方法以外は説明が無い場合もあります。今回は PostgreSQL のオフィシャルイメージを使ったのですが、すぐには initdb するときのエンコーディングを変更する方法が分かりませんでした。困った時は Docker library の中を見ると解決するかもしれません。

いったん動けるようになったら楽だった

試行錯誤している段階を過ぎてしまえば、コンテナを気軽に作成/破棄できるので楽だと思えるようになりました。消えては困るデータは --volume でホスト側からマウントし、コンテナを捨てやすくしておくこともポイントだと感じました。

まとめ

Enjoy Docker!