RHEL システムロールを使用したシステム管理の自動化

手順

1. Playbook を管理および実行するための ansible という名前のユーザーを作成します。

   [root@control-node]# useradd ansible

2. 新しく作成した ansible ユーザーに切り替えます。

   [root@control-node]# su - ansible

   このユーザーとして残りの手順を実行します。

3. SSH の公開鍵と秘密鍵を作成します。

   [ansible@control-node]$ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/ansible/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase): <password>
   Enter same passphrase again: <password>
   ...

   キーファイルの推奨されるデフォルトの場所を使用します。

4. オプション: 接続を確立するたびに Ansible が SSH キーのパスワードを要求しないように、SSH エージェントを設定します。

5. ~/.ansible.cfg ファイルを次の内容で作成します。

   [defaults]
   inventory = /home/ansible/inventory
   remote_user = ansible
   
   [privilege_escalation]
   become = True
   become_method = sudo
   become_user = root
   become_ask_pass = True

   注記

   ~/.ansible.cfg ファイルの設定は優先度が高く、グローバルな /etc/ansible/ansible.cfg ファイルの設定をオーバーライドします。

   これらの設定を使用して、Ansible は次のアクションを実行します。

   • 指定されたインベントリーファイルでホストを管理します。
   • 管理対象ノードへの SSH 接続を確立するときに、remote_user パラメーターで設定されたアカウントを使用します。
   • sudo ユーティリティーを使用して、root ユーザーとして管理対象ノードでタスクを実行します。
   • Playbook を適用するたびに、リモートユーザーの root パスワードの入力を求められます。これは、セキュリティー上の理由から推奨されます。

6. 管理対象ホストのホスト名をリストする ~/inventory ファイルを INI または YAML 形式で作成します。インベントリーファイルでホストのグループを定義することもできます。たとえば、以下は、3 つのホストと US という名前の 1 つのホストグループを含む INI 形式のインベントリーファイルです。

   managed-node-01.example.com
   
   [US]
   managed-node-02.example.com ansible_host=192.0.2.100
   managed-node-03.example.com

   コントロールノードはホスト名を解決できる必要があることに注意してください。DNS サーバーが特定のホスト名を解決できない場合は、ホストエントリーの横に ansible_host パラメーターを追加して、その IP アドレスを指定します。

7. RHEL システムロールをインストールします。

   • Ansible Automation Platform のない RHEL ホストに、rhel-system-roles パッケージをインストールします。

     [root@control-node]# yum install rhel-system-roles

     このコマンドは、/usr/share/ansible/collections/ansible_collections/redhat/rhel_system_roles/ ディレクトリーにコレクションをインストールし、依存関係として ansible-core パッケージをインストールします。

   • Ansible Automation Platform で、ansible ユーザーとして次の手順を実行します。

     1. ~/.ansible.cfg ファイルで コンテンツのプライマリーソースとして Red Hat Automation Hub を定義します。

     2. Red Hat Automation Hub から redhat.rhel_system_roles コレクションをインストールします。

        [ansible@control-node]$ ansible-galaxy collection install redhat.rhel_system_roles

        このコマンドは、コレクションを ~/.ansible/collections/ansible_collections/redhat/rhel_system_roles/ ディレクトリーにインストールします。

手順

1. ansible という名前のユーザーを作成します。

   [root@managed-node-01]# useradd ansible

   コントロールノードは後でこのユーザーを使用して、このホストへの SSH 接続を確立します。

2. ansible ユーザーのパスワードを設定します。

   [root@managed-node-01]# passwd ansible
   Changing password for user ansible.
   New password: <password>
   Retype new password: <password>
   passwd: all authentication tokens updated successfully.

   Ansible が sudo を使用して root ユーザーとしてタスクを実行する場合は、このパスワードを入力する必要があります。

3. ansible ユーザーの SSH 公開鍵を管理対象ノードにインストールします。

   1. ansible ユーザーとしてコントロールノードにログインし、SSH 公開鍵を管理対象ノードにコピーします。

      [ansible@control-node]$ ssh-copy-id managed-node-01.example.com
      /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ansible/.ssh/id_rsa.pub"
      The authenticity of host 'managed-node-01.example.com (192.0.2.100)' can't be established.
      ECDSA key fingerprint is SHA256:9bZ33GJNODK3zbNhybokN/6Mq7hu3vpBXDrCxe7NAvo.

   2. プロンプトが表示されたら、yes と入力して接続します。

      Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

   3. プロンプトが表示されたら、パスワードを入力します。

      ansible@managed-node-01.example.com's password: <password>
      
      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh 'managed-node-01.example.com'"
      and check to make sure that only the key(s) you wanted were added.

   4. コントロールノードでコマンドをリモートで実行して、SSH 接続を確認します。

      [ansible@control-node]$ ssh managed-node-01.example.com whoami
      ansible

4. ansible ユーザーの sudo 設定を作成します。

   1. visudo コマンドを使用して、/etc/sudoers.d/ansible ファイルを作成および編集します。

      [root@managed-node-01]# visudo /etc/sudoers.d/ansible

      通常のエディターではなく visudo を使用する利点は、このユーティリティーがファイルをインストールする前に解析エラーなどの基本的なチェックを提供する点にあります。

   2. /etc/sudoers.d/ansible ファイルで、要件に応じた sudoers ポリシーを設定します。次に例を示します。

      • ansible ユーザーのパスワードを入力した後、このホスト上で任意のユーザーおよびグループとしてすべてのコマンドを実行する権限を ansible ユーザーに付与するには、以下を使用します。

        ansible   ALL=(ALL) ALL

      • ansible ユーザーのパスワードを入力せずに、このホスト上で任意のユーザーおよびグループとしてすべてのコマンドを実行する権限を ansible ユーザーに付与するには、以下を使用します。

        ansible   ALL=(ALL) NOPASSWD: ALL

   または、セキュリティー要件に合わせてより細かいポリシーを設定します。sudoers ポリシーの詳細は、sudoers(5) man ページを参照してください。

検証

1. すべての管理対象ノード上のコントロールノードからコマンドを実行できることを確認します。

   [ansible@control-node]$ ansible all -m ping
   BECOME password: <password>
   managed-node-01.example.com | SUCCESS => {
       	"ansible_facts": {
       	    "discovered_interpreter_python": "/usr/bin/python3"
       	},
       	"changed": false,
       	"ping": "pong"
   }
   ...

   ハードコーディングされたすべてのホストグループには、インベントリーファイルにリストされているすべてのホストが動的に含まれます。

2. Ansible command モジュールを使用して管理対象ノードで whoami ユーティリティーを実行し、権限昇格が正しく機能することを確認します。

   [ansible@control-node]$ ansible all -m command -a whoami
   BECOME password: <password>
   managed-node-01.example.com | CHANGED | rc=0 >>
   root
   ...

   コマンドが root を返した場合、管理対象ノード上で sudo が正しく設定されています。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Set boot device to be used on next boot
     hosts: managed-node-01.example.com
     tasks:
       - name: Ensure boot device is HD
         redhat.rhel_mgmt.ipmi_boot:
           user: <admin_user>
           password: <password>
           bootdev: hd

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Power management
     hosts: managed-node-01.example.com
     tasks:
       - name: Ensure machine is powered on
         redhat.rhel_mgmt.ipmi_power:
           user: <admin_user>
           password: <password>
           state: on

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

