Proxmox VEのLXC上でPodman Composeを良い感じに使う

コメントを残す

　我が家では、公式がAPTやRPMリポジトリを提供していないソリューションのデプロイに、アプリケーション毎にLXCを用意し、その上でDocker Composeを使うか、K8s基盤を利用しています。

　特にDockerに不満があるわけではないのですが、純正でwatchtowerのような機能を持っていたり、systemdとの相性が良かったりと、Podmanならではの機能がかなり気になったため、新規に構築するForgejoをUbuntu 26.04 LXCのPodman Composeで構築してみることにしました。

環境

  • Proxmox VE 9
  • Ubuntu 26.04 LTS
    • Unprivileged container: Yes
    • Features: nesting=1
  • Podman 5.7.0+ds2-3build1
  • Podman Compose 1.5.0-2

compose.yamlを記述する

　完全に本番環境と同じ設定ではありませんが、大まかには下記の通りです。

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:16-rootless
    user: 1000:1000
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo:/data
    ports:
      - '3000:3000'
    depends_on:
      - valkey
    labels:
      - io.containers.autoupdate=registry

  valkey:
    image: docker.io/valkey/valkey:alpine
    restart: always
    networks:
      - forgejo
    labels:
      - io.containers.autoupdate=registry

x-podman:
  pod_args:
    - "--infra=true"
    - "--share="
    - "[email protected]"

　上記の設定でlabelsを利用し、autoupdateの設定を入れています。しかし、正しく動くかはまだ検証していません。

　次セクションでも触れていますが、systemd Unitの名前を埋め込んでおく必要があります。podman-compose@と.serviceは固定で、forgejoの部分はcompose.yamlを置いたディレクトリ名になると思われます。記号を入れると面倒くさい事になると思いますが、最悪後から書き換えても問題ないです。

　また、x-podmanの箇所はauto-updateを使うためだけに使っているため、これを使わない場合は完全に削除しても問題ないです。その際は、各コンテナに設定しているio.containers.autoupdateラベルも削除してください。

systemdに登録する。

　Rootlessイメージを利用していますが、LXCの標準ユーザであるrootを使って作業します。本来は適当な作業ユーザを作り、当該ユーザで作業すべきでしょう。

　まず、systemdのユーザレベルサービスを有効にします。元々Rootで実行させるため、systemで起動させれば良いのですが、設定を変に弄るのは好きでは無いため、podman systemdが標準で生成するサービスにこちらから歩み寄る手法を取ります。

loginctl enable-linger root

　上記のコマンドを投入することで、rootユーザにおけるuserサービスが自動起動するようになる。

　続いて、podman-compose systemdコマンドを用いて、systemdのserviceを生成させる。これらのコマンドは、compose.yamlの置かれているディレクトリ上で実施する。サービス名にcompose.yamlが置かれているディレクトリの名前が使われるため、必要に応じて事前にリネームすると良い。もしかしたらnameでも変更できるのかもしれないが、今回は未検証。

podman-compose systemd -a create-unit
podman-compose systemd -a register

　上記の2コマンドで、/etc/systemd/user/にpodman-compose.serviceが出来上がるはずである。実際のサービス名は画面に出ている通り。最後に下記の2コマンドでサービスの起動を行う。

　もしroot以外のユーザを利用している場合は、--machine=のrootを書き換えれば良いと思われる。こちらも未検証。ホスト名は.hostで良い。

systemctl daemon-reload
systemctl [email protected] --user enable --now 'podman-compose@forgejo'

　成功すれば、見慣れたCreated symlinkのメッセージが出るだろう。これでPodmanライフが始まる。

Podman Auto updateを設定する

　導入して間もないため、これらの設定が意味を成しているのかは検証していない。

　取りあえず、下記のコマンドでauto-updateを定期実行してくれるようになる。

systemctl enable podman-auto-update.timer

　最後にpodman auto-update --dry-runで検証しよう。下記のように出力されたら問題ない。

            UNIT                            CONTAINER                        IMAGE                                     POLICY      UPDATED
            [email protected]  2217d37750f5 (forgejo_valkey_1)  docker.io/valkey/valkey:alpine            registry    false
            [email protected]  f2f63008375d (forgejo_server_1)  codeberg.org/forgejo/forgejo:16-rootless  registry    false

さいごに

　ここまで書いた上でこのような事を書くのもどうかと思うが、Dockerよりも手軽さは無いし、GitHubのとあるIssueを見ると、下記のような事が書かれていたりする。実際に触って見た感じでも、本来自動設定されるはずのPODMAN_SYSTEMD_UNITを手動で設定させられたりと、何だかなぁと思う部分が多い。

Side note. I think podman compose is a dead end project. Redhat seems to have refocused its efforts on quadlets. You can convert compose files to quadlet service files easily enough though.

― mholiv, https://github.com/containers/podman-compose/issues/534#issuecomment-2897749501

　また、本記事は自宅インフラに導入しているPodmanのデプロイ手順から、右往左往した部分を省略して記述している。もしかしたら過不足があるかもしれないので、注意してほしい。また、一部のトラブルシューティングと解決策はAIに言われたままの内容が含まれている。これらの修正がまともに動作することはある程度確認したが、ベストプラクティスではないかもしれない。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です