Kubernetes チャレンジ その2
どうしてもGKE上でKusanagi on Docker動かしたい。シリーズその2。
何かの解決を期待してこのエントリにたどり着いた方、申し訳ございませんがその足でお帰り下さい。田中(゜p゜)の悩みが深まっただけでございます。
前回のエントリの通り、ローカルのKubernetes環境の構築には成功。
しかし本日は一進二退という感じで、むしろ退きました。
既にKusanagiはローカルのDockerにデプロイはできているんですが、何故かどーしてもコレ。
まー、ボリュームのマウントがうまくいってないんだろな、というのは分かりましたが、色々切り分けると、何故かKusanagI on Dockerは、Dockerコンテナをダウンさせても、データが残るという事象に到達。
もはやKubernetes関係ない。
結論からいうと、裏でKusanagiがVolumeマウントしてやがりました。
「docker volume ls」すれば一発なんだろうけど、ああ悲しきかな、田中(゜p゜)は初心者。かなりの時間右往左往してしまいました。
挙句の果に、Docker落とさずにマウントされた実体ファイルを移動してみるという暴挙に居たり、結果がコレ。
まあ普通に壊れますわな。
その後、Dockerの再インストールはなんとか食い止めましたが、Kusanagiさんは再インストール。orz。
で、Kusanagiのボリュームのマッピングはだいたい把握したので、いかにそれをKubernetes用に落とし込むか、というのが課題となりまして。
Webを漁るとやっぱりディスクのマウントというのは課題になるみたいで、Kubernetesでもゴニョゴニョ開発中のこと。嫌な予感するなあ。
そもそもKubernetesのPODつうのは揮発性でかつ複数存在するものであって、書き込みが必要なデータをどっかに置いとかなきゃいけない。
一般的なシステムならDBにおけば解決なんだろうけど、残念ながら田中(゜p゜)が使いたいのはWordpressでおもいきりディスク依存。
レガシーな田中(゜p゜)の知識でも、複数のノードから一つのディスクにアクセスするっつうのは排他制御などの関係からえらく面倒だという認識はある。
結局、可用性も物理考慮しないとだし、ディスクの悩み解決してないし、レガシーなインフラとあまり変わらんやん！
ということで、もう少し頑張りたいと思います。