廃止された Docker は Podman に置き換えられますか?

Kubernetes チームは最近、最新バージョンの Docker でサポートされている機能を廃止し、これらの機能は以降のバージョンで削除されることを発表しました。

最近、Kubernetes チームは最新バージョン 1.20 をリリースし、多くのコンテンツを更新しました。

ストレージボリュームのスナップショット機能が安定しました。Kubectl Debug がベータ版に移行しました。ベータ版: API の優先順位と公平性、IPV4/IPV6 Alpha 機能の更新、GA: プロセス PID の制限、Dockershim が非推奨になりました。Exec プローブのタイムアウト処理など。(詳細については、https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/ を参照してください)

その中には、開発者コミュニティにとって間違いなく衝撃的なアップデートがあります。それは、Docker でサポートされている機能の廃止の公式発表です。では、Kubernetes はなぜこれを実行し、どのような影響を与えるのでしょうか?

Docker は、コンテナ化された方法でアプリケーションをパッケージ化、配布、および展開する方法です。 2013 年 3 月 13 日の最初のリリース以来、Docker はコンテナ業界の事実上の標準となっています。 Kubernetes は、Google が開発したオープンソースのコンテナ オーケストレーション システムです。

Kubernetes アーキテクチャ図 (Wikipedia より)

Docker と OpenShift

2015 年のサミットで、Red Hat は OpenShift V3.0 をリリースしました。この新しいバージョンの OpenShift では、最下層で Docker コンテナを使用し、Kubernetes を使用してイメージをオーケストレーションし始めます。しかし、2016 年の Red Hat Summit で、Docker は Red Hat の OpenShift に対して激しい攻撃を開始しました。彼らは以下のツイートを投稿しただけでなく、参加者に「模倣品はお断りします」と書かれたTシャツも配布した。

明らかに、左側の模造クジラは Red Hat の OpenShift を嘲笑しています。当時、OpenShift は Docker ベースのコンテナを使用していました。 Red Hat がリリースした Docker は、一般的には元のバージョンより少し遅れており、いわゆる「エンタープライズ サポート」を提供するために、Red Hat は古いバージョンの Docker にパッチを当てるという動作を採用しています。しかし対照的に、Docker は常に最新バージョンをリリースしています。

もちろん、エンタープライズ アプリケーションをアップグレードで維持するか、パッチを移植するかについては意見が分かれているため、ここではこの点についてはコメントしませんが、Red Hat 自身のサミットでの Docker の行動は確かに少し予想外のものでした。それ以前から Docker は素晴らしいテクノロジーであり、RedShift の重要な部分であったことは認めざるを得ませんが、その日から事態は悪化し始めました。

プラットフォーム戦争

初期の PaaS プラットフォームは主に OpenShift であり、競合の 2 つの Docker と Pivotal もありました。 Docker は誰もがよく知っているので、これ以上説明する必要もありません。Pivotal は、EMC と VMware によって 2013 年に設立された、オープンソースの PaaS ソリューションに重点を置いた企業です。同社のエンタープライズ ソリューションが非常に成功した理由は 1 つだけです。それは、特に Pivotal Labs と組み合わせた場合のユーザー エクスペリエンスが優れていることです。

Docker はエンタープライズ ソリューションの注目の的となっています。その利点は、開発者がすでに Docker エンジンに精通していることです。当時、Kubernetes はどこにも見つかりませんでした。しかし、Docker による OpenShift への攻撃により、Red Hat は Kubernetes にリソースを投資せざるを得なくなりました。誰もが後からその結果を目にしました。Kubernetes は大きな成功を収め、業界全体の支持を獲得しました。

このとき、Docker は状況を救うために Docker Swarm を立ち上げましたが、手遅れでした。 2016 年後半には、Kubernetes が Docker Swarm を上回り、業界の事実上の標準となりました。結局のところ、Docker Swarm は Kubernetes に何の影響も与えませんでした。これは Docker の最初の終焉と言えるでしょう。それ以降、Docker はエンタープライズ レベルの PaaS ソリューションではなくなり、クラウド ネイティブ システムの一部としてのみ存在できるようになりました。幸いなことに、Docker は常に Kubernetes の重要な部分であり続けています。

KubernetesがDockerの廃止を発表

最近、Kubernetes は Docker を廃止すると発表しました。

(公式ブログリンク: https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/):

これは間違いなく Docker の死の 2 回目の発表です。 Kubernetes 自体によれば、Docker はもはや必要な技術ではなく、技術的負債となっているとのことです。 Kubernetes 1.19 より前のバージョンでは、Dockershim というモジュールを介して Docker に接続し、Docker が Containerd に接続してコンテナを作成する必要がありました。技術的には、実際のコンテナ ランタイムは Docker ではなく Containerd です。 Docker の役割は、Containerd 上にコンテナを作成することだけです。人間のユーザーとしては、Docker run を実行するだけでコンテナを作成できるのは非常に便利です。しかし、便利な反面、Docker は多くの無駄な操作と技術的負債をもたらし、Kubernetes にとって負担となります。 Kubernetes は Docker を完全にバイパスし、Containerd 上にコンテナを作成して同じ効果を実現できます。このアプローチは Kubernetes 1.20 で採用されました。

Docker のビジネス モデルは失敗しましたが、Docker が業界全体に多大な貢献を果たしたことを認めなければなりません。 Docker がもたらすテクノロジーは業界最高です。現在に至るまで、当社の CI/CD システムは Docker に大きく依存しています。 Docker がなければ Kubernetes は成功しなかったでしょうし、Kubernetes には今でも Docker の影が残っています。

しかし、心配しないでください。Kubernetes チームは、アップグレード プロセスを可能な限りスムーズにするために多くの作業を行ってきました。 1.20 にアップグレードしても、Docker が非推奨であるという警告のみが表示されます。 Kubernetes の現在の計画では、2021 年末にリリースされる 1.22 で Docker サポートが完全に削除されるため、開発者はそれまでに Containerd や CRI-O などの他のコンテナ ランタイムに切り替える必要があります。

Dockerの代替

Docker が放棄された後、開発者たちはその代替案について議論し始めましたが、その中でも Containerd と Podman が大きな期待を集めていました。

Containerd は、シンプルさ、堅牢性、移植性を重視した業界標準のコンテナ ランタイムです。コンテナのライフサイクルを管理し、Kubernetes CRI などのプロジェクトで使用でき、広範な業界協力の基盤を築くことができます。

Podman はもともと CRI-O プロジェクトの一部でしたが、後に libpod と呼ばれる別のプロジェクトに分離されました。 Podman のユーザー エクスペリエンスは Docker と似ていますが、Podman にはデーモンがありません。コンテナは OCI ランタイム (デフォルトでは runc) を介して直接起動されるため、コンテナ プロセスは Podman の子プロセスになります。これは Linux の fork/exec モデルに似ていますが、Docker は C/S (クライアント/サーバー) モデルを使用します。

Docker は現在のコンテナ市場で依然として大きな割合を占めていますが、放棄される運命にあることは間違いありません。この移行期間中は、Containerd と Podman を採用したほうがよいでしょう。

これで、非推奨の Docker は Podman に置き換えられるかどうかについてのこの記事は終わりです。記事はこれで終わりです。Podman に代わる Docker についての詳細は、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続きご覧ください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。