こうした悩みの多くは、ansible.cfgの探索順と設計の理解不足から来ています。
この記事では、Ansibleの設定ファイルansible.cfgの役割・全セクション([defaults]・[privilege_escalation]・[ssh_connection])・プロジェクト別設定分離の設計パターンを体系的に解説します。RHEL 9 / Ubuntu 24.04 LTSで動作確認済みです。
この記事のポイント
・ansible.cfgは4段階の優先順で探索され、プロジェクト直下への配置が現場標準
・[defaults]・[privilege_escalation]・[ssh_connection]の3セクションが設計の中心
・pipelining=Trueの有効化でsudo対応かつPlaybook実行を大幅に高速化できる
・グローバル設定はansible.cfg、ホスト固有の差分はhost_varsに書き分けるのが鉄則
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
ansible.cfgの役割と設定ファイルの探索順
ansible.cfgはAnsibleの動作全体を制御する設定ファイルです。インベントリのデフォルトパス、SSH接続オプション、権限昇格の設定、実行ログの出力先など、Playbookを実行するための「基盤パラメータ」をここに集約します。Ansibleは起動時に以下の順で設定ファイルを探索し、最初に見つかったものを使います。
1. 探索優先順位(高い順)
・ANSIBLE_CONFIG:環境変数に指定したパス(最優先)・./ansible.cfg:コマンド実行ディレクトリの直下(現場の標準)
・~/.ansible.cfg:ユーザーのホームディレクトリ
・/etc/ansible/ansible.cfg:システム全体のデフォルト(最後の砦)
プロジェクトディレクトリの直下に置くのが現場の標準です。これにより「このディレクトリでansible-playbookを実行すれば必ずこの設定が使われる」という予測可能な動作を確保できます。複数のシステムを同一の管理サーバーから運用する場合も、設定が干渉しません。
2. 現在読み込まれているansible.cfgを確認する
$ ansible --version ansible [core 2.17.4] config file = /home/admin/ansible-project/ansible.cfg configured module search path = ['/home/admin/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3.9/site-packages/ansible ansible collection location = /home/admin/.ansible/collections:/usr/share/ansible/collections executable location = /usr/bin/ansible python version = 3.9.18 (main, Sep 7 2023, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] jinja version = 3.1.4 libyaml = True
[defaults]セクションの主要パラメータ
ansible.cfgの中で最も頻繁に設定するのが[defaults]セクションです。inventory・remote_user・host_key_checkingなどPlaybook実行の基本動作を制御します。[defaults] # デフォルトのインベントリファイルパス inventory = ./inventory/hosts.yaml # 接続先サーバーのSSHユーザー名 remote_user = ansible # 初回接続時のhostkey確認を省略(CI/CDや開発環境で使用) host_key_checking = False # Roleの追加検索パス roles_path = ./roles:~/.ansible/roles # 並列接続数(デフォルトは5) forks = 10 # 失敗したPlaybookの.retryファイルを生成しない(Ansible 2.12+でデフォルト無効化) retry_files_enabled = False # 実行結果の出力フォーマット(yaml/dense/oneline) stdout_callback = yaml # コールバックプラグインの有効化(タイミング情報の収集等) callbacks_enabled = timer, profile_tasks
1. inventory:インベントリパスの固定
inventoryはデフォルトのインベントリファイルパスです。コマンドライン引数の-iを毎回省略できます。複数パスをコロン区切りで指定することも可能です。# 複数インベントリを指定する例(静的インベントリ+動的インベントリの混在) inventory = ./inventory/staging.yaml:./inventory/aws_ec2.yaml
2. host_key_checking:本番環境ではTrueを維持する
host_key_checking = Falseは開発環境やCI/CD環境では便利ですが、本番環境での無効化は避けてください。中間者攻撃(MITM)のリスクが生まれます。本番では初回接続時にknown_hostsへの登録を行う手順を踏むのが正しい設計です。3. stdout_callback:yamlフォーマットで可読性を高める
デフォルトのdefaultからyamlまたはdenseに変更すると、実行ログが格段に読みやすくなります。# defaultフォーマットの出力例 TASK [install nginx] ******************** changed: [web01.example.com] # yamlフォーマットの出力例(変更内容がYAML形式で詳細表示される) TASK [install nginx] ******************** changed: [web01.example.com] => changed=true invocation: module_args: name: - nginx state: present
[privilege_escalation]セクションとsudo設計
[privilege_escalation]セクションはPlaybook実行時のsudo(root権限昇格)の動作を設定します。[privilege_escalation] # 権限昇格を使用するか(全タスクにbecomeを適用する場合True) become = True # 昇格方法(sudo/su/pbrun/pfexec) become_method = sudo # 昇格後のユーザー(デフォルトはroot) become_user = root # sudoパスワードをインタラクティブに求めるか(NOPASSWDを前提とする場合False) become_ask_pass = False
1. グローバル設定とホスト固有設定の分離
become = Trueをansible.cfgに書くと、すべてのタスクに適用されます。ホストによって昇格設定が異なる場合(例:開発環境はsudo不要、本番はsudo必須)は、ansible.cfgには書かず、host_vars側で差分管理するのがクリーンな設計です。# inventory/host_vars/prod-web01.yaml(本番ホスト固有の設定) ansible_become: true ansible_become_method: sudo ansible_become_user: root # inventory/host_vars/dev-web01.yaml(開発ホストはbecome不要) ansible_become: false
2. サーバー側のsudoers設定
becomeがTrueでもサーバー側の/etc/sudoersが正しく設定されていなければ実行に失敗します。Ansibleの接続ユーザーに対してパスワードなしsudoを許可するには以下の設定が必要です。# /etc/sudoers.d/ansible(管理対象サーバー側の設定) ansible ALL=(ALL) NOPASSWD: ALL
[ssh_connection]セクションとSSH最適化
[ssh_connection]セクションはSSH接続の動作を制御します。設定次第でPlaybook実行速度に大きな差が出ます。[ssh_connection] # pipelining有効化(パフォーマンス改善の最重要設定) pipelining = True # SSH接続オプション(多重接続・タイムアウト設定) ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no # SSH多重接続のソケット保存先(デフォルトの/tmpより専用ディレクトリが推奨) control_path_dir = ~/.ansible/cp
1. pipelining:最も効果が大きいパフォーマンスチューニング
pipelining = TrueはAnsibleのパフォーマンス改善で最も効果が大きい設定です。デフォルトのFalseでは、Ansibleはモジュールをスクリプトファイルとして転送してから実行しますが、Trueにするとデータをパイプで直接送り込むため、一時ファイルの作成が不要になります。ただし、管理対象サーバーの
/etc/sudoersでrequirettyが有効な場合はpipelining=Trueが動作しません。RHEL系ではDefaults requirettyがコメントアウトされていることを確認してから有効化してください。# requirettyの有無を確認(何も出力されなければ問題なし) $ sudo grep requiretty /etc/sudoers /etc/sudoers.d/* 2>/dev/null # pipelineの効果を実測する例(timeコマンドで実行時間を比較) $ time ansible-playbook -i inventory/hosts.yaml site.yml # pipelining=False(参考値) real 2m47s # pipelining=True(参考値) real 1m23s
2. ControlPersistでSSH接続を使い回す
ControlMaster=autoとControlPersist=60sを組み合わせると、一度確立したSSH接続を60秒間維持して後続の接続に使い回します。多数のタスクを実行するPlaybookでは、接続確立のオーバーヘッドが大幅に削減されます。control_path_dirのデフォルトは/tmpですが、セキュリティと安定性のために~/.ansible/cpなど専用ディレクトリに変更するのが推奨です。プロジェクトごとにansible.cfgを分離する設計パターン
複数のAnsibleプロジェクトを同一の管理サーバーから運用する場合、ansible.cfgをプロジェクト直下に置いて分離するのが基本です。1. モノレポ構成での設計
# モノレポ(単一リポジトリ)で複数環境を管理する構成例 ansible-project/ ├── ansible.cfg # プロジェクト共通設定 ├── inventory/ │ ├── staging/ │ │ └── hosts.yaml │ └── production/ │ └── hosts.yaml ├── group_vars/ │ ├── staging.yaml │ └── production.yaml ├── host_vars/ └── site.yml
2. プロジェクト分離構成
# システムごとにリポジトリとansible.cfgを完全分離する構成例 /home/admin/ ├── webserver-ansible/ │ ├── ansible.cfg # Webサーバー専用設定(remote_user=deploy) │ └── site.yml ├── database-ansible/ │ ├── ansible.cfg # DBサーバー専用設定(remote_user=dbadmin) │ └── site.yml └── monitoring-ansible/ ├── ansible.cfg # 監視システム専用設定 └── site.yml
3. ansible.cfgをGitで管理する際の注意点
ansible.cfgをGitリポジトリで管理する場合、パスワードや秘密鍵のパスが含まれていないことを必ず確認してください。vault_password_fileのパスを記録する場合は、そのパスワードファイル自体はGit管理外(.gitignoreに追加)にします。# .gitignore に追加する項目 .vault_pass *.retry *.pyc __pycache__/
ansible.cfgとインベントリ変数の使い分け
ansible.cfgとhost_vars/group_varsは設定の「スコープ」が異なります。どちらに書くべきかの判断基準を整理します。| 設定内容 | 書く場所 | 理由 |
|---|---|---|
| SSH接続オプション(ControlPersist等) | [ssh_connection] ansible.cfg | 全ホスト共通の接続設定 |
| デフォルトのremote_user | [defaults] ansible.cfg | プロジェクト全体のデフォルト値 |
| 特定ホストのSSHユーザー | host_vars/対象ホスト.yaml | ホスト固有の差分 |
| become設定(全ホスト統一) | [privilege_escalation] ansible.cfg | 全ホスト同一のsudo設計時 |
| become設定(ホストごとに差分あり) | host_vars/group_vars | 環境ごとに昇格設計が異なる時 |
| ansible_port(非標準SSHポート) | host_vars/対象ホスト.yaml | ホスト固有の設定 |
原則は「全ホストに共通するデフォルト値はansible.cfg、ホスト・グループ間に差分がある設定はインベントリ変数」です。この分離を守ることで、ansible.cfgの変更が意図せず一部ホストのみに影響するという問題を防げます。
ansible.cfgで詰まった時のトラブルシュート
1. ansible.cfgの変更が反映されない
設定を変更したのに動作が変わらない場合、まず「どのansible.cfgが読まれているか」を確認してください。ansible --versionのconfig file行が期待どおりのパスを指していない場合、探索優先順位の高い別の設定ファイルが使われています。# 実際に読まれているansible.cfgを確認する $ ansible --version | grep "config file" config file = /home/admin/other-project/ansible.cfg # 意図しないパス # ANSIBLE_CONFIG環境変数が設定されていないか確認 $ echo $ANSIBLE_CONFIG # カレントディレクトリを確認(./ansible.cfgが優先される) $ pwd && ls -la ansible.cfg
2. pipelining=Trueにするとsudoが失敗する
「sudo: sorry, you must have a tty to run sudo」というエラーが出た場合、管理対象サーバーの/etc/sudoersでDefaults requirettyが有効になっています。# requirettyの確認(RHEL系サーバーで実行) $ sudo grep requiretty /etc/sudoers Defaults requiretty # これが原因 # 対処:visudoでコメントアウトする $ sudo visudo # Defaults requiretty # 先頭に#を付けてコメントアウト # またはsudoers.dで上書きする $ echo 'Defaults !requiretty' | sudo tee /etc/sudoers.d/ansible-pipeline
3. host_key_checkingをFalseにしても接続できない
host_key_checking = Falseを設定してもSSH接続に失敗する場合、ssh_argsにStrictHostKeyChecking=noが含まれているか確認してください。一部の環境ではssh_args側での設定も必要です。[ssh_connection] # host_key_checkingと合わせてssh_args側でも無効化する ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null
本記事のまとめ
ansible.cfgはAnsibleプロジェクトの基盤設定を集約するファイルです。探索優先順位を理解してプロジェクト直下に配置し、3つの主要セクションを正しく設計することで、複数環境・複数プロジェクトでも予測可能な動作を確保できます。| 設計したいこと | 設定場所・パラメータ |
|---|---|
| デフォルトインベントリを固定する | [defaults] inventory = ./inventory/hosts.yaml |
| Playbookを高速化する | [ssh_connection] pipelining = True |
| sudo権限昇格を全体設定する | [privilege_escalation] become = True |
| プロジェクト間の設定干渉を防ぐ | プロジェクト直下にansible.cfgを配置 |
| 現在の設定ファイル場所を確認する | ansible --version のconfig file行 |
| ホスト固有の差分設定を管理する | host_vars/対象ホスト.yaml に分離 |
Ansible実践ハンズオンの詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Ansible Execution Environments(EE)設計入門|ansible-builderで実行環境をコンテナ化してチーム統一を実現する方法
- この記事の属するカテゴリ:Ansibleへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます