Red Hat Certified Engineer (RHCE) #18: 試験のコツと時間管理

#1 から #17 まで、RHCE のすべての出題ドメインを整理しました。この記事は 実技試験に入る直前にもう一度読んでいく圧縮版 です。新しい文法はなく、4 時間の実技をどう運用するか、そしてシリーズ全体で最も頻繁に点数を流す落とし穴だけを集めました。RHCE は手でコマンドを打つ試験ではなく、空の control node から冪等なプレイブックを書いて複数の managed node を構成する 試験なので、同じ知識でも運用が合格と不合格を分けます。

4 時間の運用戦略 #

すべて自動化なので環境セットアップが先 #

RHCE が CKA・RHCSA と決定的に違う点は、すべての作業が 1 つの control node のプレイブックに収束する ことです。作業ごとに新しいクラスターへ切り替えたり別のノードへ SSH したりする運用ではなく、試験開始直後に一度環境をセットアップしておけば、その上に task を積み上げ続ける 構造です。そのため最初の 10〜15 分にかける環境セットアップが 4 時間全体の速度を決めます。

task の積み上げ方式で運用する #

RHCE 環境は作業が複数の問題に分かれても、結局 1 つの作業ディレクトリの中で inventory と ansible.cfg を共有 します。問題ごとに別のプレイブックを作りつつ、inventory・become・ssh の設定は開始時に一度押さえた ansible.cfg がすべて持っていくようにします。同じ設定を問題ごとに押さえ直さないことが最も大きく時間を節約します。

# 作業ディレクトリで ansible.cfg が認識されるかをまず確認
ansible --version | grep "config file"

# inventory のすべてのホストが応答するか (環境セットアップ直後に 1 回)
ansible all -m ping

ansible.cfg の位置は点数に直結します。現在の作業ディレクトリの ansible.cfg が最初に読まれる ので、作業ディレクトリを外れてプレイブックを実行すると、意図した inventory・become が適用されません。開始時に作業ディレクトリへ ansible.cfg を置き、その中だけでプレイブックを実行する流れを身につけておきます。

# 作業ディレクトリの ansible.cfg (一度だけ押さえておく)
[defaults]
inventory = ./inventory
remote_user = devops
become = true
[privilege_escalation]
become = true
become_method = sudo
become_user = root

–syntax-check と –check を頻繁にかける #

プレイブックを書き終えて一度に実行すると、YAML インデントの事故やモジュール引数のエラーを最後になって初めて発見します。task をいくつか書くたびに --syntax-check で文法を、--check で動作を事前に 確認する習慣が、デバッグ時間を大きく減らします。

# YAML/プレイブックの文法だけを素早く検証 (実行しない)
ansible-playbook play.yml --syntax-check

# 実際の変更なしで何が変わるかを事前に見る (dry-run)
ansible-playbook play.yml --check

# 特定の task だけを素早く回すときは tag を活用
ansible-playbook play.yml --tags web

--check は一部のモジュールで正確でないことがありますが、大多数の作業で「このプレイブックが何を変えようとしているか」を安全に見せてくれます。詰まる task は -vvv で詳細ログを点けて、どの引数で失敗しているかをすぐに突き止めます。

1 つの作業に過集中しない #

合格ラインは 210/300 (70%) です。配点に比べて時間がかかる作業は、ひとまず可能なところまで task を作っておいて次へ進みます。モジュールが 1 つ思い出せない作業を抱え込んで、手に馴染んだ作業をいくつも逃すのが最もよくある失敗です。知らないモジュールは後で扱う ansible-doc で解く道があるので、詰まったら印を付けて先に進みます。

ansible-doc を武器に使う #

RHCE は インターネットがありません。 ローカルの man page と ansible-doc だけが許可されるので、知らないモジュールを解く能力はそのまま ansible-doc を素早く読む能力です。

# モジュールを知らないときはキーワードで検索
ansible-doc -l | grep -i firewall

# モジュールのオプションと説明の全体
ansible-doc ansible.posix.firewalld

# ドキュメント下部の EXAMPLES だけをすぐ見る (最も速い動線)
ansible-doc ansible.posix.firewalld | grep -A 40 EXAMPLES

運用の核心は EXAMPLES をコピーして変形すること です。モジュールのオプションを最初から覚えて書くのではなく、ansible-doc 下部の EXAMPLES ブロックをプレイブックに貼り付け、値だけを作業条件に合わせて変えます。FQCN (例: ansible.posix.firewalld) も ansible-doc -l の検索結果にそのまま出るので、コレクション名を覚えていなくても正確なモジュール名を見つけられます。

# どのコレクションがインストールされているか (FQCN 確認用)
ansible-galaxy collection list

system roles example ドキュメントを積極的に活用する #

rhel-system-roles は RHCE でよく出る高配点ドメインで、各 role の例示プレイブックがローカルにインストールされています。 インターネットなしでも /usr/share/doc 以下の例をそのまま持ってきて使えるので、system roles の作業は最初から書くより例をコピーして変形する方が速くて安全です。

