Docker Compose のシンプルさ (ただ実行する compose up だけ) は、10 年前から開発者のワークフローに不可欠な要素であり、 最初のコミット は Plum と呼ばれていた 2013年に行われました。 その間、機能セットは劇的に成長しましたが、そのエクスペリエンスを維持することは、常に Compose の精神に不可欠です。
この投稿では、他の Git リポジトリからサブプロジェクトをインポートして、Docker Compose でマイクロサービスの無秩序な増加を管理する方法について説明します。
シンプルさの維持
今、おそらくこれまで以上に、そのシンプルさが鍵を握っています。 最新のソフトウェア開発の複雑さは、マイクロサービスやモノリスを使用しているか、クラウドやオンプレミスにデプロイしているか、JavaScript や C で記述しているかに関係なく、否定できません。
Compose は、この「開発のスプロール化」に追いついておらず、より大規模で複雑なプロジェクトに取り組む際に障害になることさえあります。 ますます複雑化するアプリケーションを正確に表現するために Compose を維持するには、独自の専門知識が必要になる場合があり、多くの場合、YAML の構成が古くなったり、makefile タスクが複雑になったりします。
オープンソース プロジェクトである Compose は、ホーム ラボの愛好家から大陸を横断する企業まで、あらゆる人にサービスを提供しており、 すべてのユーザーのために Compose の特徴であるシンプルさを維持するという当社のコミットメントは変わっていません。
Compose ウォッチとインクルードによって柔軟性が向上したことで、プロジェクトは画一的である必要がなくなりました。これで、プロジェクトを Git リポジトリに分割し、必要に応じてサービスをインポートし、その過程で構成をカスタマイズできるようになりました。
アプリケーション アーキテクチャ
仮定のアプリケーションアーキテクチャを見てみましょう。 まず、アプリケーションは 2 つの Git リポジトリに分割されます。
backend— python/flask のバックエンドfrontend— JavaScript/Node.jsのシングルページアプリ(SPA)フロントエンド
フロントエンドでの作業中、開発者は Docker や Compose を使用せずに実行し、ラップトップで直接起動 npm start し、API リクエストを共有ステージング サーバーにプロキシします (バックエンドをローカルで実行するのではなく)。 一方、バックエンドでの作業中、開発者と CI(統合テスト用)は Compose ファイルを共有し、cURL などのコマンドライン ツールを使用してローカルで機能を手動でテストします。
開発者の各グループが最適なワークフロー (フロントエンドのホット リロードを活用するなど) を使用できるようにすると同時に、リポジトリ間でプロジェクト構成を共有するために再利用できる柔軟な構成が必要です。 一見すると、これは解決不可能な状況のように思えます。
フロントエンド
まず、ファイルを次の場所frontendに追加しますcompose.yaml。
services:
frontend:
pull_policy: build
build:
context: .
environment:
BACKEND_HOST: ${BACKEND_HOST:-https://staging.example.com}
ports:
- 8000:8000
手記： Dockerfile がどのようなものか気になる場合は、 このサンプル ページで 、 によって docker init生成されたベスト プラクティスの最新の例を参照してください。
これは素晴らしいスタートです! 実行する docker compose up と、Node.jsフロントエンドがビルドされ、 http://localhost:8000/ でアクセスできるようになります。
環境変数を使用して BACKEND_HOST 、アップストリーム API 要求がプロキシされる場所を制御し、既定で共有ステージング インスタンスにすることができます。
残念ながら、すべてがコンテナー内にあるため、ホット モジュール リロード (HMR) によって提供される優れた開発者エクスペリエンスが失われました。 セクションを追加する develop.watch ことで、次のものを保持できます。
services:
frontend:
pull_policy: build
build:
context: .
environment:
BACKEND_HOST: ${BACKEND_HOST:-https://staging.example.com}
ports:
- 8000:8000
develop:
watch:
- path: package.json
action: rebuild
- path: src/
target: /app/src
action: sync
現在、フロントエンドに取り組んでいる間、開発者はHMRによる迅速なイテレーションサイクルの恩恵を受け続けています。 ディレクトリ内で src/ ファイルがローカルに変更されるたびに、 の /app/src コンテナに 同期 されます。
package.jsonファイルが変更されると、コンテナー全体が再構築され、Dockerfile のステップが再実行され、RUN npm install最新の依存関係がインストールされます。最良の部分は、ワークフローに対する唯一の変更が ではなく実行docker compose watchnpm startされていることです。
バックエンド
次に、Composeファイルを backend次のように設定しましょう。
services:
backend:
pull_policy: build
build:
context: .
ports:
- 1234:8080
develop:
watch:
- path: requirements.txt
action: rebuild
- path: ./
target: /app/
action: sync
include:
- path: [email protected]:myorg/frontend.git
env_file: frontend.env
frontend.env (英語)
BACKEND_HOST=http://backend:8080これの多くはフロントエンド compose.yamlと非常によく似ています。
プロジェクト ディレクトリ内のファイルがローカルで変更されると、コンテナー内に同期 /app されるため、Flask 開発サーバーはホット リロードを処理できます。 が変更され requirements.txt ると、コンテナー全体が再構築され、Dockerfile のステップが再実行され、 RUN pip install 最新の依存関係がインストールされます。
ただし、Git リポジトリによってフロントエンド プロジェクトを参照するセクションも追加 include しました。 カスタム env_file は (リポジトリ内の backend ) ローカル パスを指し、フロントエンド サービス コンテナーが既定値ではなくバックエンド サービス コンテナーに API 要求をプロキシするように設定 BACKEND_HOST されます。
手記： リモートインクルードは実験的な機能です。 Git 参照を使用するには、環境で設定 COMPOSE_EXPERIMENTAL_GIT_REMOTE=1 する必要があります。
この構成により、開発者は、フロントエンドとバックエンドの Compose プロジェクトを独立させながら、異なる Git リポジトリでもフルスタックを実行できるようになりました。
デベロッパーはコード ライブラリの依存関係を共有することに慣れており、この include キーワードは Compose 開発構成にも同じ再利用性と利便性をもたらします。
次は何ですか?
まだ荒削りな部分が残っています。 たとえば、リモート プロジェクトは一時ディレクトリに複製されますが、ファイルは編集できないため、インポート時に監視モードで使用するのは現実的ではありません。 より大規模で複雑なソフトウェア プロジェクトで Compose を柔軟でパーソナルな環境で使用できるようにすることは、私たちが継続的に改善している点です。
マイクロサービスやリポジトリで Compose を使用している Docker のお客様は、より良いサポート方法をぜひお聞かせください。 ご連絡ください!
さらに詳しく
- Docker デスクトップの最新リリースを入手します。
- 次のものに投票してください! 公開ロードマップをご覧ください。
- 質問がありますか? Docker コミュニティがお手伝いします。
- ドッカーは初めてですか? 始めましょう。