![- docker compose v2 スケーリング Docker Compose V2に切り替えます。](https://www.docker.com/ja-jp/app/uploads/2023/01/docker-compose-v2-scaled.jpg)
チームが構築した Docker Compose の新機能について説明し、次に取り組む予定の内容を共有し、できるだけ早く Compose V2 に切り替えるように通知します。
Compose V1 のサポートは 2023 年 6 月以降提供されなくなり、今後のすべての Docker デスクトップ バージョンから削除されます。 まだ Compose V1 を使用している場合は、できるだけ早く切り替えて、Compose アプリケーションの実行に関する問題に対処する時間を確保することをお勧めします。 (2023 年 6 月末まで、V1 から V2 への移行に関連する課題に対処するために 、作成の問題 を監視します)。
この記事の内容
作曲V1:とても長くて別れを告げる、旧友!
Compose V2 GA の発表 では、次のタイムラインを提案しました。
![- Docker Compose v1 サポート終了のタイムライン Compose v1 サポート終了タイムライン: 4 月 2022日、Compose v2 GA。 重大度の高いセキュリティ問題と重大なバグ修正のみが、次のマイルストーンまで v1 で引き続き行われます。 ユーザーは、docker-compose にエイリアスを付けることができます。 ユーザーは、Docker Desktop UI または docker-compose disable-v2 コマンドを使用して、v2をオプトアウトできます。10月 2022日、GAから6ヶ月後。 重大なバグ修正と重大なセキュリティ問題のサポートは、Compose v1で終了します。 ユーザーは、docker-compose にエイリアスを付けることができます。 ユーザーは、Docker デスクトップ UI または docker-compose disable-v2 コマンドを使用して、v2をオプトアウトできます。2023年4月、GA後1年。ユーザーは、docker-compose にエイリアスを付けることができます。 ユーザーは、Docker Desktop UI または docker-compose disable-v2 コマンドで v2 をオプトアウトできなくなりました。](https://www.docker.com/ja-jp/app/uploads/2022/04/Docker-Compose-v1-end-of-life-timeline.png)
タイムラインが延長されたため、サポートは 2023 年 6 月以降に終了します。
切り替えは簡単です。 お気に入りの端末の代わりに docker-compose 入力します docker compose 。
さらに簡単な方法は、Dockerデスクトップ設定内でデフォルトでComposeV2を選択することです。 このオプションを有効にすると、シンボリックリンクが作成されるため、既存のスクリプトを保持するために引き続き使用できます docker-compose が、最新バージョンのComposeの使用を開始できます。
![- Compose V の2 1 を有効にします。 Docker Desktop の [Preferences] > [General] で [Compose V2 ] を有効にします。](https://www.docker.com/ja-jp/app/uploads/2023/01/enable-compose-v2-1.gif)
V1 と V2 の違いの詳細については、ドキュメントの「作成 の進化 」を参照してください。
新機能
ビルドの改善
過去数か月間、チームの主な取り組みは、Compose 内のビルド エクスペリエンスの向上に焦点を当てることでした。 Compose 仕様で開かれた すべての提案を収集し た後、次の新機能を段階的に出荷し始めました。
- cache_to マルチステージビルドで中間画像からレイヤーを共有できるようにするサポート。 このオプションを使用する最良の方法の 1 つは、ワークフローステップ間で CI のキャッシュを共有することです。
- no-cache を使用して、サービスの完全な再構築を強制します。
- pull を使用して、基本イメージを強制的にプルするためのレジストリ同期をトリガーします。
- secrets ビルド時に使用します。
- tags をクリックして、最終的なビルド イメージに関連付けられたリストを定義します。
- ssh ローカルの SSH 構成を使用するか、ビルド プロセスにキーを渡します。 これにより、プライベートリポジトリを複製したり、保護されたリソースを操作したりできます。SSH 情報は最終的なイメージには保存されません。
- platforms を使用して複数のプラットフォームを定義し、Compose にサービスのマルチアーキテクチャイメージを生成させます。
最後の 2 つの改善点について詳しく見ていきましょう。
sshリソースの使用
ssh は Compose V2.4.0 GA で導入され、ビルド時に ssh リソースを使用できるようになりました。 これで、サービス イメージをビルドするときに、ローカル ssh 構成または公開/秘密キーを使用できるようになりました。 たとえば、コンテナー内のプライベート Git リポジトリを複製したり、リモート サーバーに接続して、サービスのビルド プロセス中に重要なリソースを使用したりできます。
ssh リソースはビルド プロセス中にのみ使用され、最終的なイメージでは使用できません。
作成でsshを使用するにはさまざまな可能性があります。 1つ目は、Composeファイルのビルドセクションの新しい ssh 属性です。
1 2 3 4 5 6 7 | services: myservice: image: build- test - ssh build: context: . ssh : - fake- ssh =. /fixtures/build-test/ssh/fake_rsa |
また、Dockerfile内のsshリソースのIDを参照する必要があります。
1 2 3 4 5 6 7 | FROM alpine RUN apk add --no-cache openssh-client WORKDIR /compose COPY fake_rsa.pub /compose/ RUN -- mount = type = ssh , id =fake- ssh ,required= true diff <( ssh -add -L) <( cat /compose/fake_rsa .pub) |
この例は、ビルド時にキーを使用する簡単なデモンストレーションです。 公開sshキーをコピーし、コンテナ内に秘密キーをマウントし、以前に追加された公開キーと一致するかどうかを確認します。
新しい --ssh フラグで CLI を直接使用することもできます。 これを使用して、プライベートGitリポジトリをコピーしてみましょう。
次の Dockerfile は、イメージの ssh 構成に既知のホストとして GitHub を追加し、ssh ローカル エージェントをマウントしてプライベート リポジトリを複製します。
1 2 3 4 5 6 7 8 | # syntax=docker/dockerfile:1 FROM alpine:3.15 RUN apk add --no-cache openssh-client git RUN mkdir -p -m 0700 ~/. ssh && ssh -keyscan github.com >> ~/. ssh /known_hosts RUN -- mount = type = ssh git clone git@github.com:glours /secret-repo .git CMD ls -lah secret-repo |
また、docker作成ビルド --no-cache --progress=plain --ssh default コマンドを使用すると、ローカルsshエージェントが作成に渡されます。
Composeでマルチアーキテクチャ画像を構築する
Compose バージョン V2.11.0 では、ビルド セクションにプラットフォームを追加し、Compose にクロスプラットフォーム ビルドを実行させる機能が導入されました。
次の Dockerfile は、サービスの名前、ビルドするターゲット プラットフォーム、およびこのビルドの実行に使用されるプラットフォームをログに記録します。
1 2 3 4 5 6 7 8 9 | FROM --platform=$BUILDPLATFORM golang:alpine AS build ARG TARGETPLATFORM ARG BUILDPLATFORM ARG SERVICENAME RUN echo "I am $SERVICENAME building for $TARGETPLATFORM, running on $BUILDPLATFORM" > /log FROM alpine COPY --from=build /log /log |
この Compose ファイルは、異なるビルドプラットフォームを対象とする 2 つのサービス (A と B) を持つアプリケーションスタックを定義します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | services: serviceA: image: build- test -platform-a: test build: context: . args: - SERVICENAME=serviceA platforms: - linux /amd64 - linux /arm64 serviceB: image: build- test -platform-b: test build: context: . args: - SERVICENAME=serviceB platforms: - linux /386 - linux /arm64 |
マルチアーキテクチャイメージをビルドできるビルドドライバを作成して使用 docker-container してください。
1 | docker buildx create --driver docker-container --use |
マルチアーキテクチャビルド機能を使用するには:
1 | > docker compose build --no-cache |
追加の更新プログラム
また、問題の修正、コーナーケースの管理、機能の追加も行いました。 たとえば、環境変数の値からシークレットを定義できます。
1 2 3 4 5 6 7 8 9 10 11 | services: myservice: image: build- test -secret build: context: . secrets: - envsecret secrets: envsecret: environment: SOME_SECRET |
現在、windows/arm64 および linux/riscv64 用の Compose バイナリを提供しています。
Composeが.envを管理する方法を見直しました ファイル、環境変数、および優先順位補間。 詳細については、 環境変数の優先順位に関するドキュメント を参照してください。
2022 年 4 月以降に行われたすべての変更を確認するには、 リリースの作成 ページまたは 変更の比較ページを確認してください。
次は何ですか?
Compose チームは、Compose を使用して開発者の内部ループを改善することに重点を置いています。 私たちが取り組んでいるアイデアは次のとおりです。
- development ウォッチモードを含む Compose 仕様のセクション。プログラミングツールで定義されたモードを使用したり、Compose に管理させたりすることができます
- 特定のデバッグ ポートを追加したり、サービス コンテナー内でプロファイリング ツールを使用したりする機能
- コンテナライフサイクルのさまざまな瞬間にサービスと対話するためのライフサイクルフック(たとえば、コンテナが作成されても起動していないとき、またはコンテナが稼働していて正常なときにコマンドを実行できるようにする)
- --dry-run Compose コマンドを実行する前にテストするためのフラグ
開発ワークフローを改善するために Compose で何かを見たい場合は、 パブリック ロードマップでフィードバックをお待ちしています。
Compose の継続的な改善を利用して、サポートが 2023 年 6 月に終了する前に問題を明らかにするには、Compose V2 を使用していることを確認してください。 CLI を使用するか、 docker compose Docker デスクトップ設定でオプションをアクティブにします。
V1 と V2 の違いの詳細については、ドキュメントの Compose の進化 に関するページを参照してください。