Red Hat Certified Engineer (RHCE) #3: 設定ファイルと接続: ansible.cfg、ssh、become

#2 Inventory で Ansible がどのホストを扱うかを定義したなら、今回は Ansible が そのホストにどう接続し、どの権限で作業するか を決めます。その中心にあるのが設定ファイルの ansible.cfg、SSH キーベースの接続、そして権限昇格を担う become です。この 3 つが噛み合ってこそ、control node で書いたプレイブックが managed node で意図どおりに実行されます。

ansible.cfg は Ansible のほぼすべての既定動作を変えるスイッチ盤です。どの inventory を使うか、どのユーザーで接続するか、権限をどう上げるかが、すべてこのファイル 1 枚に収まります。試験では プロジェクトディレクトリごとに専用の ansible.cfg を置き、become まで構成する タイプが定番として出るので、探索優先順位と主要な項目を正確に覚えておきます。

ansible.cfg の探索優先順位 #

Ansible は実行されるとき、設定ファイルを決まった順序で探し、最初に見つけた 1 枚だけ を使います。複数の場所にファイルがあっても統合はされず、優先順位の高いファイルが残りを完全に覆い隠します。探索順序は次のとおりです。

ここで試験に直結する核心は、現在のディレクトリの ./ansible.cfg がホームとシステムの設定の両方に勝つ という点です。そのためプロジェクトディレクトリごとに専用の ansible.cfg を置けば、そのディレクトリでコマンドを実行している間は常に意図した設定が適用されます。試験で「このディレクトリで作業せよ」と指定されたら、そのディレクトリに ansible.cfg を作るのが定石です。

現在どの設定ファイルが実際に適用されているかは、次のコマンドで確認します。

ansible --version

出力の config file の行に、実際に読まれたファイルのパスが表示されます。意図した ansible.cfg ではない別のパスが見えたら、現在のディレクトリや環境変数を改めて点検します。

セキュリティ注意: 現在のディレクトリの設定 #

現在のディレクトリの ansible.cfg を読むには、そのディレクトリが 他のユーザーが書き込めない 状態でなければなりません。world-writable なディレクトリにある ansible.cfg はセキュリティ上無視され、警告が出力されます。試験で自分が作ったプロジェクトディレクトリは通常問題ありませんが、共用パスで作業するときは権限を確認しておくほうが安全です。

ansible.cfg の主要な設定 #

設定ファイルは [セクション] の下に キー = 値 形式で項目を並べる INI 構造です。RHCE でよく使うセクションは [defaults] と [privilege_escalation] の 2 つです。

[defaults] セクション #

[defaults] は inventory の場所、接続ユーザー、キー検査ポリシーなど、最も基本的な動作を定義します。

各項目をもう少し見ておきます。

• inventory。この値を指定すると -i オプションなしでも常に同じ inventory を使います。プロジェクトディレクトリの inventory ファイルを指すようにしておくとコマンドが短くなります。
• remote_user。試験では通常、一般ユーザーで接続したあと become で権限を上げるので、root ではなく作業アカウントを指定します。
• host_key_checking。新しく作った managed node に初めて接続するときに出るホストキー確認プロンプトを止め、プレイブックが止まらないようにします。実務ではセキュリティ上オンにしておくほうですが、実習環境ではよく false にします。
• roles_path。#11 Role で扱う role をプロジェクト内の特定のディレクトリで探させるには、この値を指定します。

[privilege_escalation] セクション #

[privilege_escalation] は一般ユーザーで接続したあと どのように root 権限で作業するか を定義します。become 関連の設定がすべてここに集まります。

• become = true にすると、プレイブックのすべての task が既定で権限昇格状態で実行されます。パッケージインストールやサービス管理のように root が必要な作業がほとんどの RHCE では、この値をオンにしておく場合が多いです。
• become_method。RHEL ではほぼ常に sudo を使います。
• become_user。特定の task だけ別のアカウントになる必要があるときは task レベルで個別に指定し、全体の既定は通常 root にしておきます。
• become_ask_pass。sudo がパスワードを要求するなら true にするか、コマンド実行時に -K オプションで入力します。

SSH キーベースの接続 #

Ansible は SSH で managed node に接続します。毎回パスワードを入力せずプレイブックを自動で回すには、SSH 公開キーを managed node に登録 してキーベース認証を構成します。これが RHCE 環境構成の最初のボタンです。

1) キーペアの生成 #

control node にキーペアがなければ、まず作ります。

ssh-keygen

既定のパス (~/.ssh/id_rsa、~/.ssh/id_rsa.pub) と空の passphrase で生成すると、追加入力なしで自動接続できます。

2) 公開キーの配布 #

生成した公開キーを各 managed node にコピーします。

ssh-copy-id devops@node1.example.com

ssh-copy-id は公開キーを対象ホストの ~/.ssh/authorized_keys に自動で追加します。この段階でだけ一度パスワードを入力すれば、以降はキーで接続します。managed node が複数台あれば、各ホストに同じように実行します。

3) 接続ユーザーの指定 #

Ansible がどのユーザーで接続するかは ansible.cfg の remote_user で決めるか、inventory でホストごとに ansible_user を指定します。

[webservers]
node1.example.com ansible_user=devops
node2.example.com ansible_user=devops

inventory の ansible_user は該当ホストにのみ適用され、ansible.cfg の remote_user より優先されます。ホストごとに接続アカウントが異なるときに便利です。

become による権限昇格 #

キーベースで接続するアカウントは通常、一般ユーザーです。パッケージインストール、サービス再起動、システムファイル修正のように root 権限が必要な作業は、become で sudo 権限を借りて 処理します。

