Podman vs Docker: どちらを選ぶべきか?

仮想化とコンテナー化の世界に興味がある場合は、Podman と Docker に遭遇したことがあり、それらが互いにどう違うのか疑問に思っているかもしれません。

この投稿では、Docker と Podman の違いを探り、どちらが適切な選択かを見つけようとします!

ドッカー

Docker は、すべてのレベル (開発と展開) でプロジェクト内の依存関係の管理を容易にするコンテナー化テクノロジです。

Linux、Windows、および Mac OS で利用できる Docker のメカニズムは、コンテナとそのオーケストレーションを中心にしています。これが、コンテナ化が仮想化と異なるところです。

Docker には、Docker CLI と Docker Daemon という 2 つの主要なビルディング ブロックがあります。

Docker デーモン:

これは、Docker イメージ、コンテナー、ネットワーク、およびストレージ ボリュームの管理に役立つ一定のバックグラウンド プロセスです。 Docker は Docker Engine REST API を使用して、HTTP プロトコル経由でアクセスする Docker デーモンと対話します。

ドッカー CLI:

これは、Docker デーモンと対話するための Docker コマンド ライン クライアントです。 これは、Docker コマンドを実行するときに使用するものです。

Docker の動作は、Linux カーネルと、cgroup や名前空間など、このカーネルの機能に基づいています。 コンテナの目的は複数のプロセスとアプリケーションを別々に実行することであるため、これらの機能はプロセスを分離して、独立して実行できるようにします。

これにより、個別のシステムと比較してセキュリティ レベルを低下させることなく、インフラストラクチャの使用を最適化することが可能になります。

Docker などのすべてのコンテナー ツールには、イメージ ベースのデプロイ モデルが付属しています。 このモデルにより、アプリケーションまたは一連のサービスを複数の環境で簡単に共有できます。

さらに、Docker は、コンテナー環境内でのアプリケーションの展開を自動化するのに役立ちます。 これらのさまざまなツールを使用すると、ユーザーはアプリケーションへの完全なアクセスを取得し、展開を加速し、バージョンを制御して割り当てることができます。

ポッドマン

Podman (POD MANAger ) は、OCI コンテナーとコンテナー イメージを構築、実行、および管理します。 これは Red Hat によって開発され、当初はそのエンタープライズ Linux 8 を対象としていました。コンテナー管理に使用され、Docker の公式の後継として機能します。

その結果、Red Hat は Docker のサポートを中止しましたが、Podman は Docker に基づいているため、切り替えはユーザーにとって簡単であると保証しましたが、もともとはデバッグ ツールとしてのみ意図されていました。

libpod ライブラリを使用してコンテナ エコシステム全体を管理します。 Podman は Linux プラットフォームでのみ動作するため、REST API とクライアントは現在、Mac および Windows システムがサービスを呼び出せるように開発中です。

でも、   現在、Linux ベースの Podman サーバーとのリモート通信を可能にする Mac または Windows プラットフォームで動作する Varlink ベースのリモート クライアントがあります。 libpod ライブラリは、信頼やイメージ検証など、イメージを安全にアップロードするための複数の方法をサポートしています。

また、コンテナのグループをまとめて管理するポッドと、OCI および Docker イメージ形式を含む複数のイメージ形式もサポートしています。

非常に小規模で管理しやすい環境では、Podman は Kubernetes の前身として機能することさえできます。 これは、コンテナの誇大宣伝の初期からの個々のインスタンスの単一管理と、Kubernetes による最新のオーケストレーションとの間のギャップを埋めます。

野心的なコンテナ ユーザーは、ポッドで次のレベルを楽しむことができます。 Kubernetes クラスターの構築と運用は不要になります。 最も単純なケースでは、新しく設計されたポッドを個々の操作でテストして改善することができます。 その後の Kubernetes への移行も可能です。

コマンドpodman generate kubeは、対応する構成ファイルを提供します。 これらは、Kubernetes ツール kubectl の入力として 1 対 1 で機能します。

現在のバージョンの Podman では、systemd の構成ファイルを作成することもできます。これは、コンテナー オーケストレーションにユビキタスな init 後継者を使用するすべての人にとってはありがたいことです。

Podman と Docker: 違い

Docker は、コンテナー管理のホビーホースとしての地位を急速に確立しています。 ただし、Docker には多くの利点があり、何よりもイメージのレパートリーが急速に増加していることに加えて、欠点やセキュリティ リスクの可能性もあります。 さらに、Docker は Kubernetes のコンテナーとしてサポートされなくなりました。

仮想システムとは対照的に、コンテナーがカーネルを必要としないという事実は、通常、大きな利点の 1 つと見なされます。 ただし、Docker コンテナーは root 権限でしか実行できないため、Docker では重大なセキュリティ リスクが生じます。

これにより、コンテナで実行されているプロセスがルート権限でカーネルにアクセスできるようになり、ホスト システムが攻撃されます。