1. redfish_info: redfish_info モジュールは、システムインベントリーなどのリモートアウトオブバンド (OOB) コントローラーに関する情報を取得します。
2. redfish_command: redfish_command モジュールは、ログ管理やユーザー管理などの帯域外 (OOB) コントローラー操作と、システムの再起動、電源のオンとオフなどの電源操作を実行します。
3. redfish_config: redfish_config モジュールは、OOB 設定の変更や BIOS 設定の設定などの OOB コントローラー操作を実行します。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Manage out-of-band controllers using Redfish APIs
     hosts: managed-node-01.example.com
     tasks:
       - name: Get CPU inventory
         redhat.rhel_mgmt.redfish_info:
           baseuri: "<URI>"
           username: "<username>"
           password: "<password>"
           category: Systems
           command: GetCpuInventory
         register: result

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Manage out-of-band controllers using Redfish APIs
     hosts: managed-node-01.example.com
     tasks:
       - name: Power on system
         redhat.rhel_mgmt.redfish_command:
           baseuri: "<URI>"
           username: "<username>"
           password: "<password>"
           category: Systems
           command: PowerOn

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Manages out-of-band controllers using Redfish APIs
     hosts: managed-node-01.example.com
     tasks:
       - name: Set BootMode to UEFI
         redhat.rhel_mgmt.redfish_config:
           baseuri: "<URI>"
           username: "<username>"
           password: "<password>"
   	category: Systems
           command: SetBiosAttributes
           bios_attributes:
             BootMode: Uefi

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      usr: administrator
      pwd: <password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Active Directory integration
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Join an Active Directory
         ansible.builtin.include_role:
           name: rhel-system-roles.ad_integration
         vars:
           ad_integration_user: "{{ usr }}"
           ad_integration_password: "{{ pwd }}"
           ad_integration_realm: "ad.example.com"
           ad_integration_allow_rc4_crypto: false
           ad_integration_timesync_source: "time_server.ad.example.com"

   サンプル Playbook で指定されている設定は次のとおりです。

   ad_integration_allow_rc4_crypto: <true|false>

   ロールが管理対象ノードで AD-SUPPORT 暗号化ポリシーを有効にするかどうかを設定します。デフォルトでは、RHEL は脆弱な RC4 暗号化をサポートしていませんが、それでも AD 内の Kerberos で RC4 が必要な場合は、ad_integration_allow_rc4_crypto: true を設定することでこの暗号化タイプを有効にできます。

   Kerberos が AES 暗号化を使用する場合は、この変数を省略するか、false に設定します。

   ad_integration_timesync_source: <time_server>

   時刻同期に使用する NTP サーバーを指定します。Kerberos は、リプレイ攻撃を防ぐために、AD のドメインコントローラーとドメインメンバー間の時刻同期を必要とします。この変数を省略すると、ad_integration ロールは、管理対象ノードで時刻同期を設定するために timesync RHEL システムロールを使用しません。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ad_integration/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create certificates
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a self-signed certificate
         ansible.builtin.include_role:
           name: rhel-system-roles.certificate
         vars:
           certificate_requests:
             - name: web-server
               ca: ipa
               dns: www.example.com
               principal: HTTP/www.example.com@EXAMPLE.COM
               run_before: systemctl stop httpd.service
               run_after: systemctl start httpd.service

   サンプル Playbook で指定されている設定は次のとおりです。

   name: <path_or_file_name>

   生成される秘密鍵と証明書ファイルの名前またはパスを定義します。

   • 変数を web-server に設定すると、ロールによって秘密鍵が /etc/pki/tls/private/web-server.key に保存され、証明書が /etc/pki/tls/certs/web-server.crt ファイルに保存されます。

   • 変数を /tmp/web-server などのパスに設定すると、ロールによって秘密鍵が /tmp/web-server.key に保存され、証明書が /tmp/web-server.crt ファイルに保存されます。

     使用するディレクトリーに cert_t SELinux コンテキストが設定されている必要があることに注意してください。SELinux コンテキストは、selinux RHEL システムロールを使用して管理できます。

   ca: ipa

   ロールが IdM CA から証明書を要求することを指定します。

   dns: <hostname_or_list_of_hostnames>

   発行された証明書のサブジェクト代替名 (SAN) フィールドに含まれるホスト名を設定します。ワイルドカード (*) を使用することも、YAML リスト形式で複数の名前を指定することもできます。

   principal: <kerberos_principal>

   オプション: 証明書に含める Kerberos プリンシパルを設定します。

   run_before: <command>

   オプション: CA から証明書を要求する前に certmonger が実行するコマンドを定義します。

   run_after: <command>

   オプション: CA から発行された証明書を受け取った後に certmonger が実行するコマンドを定義します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.certificate/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create certificates
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a self-signed certificate
         ansible.builtin.include_role:
           name: rhel-system-roles.certificate
         vars:
           certificate_requests:
             - name: web-server
               ca: self-sign
               dns: test.example.com

   サンプル Playbook で指定されている設定は次のとおりです。

   name: <path_or_file_name>

   生成される秘密鍵と証明書ファイルの名前またはパスを定義します。

   • 変数を web-server に設定すると、ロールによって秘密鍵が /etc/pki/tls/private/web-server.key に保存され、証明書が /etc/pki/tls/certs/web-server.crt ファイルに保存されます。

   • 変数を /tmp/web-server などのパスに設定すると、ロールによって秘密鍵が /tmp/web-server.key に保存され、証明書が /tmp/web-server.crt ファイルに保存されます。

     使用するディレクトリーに cert_t SELinux コンテキストが設定されている必要があることに注意してください。SELinux コンテキストは、selinux RHEL システムロールを使用して管理できます。

   ca: self-sign

   ロールで自己署名証明書を作成することを指定します。

   dns: <hostname_or_list_of_hostnames>

   発行された証明書のサブジェクト代替名 (SAN) フィールドに含まれるホスト名を設定します。ワイルドカード (*) を使用することも、YAML リスト形式で複数の名前を指定することもできます。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.certificate/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Manage the RHEL web console
     hosts: managed-node-01.example.com
     tasks:
       - name: Install RHEL web console
         ansible.builtin.include_role:
           name: rhel-system-roles.cockpit
         vars:
           cockpit_packages: default
           cockpit_port: 9050
           cockpit_manage_selinux: true
           cockpit_manage_firewall: true
           cockpit_certificates:
             - name: /etc/cockpit/ws-certs.d/01-certificate
               dns: ['localhost', 'www.example.com']
               ca: ipa

   サンプル Playbook で指定されている設定は次のとおりです。

   cockpit_manage_selinux: true

   selinux システムロールを使用して、websm_port_t SELinux タイプで正しいポート権限を設定するように SELinux を設定できるようにします。

   cockpit_manage_firewall: true

   cockpit システムロールが firewalld システムロールを使用してポートを追加できるようにします。

   cockpit_certificates: <YAML_dictionary>

   デフォルトでは、RHEL Web コンソールは自己署名証明書を使用します。または、cockpit_certificates 変数を Playbook に追加し、IdM 認証局 (CA) から証明書を要求するか、管理対象ノードで使用可能な既存の証明書と秘密鍵を使用するようにロールを設定することもできます。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.cockpit/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure cryptographic policies
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure the FUTURE cryptographic security policy on the managed node
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
         vars:
           - crypto_policies_policy: FUTURE
           - crypto_policies_reboot_ok: true

   サンプル Playbook で指定されている設定は次のとおりです。

   crypto_policies_policy: FUTURE

   管理対象ノードで必要な暗号化ポリシー (FUTURE) を設定します。これは、基本ポリシー、またはいくつかのサブポリシーを含む基本ポリシーのどちらかです。指定した基本ポリシーとサブポリシーが、管理対象ノードで使用可能である必要があります。デフォルト値は null です。つまり、設定は変更されず、crypto_policies RHEL システムロールは Ansible fact のみを収集します。

   crypto_policies_reboot_ok: true

   すべてのサービスとアプリケーションが新しい設定ファイルを読み取るように、暗号化ポリシーの変更後にシステムを再起動します。デフォルト値は false です。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. コントロールノードで、たとえば verify_playbook.yml という名前の別の Playbook を作成します。

   ---
   - name: Verification
     hosts: managed-node-01.example.com
     tasks:
       - name: Verify active cryptographic policy
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
       - name: Display the currently active cryptographic policy
         ansible.builtin.debug:
           var: crypto_policies_active

   サンプル Playbook で指定されている設定は次のとおりです。

   crypto_policies_active

   crypto_policies_policy 変数で受け入れられる形式の現在アクティブなポリシー名が含まれているエクスポートされた Ansible fact。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/verify_playbook.yml

