シルバーウィークのお家サーバーのGitOps

Posted at 2026-09-23

5連休だ！！

シルバーウィーク。ある程度することはあるけど、時間もそれなりにある・・・
ということで、ずっと気になっていたセルフホストの自動化を決行

気になっていた参考ブログ

komodoのrpeo
komo.doって公式URLもよい

下記のような形で現在は5つのサーバーに対して色々なdocker composeによるサービスが稼働している。
基本的に1サーバーにつき1つのrepoを作成、その中でサービス別にcompose.ymlを作成し、管理。

バージョンの更新についてはForgejo上でrenovateを使って定期的にバージョン更新のPRをマージする流れ。

最初は一つのサーバーから始まり、結果的に色々増えたわけですが、最初はやはりSSHで直接更新していました。

ssh server-**
cd tool/<service-name>/
docker compose pull
docker compose up -d

次第にサーバーも増えて、面倒になりました...

Ansibleを使うようになりました。
といっても、サービス数が多いServerAだけ。
Forgejo Runnerを使って、mainにマージされた時や、Cronによる定期的な更新、手動のディスパッチのタイミングなど、タイミングは調整しながら自動化できました。

便利になった。でもSSHキーは管理しておかないといけないのが少し嫌だった。。。

フローのイメージ

※最初はサーバーAでRunnerも動かしてたけど、依存関係でForgejo系サービスはAnsibleで更新できないなどのトラブル多数...

Komodo + Komodo Agent(periphery)によるForgejoのPushをトリガーにしたWebhook連携

ちょーすごい(語彙力)

あ、ちなみにkomodo本体の管理はいまのところ手動を予定しています。
komodoはForgejo Runnerから更新してもいいけどね...

全てのサーバーでAgentさえインストールすれば、あとはtomlの定義だけで完結する
- 自分で認証方式の管理も不要
- 差分検知もお手頃(Ansible時代はgit diffから差分を取得していた)
komodoのwebuiからターミナル操作も可能
CronJobもkomodo管理にできる
- task系がサーバー別の管理をする必要がなく、Git repoをベースにtomlファイルの定義だけで定期実行が可能になった
  - バックアップ処理系は全部komodoに移行しました
- ステータスの管理もkomodoから完結する

サービスを大量に抱えつつ(といってもユーザーは自分だけ)、komodoに合わせて移行するのが少し面倒だった。

というのも$HOME/toolというdirでの運用、.envを使う、mountポイント、labelの管理など、それなりにルールの徹底はしていたが、
Agentはroot権限で実行されるため、komodo likeにするのか、既存のルールを引き継ぐかが悩みどころだった

AIにssh権限も渡しつつ、komodoの実装も確認した上で、komodo like(/etc/komodo/repos/<user>/<repo>/)に運用することに決定。
事前に.envなどの必要なファイル・ディレクトリのコピーもAIに指示を出したことで、手間自体はほぼほぼなかった。

最初は手動でkomodoをポチポチしていたのですが、terraform管理できねぇの？！と思い調べると、やはり変態(ひどい)はどこにでもいるもので。。。

komodoのプロバイダー(sebastianfs82/komodo)とforgejoのプロバイダー(svalabs/forgejo)がありました

下記のような感じで管理。
新しいサーバーを導入するときも事前にAgentさえ入れておけば、variablesに、repo, server, tomlのパスを追加することでWebHookの設定なども不要になる。

ということで、いまのところ最強(笑)なGitOpsが完成

Jevとかの話題も良いのですが、AI疲れは否めなかったので自宅鯖の環境が整理できてよかったです。
今回はあまりブログ自体は見てなかったけど、先駆者がいる、というのはとても助かる