Chefインフラを「壊れない遺産」にする：Cookstyleによる静的解析とCI自動化の極意
こんにちは。インフラをコードで統治するSREの世界へようこそ。
Chefを運用していると、必ず直面する壁があります。それは「誰が書いても同じ品質を保つこと」と「数年前のレガシーコードに怯えずに修正すること」です。
今日は、Chefのベストプラクティスを強制し、あなたのインフラを「自動で品質が向上し続けるシステム」に変えるための静的解析（Lint）とCI統合の極意を伝授します。これをマスターすれば、深夜の障害対応で冷や汗をかくことは劇的に減りますよ。
—
1. なぜ「Cookstyle」なのか？
Chefの世界にはかつて`Foodcritic`という名ツールがありました。しかし、今はChef社が公式にサポートするCookstyle一択です。
CookstyleはRubyの静的解析ツールである`RuboCop`をベースにしています。単なる構文チェックではありません。「Chefの書き方としてイケてない（アンチパターン）」を検出し、時には自動で修正コードまで提案してくれる、まさに頼れる相棒です。
インストールとセットアップ
Chef Workstationをインストールしていれば、すでに手元にあるはずです。まずは確認しましょう。
バージョンの確認
cookstyle –version
プロジェクトのルートで以下を実行し、初期設定ファイルを生成します。
設定ファイルの生成
cookstyle –init
これで`.cookstyle.yml`が生成されます。ここがあなたの「コードの門番」となります。
—
2. 精度を高める「ルールカスタマイズ」の哲学
デフォルトのルールは非常に優秀ですが、現場の事情に合わせて調整が必要です。`.cookstyle.yml`を編集して、プロジェクトの規約を定義しましょう。
.cookstyle.yml の設定例
require:
- rubocop-performance
AllCops:
TargetRubyVersion: 2.7
Exclude:
- ‘spec//’ # テストコードは一旦対象外にする戦略もアリ
特定の厳しいルールを緩和する例
Chef/Deprecations/ResourceWithoutNameProperty:
Enabled: true
チームで合意した独自のベストプラクティスを追加
Layout/LineLength:
Max: 120 # 読みやすさを優先して少し長めに設定
ポイント: 最初からすべてのルールを有効にすると、既存コードがエラーで埋め尽くされます。「最初は警告（Warning）レベルで流し、徐々に厳格化する」のが、現場を混乱させないプロの作法です。
—
3. レガシーコードを「段階的」に攻略する
数千行のレガシーなCookbookを前に、心を折ってはいけません。以下の手順で攻略します。
1. まずは現状把握: `cookstyle` を実行し、全件を一度ファイルに出力して眺める。
2. 自動修正の活用: `cookstyle -a` で自動修正可能なものだけを叩く。これで8割の瑣末なミスは消えます。
3. 除外リストの作成: 直ちに修正が困難な箇所は、`.cookstyle.yml` の `Exclude` に追加し、「技術的負債リスト」としてissue化します。
4. 新規コードからの適用: 新しく書くコードには一切の警告を許さないルールを敷きます。
—
4. CI/CDパイプラインへの統合：GitHub Actions編
人間が手動でチェックする時代は終わりました。Pull Request（PR）を出した瞬間に、ロボットがコードを審査する環境を作りましょう。
`.github/workflows/lint.yml` を作成します。
name: Chef Lint
on: [push, pull_request]
jobs:
cookstyle:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Chef Workstation
uses: actionshub/chef-install@v1
- name: Run Cookstyle
# 自動修正はせず、指摘があればfailさせる設定
run: cookstyle –display-cop-names –fail-level A
ここが重要: `–fail-level A` を指定することで、警告（Convention）レベルでもCIを落とすように強制します。これにより、「PRがマージされる＝品質が保証されている」という信頼のループが完成します。
—
最後に：コードは「対話」である
静的解析ツールを入れる目的は、コードを厳しく監視することではありません。「どう書くのが今のChefで最も安全か」という知識を、チーム全員で共有することにあります。
エラーメッセージが出てきたら、それはツールからの「もっとこう書けば、将来の君が楽になれるよ」というアドバイスです。
最初は少し面倒に感じるかもしれません。しかし、一度このパイプラインを構築してしまえば、あなたは「コードの細部」に悩まされることから解放され、「インフラの設計」という本質的な課題に集中できるようになります。
さあ、今日からあなたのCookbookを「壊れない遺産」に変えていきましょう。応援しています。