Docker Compose v2のリリースに伴い、.36。0、このたび、強力な新機能である プロバイダーサービスをご紹介します。この拡張ポイントにより、Docker Compose は、使い慣れた Compose ファイルをワークフローの中心に保ちながら、コンテナだけでなく、あらゆる種類の外部システムとも対話できるようになります。
このブログ投稿では、プロバイダ サービスとは何か、デベロッパーがプロバイダ サービスを使用してワークフローを効率化する方法、プロバイダ システムがバックグラウンドでどのように機能するか、独自のプロバイダを構築してプラットフォームのニーズに合わせて Compose を拡張する方法について説明します。
プロバイダーサービスがゲームチェンジャーである理由
Docker Compose は、マルチコンテナアプリケーションをシンプルで宣言的な方法でオーケストレーションするために、開発者の間で長い間愛用されてきました。しかし、開発環境が複雑になるにつれて、コンテナ以外の依存関係を統合する必要性が共通の課題となっています。多くの場合、アプリケーションはマネージド データベース、SaaS API、クラウドでホストされるメッセージ キュー、VPN トンネル、LLM 推論エンジンに依存しており、これらはすべて従来 Compose の範囲外に置かれていました。
開発者は、これらの外部コンポーネントを管理するためにシェルスクリプト、Makefile、またはラッパーCLIに頼らざるを得なかったため、開発者のエクスペリエンスが断片化され、新しい貢献者のオンボーディングやチーム間での一貫したワークフローの維持が困難になっていました。
プロバイダーサービスはそれを変えます。ネイティブ拡張ポイントを Compose に導入することで、デベロッパーは Compose で外部リソースを直接定義および管理できるようになりました compose.yaml.Compose は、そのライフサイクルをプロバイダー バイナリに委任し、独自のサービス ライフサイクルの一部としてプロバイダー バイナリと調整します。
これにより、Docker Compose は、ローカル環境からハイブリッドまたはリモートのセットアップまで、フルスタックでプラットフォームを意識した開発のためのより完全なソリューションになります。
Compose ファイルでプロバイダー サービスを使用する
プロバイダ サービスは、他の Compose サービスと同様に宣言されますが、imageを指定する代わりに、typeとオプションで一部のoptionsを含むproviderを指定します。typeは、Compose プロバイダ仕様を実装する $PATH で使用可能なバイナリの名前に対応している必要があります。
例として、Kubernetesトラフィックをローカルサービスにルーティングしてライブクラウドデバッグを行う Telepresenceプロバイダープラグインを使用します。これは、実際のクラスターに統合したときにローカルサービスがどのように動作するかをテストする場合に特に便利です。
この設定では、 docker compose upを実行すると、Compose は compose-telepresence プラグイン バイナリを呼び出します。プラグインは、次のアクションを実行します。
アップアクション:
- Telepresence トラフィック マネージャーが Kubernetes クラスターにインストールされているかどうかを確認し、必要に応じてインストールします。
- インターセプトを確立して、指定した Kubernetes サービスからローカル サービスにトラフィックを再ルーティングします。
ダウンアクション:
- 以前に設定したインターセプトを削除します。
- クラスタから Telepresence トラフィック マネージャをアンインストールします。
- アクティブな Telepresence セッションを終了します。
⚠️ options フィールドの構造と内容は、各プロバイダーに固有です。プラグインの作成者は、必要なキーと値を定義して文書化する必要があります。
Compose ファイルでプロバイダ サービスを適切に構成する方法がわからない場合は、Compose Language Server(LSP)がインラインの提案と検証を段階的にガイドします。
その他の使用例とサポートされているワークフローについては、公式ドキュメントを参照してください https://docs.docker.com/compose/how-tos/provider-services/
プロバイダーサービスの舞台裏の仕組み
内部的には、Compose が provider キーを使用するサービスを検出すると、ユーザーの $PATH でプロバイダ type の名前(例:docker-model cli plugin または compose-telepresence) を使用します。その後、Compose はバイナリを生成し、サービス options をフラグとして渡すため、プロバイダーはコマンドライン引数を介して必要なすべての構成を受け取ることができます。
バイナリは、stdin で JSON 形式の要求に応答し、stdout で構造化された JSON 応答を返す必要があります。
インタラクションを示す図を次に示します。
Compose との通信
Compose は、すべての options 属性をフラグとして変換することにより、必要なすべての情報をプロバイダー バイナリに送信します。また、プロジェクト名とサービス名も渡します。compose-telepresenceプロバイダーの例を見ると、upコマンドでComposeは次のコマンドを実行します。
$ compose-telepresence compose --project-name my-project up --name api --port 5732:api-80 --namespace avatars --service api dev-api
一方、プロバイダはランタイム メッセージを Compose に送信することもできます。
info:ステータスの更新を報告します。Compose のログに表示されます。error:エラーを報告します。失敗の理由として表示されます。setenv:環境変数を依存サービスに公開します。debug:デバッグ メッセージは、-verboseを使用して Compose を実行している場合にのみ表示されます。
この柔軟なプロトコルにより、新しいタイプの追加や、豊富なプロバイダー統合の構築が容易になります。
詳細な構造と例については、 公式のプロトコル仕様 を参照してください。
独自のプロバイダープラグインの構築
プロバイダー サービスの真の力は、その拡張性にあります。プロトコルに準拠している限り、任意の言語で独自のプラグインを作成できます。
一般的なプロバイダー バイナリは、up サブコマンドと down サブコマンドを使用して compose コマンドを処理するロジックを実装します。
compose-telepresence-plugin のソースコードは良い出発点になります。このプラグインは Go で実装され、Telepresence CLI をラップして、ローカル開発コンテナとリモート Kubernetes サービスをブリッジします。
以下は、その up 実装の抜粋です。
このメソッドは、 docker compose up が実行されるとトリガーされ、受信したオプションに基づいて Telepresence CLI を呼び出してサービスを開始します。
独自のプロバイダーを構築するには:
- 拡張プロトコルの仕様全文を読む
- すべてのオプションをフラグとして解析し、プロバイダーが必要とする全体の構成を収集します
- /stdout に対する予期される JSON 応答処理を実装します
- 実装フェーズでは、できるだけ多くの詳細を含めるために、
debugメッセージを追加することを忘れないでください。 - バイナリをコンパイルし、それをあなたの
$PATH - を使用して Compose ファイルで参照します
provider.type
サービスエミュレータからリモートクラウドサービスのスターターまで、何でも構築できます。Compose は、必要に応じてバイナリを自動的に呼び出します。
次は何ですか?
プロバイダー サービスは進化し続け、将来の機能強化は、ユーザーからの実際のフィードバックに基づいて、プロバイダー サービスが最も有用で影響力のある方向に成長するように導きます。
将来的には、Compose がコンテナ、ローカル ツール、リモート サービス、AI ランタイムなどのフルスタック開発環境の宣言型ハブとして機能する未来を思い描いています。
クラウドでホストされるデータベースに接続する場合でも、トンネルを起動する場合でも、機械学習推論をオーケストレーションする場合でも、Compose プロバイダ サービスを使用すると、ラッパーやハッキングなしで開発環境をネイティブに拡張できます。
どのようなプロバイダーを構築したいか、または追加してほしいかをお知らせください。コミュニティがこれをさらに進める方法を見るのが待ちきれません。
ご期待ください、楽しいコーディング!