become をオンにする方法は 3 つのレベルがあります。

1) ansible.cfg での全体設定 #

先に見た [privilege_escalation] の become = true が最も広い範囲です。このディレクトリで実行するすべてのプレイブックと ad-hoc コマンドが既定で権限を昇格します。

2) play や task レベルでの設定 #

プレイブックの中で play 全体または個別の task に become を指定できます。

- name: Web サーバーの構成
  hosts: webservers
  become: true
  tasks:
    - name: httpd のインストール
      ansible.builtin.dnf:
        name: httpd
        state: present

    - name: ログ確認は一般ユーザーで
      ansible.builtin.command: whoami
      become: false

play に become: true を置くとその play のすべての task が権限を昇格し、特定の task だけ become: false にするとその task だけ元のアカウントで実行されます。task ごとの become が play の設定を上書きするので、例外が必要な task だけ個別に指定すればよいです。

特定の task を root ではなく別のアカウントで実行するには、become_user を task に付けます。

    - name: postgres ユーザーで作業
      ansible.builtin.command: psql -c "SELECT 1"
      become: true
      become_user: postgres

3) コマンドラインオプションでの設定 #

設定ファイルを変えずに一回限りで権限を上げるときは、コマンドラインオプションを使います。

ansible-playbook site.yml --become -K

• --become (または -b)。今回の実行に限って権限昇格をオンにします。
• -K (--ask-become-pass)。sudo パスワードを一度尋ねます。対象アカウントの sudo がパスワードを要求するときに必要です。

managed node の sudo がパスワードなしで動くよう NOPASSWD に設定されていれば -K なしでも動きます。試験環境では作業アカウントにパスワードなしの sudo があらかじめ構成されている場合が多いですが、そうでなければ -K や become_ask_pass でパスワードを渡します。

接続テスト #

設定とキー、become まで揃ったら、実際に接続できるか確認します。ping モジュールが最も速い点検ツールです。

ansible all -m ping

ansible の ping モジュールは ICMP ではなく、SSH で接続して Python が動くかまで 確認するモジュールです。すべてのホストで次のような応答が出れば接続は正常です。

node1.example.com | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

権限昇格まで点検するには become をオンにして現在のユーザーを確認します。

ansible all -m command -a "whoami" --become

すべてのホストが root を返せば become は正常に動いています。UNREACHABLE が出たら SSH キーや ansible_user を、sudo 関連のエラーが出たら become の設定や -K の有無を点検します。

プロジェクト全体の例 #

ここまで扱った内容を 1 つのプロジェクトにまとめてみます。作業ディレクトリに ansible.cfg と inventory を一緒に置く構造が試験の標準形です。

ansible.cfg は次のように書きます。

[defaults]
inventory = ./inventory
remote_user = devops
host_key_checking = false
roles_path = ./roles

[privilege_escalation]
become = true
become_method = sudo
become_user = root
become_ask_pass = false

同じディレクトリの inventory は次のとおりです。

[webservers]
node1.example.com
node2.example.com

[dbservers]
node3.example.com

このディレクトリでコマンドを実行すると ./ansible.cfg が自動で適用され、-i オプションや --become なしでも意図した inventory と権限昇格がそのまま動きます。

ansible all -m ping
ansible all -m command -a "whoami"

whoami の結果がすべて root なら、ansible.cfg の become = true が適用されたという意味です。プロジェクトディレクトリ 1 つに設定と inventory をまとめておけば、そのディレクトリの中では常に同じ環境が再現されます。

試験ポイント #

• プロジェクトごとの ansible.cfg。試験は通常、特定の作業ディレクトリを指定します。そのディレクトリに ansible.cfg を作って inventory、remote_user、become を明示するのが定石です。./ansible.cfg がホームとシステムの設定の両方に勝ちます。
• become 設定。RHCE の作業のほとんどが root 権限を要求するので、[privilege_escalation] に become = true を置く構成がよく出ます。特定の task だけ例外が必要なら、task レベルで become: false や become_user で調整します。
• 接続確認。環境を整えた直後は ansible all -m ping で SSH 接続を、--become を付けた whoami で権限昇格を一緒に点検します。
• 適用設定の確認。ansible --version の config file の行で、実際に読まれた ansible.cfg が意図したファイルかを確認する習慣が、些細なミスを防ぎます。
• host_key_checking。新しい managed node でホストキープロンプトによりプレイブックが止まらないよう、false にする場合が多いです。

まとめ #

この記事で押さえたこと:

• ansible.cfg の優先順位。ANSIBLE_CONFIG 環境変数、現在のディレクトリ、ホームディレクトリ、/etc/ansible の順で探し、最初に見つけた 1 枚だけ適用
• 主要な設定。[defaults] の inventory・remote_user・host_key_checking・roles_path、[privilege_escalation] の become・become_method・become_user・become_ask_pass
• SSH キー接続。ssh-keygen でキーを作り ssh-copy-id で配布、remote_user や inventory の ansible_user で接続アカウントを指定
• become。ansible.cfg 全体、play と task レベル、コマンドライン --become -K の 3 つの方式で sudo 権限を昇格
• 接続テスト。ansible all -m ping で接続を、--become を付けた whoami で権限昇格を確認

次へ: ad-hoc コマンド #

接続と権限まで揃ったので、プレイブックを書く前にモジュールを即席で実行してみます。

#4 ad-hoc コマンド: モジュールの即席実行 では、ansible コマンドでモジュールを 1 行で実行する方法、よく使うモジュール (command・shell・copy・file・dnf・service)、そして素早い点検と一回限りの作業に ad-hoc を活用する感覚を整理します。