dotfiles にも CI を — 破壊的インストーラの冪等性を Ubuntu と Kali の二役で検証する

Sat, 04 Jul 2026 10:00:00 +0900

自分の開発環境が、ある日再現できなくなる

開発環境を1本のスクリプトにまとめている。シェル設定・プロンプト・ターミナルマルチプレクサ・言語ランタイム・クラウドCLIを、./setup_env.sh 一発で入れる。最終的に 1,358 行になった。新しいマシンでも、OS を入れ直した後でも、同じ環境がすぐ戻ってくる。便利だ。

便利なのだが、ひとつ不安が残った。今度は そのスクリプト自体が壊れたときに気づけない。うっかり片方の OS でしか通らない書き方をしても、次にそのマシンを触るまで分からない。設定ファイルを追記する処理が既存の .zshrc を壊しても、実際に事故ってから気づく。手作業をスクリプトにまとめた結果、こんどはその 1 本のスクリプトに、環境の再現を丸ごと預けることになった。

それで、dotfiles にも CI をつけた。やることは本番インフラの検証と変わらない。「危険な変更が入ったら、その場で赤くする」 を、開発環境の構築スクリプトに対してやる。この記事では、その CI（GitHub Actions）を抜粋して紹介する。リポジトリ固有の名前やレイアウト名は伏せるか一般化し、コードは要点を示す抜粋にしてある。

数字で見た中身

実環境の中身は出せないので、代わりに構成の規模で示す。以下はこの dotfiles と CI を実測した値だ。

指標	値
`setup_env.sh` 行数（単一エントリポイント）	1,358
CI ジョブ（builder / breaker / aggregate）	3
検証環境（Ubuntu runner / Kali コンテナ）	2
`scripts/ci/validate_*` チェッカ	14
CI で生成検証する Zellij レイアウト（総数9本のうち）	8
インストーラ検証の段階（dry-run → 実行 → `--clean` 再構築）	3

全体構成

 push / PR / dispatch
 │
 ┌────────────────┴────────────────┐
 ▼ ▼
 ┌──────────────────────┐ ┌──────────────────────────┐
 │ builder (Ubuntu) │ │ breaker (Kali container) │
 │ shellcheck / clippy │ │ shellcheck / clippy │
 │ setup --dry-run │ │ setup --dry-run │
 │ 隔離HOMEで実インストール │ │ 隔離HOMEで実インストール │
 │ --clean で再構築 │ │ --clean で再構築 │
 │ layout ×4 を assert │ │ layout ×4 を assert │
 └──────────┬───────────┘ └────────────┬─────────────┘
 │ report (artifact) │ report (artifact)
 └────────────────┬──────────────────┘
 ▼
 ┌──────────────────────┐
 │ aggregate │
 │ 2環境のレポートを統合 │
 │ → CI step summary │
 └──────────────────────┘

CI は 3 ジョブに分けている。同じインストーラを 2 つの OS で流す builder と breaker、そして両者のレポートを 1 枚にまとめる aggregate だ。

homelab を Ansible でコード化する — fail-closed な多層防御インフラ

Mon, 15 Jun 2026 10:00:00 +0900

自宅サーバを丸ごとコードにした話

自宅サーバ（homelab）で AI エージェント基盤を動かすために、コンテナランタイム、ネットワーク分離、暗号化DNS、カーネル緩和、監査ログまで一通り手で組んだ。動くには動いたのだが、ひとつ不安が残った。OS を入れ直したとき、同じものをもう一度作れる自信が無かったのだ。どこをどう直したか、どのセキュリティ設定を入れ忘れているか、結局は頭の中にしか無い。

それで、構築手順そのものを Ansible に落とした。最終的に9ロール・約3,900行になった。手順をコードにしただけではなくて、「危険な設定なら構築を止める」ところまで踏み込んでいる。空の許可リストや古い Podman で進もうとすると、playbook が走り出す前に assert が落とす。

この記事では、その構成（rootless Podman + Quadlet による多層防御 homelab）を抜粋して紹介する。実環境のホスト名・IP・ユーザ名・トークン・コンポーネント名のたぐいは伏せるか一般化し、コードも要点を示す抜粋にしてある。固有名が絡むところは変数名やファイル名を一般化し、汎用的で機微に関わらないところは実物に近い形で残した。

数字で見た中身

実環境の中身は出せないので、代わりにコードの規模で示す。以下はこの Ansible 構成を実測した値だ。

指標	値
Ansible ロール数	9
`roles/*/tasks/main.yml` 総行数	3,898
fail-closed な `assert` 箇所	13
分離ネットワーク（内部用 / 外部egress用）	2
Quadlet コンテナユニット	8

全体構成

┌─────────────┐ ansible-playbook ┌──────────────────────────────┐
│ 司令ホスト │ ───── over SSH ─────▶ │ 本番ホスト (target) │
│ (operator) │ apply --tags … │ │
└─────────────┘ │ ┌────────────────────────┐ │
 │ │ bootstrap: OS/pkg/UFW │ │
 │ │ /DoT/helpers │ │
 │ ├────────────────────────┤ │
 │ │ podman 5.x rootless │ │
 │ │ + cgroup v2 + Quadlet │ │
 │ ├──────────┬─────────────┤ │
 internal-net ◀─────────────────────┼──│ policy / │ notification │ │
 （サービス間） │ │ LLM 系 │ / relay │ │
 外部 API ◀──────────────────────────┼──│ gateway │ │ │
 │ ├──────────┴─────────────┤ │
 │ │ audit: ログ収集+署名付死活 │ │
 │ └────────────────────────┘ │
 └──────────────────────────────┘

役割は9つのロールに分けている（名前は一般化したもの）。

Infra on 万屋猫Labs

dotfiles にも CI を — 破壊的インストーラの冪等性を Ubuntu と Kali の二役で検証する

自分の開発環境が、ある日再現できなくなる

数字で見た中身

全体構成

homelab を Ansible でコード化する — fail-closed な多層防御インフラ

自宅サーバを丸ごとコードにした話

数字で見た中身

全体構成