Ansible Linux

この記事のポイント

・ansible roleとはplaybookの処理を「名前のついた部品」として独立させるAnsibleの仕組み
・roleの境界は「1ソフトウェアスタック」「変更理由が同じ」「オーナーが同じ」の3基準で引く
・変数がroleの「インターフェース」。defaults/main.ymlを差し替え口として使うのが設計の要
・チームで共有するには「role内完結」「命名規則統一」「依存の明示」の3原則を守る

この記事のポイント

・defaultフィルターで未定義変数を安全な既定値で処理できる
・int・bool・stringフィルターで型の不一致エラーを防げる
・select・map・combineでリスト・辞書を動的に変換する設計ができる
・ternaryフィルターで条件分岐をインラインに書きPlaybookを短くできる

この記事のポイント

・Lookupプラグインはコントロールノードで評価され、外部データを変数に変換する仕組み
・file・env・csvfile・pipe・passwordの5種で現場の大半のユースケースを網羅できる
・query()を使うとLookupをリスト形式で返せてloopと組み合わせやすくなる
・pipeプラグインは外部入力をそのまま渡すとシェルインジェクションのリスクがある

この記事のポイント

・Ansible変数はPlaybook全体がスコープ—role変数は名前が衝突しやすい
・role名を変数プレフィックスにする（例: nginx_port）のが公式推奨の規約
・defaults/main.ymlでプレフィックスを付けると衝突リスクをほぼゼロにできる
・group_vars・host_varsはroleのdefaultsより優先されるため環境差分の上書きに使う

この記事のポイント

・AnsibleのAWSモジュールはboto3経由でAWS CLIと共通の認証情報チェーンを利用する
・認証情報の優先順位は「環境変数 → CLIプロファイル → EC2インスタンスプロファイル」の順
・aws_profile変数でPlaybookから明示的にCLIプロファイルを指定できる
・本番EC2ではIAMロールのみで認証できるためシークレットをサーバーに保存しなくていい

この記事のポイント

・defaults/main.ymlがroleの「公開インターフェース」になる
・roles:配下のvarsで呼び出し側から値をインライン渡しできる
・include_roleのvars:はタスクレベルで動的に渡す経路として使う
・変数が効いていない時はdebugモジュールとansible-inventoryで確認する

この記事のポイント

・VPC→サブネット→IGW→SG→EC2の順序を守らないとPlaybookは動かない
・register変数でVPC作成結果のIDをEC2タスクへ引き渡す
・role分割でVPCネットワーク層とEC2起動層の依存を明示的に管理する
・subnet_id/vpc_idが見つからないエラーは順序と変数名のミスが原因の9割

この記事のポイント

・copyモジュールのsrcはrole内ではfiles/以下が自動探索され相対パスで指定できる
・ansible-galaxy role initでrole骨格を1コマンドで生成しファイル配置ミスを防げる
・handlers/main.ymlにnotifyハンドラを移設するのを忘れると再起動が実行されなくなる
・移行後はansible-playbook --check --diffで差分ゼロを確認してから本番適用する

この記事のポイント

・インベントリはリージョン別ディレクトリ型が運用しやすい
・group_varsにaws_regionを定義し全モジュールで参照する設計が基本
・AMI IDはリージョン固有のためgroup_varsで別管理が必須
・実行は -i inventory/ap-northeast-1 のようにリージョンを明示指定する

この記事のポイント

・meta/main.ymlのdependenciesで依存roleをrole側から宣言できる
・依存roleは宣言した順序で、本体roleより必ず先に実行される
・Ansibleは同一roleの重複実行をデフォルトで自動排除する
・allow_duplicates: trueで変数を変えた複数回実行が可能になる

この記事のポイント

・hostsファイルはINI形式とYAML形式の2種類で書ける
・グループ入れ子は[グループ名:children]（INI）で定義する
・ホスト範囲はweb[01:05]形式でまとめて指定できる
・ansible-inventory --graphでグループ階層をツリー確認できる

この記事のポイント

・aws_ssm接続プラグインはSSHポート不要でEC2にPlaybookを実行できる
・ターゲットEC2にはIAMロールとSSM Agentの稼働が必須条件
・ファイル転送にS3バケットが必要（ansible_aws_ssm_bucket_nameで指定）
・制御ノードにはAWS CLI v2・session-manager-plugin・boto3の導入が前提

この記事のポイント