最初の違いは、最初に使用するときに明らかです。 Docker ではまず Docker デーモンを開始する必要がありますが、Podman コンテナーはコマンド ラインから直接開始できます。 したがって、バックグラウンド プロセスはなく、アプリケーションは必要な場合にのみ実行されます。

セキュリティの観点からは、デーモンがスーパーユーザー権限で 24 時間 365 日実行する必要がない場合、Podman は攻撃に対して脆弱ではないため、これは良いことです。 Podman は、Docker とは根本的に異なるアーキテクチャのため、バックグラウンド プロセスを必要としません。

Docker は、Docker クライアントが API を介して Docker デーモンと通信するクライアント サーバー モデルに従いますが、Podman は fork-exec モデルに従います。 各コンテナは Podman の子プロセスとして実行されます。

Podman を通常のユーザー権限で実行すると、最初の使用時にユーザー名前空間が作成されます。 ユーザー名前空間では、Podman は root 権限で実行され、ファイル システムをマウントしてコンテナーを作成する権限を持っています。

したがって、Podman コンテナーには、実行ユーザーが持つ権限しかありません。 ユーザー名前空間を使用すると、各ユーザーは独自のコンテナーを作成および管理できますが、これらは他のユーザーやスーパーユーザーには表示されません。

Podman は Docker とは独立して運用されるため、開発者は自由度が高く、コミュニティの要望に応えることができます。 Podman への興味深い追加には、mount/unmount コマンドと systemd 統合が含まれます。

ホストは、mount/unmount コマンドを使用してコンテナーのファイル システムをマウントできます。たとえば、ファイルにアクセスまたは変更してから、それらを再度アンマウントすることができます。

Podman を使用した Docker のデーモンが原因で、systemd を使用したコンテナーの監視は機能しませんが、systemd を介してコンテナーを開始、監視、および再起動することもできます。

さらに、Podman はpodman generate systemdコマンドを提供します。このコマンドは、それぞれのコンテナーに対応する systemd サービスを生成するため、ユーザーは systemd サービスを作成する必要がなくなります。つまり、ホスト システムでの統合が利用可能になります。

Podman と Docker のもう 1 つの重要な違いは、Docker は内部ネットワークを作成できるため、ファイアウォール ルールや現在の dnsmasq インストールを変更しないことです。 対照的に、Docker はコンテナー間通信を有効にするためにファイアウォール ルールを上書きする必要があります。

Docker から Podman にいつ移行する必要があるか

RHEL ベースの環境にコンテナーをデプロイする場合、RHEL ネイティブであるため、Podman を使用する以外に多くのオプションはありません。 コンテナーがほとんどない小規模なデプロイメントの場合は、Docker ではなく Podman に移行するか、Podman を選択することもできます。

ただし、それよりも複雑にしたい場合は、複数のコンテナーと、ネットワーク経由で docker-compose/podman-compose を使用して調整するコンテナーのスタックを用意してください。 ネットワークの処理がはるかに優れているため、Docker を使用することをお勧めします。

同様に、コンテナの世界に参入し始めたばかりの場合は、安定性が高く、適切なドキュメントが確立されており、Podman と比較して学習曲線が浅いため、Docker の方が適しています。明確に定義されたドキュメントがありません。

Podman から Docker への移行

コマンド ラインを使用している場合、Docker Engine から Podman に切り替えるのは非常に簡単です。 最も単純な場合、 $ alias docker=podmanコマンドはほとんどの場合機能します。

もちろん、これは適切なソフトウェアがシステムにインストールされていることを前提としています。 Linux の場合、これも問題ではありません。 既製のソフトウェア パッケージは、市販のディストリビューションで利用できます。

Windows または macOS は、サポートされているオペレーティング システムに含まれていません。 多くの Docker コマンドには Podman に相当するものがあるため、エイリアス アプローチが機能します。

ただし、一部の Docker コマンドは Podman の世界に対応するものがないため、例外もあります。 同様に、一部のコマンドは Docker と Podman ユニバースで動作が異なります。 現時点では、これはすでにセットアップされているボリュームの処理にのみ影響します。

Docker Desktop などのグラフィカル ツールを使用している場合、切り替えは少し難しくなります。 これは、Windows または macOS を使用する開発者に特に影響を与えるはずです。

Docker Desktop ユーザーはコマンド ラインに慣れる必要があります。これは Docker Compose にも当てはまります。 ただし、podman-compose プロジェクトがあります。 Python で書かれたこのソフトウェアは、Docker Compose の代わりとして機能します。

最後の言葉

Podman による Docker の置き換えは、ほぼ完了したと見なすことができます。 ユーザーと管理者にとって、この変更のほとんどの側面は簡単です。 多くの Docker 機能は、Podman に同等のものがあります。

本当の利点は、コンテナー グループの自然な使用は言うまでもなく、単一のデーモン プロセスとルート権限がないことです。 ただし、コンテナーに関しては Docker が引き続き主要なテクノロジであることに言及する価値がありますが、これは長期的には変化する可能性が高いです。

また、コンテナーを管理するためのいくつかの Docker コマンドを調べることもできます。