しばらくの間、DockerをエグゼキュータとしてGitLabRunnerを使用するプロジェクトに取り組んできました。ランナーはCentOS7でホストされているため、CentOS 8への移行を検討し始め、世界が爆発するまで、すべてが理にかなっています。
私たちが最初に考えたのは、Podmanはドロップインの代替品であるため、これは簡単なはずです（そのステートメントの信憑性を自分で想像できます）。実のところ、PodmanにはGitLab Runnerがコンテナーを管理するために使用するAPIがなかったため、すべてを手動で実行できたとしても、まだそこにはいませんでした。
さて、設計図に戻りましょう。GitLabRunnerにGitLabの問題を提出して、Podmanをエグゼキュータとして実装するのはどうでしょうか。問題はすでに存在していたことが判明しました。言い換えると、「私たちは新しいエグゼキュータを採用していませんが、自分で作成すれば、採用できるかどうかを確認できます」というものでした。 GitLab Runnerの内部に関する私の知識は、ドイツ語よりも劣っています。私が言えるのは、「ダンケ」だけであり、単語全体ではありません。
自宅でこれを試さないでください
この「単純な」移行は何でもありましたが、最後の手段として、CentOS8にDockerをインストールする方法が必要だと考えました。ええと、それを行ういくつかの「チュートリアル」を読むことができますが、それらはあなたに目を釘付けにしたくなるので、それはオプションではありませんでした。 （真剣に、これを家で試さないでください。）
[次のこともお勧めします：Podman2.0とのsystemd統合の改善]
しばらく経ちましたが、一時的に緊急性の高い別のプロジェクトに移りました。すべてをCentOS8に移行したかったのですが、急ぐ必要はありませんでした。
しかし、数か月前、PodmanがDocker互換のRESTAPIを実装しているという投稿を見つけました。彼らが私たちの心を読んでいるように感じました。これはまさに私たちが必要としていたものです。これは今では簡単なはずです。 （これでどこに行くのかわかりますよね？）
Podman 2.0がリリースされたとき、私たちは再びテストを開始しました。すべてが幸せで楽観的です。 GitLab Runnerはソケットに接続していましたが、ボリュームの作成に失敗しました。次に、リリースノートを注意深く読み、ボリュームのエンドポイントはまだ実装されていないと言われましたが、メインツリーにありました（まもなく2.1になります）。ですから、まだチャンスがありました。
ハッキーなバックポート
数日が経ちました。ボリュームエンドポイントのハッキーなバックポートを2.0に作成し、メインブランチも試しましたが、すべてが失敗し、理由がわかりませんでした。
幸い、Podman 2.1はすぐにリリースされ、順調に戻ってきました。再開しましたが、今回は別のアプローチを取りました。対応するPodmanの問題について少しコメントした後、IRCの#podmanでぶらぶらして、この問題について質問し始めました。開発者からいくつかの回答を得ました。そのとき、物事が面白くなりました。
GitLabにテストリポジトリを設定し、多数のランナーを登録して、すべての問題に1つずつ取り組み始めました。また、ベースラインとして使用するDockerインスタンスを設定しましたが、 socatを使用してGitLabRunnerとのすべての通信を監視しました —そうすることで、何が起こっているのか、何を一致させる必要があるのかを正確に確認できました。
私たちは仕事がうまくいったように見える問題から始めましたが、実際には何もしていませんでした。最悪の場合、何もログに記録されていなかったため、最初にログを修正してから、メインの問題に戻る必要がありました。それが邪魔にならないように、/devエントリに別の問題がありました。これも解決されました。数日間のテストの後、物事は本当に良く見え始めていました。簡単なワンライナーを問題なく走らせることができました。完了したと思ったのですが、実際にはまだ少し道のりがありました。
実行時間の長いジョブに移行したとき、アイドル接続の追跡の問題により、ジョブは途中でカットされていました。これを修正すると、Podmanが閉じないという別の問題が発生しましたが、Podmanのメンテナはこれらの問題の両方に対処しました。
バグのバグ
ただし、最初から私たちを悩ませていた問題が1つありました。それは、実行するたびにボリュームを削除する必要があったことです。互換性について誰も教えてくれないのは、これを実現するには、バグごとに互換性がなければならない場合があるということです。 Dockerには、5年以上前に提出された問題があります。これは、既存のボリュームを作成するように要求すると、「すべて正常」に戻り、何も起こらなかったように動作するという事実です。一方、Podmanは正しいエラーメッセージを返していました（少なくとも互換モードでは、Dockerと同じように動作するため、「was」が強調されています。バグごとですよね？）
これらの大きな問題が邪魔にならないため、いくつかの小さな問題が発生しましたが、少なくともテストできる限り、すべてがスムーズに実行されていました。
[APIオーナーズマニュアル：効果的なAPIプログラムの7つのベストプラクティス]
まとめ
では、今はどうですか？さて、私たちがPodmanで遭遇したすべての問題は、現在メインブランチで修正されており、すべてがうまくいけば、Podman2.2の次のリリースの一部になるでしょう。これは、Podmanと通信していることを知らなくても、GitLabRunnerですぐに実行できる最初のPodmanリリースになります。それは私たちにとって本当に大きなマイルストーンです。