2017年04月07日

docker上にredmine環境を構築

我が家で飼っている鼻毛鯖、近頃ubuntu16.04にアップデートして元のとおり運用を回そうとしてるんだけど
前みたいにrubyのバージョンやらapacheに色んなのが相乗りする状況やらをもう一度やり直したくて、
せっかくubuntuバージョンアップさせたんなら各機能dockerで独立でしょ、という機運が高まってきた。

そういうわけでdocker導入してredmine運用するまでの手続きと、
手続きだけならQiitaで読めるのでその時の俺の苦悩やらだだ漏れた妄想やら欲望やらをここに記す。
つまりここに記されているのは有益な情報ではなく一人のおっさんの個人サーバー環境に対するフェティシズムだけだ。



まずはdocker導入

メモリ9GB、ディスク6TBまで拡張して何やる?といわれれば、仮想環境をぽこじゃか独立させて気軽にお試し環境なりなんなりを作ることでしょう。
昔はVirtualBox直起動、そのうちVagrantなどのセットアップまで一揃えにした環境を使うようになったんだけど
今はdockerの時代。わざわざディスクやネットワークまで仮想化しなくても、ファイルシステムだけ仮想化すればいいよねという効率的な仮想化のやり方らしい(解釈これであってんのかな)これをコンテナ型というそうな。

ubuntu16.04へのインストールの仕方はいろんなところに書いてるけど、今回はこっちの記事を参考にした


dockerの他にdocker-composeという、複数のdockerの環境設定をしつつ依存関係を調整しながら構築するツールを導入する必要があるようだ。これがないと後に説明するredmine環境をうまく引っ張ってこれない

ん?複数のdocker?redmine1機能を構築するのになぜdockerが複数必要になる?
一瞬悩むところなんだけど、ここがdockerの使い方のキモのようなのだ。

dockerのベストプラクティスとは

従来にないコンテナ型の仮想環境ということで色々知見が溜まってきており、こんな風に運用するといいらしい


ここでのポイントは

  • イメージは短命に。すぐ構築・破棄できるように
  • 1コンテナ(仮想環境のことをdockerではこう言う)なるべく1プロセスにする

ってことらしい。低コストで仮想環境を沢山作成できるから、その分一つ一つの環境を贅沢に1プロセスに限っちゃえってことだな
かつてrailsが環境依存が複雑すぎてbundle/install配下にgemを閉じ込めるようになったけど
それをアプリケーションレベルでやってしまおうというノリかもしれない。ほぼ仮想環境というよりアプリケーション実行環境だな・・・

つーわけで、最低でもredmine本体のコンテナとDBコンテナは別、下手するとapacheなりnginxなりのhttpサーバー環境ですら別コンテナで構築すべきなようだ。

まあいろんなページみたけどnginxレベルまで別コンテナにして運用してる人はいなかったし、redmineとdbでコンテナ2台構成で行きましょう
Redmine導入するやで

さて、このredmine+db環境、構築するのに一番お手軽かつ人気がある環境がsameersbn/docker-redmineだ。


screenshot.47.png
ところでこのアイコン、環境作ったご本人?オーラ強すぎなんだけど

公式ページのQuick Startの章を参考にすると、本当にquickにstartできる。すなわちdocker-composeがある環境なら


これだけ。別環境から http://{サーバIP}:10083/にアクセスすれば、もうすでにredmine立ち上がってる!
おお、入れるのにあれだけ苦労してた過去はなんだったんだ。

なお、URL等が気に食わない場合、docker-compose.ymlを多少弄るとよい。俺の場合

redmine:
image: sameersbn/redmine:3.3.2-1latest
environment: - TZ=Asia/KolkataTokyo
- REDMINE_PORT=1008380
- REDMINE_RELATIVE_URL_ROOT=/redmine
ports:
- "10083:80""80:80"
ここらへんを弄った結果、http://{サーバIP}/redmine でアクセスできるように。いいねえ。

プラグイン入れるやで→その前に永続化ってナニ

あと欲しいのがコレ。あんまり色々入れるとポータビリティが悪くなるんで、PlantUMLとコードレビュープラグインのみ導入としたいんだけど、これをどうやって入れるのか、と言う前にまずdockerでファイルっていうのがどう扱われるのかという話を理解しなきゃいかん。

普通の仮想環境では、環境を立ち上げて→落としてってしたあともファイルは保存されている。
まあ普通のOSと同じだよな。仮想HDDもちゃんとある。

一方、dockerには仮想HDDみたいなもんはないらしい。起動したらメモリ上にファイルシステムはできあがるんだけど
なんと環境を停止すると消えてしまう。なんでこんな動作になってるのかよくわからないけど
先のベストプラクティスとか参考にすると、そもそもdockerってのは一時的なテスト環境をガンガン立ち上げて壊すみたいな用途を想定してるらしい。
まあわかるっちゃあわかるんだけど、そんなんじゃまともに運用できねぃよ

というわけで、対応としてdockerを実行する側(ホスト環境)のファイルシステムにデータを保存できるボリュームという機能がある。
素のdokcerを利用する際には、docker run の引数に -vスイッチを使用すれば利用できるし
docker-composeではvolumes:というセクション内にホスト側:ゲスト側の順番に記述する

/srv/docker/redmine/redmine:/home/redmine/data

こうするとdocker側の/home/redmine/dataフォルダが、ホスト側の/srv/docker/redmine/redmineにちょうどマウントされたような形で利用可能なんだそうな。

さて、ここまできてやっとプラグインの導入のしかたを説明できる。
/srv/docker/redmine/redmine/plugins内にいつもの通りプラグインのファイル一式を格納し、
docker-compose upでコンテナを起動するのだ。

もちろんプラグインの実行前には必要ソフトのインストールとかdb:migrateとか色々あるんだけど、
そろそろ文量も多くなったのでまた別の機会に書きます〜
まずは今回、redmineをちゃんと構築できたのでよかったよかった。

今後やりたいこと

以前の環境をdockerに入れ替えてしっかり運用するのが当面の目標だ。すなわち

  • bittrrent syncでローカル動機環境(最近resilio syncって名前になったんだっけ?)
  • Chinachu + Mirakurunで録画環境
  • redmine

これらをnginxのサブディレクトリとして切って、それぞれ独立に運用したい・・・

で、dockerがそれぞれ独立してるんで、docker-composeで管理だな。
あ、データ永続化はそれぞれがボリュームを持つんじゃなくてデータ永続化のみ一手に引き受けるコンテナを作るほうがいいんだっけ?
(data-only container patternというらしい)

あと複数のdockerを管理するのってdocker-composeが直感的で楽なんだけどkubernetesってのもあるんだっけ?
こっちのほうが本格的なのかな、

そもそもdockerの元イメージってubuntuだと無駄なデータが入ってて重くなるから
debianベースにしたほうがいいとか、そもそもコンテナ用にgoogleがContainer-Optimized OSっていうのを作ってたりとか
ああ、新しい技術だから色々楽しいことあるなあ。色々やりたいなあ
タグ:redmine
posted by LoyalTouch at 06:50| Comment(0) | TrackBack(0) | インフラ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのトラックバックURL
http://blog.seesaa.jp/tb/448794550

この記事へのトラックバック