終わらない「手動適用」に終止符を。GitHub Actions × Chef で実現するインフラCDの極致
「Chefの適用は、特定の管理端末から手動で実行する」――もしあなたがまだそう信じているなら、それはインフラの進化を自ら止めているのと同じだ。
SREの現場において、インフラ構成管理は「コード」である以上、アプリケーションコードと同様のパイプラインを通らなければならない。本稿では、ChefをモダンなCI/CDパイプラインに組み込み、「プルリクエストを投げればテストが走り、マージすればインフラが変わる」という至高の環境を構築する極限のテクニックを伝授する。
—
1. インフラCI/CDの全体像：Chefを「自律駆動」させる
CI/CDにおいてGitHub Actionsは「実行環境の抽象化」を担う。Chef Server（またはPolicyfile）とGitHubを連携させる際、重要なのは「いかにChefの実行コンテキストを分離するか」だ。
- CI (Continuous Integration): 構文チェック、静的解析、ユニットテスト（ChefSpec）。
- CD (Continuous Deployment): CookbookのChef Serverへのアップロード、およびターゲットノードへの適用。
ここで意識すべきは「Chefは冪等性（Idempotency）を担保するツールである」という大前提だ。GitHub Actionsでトリガーを引く際は、常に「何度実行しても結果が同じである」ことをコードレベルで保証しなければならない。
—
2. CIの実装：妥協なきコード品質の強制
開発スピードを上げる鍵は「人間がレビューする前に、マシンが致命的なミスを排除すること」にある。
必須のツールチェーン
- Cookstyle: Chef推奨のLintツール。
- Foodcritic: （現在Cookstyleに統合傾向だが）依存関係の可視化に必須。
- ChefSpec: ユニットテストの要。
`.github/workflows/ci.yml` のベストプラクティス
name: Chef Cookbook CI
on: [pull_request]
jobs:
lint-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Chef Workstation
uses: action-lab/chef-install@v1 # 賢いエンジニアは公式アクションで環境を固定する
- name: Run Cookstyle
run: cookstyle .
- name: Run ChefSpec
run: chef exec rspec spec/
【プロの知見】
CIの時間を短縮するには、`chef exec` のオーバーヘッドを避けるため、コンテナイメージを自前でビルドし `container` 指定でGitHub Actionsを回すのが定石だ。依存ライブラリのインストールを毎回行うのは時間の無駄。Dockerレイヤーキャッシュをフル活用せよ。
—
3. CDの実装：Policyfileによる「意図の確定」
Chefの運用において、環境（Environment）やロールの管理で疲弊していないか？ 今すぐ Policyfile に移行すべきだ。Policyfileは「どのバージョンのどのCookbookを、どのノードに当てるか」という「完全な状態」を単一のファイルで管理する。
`Policyfile.rb` の構成例
name ‘web-server-policy’
default_source :supermarket
cookbook ‘nginx’, ‘~> 12.0’
run_list ‘nginx::default’
このファイルをコンパイルし、生成された `Policyfile.lock.json` をコミットする。これにより、「CIでテストされたコードと、本番で適用されるコードが1bitも違わない」ことを保証できる。
—
4. シークレットの管理と安全なデプロイ
Chef Serverのアクセスキーや秘密鍵をGitHub Actions上にベタ書きするのは自殺行為だ。
1. GitHub Secretsの活用: `CHEF_SERVER_URL`, `CHEF_CLIENT_KEY` をシークレットに保存。
2. `chef-client` の非対話的実行:
- name: Upload to Chef Server
run: |
echo “$CHEF_CLIENT_KEY” > client.pem
chef push web-server-policy Policyfile.lock.json
【極限の知見】
さらにセキュリティを高めるなら、GitHub ActionsのOIDC（OpenID Connect）を使い、Chef Server側でIAMロール認証を行うのが現代のインフラエンジニアの嗜みである。静的な鍵管理からの脱却こそが、攻撃対象領域を最小化する唯一の道だ。
—
現場で差がつく「神」テクニック・共有ルール
最後に、チームの生産性を限界まで引き上げるためのTipsを授ける。
- キーボードショートカット (VS Code):
- `Cmd + P` → `> Cookstyle: Run`（設定の反映確認を瞬時に行う）
- `Ctrl + ~`（ターミナルを即座に開閉し、`chef shell-init` の状態を確認）
- 絶対入れるべき神プラグイン:
- Chef extension for VS Code: これがないとChef開発は始まらない。自動補完とリントが神がかっている。
- チーム開発のルール:
- 「Commit MessageにPolicyfileの差分を書け」: 構成が変わる時は必ずPolicyfile.lock.jsonの差分を詳細に記載する。これを守らないエンジニアにはPRをマージさせるな。
- 「テストが通らないコードはマージ不可」: `branch protection rule` でGitHub ActionsのPASSを必須条件に設定する。
最後に
Chefによるインフラ管理は、単なるスクリプトの実行ではない。「あるべき状態（Desired State）」をコードとして定義し、それを継続的に維持するエンジニアリングそのものだ。
自動化パイプラインを構築することは、最初は面倒かもしれない。しかし、一度完成すれば、あなたは「サーバーの設定」という泥沼から解放され、より価値のある「システムのアーキテクチャ設計」に集中できる。
さあ、今すぐGitHub Actionsのワークフローを書き換えろ。インフラは、あなたが寝ている間にも、コードによって守られるべきなのだから。