トップ > Ansible > RHEL(Red Hat Enterprise Linux) System Rolesについて

RHEL(Red Hat Enterprise Linux) System Rolesについて

Ansible Red Hat Enterprise Linux

レッドハット　ソリューションアーキテクト石倉です。

ここでは、 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時刻同期設定用ロール
selinuxSELinux操作用ロール
networkNetwork操作用ロール
kdumpKernel dumps操作用ロール
storageStorage操作用ロール
postfixPostfix (mail transfer agent)操作用ロール
sap_general_preconfigureSAP 共通Note適用ロール
sap_netweaver_preconfigureSAP NetWeaver Note適用ロール
sap_hana_preconfigureSAP HANA Note適用ロール
sap_hana_installSAP HANA インストール用ロール
kernel_settingsKernel settings用ロール
loggingLogging (rsyslog)操作用ロール
metricsMetrics (Performance Co-Pilot)操作用ロール
nbde_clientNetwork bound disk encryption client操作用ロール
nbde_serverNetwork bound disk encryption server操作用ロール
certificateCertificate issuance and renewal操作用ロール
tlogTerminal session recording操作用ロール
sshSecure Shell (SSH) client操作用ロール
sshdSecure Shell (SSH) server操作用ロール
crypto_policiesSystem-wide cryptographic policies操作用ロール
ha_clusterHigh availability clustering操作用ロール
vpnVirtual private networks操作用ロール
microsoft.sql.serverMicrosoft SQL Server設定用ロール
cockpitWeb console設定用ロール
firewallFirewall設定用ロール

システム管理者やインフラエンジニアの方が実施する作業がロールとして提供されています。
また、Microsoft 社の SQL Server や、SAP 社の S/4HANA 向けのロールもいくつかリリースされています。

では、実際に RHEL System Roles を使ってみたいと思います。
以下の 3 ステップで利用ができます。

  1. Ansible Core 、 RHEL System Roles のインストール
  2. Role を呼び出す Playbook を作成
  3. 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 で活用することにより作業の重労働化を抑止し、作業品質の安定化が実現できます。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。