6.4構成管理ツール（Ansible・Terraform・Puppet/Chef）

手作業のCLIをスクリプトで置き換える先に、「あるべき設定状態をコードで宣言し、ツールに実現させる」という構成管理の世界があります。設定をコード化すればバージョン管理・レビュー・再現ができ、IaC（Infrastructure as Code）と呼ばれます。この節では、CCNAで問われる代表的なツール——Ansible・Terraform・Puppet・Chef——が「エージェントの要否」「プッシュかプルか」「記述言語」でどう違うかを整理し、要件に応じたツール選定の判断を身につけます。

6.4.1IaCと冪等性

• IaC（Infrastructure as Code）＝サーバやネットワークの設定を手作業ではなくコード（テキストファイル）として記述・管理する考え方。Git等でバージョン管理でき、変更のレビューや過去状態への復元、環境の再現が容易になる。
• 冪等性（idempotency）＝同じ設定コードを何度適用しても結果が同じになる性質。既に望む状態なら変更せず、差分がある部分だけを直すため、繰り返し実行しても安全。構成管理ツールが備えるべき重要な性質。
• 宣言的 vs 手続き的＝「最終的にどうあってほしいか（状態）」を書くのが宣言的、「どの手順で行うか（順序）」を書くのが手続き的。宣言的な記述は冪等性と相性が良い。

6.4.2Ansible（エージェントレス・プッシュ・YAML）

• Ansible＝エージェントレス（管理対象に専用の常駐ソフトを入れず、SSHで接続して設定を適用する）ツール。設定はプレイブックというYAMLファイルに記述し、冪等に適用される。
• プッシュ型＝管理側（コントロールノード）から対象機器へ設定を押し出す方式。対象側に何かを常駐させる必要がなく、既にSSHが有効な機器へすぐ適用できるため導入障壁が低い。

6.4.3Terraform（宣言的IaC）とPuppet/Chef

• Terraform＝インフラ（特にクラウドのリソース）を宣言的に記述して構築・管理するIaCツール。「あるべき状態」を定義し、現状との差分を計算して必要な変更だけを適用する。エージェントレスでプロバイダ経由に近い形で対象APIを操作する。
• Puppet／Chef＝主にエージェントを管理対象に常駐させ、プル型（各エージェントが中央のサーバへ定期的に設定を取りに行く）で構成を保つツール。PuppetはPuppet独自のDSL、ChefはRubyベースの記述を用いる。CCNA v1.1では範囲が縮小傾向だが、エージェント常駐・プル型という特徴を対比で押さえておく。

あなたはネットワークチームで、既存の数十台のCiscoスイッチへ「SNMPコミュニティとSyslog宛先を統一設定する」自動化を最短で始めたい、という状況だとします。対象機器には新しいソフトを入れたくない（変更管理のハードルが高い）という制約があるため、まずエージェントの要否が選定の分岐点になります。Puppet/Chefは各機器にエージェントを常駐させ、エージェントが中央サーバへ設定を取りに行くプル型が基本のため、この「機器に何も入れたくない」制約とは相性が悪いです。一方Ansibleはエージェントレスで、既にSSHが有効なスイッチへコントロールノードから設定をプッシュするだけで始められ、設定はYAMLのプレイブックに宣言的に書けます。しかもプレイブックは冪等なので、途中で失敗して再実行しても「既に正しい機器はそのまま・未適用の機器だけ直す」動きになり、二重適用の事故を避けられます。ここで仮に要件が「新しいクラウド上に仮想ネットワークとVMを一から構築する」であれば、機器設定というよりインフラのプロビジョニングが主眼になるため、宣言的IaCのTerraformが有力候補になります。このように「既存機器へエージェントを入れずに設定を配りたいのか（Ansible）」「クラウドのインフラを宣言的に作りたいのか（Terraform）」「エージェント常駐のプル型運用に乗せたいのか（Puppet/Chef）」という要件の性質でツールを選ぶのが、暗記ではない実務の判断です。

6.4.4この節のまとめ

• IaCは設定をコードとして管理してバージョン管理/再現を可能にし、冪等性は何度適用しても結果が同じになる性質
• Ansibleはエージェントレス・プッシュ・YAML・SSH、Terraformは宣言的IaC（特にクラウド構築）
• Puppet／Chefはエージェント常駐・プル型が特徴。要件（エージェント要否/プッシュかプルか/対象）でツールを選ぶ