3. Playbook を実行します。

   $ ansible-playbook ~/verify_playbook.yml
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   crypto_policies_active 変数は、管理対象ノード上のアクティブなポリシーを示します。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Reset firewalld example
     hosts: managed-node-01.example.com
     tasks:
       - name: Reset firewalld
         ansible.builtin.include_role:
           name: rhel-system-roles.firewall
         vars:
           firewall:
             - previous: replaced

   サンプル Playbook で指定されている設定は次のとおりです。

   previous: replaced

   既存のユーザー定義設定をすべて削除し、firewalld 設定をデフォルトにリセットします。previous:replaced パラメーターを他の設定と組み合わせると、firewall ロールは新しい設定を適用する前に既存の設定をすべて削除します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.firewall/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
       - name: Forward incoming traffic on port 8080 to 443
         ansible.builtin.include_role:
           name: rhel-system-roles.firewall
         vars:
           firewall:
             - forward_port: 8080/tcp;443;
               state: enabled
               runtime: true
               permanent: true

   サンプル Playbook で指定されている設定は次のとおりです。

   forward_port: 8080/tcp;443

   TCP プロトコルを使用してローカルポート 8080 に送信されるトラフィックが、ポート 443 に転送されます。

   runtime: true

   ランタイム設定の変更を有効にします。デフォルトは true に設定されています。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.firewall/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure firewalld
     hosts: managed-node-01.example.com
     tasks:
       - name: Creating a DMZ with access to HTTPS port and masquerading for hosts in DMZ
         ansible.builtin.include_role:
           name: rhel-system-roles.firewall
         vars:
           firewall:
             - zone: dmz
               interface: enp1s0
               service: https
               state: enabled
               runtime: true
               permanent: true

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.firewall/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create TLS certificates and key files in a high availability cluster
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_pcsd_certificates:
             - name: FILENAME
               common_name: "{{ ansible_hostname }}"
               ca: self-sign

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_pcsd_certificates: <certificate_properties>

   自己署名された pcsd 証明書と秘密鍵ファイルを /var/lib/pcsd に作成する変数。この例では、pcsd 証明書のファイル名は FILENAME.crt で、鍵ファイルの名前は FILENAME.key です。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with minimum required parameters and no fencing
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with fencing and resources
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_resource_primitives:
             - id: xvm-fencing
               agent: 'stonith:fence_xvm'
               instance_attrs:
                 - attrs:
                     - name: pcmk_host_list
                       value: node1 node2
             - id: simple-resource
               agent: 'ocf:pacemaker:Dummy'
             - id: resource-with-options
               agent: 'ocf:pacemaker:Dummy'
               instance_attrs:
                 - attrs:
                     - name: fake
                       value: fake-value
                     - name: passwd
                       value: passwd-value
               meta_attrs:
                 - attrs:
                     - name: target-role
                       value: Started
                     - name: is-managed
                       value: 'true'
               operations:
                 - action: start
                   attrs:
                     - name: timeout
                       value: '30s'
                 - action: monitor
                   attrs:
                     - name: timeout
                       value: '5'
                     - name: interval
                       value: '1min'
             - id: dummy-1
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-2
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-3
               agent: 'ocf:pacemaker:Dummy'
             - id: simple-clone
               agent: 'ocf:pacemaker:Dummy'
             - id: clone-with-options
               agent: 'ocf:pacemaker:Dummy'
           ha_cluster_resource_groups:
             - id: simple-group
               resource_ids:
                 - dummy-1
                 - dummy-2
               meta_attrs:
                 - attrs:
                     - name: target-role
                       value: Started
                     - name: is-managed
                       value: 'true'
             - id: cloned-group
               resource_ids:
                 - dummy-3
           ha_cluster_resource_clones:
             - resource_id: simple-clone
             - resource_id: clone-with-options
               promotable: yes
               id: custom-clone-id
               meta_attrs:
                 - attrs:
                     - name: clone-max
                       value: '2'
                     - name: clone-node-max
                       value: '1'
             - resource_id: cloned-group
               promotable: yes

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_resource_primitives: <cluster_resources>

   ha_cluster RHEL システムロールによって設定される Pacemaker リソース (フェンシングを含む) のリソース定義のリスト。

   ha_cluster_resource_groups: <resource_groups>

   ha_cluster RHEL システムロールによって設定されるリソースグループ定義のリスト。

   ha_cluster_resource_clones: <resource_clones>

   ha_cluster RHEL システムロールによって設定されるリソースクローン定義のリスト。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with fencing and resource operation defaults
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           # Set a different resource-stickiness value during
           # and outside work hours. This allows resources to
           # automatically move back to their most
           # preferred hosts, but at a time that
           # does not interfere with business activities.
           ha_cluster_resource_defaults:
             meta_attrs:
               - id: core-hours
                 rule: date-spec hours=9-16 weekdays=1-5
                 score: 2
                 attrs:
                   - name: resource-stickiness
                     value: INFINITY
               - id: after-hours
                 score: 1
                 attrs:
                   - name: resource-stickiness
                     value: 0
           # Default the timeout on all 10-second-interval
           # monitor actions on IPaddr2 resources to 8 seconds.
           ha_cluster_resource_operation_defaults:
             meta_attrs:
               - rule: resource ::IPaddr2 and op monitor interval=10s
                 score: INFINITY
                 attrs:
                   - name: timeout
                     value: 8s

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_resource_defaults: <resource_defaults>

   リソースのデフォルトのセットを定義する変数。

   ha_cluster_resource_operation_defaults: <resource_operation_defaults>

   リソース操作のデフォルトのセットを定義する変数。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>
      fence1_password: <fence1_password>
      fence2_password: <fence2_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. Playbook ファイル (例: ~/playbook.yml) を作成します。このサンプル Playbook ファイルは、firewalld および selinux サービスを実行するクラスターを設定します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Configure a cluster that defines fencing levels
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_resource_primitives:
             - id: apc1
               agent: 'stonith:fence_apc_snmp'
               instance_attrs:
                 - attrs:
                     - name: ip
                       value: apc1.example.com
                     - name: username
                       value: user
                     - name: password
                       value: "{{ fence1_password }}"
                     - name: pcmk_host_map
                       value: node1:1;node2:2
             - id: apc2
               agent: 'stonith:fence_apc_snmp'
               instance_attrs:
                 - attrs:
                     - name: ip
                       value: apc2.example.com
                     - name: username
                       value: user
                     - name: password
                       value: "{{ fence2_password }}"
                     - name: pcmk_host_map
                       value: node1:1;node2:2
           # Nodes have redundant power supplies, apc1 and apc2. Cluster must
           # ensure that when attempting to reboot a node, both power
           # supplies # are turned off before either power supply is turned
           # back on.
           ha_cluster_stonith_levels:
             - level: 1
               target: node1
               resource_ids:
                 - apc1
                 - apc2
             - level: 1
               target: node2
               resource_ids:
                 - apc1
                 - apc2

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_resource_primitives: <cluster_resources>

   ha_cluster RHEL システムロールによって設定される Pacemaker リソース (フェンシングを含む) のリソース定義のリスト。

   ha_cluster_stonith_levels: <stonith_levels>

   フェンシングトポロジーとも呼ばれる STONITH レベルを定義する変数。複数のデバイスを使用してノードをフェンスするようにクラスターを設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster with resource constraints
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           # In order to use constraints, we need resources
           # the constraints will apply to.
           ha_cluster_resource_primitives:
             - id: xvm-fencing
               agent: 'stonith:fence_xvm'
               instance_attrs:
                 - attrs:
                     - name: pcmk_host_list
                       value: node1 node2
             - id: dummy-1
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-2
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-3
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-4
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-5
               agent: 'ocf:pacemaker:Dummy'
             - id: dummy-6
               agent: 'ocf:pacemaker:Dummy'
           # location constraints
           ha_cluster_constraints_location:
             # resource ID and node name
             - resource:
                 id: dummy-1
               node: node1
               options:
                 - name: score
                   value: 20
             # resource pattern and node name
             - resource:
                 pattern: dummy-\d+
               node: node1
               options:
                 - name: score
                   value: 10
             # resource ID and rule
             - resource:
                 id: dummy-2
               rule: '#uname eq node2 and date in_range 2022-01-01 to 2022-02-28'
             # resource pattern and rule
             - resource:
                 pattern: dummy-\d+
               rule: node-type eq weekend and date-spec weekdays=6-7
           # colocation constraints
           ha_cluster_constraints_colocation:
             # simple constraint
             - resource_leader:
                 id: dummy-3
               resource_follower:
                 id: dummy-4
               options:
                 - name: score
                   value: -5
             # set constraint
             - resource_sets:
                 - resource_ids:
                     - dummy-1
                     - dummy-2
                 - resource_ids:
                     - dummy-5
                     - dummy-6
                   options:
                     - name: sequential
                       value: "false"
               options:
                 - name: score
                   value: 20
           # order constraints
           ha_cluster_constraints_order:
             # simple constraint
             - resource_first:
                 id: dummy-1
               resource_then:
                 id: dummy-6
               options:
                 - name: symmetrical
                   value: "false"
             # set constraint
             - resource_sets:
                 - resource_ids:
                     - dummy-1
                     - dummy-2
                   options:
                     - name: require-all
                       value: "false"
                     - name: sequential
                       value: "false"
                 - resource_ids:
                     - dummy-3
                 - resource_ids:
                     - dummy-4
                     - dummy-5
                   options:
                     - name: sequential
                       value: "false"
           # ticket constraints
           ha_cluster_constraints_ticket:
             # simple constraint
             - resource:
                 id: dummy-1
               ticket: ticket1
               options:
                 - name: loss-policy
                   value: stop
             # set constraint
             - resource_sets:
                 - resource_ids:
                     - dummy-3
                     - dummy-4
                     - dummy-5
               ticket: ticket2
               options:
                 - name: loss-policy
                   value: fence

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_resource_primitives: <cluster_resources>

   ha_cluster RHEL システムロールによって設定される Pacemaker リソース (フェンシングを含む) のリソース定義のリスト。

   ha_cluster_constraints_location: <location_constraints>

   リソースの場所の制約を定義する変数。

   ha_cluster_constraints_colocation: <colocation_constraints>

   リソースのコロケーションの制約を定義する変数。

   ha_cluster_constraints_order: <order_constraints>

   リソースの順序の制約を定義する変数。

   ha_cluster_constraints_ticket: <ticket_constraints>

   Booth チケットの制約を定義する変数。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create cluster that configures Corosync values
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_transport:
             type: knet
             options:
               - name: ip_version
                 value: ipv4-6
               - name: link_mode
                 value: active
             links:
               -
                 - name: linknumber
                   value: 1
                 - name: link_priority
                   value: 5
               -
                 - name: linknumber
                   value: 0
                 - name: link_priority
                   value: 10
             compression:
               - name: level
                 value: 5
               - name: model
                 value: zlib
             crypto:
               - name: cipher
                 value: none
               - name: hash
                 value: none
           ha_cluster_totem:
             options:
               - name: block_unlisted_ips
                 value: 'yes'
               - name: send_join
                 value: 0
           ha_cluster_quorum:
             options:
               - name: auto_tie_breaker
                 value: 1
               - name: wait_for_all
                 value: 1

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_transport: <transport_method>

   クラスターの転送方法を設定する変数。

   ha_cluster_totem: <totem_options>

   Corosync トーテムオプションを設定する変数。

   ha_cluster_quorum: <quorum_options>

   クラスタークォーラムオプションを設定する変数。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster that uses SBD node fencing
     hosts: node1 node2
     roles:
       - rhel-system-roles.ha_cluster
     vars:
       ha_cluster_cluster_name: my-new-cluster
       ha_cluster_hacluster_password: <password>
       ha_cluster_manage_firewall: true
       ha_cluster_manage_selinux: true
       ha_cluster_sbd_enabled: yes
       ha_cluster_sbd_options:
         - name: delay-start
           value: 'no'
         - name: startmode
           value: always
         - name: timeout-action
           value: 'flush,reboot'
         - name: watchdog-timeout
           value: 30
       # Suggested optimal values for SBD timeouts:
       # watchdog-timeout * 2 = msgwait-timeout (set automatically)
       # msgwait-timeout * 1.2 = stonith-timeout
       ha_cluster_cluster_properties:
         - attrs:
             - name: stonith-timeout
               value: 72
       ha_cluster_resource_primitives:
         - id: fence_sbd
           agent: 'stonith:fence_sbd'
           instance_attrs:
             - attrs:
                 # taken from host_vars
                 - name: devices
                   value: "{{ ha_cluster.sbd_devices | join(',') }}"
                 - name: pcmk_delay_base
                   value: 30

   このサンプル Playbook ファイルは、SBD フェンシングを使用し、SBD Stonith リソースを作成するfirewalld および selinux サービスを実行するクラスターを設定します。

   実稼働用の Playbook ファイルを作成するときは、Encrypting content with Ansible Vault で説明されているように、パスワードを vault で暗号化します。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: node1 node2
     vars_files:
       - vault.yml
     tasks:
       - name: Create a cluster that defines node attributes
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_cluster_name: my-new-cluster
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_node_options:
             - node_name: node1
               attributes:
                 - attrs:
                     - name: attribute1
                       value: value1A
                     - name: attribute2
                       value: value2A
             - node_name: node2
               attributes:
                 - attrs:
                     - name: attribute1
                       value: value1B
                     - name: attribute2
                       value: value2B

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_node_options: <node_settings>

   クラスターノードごとに異なるさまざまな設定を定義する変数。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

   関連情報

   • Pacemaker ルール

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      cluster_password: <cluster_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Create a high availability cluster
     hosts: z1.example.com z2.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Configure active/passive Apache server in a high availability cluster
         ansible.builtin.include_role:
           name: rhel-system-roles.ha_cluster
         vars:
           ha_cluster_hacluster_password: "{{ cluster_password }}"
           ha_cluster_cluster_name: my_cluster
           ha_cluster_manage_firewall: true
           ha_cluster_manage_selinux: true
           ha_cluster_fence_agent_packages:
             - fence-agents-apc-snmp
           ha_cluster_resource_primitives:
             - id: myapc
               agent: stonith:fence_apc_snmp
               instance_attrs:
                 - attrs:
                     - name: ipaddr
                       value: zapc.example.com
                     - name: pcmk_host_map
                       value: z1.example.com:1;z2.example.com:2
                     - name: login
                       value: apc
                     - name: passwd
                       value: apc
             - id: my_lvm
               agent: ocf:heartbeat:LVM-activate
               instance_attrs:
                 - attrs:
                     - name: vgname
                       value: my_vg
                     - name: vg_access_mode
                       value: system_id
             - id: my_fs
               agent: Filesystem
               instance_attrs:
                 - attrs:
                     - name: device
                       value: /dev/my_vg/my_lv
                     - name: directory
                       value: /var/www
                     - name: fstype
                       value: xfs
             - id: VirtualIP
               agent: IPaddr2
               instance_attrs:
                 - attrs:
                     - name: ip
                       value: 198.51.100.3
                     - name: cidr_netmask
                       value: 24
             - id: Website
               agent: apache
               instance_attrs:
                 - attrs:
                     - name: configfile
                       value: /etc/httpd/conf/httpd.conf
                     - name: statusurl
                       value: http://127.0.0.1/server-status
           ha_cluster_resource_groups:
             - id: apachegroup
               resource_ids:
                 - my_lvm
                 - my_fs
                 - VirtualIP
                 - Website

   サンプル Playbook で指定されている設定は次のとおりです。

   ha_cluster_cluster_name: <cluster_name>

   作成するクラスターの名前。

   ha_cluster_hacluster_password: <password>

   hacluster ユーザーのパスワード。hacluster ユーザーには、クラスターへのフルアクセス権が付与されます。

   ha_cluster_manage_firewall: true

   ha_cluster RHEL システムロールがファイアウォールを管理するかどうかを決定する変数。

   ha_cluster_manage_selinux: true

   ha_cluster RHEL システムロールが selinux RHEL システムロールを使用してファイアウォール高可用性サービスのポートを管理するかどうかを決定する変数。

   ha_cluster_fence_agent_packages: <fence_agent_packages>

   インストールするフェンスエージェントパッケージのリスト。

   ha_cluster_resource_primitives: <cluster_resources>

   ha_cluster RHEL システムロールによって設定される Pacemaker リソース (フェンシングを含む) のリソース定義のリスト。

   ha_cluster_resource_groups: <resource_groups>

   ha_cluster RHEL システムロールによって設定されるリソースグループ定義のリスト。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.ha_cluster/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

