Subtreeがアプリケーション状態のキャプチャ、管理、共有を行うGitライクなCLIの“Dotmesh”をリリース

Subtreeは、コンテナフレンドリなアプリケーション状態のスナップショットツールであるDotmeshをリリースした。取得したデータを操作したり、共有したりするためのgit風CLIを備えている。おもなユースケースとしては、クラウドネイティブなマイクロサービスベースのアプリケーションの状態をキャプチャし、管理し、共有することによる、QA環境や運用環境で発生する問題状況のデバッグや探索の支援が考えられる。

Dotmeshはデータベースやファイルシステム状態のためのスナップショットツールで、“アプリケーションの状態をキャプチャ、管理、共有するgit風のCLI”を提供する。アプリケーションの状態は“datadot”としてキャプチャされ、共通の“dothub”リポジトリに保管し、共有することが可能だ。Dotmeshは複数のデータベース状態をキャプチャし、それぞれを“subdot”として、単一のアトミックなコミットに含めることができる。この機能はデータストアやキャッシュ、キューなど、複数のコンポーネントに状態が分散するマイクロサービスベースのアプリケーションを対象として、その(ある特定の時点での)状態をキャプチャする場合に有効だ。

ドキュメントには簡単なサンプルと、DotmeshでバックアップしたPostgreSQLコンテナを起動する方法が示されている。

docker run -d --volume-driver dm -v myapp:/var/lib/postgresql/data --name postgres postgres:9.6.6

この例では“myapp”というdatadotを生成し、その中にデフォルトマスタブランチ用の書き込み可能なファイルシステムを作成して、マスタブランチの書き込み可能なファイルシステムをpostrgresコンテナ内の/var/lib/postgresql/dataにマウントした上で、PostgreSQLコンテナを起動する。datadotをコミットするには、dm commit -m “empty state”を実行する。 これにより、現在のdotで有効なブランチ上のファイルシステムの状態に対する、実行時点でのスナップショットが作られる。

PostgreSQLデータベースにデータを追加することも可能で、この場合には新たなコミットが作成される。dm logを実行してコミット内容を確認したり、dm reset --hard HEAD^で最初のコミットにロールバックすることも可能だ(HEAD^という構文はgitを使用しているエンジニアには馴染みのもので、“現在のブランチの最終コミットのひとつ前のコミット”という意味である)。コミットIDを指定したロールバックやファーストフォワードを行うこともできる。データを“dothub” Dotmeshリポジトリにプッシュして一元管理することや(現在のDothub SaaSサービスを使用するには登録が必要)、他のdotからcloneやpullすることもできる。

マイクロサービスベースのアプリケーションでは、複数のデータベースやキャッシュ、キューといったように、複数のステートフルなコンポーネント(単一サービスの場合もある)を持っていることが少なくない。それらすべての状態を単一でアトミック、かつ一貫性のあるコミットで、ひとつのdatadotにキャプチャすることが可能である。subdotは、ファイルシステムを分割して個々のコンテナが独自の部分を使用できるという意味で、マスタブランチの書き込み可能なファイルシステムの“パーティション”の一種と考えることができる。datadotへのコミットとブランチは特定のsubdotではなく、datadot全体に適用される。これはつまり、datadotのコミットは個々のデータサービスではなく、アプリケーション全体の状態のスナップショットを表しているということだ。

DotmeshはdatadotをZFSに格納する。ZFSはファイルシステムと論理ボリュームの組み合わせで、元々はSun Microsystemが設計したものだ。ZFSはデータ破損からの保護、大記憶容量のサポート、効率的なデータ圧縮、ファイルシステムとボリューム管理の概念の統合、スナップショット、コピーオンライト方式のクローン、といった機能を備えている。Dockerを始めとする多くのLinuxコンテナ実装は、ZFSボリュームの直接マウントをサポートしている -- ZFS on Linux (ZoL)は完成度の高い実装だ -- が、現時点では“Linux上のZFSに豊富な経験を”持っていない限り、Dockerストレージドライバを運用環境で使うことは推奨されていない。Dotmeshが目指すのは、それらのツーリングに必要な専門的知識を提供することだ。

Dotmeshのノードはクラスタ編成されている。そのノードをクラスタ内にまとめ上げる“メッシュ”がetcdだ。各ノードでもDotmeshサーバが実行される -- 現在のDotmeshの資料には、DotmeshサーバをDockerや通常のKubernetesクラスタ、Google Container Engine (GKE)クラスタにインストールする手順の説明がある。クラスタ内のすべてのノードは、同じDotのリストを参照して操作する。Dotmeshはdatadotの基礎となっている物理データを、必要に応じてクラスタのノード間で移動する。

ブランチ上のすべてのコミットは、すべてのノードに自動的に複製される。各ブランチのsubdotで複製されないのは、コミットされていない“ダーティ”な状態のもののみだ -- この状態は、ブランチの“マスタノード”と呼ばれる単一のノードに格納される。ダーティ状態をコミットすることにより、そのデータが複数のノードに複製されるようになる。

クラスタ内のサーバプロセス間の通信には２つの手段がある - ポート43280を使って通信するetcdの状態共有と、ポート6969経由のHTTPだ。ドキュメントには、ポート6969を介したHTTP通信は暗号化など、あらゆる意味において攻撃者からの保護が施されていない、とある。したがって、これらのポートはクラスタ内で閉じられていなければならず、信頼できないネットワークにまでクラスタを拡張する場合はVPNを用いる必要がある。

DotmeshのFAQにはPortworxやRookなど、他のコンテナやクラウドネイティブコンテナとの違いに関する情報が含まれている。

PortworxとDotmeshは実際に、さまざまな問題に取り組んでいます。Portworxは同期レプリケーションされたブロックストレージを使うことで、運用レベルのコンテナ用のストレージ提供に取り組んでいると思いますが、採用の可否は運用者の判断によるものとなります。これは素晴らしいことで、特にEBSやGCE PDといったテクノロジが利用できない(あるいは技術が不足している)多くのユーザにとっては、必要不可欠なコンポーネントです。

FAQにはDotmesh開発チームの方針として、同期レプリケーションされたブロックストレージシステムを新たに開発のではなく、“必要なデータをソフトウェア開発ライフサイクル全体を通じて適切な場所に配置するという、もっと広範かつワークフロー寄りの問題”に取り組む姿勢が示されている。チームのビジョンは、“アプリケーション全体のスナップショットのように、アプリケーション状態のキャプチャ、管理、共有”を可能にすることにある。中でも特に、状態管理に多言語永続性を取り入れた、マイクロサービスベースのアプリケーションを開発するワークフローを重視している。

Dotmeshの詳細については、プロジェクトのWebサイトやGitHubリポジトリを参照してほしい。インタラクティブなKatacodaチュートリアルでツーリングを試用することも可能だ。