# インストール済みの system roles を確認
ls /usr/share/ansible/roles/

# role ごとの例示プレイブックとドキュメントの場所
ls /usr/share/doc/rhel-system-roles/

# 例えば timesync (chronyd) role の例
ls /usr/share/doc/rhel-system-roles/timesync/

/usr/share/doc/rhel-system-roles/<role>/ には README とともに、すぐ実行できる例示プレイブックが入っています。作業が「system roles で chronyd を構成せよ」なら、該当する例をコピーして NTP サーバーアドレスのような値だけを作業条件に合わせて変えれば済みます。role 変数の名前を覚える必要はなく、README の変数表をそのまま参照します。

冪等性を 2 回実行で検証する #

RHCE 採点の核心は 同じプレイブックを何度回しても結果が同じか です。採点システムがプレイブックを再実行して冪等性を確認する場合が多いので、書いたプレイブックは必ず 2 回回して 2 回目の実行で changed が 0 になるかを確認します。

# 1 回目の実行: 変更が起きる (changed 発生)
ansible-playbook play.yml

# 2 回目の実行: 何も変わってはいけない (changed=0 なら冪等)
ansible-playbook play.yml

2 回目の実行で changed が残っているなら、その task は冪等ではありません。最もよくある原因は command・shell モジュールです。この 2 つは毎回実行されるので、可能なら専用モジュールに変え、やむを得なければ creates・removes や changed_when で冪等性を自分で押さえます。

# command を使うしかないときは冪等性を直接制御
- name: 初期化スクリプトは一度だけ
  ansible.builtin.command: /opt/setup.sh
  args:
    creates: /opt/.setup_done

- name: 出力だけを見るコマンドは変更なしと表示
  ansible.builtin.command: cat /etc/redhat-release
  register: rel
  changed_when: false

よく間違えるパターン #

実技で点数を流す定番パターンです。知識不足より運用ミスで失う点数の方が多いです。

1) FQCN の欠落 #

最新の RHCE 環境では、モジュールを短い名前で書くとコレクションが見つからず失敗する場合があります。firewalld ではなく ansible.posix.firewalld、setup ではなく ansible.builtin.setup のように FQCN をそのまま 書きます。正確な FQCN は ansible-doc -l で確認します。

# 短い名前の代わりに FQCN で
- name: パッケージのインストール
  ansible.builtin.dnf:
    name: httpd
    state: present

2) become の抜け #

root 権限が必要な task (パッケージインストール、サービス制御、システムファイルの修正) に become がないと、権限エラーで失敗します。ansible.cfg にグローバルで押さえつつ、play や task 単位で必要な箇所を再確認します。

- name: システムの構成
  hosts: webservers
  become: true   # play 全体に権限昇格
  tasks: ...

3) command/shell の冪等性の未処理 #

command・shell は毎回の実行で changed として捕捉され、冪等性を壊します。専用モジュールに置き換えるか、やむを得なければ creates・removes・changed_when で制御します (前節の例を参照)。2 回目の実行でこの task だけが changed として残っているなら、採点で冪等性の点数を失います。

4) Vault パスワードファイルの欠落 #

Vault で暗号化した変数を使うプレイブックは、実行時にパスワードを与える必要があります。--ask-vault-pass を毎回入力するより、パスワードファイルを作って ansible.cfg にパスを登録 しておくとミスが減ります。

# ansible.cfg
[defaults]
vault_password_file = ./vault_pass.txt

# 変数ファイルの暗号化/編集
ansible-vault encrypt secret.yml
ansible-vault edit secret.yml

5) mount は state=mounted #

ファイルシステムのマウント作業で state: present は /etc/fstab エントリを追加するだけで、今マウントはしません。 試験は普通「今マウントし、再起動後も維持」を要求するので state: mounted を使います。present と mounted の違いを混同すると永続適用の点数を失います。

- name: NFS を今マウントして fstab にも登録
  ansible.posix.mount:
    path: /mnt/data
    src: nfs.example.com:/export
    fstype: nfs
    state: mounted   # present は fstab だけ、mounted は今 + 永続

6) handler notify 名の不一致 #

notify に書いた名前と handler の name が 1 文字でも違うと、handler が呼ばれずサービスが再起動されません。設定を変えたのに反映されない定番の原因です。両者をコピーして正確に一致させます。

tasks:
  - name: 設定のデプロイ
    ansible.builtin.template:
      src: httpd.conf.j2
      dest: /etc/httpd/conf/httpd.conf
    notify: restart httpd   # 下の handler name と正確に一致する必要あり

handlers:
  - name: restart httpd
    ansible.builtin.service:
      name: httpd
      state: restarted

7) –syntax-check をしない #