5. apache リソースエージェントを使用して Apache を管理する場合は systemd が使用されません。このため、Apache で提供される logrotate スクリプトを編集して、systemctl を使用して Apache を再ロードしないようにする必要があります。

   クラスター内の各ノードで、/etc/logrotate.d/httpd ファイルから以下の行を削除します。

   # /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true

   • RHEL 8.6 以降の場合は、削除した行を次の 3 行に置き換え、PID ファイルパスとして /var/run/httpd-website.pid を指定します。ここの website は、Apache リソースの名前になります。この例では、Apache リソース名は Website です。

     /usr/bin/test -f /var/run/httpd-Website.pid >/dev/null 2>/dev/null &&
     /usr/bin/ps -q $(/usr/bin/cat /var/run/httpd-Website.pid) >/dev/null 2>/dev/null &&
     /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd-Website.pid" -k graceful > /dev/null 2>/dev/null || true

   • RHEL 8.5 以前の場合は、削除した行を次の 3 行に置き換えます。

     /usr/bin/test -f /run/httpd.pid >/dev/null 2>/dev/null &&
     /usr/bin/ps -q $(/usr/bin/cat /run/httpd.pid) >/dev/null 2>/dev/null &&
     /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true

検証

1. クラスター内のノードのいずれかから、クラスターのステータスを確認します。4 つのリソースがすべて同じノード (z1.example.com) で実行されていることに注意してください。

   設定したリソースが実行していない場合は、pcs resource debug-start resource コマンドを実行して、リソースの設定をテストします。

   [root@z1 ~]# pcs status
   Cluster name: my_cluster
   Last updated: Wed Jul 31 16:38:51 2013
   Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com
   Stack: corosync
   Current DC: z2.example.com (2) - partition with quorum
   Version: 1.1.10-5.el7-9abe687
   2 Nodes configured
   6 Resources configured
   
   Online: [ z1.example.com z2.example.com ]
   
   Full list of resources:
    myapc  (stonith:fence_apc_snmp):       Started z1.example.com
    Resource Group: apachegroup
        my_lvm     (ocf::heartbeat:LVM-activate):   Started z1.example.com
        my_fs      (ocf::heartbeat:Filesystem):    Started z1.example.com
        VirtualIP  (ocf::heartbeat:IPaddr2):       Started z1.example.com
        Website    (ocf::heartbeat:apache):        Started z1.example.com

2. クラスターが起動したら、IPaddr2 リソースとして定義した IP アドレスをブラウザーで指定して、単純な単語 "Hello" で構成される表示例を確認できます。

   Hello

3. z1.example.com で実行しているリソースグループが z2.example.com ノードにフェイルオーバーするかどうかをテストするには、ノード z1.example.com を standby にすると、ノードがリソースをホストできなくなります。

   [root@z1 ~]# pcs node standby z1.example.com

4. ノード z1 を standby モードにしたら、クラスター内のノードのいずれかからクラスターのステータスを確認します。リソースはすべて z2 で実行しているはずです。

   [root@z1 ~]# pcs status
   Cluster name: my_cluster
   Last updated: Wed Jul 31 17:16:17 2013
   Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com
   Stack: corosync
   Current DC: z2.example.com (2) - partition with quorum
   Version: 1.1.10-5.el7-9abe687
   2 Nodes configured
   6 Resources configured
   
   Node z1.example.com (1): standby
   Online: [ z2.example.com ]
   
   Full list of resources:
   
    myapc  (stonith:fence_apc_snmp):       Started z1.example.com
    Resource Group: apachegroup
        my_lvm     (ocf::heartbeat:LVM-activate):  Started z2.example.com
        my_fs      (ocf::heartbeat:Filesystem):    Started z2.example.com
        VirtualIP  (ocf::heartbeat:IPaddr2):       Started z2.example.com
        Website    (ocf::heartbeat:apache):        Started z2.example.com

   定義している IP アドレスの Web サイトは、中断せず表示されているはずです。

