はじめに
Ansible を正しくインストールしても、誤ったインベントリ、インタープリター、権限を使用することがあります。信頼できるプロジェクトでは、これらの選択を明示し、実際の対象でその効果を確認します。
この実習では、プロジェクト設定を作成し、読み込まれた値を調べ、インベントリで対象の Python を指定して、準備済みの 2 つの SSH ノードで通常実行と明示的な権限昇格を比較します。この独立した環境には Ansible と接続が用意されており、パッケージのインストールや SSH サーバーの変更は必要ありません。
プロジェクト設定を作成して読み込む
このステップでは、プロジェクト設定を作成し、Ansible が実際にそれを読み込むことを確認します。
前の実習で Ansible をインストールしました。この独立した環境では、設定に集中できるようにコース共通のインストール環境が用意されています。ターミナルを開き、作業スペースに移動してください。
cd /home/labex/project
Ansible は 1 つの設定ファイルを使用します。ANSIBLE_CONFIG、現在のディレクトリの ansible.cfg、ユーザーのホームの設定、システムの設定の順に、最初に利用できるものを選択します。そのため、ディレクトリを移動すると、読み込まれるプロジェクト設定が変わることがあります。プロジェクトファイルが存在していても、環境変数が別のファイルを選択する場合があります。
用意された connection-reference.cfg には、元の練習用接続設定が含まれています。cat で表示します。
cat connection-reference.cfg
この設定はプロジェクトのインベントリと、信頼済みホストキーのファイルを選択します。実習ではキーとノードがすでに作成されています。プラットフォームのログインや SSH サーバーは変更しないでください。
次のように ansible.cfg を作成します。cat > は標準入力をファイルに書き込み、既存の内容を置き換えます。<<'EOF' はヒアドキュメントの開始です。最後の EOF まで全行を貼り付けてください。区切り文字を引用符で囲むと、テキストはそのまま保持されます。角括弧で囲まれた INI セクション名は設定をグループ化し、各 name = value 行はオプションを設定します。
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory はホスト一覧を選択します。host_key_checking はサーバーの身元確認を有効に保ちます。interpreter_python はデフォルトの対象側 Python を指定し、コントローラーのインタープリターは指定しません。become = False により、通常のタスクは権限昇格せずに実行されます。用意された ssh_args は、練習用の known_hosts ファイルを使用し、信頼されたキーを必須とし、短時間存続する SSH 接続を再利用します。
バージョンと設定の情報を表示します。
ansible --version
config file = /home/labex/project/ansible.cfg を探してください。この実習のモジュールパスは、コースの共有インストール環境に属します。前のインストール実習では、別の学習者用環境を使用しました。
ansible-config dump は有効な設定を表示します。--only-changed はデフォルト以外の設定だけに絞り込み、それぞれの取得元を示します。
ansible-config dump --only-changed
CONFIG_FILE() = /home/labex/project/ansible.cfg、プロジェクトの DEFAULT_HOST_LIST、/usr/bin/python3 に設定された INTERPRETER_PYTHON を探してください。出力では、INI の表記と異なる場合がある内部オプション名が使われます。ファイルを読むだけでは、Ansible がそれを読み込んだ証明にはなりません。
すでに学んだ Python ping モジュールで、プロジェクト設定をテストします。
ansible all -m ansible.builtin.ping
web1 と web2 の両方が pong を返すはずです。意図した設定を有効に保つため、この作業スペースで引き続きコマンドを実行してください。
インベントリで対象のインタープリターを設定する
このステップでは、両ホストに接続変数を設定し、プロジェクトのデフォルトとの関係を理解します。
用意されたインベントリを読みます。
cat inventory.ini
異なる 2 つの ansible_host 接続先の後に、[all:vars] があります。そのセクション以降の設定は、ansible_user=automation と練習用秘密鍵のパスを含め、両方のホストに適用されます。これらは管理対象ノードでの SSH アカウントと認証を記述します。
ansible_python_interpreter という接続変数は、該当ホストについて設定ファイルのデフォルト値 interpreter_python を上書きします。インベントリに特定の対象インタープリターが必要な場合に使用します。インベントリ変数が存在しない実行ファイルを指している場合、デフォルト値が正しくても解決できません。
printf はテキストを出力し、\n は改行を意味します。>> は既存のインベントリを置き換えずに追記します。既存の [all:vars] セクションの下に、インタープリター変数を追記してください。
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
インベントリをもう一度表示し、[all:vars] の下に新しい設定があることを確認します。
cat inventory.ini
コントローラーの Python インストール環境は変更されません。このパスは、各管理対象ノード内で個別に実行されます。両方の対象をテストしてください。
ansible all -m ansible.builtin.ping
引き続き、各対象が pong と changed: false を返すはずです。プロジェクトのデフォルトに加えて、動作するインベントリ別のインタープリター設定ができました。設定出力はデフォルト値を記述しますが、実行時に接続変数がそれを上書きする場合があります。
通常実行と権限昇格した実行を比較する
このステップでは、明示的な権限昇格の前後で、実際のリモートユーザーを観察します。
command モジュールは対象でプログラムを実行します。-a はモジュール引数を指定します。id -un を引用符で囲み、シェルがプログラムとそのオプションを 1 つの引数文字列として渡すようにします。id -un は実効ユーザー名を表示します。
ansible all -m ansible.builtin.command -a 'id -un'
両ホストが automation を報告するはずです。これはインベントリで選択した管理対象ノードのアカウントであり、コントローラーの labex ユーザーではありません。
--become は、この呼び出しでの権限昇格を要求します。練習用ノードでは automation アカウントがパスワードなしで sudo を使用できます。プロジェクトのデフォルトでは、引き続き通常実行時の権限昇格は無効です。
ansible all -m ansible.builtin.command -a 'id -un' --become
両ホストが root を報告するはずです。Ansible の command モジュールは、コマンド実行時には通常 CHANGED を報告します。今回のような読み取り専用のユーザー確認でも同様です。この表示だけでは、システム設定が変更された証明にはなりません。実際の標準出力と終了ステータスを解釈してください。
--become なしで繰り返します。
ansible all -m ansible.builtin.command -a 'id -un'
出力は automation に戻ります。権限昇格は 1 回の呼び出しに対して明示されただけで、ログインアカウントが恒久的に変更されたわけではありません。グローバルな権限昇格は無効のままにし、プラットフォームのアカウント設定は変更しないでください。
まとめ
プロジェクト設定を作成して読み込み、有効なデフォルト値を調べ、インベントリから優先度の高い対象インタープリターを指定しました。実際の SSH モジュール実行で両方の対象を確認し、ユーザー確認によって、通常の automation によるアクセスと明示的な become の違いを実証しました。これらの確認は、プラットフォームへのアクセスを変更せずに接続設定を診断するための基礎になります。