・Ansibleとはサーバーの「あるべき状態」を宣言して何台にも同時に配布する構成管理ツール
・手作業のSSH繰り返しは台数が増えるほど設定ズレとミスが避けられなくなる
・管理対象にエージェント不要でSSH接続だけで完結する軽量な設計が特徴
・「手順を書く」ではなく「状態を宣言する」発想の転換がAnsibleの本質

この記事のポイント

・AnsibleのStrategyは「どのホストがいつ次のタスクへ進めるか」を制御する設定で、linear・free・host_pinnedの3種がある
・linearはデフォルト。全ホストが同じタスクを完了してから次に進む（遅いホストがボトルネックになる）
・freeは完了したホストが即座に次のタスクへ先行できる。ホスト間に依存がない処理で時間を短縮できる
・forksが「同時接続数の上限」、serialが「何ホストずつグループ化するか」を制御する点でstrategyとは別の軸になる

この記事のポイント

・Ansible EDAはイベント検知を契機にPlaybookを自動実行するイベント駆動型の拡張仕組み
・rulebookでsource（イベント監視）・condition（条件評価）・action（実行処理）を定義する
・ansible-rulebook CLIがrulebookを解釈してイベント待ちループを維持し、条件合致で即時起動する
・AWXのEDAコントローラーでルール管理とPlaybook実行を統合し、本番規模の自律自動化を実現できる

この記事のポイント

・ansible.cfgは4段階の優先順で探索され、プロジェクト直下への配置が現場標準
・[defaults]・[privilege_escalation]・[ssh_connection]の3セクションが設計の中心
・pipelining=Trueの有効化でsudo対応かつPlaybook実行を大幅に高速化できる
・グローバル設定はansible.cfg、ホスト固有の差分はhost_varsに書き分けるのが鉄則

この記事のポイント

・AnsibleのEEはPlaybook実行環境をOCIコンテナに封入してチームで統一する仕組み
・ansible-builderでEEイメージを作成し、ansible-navigatorで実行するのが基本フロー
・execution-environment.ymlにベースイメージ・コレクション・Pythonパッケージを定義する
・AWX・AAPへのEE登録でCI/CD全体の実行環境を一元管理できる

この記事のポイント

・Magic VariablesはAnsibleが自動で設定する組み込み変数で上書き不可
・inventory_hostnameでホスト名を、hostvarsで他ホストの変数を参照できる
・groupsとgroup_namesでグループ条件分岐やクロスホスト設定が実現できる
・map/selectattrフィルタとMagic Variablesを組み合わせるとIPリスト生成が一行で書ける
・ansible_play_hostsとansi_verbosityを使うと動的デバッグ出力と実行台数制御が可能

この記事のポイント

・GitHubリポジトリへのPushを契機にAnsibleを自動実行できる
・SSHキーはBase64エンコードしてGitHub Secretsで安全に管理する
・GitHub-hostedとself-hostedランナーの選定が設計の核心
・GitHub Environmentsでstaging→production承認フローを実現できる

この記事のポイント

・stagingとproductionは別ディレクトリのInventoryで物理的に分離し、誤適用を構造的に防ぐ
・共通変数はroleのdefaults、環境固有値は各環境のgroup_vars/配下に配置する
・ansible-playbook -i inventories/staging のように実行時に-iで環境を明示指定する
・本番適用前は--list-hostsで対象確認→--check --diffで差分確認→本適用の3ステップを踏む

この記事のポイント

・-vフラグで詳細ログを出し、タスク結果とモジュール引数を確認できる
・debugモジュールで変数の実際の値や条件式の評価結果を可視化できる
・assertモジュールで「期待通りの状態か」を宣言的に検証し失敗させられる
・--start-at-taskで問題箇所から実行を再開すれば検証サイクルが速くなる

この記事のポイント

・with_items は非推奨。loop: キーワードが現在の標準的な繰り返し構文
・loop_control の label でログ出力を短縮し、index_var でインデックス番号を取得できる
・register 変数はループ全体の結果を .results リストとして保持する
・register + when の組み合わせで「失敗したアイテムにだけ再処理をかける」設計が可能
・handler + notify は「変更があったときだけ再起動する」冪等設計のもう一つの柱

この記事のポイント

