kubernetesで永続ボリュームをNFSにするぜっていうアレ
2018/06/27
今日は自分用備忘録的なアレ
なんやかんやあって今更ながらkubernetesを使うことになって色々わからないながらいじってたけど、結局解決できなかった
Docker単体やdocker-composeであればvolumeでnameだけ指定して起動すればコンテナの初回起動時に自動的にあれこれしてくれて、そんな名前のボリュームはどこにも見当たらねぇ！ってなった場合はコンテナ内の配置済みファイルを初期ボリュームとして使用してボリュームを作ってくれたのだが、どうもkubernetesはNFSをサポートこそするが初期ボリュームのプロビジョニングはやってくれないという中途半端な状態のようだ。苦手な英語の公式ドキュメントをよくよく読んで調べてストレージドライバとプロビジョニングコンテナを配置しても結局状況は変わらず、自動的にディレクトリの作成までしかしてくれずなんとも言えない感じになった。
結局いくら調べてもNFS使用時のボリュームプロビジョニングはエンジニアがすげー時間と手間暇かけてアレコレする必要が～っていうのしか見つからず根本的解決法はまだ見つかっていない。よくネットで目にするNFSのサーバーとパスを指定しておけばOKだぜ！っていうアレな記事はnginxとかmysql等の永続ボリューム化したいディレクトリの初期値が空っぽだから成立するものばかりだった・・・
configmapも結局ディレクトリ単位だし、ファイルで置くこともできるけど同一パスに複数回のマウントできないから1つしか置けないし結局結構な数の変える必要もないファイルも含めてまとめてマウントするという荒業に今のところ落ち着いた・・・
何かアイデアが湧いたら書き足したり書き直したりしていく
追記っぽいもの
やっぱりこれだ！という画期的な何かは見つからないし誰も作っていないようだ。
手っ取り早く全ファイルをマウントするのはちょっと無駄すぎね？となった場合、entrypointを自作してどうにかすることもできなくはない。コンテナ内に置きたいファイルやらをコンテナ内の/tmpとか適当かつ無いわけ無いだろうっていうようなところにマウントし、自作したentrypointであるべき場所へcpなりmvなりする。いちいち設定ファイル更新するごとにイメージのビルドなんてそれこそ不毛なんでベースのイメージがあるなら手っ取り早くentrypointを作る。その中で必要なファイルの配置だとかを終わらせ、その中で改めて本来のentrypointを叩き起こすというような手順が何も考えずにスパッとできる事じゃないだろうか・・・
entrypoint作ってイメージビルドとかせず、既存イメージでpodを立ち上げ、マウントしたディレクトリにシェル置いて、それを叩くのもあり。ただ訳がわからなくなったりもするので自分で作った部分がentrypointだけだったとしてもイメージにしといたほうがいい場合もよくある。
ただまぁ、設定ファイル的なものならともかく、頻繁に書き換えがあるようなファイルがあるディレクトリは何も考えずボリューム化しておくことをオススメする。適当に入れたモジュールが意味がわからないほどバンバンログ吐く時とかは特に。理由は・・・まぁやってみればわかる。