Docker Compose バージョン 2 (別名 V2) の一般提供を発表できることを嬉しく思います。

2021 年 6 月に Compose V2 の最初のバージョンをリリースしました。 皆様からのフィードバックのおかげで、最初のロールアウト以来、多くの改善が行われ、過去 10 か月間で採用が着実に増加しています。 V2について多くの良いことを聞いています! 現在、最新バージョンの Docker Desktop を実行している Docker Compose ユーザーの 78% が Compose V2 を使用しているため、本番環境のワークフローで一般公開できることに自信を持っています。

移行について知っておくべきこと

Compose V2 GA はいつで、どういう意味ですか?

2022 年 4 月 26 日は、Docker Compose V2 の一般公開です。 本日より、Compose V2 がすべてのドキュメントの標準となり、Compose V2 が Docker Desktop の開発者向けデフォルトになります。 ただし、 引き続き docker-compose を docker compose にエイリアスし、Docker Desktop UI を使用するか、 docker-compose disable-v2 コマンドを入力することで、V2 をオプトアウトできます。

Compose V1 はどうなりますか?

Compose V1 を非推奨としてマークしました。 優先度の高いセキュリティ パッチと重大なバグ修正のみが、次のマイルストーンまで V1 に適用されます。 このブログの後半では、Docker Compose V1 のサポート終了 (EOL) の タイムライン 案について概説します (これには、6 か月間の重要なセキュリティとバグの修正と、V2 をオプトアウトするための 1 年間の猶予期間が含まれます)。

現在、 docker-compose から docker compose へのエイリアスを削除する予定はありません。 ご質問やご不明な点がございましたら、 オープンロードマップの問題に関するフィードバックをお待ちしております。 V2 の使用状況を継続的に追跡しながらフィードバックを収集し、作業を進めながら調整を行います。

開発者として何をする必要がありますか?

ほとんどの場合、何もする必要はありません。 Docker Desktop バージョン 3.4+ では、Compose V2 が自動的にインストールされます。 ドッカーデスクトップバージョン4.4.2+では、 既定では、Docker-compose 構文から Docker compose へのエイリアシングが有効になっています。これにより、V2 を V1 のドロップイン置換として使用しながら、スクリプトの更新 (存在する場合) を最小限に抑えることができます。

エイリアシングを使用しているかどうかは、Docker Desktop の [全般] 設定タブで、[Docker Compose V2 を使用する] が選択されているかどうかで確認できます。 移行の詳細については、このブログの「Compose V1 をまだ使用している場合の対処方法」セクションを参照してください。 非互換性が発生した場合は、 こちらから送信してください。

Linuxを使用している場合はどうなりますか?

Docker Desktop for Linux は現在ベータ版であり、Compose V2 が含まれています。 または、Docker Compose V2 for Linux を手動でインストールすることもできます。 Moby v20.10.13では、インストールを容易にするために、オプションのDocker CLIプラグインとして 作成プラグイン が含まれています。 詳細については、 ドキュメント をご覧ください。

Docker がこの移行を行う理由と、V2 を使用する必要があるのはなぜですか?

Compose V2 は、マルチコンテナアプリケーションを効率的に実行するのに役立つ Compose V1 のすべての機能を提供します。 Go への移行は、私たちが最も気に入った ロードマップ項目 の 1 つであり、より多くの機能をより速い速度で提供できるようになりました。 これらは現在 Docker CLI に統合されており、Docker のツール間でシームレスなユーザー エクスペリエンスを実現しています。 V2 で導入された主な機能の詳細については、こちらをご覧ください。

ああ、そしてコンポジションタコの名前は何ですか?

まだありません! GitHub にアクセスして友達に名前を付けるのを手伝ってください—自分の名前を送信し、お気に入りに投票してください!

Compose V1 をまだ使用している場合はどうすればよいですか?

Compose V2 がインストールされていることを確認します

