はじめに
この実験 (Lab) では、Ansible のロール (Roles) とコレクション (Collections) の強力で再利用可能な機能を活用して、Red Hat Enterprise Linux (RHEL) Web サーバーの設定を自動化する方法を学びます。特定の構成をデプロイするためのカスタムロールを作成し、Git リポジトリからの外部ロールを依存関係として統合し、SELinux のようなシステムサービスを管理するために事前に構築された RHEL System Role を Ansible Collection から利用することで、包括的な自動化ワークフローを構築します。
プロセスは、ansible-galaxy init を使用して標準化されたロール構造を作成することから始まります。次に、requirements.yml ファイルを使用して Git リポジトリからのロール依存関係を定義およびインストールします。RHEL System Role を統合した後、カスタム、Git ベース、およびコレクション ベースの 3 種類のロールすべてを単一のマスタープレイブックに組み立てます。最後に、プレイブックを実行し、Apache Web サーバーと SELinux 設定がターゲット RHEL サーバーに正しく適用されたことを確認し、完全でモジュール化された自動化ソリューションを実証します。
ansible-galaxy init を使用してカスタム Ansible ロールを作成する
このステップでは、ansible-galaxy init コマンドを使用して新しい Ansible ロールの標準化されたディレクトリ構造を作成することから始めます。Ansible ロールは、再利用可能で整理された自動化コンテンツを構築するための基本的な概念です。ロールを使用すると、タスク、ハンドラー、変数、その他のコンポーネントを自己完結型のポータブルなユニットにパッケージ化できます。標準構造を使用することは、自動化の理解、管理、共有を容易にするためのベストプラクティスです。
まず、正しい作業ディレクトリにいることを確認してください。この実験 (Lab) のすべての作業は、~/project ディレクトリ内で行われます。
cd ~/project
ロールを作成する前に、Ansible コマンドラインツールがインストールされていることを確認する必要があります。ansible-core パッケージは、ansible-galaxy を含む必須ツールを提供します。
dnf パッケージマネージャーを使用して ansible-core をインストールします。-y フラグは、確認プロンプトに自動的に「yes」と応答します。
sudo dnf install -y ansible-core
パッケージがインストールされ、依存関係が解決されていることを示す出力が表示されるはずです。
...
Installed:
ansible-core-2.16.x-1.el9.x86_64
...
Complete!
すべてのプロジェクトロールを専用の roles ディレクトリ内に整理するのが一般的です。このディレクトリを今すぐ作成します。
mkdir roles
次に、新しく作成された roles ディレクトリに移動します。ここで新しいカスタムロールを初期化します。
cd roles
ここで ansible-galaxy init コマンドを使用して、apache.developer_configs という名前のロールのスケルトンを作成します。このコマンドは、標準的なディレクトリとファイルのセットを自動的に生成し、ロール開発のクリーンな開始点を提供します。
ansible-galaxy init apache.developer_configs
コマンドを実行すると、確認メッセージが表示されます。
- Role apache.developer_configs was created successfully
作成されたばかりの構造を確認するには、ls -R コマンドを使用できます。このコマンドは、ディレクトリとそのすべてのサブディレクトリの内容を再帰的に一覧表示します。
ls -R apache.developer_configs
出力は、Ansible ロールの標準的なディレクトリ構造を示しています。
apache.developer_configs:
defaults files handlers meta README.md tasks templates tests vars
apache.developer_configs/defaults:
main.yml
apache.developer_configs/files:
apache.developer_configs/handlers:
main.yml
apache.developer_configs/meta:
main.yml
apache.developer_configs/tasks:
main.yml
apache.developer_configs/templates:
apache.developer_configs/tests:
inventory test.yml
apache.developer_configs/vars:
main.yml
最も重要なディレクトリの簡単な概要を以下に示します。
tasks: ロールによって実行されるタスクのメインリストが含まれています。handlers: ハンドラーが含まれています。ハンドラーは、別のタスクによって通知された場合にのみ実行されるタスクです。vars: ロールの変数を含んでいます。templates: Jinja2 テンプレートエンジンを使用するファイルテンプレートを含んでいます。meta: 他のロールへの依存関係を含む、ロールのメタデータが含まれています。
これで、カスタム Ansible ロールの基本的な構造を正常に作成しました。次のステップでは、これらのディレクトリにコンテンツを投入して Web サーバーを構成します。
requirements.yml を使用して Git リポジトリからロールの依存関係をインストールする
このステップでは、Git リポジトリのような外部ソースからロールの依存関係を管理する方法を学びます。これは、コミュニティや他のチームによって開発されたロールを再利用する、より大規模な Ansible プロジェクトで一般的なプラクティスです。Ansible は、通常 requirements.yml と呼ばれるファイルを使用して、インストールするロールのリストを定義します。
カスタムロール apache.developer_configs は、Web サーバーがインストールされ実行されていることを保証するために、基盤となる Apache ロールに依存します。この依存関係を定義し、インストールします。
まず、メインのプロジェクトディレクトリにいることを確認してください。前のステップからまだ roles サブディレクトリにいる場合は、~/project に戻ってください。
cd ~/project
次に、roles ディレクトリ内に requirements.yml ファイルを作成します。このファイルには、プロジェクトが必要とするすべての外部ロールがリストされます。nano エディタを使用してファイルを作成および編集します。
nano roles/requirements.yml
ファイルに以下のコンテンツを追加します。このエントリは、ansible-galaxy に対して、公開 Git リポジトリから Apache ロールの特定のバージョンをダウンロードし、ローカルで infra.apache という名前を付けるように指示します。
- name: infra.apache
src: https://github.com/geerlingguy/ansible-role-apache.git
scm: git
version: 3.2.0
この定義の内訳を見てみましょう。
name: これはロールのローカル名です。ソースリポジトリの名前は異なりますが、infra.apacheという名前のディレクトリにインストールされます。src: Git リポジトリのソース URL です。scm: ソース管理ツールを指定します。この場合はgitです。version: 使用する特定の Git ブランチ、タグ、またはコミットハッシュです。バージョンの固定は、自動化の安定性と予測可能性を確保するために不可欠です。
ファイルを保存し、Ctrl+X、Y、Enter の順に押して nano を終了します。
requirements.yml ファイルが配置されたら、ansible-galaxy install コマンドを使用してロールをダウンロードおよびインストールできます。
-rフラグは要件ファイルを指します。-pフラグは、ロールをインストールするパスを指定します。
ansible-galaxy install -r roles/requirements.yml -p roles
ダウンロードとインストールのプロセスを確認する出力が表示されます。
Starting galaxy role install process
- downloading role 'ansible-role-apache', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-apache/archive/3.2.0.tar.gz
- extracting infra.apache to /home/labex/project/roles/infra.apache
- infra.apache (3.2.0) was installed successfully
ロールが正しくインストールされたことを確認するには、roles ディレクトリの内容を一覧表示します。
ls -l roles
これで、以前に作成した apache.developer_configs ロールとともに infra.apache ディレクトリが表示されるはずです。
total 12
drwxr-xr-x. 9 labex labex 4096 Nov 10 10:10 apache.developer_configs
drwxr-xr-x. 9 labex labex 4096 Nov 10 10:15 infra.apache
-rw-r--r--. 1 labex labex 118 Nov 10 10:12 requirements.yml
これで、外部 Git リポジトリを依存関係として正常に宣言し、プロジェクトにインストールしました。次のステップは、この依存関係をカスタムロールのメタデータに統合することです。
Ansible コレクションから RHEL システムロールを統合する
このステップでは、Ansible Collection を使用します。Ansible Collection は、ロール、モジュール、プラグインを含む Ansible コンテンツを配布する標準的な方法です。ここでは、SELinux 管理を含む一般的な管理タスクの自動化に役立つモジュール群を提供する Community General collection をインストールします。
Web サーバーのシナリオでは、Apache サービスが非標準ポートでリッスンできるように SELinux を正しく設定する必要があります。community.general collection には、このタスクに最適な SELinux モジュールが含まれています。
まず、メインのプロジェクトディレクトリにいることを確認してください。
cd ~/project
プロジェクトを自己完結型にするために、Collection はプロジェクトディレクトリ内にインストールしておくのがベストプラクティスです。それらを格納するために collections という名前のディレクトリを作成します。
mkdir collections
次に、ansible-galaxy collection install コマンドを使用して、必要な Collection をインストールします。-p フラグは、コマンドに作成したばかりの collections ディレクトリに Collection をインストールするように指示します。
ansible-galaxy collection install community.general:7.5.0 ansible.posix:1.5.4 -p collections
このコマンドは、Collection とその依存関係をダウンロードします。以下のような出力が表示されます。
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Installing 'community.general:7.5.0' to '/home/labex/project/collections/ansible_collections/community/general'
Installing 'ansible.posix:1.5.4' to '/home/labex/project/collections/ansible_collections/ansible/posix'
...
community.general:7.5.0 was installed successfully
ansible.posix:1.5.4 was installed successfully
Collection がプロジェクトで利用可能になったことを確認するには、Collection パスを指定してインストールされているすべての Collection を一覧表示できます。
ansible-galaxy collection list -p collections
出力には、インストールされた Collection とプロジェクト内のインストールパスが表示されます。
## /home/labex/project/collections/ansible_collections
Collection Version
----------------------- -------
ansible.posix 1.5.4
community.general 7.5.0
プレイブックで Collection のモジュールを使用する場合、その完全修飾 Collection 名 (FQCN) で参照する必要があります。SELinux 管理には、SELinux 状態管理に ansible.posix.selinux を、SELinux ポート管理に community.general.seport を使用します。
これで、SELinux 管理モジュールを含む強力な Collection を正常にインストールしました。次のステップでは、カスタムロール、Git からのロール、およびこれらの Collection の SELinux モジュールを使用して、開発 Web サーバーを完全に構成するプレイブックを組み立てます。
カスタム、Git、およびシステムロールを使用してプレイブックをアセンブルおよび実行する
このステップでは、準備したすべてのコンポーネント（カスタムロール、Git からの依存関係、RHEL システムロール）を統合します。これらのロールをオーケストレーションして開発 Web サーバーを完全に構成するメインプレイブックを作成します。
このステップは、さまざまな部品から複雑な機械を組み立てるようなものだと考えてください。各ロールは特定の目的を果たし、それらが連携して完全な Web サーバー環境を作成します。これを管理可能な小さな部分に分解しましょう。
まず、メインプロジェクトディレクトリにいることを確認してください。
cd ~/project
構成に入る前に、何を作成しているのかを理解しましょう。
- Ansible Configuration: Ansible の動作方法とファイルの検索場所を設定します。
- Inventory: 管理するサーバーを定義します（この場合は localhost）。
- Variables: ロールが使用するデータを格納します（開発者情報、SELinux 設定）。
- Custom Role Content: 開発者環境を構成する実際のタスクです。
- Main Playbook: すべてを正しい順序で実行するオーケストレーターです。
1. Ansible 構成とインベントリの作成
ansible.cfgファイルは、Ansible に動作方法を指示する設定ファイルのようなものです。これがないと、すべてのコマンドでパスとオプションを指定する必要があります。これがあれば、Ansible はロール、コレクション、インベントリの場所を自動的に認識します。
nanoを使用してansible.cfgファイルを作成します。このファイルは、Ansible がロール、コレクション、インベントリの場所をどこで見つけるかを指示します。
nano ansible.cfg
以下の内容を追加します。各行を理解しましょう。
[defaults]
inventory = inventory
roles_path = roles
collections_paths = collections
host_key_checking = False
[privilege_escalation]
become = True
各設定の意味：
inventory = inventory:-i inventoryを毎回入力する代わりに、Ansible はこのファイルを自動的に使用します。roles_path = roles: Ansible はrolesディレクトリでロールを探します。collections_paths = collections: Ansible はインストールされたコレクションをここで見つけます。host_key_checking = False: ラボ環境での SSH キー検証エラーを防ぎます。become = True: 必要に応じて、昇格された権限でタスクを自動的に実行します。
nanoを保存して終了します（Ctrl+X、次にY、次にEnterを押します）。
インベントリファイルは、Ansible がどのマシンを管理するかを指示します。この場合、ローカルマシンを構成しています。
nano inventory
次の行を追加します。
localhost ansible_connection=local
これはどういう意味か：
localhost: 対象ホストの名前です。ansible_connection=local: SSH の代わりにローカル接続を使用します（Ansible を実行しているのと同じマシンを管理しているため）。
nanoを保存して終了します。
2. ロール変数の定義
Ansible の変数は、ロールが使用できる設定のようなものです。タスクにユーザー名やポート番号のような値をハードコーディングする代わりに、変数ファイルで定義します。これにより、自動化が柔軟で再利用可能になります。
group_vars/allディレクトリは、Ansible がすべてのホストの変数を自動的にロードする特別な場所です。このディレクトリ内の任意の YAML ファイルが、プレイブックやロールで利用可能になります。
すべてのホストに適用される変数のディレクトリ構造を作成します。
mkdir -p group_vars/all
次に、開発者情報用の変数ファイルを作成します。このデータは、カスタムロールがユーザーアカウントと Web 構成を作成するために使用します。
nano group_vars/all/developers.yml
次の内容を追加します。
---
web_developers:
- username: jdoe ## First developer
port: 9081 ## Custom port for this developer's website
- username: jdoe2 ## Second developer
port: 9082 ## Custom port for this developer's website
このデータ構造の意味：
web_developers: 開発者情報を含むリストです。- 各開発者には
usernameとportがあります。 - カスタムロールは、このリストをループして各開発者の構成を作成します。
保存して終了します。
次に、SELinux 構成用の変数ファイルを作成します。SELinux（Security-Enhanced Linux）は、アプリケーションができることを制御するセキュリティモジュールです。
nano group_vars/all/selinux.yml
次の内容を追加します。
---
selinux_state: enforcing ## Set SELinux to enforcing mode (highest security)
selinux_ports: ## List of ports to allow Apache to use
- ports: "9081" ## Allow port 9081
proto: "tcp" ## Protocol: TCP
setype: "http_port_t" ## SELinux type: HTTP port
state: "present" ## Add this rule
- ports: "9082" ## Allow port 9082
proto: "tcp" ## Protocol: TCP
setype: "http_port_t" ## SELinux type: HTTP port
state: "present" ## Add this rule
SELinux 設定の理解：
selinux_state: enforcing: SELinux は不正な操作を積極的にブロックします。selinux_ports: ポート構成のリストです。http_port_t: Apache がポートにバインドすることを許可する SELinux タイプです。- デフォルトでは、Apache はポート 80 と 443 しか使用できません。ポート 9081 と 9082 を明示的に許可する必要があります。
保存して終了します。
3. カスタムロールの入力
apache.developer_configsロールには現在ディレクトリ構造がありますが、実際のコンテンツはありません。以下を追加する必要があります。
- Templates: 変数を含めることができるファイル（Jinja2 構文を使用）。
- Tasks: Ansible が実行する実際の作業。
- Handlers: 通知されたときにのみ実行される特別なタスク（サービスの再起動など）。
- Metadata: ロールの依存関係に関する情報。
テンプレートを使用すると、変数に基づいて適応する設定ファイルを作成できます。.j2拡張子は、これが Jinja2 テンプレートであることを示します。
nano roles/apache.developer_configs/templates/developer.conf.j2
次の内容を追加します。
{% for dev in web_developers %}
Listen {{ dev.port }}
<VirtualHost *:{{ dev.port }}>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/{{ dev.username }}
<Directory /var/www/{{ dev.username }}>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
</VirtualHost>
{% endfor %}
テンプレート構文の理解：
{% for dev in web_developers %}: 開発者リストのループを開始します。{{ dev.port }}: この開発者のポート番号を挿入します。{{ dev.username }}: この開発者のユーザー名を挿入します。{% endfor %}: ループを終了します。- 結果として、各開発者の個別の仮想ホスト構成が生成されます。
これが作成するもの： 2 人の開発者に対して、このテンプレートは次の Apache 構成を生成します。
- Apache をポート 9081 および 9082 でリッスンさせます。
/var/www/jdoeおよび/var/www/jdoe2からコンテンツを提供する仮想ホストを作成します。- 各ディレクトリに適切な権限を設定します。
保存して終了します。
タスクは、Ansible が実行する実際の作業です。各タスクは、特定のことを達成するために Ansible モジュールを使用します。
nano roles/apache.developer_configs/tasks/main.yml
次の内容を追加し、各タスクを理解しましょう。
---
## Task 1: Create user accounts for each developer
- name: Create developer user accounts
ansible.builtin.user: ## Use the 'user' module
name: "{{ item.username }}" ## Create user with this name
state: present ## Ensure the user exists
loop: "{{ web_developers }}" ## Do this for each developer in the list
## Task 2: Create web directories for each developer
- name: Create developer web root directories
ansible.builtin.file: ## Use the 'file' module
path: "/var/www/{{ item.username }}" ## Create this directory
state: directory ## Ensure it's a directory
owner: "{{ item.username }}" ## Set the owner
group: "{{ item.username }}" ## Set the group
mode: "0755" ## Set permissions (rwxr-xr-x)
loop: "{{ web_developers }}"
## Task 3: Create a sample webpage for each developer
- name: Create a sample index.html for each developer
ansible.builtin.copy: ## Use the 'copy' module
content: "Welcome to {{ item.username }}'s dev space\n" ## File content
dest: "/var/www/{{ item.username }}/index.html" ## Where to put the file
owner: "{{ item.username }}" ## File owner
group: "{{ item.username }}" ## File group
mode: "0644" ## File permissions (rw-r--r--)
loop: "{{ web_developers }}"
## Task 4: Deploy the Apache configuration file
- name: Deploy developer apache configs
ansible.builtin.template: ## Use the 'template' module
src: developer.conf.j2 ## Source template file
dest: /etc/httpd/conf.d/developer.conf ## Destination on the server
mode: "0644" ## File permissions
notify: restart apache ## Trigger the restart handler when this changes
主要な概念の理解：
loop: リストの各項目に対してタスクを繰り返します。{{ item.username }}: ループ内の現在の項目のユーザー名を参照します。notify: restart apache: このタスクが変更を加えると、「restart apache」というハンドラーがトリガーされます。- ファイル権限：
0755は、所有者が読み取り/書き込み/実行可能で、他者は読み取り/実行可能であることを意味します。0644は、所有者が読み取り/書き込み可能で、他者は読み取りのみ可能であることを意味します。
保存して終了します。
ハンドラーは、他のタスクから通知されたときにのみ実行される特別なタスクです。通常、サービスの再起動などのアクションに使用されます。
nano roles/apache.developer_configs/handlers/main.yml
次の内容を追加します。
---
- name: restart apache ## This name must match the notify: statement
ansible.builtin.service: ## Use the 'service' module
name: httpd ## The service name (Apache is called 'httpd' on RHEL)
state: restarted ## Restart the service
ハンドラーを使用する理由：
- 効率性：設定が実際に変更された場合にのみサービスが再起動されます。
- 順序：すべてのタスクが最初に実行され、その後すべてのハンドラーが最後に実行されます。
- 冪等性：複数のタスクが同じハンドラーを通知できますが、それは一度だけ実行されます。
保存して終了します。
最後に、カスタムロールが以前にインストールしたinfra.apacheロールに依存していることを Ansible に伝える必要があります。
nano roles/apache.developer_configs/meta/main.yml
ファイルのコンテンツを次のように置き換えます。
---
dependencies:
- role: infra.apache ## This role must run before our custom role
これは何をするか：
- Ansible が
apache.developer_configsを実行すると、まずinfra.apacheが自動的に実行されます。 - これにより、カスタム構成を追加する前に Apache がインストールされ構成されることが保証されます。
- 依存関係はリストされた順序で実行されます。
保存して終了します。
4. メインプレイブックのアセンブルと実行
プレイブックは、Ansible に何を行い、どのような順序で行うかを指示するレシピのようなものです。プレイブックは次のことを行います。
- SELinux 設定の構成（pre_tasks）。
- ロールの実行（依存関係チェーンを含む）。
メインプレイブックファイルを作成します。
nano web_dev_server.yml
詳細な説明とともに次の内容を追加します。
---
- name: Configure Dev Web Server ## Playbook name
hosts: localhost ## Run on localhost
pre_tasks: ## Tasks that run before roles
## Task 1: Configure SELinux mode
- name: Set SELinux to enforcing mode
ansible.posix.selinux: ## Module from ansible.posix collection
policy: targeted ## Use the 'targeted' SELinux policy
state: "{{ selinux_state }}" ## Use the variable we defined
when: selinux_state is defined ## Only run if the variable exists
## Task 2: Configure SELinux ports
- name: Configure SELinux ports for Apache
community.general.seport: ## Module from community.general collection
ports: "{{ item.ports }}" ## Port number
proto: "{{ item.proto }}" ## Protocol (tcp)
setype: "{{ item.setype }}" ## SELinux type (http_port_t)
state: "{{ item.state }}" ## present or absent
loop: "{{ selinux_ports }}" ## Loop through our port list
when: selinux_ports is defined ## Only run if the variable exists
roles: ## Roles to execute
- apache.developer_configs ## Our custom role (which will trigger infra.apache)
実行順序の理解：
pre_tasks: SELinux 構成が最初に実行されます。roles: ロールの依存関係（infra.apache）が実行され、次にカスタムロールが実行されます。handlers: 通知されたハンドラーが最後に実行されます。
この順序が重要な理由：
- Apache がカスタムポートにバインドしようとする前に SELinux を構成する必要があります。
- 仮想ホストを構成する前に Apache をインストールする必要があります。
- すべての構成が完了した後でサービスの再起動が行われます。
保存して終了します。
これで、完全な自動化を実行する準備ができました。
ansible-playbook web_dev_server.yml
プレイブックが実行され、詳細な出力が表示されます。期待される内容は次のとおりです（例）。
PLAY [Configure Dev Web Server] *************************************************
TASK [Gathering Facts] **********************************************************
ok: [localhost] ## Ansible collects system information
TASK [Set SELinux to enforcing mode] *******************************************
changed: [localhost] ## SELinux mode was changed
TASK [Configure SELinux ports for Apache] **************************************
changed: [localhost] => (item={'ports': '9081', 'proto': 'tcp', 'setype': 'http_port_t', 'state': 'present'})
changed: [localhost] => (item={'ports': '9082', 'proto': 'tcp', 'setype': 'http_port_t', 'state': 'present'})
TASK [infra.apache : Ensure Apache is installed.] *******************************
changed: [localhost] ## Apache package was installed
TASK [apache.developer_configs : Create developer user accounts] ****************
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})
TASK [apache.developer_configs : Create developer web root directories] *********
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})
TASK [apache.developer_configs : Create a sample index.html for each developer] *
changed: [localhost] => (item={'username': 'jdoe', 'port': 9081})
changed: [localhost] => (item={'username': 'jdoe2', 'port': 9082})
TASK [apache.developer_configs : Deploy developer apache configs] ***************
changed: [localhost] ## Configuration file was created
RUNNING HANDLER [apache.developer_configs : restart apache] *********************
changed: [localhost] ## Apache was restarted
PLAY RECAP **********************************************************************
localhost : ok=17 changed=12 unreachable=0 failed=0 skipped=3 rescued=0 ignored=0
複数のソースからの複数のロールを組み合わせて、完全な Web 開発環境を作成する複雑なプレイブックを正常にアセンブルして実行しました！
RHEL サーバーで SELinux と Apache の設定を確認する
この最終ステップでは、Ansible 自動化がシステムを正しく構成したことを検証します。サービスが期待どおりに実行されており、セキュリティポリシー（SELinux）が正しく適用されていることを確認することが重要です。標準的な RHEL コマンドラインツールを使用して、システムの状態を検査します。
まず、メインのプロジェクトディレクトリにいることを確認してください。
cd ~/project
1. SELinux 設定の検証
コレクションからの SELinux モジュールは、SELinux モードを enforcing に設定し、http_port_t タイプに新しいポートを許可するタスクを実行しました。
sestatus コマンドを使用して、現在の SELinux の状態を確認します。
sestatus
出力には、SELinux が有効であり、enforcing モードであることが示されているはずです。
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
次に、semanage port コマンドを使用して、ポート 9081 および 9082 が http_port_t コンテキストに追加されていることを確認します。関連する行を見つけるために、出力を grep にパイプできます。
sudo semanage port -l | grep http_port_t
デフォルトの HTTP ポートの中に、カスタムポートがリストされているはずです。正確な出力は異なる場合がありますが、定義したポートが含まれます。
http_port_t tcp 9082, 9081, 80, 81, 443, 488, 8008, 8009, 8443, 9000
pegasus_http_port_t tcp 5988
これにより、SELinux モジュールがポリシーを正常に更新したことが確認されます。
2. Apache サービスと設定の検証
infra.apache ロールは httpd サービスをインストールして開始しました。このコンテナ環境では systemctl が利用できないため、ps を使用して実行中のプロセスを確認できます。
ps aux | grep httpd
複数の httpd プロセスが実行されているはずで、サービスがアクティブであることを示しています。
root 8851 0.2 0.4 25652 16228 ? Ss 09:31 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8852 0.0 0.1 25308 6044 ? S 09:31 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8853 0.0 0.3 1443348 11364 ? Sl 09:31 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8854 0.0 0.3 1443348 11480 ? Sl 09:31 0:00 /usr/sbin/httpd -DFOREGROUND
apache 8855 0.0 0.4 1574484 15848 ? Sl 09:31 0:00 /usr/sbin/httpd -DFOREGROUND
labex 9298 0.0 0.0 6408 2176 pts/3 S+ 09:31 0:00 grep --color=auto httpd
3. Web コンテンツへのアクセシビリティの検証
最後に、最も重要なテストは、開発者 Web サイトにアクセスできるかどうかを確認することです。apache.developer_configs ロールは、ポート 9081 および 9082 で仮想ホストを設定しました。curl コマンドを使用して、各エンドポイントからコンテンツをリクエストします。
まず、ポート 9081 でユーザー jdoe のサイトをテストします。
curl http://localhost:9081
期待される出力は、このユーザーのために作成した index.html ファイルの内容です。
Welcome to jdoe's dev space
次に、ポート 9082 でユーザー jdoe2 のサイトをテストします。
curl http://localhost:9082
対応するウェルカムメッセージが表示されるはずです。
Welcome to jdoe2's dev space
これらの成功した curl コマンドは、Apache が正しく構成されており、仮想ホストが機能しており、SELinux ポリシーがカスタムポートでのトラフィックを許可していることを確認します。
おめでとうございます！カスタムロール、Git リポジトリからのロール、および Ansible コレクションからの SELinux モジュールを組み合わせて、安全なマルチテナント開発 Web サーバーを構成する完全な Ansible 自動化プロジェクトを正常に構築しました。
まとめ
この実験 (Lab) では、Ansible ロールとコレクションのパワーと構造を活用して、RHEL Web サーバーの設定を自動化する方法を学びます。まず、ansible-galaxy init コマンドを使用してカスタムロールをゼロから作成し、再利用可能な自動化コンテンツのための標準化されたディレクトリ構造を確立します。この基本的なステップは、より複雑な自動化タスクの準備を整えます。
カスタムロールを基盤として、次に requirements.yml ファイルを介した Git リポジトリからのロールと、Ansible コレクションからの公式 RHEL System Role を含む外部依存関係を統合します。最後に、これらの異なる種類のロール（カスタム、Git ベース、システム）を単一のプレイブックに組み立て、それを実行してサーバーを構成し、結果の Apache および SELinux 設定を検証して、自動化が成功したことを確認します。