5. スタンバイ モードから z1 を削除するには、以下のコマンドを実行します。

   [root@z1 ~]# pcs node unstandby z1.example.com

   注記

   ノードを スタンバイ モードから削除しても、リソースはそのノードにフェイルオーバーしません。これは、リソースの resource-stickiness 値により異なります。resource-stickiness メタ属性については、現在のノードを優先するようにリソースを設定する を参照してください。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure journald
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure persistent logging
         ansible.builtin.include_role:
           name: rhel-system-roles.journald
         vars:
           journald_persistent: true
           journald_max_disk_size: <size>
           journald_per_user: true
           journald_sync_interval: <interval>

   サンプル Playbook で指定されている設定は次のとおりです。

   journald_persistent: true

   永続的なロギングを有効にします。

   journald_max_disk_size: <size>

   ジャーナルファイルの最大ディスク領域サイズを MB 単位で指定します (例: 2048)。

   journald_per_user: true

   各ユーザーのログデータを個別に保持するように journald を設定します。

   journald_sync_interval: <interval>

   同期の間隔を分単位で設定します (例: 1)。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.journald/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configuring kernel crash dumping
     hosts: managed-node-01.example.com
     tasks:
       - name: Setting the kdump directory.
         ansible.builtin.include_role:
           name: rhel-system-roles.kdump
         vars:
           kdump_target:
             type: raw
             location: /dev/sda1
           kdump_path: /var/crash/vmcore
           kernel_settings_reboot_ok: true

   サンプル Playbook で指定されている設定は次のとおりです。

   kdump_target: <type_and_location>

   vmcore をルートファイルシステム以外の場所に書き込みます。type が raw またはファイルシステムの場合、location は (名前、ラベル、または UUID で) パーティションを参照します。

   kernel_settings_reboot_ok: <true|false>

   デフォルトは false です。true に設定すると、要求された変更を有効にするために管理対象ホストの再起動が必要かどうかをシステムロールが判断し、ホストを再起動します。false に設定すると、再起動が必要であることを示す true 値を持つ変数 kernel_settings_reboot_required がロールによって返されます。この場合、ユーザーが管理対象ノードを手動で再起動する必要があります。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.kdump/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configuring kernel settings
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure hugepages, packet size for loopback device, and limits on simultaneously open files.
         ansible.builtin.include_role:
           name: rhel-system-roles.kernel_settings
         vars:
           kernel_settings_sysctl:
             - name: fs.file-max
               value: 400000
             - name: kernel.threads-max
               value: 65536
           kernel_settings_sysfs:
             - name: /sys/class/net/lo/mtu
               value: 65000
           kernel_settings_transparent_hugepages: madvise
           kernel_settings_reboot_ok: true

   サンプル Playbook で指定されている設定は次のとおりです。

   kernel_settings_sysfs: <list_of_sysctl_settings>

   sysctl 設定とこの設定に割り当てる値の YAML リスト。

   kernel_settings_transparent_hugepages: <value>

   メモリーサブシステムの Transparent Huge Pages (THP) 設定を制御します。THP のサポートを無効にするか (never)、サポートをシステム全体で有効にするか (always)、または MAD_HUGEPAGE リージョン内で有効にする (madvise) ことができます。

   kernel_settings_reboot_ok: <true|false>

   デフォルトは false です。true に設定すると、要求された変更を有効にするために管理対象ホストの再起動が必要かどうかをシステムロールが判断し、ホストを再起動します。false に設定すると、再起動が必要であることを示す true 値を持つ変数 kernel_settings_reboot_required がロールによって返されます。この場合、ユーザーが管理対象ノードを手動で再起動する必要があります。

1. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

2. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configuration and management of GRUB2 boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Update existing boot loader entries
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_settings:
             - kernel:
                 path: /boot/vmlinuz-5.14.0-362.24.1.el9_3.aarch64
               options:
                 - name: quiet
                   state: present
           bootloader_reboot_ok: true

   サンプル Playbook で指定されている設定は次のとおりです。

   kernel

   更新するブートローダーエントリーに関連するカーネルを指定します。

   options

   選択したブートローダーエントリー (カーネル) の更新するカーネルコマンドラインパラメーターを指定します。

   bootloader_reboot_ok: true

   変更を有効にするために再起動が必要であることをロールが検出し、管理対象ノードの再起動を実行します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      pwd: <password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configuration and management of GRUB2 boot loader
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Set the bootloader password
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_password: "{{ pwd }}"
           bootloader_reboot_ok: true

   サンプル Playbook で指定されている設定は次のとおりです。

   bootloader_password: "{{ pwd }}"

   この変数は、ブートパラメーターをパスワードで保護します。

   bootloader_reboot_ok: true

   変更を有効にするために再起動が必要であることをロールが検出し、管理対象ノードの再起動を実行します。

   重要

   ブートローダーのパスワードの変更は、冪等のトランザクションではありません。つまり、同じ Ansible Playbook を再度適用すると、結果が同じではなく、管理対象ノードの状態が変わります。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

1. 管理対象ノードで、GRUB2 ブートメニュー画面中に、編集のために e キーを押します。

   

2. ユーザー名とパスワードの入力を求められます。

   

   Enter username: root

   ブートローダーのユーザー名は常に root であり、Ansible Playbook で指定する必要はありません。

   Enter password: <password>

   ブートローダーのパスワードは、vault.yml ファイルで定義した pwd 変数に対応します。

3. 特定のブートローダーエントリーの設定を表示または編集できます。

   

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configuration and management of GRUB2 boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Update the boot loader timeout
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_timeout: 10

   サンプル Playbook で指定されている設定は次のとおりです。

   bootloader_timeout: 10

   デフォルトのエントリーを起動する前に GRUB2 ブートローダーメニューを表示する時間を制御する整数を入力します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. 管理対象ノードをリモートで再起動します。

   # ansible managed-node-01.example.com -m ansible.builtin.reboot
   managed-node-01.example.com | CHANGED => {
       "changed": true,
       "elapsed": 21,
       "rebooted": true
   }

2. 管理対象ノードで、GRUB2 ブートメニュー画面を確認します。

   

   The highlighted entry will be executed automatically in 10s

   GRUB2 が自動的にデフォルトエントリーを使用するまで、このブートメニューを表示する時間。

   • 別の方法: 管理対象ノードの /boot/grub2/grub.cfg ファイル内の "timeout" 設定をリモートでクエリーすることもできます。

     # ansible managed-node-01.example.com -m ansible.builtin.command -a "grep 'timeout' /boot/grub2/grub.cfg"
     managed-node-01.example.com | CHANGED | rc=0 >>
     if [ x$feature_timeout_style = xy ] ; then
       set timeout_style=menu
       set timeout=10
     # Fallback normal timeout code in case the timeout_style feature is
       set timeout=10
     if [ x$feature_timeout_style = xy ] ; then
         set timeout_style=menu
         set timeout=10
         set orig_timeout_style=${timeout_style}
         set orig_timeout=${timeout}
           # timeout_style=menu + timeout=0 avoids the countdown code keypress check
           set timeout_style=menu
           set timeout=10
           set timeout_style=hidden
           set timeout=10
     if [ x$feature_timeout_style = xy ]; then
       if [ "${menu_show_once_timeout}" ]; then
         set timeout_style=menu
         set timeout=10
         unset menu_show_once_timeout
         save_env menu_show_once_timeout

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configuration and management of GRUB2 boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Gather information about the boot loader configuration
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_gather_facts: true
   
       - name: Display the collected boot loader configuration information
         debug:
           var: bootloader_facts

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Deploy the logging solution
     hosts: managed-node-01.example.com
     tasks:
       - name: Filter logs based on a specific value they contain
         ansible.builtin.include_role:
           name: rhel-system-roles.logging
         vars:
           logging_inputs:
             - name: files_input
               type: basics
           logging_outputs:
             - name: files_output0
               type: files
               property: msg
               property_op: contains
               property_value: error
               path: /var/log/errors.log
             - name: files_output1
               type: files
               property: msg
               property_op: "!contains"
               property_value: error
               path: /var/log/others.log
           logging_flows:
             - name: flow0
               inputs: [files_input]
               outputs: [files_output0, files_output1]

   サンプル Playbook で指定されている設定は次のとおりです。

   logging_inputs

   ロギングの入力ディクショナリーのリストを定義します。type: basics オプションを指定すると、systemd ジャーナルまたは Unix ソケットからの入力が対象になります。

   logging_outputs

   ロギングの出力ディクショナリーのリストを定義します。type: files オプションにより、ローカルファイル (通常は /var/log/ ディレクトリー内) にログを保存できます。property: msg、property: contains、および property_value: error オプションを指定すると、error 文字列を含むすべてのログが /var/log/errors.log ファイルに保存されます。property: msg、property: !contains、および property_value: error オプションを指定すると、他のすべてのログが /var/log/others.log ファイルに保存されます。error 値は、フィルタリングする必要がある文字列に置き換えることができます。

   logging_flows

   ロギングのフローディクショナリーのリストを定義して、logging_inputs と logging_outputs の関係を指定します。inputs: [files_input] オプションは、ログの処理を開始する入力のリストを指定します。outputs: [files_output0, files_output1] オプションは、ログ送信先の出力のリストを指定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. 管理対象ノードで、/etc/rsyslog.conf ファイルの構文をテストします。

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run...
   rsyslogd: End of config validation run. Bye.

