Ansibleのansible.cfg設計入門|接続・実行・ログ・escalationの全セクションとプロジェクト別設定分離のパターン

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Ansible > Ansibleのansible.cfg設計入門|接続・実行・ログ・escalationの全セクションとプロジェクト別設定分離のパターン
「ansible.cfgをどこに置けばいいか分からない」「プロジェクト間で設定が干渉してしまった」──
こうした悩みの多くは、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に書き分けるのが鉄則


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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

「config file = /home/admin/ansible-project/ansible.cfg」の行で、どのファイルが使われているか即座に確認できます。ansible.cfgの変更を反映させるために再起動やリロードは不要で、次のansibleコマンド実行時に自動的に読み込まれます。

[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

この設計パターンをAnsibleの実機環境で体験したい方は、>> Ansibleハンズオン講座の詳細を見る をご覧ください。

[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

この分離により、Playbookを変えずに環境差分を吸収できます。

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/sudoersrequirettyが有効な場合は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=autoControlPersist=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

プロジェクト分離構成はシステム間の設定干渉を完全に防ぎますが、共通の設定(roles_path等)を各プロジェクトで重複して書く必要があります。運用規模が小さい場合はモノレポ構成、システムの独立性が高い場合はプロジェクト分離を選択してください。

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 --versionconfig 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/sudoersDefaults 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_argsStrictHostKeyChecking=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 に分離
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Ansible実践ハンズオンの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。