Kai Davenport氏はLondon Microservice User Group July meetupにおいて、 ClusterHQのコンテナデータボリューム管理ツール Flocker v1.0を使って、Docker Swarmで動く複数のコンテナ間でDockerストレージボリュームを移動させるデモを披露した。
ClusterHQの開発者エバンジェリストであるDavenport氏は、ソフトウェアデザインおよびデプロイメントに対するモノリシックアプローチとマイクロサービスアプローチの比較から話しを始めた。アーキテクチャに対する「フリーサイズ」のアプローチは存在しないが、モノリスを開発するときには注意が必要だと、Davenport氏はいう。たくさんの異なる機能をひとつのアプリケーションに追加するのは簡単であるためだ。
...たくさんの異なる機能を（モノリスに）つぎ込むという考え、それはブラックアンドデッカーのワークベンチのようなものです。あなたが本当に必要なのは、金槌と釘です。好きなように組み合わせることができます。
Davenport氏は、Dockerのようなコンテナ技術は、アプリケーションデプロイメントを破壊するという。（VMと比べて）小さなリソースオーバーヘッド、高速な起動時間、‘Immutable Infrastructure’の実現といったメリットは、特にマイクロサービスベースのアプリケーションにおいて、インフラストラクチャのプロビジョニングとデプロイメントを変革しつつある。
コンテナのオーケストレーションにはたくさんのソリューションが登場している。これには、Docker Swarm、Kubernetes、Mesos/Marathon、CloudFoundryなどが含まれる。ところが、コンテナ内の状態のハンドリングと、クラスタ内の関連ホストマシンを横断したストレージボリュームデータのモビリティは、忘れられがちな問題だ。Davenport氏によると、オープンソースのコンテナデータボリュームマネージャ「Flocker」はそのためのソリューションを提供するという。.
クラスタにわたるコンテナ状態のモビリティの提供に加え、FlockerはDockerボリュームの抽象レイヤとして振舞うことができる。Flockerは現在、Amazon Web ServiceのEBS、OpenStack Cinder、EMCのScaleIOとXtremIO、実験的なZFSストレージバックエンドを使ったローカルストレージなど、複数のブロックベース共有ストレージ実装をサポートしている。（Flockerのドキュメントに詳しいストレージ比較表が含まれている）。Davenport氏によると、Flockerデータボリュームを使うことによって、開発者やオペレータが別のストレージデバイスに切り替えたり、クラウドプラットフォームベンダーを変えたりした場合に必要な追加作業を減らせるという。
Flockerは主要なオーケストレーションツールとのインテグレーションも計画している。Davenport氏はFlockerをDocker Swarmとともに使うデモを見せた。デモの再現手順がClusterHQのGithubアカウントにある。MesosphereのMarathon Apache Mesosスケジューラは「そのまま」Flockerで動かせる。Kubernetesを動かすには（現在リリースされていない）パッチ を必要とする。プロトタイプのFlockerボリュームGUIもデモされた。これはホストマイグレーション前後のコンテナボリュームの位置と状態を表示する。
ミートアップ参加者からの質問に答えて、Davenport氏はFlockerの可能性を高める作業を計画していると述べた。現在はクラスタにひとつのFlocker Control Serviceしかデプロイされないためだ。またDavenport氏はDockerボリュームのパフォーマンスに関する質問に対して、これはDockerストレージドライバに大きく依存しており、Flockerを使うことでボリューム管理プロセスに加わるオーバーヘッドは最小限だろうと述べた。Flockerが大きく関与するのは、コンテナとボリュームの初期化や移動時だけであるためだ。
ClusterHQのブログには、Flockerのv1.0リリースに関する詳細な情報がある。実験的なDockerプラグインシステムのサポートに関する情報は、InfoQの記事を参照してほしい。London Microservice User Group meetupでのKai Davenport氏のトーク「Orchestrating storage for a Docker microservices stack」のビデオは、Skillsmatterのサイトにある。