2. 管理対象ノードで、システムが error 文字列を含むメッセージをログに送信することを確認します。

   1. テストメッセージを送信します。

      # logger error

   2. 以下のように /var/log/errors.log ログを表示します。

      # cat /var/log/errors.log
      Aug  5 13:48:31 hostname root[6778]: error

      hostname はクライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Deploy the logging solution
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure the server to receive remote input
         ansible.builtin.include_role:
           name: rhel-system-roles.logging
         vars:
           logging_inputs:
             - name: remote_udp_input
               type: remote
               udp_ports: [ 601 ]
             - name: remote_tcp_input
               type: remote
               tcp_ports: [ 601 ]
           logging_outputs:
             - name: remote_files_output
               type: remote_files
           logging_flows:
             - name: flow_0
               inputs: [remote_udp_input, remote_tcp_input]
               outputs: [remote_files_output]
   
   - name: Deploy the logging solution
     hosts: managed-node-02.example.com
     tasks:
       - name: Configure the server to output the logs to local files in directories named by remote host names
         ansible.builtin.include_role:
           name: rhel-system-roles.logging
         vars:
           logging_inputs:
             - name: basic_input
               type: basics
           logging_outputs:
             - name: forward_output0
               type: forwards
               severity: info
               target: <host1.example.com>
               udp_port: 601
             - name: forward_output1
               type: forwards
               facility: mail
               target: <host1.example.com>
               tcp_port: 601
           logging_flows:
             - name: flows0
               inputs: [basic_input]
               outputs: [forward_output0, forward_output1]
   
   [basic_input]
   [forward_output0, forward_output1]

   サンプル Playbook の最初のプレイで指定されている設定は次のとおりです。

   logging_inputs

   ロギングの入力ディクショナリーのリストを定義します。type: remote オプションを指定すると、ネットワークを介した他のロギングシステムからのリモート入力が対象になります。udp_ports: [ 601 ] オプションは、監視する UDP ポート番号のリストを定義します。tcp_ports: [ 601 ] オプションは、監視する TCP ポート番号のリストを定義します。udp_ports と tcp_ports の両方が設定されている場合、udp_ports が使用され、tcp_ports は削除されます。

   logging_outputs

   ロギングの出力ディクショナリーのリストを定義します。type: remote_files オプションを指定すると、ログの送信元であるリモートホストとプログラム名ごとに、出力がローカルファイルに保存されます。

   logging_flows

   ロギングのフローディクショナリーのリストを定義して、logging_inputs と logging_outputs の関係を指定します。inputs: [remote_udp_input、remote_tcp_input] オプションは、ログの処理を開始する入力のリストを指定します。outputs: [remote_files_output] オプションは、ログ送信先の出力のリストを指定します。

   サンプル Playbook の 2 番目のプレイで指定されている設定は次のとおりです。

   logging_inputs

   ロギングの入力ディクショナリーのリストを定義します。type: basics オプションを指定すると、systemd ジャーナルまたは Unix ソケットからの入力が対象になります。

   logging_outputs

   ロギングの出力ディクショナリーのリストを定義します。type: forwards オプションにより、ネットワーク経由でリモートログサーバーにログを送信できます。severity: info オプションは、重大度が情報のログメッセージを示します。facility: mail オプションは、ログメッセージを生成するシステムプログラムの種類を示します。target: <host1.example.com> オプションは、リモートログサーバーのホスト名を指定します。udp_port: 601/tcp_port: 601 オプションは、リモートログサーバーがリッスンする UDP/TCP ポートを定義します。

   logging_flows

   ロギングのフローディクショナリーのリストを定義して、logging_inputs と logging_outputs の関係を指定します。inputs: [basic_input] オプションは、ログの処理を開始する入力のリストを指定します。outputs: [forward_output0, forward_output1] オプションは、ログ送信先の出力のリストを指定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.logging/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. クライアントとサーバーシステムの両方で、/etc/rsyslog.conf ファイルの構文をテストします。

   # rsyslogd -N 1
   rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

2. クライアントシステムがサーバーにメッセージを送信することを確認します。

   1. クライアントシステムで、テストメッセージを送信します。

      # logger test

   2. サーバーシステムで、/var/log/<host2.example.com>/messages ログを表示します。次に例を示します。

      # cat /var/log/<host2.example.com>/messages
      Aug  5 13:48:31 <host2.example.com> root[6778]: test

      <host2.example.com> は、クライアントシステムのホスト名に置き換えます。ログには、logger コマンドを入力したユーザーのユーザー名 (この場合は root) が含まれていることに注意してください。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Monitoring performance metrics
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure Performance Co-Pilot
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_retention_days: 14
           metrics_manage_firewall: true
           metrics_manage_selinux: true

   サンプル Playbook で指定されている設定は次のとおりです。

   metrics_retention_days: <number>

   pmlogger_daily systemd タイマーが古い PCP アーカイブを削除するまでの日数を設定します。

   metrics_manage_firewall: <true|false>

   firewalld サービスで必要なポートをロールによって開くかどうかを定義します。管理対象ノード上の PCP にリモートでアクセスする場合は、この変数を true に設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      metrics_usr: <username>
      metrics_pwd: <password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Monitoring performance metrics
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure Performance Co-Pilot
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_retention_days: 14
           metrics_manage_firewall: true
           metrics_manage_selinux: true
   	metrics_username: "{{ metrics_usr }}"
           metrics_password: "{{ metrics_pwd }}"

   サンプル Playbook で指定されている設定は次のとおりです。

   metrics_retention_days: <number>

   pmlogger_daily systemd タイマーが古い PCP アーカイブを削除するまでの日数を設定します。

   metrics_manage_firewall: <true|false>

   firewalld サービスで必要なポートをロールによって開くかどうかを定義します。管理対象ノード上の PCP にリモートでアクセスする場合は、この変数を true に設定します。

   metrics_username: <username>

   このロールは、管理対象ノード上でこのユーザーをローカルに作成し、Simple Authentication and Security Layer (SASL) データベース /etc/pcp/passwd.db に認証情報を追加し、PCP に認証を設定します。さらに、Playbook で metrics_from_bpftrace: true を設定すると、PCP がこのアカウントを使用して bpftrace スクリプトを登録します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      grafana_admin_pwd: <password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Monitoring performance metrics
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Set up Grafana to monitor multiple hosts
         ansible.builtin.include_role:
           name: rhel-system-roles.metrics
         vars:
           metrics_graph_service: true
           metrics_query_service: true
           metrics_monitored_hosts:
             - <pcp_host_1.example.com>
             - <pcp_host_2.example.com>
           metrics_manage_firewall: true
           metrics_manage_selinux: true
   
       - name: Set Grafana admin password
         ansible.builtin.shell:
           cmd: grafana-cli admin reset-admin-password "{{ grafana_admin_pwd }}"

   サンプル Playbook で指定されている設定は次のとおりです。

   metrics_graph_service: true

   Grafana と PCP プラグインをインストールします。さらに、PCP Vector、PCP Redis、および PCP bpftrace データソースが Grafana に追加されます。

   metrics_query_service: <true|false>

   ロールによって、一元的なメトリクス記録用に Redis をインストールして設定する必要があるかどうかを定義します。有効にすると、PCP クライアントから収集されたデータが Redis に保存され、ライブデータだけでなく履歴データも表示できるようになります。

   metrics_monitored_hosts: <list_of_hosts>

   監視するホストのリストを定義します。定義すると、Grafana で、これらのホストのデータに加えて、Grafana を実行しているホストのデータを表示できます。

   metrics_manage_firewall: <true|false>

   firewalld サービスで必要なポートをロールによって開くかどうかを定義します。この変数を true に設定すると、たとえば Grafana にリモートでアクセスできるようになります。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.metrics/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

1. ブラウザーで http://<grafana_server_IP_or_hostname>:3000 を開き、上記手順で設定したパスワードを使用して admin ユーザーとしてログインします。