Docker Desktop には、Docker Compose V2 が自動的に含まれます。 さらに、 Docker Desktop for Linux (Beta) には Compose V2 が付属しています。 必要に応じて、Linux に Docker Compose V2 を手動でインストールすることもできます。 また、インストールを簡素化するために、 Moby v20.10.13 (Docker CLI 内) にオプションの compose-plugin が含まれています。 Compose V2 は Go プロジェクトであるため、Python ライブラリとしては使用できません。 Compose V1 のみが pip 経由で利用できます。 詳細については、 ドキュメントを参照してください。

Alias docker-compose to docker compose

Dockerデスクトップ内で、[全般]タブの下にある[Docker Compose V2を使用する]オプションを切り替えます。 これにより、ドッカー作成コマンドが ドッカー作成 に エイリアスされます。V2 は、最小限のスクリプト更新で V1 のドロップイン置換として簡単に使用できます。

V1 と V2 の互換性を確保する

Compose V1 と Compose V2 の互換性を確保することは、日常のワークフローを中断することなく Compose V2 を活用するうえで重要です。 以下は、Compose V2 で導入された 2 つの重要な変更点とその軽減手順です。 さらに、Compose V2 に実装されていないいくつかの Compose V1 フラグを非推奨にしました。 これらの変更の詳細については、 互換性に関するドキュメントをご覧ください。

Docker Compose V2 は、Compose V1 に代わるドロップイン型です。 ほとんどの場合、ダッシュを削除するか、 docker-compose から docker作成 へのエイリアシングを有効にして、追加の変更なしで続行できます。 移行中に問題が発生した場合は、 Compose 課題リポジトリ にフィードバックを送信していただければ、それに応じて優先順位が付けられます。

Docker Compose V1 についてはどうですか?

Compose V2 に移行する時間を十分に確保してください。 Docker Compose V1 をすぐに廃止することはなく、開発者は一時的に V1 に戻すことができます。

Docker Compose V2 の卒業があなたにとって何を意味するかは次のとおりです。

• Docker Compose V2 ブランチが GitHub の既定になりました。
• Docker Compose V1 は 引き続き 'master' ブランチにあります。
• Compose V1 は非推奨としてマークされており、次のマイルストーンまで、重大度の高い脆弱性のみにパッチを適用するか、重大なバグを修正します。
• 開発者は引き続き docker-compose にエイリアスを付けて、 docker compose を使用できます。
• 開発者は、Docker Desktop UI を使用するか、 docker-compose disable-v2 コマンドを使用して、引き続き V2 をオプトアウトできます。
• Compose V1はオープンソースのままですが、新機能の開発は終了しています。 コミュニティから提出されたバグ修正やセキュリティパッチを引き続き監視し、必要に応じてマージします。

提案された Compose V1 のサポート終了タイムライン

これまでに Compose V2 への移行が多数成功してきたことを踏まえ、Docker Compose V1 のサポート終了 (EOL) について次のタイムラインを作成しました。

GitHub ロードマップの問題を通じてフィードバックを共有することをお勧めします。このフィードバックは、V2 の使用状況と並行して監視し、それに応じて調整を行います。

Compose V2 の利点は何ですか?

1)ドッカーCLI内の新機能の高速配信

Compose V2への移行には、多くの便利な新機能が付属しています。

• GPU マシンのサポート – Docker ホストにそのようなデバイスが含まれている場合、および Docker デーモンがそれに応じて設定されている場合、作成サービスで GPU デバイスの予約を定義できます。
• プロファイルのサポート – プロファイルを使用すると、選択的なサービスを有効にすることで、Composeアプリケーションモデルをさまざまな用途や環境に適合させることができます。
• docker compose ls コマンドで、作成アプリの完全なリストを表示できるようになりました。
• docker compose cp コマンドを使用すると、サービスコンテナとローカルファイルシステムの間でファイルとフォルダをコピーできます。

これらの機能は、Docker CLI を介して出荷されます。 各 Docker デスクトップは、すべての更新を CLI に自動的に適用するため、管理ワークロードが軽減されます。

2)生産へのシームレスな道

プロジェクトを簡単に 作成 し、AWS または ECS 環境内、または Azure ACI 内で直接実行できるとしたらどうでしょうか。 これは、新しい クラウド統合のおかげでComposeV2で行うことができます。

