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の GA がリリースされました。本日より、Compose V2 はすべてのドキュメントの標準となり、Compose V2 は Docker Desktop の開発者向けデフォルトになります。ただし、docker-compose docker composeへのエイリアス設定と V2 のオプトアウトは、Docker Desktop UI を使用するか、docker-compose disable-v2 command.
Compose V1 はどうなりますか?
Compose V1 はサポート終了としてマークされました。優先度の高いセキュリティパッチと重大なバグ修正のみが、次のマイルストーンまでV1 に適用されます。このブログの後半では、Docker Compose V1のサポート終了 (EOL) の提案されたタイムラインの概要を説明します — これには、6 か月間の重要なセキュリティとバグの修正と、V2をオプトアウトするための 1 年間の猶予期間が含まれます。
現在、docker-compose to docker composeのエイリアシングを削除する予定はありません。ご質問やご不明な点がございましたら、オープンロードマップの問題に関するフィードバックをお待ちしております。V2の使用状況を継続的に追跡しながらフィードバックを収集し、必要に応じて調整を行います。
開発者として何をする必要がありますか?
ほとんどの場合、何もする必要はありません。Docker Desktop のバージョン 3.4+はCompose V2 を自動的にインストールします。Docker Desktop バージョン . 4の場合4。2+、デフォルトでは、docker-compose構文のエイリアスをdocker composeに有効にしています。これにより、V2 を V1 のドロップイン代替品として使用しながら、スクリプトの更新 (あったとしても) を最小限に抑えることができます。
エイリアシングを使用しているかどうかは、Docker Desktop の [一般] 設定タブで [Docker Compose V2を使用する] が選択されているかどうかを確認することで確認できます。移行の詳細については、このブログの「Compose V1をまだ使用している場合の対処方法」をご覧ください。互換性がない場合は、こちらからご提出ください。
Linuxを使用している場合はどうなりますか?
Docker Desktop for Linux は現在ベータ版で、Compose V2が含まれています。または、Linux 用の Docker Compose V2 を手動でインストールすることもできます。Moby v20.10.13,インストールを容易にするために、オプションのDocker CLIプラグインとしてcompose-pluginが含まれています。詳細については、ドキュメントをご覧ください。
Docker がこの移行を行う理由と、V2 を使用する必要があるのはなぜですか?
Compose V2 は、マルチコンテナアプリケーションを効率的に実行するのに役立つ Compose V1のすべての機能を提供します。Go への移行は、私たちが最も気に入ったロードマップ アイテムの 1 つであり、より多くの機能をより迅速に提供できるようになりました。これらはDocker CLIに統合され、Dockerのツール全体でシームレスなユーザーエクスペリエンスが実現しました。V2で紹介された主な機能の詳細については、こちらをご覧ください。
ああ、そしてコンポジションタコの名前は何ですか?
まだありません!GitHubにアクセスして、友達に名前を付けるのを手伝ってください—自分の名前を提出したり、お気に入りに投票したりするために!
次に、V2 に移行するプロセスとその利点について説明します。
Compose V1 をまだ使用している場合はどうすればよいですか?
Compose V2 がインストールされていることを確認します
Docker Desktop には、Docker Compose V2が自動的に含まれます。さらに、Docker Desktop for Linux(ベータ版)にはCompose V2が付属しています。必要に応じて、 Docker Compose V2 を Linux に手動でインストールすることもできます。また、 Moby v..20 1013にオプションの compose-plugin も含まれています— Docker CLI で — インストールを簡略化します。Compose V2 は Go プロジェクトであるため、Python ライブラリとしては利用できないことに注意してください。pip では Compose V1 のみご利用いただけます。詳細については、ドキュメントを参照してください。
Alias docker-compose to docker compose
Docker Desktop 内で、[一般] タブの [Docker Compose V2を使用する] オプションを切り替えます。これにより、docker-composeコマンドが docker compose にエイリアスされます。V2 は、最小限のスクリプト更新で V1 のドロップイン代替品として簡単に使用できます。
V1 と V2 の互換性を確保する
Compose V1 と Compose V2 の互換性を確保することは、日常のワークフローを中断することなく Compose V2を活用するために重要です。以下は、Compose V2で導入された 2 つの主要な変更点と、その軽減手順です。さらに、Compose V2に実装されていないいくつかの Compose V1 フラグを廃止しました。これらの変更の詳細については、互換性に関するドキュメントをご覧ください。
| 変更内容 | 潜在的な影響 | 緩和 |
| ビルドキットのサポートは V2 内でネイティブであり、Docker CLI と同様にデフォルトで有効になっています。 | V2 の開発者は、デフォルトで BuildKit を使用します。 | DOCKER_BUILDKIT=0 を設定してオプトアウトする |
| コンテナー名で、アンダースコアの代わりにハイフンが区切り文字として使用されるようになりました。 | スクリプトでコンテナー名に依存している場合、破壊的変更が発生します。 一般に、コンテナー名に依存しないように注意してください。 | これをオフにするには、フラグ "–compatibility " を渡します |
Docker Compose V2 は、Compose V1のドロップイン代替品です。ほとんどの場合、ダッシュを削除するか、docker-composeのエイリアシングを有効にすると、追加の変更なしでdocker composeして続行できます。移行中に問題が発生した場合は、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 ホストに GPU デバイスの予約が含まれている場合、および Docker デーモンがそれに応じて設定されている場合、Compose サービスでは GPU デバイスの予約を定義できます。
- プロファイルのサポート – プロファイルを使用すると、選択的なサービスの有効化を通じて、Compose アプリケーション モデルをさまざまな用途や環境に適応させることができます。
docker composels コマンドで、Compose アプリの完全なリストを表示できるようになりました。docker composecp コマンドを使用すると、サービス・コンテナーとローカル・ファイル・システムの間でファイルおよびフォルダーをコピーできます。
これらの機能は、Docker CLI を介して出荷されます。 各 Docker デスクトップは、すべての更新を CLI に自動的に適用するため、管理ワークロードが軽減されます。
2)生産へのシームレスな道
プロジェクトを簡単に作成し、AWSまたはECS環境内、またはAzure ACI内で直接実行できるとしたらどうでしょうか。これは、新しいクラウド統合のおかげで、Compose V2で行うことができます。
ローカル開発に Docker Compose を使用し、運用環境に ACI または ECS を使用する場合、クラウドへの Docker Compose アプリケーションのデプロイがはるかに簡単になりました。 クラウドプラットフォーム上でアプリケーションを「アップ」するには、Docker コンテキストを切り替え、Amazon ECS または Microsoft ACI でアプリを起動するだけです。
V2内の Compose 仕様はこれを可能にします。Compose 仕様では、プラットフォームに依存しないマルチコンテナ アプリケーションを定義できます。他のプログラムは、この仕様を使用して、これらのファイルを検証し、実行することができます。これにより、Go の Compose ファイルの解析と表現の実装である 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 の両方を実行しながら、十分にテストされた動作を保持docker compose。ログ出力に至るまですべてが一貫性を保つため、開発者はログ出力を簡単に切り替えることができます。
4)バイナリの作成による更新と依存関係の管理の容易化
Goを使用すると、以前は不可能だった静的バイナリをリリースできるようになりました(GNU / Linuxでのglibcとlibmuslのようないくつかの問題を回避できます)。これは、Python にコンパイラが組み込まれていないためです。これにより、主要なプラットフォーム (GNU/Linux、macOS、Windows) 用のバイナリを生成するために pyinstaller に頼る必要がありました。より異種混在のプラットフォームの場合、V1 は PyPI (pip install単位) に依存しているため、依存関係の管理が複雑になります。さまざまな依存関係の組み合わせが既にインストールされている可能性があります。
Go 言語は、$GOOS、$GOARCH、場合によっては $GOARM を通じてクロスコンパイルのロックを解除します (完全なリストについては、Go のドキュメントを参照してください)。その後、Raspberry Piで静的バイナリを使用して、pip installを回避できます。
最後に、ネイティブに物事を実行するのははるかに高速です!
5.作成ファイルなしでコマンドを実行します
最後に、コンテナラベルを使用すると、YAMLファイルに含まれる情報を再作成できます。この機能を使用すると、コマンドラインに –project-name を追加するだけで実行中のプロジェクトを管理できるため、元の Compose ファイルや環境変数なしで 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 をテストします。 それはそれと同じくらい簡単です!