レッドハット ソリューションアーキテクト石倉です。
ここでは、 RHEL System Roles について紹介をします。
システム関連の作業で、サーバにログインして構築作業を実施したり、ログインしてパッチ適用や設定ファイルの変更作業などを実施することは日常的にあると思います。
対象システムが数台程度であればそれでも問題は無いかもしれないですが、多数のシステムを同じようにそれぞれログインしてメンテナンスしていくことは非常に重労働ですし、人手で対応することで設定ミス、作業漏れなどが発生しがちです。
RHEL System Roles は、そのようなインフラ作業を効率化する目的で開発されています。
RHEL System Roles とは、 Red Hat Enterprise Linux を管理および設定する安定した設定インターフェイスを提供する Ansible ロール、モジュール、および Playbook のコレクションです。
Red Hat にて開発された RHEL System Roles を活用することで、システムにログインすること無く、対象システムのメンテナンスを実施することが可能です。
2022年10月現在、 RHEL System Roles では以下のラインナップがあり、その数は日々増えています。
参考：
Red Hat Enterprise Linux (RHEL) System Roles - Red Hat Customer Portal
- 一部 Tech preview のものや、 RHEL のバージョンによって利用できないものもあるので、詳細は上記 URL をご確認ください。
| ロール名 | 説明 |
|---|---|
| timesync | 時刻同期設定用ロール |
| selinux | SELinux操作用ロール |
| network | Network操作用ロール |
| kdump | Kernel dumps操作用ロール |
| storage | Storage操作用ロール |
| postfix | Postfix (mail transfer agent)操作用ロール |
| sap_general_preconfigure | SAP 共通Note適用ロール |
| sap_netweaver_preconfigure | SAP NetWeaver Note適用ロール |
| sap_hana_preconfigure | SAP HANA Note適用ロール |
| sap_hana_install | SAP HANA インストール用ロール |
| kernel_settings | Kernel settings用ロール |
| logging | Logging (rsyslog)操作用ロール |
| metrics | Metrics (Performance Co-Pilot)操作用ロール |
| nbde_client | Network bound disk encryption client操作用ロール |
| nbde_server | Network bound disk encryption server操作用ロール |
| certificate | Certificate issuance and renewal操作用ロール |
| tlog | Terminal session recording操作用ロール |
| ssh | Secure Shell (SSH) client操作用ロール |
| sshd | Secure Shell (SSH) server操作用ロール |
| crypto_policies | System-wide cryptographic policies操作用ロール |
| ha_cluster | High availability clustering操作用ロール |
| vpn | Virtual private networks操作用ロール |
| microsoft.sql.server | Microsoft SQL Server設定用ロール |
| cockpit | Web console設定用ロール |
| firewall | Firewall設定用ロール |
システム管理者やインフラエンジニアの方が実施する作業がロールとして提供されています。
また、Microsoft 社の SQL Server や、SAP 社の S/4HANA 向けのロールもいくつかリリースされています。
では、実際に RHEL System Roles を使ってみたいと思います。
以下の 3 ステップで利用ができます。
- Ansible Core 、 RHEL System Roles のインストール
- Role を呼び出す Playbook を作成
- Playbook の実行
一つずつ、実際のやり方をご紹介します。
* 今回はRHEL9.0 で作業を実施していますが、RHEL 7, 8, 9 で同じ手順で操作できます。
OS のバージョンにより、 Ansible Core が含まれるリポジトリが異なる場合がありますので、その点はご注意ください。
1. Ansible Core 、 RHEL System Roles のインストール
作業対象に Ansible Core と RHEL System Roles をインストールします。
ご存知のように、Ansible は IT 自動化ツールです。
Ansible の活用により、システムの構成、ソフトウェアの展開、より高度な IT タスク (継続的なデプロイメント、ダウンタイムなしのローリング更新など) のオーケストレーションが可能になります。
もし、対象の環境が既に Ansible を利用した自動化環境を構成しているのであれば、既存のコントロールノードから Playbook を実行すれば良いでしょう。
ここでは Ansible による自動化環境が構成されていない想定とし、自ノードに Ansible Core を導入しています。
Ansible Core は Ansible の主要なビルディングブロックおよびアーキテクチャーであり、CLI ツールや Ansible プラグインが含まれます。
なお、 RHEL のサブスクリプションをお持ちであれば、 Ansible Automation Platform のサブスクリプションは購入していなくても、 RHEL System Roles のサポートを受けることが可能です。
詳細は以下をご確認ください。
Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories - Red Hat Customer Portal
RHEL System Roles と、必要となる Ansible Core をインストールします。
# dnf install rhel-system-roles ansible-core
Ansible Core のインストールが終わると、ansibleコマンドが利用可能になります。
# ansible --version ansible [core 2.12.2] config file = /etc/ansible/ansible.cfg configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3.9/site-packages/ansible ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections executable location = /bin/ansible python version = 3.9.10 (main, Feb 9 2022, 00:00:00) [GCC 11.2.1 20220127 (Red Hat 11.2.1-9)] jinja version = 2.11.3 libyaml = True
また、RHEL System Roles は、/usr/share/ansible/roles/以下に展開されます。
# ls /usr/share/ansible/roles | grep rhel-system-roles rhel-system-roles.certificate rhel-system-roles.cockpit rhel-system-roles.crypto_policies rhel-system-roles.firewall rhel-system-roles.ha_cluster rhel-system-roles.kdump rhel-system-roles.kernel_settings rhel-system-roles.logging rhel-system-roles.metrics rhel-system-roles.nbde_client rhel-system-roles.nbde_server rhel-system-roles.network rhel-system-roles.postfix rhel-system-roles.selinux rhel-system-roles.ssh rhel-system-roles.sshd rhel-system-roles.storage rhel-system-roles.timesync rhel-system-roles.tlog rhel-system-roles.vpn
- ドキュメントと、幾つかのサンプル Playbook は、
/usr/share/doc/rhel-system-roles/以下に展開されます。 - SQL Server や、 S/4HANA のようなサードパーティーアプリケーションの Role は、それぞれ、
ansible-collection-microsoft-sql、rhel-system-roles-sapのインストールが必要です。
(S/4HANA用のものは、専用のRHEL for SAP Solutionsサブスクリプションが必要となります。)
2. Role を呼び出す Playbook を作成
数ある RHEL System Roles の中で、今回は storage Role を利用しての、ファイルシステム拡張を実施してみます。
例として、/dev/sdbに/app/dataを100GBで、/app/logを20GBで作成することにします。
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 99G 0 part ├─rhel-root 253:0 0 65.1G 0 lvm / ├─rhel-swap 253:1 0 2G 0 lvm [SWAP] └─rhel-home 253:2 0 31.8G 0 lvm /home sdb 8:16 0 200G 0 disk sr0 11:0 1 1024M 0 rom
実行する Playbook を作成します。
中身は以下です。
実行対象はlocalhost、また、 Ansible 変数で、作成対象のボリュームサイズや Mount Point 、ファイルシステムフォーマットを指定し、 storage Role を呼び出すようにします。
# cat app-storage-prepare.yml
---
- hosts: localhost
vars:
storage_pools:
- name: app-area
disks:
- sdb
volumes:
- name: appdata
size: "100 GiB"
mount_point: "/app/data"
fs_type: xfs
state: present
- name: applog
size: "50 GiB"
mount_point: "/app/log"
fs_type: ext4
state: present
roles:
- rhel-system-roles.storage
3. Playbook の実行
準備が出来たらPlaybookを実行します。
# ansible-playbook app-storage-prepare.yml
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
PLAY [localhost] **************************************************************************************************************
TASK [Gathering Facts] ********************************************************************************************************
ok: [localhost]
TASK [rhel-system-roles.storage : Set version specific variables] *************************************************************
ok: [localhost]
TASK [rhel-system-roles.storage : define an empty list of pools to be used in testing] ****************************************
ok: [localhost]
TASK [rhel-system-roles.storage : define an empty list of volumes to be used in testing] **************************************
ok: [localhost]
TASK [rhel-system-roles.storage : include the appropriate provider tasks] *****************************************************
included: /usr/share/ansible/roles/rhel-system-roles.storage/tasks/main-blivet.yml for localhost
TASK [rhel-system-roles.storage : get a list of rpm packages installed on host machine] ***************************************
skipping: [localhost]
TASK [rhel-system-roles.storage : make sure blivet is available] **************************************************************
ok: [localhost]
TASK [rhel-system-roles.storage : show storage_pools] *************************************************************************
ok: [localhost] => {
"storage_pools": [
{
"disks": [
"sdb"
],
"name": "app-area",
"volumes": [
{
"fs_type": "xfs",
"mount_point": "/app/data",
"name": "appdata",
"size": "100 GiB",
"state": "present"
},
{
"fs_type": "ext4",
"mount_point": "/app/log",
"name": "applog",
"size": "50 GiB",
"state": "present"
}
]
}
]
}
TASK [rhel-system-roles.storage : show storage_volumes] ***********************************************************************
ok: [localhost] => {
"storage_volumes": "VARIABLE IS NOT DEFINED!"
}
・
・
・
(中略)
・
・
・
TASK [rhel-system-roles.storage : set up new/current mounts] ******************************************************************
changed: [localhost] => (item={'src': '/dev/mapper/app--area-appdata', 'path': '/app/data', 'fstype': 'xfs', 'opts': 'defaults', 'dump': 0, 'passno': 0, 'state': 'mounted'})
changed: [localhost] => (item={'src': '/dev/mapper/app--area-applog', 'path': '/app/log', 'fstype': 'ext4', 'opts': 'defaults', 'dump': 0, 'passno': 0, 'state': 'mounted'})
TASK [rhel-system-roles.storage : tell systemd to refresh its view of /etc/fstab] *********************************************
ok: [localhost]
TASK [rhel-system-roles.storage : retrieve facts for the /etc/crypttab file] **************************************************
ok: [localhost]
TASK [rhel-system-roles.storage : manage /etc/crypttab to account for changes we just made] ***********************************
TASK [rhel-system-roles.storage : Update facts] *******************************************************************************
ok: [localhost]
PLAY RECAP ********************************************************************************************************************
localhost : ok=22 changed=2 unreachable=0 failed=0 skipped=9 rescued=0 ignored=0
程なくして処理が終わります。 実際に確認をしてみると、
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 99G 0 part ├─rhel-root 253:0 0 65.1G 0 lvm / ├─rhel-swap 253:1 0 2G 0 lvm [SWAP] └─rhel-home 253:2 0 31.8G 0 lvm /home sdb 8:16 0 200G 0 disk ├─app--area-applog 253:3 0 50G 0 lvm /app/log └─app--area-appdata 253:4 0 100G 0 lvm /app/data sr0 11:0 1 1024M 0 rom
# grep app--area /etc/fstab /dev/mapper/app--area-appdata /app/data xfs defaults 0 0 /dev/mapper/app--area-applog /app/log ext4 defaults 0 0
ボリュームの作成だけでなく、 Mount Point ディレクトリの作成や、 fstab の更新まで処理されることがわかります。
作成した Playbook は再利用が可能ですので、似たような設定が必要なシステムでは同じ Playbook を利用して設定を行うことで、人手で行う事に起因して発生する、設定ミスや作業漏れなどが抑制できるのがご理解いただけたと思います。
また、対象システムが多ければ多いほど、自動化の効果は絶大な効果を発揮します。
RHEL System Roles を Ansible で活用することにより作業の重労働化を抑止し、作業品質の安定化が実現できます。
