たまにはエンジニアっぽいふいんき(なぜか変換できない)を醸す

みなさんごきげんよう、沙耶です。

docker使ってますか? 沙耶はわりとこれが好きです。

docker自体は枯れた技術の集合に近いのですが、沙耶としてはdockerの思想に近い部分、事象の抽象化によってあらゆるプロセスを疎結合に導くという解は、一つのあるべき形でもあるかと思います。

そういった意味で、それをさらにゴリ押ししているrancherOSやcoreOSも割と好きです。
ただあいつらはたぶんちょっと行き過ぎている気もするんですが、まああと3年後には支配者になっていることでしょう。そうじゃなかったら全員の記憶から消えているでしょう。

ばくちやなw

さて。そんなDockerも一つだけ欠点があります。ストレージ。そうです。ストレージどうするんだよ、という大事な問題。プロセスは分離できても、ストレージはどうやったってハードウェアと密結合する要素です。そして、世間はそれに対する解をいくつか提示しています。

まず、もっとも単純なのは、永続ボリュームコンテナ。
これはホスト上のストレージの一部をコンテナに引き渡し、コンテナ自体が終了しててもアクセスできるストレージコンテナとして、プロセスコンテナから分離する、という考えですね。

ネックは、このコンテナ、ホストと密結合することです。

つまり、ちょっとDockerのアプリケーションコンテナをスケーリングさせるぜぇ!とか分散配置だぜぇ!とか、そういうクラスタリングっぽいことをやろうとするといきなり役に立たなくなります。

よし分かった。じゃあ俺が。

そういって出てくるのがGlusterFSやHadoopのHDFSみたいな分散ファイルシステム、ということになります。
多くの分散ファイルイステムがありますが、OSSベースで使いやすくて楽ちんで、とかになるとGlusterFSになってくるかと思うんですが、これもまた欠点があります。ただでさえオブジェクトが増えると一気に遅くなるGlusterFSがデバイスマッパーを通じた多重マウントの向こう側、なんてことになるわけで、高速化やなんやかんやなんて話にはまるで適しません。

でっかいデータをじっくり腰据えて処理する分にはいいんでしょうけど、少なくとも沙耶はGlusterFSを速度要求の強いWebの共有ストレージになんかは使いたいとは思わないわけです。

しょうがねぇ、じゃあ俺だ。

そういって出てくるのはRDB。要はなにもかもblobにして突っ込んでしまえという思想ですが、これもアプリ側の対応必須なのと、インフラだけで完結しないのと、そもそもじゃあDBの方の冗長性と可用性は。とかいう話が持ち上がります。
※ただ、そこに関してはRDSとか使えばだいぶラクできる。

とはいえまあなにもかもblobで突っ込んだら、それはそれでDBのパフォーマンスに如実に引っかかりそうなのと、くだらないロック待ちとかで読めない応答時間やデータが巨大すぎるとそもそも1カラムに突っ込んでるそのデータ毎度読んでくるのかとかテーブルがオンメモリ展開されたときそこのカラム間違えてselectに含んでたらえらい目に遭いそうです。
自分のせいじゃないとはいえ、クエリに激しく依存するので、アホクエリ作られたら目も当てられないかもしれません。

じゃあ俺?とか言って出てくるのは昔ながらの共有ストレージ。NFSだとかですね。

お前は実績高いんだけど、結局のところDockerの思想とうまくかみ合いにくい。どうしたってお前はハードウェアと密結合しているわけで、そこをスポイルできるEFSとかならまあいいのかもしれんが、結局のところそれだってホスト側実装になる。ホスト側実装をどこまで簡略化できるか、という部分はあるにしろ、AMI一発ですべて完結させよう、とかのRancherやECSの思想に染めるには手数が多そうだ。

 

と、どれも一長一短なわけです。

そんな今日試すのは、”共有ストレージ”アプローチ。ただし、インターフェースは”バックエンドストレージが何者であろうとも”同じアクションで同じものが作れる、というアクション。

