これは、 StorjのプリンシパルソフトウェアエンジニアであるMarton Elekによって書かれたゲスト投稿です。
この2部構成のシリーズの パート1 では、Web3とDockerの共通部分を概念レベルで説明しました。 この投稿では、手を汚して、分散型ストレージを含む実際的な例を確認します。
Web3プロジェクトをDockerと統合する方法を見たいと思います。 最初に、2つのオプションから選択する必要があります。
- Dockerを使用して、Web3アプリケーションをコンテナ化できます。 コンテナ内でIPFSデーモンまたはイーサリアムノードを起動することもできます。 Dockerは、コンテナ内でほとんど何でも実行できるため、インフラストラクチャレイヤーに似ています。
- 最も興味深いのは、Docker自体をWeb3プロジェクトと統合することです。 これには、Web3を使用して、コンテナを起動したり、コンテナ内で何かを実行したりするときに役立ちます。 この投稿では、この部分に焦点を当てます。
コンテナー エンジンの最も明白な 2 つの統合ポイントは、実行とストレージです。 より成熟した分散型ストレージオプションが現在利用可能であるため、ここでストレージを選択します。 クラウド コンテナー ランタイムの分散型バージョン( ankrなど)にはいくつかの興味深いアプローチがありますが、コンテナ エンジン自体ではなく、Kubernetes などのコンテナー オーケストレーターに代わる可能性が高いです。
分散型ストレージでDockerを使用しましょう。 この例では Storjを使用していますが、すべての例はほとんどすべての分散型クラウドストレージソリューションに適用されます。
Storjは分散型クラウドストレージであり、ノードプロバイダーはデータをホストするために報酬を受け取りますが、メタデータサーバー(暗号化された部分の場所を管理する)はフェデレーションされます(多くの相互運用可能な中央サーバーはストレージプロバイダーと連携できます)。
分散型ストレージでは、ほとんどの場合、カスタムプロトコルを使用する必要があることに注意してください。 従来のHTTPアップロードは、1つのクライアントと1つのサーバー間の接続です。 分散化では、複数のサーバーにデータをアップロードする必要があります。
私たちの目標は単純です:中央のDockerレジストリの代わりに分散型ストレージでコマンド docker pull を使用し docker push たいと考えています。最新の DockerCon プレゼンテーションでは、複数のアプローチを特定しました。
- Dockerとコンテナを変更して、さまざまなストレージオプションをネイティブにサポートできます
- 分散型ストレージから魔法のように画像をダウンロードし、コンテナエンジンの保存場所に保持するツールを提供できます(もちろん、正しい形式で)
- 使い慣れたDockerレジストリのHTTPリクエストを分散型クラウドに固有のプロトコルに変換するサービスを実行できます
- これはユーザーが自分で管理できます。
- これは、マネージド サービスにすることもできます。
ネイティブサポートの活用
理想的な解決策は、Docker(および/または基盤となるコンテナランタイム)を拡張して、さまざまなストレージオプションをサポートすることだと思います。 しかし、これは間違いなくより大きな課題です。 技術的には、すべてのサービスを変更することは可能ですが、大規模な採用と大規模なユーザーベースは、大規模な変更には慎重な計画が必要であることを意味します。
現時点では、特別なプッシュ ターゲットまたはプル ターゲットを使用するように Docker デーモンを拡張することは容易にはできません。 技術的な詳細と統合の課題に興味がある場合は、 Dockerの拡張に関するプレゼンテーション をご覧ください。 最善の解決策は、 検討中の新しいコンテナプラグインタイプかもしれません。
このアプローチの利点の 1 つは、使いやすさです。 ユーザーは、一般的なプッシュ コマンドまたはプル コマンドを利用できます。 ただし、ホストに基づいて、コンテナレイヤーを分散型ストレージに送信できます。
ツールベースのプッシュとプルの使用
別のオプションは、リモート分散型ストレージを直接使用してコンテナエンジンのストレージディレクトリに保存できる外部ツールを使用して画像をアップロードまたはダウンロードすることです。
このアプローチの一例 (ただし、集中型ストレージを使用) は、 AWS ECR コンテナリゾルバー プロジェクトです。 カスタムソースを使用してイメージをプルおよびプッシュできるCLIツールを提供します。 また、それらをcontainerdデーモンのコンテナイメージとして保存します。
残念ながら、このアプローチにはいくつかの強い制限もあります。
- Kubernetes のようなコンテナー オーケストレーターでは、イメージのプルやプッシュ以外のカスタム CLI コマンドを実行する準備ができていないため、動作しませんでした。
- コンテナ固有です。 ストレージが異なるDockerデーモンは、それを直接使用できませんでした。
- ユーザーは異なるCLIツールを必要とするため、使いやすさが低下します。
ユーザー・マネージャー・ゲートウェイの使用
分散型ストレージに直接プッシュまたはプルできない場合は、Dockerレジストリに似たサービスを作成し、内部でメッシュ client.ut し、分散型ストレージのネイティブプロトコルを使用してデータをアップロードできます。
これはありがたいことにうまく機能し、 標準のDockerレジストリ実装 はすでにさまざまなストレージオプションと互換性があります。
Storjには、テストイメージに内部で使用する 実装がすでにあります 。 ただし、サブコマンドは、 nerdctl ipfs このアプローチの別の良い例です(IPFSからコンテナにアクセスするためにローカルレジストリを開始します)。
ここでも問題があります。
- ユーザーは、各ホストでゲートウェイを実行する必要があります。 これは、Kubernetes や他のオーケストレーターと一緒に苦痛になる可能性があります。
- 実装は、ネイティブのアップロードまたはダウンロードと比較して、より複雑で困難な場合があります。
ホスト型ゲートウェイの使用
少し簡単にするために、ゲートウェイのホストバージョンを提供できます。 たとえば、Storj は、ホスト型 (またはセルフホスト型) の S3 互換 HTTP ゲートウェイを介して S3 と完全に互換性があります。 この方法では、ユーザーには次の 3 つのオプションがあります。
- 完全なエンドツーエンド暗号化とすべての機能を備えた分散型ストレージのネイティブプロトコルを使用する
- 便利なゲートウェイサービスを使用し、ホスト型ゲートウェイのオペレーターを信頼してください。
- ゲートウェイを単独で実行する
各オプションは受け入れられますが、完璧なソリューションはまだ存在しません。
ドッカー拡張機能の使用
ローカルゲートウェイを使用する際の最大の懸念事項の1つは、使いやすさでした。 ローカルレジストリは、イメージを分散型ストレージにプッシュするのに役立ちますが、追加の技術的作業(コンテナの構成と実行など)が必要です。
これは、Docker拡張機能が私たちを助けることができるところです。 拡張機能 は、Docker Desktop の新機能です。 Dockerダッシュボードからインストールでき、Dockerデスクトップ内の新しい画面、メニュー項目、オプションなどの追加機能を提供できます。 これらは拡張機能マーケットプレイス内で見つけることができます。
そして、これはまさに私たちが必要としているものです! 優れたUIにより、すべてのユーザーがWeb3統合にアクセスしやすくなります。
Docker 拡張機能は Marketplace 内で簡単に見つけることができ、手動で追加することもできます (通常は開発用)。
Storj では、Docker Desktop 用の拡張機能を開発することで、より優れたユーザー エクスペリエンスの実験を開始しました。 まだ 開発中 であり、現在マーケットプレイスには提供されていませんが、これまでのフィードバックにより、ほぼすべての利用可能な統合オプションで最大の懸念事項であった使いやすさを大幅に向上させることができると確信しています。
拡張機能自体はDockerコンテナであるため、開発エクスペリエンスが非常にスムーズで簡単になります。 拡張機能は、コンテナー内のメタデータ ファイルと静的な HTML/JS ファイルなどの単純なものにすることができます。 バックエンドなしで Docker デーモンの状態を操作する特別な JavaScript API があります。
専用のバックエンドを使用することもできます。 拡張機能の JavaScript 部分は、マウントされたソケットを介してコンテナー化されたバックエンドと通信できます。
新しい docker extension コマンドは、拡張機能をすばやく管理するのに役立ちます(例として、Docker Desktop 自体の Web 開発者ツール バーを表示する特別な docker extension dev debug サブコマンドがあります)。
提供されている開発者ツールのおかげで、課題はDockerデスクトップ拡張機能を作成することではなく、UIとUXのバランスをとることです。
概要
前回の投稿で説明したように、Web3はテクノロジー(ブロックチェーンやNFTなど)ではなく、ユーザーの要件によって定義する必要があります。Web3プロジェクトは、プライバシー、データ制御、セキュリティなどに関するユーザーの懸念に対処する必要があります。 また、親しみやすく使いやすいものでなければなりません。
ユーザビリティはコンテナの基本原則であり、Dockerが非常に人気を博した理由の1つです。 Web3プロジェクトのユーザーが必要なものを簡単に提供できるようにするには、より多くの統合ポイントと拡張ポイントが必要です。 Docker拡張機能は、優れた統合と優れた使いやすさを組み合わせるための非常に強力な方法も提供します。
Docker 用の Storj 拡張機能 (まだ開発中) をお試しください。コメントやフィードバックは GitHub 経由でお寄せください。