プレイブックを書いてすぐ実行すると、YAML インデントやモジュール引数のエラーを実行中に初めて出会います。task をいくつか書くごとに --syntax-check で文法を、--check で動作を事前に検証する一連の動作を習慣に束ねます。

8) ansible.cfg 位置の混同 #

作業ディレクトリの外でプレイブックを実行すると、意図した ansible.cfg が読まれず inventory・become・remote_user が抜けます。すべてのプレイブックは ansible.cfg のある作業ディレクトリの中で実行し、ansible --version の config file 行でどの設定が読まれているかを確認します。

紛らわしい概念ペア #

作業中に瞬間的に混同しやすいペアを、一行の違いに圧縮します。

import_* と include_* は展開のタイミングが違います。import はプレイブックを読む時点で静的に展開され、task の tag と handler が先に見える一方、include は実行途中に動的に展開され、when・loop でブロック全体を条件分岐で制御できます。変数が実行中に決まる動的な状況なら include、それ以外は import が無難です。

copy と template は変数置換の有無が分かれ目です。ホストごとに値が違う必要のある設定ファイルは template で Jinja2 をレンダリングし、内容が固定のファイルは copy でそのまま送ります。試験で「ホストごとに違う値」という条件が見えたら template です。

ドメイン別の受験直前チェックリスト #

各ドメインで手がすぐ出るべき核心モジュールと手順です。

環境と inventory、接続 #

• inventory: static ホスト・グループ、group_vars・host_vars の分離
• ansible.cfg: 作業ディレクトリに置いて inventory・remote_user・become を登録
• 接続確認: ansible all -m ping、ansible --version の config file 行
• ad-hoc: ansible <host> -m <module> -a "..." で即席確認

プレイブックと変数、テンプレート #

• 冪等性: モジュール優先、command/shell は creates・changed_when
• 変数の優先順位、setup (fact)・ansible_facts、custom facts
• template: Jinja2 フィルター・when・loop、copy と区別
• handler: notify 名と handler name を正確に一致

制御フローとエラー処理、セキュリティ #

• block/rescue/always、failed_when・ignore_errors
• when・loop・until、tags で部分実行
• Vault: ansible-vault encrypt/edit、vault_password_file を登録

role と collection、system roles #

• role 構造 (tasks・handlers・defaults・templates)、ansible-galaxy init
• collection: ansible-galaxy collection list で FQCN 確認
• system roles: /usr/share/doc/rhel-system-roles/<role>/ の例をコピー

RHCSA 作業の自動化 (比重が半分) #

• ユーザー・グループ・パッケージ・repository: user・group・dnf・yum_repository
• サービス・chronyd・log: service・timesync role・logrotate
• ストレージ・ファイルシステム: lvg・lvol・filesystem・mount (state=mounted)
• firewall・SELinux・SSH キー: firewalld・seboolean・sefcontext・authorized_key

Remote Exam 受験直前の点検 #

RHCE は試験会場 (Kiosk) または Red Hat Remote Exam で受験します。開始前に次を確認します。

身分証 #

• 英文表記のある身分証 (パスポート推奨)、名前が登録情報と正確に一致
• 監督官の案内に従って身分証をカメラに提示

受験環境 #

• 机の上のすべての物を片付け、壁面のメモ・ポスターを除去
• 単一モニターを使用、補助画面を分離
• 外部の人の出入りを遮断、静かな単独空間を確保

システムと開始直後 #

• 提供されるライブイメージを USB で起動、安定した有線ネットワーク
• 開始直後に作業ディレクトリ・inventory・ansible.cfg・SSH キー・become をセットアップ
• 最初の task の前に ansible all -m ping で全ホストの接続を確認

まとめ #

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

• 4 時間の運用。すべて自動化なので環境セットアップが先。1 つのディレクトリに task を積み上げ、書くたびに --syntax-check・--check、過集中の禁止
• ansible-doc を武器に。インターネットなし。ansible-doc -l でモジュール検索、EXAMPLES をコピーして変形、ansible-galaxy collection list で FQCN 確認
• system roles の例。/usr/share/doc/rhel-system-roles/<role>/ の例示プレイブックをコピーして値だけ変更
• 冪等性。2 回実行して changed 0 を確認。command/shell は creates・changed_when で制御
• 定番のミス。FQCN の欠落、become の抜け、command の冪等性、Vault パスワードファイル、mount state=mounted、handler 名の不一致、syntax-check の省略、ansible.cfg の位置
• 紛らわしい概念ペア (present/mounted、import/include、copy/template)、ドメイン別チェックリスト、Remote Exam の点検

次へ: フルスケール模擬試験 #

最後の記事です。

#19 フルスケール模擬試験 (Ansible 統合シナリオ + 解説) では、実際の試験に近いドメイン分布で統合シナリオをプレイブックで解き、詳しい解説を付けます。4 時間を計りながら解いてみて、冪等性と永続適用を点検し、比重の大きい RHCSA 自動化ドメインをもう一度固める最後の段階です。