CIFSをVPN通して公開するのに、FSxは巨大すぎるし、Storage GatewayもEC2で起動すると結構なコストになるし、かといって内部にアプライアンス起動するのも管理がめんどくさい。
というわけでなんかないかなー…と思って、DockerでプライベートネットワークにSAMBA立てるか。という極めて原始的なところに回帰し、適当なイメージ探してふらついていました。
EFSのマウントセットアップするの、自動化だとめんどくさいんですよね。手だと一瞬なんだけど、コンテナの起動、停止でマウント外したり上げたりしないといけないとか考え始めると、結局でっかいEFSターゲットを確保して、その中でディレクトリ別で切り分けて、とか。
そんなことを考えながらふらふらと調べものをしていたら。
…え、VolumeDriverとVolumePlugin？ 使えるの？ いつの間に！
いつの間にかECSでVolumePluginが使えるようになっているようです。気が付かなかったなぁ…。Rex-Rayは以前S3ターゲットにして試したけどありゃあ遅くて使い物にならなかったけど、EFSだとどうなのかしら。
VolumeDriverとPluginは、Dockerサーバがボリュームを作成するのに使うドライバで、ローカルストレージをターゲットにしたドライバの他、ネットワークを介したボリュームを作成するドライバとプラグインがあるのですが、Dockerサーバの起動時に設定するモノなのでコンテナコントローラであるECSではあまり期待していませんでした。
こいつがあればコンテナの要求に応じてDockerサーバがボリュームを用意してくれます。
早速使っていきましょう。
まず、ボリュームプラグインを組み込まないといけませんね。EFSをターゲットにするので、Netshare Pluginでいいかな。
とりあえず、AMIからの起動時にnfs-utilsを組み込むようにしておく。というかPackerの側ですでに入れてたので、infrabbit-amiだとnfs-utilsは導入済み。
Netshare-pluginをどこで導入するか、ですね。Packerで入れるかユーザーデータで入れるかですが、制御しやすいのはPackerですので、こちらでAnsibleさんに入れていただくことにします。
バイナリだとwget、そして最近どこでも流行りのgo製プログラムなので、バイナリ取得だとlatestを取ってくるのもどうか、って感じになりますけどbuildするならちょっとだけ安心できます。Packer走らせて失敗したらビルド失敗ですし、バイナリを突っ込んでたら停止>起動なんかでエラー起こしてホストクラスタが起動しない、というのは避けたいですし、AMIに含まれていた方が安心できます。
サービススタートもAnsibleさんにやって置いていただくとして、Packerをがすっとビルドします。
あとは使うだけです。コンテナのほうのタスク定義にボリュームプラグインの設定を追加して、EFSのターゲットをセットアップします。
EFSはネイティブにサポートされているので、ターゲットとディレクトリを-vオプションに引き渡すだけですね。
あとはプライベート領域に立ち上げたSambaコンテナにEFSをマウントさせて、そこをexportするだけでよさそうですね。
あとはお値段ですが、$0.36/GB(tokyo)だから1TB使ったら1000倍で4万円。
うーん、なんでもお気軽に置くってわけにはいかないですね。
Kubernetes使えば解消するんだけど、このレベルのことにK8s持ちだすのか？とか思うとなんだかなぁ…。
結局、オンプレ的に固定的なサービスとクラウド系は微妙にかみ合わないところがあったりもしますね。でも障害とか考えるとこういうサービスもアウトソースしたくなりますよね…。
