fbpx

Mirantis Container Runtime (旧Docker Enterprise) 23.0 メジャーリリース! #mirantis #docker

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本稿は Announcing the 23.0 major release for Mirantis Container Runtime—and Moby の和訳です。

Mirantis Container RuntimeMoby Project の2年ぶりのメジャーリリースを発表いたします。23.0 リリースは、実験的な Container Storage Interface (CSI) と代替 OCI ランタイムサポート、BuildKit のデフォルト化、ヘルスチェックの重大な改善など広く期待されていた機能に加えて、より柔軟な seccomp と新しい API バージョンなどのその他のさまざまな改善を含みます。

本稿ではこれらの変更点や、Windows 2016サポートの廃止について、詳しく見ていきましょう。その前に「Mobyって何ですか?」という問いに答える必要がありそうです。

アップストリーム第一の哲学

このリリースは、技術の進歩のみならず、Moby Projectの継続的な健全性と独立性を維持するためのDocker社の仲間達とより広範なオープンソースコミュニティの協働作業という、2年にわたる作業の集大成です。

Mobyとは、「Docker」や「Docker Engine」として皆さんがご存知のオープンソースのコンテナフレームワークです。Mobyはさまざまなライブラリとコンポーネントを、洗練されたコンテナ開発や実行体験のために組み合わせたものです。MobyはMirantis Container Runtimeのみならず、Docker CEやDocker Desktop、その他さまざまなオープンソースプロジェクトのアップストリーム(上流)です。

Mirantis Container Runtimeは常に、開発に際して「アップストリーム第一」というアプローチを取っています。私達のエンジニアはMCRに対して行った作業をコミュニティ全体に幅広く届けるため、直接 Moby Project に貢献しています。MCR 23.0では、アップストリームのバージョン番号に従うことで「アップストリーム第一」におけるユーザ対応の側面をより深め、ユーザはMCRがどのバージョンなのかを容易に理解することができ、コミュニティのオープンソースプロジェクトのDockerと、サポート付きでエンタープライズ級のMirantis Container Runtimeをシームレスに切り替えることができます。

MCRのお客様にとっては、信頼できる業界標準のコンテナエンジン上にサービスを構築していて、落とし穴や驚き、ベンダーロックインがなく、コンテナランタイムのような基本的なコンポーネントに必要なもののみでできているという安心感を得ることができます。

Moby 23.0のおもな変更点

「アップストリーム第一」の精神により、Mirantis Container RuntimeチームとMoby開発コミュニティは、MobyとMirantis Container Runtimeに大きな影響を与えるいくつかの変更点を共有することができました。rootlessモードの改善からseccompフィルタの改善まで、注目すべき追加・変更を含むその他詳細については完全なリリースノートを参照してください。

Container Storage Interface (CSI)の実験的サポート

このリリースでは、SwarmでのContainer Storage Interface (CSI)の実験的サポートを導入しました。このCSIドライバは、Kubernetesで使用されているストレージドライバと同じものです。SwarmがCSI準拠の実装として成熟するにつれて、永続ストレージバックエンドのエコシステム全体が利用可能になることが期待できます。

CSIをSwarmで利用可能とするには、CSIドライバをKubernetesコントロールプレーンに直接接続しないでください。このドライバはDocker Engineプラグインとして、Swarm用にネイティブに(再)パッケージングする必要もあります。

現時点では、SwarmにおけるCSIは、開発・実験用途にのみ適しています。MirantisはMoby開発コミュニティと積極的に協力し、Swarm CSIを宣伝し、その実装を成熟させ、バグや不足している機能が明らかになればすぐに対処しています。

Swarm CSIの実験や開発に興味があれば、コミュニティ主導でコーディネートされた取り組みをGitHubで確認してみてください。

代替OCIランタイムサポートの改善

Moby 23.0は、代替OCIランタイムのサポートを大幅に強化し、「従来の」コンテナ化の代替としてよく知られたKata ContainersgVisorのサポートをついに有効化しました。これまでのリリースでもいくつかの代替OCIランタイムをサポートしていましたが、デフォルトのrunc実装と「ドロップイン」の互換性がなければいけませんでした。

23.0リリースでは、代替shimもサポートしました。shimとは、コンテナを管理するMobyのコンポーネントであるcontainerdと、実際にコンテナ自体を実行する「実際の」ランタイムを仲介するプログラムのことです。例えばKata Containersでは、containerd shimは軽量ハイパーバイザを利用します。

現在、cri-dockerd およびKubernetesでは代替shimを利用することはできませんが、この実装により、他のコンテナ化技術の実験とスタンドアロン利用ができるようになります。Mirantisは、非互換性が明らかになった際に修正することで代替ランタイムのサポートを改善することを計画しています。また、MCRのお客様が簡単かつ自由に切り替えられるように、代替ランタイムのパッケージングも検討しています。

BuildKitとbuildxのデフォルト化