・ docker_containerモジュールでコンテナのデプロイ・停止・削除を1つのPlaybookで管理できる
・ community.dockerコレクションはansible-galaxy collection installで導入する
・ loopを使えば複数コンテナをまとめて一括起動・停止できる
・ docker_networkとdocker_volumeでネットワークとVolumeもコード管理できる

この記事のポイント

・amazon.aws.ec2_instanceモジュール1つでEC2を冪等に作成・管理できる
・VPC・サブネット・セキュリティグループもAnsibleで構築し、IDをregister変数で受け渡せる
・IAM認証はIAMロール・環境変数・Ansible Vaultから現場に合った方法を選ぶ——Playbookに認証情報を書かない設計が鉄則
・add_hostでプロビジョニング直後から設定Playbookを続けて流せる
・本番適用前に--checkオプションでドライランを実行し、変更内容を事前確認する運用が重要

この記事のポイント

・copyモジュールはコントロールノードのファイルをリモートサーバーへ冪等に配布する
・backup: yesを指定すると上書き前に元ファイルが自動でバックアップされる
・validateオプションで構文エラーのあるファイルの書き込みを事前にブロックできる
・fileモジュールはstate: directory/link/absentでディレクトリ・リンク・削除を冪等管理できる
・fetchモジュールでリモートの設定ファイルをコントロールノードへ一括回収できる

この記事のポイント

・Ansibleはエージェント不要。SSHとPython 3があれば即動く
・PuppetとChefはターゲットに常駐エージェントを入れるpull型
・記述言語はAnsibleがYAML、Puppetが独自DSL、ChefがRuby
・数十台規模で変更頻度が中程度なら、Ansibleが最短で回り始める

この記事のポイント

・failed_whenで「終了コード以外の失敗条件」をPlaybook側で定義できる
・changed_whenでcommandの「変更有無」の判定ロジックを上書きする
・ignore_errorsはエラー後も処理を継続するが、乱用は要注意
・registerとセットで使い、stdout/rcを条件式に組み込む設計が基本
・set_factでregister変数を加工すると、後続タスクで再利用しやすくなる

この記事のポイント

・Ansibleの接続はインベントリの変数（ansible_host / ansible_user等）で制御する
・SSH鍵配布はssh-copy-idで行い、known_hostsの確認を先に済ませる
・踏み台経由はansible_ssh_common_argsにProxyJumpを指定するだけ
・ansible pingが全ホストでSUCCESSになれば接続設計は完成

この記事のポイント

・become: true でSSH接続ユーザーを root に昇格させて操作できる
・設定スコープは「ansible.cfg＞inventory変数＞タスクレベル」の3段構造
・タスクごとに become を個別指定することで最小権限原則を守れる
・become_pass は Ansible Vault で暗号化して Git に安全にコミットする

この記事のポイント

・block・rescue・alwaysで失敗時の自動ロールバックを設計できる
・rescueではansible_failed_taskで失敗原因を取得できる
・alwaysは成否を問わず実行。ロック解除・通知に使う
・rescue内で失敗するとfailed=1。軽量タスクのみに絞る

この記事のポイント

・ansible roleはPlaybookを機能単位に分割・再利用する仕組み
・ansible-galaxy initコマンドでディレクトリ雛形を一瞬で生成できる
・handlers/notifyでサービス再起動を冪等に管理できる（changedの時だけ発火）
・handlerはフェーズ（pre_tasks/roles/tasks/post_tasks）の末尾でまとめて発火する
・listenキーワードで複数roleから1つのhandlerをまとめて呼べる
・defaultsは外部から上書き可能、varsは上書きを抑制する役割
・meta/main.ymlのdependenciesでrole間の依存関係をコードで宣言できる

この記事のポイント

・AnsibleはWinRM（ポート5985/5986）でWindows Serverに接続して管理できる
・Windows側でEnable-PSRemoting -Forceを実行してWinRMを有効化する
・インベントリにansible_connection: winrmを設定するだけで既存のPlaybook形式が使える
・win_service・win_package・win_copy・win_userで混在環境を冪等に一括管理できる

この記事のポイント

・import_tasksは静的（パース時）、include_tasksは動的（実行時）に読み込まれる
・whenをimport_tasksに付けると各タスクに条件がコピーされ、loopは使用不可
・include_tasksはwhenでファイル全体をスキップ、loopで繰り返し読み込みが可能
・動的ファイル名・条件付き読み込み・繰り返しが不要なら、import_tasksをデフォルトに

この記事のポイント