2. 監視データを表示します。

   • ライブデータを表示するには、次の手順を実行します。

     1. 左側のナビゲーションバーにある Performance Co-Pilot アイコンをクリックし、PCP Vector Checklist を選択します。
     2. デフォルトでは、Grafana を実行しているホストからのメトリクスがグラフに表示されます。別のホストに切り替えるには、hostspec フィールドにホスト名を入力して Enter キー を押します。
   • Redis データベースに保存されている履歴データを表示するには、PCP Redis データソースを使用してパネルを作成 します。そのためには、Playbook で metrics_query_service: true を設定する必要があります。

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      sa_pwd: <sa_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with an existing private key and certificate
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd  }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_tls_enable: true
           mssql_tls_cert: sql_crt.pem
           mssql_tls_private_key: sql_cert.key
           mssql_tls_version: 1.2
           mssql_tls_force: true

   サンプル Playbook で指定されている設定は次のとおりです。

   mssql_tls_enable: true

   TLS 暗号化を有効にします。この設定を有効にする場合は、mssql_tls_cert と mssql_tls_private_key も定義する必要があります。

   mssql_tls_cert: <path>

   コントロールノードに保存されている TLS 証明書へのパスを設定します。ロールは、このファイルを管理対象ノードの /etc/pki/tls/certs/ ディレクトリーにコピーします。

   mssql_tls_private_key: <path>

   コントロールノード上の TLS 秘密鍵へのパスを設定します。ロールは、このファイルを管理対象ノードの /etc/pki/tls/private/ ディレクトリーにコピーします。

   mssql_tls_force: true

   宛先ディレクトリー内の TLS 証明書および秘密鍵を置き換えます (存在する場合)。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/microsoft.sql-server/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      sa_pwd: <sa_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with certificates issued by Red Hat IdM
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd  }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_tls_enable: true
           mssql_tls_certificates:
             - name: sql_cert
               dns: server.example.com
               ca: ipa

   サンプル Playbook で指定されている設定は次のとおりです。

   mssql_tls_enable: true

   TLS 暗号化を有効にします。この設定を有効にする場合は、mssql_tls_certificates も定義する必要があります。

   mssql_tls_certificates

   certificate ロールの設定を含む YAML ディクショナリーのリスト。

   name: <file_name>

   証明書と秘密鍵のベース名を定義します。certificate ロールは、証明書を /etc/pki/tls/certs/<file_name>.crt に保存し、秘密鍵を /etc/pki/tls/private/<file_name>.key ファイルに保存します。

   dns: <hostname_or_list_of_hostnames>

   発行された証明書のサブジェクト代替名 (SAN) フィールドに含まれるホスト名を設定します。ワイルドカード (*) を使用することも、YAML リスト形式で複数の名前を指定することもできます。

   ca: <ca_type>

   certificate ロールが証明書を要求する方法を定義します。ホストが IdM ドメインに登録されている場合はこの変数を ipa に設定し、自己署名証明書を要求する場合は self-sign に設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/microsoft.sql-server/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      sa_pwd: <sa_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 既存の Playbook ファイル (例: ~/playbook.yml) を編集し、ストレージおよびログ関連の変数を追加します。

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with custom storage paths
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd  }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_datadir: /var/lib/mssql/
           mssql_datadir_mode: '0700'
           mssql_logdir: /var/log/mssql/
           mssql_logdir_mode: '0700'

   サンプル Playbook で指定されている設定は次のとおりです。

   mssql_datadir_mode および mssql_logdir_mode

   権限モードを設定します。ロールが値を 8 進数ではなく文字列として解析するように、値を一重引用符で囲んで指定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/microsoft.sql-server/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

検証

1. データディレクトリーのモードを表示します。

   $ ansible managed-node-01.example.com -m command -a 'ls -ld /var/lib/mssql/'
   drwx------. 12 mssql mssql 4096 Jul  3 13:53 /var/lib/mssql/

2. ログディレクトリーのモードを表示します。

   $ ansible managed-node-01.example.com -m command -a 'ls -ld /var/log/mssql/'
   drwx------. 12 mssql mssql 4096 Jul  3 13:53 /var/log/mssql/

手順

1. 機密性の高い変数を暗号化されたファイルに保存します。

   1. vault を作成します。

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. ansible-vault create コマンドでエディターが開いたら、機密データを <key>: <value> 形式で入力します。

      sa_pwd: <sa_password>
      sql_pwd: <SQL_AD_password>
      ad_admin_pwd: <AD_admin_password>

   3. 変更を保存して、エディターを閉じます。Ansible は vault 内のデータを暗号化します。

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Installing and configuring Microsoft SQL Server
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: SQL Server with AD authentication
         ansible.builtin.include_role:
           name: microsoft.sql.server
         vars:
           mssql_accept_microsoft_odbc_driver_17_for_sql_server_eula: true
           mssql_accept_microsoft_cli_utilities_for_sql_server_eula: true
           mssql_accept_microsoft_sql_server_standard_eula: true
   
           mssql_version: 2022
           mssql_password: "{{ sa_pwd }}"
           mssql_edition: Developer
           mssql_tcp_port: 1433
           mssql_manage_firewall: true
   
           mssql_ad_configure: true
           mssql_ad_join: true
           mssql_ad_sql_user: sqluser
           mssql_ad_sql_password: "{{ sql_pwd }}"
           ad_integration_realm: ad.example.com
           ad_integration_user: Administrator
           ad_integration_password: "{{ ad_admin_pwd }}"

   サンプル Playbook で指定されている設定は次のとおりです。

   mssql_ad_configure: true

   AD に対する認証を有効にします。

   mssql_ad_join: true

   ad_integration RHEL システムロールを使用して、管理対象ノードを AD に参加させます。ロールは、ad_integration_realm、ad_integration_user、および ad_integration_password 変数の設定を使用してドメインに参加します。

   mssql_ad_sql_user: <username>

   管理目的でロールが AD および SQL Server に作成する AD アカウントの名前を設定します。

   ad_integration_user: <AD_user>

   マシンをドメインに参加させる権限と、mssql_ad_sql_user で指定された AD ユーザーを作成する権限を持つ AD ユーザーの名前を設定します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/microsoft.sql-server/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

5. AD ドメインで、Playbook で指定した AD SQL ユーザーに対して 128 ビットおよび 256 ビットの Kerberos 認証を有効にします。以下のオプションのいずれかを使用します。

   • Active Directory Users and Computers アプリケーションで、以下を実行します。

     1. ad.example.com > Users > sqluser > Accounts に移動します。
     2. Account options リストで、This account supports Kerberos AES 128 bit encryption と This account supports Kerberos AES 256 bit encryption を選択します。
     3. Apply をクリックします。

   • 管理者モードの PowerShell で、次のように入力します。

     C:\> Set-ADUser -Identity sqluser -KerberosEncryptionType AES128,AES256

6. SQL Server に対して認証できる AD ユーザーを許可します。SQL Server で、次の手順を実行します。

   1. Administrator ユーザーの Kerberos チケットを取得します。

      $ kinit Administrator@ad.example.com

   2. AD ユーザーを許可します。

      $ /opt/mssql-tools/bin/sqlcmd -S. -Q 'CREATE LOGIN [AD\<AD_user>] FROM WINDOWS;'

      SQL Server へのアクセスを許可するすべての AD ユーザーに対してこの手順を繰り返します。

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Deploy a Tang server
   - hosts: tang.server.example.com
   - tasks:
     - name: Install and configure periodic key rotation
       ansible.builtin.include_role:
           name: rhel-system-roles.nbde_server
       vars:
         nbde_server_rotate_keys: yes
         nbde_server_manage_firewall: true
         nbde_server_manage_selinux: true

   このサンプル Playbook により、Tang サーバーのデプロイと鍵のローテーションが実行されます。

   サンプル Playbook で指定されている設定は次のとおりです。

   nbde_server_manage_firewall: true

   firewall システムロールを使用して、nbde_server ロールで使用されるポートを管理します。

   nbde_server_manage_selinux: true

   selinux システムロールを使用して、nbde_server ロールで使用されるポートを管理します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.nbde_server/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure clients for unlocking of encrypted volumes by Tang servers
     hosts: managed-node-01.example.com
     tasks:
       - name: Create NBDE client bindings
         ansible.builtin.include_role:
           name: rhel-system-roles.nbde_client
         vars:
           nbde_client_bindings:
             - device: /dev/rhel/root
               encryption_key_src: /etc/luks/keyfile
               nbde_client_early_boot: true
               state: present
               servers:
                 - http://server1.example.com
                 - http://server2.example.com
             - device: /dev/rhel/swap
               encryption_key_src: /etc/luks/keyfile
               servers:
                 - http://server1.example.com
                 - http://server2.example.com

   このサンプル Playbook は、2 台の Tang サーバーのうち少なくとも 1 台が利用可能な場合に、LUKS で暗号化した 2 つのボリュームを自動的にアンロックするように Clevis クライアントを設定します。

   サンプル Playbook で指定されている設定は次のとおりです。

   state: present

   state の値は、Playbook を実行した後の設定を示します。新しいバインディングを作成するか、既存のバインディングを更新する場合は、present を使用します。clevis luks bind とは異なり、state: present を使用してデバイススロットにある既存のバインディングを上書きすることもできます。absent に設定すると、指定したバインディングが削除されます。

   nbde_client_early_boot: true

   nbde_client ロールは、デフォルトで、起動初期段階で Tang ピン用のネットワークを利用可能にします。この機能を無効にする必要がある場合は、Playbook に nbde_client_early_boot: false 変数を追加します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.nbde_client/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. NBDE クライアントで、Tang サーバーによって自動的にロック解除される暗号化ボリュームの LUKS ピンに、対応する情報が含まれていることを確認します。

   # ansible managed-node-01.example.com -m command -a 'clevis luks list -d /dev/rhel/root'
   1: tang '{"url":"<http://server1.example.com/>"}'
   2: tang '{"url":"<http://server2.example.com/>"}'

2. nbde_client_early_boot: false 変数を使用しない場合は、起動初期にバインディングが使用できることを確認します。次に例を示します。

   # ansible managed-node-01.example.com -m command -a 'lsinitrd | grep clevis-luks'
   lrwxrwxrwx   1 root     root           48 Jan  4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/clevis-luks-askpass.path
   …

手順

