はじめに
Ansible は、予測可能な順序で設定ファイルを検索します。プロジェクトレベルの ansible.cfg を作成することは、どのシェルセッションから実行してもコマンドの結果を一定に保つために非常に重要です。
この実験では、小さなプロジェクトを作成し、ansible.cfg の記述、インベントリのデフォルト設定、共有変数の追加、そしてプロジェクトディレクトリからの最初の Ansible チェックを実行します。
最小限のプロジェクトとインベントリの作成
このステップでは、プロジェクトレベルの Ansible 設定に必要なディレクトリとインベントリファイルを作成します。この実験はクリーンな仮想マシン（VM）から開始するため、必要なファイルのみを構築します。
プロジェクトの構造を作成します。
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,group_vars,playbooks}
この実験では、プロジェクトを意図的に小さく保ちます。inventory には管理対象ホストのリストを、group_vars には Ansible が自動的に読み込む変数を、playbooks には後の自動化で使用するファイルを格納します。
プロジェクトディレクトリに移動します。
cd rhce-ansible
ローカルの管理対象ホストを 1 つ含むインベントリを作成します。
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF
ホスト名の node1 はインベントリ上のエイリアスであり、別の VM を指すものではありません。ansible_connection=local を設定することで、Ansible はこの RHEL システム上でモジュールを実行しつつ、グループ指定の練習を行うことができます。
プロジェクト用 ansible.cfg の作成
このステップでは ansible.cfg を作成します。[defaults] セクションでは一般的な動作を制御します。inventory を設定することで、コマンドごとに -i inventory/hosts を入力する必要がなくなります。
このステップのコマンドを実行する前に、相対パスが Ansible プロジェクトを正しく参照するようにプロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
設定ファイルを作成します。
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
remote_user = labex
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
stdout_callback = default
EOF
各設定により、コマンドラインでの繰り返し入力を省略できます。inventory は静的インベントリファイルを指定し、remote_user はデフォルトのログインユーザーを設定します。host_key_checking = False は実験環境での SSH ホストキー確認プロンプトを回避し、interpreter_python = auto_silent は煩わしい警告なしに Python を自動選択させます。
Ansible がどの設定ファイルを使用しているかを確認します。
ansible --version | sed -n '1,4p'
出力に config file = /home/labex/project/rhce-ansible/ansible.cfg が含まれているはずです。
これは重要な習慣です。Ansible が異なる設定ファイルを読み込んでいる場合、後のコマンドで実験の意図とは異なるインベントリやコールバック、接続動作が使用される可能性があるためです。
プロジェクトのデフォルト設定を通じたインベントリの確認
このステップでは、ansible.cfg が正しくインベントリを指しているかをテストします。インベントリパスが設定されているため、このコマンドでは -i オプションは不要です。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
インベントリのグラフを表示します。
ansible-inventory --graph
グラフには managed グループと node1 ホストが表示されるはずです。
グラフビューは、Ansible がインベントリを解析した後の状態を確認できるため、コマンド実行前に役立ちます。ここでグループやホストが表示されない場合、Playbook のターゲットとしても認識されません。
node1 のホスト変数を一覧表示します。
ansible-inventory --host node1
ansible_connection が local に設定されていることが確認できます。
ホストビューでは、生のインベントリ行だけでなく、解決されたホスト変数が表示されます。後の実験では、変数がインベントリ、group_vars、host_vars のどこから来ているかをトラブルシューティングするためにこのコマンドを使用します。
共有変数の追加
このステップでは、すべての管理対象ホストに対する変数を追加します。group_vars 配下のファイルは、ファイル名がインベントリのグループ名や all と一致する場合に自動的に読み込まれます。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
group_vars/all.yml を作成します。YAML では key: value 形式を使用し、コロンの後にスペースを入れます。
cat > group_vars/all.yml <<'EOF'
project_owner: labex
baseline_message: Managed by the RHCE Ansible prep project
EOF
ファイル名 all.yml には特別な意味があり、Ansible はすべてのインベントリホストに対してこの変数を適用します。YAML 形式のため、インデントとコロン後のスペースはファイルの妥当性に影響します。
debug モジュールを使用して、管理対象ホストから変数を 1 つ出力します。
ansible managed -m ansible.builtin.debug -a 'var=baseline_message'
出力には group_vars/all.yml からのメッセージが含まれているはずです。
アドホックコマンドは 3 つの部分で構成されます。managed はホストパターン、-m はモジュールの選択、-a はモジュールの引数です。成功した結果は、設定されたインベントリと変数の読み込みが正しく機能していることを証明します。
接続チェックの実行
このステップでは ping モジュールを実行します。これは ICMP ping ではなく、Ansible がターゲットホスト上で Python を実行できるかを確認する Ansible モジュールです。
このステップのコマンドを実行する前に、プロジェクトディレクトリに戻ります。
cd /home/labex/project/rhce-ansible
managed グループに対してチェックを実行します。
ansible managed -m ansible.builtin.ping
成功すると pong が返されます。
Ansible の ping モジュールはモジュール実行テストであり、ネットワークの ICMP ping ではありません。これは、Ansible がホストに到達し、Python を起動し、モジュールの結果を返せることを証明します。
アドホックコマンドを使用して小さな証明ファイルを作成します。copy モジュールは指定したパスにコンテンツを書き込みます。
ansible managed -m ansible.builtin.copy -a 'content=ansible_cfg_ready dest=/home/labex/project/rhce-ansible/config-check.txt mode=0644'
このコマンドが changed を報告すれば、Ansible がファイルを作成または更新したことを意味します。同じ内容とモードで再度実行すると、目的の状態が既に存在するため、結果は ok になるはずです。
まとめ
プロジェクトレベルの ansible.cfg を作成し、Ansible が設定されたインベントリを読み込むことを確認し、共有変数を追加して、アドホックモジュールによるチェックを実行しました。今後の実験では、この再現可能なプロジェクト設定を基盤として進めていきます。