EMCの作ったREXRayです。libstoragedのフロントエンドラッパー。ストレージを抽象化するアプローチですね。枯れた技術である共有ストレージを抽象化概念を施すラッパー通して表現型を同一にする、というアプローチ。何言ってるのかわからない? 大丈夫俺もよくわかんない。

早速取り組んでみましょう。

まず読んだのはこことかから始めてみたのですが、そもそも自分のとらえ方がいろいろ違っている部分もあり、手順としてはこれでは正しく動きません。
というか、何が正しいのか実はよくわかりませんが、ひとまず動かせるようになったので。

今回バックエンドに使ってみよう、と思ったのはオブジェクトストレージ代表、Amazon S3。EFSはまだ日本リージョンに来てないし、EBS(EC2)は抽象化といいつつどうしてもEC2と紐づいてしまうので、いちいち冗長化だの分散だのかんがえないといけない気がするので、軽くめんどくさい。もっとお手軽にやりたいんだよ俺は。というわけでS3。

正直言うとREXRayの日本語資料なんてほっとんどない(EMCDellの記事くらいだがアレもたいがい不親切だ)ので、基本英語と取っ組み合いですから、いろいろ足りなかったり、余計なことやってたりもします。

環境はvagrant + centos7のminimal

■s3fs

まず何はともあれ、S3に接続するのですから実行体が必要です。s3fsをインストールします。
正直まあここは勝手知ったるなんとやらですので、適当です。
sudo yum -y install gcc-c++ fuse fuse-devel libcurl-devel libxml2-devel openssl-devel autoconf automake
sudo cd /root
sudo git clone https://github.com/s3fs-fuse/s3fs-fuse.git
sudo cd s3fs-fuse/
sudo ./autogen.sh
sudo ./configure –prefix=/usr
sudo make
sudo make install

以上終了。めんどくさかったので次からsudoさんを省く。

■Dockerをアップデート

