この投稿は、ホストで直接Docker Engine(Community Edition)を実行しているLinuxユーザーを対象としています。Docker Desktop ユーザーは何もする必要はありません — エンジンの更新は、将来のデスクトップ リリースに自動的に含まれます。
Docker Engine v29 is a foundational release that sets the stage for the future of the Docker platform. While it may not come with flashy new features, it introduces a few significant under-the-hood changes that simplify our architecture and improve ecosystem alignment:
- Minimum API version update
- Containerd イメージストアが新規インストールのデフォルトになりました。
- Go モジュールへの移行
- NFTablesの実験的サポート
これらの変更により、コンテナエコシステム全体の保守性、開発者エクスペリエンス、相互運用性が向上します。
Minimum API Version Update
Docker versions older than v25 are now end of life, and as such, we have increased the Minimum API version to 1.44 (Moby v25).
If you are getting the following error, you will need to update to a newer client or follow the mitigation steps to override the min-version
Error response from daemon: client version 1.43 is too old.
Minimum supported API version is 1.44, please upgrade your client to a newer version
Override the minimum API version
There are two methods to launch dockerd with a lower minimum API version. Additional information can be found on docs.docker.com
Using flags when starting dockerd
Launch dockerd with the DOCKER_MIN_API_VERSION set to the previous value. For example:
DOCKER_MIN_API_VERSION=1.24 dockerd
Using a JSON configuration file — daemon.json
Set min-api-version in your daemon.json file.
{
"min-api-version": "1.24"
}
containerd イメージストアがデフォルトになります
この変更を行った理由
Containerd ランタイムは Docker Engine のコア コンポーネントとして始まり、後に分割され、Cloud Native Computing Foundation (CNCF) に寄付されました。現在では、業界標準のコンテナランタイムとして機能し、Kubernetesや他の多くのプラットフォームを強化しています。
Docker は数年前にコンテナ実行用に containerd を導入しましたが、イメージ レイヤーの管理には グラフ ドライバー ストレージ バックエンド を引き続き使用しました。一方、containerd は、モジュール性、パフォーマンス、エコシステムの調整のために設計された独自のイメージコンテンツストアとスナップショットフレームワークを進化させました。
安定性を確保するために、Docker は時間の経過とともにコンテナー イメージ ストアに 徐々に移行 してきました。Docker Desktop は、昨年のほとんどの期間、すでに containerd イメージ ストアを デフォルト として使用しています。Docker Engine v29では、この移行は Mobyエンジンのデフォルトになることで次のステップに進みます。
それは何ですか
- Docker Engine v29以降、 containerd イメージストア は、 新規インストールのイメージレイヤーとコンテンツ管理のデフォルトになります。
- レガシグラフドライバーは引き続き使用できますが、現在は非推奨です。新規インストールは、問題が発生した場合でも Containerd イメージストアをオプトアウトできます。
なぜこれが重要なのか
- 簡素化されたアーキテクチャ: 実行とストレージの両方が containerd を使用するようになり、重複と内部の複雑さが軽減されます
- 次のような新機能の可能性を解き放ちます。
- スナップショットのイノベーション
- 画像コンテンツの遅延プル
- リモートコンテンツストア
- ピアツーピア配布
- エコシステムの連携: Docker Engine を Kubernetes などのコンテナベースのプラットフォームと同期させ、相互運用性を向上させます。
- 将来性:画像レイヤーの処理とランタイム動作における迅速なイノベーションを可能にします
Containerd イメージストアは、既存のストレージドライバーと比較してコンテンツとレイヤーの管理に対して異なるアプローチをとっているため、この変更により混乱が生じる可能性があることを理解しています。
しかし、この変化は前向きなものです。これにより、より一貫性があり、モジュール化され、予測可能なコンテナ エクスペリエンスが可能になります。
移行パス
明確にしておきますが、これらの変更は新規インストールにのみ影響します。既存のユーザーは containerd に強制されません。ただし、今すぐ移行を開始して オプトインすることはできます。
私たちは、チームが既存のコンテンツを containerd イメージストアに移行して移動するのに役立つ移行ガイドに取り組んでいます。
次のステップ
- グラフ ドライバー バックエンドは、将来のリリースで削除される予定です。
- Docker は、containerd のエコシステムの全機能を活用して、イメージ ストア エクスペリエンスを進化させ続けます。
- 将来的には、コンテンツ管理の強化、マルチスナップショットのサポート、プル/プッシュ ワークフローの高速化が期待されます。
MobyがGoモジュールに移行
この変更を行った理由
Goモジュールは 2019年からコミュニティ標準でしたが、これまでMobyプロジェクトはレガシーベンダーシステムを使用していました。Goモジュールを回避することで、以下が作成されました。
- 工具の前提を回避するための絶え間ないメンテナンスの解約
- コントリビューターのワークフローを混乱させる
- 新しい Go ツールおよびエコシステムの実践との互換性の問題
簡単に言えば、Go モジュールに抵抗し続けることは、すべての人の生活を困難にしていました。
それは何ですか
- Mobyコードベースは、go.modを使用して完全にモジュールに対応しました。
- これは、よりクリーンな依存関係管理と、ツールとコントリビューターの相互運用性の向上を意味します。
- 外部クライアント、API ライブラリ、SDK は、Moby コードベースの使用と統合が容易であることがわかります。
そうでないもの
- これはユーザー向けの機能ではなく、UI やコマンドの変更は表示されません。
- ただし、Docker の Go API を使用する開発者には影響します。
Go 開発者にとって重要
独自の Go プロジェクトで Docker クライアントまたは API パッケージを使用している場合:
- 古いモジュールパス github.com/docker/dockerは更新を受信しなくなります。
- Docker Engine リリースを最新の状態に保つには、github.com/moby/moby からのインポートに切り替える必要があります。
nftablesの実験的サポート
この変更を行った理由
Linux 上のブリッジおよびオーバーレイネットワークの場合、Docker Engine は現在、「iptables」および「ip6tables」を使用してファイアウォールルールを作成します。
ほとんどの場合、これらのコマンドは「iptables-nft」および「ip6tables-nft」にリンクされています。そのため、Docker のルールは舞台裏で nftables に変換されます。
ただし、OS ディストリビューションでは iptables のサポートが廃止され始めています。Docker Engineが独自のnftablesルールを直接作成する時期は過ぎました。
それは何ですか
iptables の代わりに nftables ルールを作成するためのオプトインサポート。
ルールは機能的には同等ですが、特にiptablesで「DOCKER-USER」チェーンを使用する場合は、注意すべき違いがいくつかあります。
「firewalld」を使用するホストでは、iptables ルールは firewalld の非推奨の「直接」インターフェイスを介して作成されます。ルールは個別のテーブルに編成され、それぞれが独自のベースチェーンを持つため、nftablesでは必要ありません。Docker は引き続きデバイスに firewalld ゾーンとポリシーを設定しますが、firewalld のないホストの場合と同様に、nftables ルールを直接作成します。
そうでないもの
この初期バージョンでは、nftables のサポートは「実験的」です。本番環境でのデプロイには注意が必要です。
Swarm のサポートは、将来のリリースで計画されています。現時点では、Swarmが有効になっているノードでDocker Engineのnftablesサポートを有効にすることはできません。
将来のリリースでは、nftables がデフォルトのファイアウォールバックエンドになり、iptables のサポートは非推奨になります。
今後の仕事
計画されている Swarm サポートの追加に加えて、効率向上の余地があります。
たとえば、ルール自体は、nftables 機能、特にポートのセットをより多く利用することができます。
これらの変更は、受け取ったフィードバックに基づいて優先順位が付けられます。貢献したい場合は、お知らせください。
試してみよう
Start dockerd with option --firewall-backend=nftables to enable nftables support.
After a reboot, you may find you need to enable IP Forwarding on the host. If you’re using the “DOCKER-USER” iptables chain, it will need to be migrated. For more information, see https://docs.docker.com/engine/network/firewall-nftables
We’re looking for feedback. If you find issues, let us know at https://github.com/moby/moby/issues.
Engine v29 の使用開始
前述のように、この投稿は、ホストで直接Docker Engine(Community Edition)を実行しているLinuxユーザー向けです。Docker Desktop ユーザーは何もする必要はありません — エンジンの更新は、今後の Desktop リリースに自動的に含まれます。
ホストに Docker Engine をインストールしたり、既存のインストールを更新したりするには、特定の OS の ガイドに従って ください。
このリリースの詳細については、以下を参照してください。
