Podman移行を実験中

メイン開発環境をDockerからPodmanに移行できないかを検証中です。 PodmanはRedhat系のOCIランタイムで、以下の利点があります。

  • デフォルトでルートレスモードになる
  • デーモンがない（正確にはあるがほぼ関係ない）
  • 挙動が体感的に軽快
  • 基本的にオープンソースであり、個人法人に限らずライセンス課金が発生しない
  • Linux Desktopでの導入が楽でUIが綺麗
  • Desktop版でコンテナの削除やターミナルインが出来る為、Docker Desktopと似た使い心地

Ranchar Desktopは微妙と判断し、こちらをとりあえずメインにしようと考えています。

ただし、やっぱり使い心地で言えばDockerの方が良いです。

  • compose.ymlが意外と互換性がなさそう
  • パス問題でWSLディストリビューションからのアタッチが困難
  • Visual Studioの連携機能はDocker Desktopを前提にしていて.NET周りでは使えない

という所が現在の問題でしょうか。

どちらかと言うよりDockerよりマイクロソフト技術に依存が大きいタイプなので、マイクロソフトが頑張って的なところが多いです。

現状の問題としては、PodmanにしたことでWindowsからダイレクトでコンテナを立ち上げる必要性が出てきたことです。この為、いくつかのリポジトリで対応に迫られています。 ただ、リポジトリが悪くなることはないので、むしろ良くなる学びのチャンスを得ているとも言えるでしょう。

.gitattributesと.editorconfig

Windowsからのコンテナ開発が迫られた、と言うことで大きな問題が出てきたのは改行問題です。 具体的には.gitconfigのcore.autocrlfをWindowsはtrue、Linuxはinputと設定している為、Windowsでgit cloneした場合にまずファイルがCRLFで展開され、コンテナアタッチした状態でもそうなってしまうことが問題です(コミットはLFになるのでワークツリー自体には大抵問題はない)。

この私の設定自体はGitHubの推奨設定を元にしています。

ただし、メインの開発が私の場合コンテナが多くなったとは言え、ローカルのWindowsでの開発はバッチファイルを中心にCRLFでないと実行できないと困るので、この設定は維持する必要があります。それでも、Linux環境などでの実行がCRLF展開されてると困ります。具体的に問題にブチ当たったのはPython系のリポジトリです。なんとPythonってUnix系でCRLFのファイルが絡んでるだけで動作しないらしい。なんてポンコツなんだ。 その為、.gitattributesと.editorconfigを設定しておいた方が良いと渋々学びました。

.NETやWindows系技術に絡まない場合、.gitattributesを作成し、次のように設定しておくと良いです。

* text=auto eol=lf

*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

*.sh text eol=lf

これは通常のファイルおよびLinux系シェルファイルにはLFを強制し、バッチファイルのEOLにCRLFを強制する制約になります。この内容を作成しておけば、競合問題は一気に起こりにくくなります。画像とかバイナリファイルが必要になる都度設定しましょう。Visual Studio系のやつはテンプレートがあるので、それ使えば問題ないと思います。

同様に.editorconfigも設定しておくと更に良いです。

root = true

[*]
end_of_line = lf

これによって、VSCode（拡張機能を入れておく）やVisual Studioでは基本的なファイル保存がLFで効く。エディターコンフィグは稀に気分でしか入れてなかったので、これはちゃんと入れときましょう、と感じました。

更なる話として、core.safecrlfと言う設定があることを知りました。 これはLF変換が発生する場合に不可逆性が発生する場合、コミットの警告ないし中止をするオプションだそうです。

これが良いオプションなのかはちょっと掴めてないんですが、恐らく保全的に使えそうかもしれないので以下のように共通して反映するように一旦設定しています。

git config --global core.safecrlf warn

パーミッション問題

次に問題になるのはパーミッション問題で、devContainerで起動したファイルの所有権がrootになることでコンテナユーザと異なるので、編集できない問題がありました。 これはdevcontainer.jsonで以下の設定をすると解決できます。

"remoteUser": "vscode",
"runArgs": ["--userns=keep-id:uid=1000,gid=1000"],
"containerUser": "vscode",

特に重要なのは下2つだが、これは全てセットでやった方が良い。 具体的には「コンテナ内のプロセスの起動に使用するユーザー」「コンテナを起動するユーザー」「コンテナ内のユーザID、グループID」を全て明示的に指定することで一貫性を保つようにする。 これによってコンテナ内の所有ユーザがvscodeにすり替わり、それがホスト側の操作ユーザと同一になります。

とは言え、特にrunArgsの方なんですが、このオプション、Podman独自なんですよね。こうなると互換性が、、うむむ。。

うーん、、意外とメンドウですねえ。Dockerってなんだかんだでデファクト中のデファクトって感じが物凄くしちゃう。Podmanって所詮ジェネリックなのかって感じる苦しさよ。

しかしながら、長期目で見るととりあえずPodmanに賭けてみるのは勉強になるかも知れませんので、暫くの間維持してみようと思います。