ローカル開発に Docker Compose を使用し、運用環境に ACI または ECS を使用する場合、クラウドへの Docker Compose アプリケーションのデプロイがはるかに簡単になりました。 クラウドプラットフォーム上でアプリケーションを「アップ」するには、Docker コンテキストを切り替え、Amazon ECS または Microsoft ACI でアプリを起動するだけです。

V2 内の Compose 仕様 では、これが可能になります。 Compose 仕様では、プラットフォームに依存しないマルチコンテナー アプリケーションを定義できます。 他のプログラムでは、この仕様を使用してこれらのファイルを検証および実行できます。 これにより、GoのCompose-fileの解析と表現の実装である compose-goも導入されます。 これは、Amazon ECS、Microsoft ACI、または Kubernetes 統合を使用する実装間で共通です。

3)Goで均質なDockerエコシステムを作成する

Compose V2 に先立ち、Python で Docker Compose V1 を作成しましたが、これは Docker エコシステム内の外れ値です。 逆に、Compose V2 は Go で記述されます。 したがって、V2 は、Moby、CLI、または任意の Go ベースのプロジェクトからコードをベンダー化できます。 Docker Compose の Go への移行により、Python の新機能やバグ修正を書き直す必要がなくなりました。

Docker CLI からの修正を Compose とより簡単に統合できるようになりました。 これにより、Dockerエコシステム全体で共有機能をホストするための標準的な場所が提供され、シームレスな再利用が促進されます。 したがって、ツーリング全体でより多くの価値を迅速に提供できます。 また、BuildKit などの他の Docker ツールから Compose にアップデートを簡単に追加することもできます。

たとえば、Compose と Docker CLI の両方で run コマンドと exec コマンドに同じコードを使用するようになり、docker と docker compose の両方を実行している間、十分にテストされた動作を維持できるようになりました。 ログ出力に至るまですべてが一貫しているため、開発者はログを簡単に切り替えることができます。

4)バイナリの作成による更新と依存関係の管理の容易化

Go を使うことで、以前は不可能だった静的バイナリをリリースできるようになりました (GNU/Linux での glibc 対 libmusl のような問題を回避できます)。 これは、Pythonにはコンパイラが組み込まれていないためです。 これにより、主要なプラットフォーム(GNU / Linux、macOS、およびWindows)用のバイナリを生成するために pyinstaller に依存することを余儀なくされました。 より異種プラットフォームの場合、V1 は PyPI ( pip インストールによる) に依存しているため、依存関係の管理が複雑になります。 さまざまな依存関係の組み合わせが既にインストールされている可能性があります。

Go言語は、 $GOOS、 $GOARCH、場合によっては $GOARM によるクロスコンパイルのロックを解除します(完全なリストについては、Goのドキュメントを参照してください )。 その後、ラズベリーパイで静的バイナリを使用して、 pipインストールを回避できます。

最後に、物事をネイティブで実行することは はるかに 高速です!

5.作成ファイルなしでコマンドを実行します

大事なことを言い忘れましたが、 コンテナラベル を使用すると、YAMLファイルに含まれる情報を再作成できます。 この機能を使用すると、コマンドラインに –project-name を追加するだけで実行中のプロジェクトを管理できるため、元の作成ファイルと環境変数なしで docker compose start /stop/pause/down/ps/exec... などを実行できます。 –project-name (-p) と入力して、以前に設定した既存のプロジェクト名を取得するだけです。

たとえば、次のコマンドでは、プロジェクト名のフォルダーにいる必要はなく、Compose ファイルを現在のディレクトリに配置する必要もありません。

$ docker compose --project-name myproject down

Docker CLIのプラグインファミリーに加わったDocker Composeの進化をサポートしていただきありがとうございます。 Compose V2 のユーザー エクスペリエンスを引き続き強化できることを嬉しく思います。 次回 Docker Compose を使用するときは、ハイフンをスペースに置き換えて V2 をテストします。 それはそれと同じくらい簡単です!