Podman+tunaclo+cockpit

CentOS8/podmanに初めて触れたのでやったことと感想など。

podmanとは何か？

podmanというのはred hat社が開発しているdocker対抗のコンテナランタイムであり、もちろんオープンソース。dockerがdocker daemonとお話しをしてコンテナを立ち上げるのに対し、podmanはデーモンとは話さずにコマンドとして動作する。まだお勉強が足らないが、今回ちょっと触った感想として。

Pros

- ユーザーモードで動作する

Cons

- デーモン化するにはsystemdと付き合う必要がある

ざっくりしすぎかもしれないけれどぶっちゃけ触る側からするとこんなものな感じ。ログに関するオプションが違うとかリスタートポリシーが違うとかdocker-compose相当のものがない（開発中？）とかそういうのは置いておいても結局systemdと向き合うのが面倒事な気がします。

今回の実験

Centos8の期待のWebUIであるCockpitをtunacloで試してみたいよねというノリなので、あえて（tunacloのマニュアルにもdockerしか載せてないけれども)podmanでやってみることにします。

構成として

client <----> tunaclo <--> firewall <---> VM(cockpit)

となります。tunacloの場合はcockpitとつながるようにエージェントをdockerで建てますけど dockerだとこんなコマンドになります。

 #sudo  docker run -d --restart=unless-stopped --log-opt max-size=20m --log-opt max-file=5
--name MyCockpitDemo-agent
tunacloac/backagent:v1.1.0 back_agent
-controller https://api.kuroshio.tunaclo.net -projectID XXX -agentID XXX -agentKey XXX

じゃぁこれをpodmanで建てるとどう書くのか。

systemd+podman

最終的にデーモン化するのでsystemdのunit fileを書きます。例えばこんな感じですね。これを/etc/systemd/system/tunaclo-cockpit.serviceとしておきます。

[Unit]
Description= Podman-tunaclo-for-cockpit in Systemd

[Service]
Restart=on-failure
ExecStartPre=/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=/usr/bin/podman login -u ${DOCKERIOUSER} -p ${DOCKERIOPASS} docker.io
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid -d docker.io/tunacloac/backagent back_agent -controller ${APISERVER} -projectID ${PROJECTID} -agentID ${SERVICEID} -agentKey ${SERVICEKEY}
ExecStop=/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

全体的にはtunacloのイメージがカギつきのdockerhubにあるのでpodmanでloginするところをStartExecPreに入れている当たりがポイントでしょうか。あとはsystemdが殺せるようにpidを保存したりですかね。ちなみに、type=simpleにするとSELinuxさんに怒られてnetworkを作成できませんでした。あとは、ログ関連のオプションやリスタートポリシーの見直しも必要ですね。上の状態だと環境変数が未解決なので /etc/systemd/system/tunaclo-cockpit.service.d/tunaclo.confとしておきましょう。

[Service]
Environment="PROJECTID=XXXXXXX"
Environment="APISERVER=https://api.kuroshio.tunaclo.net"
Environment="SERVICEID=XXXXXXX"
Environment="SERVICEKEY=XXXXXX"
Environment="DOCKERIOUSER=tunaclouser"
Environment="DOCKERIOPASS=XXXXXXXX"

こうすると、サービス起動時にフックされて環境変数を読んでくれます。

以下のように起動します

 #systemctl  daemon-reload
 #systemctl  start tunaclo-cockpit.service

cockpit

cockpitはsystem管理向けWebUIで、ログインして様子を見たり、ターミナルなどが取れますね。なかなかいい感じじゃないでしょうか。

一旦起動したらssh無しでもなんとかなる？？？？？？？？という感じですね。今回はtunaclo経由なのでportを開けずにつないだhttpsのclosed network越しに繋げてますから、まぁ安全。このあとスマホを使った２要素認証も入れましたし。

ちなみに、cockpitでは2要素認証としてgoogle-authenticatorを使った２要素認証ログインもできます。google-authenticatorはEPELにあるのでdnfでインストールをしてPAMの設定をするだけなのですが、selinux=enforcingだとcockpit経由の利用にはルールが足りませんでした。selinuxとはしばらく戯れることになりましたネ(遠い目.....
※RedHatは２要素認証はFreeIPA押しですね