バックストーリーとしてのCRI-O
Linuxコンテナーの現代の世界を見ると、今日の記事のトピックがRed Hatの長期戦略の段階の1つにすぎないことが容易にわかります。 これを鮮明に確認できるのが、 約1年前に書い たCRI-Oプロジェクトです。 つまり、CRI-Oは、OCI標準（Open Container Initiative）と互換性のあるコンテナーランタイムを起動するためのKubernetes CRI（コンテナーランタイムインターフェイス）インターフェイスの実装です。 さらに短くすると、これはKubernetesのランタイムとしてのDockerの代わりになります。 （Docker IncのK8に対する技術的に類似したイニシアチブはcri-containerdであり、これについても記述しました。同じ記事で、これら2つのソリューションのパフォーマンスの比較があります。）
CRI-Oの歴史は、OCIがコンテナの標準（ ランタイム仕様とイメージ仕様 ）を準備している間に（ 偶然にもRed Hatの参加で起こった）、 OCIDと呼ばれる新しいプロジェクトが作成され、RHのKubernetesインキュベーターに置かれました（ Open Container Initiative Daemon）は、後に[OCIからリクエストされた] CRI-Oに名前が変更されました。 その目的は「Kubernetesのコンテナのランタイム環境の標準インターフェースの実装」であり、「技術的な大衆」のプロモーションは、コンテナのオペレーティングシステムを作成する大規模プロジェクトRed Hatの一部として行われました-Project Atomic 。
KubeCon + CloudNativeCon North America 2017のCRI-Oロゴ付きキャップ
過去、CRI-Oはバージョン1.0に成熟し、Minikubeでサポートを受けました。その最後の成果は、競合コミュニティ（Red Hat）によって開発されたKubicプロジェクトのインターフェースとしてデフォルトコンテナコンテナを採用したことです。 Linuxディストリビューション-openSUSE。
記事のトピックに戻る：PodmanはもともとCRI-Oの一部でした。
ポッドマンの外観と本質
ポッドマンプロジェクト（名前は「ポッドマネージャー」の略）の公式発表は、今年2月に行われました。
「ポッドマン（旧称kpod）は昨年の夏から存在しています。 当初は、 CRI-Oプロジェクトの一部でした。 podmanを別のプロジェクトlibpodに割り当てました。 ポッドマンとCRI-Oの両方がそれぞれのペースで成長することを望んでいました。 両方とも、個別に（独立したユーティリティとして）一緒に、そして一緒に素晴らしい動作をします。
このため、発表自体は「 再導入」と題されていました。 そして、この発表の2週間前にPodmanの最初の公開リリースv0.2が行われました。 ポッドマンの本質は何ですか？
Podmanの目標は、オーケストレーションシステムの外部でコンテナーを起動するためのコンソールインターフェイスを提供することです。 起動されたコンテナは、共通の名前空間を持つ特別なグループに結合できることは注目に値します。 ポッド-この概念はKubernetesのおかげですでによく知られています。 このプロジェクトはUNIXコマンドのイデオロギーに従います。各ユーティリティは1つのことだけを行いますが、良いことです。 開発者がたゆまぬ力で強調しているもう1つの重要な詳細は、上記の発表ですでに引用されています。PodmanはCRI-Oと独立して使用できます。
一般的に、Podmanの主なアイデアは、コンテナランタイムとしてCRI-Oを選択したKubernetesユーザーに、Docker CLIコンソールインターフェイスの類似物を提供することです（クラスターで実行されているコンテナーおよびイメージと対話するため）：
「ポッドマンは、Docker 1.13で定義された40個のDocker CLIコマンドのうち38個を実装しています（2月の発表時- およそTransl。 ）が、それらのいくつかは特に繰り返しませんでした。 たとえば、Docker Swarmに関連付けられているもの-代わりに、オーケストレーションが必要なポッド/コンテナの場合、Kubernetesを使用することをお勧めします。 また、ボリュームプラグインやネットワーク用など、Dockerプラグイン用の一部のコマンドは実装されていません。 PodmanコマンドとDockerでの同等のコマンドの完全なリストは、 Podman Usage Transferページにあります。
DockerコマンドとPodmanコマンドの比較テーブルの断片：ほとんどは同じですが、違いもあります
ただし、インターフェイスのこの目に見えるアイデンティティの背後には、アーキテクチャの根本的な違いがあります：Docker CLIがDockerデーモンと通信してコマンドを実行する場合、Podmanはその作業にデーモンを必要としないスタンドアロンユーティリティです。
少なくともこのアーキテクチャの違いにより、PodmanをDockerそのものではなく、 cri-toolsのコンソールユーティリティであるcrictlと比較する方が正しいでしょう（特にcontainerdとKubernetesの統合に使用されます ）。 また、機能上の違いもあります。Podmanは停止したコンテナーを再起動でき、コンテナーイメージの管理も提供します。 （より詳細な比較については、 OpenShiftブログを参照してください。）
Fedora 28 Atomic Hostのリリース （5月）に伴い、PodmanはこのLinuxディストリビューションのデフォルトのコンテナー管理ツールになりました。 そしてごく最近、9月にLinux会議All Systems Go！で開催されました。 ベルリンでは、Red Hat Container Engineeringチームの責任者であるDan WalshがPodmanをさらに多くの聴衆に紹介しました-パフォーマンスの記録はここで見ることができます （ ここでのプレゼンテーションのみ）。
All Systems Go！でのポッドマンプレゼンテーション 2018年
テクニカルノート
Podmanの最新リリースはv0.10.1.3 （10月18日付）であり、新機能を備えた最新版はv0.10.1 （10月12日）であり、いくつかの新しいチームと追加のフラグが組み込まれています。
PodmanコードはGoで記述され、無料のApache License 2.0の下で配布されます。 すぐにインストールできるパッケージは、Fedoraバージョン27以降で利用できます（Ubuntuのインストールガイドもあります）。 Podmanが動作するための依存コンポーネントには、 runcやconmonなどのLinuxコンテナ用のユーティリティ、およびCNIネットワークプラグインがあります 。
コンテナをPodmanで起動してから作業することは、通常の
docker
使用シナリオに似ています：
$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \ -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \ -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd $ sudo podman ps ... $ sudo podman inspect -l ... $ sudo podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" $ sudo podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
Podmanの実用的な紹介として、Katacodaの適切なオンラインスクリプト「 Dockerのないコンテナ-PodmanとLibpodを使用したコンテナの起動 」を使用することもできます。
最後に、 pypodmanプロジェクトは活発に開発中であり、Podmanコマンドのリモート実行用のPythonインターフェイスを提供していますが、特筆に値します。
ポッドマンだけでなく：libpodとエコシステム
Podmanとともに、この記事ではlibpodプロジェクトについて繰り返し言及しています。 違いは何ですか？
Red Hatの「完全な」プロジェクトについて話すと、実際にはlibpodと呼ばれ 、その名前でGitHubでホストされます 。 現在、libpodは「Kubernetesによって普及しているコンテナ炉床の概念で動作する必要があるアプリケーションのライブラリ」として位置付けられています。 また、Podman自体はlibpodライブラリの一部であるユーティリティです。
コンテナのより広い視野に戻ると、Red Hatには独自のビジョンがあり、あらゆる場面でユーティリティのセット全体が実現します。 それらのほとんどはgithub.com/containersという名前のリポジトリに集中しており、これだけでも会社の明白な野望をすでに示しています（ところで、これらのプロジェクトの一部はgithub.com/projectatomicにありました ） 。
コンテナエコシステムの標準化と開発に関するRed Hatの見解は、libpodプロジェクトのREADMEに直接明記されています。
これらのプロジェクト（runc、containers / image、containers / storage、CNI、conmon）のほぼすべてについてCRI-Oレビューですでに書いていますが、それ以降buildahと呼ばれるコンテナイメージを構築するためのユーティリティになりました。 さらに、Red Hatは、SELinuxを生成するためのudicaや、リモートイメージレジストリを操作するためのskopeoセキュリティプロファイルなど、現代のコンテナの世界のいくつかのニーズに対する既製の回答をすでに持っています。
要約する
Red HatがOpenShiftコンテナのエンタープライズプラットフォームの背後にあるだけでなく、基盤となるオープンソースプロジェクトKubernetesの活動に積極的に参加しているように、アメリカの企業はより基本的なレベルで現代のITインフラストラクチャに対する見解を実現しています-コンテナ自体、DevOpsおよびSREのエンジニアは、オーケストレーションに非常に関心を持っています。 Podmanとlibpodは、Red Hatがオープンスタンダードコンテナの世界で構築しているエコシステム全体の重要なコンポーネントです。 何が起こっているのかを見ると、ハイブリッドクラウドの分野でソリューションのリーディングプロバイダーを形成するためのイニシアチブとして提示されているIBMとの契約は、業界全体でさらに興味深いように見えます...
最後に、この記事が登場する前に、ポッドマンプロジェクトに関するHabraの読者の知識に関する小さな調査を提案します。 参加してくれてありがとう！
PS
ブログもご覧ください。
- 「 CRI-O-Kubernetesでコンテナを起動するためのDockerの代替品 」;
- 「 コンテナ化されたコンテナとKubernetesの統合は、Dockerに取って代わり、本番環境で使用できます」;
- 「 Mobyプロジェクトの本質は何ですか。なぜmoby / mobyが突然メインDockerリポジトリになったのですか？ ";
- 「 Dockerイメージを構築するためのゼロからのLinuxディストリビューション-dappdepsでの経験 」;
- “ 最小のDockerイメージ-1000バイト未満 ”;
- 「 Container Networking Interface（CNI）は、Linuxコンテナのネットワークインターフェイスおよび標準です 。」