・asyncでタスクをバックグラウンド実行し、SSHタイムアウトを回避できる
・poll: 0（fire-and-forget）＋async_statusで複数ホストの並行実行が可能
・retries×delayがasync値以上になるよう設計することが重要
・Windowsモジュールはasyncに対応していないため注意が必要

この記事のポイント

・FQCNは「名前空間.コレクション名.モジュール名」の3パート形式でAnsible 2.10から標準化された
・ansible.builtinは追加インストール不要の組み込みコレクションでcopy/file/serviceなどが含まれる
・外部CollectionはCollection単位でインストールしrequirements.ymlで宣言管理できる
・ansible-lintのfqcn警告はモジュール名をFQCN形式に書き直すことで解消できる

この記事のポイント

・ansible-pullはノード自身がGitからPlaybookを取得して適用する
・push型との根本的な違いは「接続の向き」と「実行の主体」にある
・Gitリポジトリ＋cronでGitOpsに近い自律型構成管理が実現できる
・ノード数が多いほどプル型の運用コストメリットが大きくなる

この記事のポイント

・AWX = Ansible Tower のOSS版。CLI実行にGUI・RBAC・監査ログを追加する
・ジョブテンプレートはPlaybook・インベントリ・認証情報の実行定義書
・スケジュール実行・通知をGUIで設定し、crontabの属人化を解消できる
・デプロイはKubernetes推奨。検証ならminikubeまたはk3sで即日構築可能

この記事のポイント

・userモジュールで全台のアカウントをPlaybookで宣言管理できる
・exclusive: trueで古い公開鍵を全台から自動削除できる
・group_varsでユーザーリストを変数化すると1ファイルで全台管理できる
・Roleに切り出すことでユーザー管理設計を複数環境に再利用できる

この記事のポイント

・delegate_toでタスクを別ホスト（LBなど）に移譲できる
・run_once: trueで全ホスト中1回だけ実行を保証できる
・delegate_to＋run_onceで実行場所と回数を同時に制御できる
・serial: 1と組み合わせて無停止ローリングデプロイを設計できる

この記事のポイント

・dnf/aptモジュールのstate:latestで複数台に一括パッチ適用できる
・serialを使うとローリング更新で障害リスクを段階的に抑えられる
・pre_tasks/post_tasksで適用前後の自動検証を組み込める
・register/assertでパッチ失敗を即座に検知して処理を止められる

この記事のポイント

・gather_facts: true（デフォルト）でsetupモジュールが自動的にホスト情報を収集する
・ansible_distributionでOS種別を判定してwhen条件分岐に使える
・gather_facts: falseに設定すると大規模環境でPlaybookを高速化できる
・/etc/ansible/facts.d/にINIファイルを置くとカスタムfactsを定義できる

この記事のポイント

・ansible-playbook --check --diffで本番変更内容を事前に確認できる
・diffの「---」が変更前、「+++」が変更後の内容を示す
・commandとshellモジュールはcheckモードでスキップされる点に注意
・本番適用前は「check→出力確認→apply」の3ステップが基本形

この記事のポイント

・ansible.cfgのforks・pipelining・fact cachingの3設定でAnsibleは劇的に速くなる
・pipeliningはSSH接続のオーバーヘッドを1タスクあたり最大2/3削減できる
・fact cachingはgathering=smartと組み合わせてFact収集を初回のみに絞る
・pipelining有効化時はターゲットホストのrequiretty無効化が必須

この記事のポイント

・ansible-lintはPlaybookとroleのコード品質違反を静的解析で即座に検出するツール
・Moleculeはroleをコンテナで実行して冪等性テストを自動化するフレームワーク
・molecule testで全フェーズ（create/converge/idempotence/verify/destroy）を一括実行できる
・GitHub Actionsに組み込めばPushごとにlintとroleテストが自動実行される

この記事のポイント

・Ansible変数は22段階の優先順位を持ち、extra_vars（-e）が最高優先度
・group_vars/all→グループ名→host_varsの順で優先度が上がる
・roleのdefaults（上書き可）とvars（固定）を使い分けるのが設計の基本
・ansible-inventory --hostコマンドで変数の最終適用値を一覧確認できる

この記事のポイント

・Ansibleの冪等性とは「何度実行しても同じ状態に収束する」設計の性質
・command/shell乱用とstate未指定が冪等性を破壊する2大アンチパターン
・4原則：モジュール優先・creates条件付け・state明示・handler活用
・--check/--diffで事前確認後、serialとmax_fail_percentageで本番への安全な段階展開を設計する

