
チームが開発した新しいDocker Composeの機能について説明し、今後取り組む予定の内容をお伝えするとともに、できるだけ早くCompose V 2に切り替えるよう改めてお知らせします。
Compose V1 のサポートは 6 月 2023 以降提供されなくなり、今後のすべての Docker Desktop バージョンから削除されます。Compose V1 をまだ使用している場合は、Compose アプリケーションの実行に関する問題に対処する時間を確保するためにも、できるだけ早く切り替えることをお勧めします。(6月2023日まで、 1 2への移行に関連する課題に対処するため、 Composeの課題を監視します。)
この記事の内容
作曲V1:とても長くて別れを告げる、旧友!
Compose V 2 GAの発表において、私たちは以下のタイムラインを提案しました。

タイムラインが延長されたため、サポートは 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)
V 1と V 2の違いの詳細については、ドキュメントのCompose の進化を参照してください。
新機能
ビルドの改善
ここ数ヶ月間、チームの主な取り組みは、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 属性です。
services:
myservice:
image: build-test-ssh
build:
context: .
ssh:
- fake-ssh=./fixtures/build-test/ssh/fake_rsa
また、Dockerfile内のsshリソースのIDを参照する必要があります。
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 ローカル エージェントをマウントしてプライベート リポジトリを複製します。
# 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 は、サービスの名前、ビルドするターゲット プラットフォーム、およびこのビルドの実行に使用されるプラットフォームをログに記録します。
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) を持つアプリケーションスタックを定義します。
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 してください。
docker buildx create --driver docker-container --use
マルチアーキテクチャビルド機能を使用するには:
> docker compose build --no-cache
追加の更新プログラム
また、問題の修正、コーナーケースの管理、機能の追加も行いました。 たとえば、環境変数の値からシークレットを定義できます。
services:
myservice:
image: build-test-secret
build:
context: .
secrets:
- envsecret
secrets:
envsecret:
environment: SOME_SECRET
現在、windows/arm64 および linux/riscv64 用の Compose バイナリを提供しています。
Compose が .env を管理する方法を全面的に見直しましたファイル、環境変数、および優先順位補間。環境変数の優先順位に関するドキュメントを読んで、詳細を確認してください。
4月2022以降に行ったすべての変更を確認するには、 Composeのリリースページまたは変更点の比較ページをご覧ください。
次は何ですか?
Compose チームは、Compose を使用して開発者の内部ループを改善することに重点を置いています。 私たちが取り組んでいるアイデアは次のとおりです。
- development ウォッチモードを含む Compose 仕様のセクション。プログラミングツールで定義されたモードを使用したり、Compose に管理させたりすることができます
- 特定のデバッグ ポートを追加したり、サービス コンテナー内でプロファイリング ツールを使用したりする機能
- コンテナライフサイクルのさまざまな瞬間にサービスと対話するためのライフサイクルフック(たとえば、コンテナが作成されても起動していないとき、またはコンテナが稼働していて正常なときにコマンドを実行できるようにする)
- --dry-run Compose コマンドを実行する前にテストするためのフラグ
Composeで開発ワークフローを改善するための機能を追加してほしいというご要望がありましたら、公開ロードマップへのフィードバックをお待ちしております。
Compose の継続的な改善を利用して、サポートが 2023 年 6 月に終了する前に問題を明らかにするには、Compose V2 を使用していることを確認してください。 CLI を使用するか、 docker compose Docker デスクトップ設定でオプションをアクティブにします。
V 1とV 2の違いについて詳しく知りたい場合は、ドキュメントの「Composeの進化」をご覧ください。