docker plugin installはdocker 1.13からのもの。1.12には存在しない。そしてCentOSの標準は1.12になっている。正直plugin install使わなくてもdocker.conf書けばいいと思うんだけど、まあそこはほら、新しいの使いたいじゃない?(キチガイ

基本はdockerさんのマニュアルに沿う。さようなら、Docker-engine、こんにちはDocker CE。

yum remove docker docker-common container-selinux docker-selinux docker-engine
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager –add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum-config-manager –disable docker-ce-edge

デフォルト無効ですが、一応明示的にedgeをdisableするほか、yum-utils以外はデフォで入っているはずだけど、念のため依存関係を入れる。

yum makecache fast
yum list docker-ce.x86_64  –showduplicates |sort -r

ちゃんとdocer-ceが見えているか確認。
yum install docker-ce-<VERSION>で入れるけど、別にここまで見えていれば

yum install -y docker-ce

でOK。これで最新版のStable。
if [[ ! -e /etc/docker/daemon.json ]] ; then
cat <<EOL > /etc/docker/daemon.json
{
“storage-driver”: “devicemapper”
}
EOL
fi

とりあえずデバイスマッパーをストレージとしてセットして、docker起動。
systemctl start docker
docker run hello-world
走ってるかの確認。

■REXRayのインストールとセットアップ
ここがほんとドキュメントなくて困ったからこんなの書いてるわけで。まあ困ったっつっても1日で終わってんだけどさ。というかDockerで一日かかってたら長いんだよね。

そもそも何を参考にすべきだったかっつーと REXRayのドキュメントEMCの記事
REXRayからちょいちょいlibStoragedのドキュメントに吹っ飛ばされるが、あれはConfigの書き方の参考にしろ、というだけでlibstorageをいれろとか言う話ではない。

curl -sSL https://dl.bintray.com/emccode/rexray/install | sh -s — stable
まずコレ。でインストール自体は終わり。
rexray version
でバージョン情報やらが出てくる。だが、rexray startやsystemctl start rexrayなんかしてもこの時点では起動しない。なぜなら設定が一ミリも(そう、基本サンプルすらも)ないからだ。

cd /etc/rexray

見事なまでに空っぽです。で、ここになんのファイルをどう置けば、ってのがはっきり書かれてなくてさまようことになる。結論から言えば、

/etc/rexray/config.yml

libstorage:
  # The libstorage.service property directs a libStorage client to direct its
  # requests to the given service by default. It is not used by the server.
  service: s3fs
  server:
    services:
      s3fs:
        driver: s3fs
        s3fs:
          region:           ap-northeast-1
          accessKey:        XXXXX
          secretKey:        XXXXX
          disablePathStyle: false

rexray:
  loglevel: debug
  storageDrivers:
  - s3fs

s3fs:
  cmd:              s3fs
  options:
  - use_cache=true
  - allow_other
  - use_cache=/tmp
  region:           ap-northeast-1
  accessKey:        XXXXX
  secretKey:        XXXXX

あ、loglevelは動くの確認したら消そうね。設定の意味についてはドキュメントに書かれている。

s3fsのaccessKey/SecretKeyが二か所に書かれてて馬鹿っぽいなと思うかもしれんが、最初のほうのがlibstoragedにわたる内容、後者のがクライアント用の設定。なんでこうなってんのかは知らん。EMCに聞け。省略できるのかどうかもしらん。Requiredって書いてあるからたぶん無理。

s3fs:のoptionsにはマウント時に引き渡すパラメータを書く。みりゃわかるだろう。

さて、これで準備は整った。rexray startでもsystemctl start rexrayでも好きにするがいい。

これでrexray起動。バックエンドにs3ストレージをs3fs経由で制御するラッパーだ。
rexray volume create rexrayvol
ボリュームの作成。–sizeオプションはs3なんで意味がない。最後のrexrayvolとかはバケット名として作成される。
#どうでもいいけど、rexrayvolってEMCの記事で使ってる名前なんだけど、当たり前のようにs3に作れてしまったのですが、まさか東京リージョンででs3fsのrexray動かした一番乗りとかいうことないよな。みんなきちんと消してるだけだよな? 僕もあとで消すつもりではあるけど。

次。これのマウント。
rexray volume mount rexrayvol
ストレージの切り出しならデバイスなのでattachを使うが、S3はマウントだね。
これで、
/var/lib/libstorage/volumes/rexrayvol/
にマウントされてる。

あとはまあ下にディレクトリ切るなりなんなりすればいいけど、設定書かずにコマンドだけで成立するし、インストールと設定終わったとこでAMI化しておけばよいかなと。
あとは永続ストレージコンテナ作って、そいつにマウントボリュームをマウントさせれば、あとはdockerの–linkの世界。

ストレージコンテナにさえつながれば、だれからでも同じストレージが見れる。実行ホストですべて同様にrexrayが起動していればストレージコンテナがホストダウンで移動させたとしても、保持できる。もちろん、やってることはコレただNFSのマウントやS3のマウントを全台あらかじめやっときましょう、てことに過ぎないんだけど、create,mount,attachが任意にコマンドレベルで起こせる、ってのは大事な事。

いやまあsed/awkしてrestartかけてつなぐなりautofsにでも書くなりしろよとか言われたらぐうの音も出ないんだけどwwwwww
そもバケット作るだけならawscliで済むしね。

rexrayを用いる意味は、複数のバックエンドストレージエンジンが使われ始めてからだ。

s3もNFSも使うしec2上のEBSも使うし、オンプレのEMCやらVMAXからも切り出すし、iSCSIでおかしなとこからも持ってくるし。みたいな勢いの時に、ストレージを切り替えやすい。
それぞれ別のコマンドで別の操作で別の設定で。

みたいなことが原則ない。コマンドの差異をすべてlibstoragedに吸収させているからだ。

一応オーケストレーションともお仕事できるみたいだけど、ひとまずストレージの抽象化、でした。まあこっから先はインフラ屋の思想に左右されるとこだから、使い方は自分で考えるべきではあるよね。

ストレージの差異を気にせず同じ手順で切り出せる、ってのはある意味非常に助かる気がするんだけどね。docker createからも作れるらしいけどw

#あ、ちなみにここに書かれてるdocker plugin installが何をしているのかいまだにわからないんだけど、dockerのネイティブストレージエンジンとしてrexrayを呼ぶため、ってことなのかなー?

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です