23.0リリースでは、LinuxではBuildKitビルダー(DOCKER_BUILDKIT=1)がデフォルトとなります。さらに、23.0のCLIでは、docker buildコマンドはdocker buildx buildのエイリアスとなります。これはBuildKitが成熟してきたことを反映しており、BuildKitによるキャッシュ、パフォーマンス、柔軟性の大幅な改善の恩恵を受けることができるでしょう。これは大幅な動作の変更ですが、ほとんどが透過的なものです。以前の動作を利用したい場合、DOCKER_BUILDKIT=0 を指定する必要があることに注意してください。

従来のビルダーとBuildKitの差異の詳細については、アップストリームのドキュメントを参照してください。

ボリュームプルーンとAPI 1.42

23.0リリースでは、サポートするDocker Engine APIバージョンを1.42に上げました。APIバージョン1.42では、ボリュームプルーンは匿名ボリュームのみに作用し、作成時に命名されたボリュームを無視します。この動作の変更は、CLIとデーモンの双方でAPIバージョン1.42をサポートしている場合のみに起こります。

現時点では、Miranris Container Runtime 23.0のみがAPIバージョン1.42をサポートしているため、この新しい動作を行うにはMirantis Container Runtime 23.0のCLIなど、更新されたAPIクライアントが必要です。古いバージョンのDocker Engine APIでは、匿名ボリュームと名前つきボリュームの両方にボリュームプルーンが実施されることに注意してください。

Docker Engine API 1.42では、all=1という新しいフィルタを使用して、名前つきボリュームに対してボリュームプルーンを実施するように動作を戻すことができます。具体的には、Mirantis Container Runtime 23.0のCLIでは、docker volume prune --filter all=1 とすることで従来のCLIにおける docker volume prune と同じ結果が得られます。docker system prune -a はこのフィルタを指定できないため、ネゴシエーションしたAPIバージョンのデフォルトの動作が常に実行されます。

Docker Engine API 1.42の完全なAPIドキュメントはこちらを参照してください。また、Docker Engine APIバージョンの完全な変更履歴はこちらを参照してください。

Windows Server 2019以上が必須化

23.0リリースはWindows Server 2016をサポートしません。これは一部のユーザにとって残念なことかもしれませんが、Mobyにおける多くの技術的負債を返済した結果です。Windowsの新しいバージョンではコンテナの成熟した実装が広く使用されているため、
Windows Server 2019以降のユーザは、Windowsコンテナサポートのより迅速な開発やバグ修正の恩恵を受けることができます。

注意: Mirantis Container Runtime 20.10は引き続きWindows Server 2016をサポートします。Mirantis Container Runtime 20.10のサポート終了は、移行を容易にするために、2023年12月まで延長されました。

ヘルスチェックの変更

ヘルスチェックを実行するために必要なオーバーヘッドは、時間の閾値の一部としてカウントされなくなりました。これによりノード負荷が増大してもコンテナを「unhealthy」とマークしないため、「Thundering Herd」現象が起きる可能性を大きく減らすことができます。また、コンテナが実行中にデーモンを再起動したとき、ヘルスチェックが適切に再開されるようになりました。さらに、永久にハングアップするのではなく、タイムアウトしたヘルスチェックプロセスをより確実に終了するようになりました。

Mirantis Container Runtimeに固有の変更

前述したアップストリームでの実装・変更に加えて、Mirantis Container Runtime 23.0では固有の変更をいくつか含みます:

新たにサポートするプラットフォーム

23.0では、次の新しいプラットフォームをサポートに含みます:

  • Oracle Linux 8
  • RHEL 9
  • Windows Server 2022

Rocky Linux 9とUbuntu 22.04 Jammyのサポートはしばらくお待ちください。

ストレージドライバの削除

MCR 23.0リリースから、Mirantisはサポートされていないストレージドライバの提供を終了します。これにより、MCR 20.10で未サポートのストレージドライバを利用しているお客様のアップグレードに問題が発生しますが、サポート対象外の構成のMCRがインストールされていることを早期に発見できるようになります。

overlay2 はMCRが構築およびサポートする唯一のストレージドライバです。ただし、SLESプラットフォームにおける btrfs は例外であり、 overlay2 と並行してサポートされます。

Mirantisは vfs ストレージドライバを引き続き利用可能としますが、これはストレージバックエンドのデバッグ用途にのみ提供します。 vfs ドライバは未サポートのままであり、本番環境での利用には適しません。

Mirantisは未サポートのストレージドライバの削除により、Moby Projectで現在開発中の新しいストレージバックエンドへの長期的な移行に向けて、お客様が適した状態になることを目指しています。

その他の重要な変更

  • btrfsZFS より overlay2 が優先されるようになりました。これは SLES プラットフォームでの MCR のアップグレード、インストールに影響を与えます。
  • overlay2d_type を持たないファイルシステムで利用できなくなりました。これにより、一部の既存システムでのインプレースアップグレードを阻害する可能性があります。

まとめ

23.0 はMirantis Container RuntimeとMobyの双方にとってエキサイティングなマイルストーンであり、Mirantisはこれをコミュニティと共有できることを嬉しく思います。ご意見やご質問がございましたら、Mirantis社にお気軽にお問い合わせ、またはコミュニティにご参加ください!

新規CTA