Docker Engine v29: 将来の基礎的なアップデート

この投稿は、ホストで直接Docker Engine(Community Edition)を実行しているLinuxユーザーを対象としています。Docker Desktop ユーザーは何もする必要はありません — エンジンの更新は、将来のデスクトップ リリースに自動的に含まれます。

Docker Engine v29 は、Docker プラットフォームの将来の準備を整える基礎リリースです。派手な新機能は付属していないかもしれませんが、アーキテクチャを簡素化し、エコシステムの整合性を改善するいくつかの重要な内部変更が導入されています。

• 最小 API バージョンの更新
• Containerd イメージストアが新規インストールのデフォルトになりました。
• Go モジュールへの移行
• NFTablesの実験的サポート

これらの変更により、コンテナエコシステム全体の保守性、開発者エクスペリエンス、相互運用性が向上します。

最小 API バージョンの更新

v25より古い Docker バージョンはサポートが終了するため、最小 API バージョンを1に増やしました。44 (Moby v25)。 

次のエラーが表示される場合は、新しいクライアントに更新するか、軽減策の手順に従って最小バージョンをオーバーライドする必要があります。

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

最小 API バージョンを上書きする

より低い最小 API バージョンで dockerd を起動するには 2 つの方法があります。追加情報は、docs.docker.com にあります。

dockerd の起動時にフラグを使用する

DOCKER_MIN_API_VERSIONを前の値に設定してdockerdを起動します。例えば：

DOCKER_MIN_API_VERSION=1.24 dockerd

JSON 構成ファイルの使用 — daemon.json

daemon.jsonファイルでmin-api-versionを設定します。

{
  "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 を使用するようになり、重複と内部の複雑さが軽減されます
• 次のような新機能の可能性を解き放ちます。
• スナップショットのイノベーション
• 画像コンテンツの遅延プル
• リモートコンテンツストア
• ピアツーピア配布
• エコシステムの連携: 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 機能、特にポートのセットをより多く利用することができます。

これらの変更は、受け取ったフィードバックに基づいて優先順位が付けられます。貢献したい場合は、お知らせください。

試してみよう

オプション --firewall-backend=nftables を使用して dockerd を開始し、nftables サポートを有効にします。
再起動後、ホストでIP転送を有効にする必要がある場合があります。「DOCKER-USER」iptablesチェーンを使用している場合は、移行する必要があります。詳細については、「https://docs.docker.com/engine/network/firewall-nftables」を参照してください。
フィードバックを募集しています。問題が見つかった場合は、 https://github.com/moby/moby/issues までお知らせください。

Engine v29 の使用開始

前述のように、この投稿は、ホストで直接Docker Engine(Community Edition)を実行しているLinuxユーザー向けです。Docker Desktop ユーザーは何もする必要はありません — エンジンの更新は、今後の Desktop リリースに自動的に含まれます。

ホストに Docker Engine をインストールしたり、既存のインストールを更新したりするには、特定の OS の ガイドに従って ください。

このリリースの詳細については、以下を参照してください。

• Engine v29 のリリースノート
• ドキュメンテーション