Red Hat Certified Engineer (RHCE) #13: system roles (rhel-system-roles)

読了 8分

#12 Collection: Galaxy, Automation Hub では collection で role とモジュールをまとめて配布し、取り込む方法を身につけました。今回の記事では Red Hat が自ら作って検証した role 集である rhel-system-roles を扱います。RHCSA で手作業でやっていた時刻同期・firewall・SELinux の設定を、自分で role を書かずに すでに検証済みの role を取り込んで変数だけを埋めて 自動化する方式です。

rhel-system-roles は試験で素早く点数を確保する近道です。NTP や firewall、SELinux を設定せよという問題が出たら、自分で task を 1 行ずつ書く代わりに、その role を呼び出して変数を数個埋めれば終わるからです。この記事ではインストールからドキュメントの活用、よく使う role の変数までを整理します。

rhel-system-roles とは何か #

rhel-system-roles は Red Hat が提供し検証した Ansible role 集 です。RHEL システムのよくある管理作業を標準化されたインターフェースで抽象化したもので、ユーザーは内部実装を知らなくても変数を数個埋めるだけで、時刻同期・firewall・SELinux のような構成を一貫して適用できます。

核心となる価値は 抽象化 です。RHCSA で chronyd をインストールし /etc/chrony.conf を編集してサービスを enable していた一連の手作業を、timesync role は timesync_ntp_servers 変数 1 つで終わらせます。RHEL のバージョンが変わって内部ツールが変わっても role の変数インターフェースは維持されるので、同じプレイブックが複数のバージョンで動きます。

これらの role は Red Hat が自らテストしサポートするので、自分で書いた role よりも冪等性と安定性が保証されます。試験でも信頼して使えます。

自分で書いた role との違い #

#11 で自分で role を作成しました。自分で書いた role は task と変数をすべて自分で設計しなければなりませんが、rhel-system-roles は インターフェースだけ知ればよい 完成品です。試験で「こういう設定を適用せよ」という問題が出たとき、自分で task を書くか system role を使うかは自由ですが、system role の方が速くてミスが少ないです。

インストール #

rhel-system-roles は 2 つの経路でインストールします。環境に合った方を使えば大丈夫です。

1) RPM パッケージでインストール #

RHEL の標準 repository からパッケージでインストールする方式です。試験環境で最もよくあります。

RPMでインストール
sudo dnf install -y rhel-system-roles

インストールすると role 本体は /usr/share/ansible/roles/ に、ドキュメントと example は /usr/share/doc/rhel-system-roles/ に置かれます。このパスの role は redhat.rhel_system_roles.timesync のような FQCN でも、rhel-system-roles.timesync のような短い名前でも参照できます。

2) collection でインストール #

Ansible Galaxy や Automation Hub から collection の形で取り込む方式です。インターネットがある環境で最新バージョンを受け取るときに使います。

collectionとしてインストール
ansible-galaxy collection install redhat.rhel_system_roles

collection でインストールすると、role は redhat.rhel_system_roles.<role> FQCN で呼び出します。例えば timesync は redhat.rhel_system_roles.timesync になります。

試験環境はインターネットが遮断されるので RPM インストールが基本です。パッケージがすでに入っているかを rpm -q rhel-system-roles で先に確認します。

ドキュメントと example を活用する #

rhel-system-roles をうまく使う核心は ドキュメントを直接読む習慣 です。インターネットのない試験で各 role の変数名を覚えることはできないので、ローカルのドキュメントを素早く探して example をコピーして使う方式が正解です。

ドキュメントの場所 #

インストールされたドキュメントは次のパスにあります。

ドキュメント位置の確認
ls /usr/share/doc/rhel-system-roles/

各 role ごとにサブディレクトリがあり、その中に README.md と example playbook が入っています。

timesyncドキュメントの確認
ls /usr/share/doc/rhel-system-roles/timesync/
# README.md  example-timesync-playbook.yml  ...

README.md には、その role が受け取る変数の一覧と説明、デフォルト値が整理されています。example playbook にはすぐ実行可能な形の呼び出し例が入っています。

example のコピーパターン #

試験で最も速い道は example playbook を作業ディレクトリにコピーして変数だけを修正する 方式です。変数名を覚えたりタイプミスをしたりする危険がなくなります。

example playbookのコピー
cp /usr/share/doc/rhel-system-roles/timesync/example-timesync-playbook.yml \
   ~/myplaybook.yml

コピーした後、README.md を参考にしながら hosts と変数値だけを環境に合わせて直せば大丈夫です。このパターンは timesync だけでなくすべての system role に同じように適用されます。

よく使う role と変数 #

rhel-system-roles には数十個の role が入っていますが、試験と実務でよく使うものは決まっています。主な role と核心変数を整理します。

role用途核心変数
timesyncNTP 時刻同期timesync_ntp_servers
firewallfirewalld ルールfirewall (サービス・ポート・zone の一覧)
selinuxSELinux mode・boolean・ポート・fcontextselinux_state, selinux_booleans
storageLVM・ファイルシステム構成storage_pools, storage_volumes
networkネットワークインターフェース・接続network_connections
postfixメール転送エージェント設定postfix_conf

各 role の正確な変数の一覧は常にその README.md で確認します。以下で試験の定番である 3 つを例で扱います。

timesync role #

timesync role は NTP サーバーの一覧を受け取って chronyd をインストールし設定した後、同期します。RHCSA の時刻同期作業を 1 つのブロックで置き換えます。

timesyncプレイブック
---
- name: NTP 時刻同期の構成
  hosts: all
  become: true
  vars:
    timesync_ntp_servers:
      - hostname: 0.jp.pool.ntp.org
        iburst: true
      - hostname: 1.jp.pool.ntp.org
        iburst: true
  roles:
    - redhat.rhel_system_roles.timesync

