Next-L Enju Leafは、Project Next-Lが開発しているオープンソースの図書館管理システムです。探せば既存のDockerイメージもありますが、以下のような問題があるので1から作りました。
- Dockerfileが公開されておらず、ビルドを再現できない
- Automated Buildになっておらず、第三者が正当性を確認しづらい
- PostgreSQLが同じコンテナ内で起動するので扱いづらい
Railsアプリ、Redis、Solr、Cronなどを1つのイメージに含めており、PostgreSQLは別コンテナを使うようにしました。本当はRedisやSolrも分けるほうが望ましいですが、公式のインストール手順でもForemanでアプリ起動時に一緒に起動するようになっていることやインデックス再生成のしやすさを考えて、とりあえずは同じコンテナとしました。
必要なもの
起動方法
以下の手順で簡単に起動できます。
-
適当なフォルダにdocker-compose.ymlをダウンロードして、コンテナを起動する。
$ wget https://github.com/orangain/docker-enju-leaf/raw/master/docker-compose.yml $ docker-compose up # sudoが必要な場合もあります -
ブラウザーで
http://<DOCKER_HOST>:3000/を開く。デフォルトの管理者アカウントは次の通り。- user:
enjuadmin - password:
adminpassword
- user:
イメージ作成のポイント
基本的には公式のインストール手順に従ってDockerfileを作っていましたが、1つ問題がありました。このインストール手順では、rails g enju_leaf:setupやrails g enju_leaf:quick_installによって、実行日時の番号（例：20170309144915）を持つ新しいマイグレーションがdb/migrate/内に作られます。
これはつまり、イメージをビルドする度にマイグレーションの番号が変わってしまうということです。このままだと、例えば1.2.0のイメージを1.2.1に差し替えたときに双方のマイグレーションの番号が完全に異なるので、rake db:migrateに失敗してしまいます。
このような事態を防ぐため、リポジトリのenju_leafディレクトリにRailsアプリのソースコード一式を置いて、それをDockerイメージにCOPYすることで、マイグレーションの番号が変わらないようにしました。
コンテナの作成時にデータベースのマイグレーションやSolrのインデックス再生成を自動的に行うので、新しいバージョンが出た時はdocker-compose.ymlのイメージのバージョンを書き換えて起動し直すだけで、いい感じにアップグレードできるようになるはずです。