1. ホストのネットワーク設定を含むファイル (例: static-ip-settings-clients.yml) を作成し、ホストに動的に割り当てる値を追加します。

   clients:
     managed-node-01.example.com:
       ip_v4: 192.0.2.1
       gateway_v4: 192.0.2.254
       netmask_v4: 255.255.255.0
       interface: enp1s0
     managed-node-02.example.com:
       ip_v4: 192.0.2.2
       gateway_v4: 192.0.2.254
       netmask_v4: 255.255.255.0
       interface: enp1s0

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   - name: Configure clients for unlocking of encrypted volumes by Tang servers
     hosts: managed-node-01.example.com,managed-node-02.example.com
     vars_files:
       - ~/static-ip-settings-clients.yml
     tasks:
       - name: Create NBDE client bindings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           nbde_client_bindings:
             - device: /dev/rhel/root
               encryption_key_src: /etc/luks/keyfile
               servers:
                 - http://server1.example.com
                 - http://server2.example.com
             - device: /dev/rhel/swap
               encryption_key_src: /etc/luks/keyfile
               servers:
                 - http://server1.example.com
                 - http://server2.example.com
   
       - name: Configure a Clevis client with static IP address during early boot
         ansible.builtin.include_role:
           name: rhel-system-roles.bootloader
         vars:
           bootloader_settings:
             - kernel: ALL
               options:
                 - name: ip
                   value: "{{ clients[inventory_hostname]['ip_v4'] }}::{{ clients[inventory_hostname]['gateway_v4'] }}:{{ clients[inventory_hostname]['netmask_v4'] }}::{{ clients[inventory_hostname]['interface'] }}:none"

   この Playbook は、~/static-ip-settings-clients.yml ファイルにリストされている各ホストの特定の値を動的に読み取ります。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. ~/inventory ファイルを編集し、ホストエントリーにホスト固有の設定を追加します。

   managed-node-01.example.com interface=enp1s0 ip_v4=192.0.2.1/24 ip_v6=2001:db8:1::1/64 gateway_v4=192.0.2.254 gateway_v6=2001:db8:1::fffe
   
   managed-node-02.example.com interface=enp1s0 ip_v4=192.0.2.2/24 ip_v6=2001:db8:1::2/64 gateway_v4=192.0.2.254 gateway_v6=2001:db8:1::fffe

2. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com,managed-node-02.example.com
     tasks:
       - name: Ethernet connection profile with static IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: "{{ interface }}"
               interface_name: "{{ interface }}"
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - "{{ ip_v4 }}"
                   - "{{ ip_v6 }}"
                 gateway4: "{{ gateway_v4 }}"
                 gateway6: "{{ gateway_v6 }}"
                 dns:
                   - 192.0.2.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               state: up

   この Playbook は、インベントリーファイルから各ホストの特定の値を動的に読み取り、すべてのホストで同じ設定に対して Playbook 内の静的な値を使用します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

3. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

4. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with static IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: example
               match:
                 path:
                   - pci-0000:00:0[1-3].0
                   - &!pci-0000:00:02.0
               type: ethernet
               autoconnect: yes
               ip:
                 address:
                   - 192.0.2.1/24
                   - 2001:db8:1::1/64
                 gateway4: 192.0.2.254
                 gateway6: 2001:db8:1::fffe
                 dns:
                   - 192.0.2.200
                   - 2001:db8:1::ffbb
                 dns_search:
                   - example.com
               state: up

   サンプル Playbook で指定されている設定は次のとおりです。

   match

   設定を適用するために満たす必要がある条件を定義します。この変数は path オプションでのみ使用できます。

   path

   デバイスの永続パスを定義します。固定パスまたは式の形式で設定できます。値には修飾子とワイルドカードを含めることができます。この例では、PCI ID 0000:00:0[1-3].0 に一致するデバイスには設定を適用しますが、0000:00:02.0 に一致するデバイスには適用しません。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with dynamic IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: enp1s0
               interface_name: enp1s0
               type: ethernet
               autoconnect: yes
               ip:
                 dhcp4: yes
                 auto6: yes
               state: up

   サンプル Playbook で指定されている設定は次のとおりです。

   dhcp4: yes

   DHCP、PPP、または同様のサービスからの自動 IPv4 アドレス割り当てを有効にします。

   auto6: yes

   IPv6 自動設定を有効にします。デフォルトでは、NetworkManager はルーター広告を使用します。ルーターが managed フラグを通知すると、NetworkManager は DHCPv6 サーバーに IPv6 アドレスと接頭辞を要求します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Ethernet connection profile with dynamic IP address settings
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             - name: example
               match:
                 path:
                   - pci-0000:00:0[1-3].0
                   - &!pci-0000:00:02.0
               type: ethernet
               autoconnect: yes
               ip:
                 dhcp4: yes
                 auto6: yes
               state: up

   サンプル Playbook で指定されている設定は次のとおりです。

   match: path

   設定を適用するために満たす必要がある条件を定義します。この変数は path オプションでのみ使用できます。

   path: <path_and_expressions>

   デバイスの永続パスを定義します。固定パスまたは式の形式で設定できます。値には修飾子とワイルドカードを含めることができます。この例では、PCI ID 0000:00:0[1-3].0 に一致するデバイスには設定を適用しますが、0000:00:02.0 に一致するデバイスには適用しません。

   dhcp4: yes

   DHCP、PPP、または同様のサービスからの自動 IPv4 アドレス割り当てを有効にします。

   auto6: yes

   IPv6 自動設定を有効にします。デフォルトでは、NetworkManager はルーター広告を使用します。ルーターが managed フラグを通知すると、NetworkManager は DHCPv6 サーバーに IPv6 アドレスと接頭辞を要求します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: VLAN connection profile with Ethernet port
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             # Ethernet profile
             - name: enp1s0
               type: ethernet
               interface_name: enp1s0
               autoconnect: yes
               state: up
               ip:
                 dhcp4: no
                 auto6: no
   
             # VLAN profile
             - name: enp1s0.10
               type: vlan
               vlan:
                 id: 10
               ip:
                 dhcp4: yes
                 auto6: yes
               parent: enp1s0
               state: up

   サンプル Playbook で指定されている設定は次のとおりです。

   type: <profile_type>

   作成するプロファイルのタイプを設定します。このサンプル Playbook では、2 つの接続プロファイルを作成します。1 つは親イーサネットデバイス用、もう 1 つは VLAN デバイス用です。

   dhcp4: <value>

   yes に設定すると、DHCP、PPP、または同様のサービスからの自動 IPv4 アドレス割り当てが有効になります。親デバイスの IP アドレス設定を無効にします。

   auto6: <value>

   yes に設定すると、IPv6 自動設定が有効になります。この場合、デフォルトで NetworkManager がルーター広告を使用します。ルーターが managed フラグを通知すると、NetworkManager は DHCPv6 サーバーから IPv6 アドレスと接頭辞を要求します。親デバイスの IP アドレス設定を無効にします。

   parent: <parent_device>

   VLAN 接続プロファイルの親デバイスを設定します。この例では、親はイーサネットインターフェイスです。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure the network
     hosts: managed-node-01.example.com
     tasks:
       - name: Bridge connection profile with two Ethernet ports
         ansible.builtin.include_role:
           name: rhel-system-roles.network
         vars:
           network_connections:
             # Bridge profile
             - name: bridge0
               type: bridge
               interface_name: bridge0
               ip:
                 dhcp4: yes
                 auto6: yes
               state: up
   
             # Port profile for the 1st Ethernet device
             - name: bridge0-port1
               interface_name: enp7s0
               type: ethernet
               controller: bridge0
               port_type: bridge
               state: up
   
             # Port profile for the 2nd Ethernet device
             - name: bridge0-port2
               interface_name: enp8s0
               type: ethernet
               controller: bridge0
               port_type: bridge
               state: up

   サンプル Playbook で指定されている設定は次のとおりです。

   type: <profile_type>

   作成するプロファイルのタイプを設定します。このサンプル Playbook では、3 つの接続プロファイルを作成します。1 つはブリッジ用、2 つはイーサネットデバイス用です。

   dhcp4: yes

   DHCP、PPP、または同様のサービスからの自動 IPv4 アドレス割り当てを有効にします。

   auto6: yes

   IPv6 自動設定を有効にします。デフォルトでは、NetworkManager はルーター広告を使用します。ルーターが managed フラグを通知すると、NetworkManager は DHCPv6 サーバーに IPv6 アドレスと接頭辞を要求します。

   Playbook で使用されるすべての変数の詳細は、コントロールノードの /usr/share/ansible/roles/rhel-system-roles.network/README.md ファイルを参照してください。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. 特定のブリッジのポートであるイーサネットデバイスのリンクステータスを表示します。

   # ansible managed-node-01.example.com -m command -a 'ip link show master bridge0'
   managed-node-01.example.com | CHANGED | rc=0 >>
   3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP mode DEFAULT group default qlen 1000
       link/ether 52:54:00:62:61:0e brd ff:ff:ff:ff:ff:ff
   4: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP mode DEFAULT group default qlen 1000
       link/ether 52:54:00:9e:f1:ce brd ff:ff:ff:ff:ff:ff

2. ブリッジデバイスのポートであるイーサネットデバイスのステータスを表示します。

   # ansible managed-node-01.example.com -m command -a 'bridge link show'
   managed-node-01.example.com | CHANGED | rc=0 >>
   3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master bridge0 state forwarding priority 32 cost 100
   4: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master bridge0 state listening priority 32 cost 100