Dockerで外部ストレージを使った永続ストレージを実現する方法

外部ストレージのデータをDockerのコンテナから利用したいこともある。外部ストレージ利用には賛否両論あるが、それでも利用したい場合はどうすればよいのか。

公開 2018年03月19日 08時00分

著者

Chris Evans

[Computer Weekly]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　前編（Computer Weekly日本語版　2月21日号掲載）では、Dockerで永続ストレージを実現するための方法と、その選択のために検討すべき要件について解説した。

　後編では、外部ストレージを使う方法について検討する。

Computer Weekly日本語版　3月7日号無料ダウンロード

本記事は、プレミアムコンテンツ「 Computer Weekly日本語版　3月7日号 」（PDF）掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

Computer Weekly日本語版　3月7日号：逆に考えるんだ「GDPRはチャンスだ」と

なお、同コンテンツのEPUB版およびKindle（MOBI）版も提供しています。

Dockerボリュームのプラグイン

　外部のストレージアレイに格納されているデータを使いたい場合はどうなるのか。

　共有ストレージを使用すると、ホストで障害が発生しても、それを切り抜けられるようになる。コンテナのコンテキストで、共有ストレージを使用する場合は多少の作業が必要だ。この技法を使うには、共有ストレージプラットフォームの開発をどこから着手すべきか、理解しておかなければならないからだ。

　従来のSAN（ストレージエリアネットワーク）は、多数の物理サーバに分散したストレージを集約する必要性から考案された仕組みだった。1つに集約することで、管理、セキュリティ、保守、効率性が向上した。例えば、共有アレイの物理LUNまたはボリュームは、ホスト内の物理アダプターにマッピングされ、マスクされる。

　仮想化への移行に伴い、ストレージはハイパーバイザーにマッピングされ、LUNやボリュームはハイパーバイザーで分割されるようになった。例えば物理LUNは、「VMware vSphere」ではデータストアとなる。通常、そのデータストア内で各仮想マシンのディスクはVMDKファイルだ。NASのファイル共有では、こうしたディレクトリ内にVMディレクトリとVMDKファイルを格納するようになるだろう。

　コンテナの観点から見ると、物理ホストにマッピングされたストレージは、ブロックデバイスのように見える。つまり、そのストレージはファイルシステムでフォーマットしなければならない。このファイルシステムをコンテナにマウントすることで、永続的なストレージが提供される。

　しかしこうした一連の手続きはどう見ても扱いにくい。そのため、プロセスをより効果的に管理するためにDockerはボリュームプラグインを導入した。サプライヤーは、Dockerの仕様に対応するプラグインソフトウェアを開発している。その仕様とは、LUNまたはボリュームの作成プロセスを自動化し、ホストおよび最終的にはコンテナに正しくマッピングするためのものだ。

外部ストレージに関する賛否両論

　外部ストレージを使用すると、当然ながらレジリエンスと永続性という利点を享受することになる。コンテナを廃棄しても、ボリュームを再接続することができる。ホストを廃止する場合は、LUNまたはボリュームを移動させて、別のホストにマウントすることができる。パフォーマンスは、システムがQoS（Quality of Service）などの機能を提供するLUNレベルで判断することになる。

　セキュリティの実装は、もう少し慎重な対応が必要だ。特定のコンテナホストに外部ボリュームをマッピングすることはできる。ただし、ホストやコンテナのオーケストレーションソフトウェアが提供しているものを除けば、ボリュームをコンテナに割り当てる際にセキュリティを確保できる仕組みは、ストレージには備わっていない。