timesync_ntp_servers は各項目に hostnameiburst を受け取ります。iburst: true は初期同期を速くしてくれるオプションで、RHCSA で手作業で /etc/chrony.conf に書いていた値と同じです。

firewall role #

firewall role は firewalld のサービス・ポート・zone を宣言的に管理します。firewall 変数にルールの一覧を与えれば大丈夫です。

firewallプレイブック
---
- name: firewall ルールの構成
  hosts: webservers
  become: true
  vars:
    firewall:
      - service: http
        state: enabled
        permanent: true
      - service: https
        state: enabled
        permanent: true
      - port: 8080/tcp
        state: enabled
        permanent: true
  roles:
    - redhat.rhel_system_roles.firewall

各ルールは service または port を指定し、state で enabled・disabled を、permanent: true で再起動後も維持されるようにします。RHCSA で firewall-cmd --add-service--permanent でやっていた作業をそのまま抽象化したものです。

selinux role #

selinux role は SELinux mode と boolean、ポートラベル、ファイルコンテキストを管理します。boolean を永続で有効にしたりポートにラベルを付けたりする作業によく使います。

selinuxプレイブック
---
- name: SELinux の構成
  hosts: webservers
  become: true
  vars:
    selinux_state: enforcing
    selinux_booleans:
      - name: httpd_can_network_connect
        state: on
        persistent: true
    selinux_ports:
      - ports: "8080"
        proto: tcp
        setype: http_port_t
        state: present
  roles:
    - redhat.rhel_system_roles.selinux

selinux_state で enforcing・permissive を指定し、selinux_booleans で boolean を永続に (persistent: true) 設定し、selinux_ports でポートに type を付けます。RHCSA の setsebool -Psemanage port -a に対応します。

selinux role を使うとき、boolean や fcontext の変更後に再起動が必要な状況があれば role が案内します。README の注意事項を一度ざっと読んでおく方が安全です。

複数の role を 1 つのプレイブックで #

system role は互いに独立しているので、1 つのプレイブックで複数を一緒に呼び出せます。ウェブサーバー 1 台を構成するなら、次のようにまとめます。

複数roleの統合プレイブック
---
- name: ウェブサーバーの標準構成
  hosts: webservers
  become: true
  vars:
    timesync_ntp_servers:
      - hostname: 0.jp.pool.ntp.org
        iburst: true
    firewall:
      - service: http
        state: enabled
        permanent: true
    selinux_booleans:
      - name: httpd_can_network_connect
        state: on
        persistent: true
  roles:
    - redhat.rhel_system_roles.timesync
    - redhat.rhel_system_roles.firewall
    - redhat.rhel_system_roles.selinux

各 role は自分の変数だけを読むので、変数を一箇所に集めておいても衝突しません。ただし変数が多くなったら group_vars で分離する方が読みやすいです。

冪等性の確認 #

system role は Red Hat が冪等性を保証しますが、書いたプレイブックが意図どおりに動くかは自分で確認します。2 回実行して 2 回目で changed が 0 になるかを見る習慣は #5 から続く原則です。

冪等性検証 — 二回実行
ansible-navigator run -m stdout site.yml
ansible-navigator run -m stdout site.yml

2 回目の実行で changed=0 なら冪等性が守られたということです。変数値がすでに適用された状態なので、role は何の変更もしません。

試験ポイント #

  • example をコピーして変数だけを修正する流れを手に覚えさせる。 /usr/share/doc/rhel-system-roles/<role>/ の example playbook を作業ディレクトリにコピーし、同じディレクトリの README.md で変数を確認した後、値だけを直すのが最も速くて安全です。
  • role の呼び出し名を正確に書く。 collection でインストールしたなら redhat.rhel_system_roles.timesync FQCN を、RPM 環境の短い名前なら rhel-system-roles.timesync を使います。環境に入っている形を先に確認します。
  • NTP・firewall・SELinux は定番の出題です。 時刻同期は timesync、firewall ルールは firewall、SELinux の boolean・ポートは selinux role で解く流れを前もって手に覚えさせます。
  • 永続適用のオプションを落とさないようにします。 firewall の permanent: true、selinux boolean の persistent: true のように再起動後も維持される設定を明示しないと採点で減点されます。
  • 冪等性を 2 回の実行で検証します。 2 回目の実行で changed が 0 かを確認する習慣を付けます。

まとめ #

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

  • rhel-system-roles は Red Hat が検証した role 集 で、RHCSA の作業を変数インターフェースで抽象化します。
  • インストールは dnf install rhel-system-roles (RPM) または ansible-galaxy collection install redhat.rhel_system_roles (collection) の 2 つの経路があり、試験環境は RPM が基本です。
  • ドキュメントは /usr/share/doc/rhel-system-roles/ にあり、example playbook をコピーして変数だけを修正する パターンが最も速いです。
  • よく使う role は timesync・firewall・selinux・storage・network・postfix で、各 role の変数はその README.md で確認します。
  • NTP・firewall・SELinux の設定は試験の定番なので、3 つの role の核心変数を手に覚えさせます。

次へ — RHCSA 自動化 1 #

ここまでが Ansible 文法と構造化 (role・collection・system roles) の領域です。これから試験の比重の半分を占める RHCSA 作業の自動化に入ります。

#14 RHCSA 自動化 1: ユーザー/グループ、パッケージ/repository では、user・group モジュールでアカウントを作り、dnf・yum_repository モジュールでパッケージと repository を管理する方法を、試験でよく出る形そのままにプレイブックで書きながら整理します。

X