ポッドマンとドッカー: どちらを選択しますか?

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

この記事では、Docker と Podman の違いを調査し、どちらがあなたにとって正しい選択であるかを見つけていきます。

ドッカー

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

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

Docker には、Docker CLI と Docker Daemon という 2 つの主要な構成要素があります。

ドッカーデーモン:

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

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 プラットフォームでのみ動作するため、Mac および Windows システムからサービスを呼び出せるようにするための REST API とクライアントが現在開発中です。

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

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

非常に小規模で管理しやすい環境では、Podman は Kubernetes の前身として機能することもあります。これは、コンテナーが大流行した初期の個々のインスタンスの単一管理と、Kubernetes を使用した最新のオーケストレーションとの間のギャップを埋めます。

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

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

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

ポッドマンとドッカー: 違い

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

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

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

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

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

Docker はクライアント/サーバー モデルに従い、Docker クライアントは API 経由で Docker デーモンと通信しますが、Podman はフォーク実行モデルに従います。各コンテナは 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 つの決定的な違いは、後者は内部ネットワークを作成できるため、ファイアウォール ルールや現在の dnsmasq インストールを変更しないことです。対照的に、Docker はコンテナ間通信を可能にするためにファイアウォール ルールを上書きする必要があります。

	ポッドマン	ドッカー
建築	デーモン	デーモンレス
サービス管理	システムド	ドッカーエンジン
ファイアウォールの互換性	ファイアウォールルールを上書きします	ファイアウォールルールを尊重します
プラットホーム	Linuxのネイティブサポート	Linux、Windows、Mac

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

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

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

同様に、コンテナの世界に参入し始めたばかりの場合、Docker は安定しており、適切なドキュメントが十分に確立されており、まだ安定性と安定性に欠ける Podman に比べて学習曲線が浅いため、より良い選択肢となります。明確に定義されたドキュメントがありません。

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 の代替として機能します。

最後の言葉

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

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

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