この記事のポイント

・whenはOS種別・ファクト変数・register結果・グループ判定など多様な条件を記述できる
・loopはリスト・辞書を使った繰り返しで複数ユーザー・パッケージの一括操作を簡潔に書ける
・tagsで「インストールだけ」「設定だけ」を選択実行でき大規模Playbookの運用効率が上がる
・registerで保存した実行結果をset_factで加工することで動的な変数設計が実現できる
・block/rescue/alwaysはPythonのtry/except/finallyに相当するエラーハンドリング構造

この記事のポイント

・Ansible Galaxyはコミュニティroleの公式共有プラットフォームで1コマンドで取り込める
・requirements.ymlでrole依存とバージョンを宣言しチームで環境を統一できる
・ansible-galaxy role initで自社roleの骨格を生成し再利用しやすい設計を実現できる
・本番環境ではバージョン固定とGalaxy/Automation Hubの使い分けが品質の鍵になる

この記事のポイント

・aws_ec2プラグインはEC2 APIをリアルタイムで呼び出してホスト一覧を自動生成する
・aws_ec2.yaml 1ファイルにリージョン・フィルター・グループ条件を定義できる
・タグ（Env/Role）のkeyed_groupsでhosts.ini不要の自動グループ化が実現できる
・host_vars・Ansible Vaultと組み合わせてマルチ環境の設定差分を安全に管理できる

この記事のポイント

・templateモジュールはJinja2で変数・条件分岐を埋め込める設定ファイル配布モジュール
・handlerはnotify時のみPlay終了後に1回だけ実行される通知型タスク
・flush_handlersでhandlerを即時実行でき、後続taskが再起動後サービスに依存する場合に使う
・listenで複数taskから1つのhandlerを疎結合に呼び出せる
・handler連鎖（Ansible 2.9以降）でhandlerが別のhandlerをnotifyできる

この記事のポイント

・ansible-vault encrypt でファイルをAES256で丸ごと暗号化してGitに安全にコミットできる
・vault_password_fileで対話入力なし・自動実行が可能になる
・vars.ymlとvault.ymlを分けると変数名を平文で検索しながら値だけ暗号化できる
・vault-idで本番・開発のVaultパスワードを環境ごとに分離できる

この記事のポイント

・SSHループは「手順の自動化」、Ansibleは「状態の自動化」という根本的な違いがある
・冪等性（何度実行しても同じ結果になる性質）の有無が最大の分岐点
・サーバー台数が10台超・設定変更が月1回以上ならAnsibleへの移行が効果的
・inventoryとrole分離で、設定の再利用性と可読性が大幅に向上する

この記事のポイント

・terraform moduleでリソース定義を再利用可能な単位にまとめられる
・countはインデックス（数値）でリソースを識別するため途中削除でずれが起きる
・for_eachはキー名（文字列）で管理するため途中追加・削除しても影響が限定される
・dynamic blockでfor_eachを使うとリソース内のブロックを宣言的に管理できる

この記事のポイント

・inventory は INI形式（手軽）とYAML形式（階層記述）から用途に合わせて選択する
・ansible inventory は dev/stg/prod のディレクトリに分割し group_vars で環境差分を自動適用する
・ansible-inventory --list / --graph で変数とグループ構造を実行前に必ず検証する
・role は機能単位（nginx/mariadb）で分割し依存性を meta/main.yml で管理する
・module は「冪等性が保証されるか」を基準に選択。command/shell は最終手段
・vars_prompt で本番実行に確認ステップを追加し、--check --diff でドライラン必須

この記事のポイント

・ansible-playbookコマンド1本でEC2にLEMP環境を自動構築できる
・RoleでNginx・PHP・MariaDBを分離すれば再利用性が大きく上がる
・Inventoryに接続情報を集約することで複数台管理も一元化できる
・AWSセキュリティグループのポート開放を事前に忘れると接続でつまずく

この記事のポイント

・Ansibleはエージェント不要でSSH経由だけでサーバーを自動設定できる
・Inventoryで対象サーバーを定義し、Playbookで手順を宣言的に書く
・べき等性（何度実行しても同じ結果）がAnsibleの最大の強み
・セミナーLP（ansible.linuxmaster.jp）で実機ハンズオンを体験できる