Chefの「負債」を「資産」に変える：静的解析の極致とCIパイプライン完全実装術
Chefを使いこなしていると必ず直面する壁がある。「Chefは書けるが、メンテナンスが地獄」という状況だ。レガシーなCookbookが乱立し、冪等性を担保できないコードが運用を蝕む。
今日は、Chefの歴史的遺物であるFoodcriticを卒業し、RuboCopベースのCookstyleを極限までチューニングして、Chefインフラを「自動で品質が向上し続けるシステム」へと昇華させる戦略を伝授する。
—
1. Cookstyleカスタムルールの極意：組織の「暗黙知」をコード化せよ
デフォルトのルールだけでは、あなたの組織特有のベストプラクティスは守れない。`Cookstyle`はRuboCopのエンジンを積んでいるため、カスタムルールは驚くほど強力だ。
カスタムルールの作成
`lib/rubocop/cop/chef/custom_rule.rb` のようなディレクトリに、特定の規約を定義する。
例: 独自のリソース使用を禁止するカスタムCop
module RuboCop
module Cop
module Chef
class NoDeprecatedExecute < Base
# 実行時に警告を出すメッセージ
MSG = 'executeリソースは極力避け、専用のリソースを作成してください'.freeze
def on_send(node)
# executeブロックを見つけたら警告
return unless node.method_name == :execute
add_offense(node)
end
end
end
end
end
プロのテクニック:
ルールを書きすぎるとノイズになる。まずは「破壊的な変更」や「セキュリティリスク」に絞り、「段階的修正アプローチ」を取れ。`.rubocop.yml` で `inherit_from` を使い、既存ルールは `enabled: false` にせず `Severity: info` から始め、徐々に厳格化する。
—
2. CI統合：プルリクを「番人」にする
静的解析をローカルに依存させてはいけない。GitHub Actionsを使った、妥協のないパイプライン構成例を示す。
`.github/workflows/chef_lint.yml`
name: Chef Quality Gate
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Chef Workstation
uses: actionshub/chef-install@v2
- name: Run Cookstyle
# –display-cop-names でどのルールに違反したか明示させる
# –format progress で進捗を可視化
run: cookstyle –display-cop-names –format progress
現場の知見:
ここで重要なのは「失敗した時に何をすべきか」だ。`–auto-correct` をCIで実行させ、コミットまで自動化するパイプラインを組めば、エンジニアは「コードのロジック」に集中できる。
—
3. 生産性を劇的に高める「神」ツールと設定
Chef開発は「Chef Workstation」だけでは完結しない。以下のツールを導入せよ。
VS Code 必須プラグイン
- Chef Extension for VS Code: 言語サーバー（LSP）を有効化し、インテリセンスを完璧にしろ。
- YAML/JSON Language Support: `attributes` ファイルやメタデータ管理用。
- Error Lens: エラーをコード行に直接表示させ、修正ループを極限まで短縮する。
隠れたキーボードショートカット
- `Cmd/Ctrl + Shift + P` -> `Chef: Execute Resource`: 該当するリソースブロックを即座に検証（インフラエンジニアの必須技）。
—
4. 実践的設定ファイルのベストプラクティス
`attributes/default.rb` や `metadata.rb` が巨大化するのは敗北のサインだ。
ディレクトリ構造の黄金則:
cookbooks/
my_app/
attributes/
default.rb # アプリの基本設定
tuning.rb # パフォーマンスチューニング用（分離する）
libraries/ # Chefのヘルパー関数（ビジネスロジックをここに書け）
recipes/
default.rb # 宣言的記述のみを記載
ベストプラクティス:
- 属性の分離: `default.rb` に全てを詰め込むな。`tuning.rb` や `platform_specific.rb` などに分割し、`include_attribute` で呼び出せ。
- ライブラリの活用: 複雑な条件分岐は `recipe` に書くな。`libraries/` 配下にカスタムヘルパーとしてメソッド化し、テスト（RSpec）可能にせよ。
—
最後に：なぜ「コード監査」なのか
インフラの自動化において、最もコストがかかるのは「コードを書くこと」ではなく「運用中にそのコードを読み解くこと」だ。
CookstyleをCIに統合し、カスタムルールで組織の知見をコードに溶け込ませることは、将来の自分たちへの最大の投資になる。「ルールを守らせる」のではなく、「ルールを守らないとコードがデプロイできない」状態をシステム的に強制せよ。
それが、世界最高峰のSREとして私が辿り着いた、インフラを「負債」から「資産」に変える唯一の道だ。さあ、今すぐ `cookstyle` を叩き、そのレガシーを浄化してくれ。