Redmineの公式Dockerイメージを例に、自分に合ったDockerの使い方を探る
大体は redmine の公式コンテナイメージの使い方に終始します。
環境
環境については、以下の通り。
1
2
3
4
5
6
7
8
9
|
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
$ docker -v
Docker version 1.12.1, build 23cf638
$ docker-compose -v
docker-compose version 1.8.1, build 878cff1
|
また、一般ユーザーが Docker グループに所属しているという前提で進行する。
Redmineを起動する
Redmine公式のドキュメント
によれば、SQLite3、PostgreSQL、MySQL(MariaDB)が使えるらしいので、今回はMariaDBを使用することにする。
まずは、以下のような docker-compose.yml を作成した。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
version: '2'
services:
redmine:
image: redmine:3.2
ports:
- 3000:3000
environment:
REDMINE_DB_MYSQL: db
REDMINE_DB_PASSWORD: password
depends_on:
- db
restart: always
db:
image: mariadb:10.0
environment:
MYSQL_ROOT_PASSWORD: password
MYSQL_DATABASE: redmine
restart: always
volumes:
- ./mysql_conf.d:/etc/mysql/conf.d/
- ./mysql_data:/var/lib/mysql
|
そして起動する。
これで http://localhost:3000
にでもアクセスすればRedmineの画面とご対面だ。
それにしても手軽だなぁ。
メールの設定追加
さて Username: admin
/ Password: admin
でログインしてRedmineの管理画面に辿り着いた僕は、メールの設定をしないといけないことに気付いた。
config/configuration.yml
を編集するように言われるので、公式コンテナイメージではどうなっているか見てみると、こんな感じだった。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
$ docker exec -it redmine_redmine_1 ls -l config
total 75
-rw-rw-r-- 1 redmine redmine 219 Oct 10 07:50 additional_environment.rb.example
-rw-rw-r-- 1 redmine redmine 3490 Oct 10 07:50 application.rb
-rw-rw-r-- 1 redmine redmine 171 Oct 10 07:50 boot.rb
-rw-rw-r-- 1 redmine redmine 8140 Oct 10 07:50 configuration.yml.example
-rw-r--r-- 1 root root 132 Nov 19 14:39 database.yml
-rw-rw-r-- 1 redmine redmine 1137 Oct 10 07:50 database.yml.example
-rw-rw-r-- 1 redmine redmine 586 Oct 10 07:50 environment.rb
drwxrwxr-x 2 redmine redmine 4096 Oct 10 07:50 environments
drwxrwxr-x 2 redmine redmine 4096 Nov 19 14:39 initializers
drwxrwxr-x 2 redmine redmine 4096 Oct 10 07:50 locales
-rw-rw-r-- 1 redmine redmine 17323 Oct 10 07:50 routes.rb
-rw-rw-r-- 1 redmine redmine 5526 Oct 10 07:50 settings.yml
|
つまり設定ファイルを書いて送り込めばいい。
まずは configuration.yml.example
に倣って、以下のように configuration.yml
を書いてみる。(ここではGmailを例にしてみる)
1
2
3
4
5
6
7
8
9
10
11
|
default:
email_delivery:
delivery_method: :smtp
smtp_settings:
enable_starttls_auto: true
address: "smtp.gmail.com"
port: 587
domain: "example.com" # 'your.domain.com' for GoogleApps
authentication: :login
user_name: "redmine@example.com"
password: "password"
|
dockerにはホストからコンテナ内にファイルコピーが可能なので、上記ファイルをコピーして、サービスを再起動する。
1
2
|
$ docker cp configuration.yml redmine_redmine_1:/usr/src/redmine/config/configuration.yml
$ docker-compose restart
|
これを手間と見るかどうかは人による気がする。
確かにメール位は docker-compose で environment に設定できた方が良いかもね。
environment で設定できそうかどうかは docker inspect redmine:3.2
のようにして確認できるので、初めて触れるイメージにはとりあえず叩いてみるのも良さそうだ。
テーマの追加
Redmineのテーマを変えたい場合はどうしよう。
場所はここ。
1
2
3
4
5
|
$ docker exec -it redmine_redmine_1 ls -l public/themes
total 10
-rw-rw-r-- 1 redmine redmine 30 Oct 10 07:50 README
drwxrwxr-x 3 redmine redmine 4096 Oct 10 07:50 alternate
drwxrwxr-x 4 redmine redmine 4096 Oct 10 07:50 classic
|
やっぱりボリュームマウントによる対応かな?
ボリュームマウントすると通常のマウントと同じように、元々入ってるthemesが見えなくなる。
元々入ってるテーマもとりあえず残しておきたいので、今回は追加コマンドを叩く方式を採用する。
ファイルを置いてコンテナを再起動するだけ。
gitmike をお借りした。
1
2
|
$ docker exec -it redmine_redmine_1 sh -c 'git clone git://github.com/makotokw/redmine-theme-gitmike.git public/themes/gitmike'
$ docker-compose restart
|
ふむ、簡単。
プラグインの追加
プラグインの追加はもう少し悩むべきだったかもしれない。
確かに bundle install
とか叩かないといけない場合はコマンドが2,3行になるのだけど、よく考えたらDockerfile もRUNコマンドが長かったな、と考えたのがまずかった。
テーマの追加と同じように、外からコマンド叩けばいいや、と思考停止した僕はプラグインの追加についても左程悩まなくなってしまった。
例えば、ナレッジベースを追加するプラグインの場合は、
1
2
3
4
|
$ docker exec -it redmine_redmine_1 sh -c '
git clone git://github.com/alexbevi/redmine_knowledgebase.git plugins/redmine_knowledgebase &&
bundle install &&
rake redmine:plugins:migrate NAME=redmine_knowledgebase'
|
のように実行できる。
docker exec
する場合は、どこがコマンドの終端か分かりにくいので sh -c '<command>'
する方が良さそうだな、と言うくらい。
後は同じようにコンテナを再起動する。
1
|
$ docker-compose restart
|
おわり
アプリケーションデプロイの方法にDockerを使う、と言うものが追加されたことによって、公式コンテナイメージを使うのと、自分用に変数化する部分とインストール手順を決めてコンテナイメージを作るのと、どちらが良いかについて悩むことになった。
リスク的な面で、とりあえず公式コンテナイメージを使うポリシーで動こうと決めたものの、ではそのカスタマイズは、と言うのが今回の話。
今回ネタにしたように、公式コンテナイメージにもう少し手を加えたいとなれば、それはコンテナ自体をデプロイするAnsibleの役目なんじゃないかなーと思うので、僕としては役割分担についてもある程度納得できた。
最初からプラグインもテーマもてんこ盛りにした誰かが作ったコンテナイメージでも、動くならそれを使って、本来やるべきことに注力したい人もいるのかもしれない。
まぁ、その辺りは面倒を見る期間とか立場とか興味とか、色々あるだろうね。
僕の場合は「本来やるべきこと」が環境作りに偏っているので、だいぶ保守的な使い方に落ち着きそう。
いったんここまで。