MroongaのDockerイメージをメンテナンスする、とは

こんにちは、DBAです。
この記事は Groonga Advent Calendar 2015 の8日目の記事です。
前回の記事 で MroongaのDockerイメージ をメンテナンスしていることを話しました。
今日は、「MroongaのDockerイメージのメンテナンスって何するの?」というのを考えてみたいと思います。あわよくば誰か 代わって 参加してくださいお願いします。
1. 新しいMroongaがリリースされたら新しいイメージをビルドする
- これが一番目立つ作業です。
- groonga/mroongaのイメージはCentOS 6.6をベースにmysql-community-mroongaをyum installしています。
- 文字コードの設定を追加したmy.cnfを毎回上書きしています。
- ビルドテストの中でバージョンのチェックを行っているので、対応するGroongaとMroongaとMySQLのバージョンをversion.jsonに記述します。
- mysql-community-mroonga(MariaDB版やPercona Server版も同様ですが)は「ビルドした時に使ったMySQLのバージョン」に依存します。Mroongaを据え置きでMySQLのみアップグレードするようなケースでは、mysql-community-mroongaのパッケージが新しくビルドされ直すのを待たなければいけません。
- MroongaとGroongaは原則似たようなバージョン(ex. Mroonga 5.10 => Groonga 5.1.0)に対応します。過去例外(ex. Mroonga 4.10 => Groonga 5.1.1)があったのでその対応をしています
これだけです。簡単でしょう? (Docker Hubのビルド設定をブラウザでポチポチしますが、それも数分です)
たとえば、Mroonga 5.10がリリースされたので、MySQL 5.6.27 + Mroonga 5.10のペアのDockerイメージを作るためのPull Requestはこんな感じです。
Support mysql5627_mroonga510 by yoku0825 · Pull Request #11 · mroonga/docker
2. 新しいイメージをビルドしようとしたら素直にインストールできなくて気が付いたらSPECファイルを直している
- たまにです。
- がんばって自分で直さなくても対応してもらえることが多いのですが、折角の(Mroonga本体への)プルリクチャンスなので…と思ってやっています。
- 弊社ではrpmパッケージのMroongaは利用していませんが、ソースビルドでも同じ問題に当たっていたかも…と思うと、ベーシックなテストを走らせる良い機会になっていると思います。
3. いろいろ妄想する
- 弊社では(自分でメンテナンスしておいてなんですが)Dockerコンテナーの本番投入は全然考えてません。ユニットテスト用途、動作確認用途に嬉しくなりそうなことを考えたりしています。
- groonga-httpdをサポートしたSQL/HTTPハイブリッドなコンテナーにしたいなぁ。
- Percona XtraDB ClusterとMroongaの組み合わせももう一度試したいなぁ(前に試した 時は動いたけれど、今もまだビルドできるのかしらん)
- コンテナーの/var/lib/mysqlをホスト側のディレクトリーにマウントしたいなぁ。
- そうしたら、.frmファイルと.mrnファイルを丸コピーすれば初期データのロードが済むよなぁ(ラッパーモード使わない派です)
とかとか。何か面白そうなことがあったら教えてください :)
Pull Requestお待ちしております!
https://github.com/mroonga/docker