はじめに
「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。
前回は”K8sの機能を理解する”！としてK8sの機能について図解で説明しました。今回はdockerコンテナに置き換わるであろうPodmanについて概要を説明したいと思います。
このBlogでは、DXソリューションを担当する営業の方を少しでも支援できるように分かりやすくご紹介します。参考にしてください。
第一回記事：「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事：「DXを売る」”DXに関心を持たせる” 営業トーク 」
第三回記事：「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事：「DXを売る」”IT自動化とDX推進を繋げる５つのポイント”
第五回記事：「DXを売る」営業の素朴な疑問 ”コンテナってどこでも動くの？”
第六回記事：「DXを売る」営業の素朴な疑問 ”サイドカーって何モノ？”
第七回記事：「DXを売る」営業の素朴な疑問 ”コンテナ向けOSって何？”
第八回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（1/2）
第九回記事：「DXを売る」DX営業”OpenShiftの特徴を説明できる?”（2/2）
第10回記事：「DXを売る」DX営業 ”サービスメッシュ” を説明できる?
第11回記事：「DXを売る」DX営業 ”API連携とは何？”を理解する
第12回記事：「DXを売る」DX営業 ”APIマネージメントとは？” を理解する！
第13回記事：「DXを売る」DX営業 ”K8sの機能を理解する”！
第14回記事：「DXを売る」DX営業 ”Podmanを知っている？”
第15回記事：「DXを売る」DX営業 ”Pod”についての理解
【その１】dockerはどうなってしまうのか？
私がPodmanというワードを初めて耳にしたときは、Red Hat社で実施された”RHELの戦略について” Red Hat Enterprise Linux（以後、RHELと省略）の責任者から話を聞いた時でした。まだRHEL7が最新バージョンのときです。（現在はRHEL8）
衝撃的だったことを思い出します。「Dockerはエンタープライズには不向きで、RHEL8からはPodmanに置き換わると！！」
案の定、
＊RHEL8からDockerはRHELに同梱されなくなりました
＊Kubernetes1.20から始まったdocker非推奨化となる
以上のことから、Red Hat都合でDockerをサポート対象外にしただけではないような気がします。ディファクトだと思っていたDockerコンテナの時代が変わるかもしれません。
【その2】Podmanとは何者じゃ？
コンテナといえば”Docker”というようにメジャーになったDockerですが、”Podman”がいつメジャーになるのか？ 個人的には少し不安です。
余談ですが、ロゴは Dockerが”くじら”でしたが、Podmanは”アザラシ”です。
どちらが親しみやすいキャラなのか？は本題とは関係ありませんが、個人的にはくじらの方が好きかな？ 正直、このロゴを見てアザラシとわかる人は少ないかもしれません。少なくとも私は勝手にモグラだと思っていましたが、土盛りではなく水面のような気がしてサイトをいろいろ調べました。
うんちくになりますが、”アザラシのグループはポッドと呼ばれる” そうですよ！！
まず、Podmanの特徴や経緯を知りましょう！
- Red Hat社を中心としたコミュニティが開発しているもの
- PodmanはDockerデーモンを使用しない
- Docker互換のコンテナエンジン（Dockerコマンドが使えるなど）である
- DockerコンテナイメージはPodman環境でも動く
- しかしPodmanで作成されたコンテナイメージはDocker環境では動かない
（Podmanから生成されたコンテナイメージはDockerコンテナイメージではない）
- 使い勝手は、Dockerとそれほど変わらない（ほぼ同じ）
- ベンチマークは、それほど起動速度に大きな差はないが、Dockerの方が気持ち速い（計測条件やVersionにより異なる）
- リリースサイクルは、Podmanの方が頻繁
- セキュリティは、DockerもPodmanもセキュリティ強化する機能を実装しているが、リリースサイクルがPodmanの方が頻繁なので少し安心かも
このままだと、差がほとんどわかりません。
そこで、Podmanの特徴を調べてみました（Publickeyから引用）
- Rootless containers
Podmanはコマンド実行にdaemonを用いず、ルート権限などを要求しないことで運用などを容易にしている - Support for pods
複数のコンテナをグループ化した「Pod」もサポート - Interacting with Kubernetes pod YAML
Podを定義するYAMLファイルにも対応 - A Varlink API for interacting with Podman on remote machines
リモートマシン上のPodmanに対してVarlinkで記述されたAPI経由での操作にも対応 - セキュリティの強化
Rootlessコンテナだけでなく多くのセキュリティ機能を実装。さらにユーザー名前空間のサポートで、より優れた分離も実現
【その３】なぜRed Hatは、Podmanへ切り替えるのか？
Podman開発の中心となるRed Hat社が投稿している”赤帽ブログ”にわかりやすく記述されていたので、営業向けに要点だけピックアップしてみました。
Dockerの利用が増加してくるにあたり、以下の問題が出てきたようです。
- Dockerは、Dockerデーモンを中心に動作することから
- 1つのプロセスが1つの障害点になる可能性がある
- このプロセスはすべての子プロセス(実行中のコンテナ)を所有する
- 障害が発生した場合、孤児(orphan)となるプロセスが存在する
- すべてのDockerの操作は、同一の完全なroot権限を持つユーザーによって行われなければならなかった
- Podmanは、これらの問題を改善するために開発された。さらにPodmanには
- Dockerにない機能が含まれている
- Kubernetes環境で開発者や運用者を支援するいくつかの追加機能がある
- この機能はDockerでは利用できないものが含まれている
- Dockerにない機能が含まれている
以上から、コンテナをエンタープライズ環境でセキュアにある程度の規模でK8sを使って運用することを想定すれば、DockerよりもPodmanが適すると思われます。
以下に、DockerとPodmanの抽象的な構造を示します。
【まとめ】
- セキュアにエンタープライズ環境でK8s/OpsnShift上でコンテナを運用するならば、Podmanを利用するほうがよい
- 小規模の場合や開発環境でDockerを使うのは今のところ問題なさそう
- Podmanのキャラクターは、モグラではなく、アザラシである（笑うか呆れるところです）
”アザラシのグループはポッドと呼ばれる” Wow！
以上、今回も文字が多くてごめんなさい。m(_ _)m
今回のBlogの内容はお役に立ちましたでしょうか？
今後のBlog記事に関するご要望や実際のビジネスでのご相談事などございましたらお問合せいただきますようお願いいたします。最後まで読んでいただきありがとうございました。
