Configuration Management

基本概念

ツール/考え方	内容
Ansible	エージェントレス自動化
Source of Truth	正状態の定義管理
Idempotency	冪等性（何度実行しても同じ結果）

PUSH型 vs PULL型

方式	動作	エージェント
PUSH型	構成管理ツールから機器へ設定を送る	不要（エージェントレス）
PULL型	設定対象の機器が構成管理ツールから情報を取得して自身を設定する	必要

コード記法: 手続き型 vs 宣言型

記法	定義する内容	特徴
手続き型（Procedural）	命令の実行順序を定義する	「何をどの順番でやるか」を記述
宣言型（Declarative）	最終的にどのような状態になるかを定義	命令や実行順序は記述しない

4大構成管理ツール比較

特徴	Ansible	Puppet	Chef	SaltStack
PUSH/PULL	PUSH型	PULL型	PULL型	PUSH型、PULL型（両方可能）
使用プロトコル	SSH、NETCONFなど	HTTP	HTTP	SSH、ZeroMQなど
定義ファイル名	Playbook	Manifest	Recipe、Cookbook	State（SLSファイル）
定義ファイル形式	YAML	Rubyベースの独自DSL	Ruby言語	YAML、独自形式
サーバ待受ポート	なし	8140/tcp	10002/tcp	4505/tcp、4506/tcp
エージェント要否	不要（エージェントレス）	必要	必要	必要（Salt SSHは不要）
コード記法	手続き型	宣言型	手続き型	手続き型、宣言型
可用性構成	プライマリ／セカンダリ	マルチマスタ	プライマリ／セカンダリ	マルチマスタ
開発言語	Python	Ruby	Ruby	Python

各ツールの特性

Ansible

エージェントレスが最大の特徴
SSH で PUSH するためサーバ側の待受ポート不要
対象機器は SSH サーバとして動作する必要がある（Ansible側がSSHクライアント）
Playbook（YAML）で定義
分類は「構成管理ツール」（オーケストレーションツールではない）

Puppet

宣言型のみ対応
Manifest（Rubyベースの独自DSL）で記述
エージェントが Master に PULL しにいく

Chef

手続き型のみ対応
Ruby で Recipe/Cookbook を記述
エージェント必須（外部エージェント非対応 → Cisco機器の設定には不向き）
Cookbook を Chef サーバにアップロードするには knife コマンドを使用

SaltStack

最も柔軟性が高い（PUSH/PULL両方、手続き型/宣言型両方対応）
PUSH型：Salt SSH（SSH利用）
PULL型：Master-Minion（ZeroMQ利用、4505/4506 tcp）
State（SLSファイル、YAMLまたは独自形式）で定義

Mutable vs Immutable

設計思想	意味	アプローチ	対応ツール
Mutable（可変）	既存サーバに直接変更を加える	インプレースアップデート	Ansible、Puppet、Chef、SaltStack
Immutable（不変）	既存サーバは変更せず、新しいサーバを作成して切り替える	プロビジョニング＋切替	Terraform

Mutable: Version 1.0 → 中間状態(1.0.1) → Version 1.1 と段階的に変更。エラーで中間状態のまま残るリスクあり
Immutable: 新しい Version 1.1 のサーバを別途作成 → 稼働中の 1.0 から切り替え → 旧サーバ削除。中間状態が発生しない

重要: 「既存サーバに直接アップデート」= mutable = 構成管理ツール（Ansible/Puppet/Chef/SaltStack）。Terraform は immutable 設計

覚え方

重要: 「両方」がキーワードの場合は SaltStack（PUSH/PULL両方、手続き型/宣言型両方対応）

エージェントレス = Ansible
宣言型のみ = Puppet
Ruby開発 = Chef / Puppet
Python開発 = Ansible / SaltStack
既存サーバ直接変更 = Mutable = 4大構成管理ツール
新規サーバ作成＋切替 = Immutable = Terraform
構成管理ツール = Ansible / Puppet / Chef / SaltStack
オーケストレーションツール = Terraform（大規模で複雑なシステムの管理を自動化）