AOS 4.7上のNutanixのDockerボリュームプラグイン

Nutanixの7月のリリースでAcropolis Container Servicesと呼ばれる機能があり、その最初のアプリケーションは、NutanixクラスターのDockerインフラストラクチャのサポートであり、独自の無料AHVハイパーバイザー（Acropolis Hypervisor、フォーク、KVMの大幅な変更） ）

Dockerについては説明しませんが、Habréには良い記事があります。 また、Nutanixがコンテナ仮想化に携わった理由は、この記事を書いているときにGoogleトレンドで書いた1つの写真で語られるよりも、1000語よりも優れています。







しかし、なぜコンテナとデータボリュームの特別なサポートとDockerとの統合が必要なのでしょうか？ これは、既に実稼働環境でDockerを実装しようとした人には明らかです。



事実は、数日間の実験と分解の後、Test / Devで機能し、本格的なプロダクションに移植すると非常に気まぐれになります。 そして何より、これはステートレスデータコンテナの問題です。



Dockerを紹介し、「戦闘中」のコンテナ仮想化の実用化を考えている新参者にとって、Docker（およびDockerの第一人者）に対する多くの疑問がすぐに生じます。

• コンテナを使用するときにデータの永続性を確保する方法は？
• すべてのコンテナのログを書き込む場所は？
• Dockerイメージを何百台ものマシンにデプロイする方法は？
• これらのマシンへの別のプッシュが失敗した場合、迅速にロールバックする方法は？
• コンテナでの自動ビルドとテストはどうですか？
• コンテナ間の相互運用性を確保する方法は？
• コンテナでアプリケーションメトリックを収集する方法

...そして他にも多くの質問 。

しかし、最も重要なことの1つは、コンテナー内のデータストレージの永続性です。



ほとんどの「仮想マシン」にすでに馴染みのあるものとは異なり、コンテナは一時的なオブジェクトであり、それに関連するストレージ機能でもあります。 Dockerコンテナーをリロードすると、以前に実行されていたコンテナーで変更されたすべてのデータが失われます。

これがなぜそうなのかは、Dockerアーキテクチャの設計方法に関連しています。 これは、最初のPaaSプロバイダーの1つであるHerokuで最初に登場した開発パターンである、いわゆる「12ファクター」に基づいています。 このスキームは、アプリケーションの状態がアプリケーション自体とは別のストレージにあることを宣言しています。 これは、本質的にステートレスであるため、状態を失う問題のないフロントエンドアプリケーションに適していますが、それ以外のアプリケーションには深刻な問題があります。 アプリケーションログ、Webサーバーキャッシュ、またはSSHキーはどうですか？

異なるコンテナ間、またはホストとコンテナ間でデータを共有する方法は？



通常、このような場合はすべて、ホスト上にあるサードパーティのコンテナにマウントされたディスクボリュームを使用するのが一般的です。 ただし、この場合、コンテナーはホストの動作に依存するようになり、ホストの損失はコンテナーでそれを使用するすべてのアプリケーションのこのホストからマウントされたボリュームのデータ損失を自動的に意味するため、単一障害点が潜在的に作成されます。 コンテナの再起動は問題ありませんが、ホスト上のデータボリュームは失われます。



コンテナのディスクI / Oパフォーマンスが非常に低いことも覚えておく必要があります。そのため、Dockerは高性能アプリケーションにボリュームを使用することをお勧めします。

デフォルトでは、コンテナはUnionFSを使用してデータの書き込み時コピー動作を実装します。これにより、コンテナの変更にgitのような動作を使用できます。 ただし、コンテナに関係なく、アプリケーションの最大ディスクI / Oパフォーマンスとデータストレージの永続性を取得する必要がある場合は、Dockerボリュームを使用する必要があります。



バージョン1.8から、ボリュームプラグインの概念がDockerに登場し、その助けを借りてDockerとストレージAPI間の相互作用を実装できます。 これは、Dockerとリポジトリ間の統合を整理する最初の試みでしたが、すべてが非常にSpartanで実装されました。 バージョン1.9以降、いわゆる名前付きボリュームが登場しました。これにより、ボリュームをコンテナ内から管理するのではなく、個別の名前付きエンティティとして対話できるようになりました。



これらの新機能を使用して、NutanixはDockerインフラストラクチャのプラットフォームとして、そして一般的には戦闘生産における「コンテナ仮想化」としてNutanixシステムをより便利に使用できるツールを作成しました。



このために作成されました：



Docker Machine Driverは、ローカルコンピューター、クラウドプロバイダー、または独自のデータセンター内にDockerホストを作成できるプロビジョニングツールです。 サーバーを作成し、Docker Engineをインストールし、Dockerクライアントがサーバーと連携するように構成します。 Docker Machineのサポートにより、エンドユーザー（管理者と開発者の両方）がAHV VMでDockerエンジンをプロビジョニングし、docker-machine cliコマンドでVMを管理できます。



Dockerボリュームプラグイン -Docker Engine展開ツールを外部ストレージシステムと統合し、これらのアプリケーションの永続的なボリュームを作成できます。



さて、ここで以下に言及して使用するので：

Docker Datacenter（UCP）は、ユーザーがボリュームプラグインを使用して永続ストレージとしてNutanix DSFを使用できるようにするDockerの管理ソリューションです。

Acropolis OS 4.7では、コンテナ管理はこれまでCLIを介してのみ実装されていましたが、Asterixリリース（4.8）ではPrism GUIに統合されます。



これで、Dockerコンテナおよびホストとは別に配置されたコンテナに、アクセスしやすく便利に取り付けられた保管施設を提供できるようになりました。



Acrpolis OS 4.7以降、これらのDockerメカニズムのDSF（以前はNDFSと呼ばれていた分散クラスターファイルシステムである分散ストレージファブリック）サポートが追加されました。



Nutanix Acropolis DSF VolumeドライバーはGoで記述されており、Docker Volume拡張として機能します。 中間のSidekickコンテナとして機能します。 Nutanix Acropolis DSF Volumeプラグインは、iSCSIボリュームグループメカニズムを介してDSFへのリンクを転送します。これにより、コンテナーからハイパーバイザーをバイパスしてアクセスオーバーヘッドを排除するDSFへのアクセスが提供されます。







この結果、コンテナまたはホストを失っても、ボリュームデータへのアクセスは失われません。 さらに、コンテナはデータの局所性の原則に従っているため、コンテナを移動すると、その後のデータもNutanixクラスタに沿って移動します。

上記のすべては、サードパーティのソリューションを必要としない、プラットフォーム上の完全にネイティブな実装です。



NutanixプラットフォームとDocker用のAcropolis DSF VolumeプラグインおよびDockerマシンドライバーを使用してDockerインフラストラクチャを展開すると、NutanixプラットフォームとDocker APIのネイティブ統合が得られ、透過的なティアリング、重複排除、圧縮、スナップショットなどのNutanixストレージのデータストレージを最大限に活用できますデータ、レプリケーション、同期および非同期の両方。 アプリケーションに最高のパフォーマンスのディスクI / Oを提供します。

最後になりましたが、これらはすべてインストールされ、オンラインテクニカルサポートサポートを含め、迅速かつ簡単に機能します。



10分間の短いスクリーンキャスト形式での動作を以下に示します（Youtube設定でHDを有効にすることを忘れないでください！）：







ところで、Nutanix CEで既にライブで試してみることができます。