RHEL 実践 #6 トラックの締めくくり: リファレンスアーキテクチャ

インフラ Linux RHEL Red Hat
読了 8分

RHEL 実践トラックを追いながら、Web サーバ、データベース、コンテナ、モニタリング、自動化を 1 つずつ身につけてきました。各記事は 1 つのテーマを最初から最後まで扱いましたが、実際の運用ではこれらの部品がバラバラに動くわけではありません。1 台のサーバの上で互いに噛み合って回ります。トラック最終回となる今回は、これまで扱ったすべての部品を 1 つのリファレンスアーキテクチャにまとめ、小さな Web サービスを RHEL の上でどう構成し運用するかの全体像を描きます。

リファレンスアーキテクチャは大げさなダイアグラムではありません。どの部品をどの順で積み、何を永続的に固定し、どこをロックし、何をバックアップするかについての 1 枚の合意です。この記事をトラック全体の要約であると同時に、現場ですぐ取り出して使えるチェックリストとして使ってください。

1 台で回す小さな Web サービス #

このトラックで扱った部品を集めると、小さな Web サービスが 1 台分でき上がります。構成は次のとおりです。

  • nginx フロント。外部リクエストを受ける入口です。静的コンテンツを直接返すか、後ろにあるアプリケーションへリクエストを転送する reverse proxy の役割を果たします (#1)。
  • PostgreSQL データ層。サービスの状態を保管するデータベースです。AppStream module でインストールし、データディレクトリと SELinux コンテキストを合わせます (#2)。
  • Podman コンテナ。アプリケーション本体はコンテナで動かします。quadlet で systemd サービスのように扱い、ブート時に自動で立ち上がるようにします (#3)。
  • Cockpit/PCP モニタリング。Web コンソールでサーバの状態を見て、PCP で性能指標を収集します (#4)。
  • Ansible 自動化。上記すべての構成を手で 1 回ずつ行う代わりに playbook でコード化し、同じサーバをいつでも同じように再現します (#5)。

この 5 つの部品が 1 台のサーバの中でどう層を成すかを図で見ると、次のようになります。

                    [ 外部ユーザー ]
                          │
                    HTTPS (443)
                          │
   ┌──────────────────────┴───────────────────────┐
   │                  RHEL サーバ                    │
   │                                                │
   │   firewalld (80·443·22 のみ開放)                │
   │   SELinux enforcing (全層で強制)                │
   │  ──────────────────────────────────────────    │
   │                                                │
   │   [ nginx フロント ] ── reverse proxy ──┐       │
   │                                        │        │
   │                              [ Podman コンテナ ] │
   │                                  (アプリ本体)    │
   │                                        │        │
   │                              [ PostgreSQL ]     │
   │                                  (データ)       │
   │                                                │
   │  ──────────────────────────────────────────    │
   │   [ Cockpit·PCP ] 状態・性能の観測             │
   │   [ Ansible ]     構成全体をコードで再現        │
   │                                                │
   │   journald 永続ログ │ chronyd 時刻同期          │
   │   3-2-1 バックアップ (DB ダンプ + 設定 + ボリューム) │
   └────────────────────────────────────────────────┘

上から下へリクエストが流れ、その流れ全体を firewalld と SELinux が包み、横でモニタリングと自動化が支えます。1 台構成ですが、各層の責務がはっきり分かれています。

運用チェックリスト #

リファレンスアーキテクチャの核心は図よりも 運用規律 です。トラック全体で繰り返し強調してきた原則を 1 か所に集めました。新しいサーバを立ち上げるたびに、このリストを上から下へ点検すればよいでしょう。

1. すべての設定を永続的に固定する #

ランタイムだけに適用した設定は再起動 1 回で消えます。マウントは /etc/fstab に、サービスは systemctl enable で、ファイアウォールは --permanent で、SELinux boolean・ポート・コンテキストは semanage と setsebool -P で永続化します。

# マウントは fstab に登録して検証
sudo systemctl daemon-reload
sudo mount -a

# サービスは enable でブート自動起動を固定
sudo systemctl enable --now nginx postgresql

# ブート時に立ち上がるサービス一覧を確認
systemctl list-unit-files --state=enabled

「今動くか」ではなく「再起動後も動くか」を基準にします。運用中で最もよくある事故は、一時的な設定が再起動とともに消えてしまうケースです。

2. SELinux は enforcing で維持する #

塞がれたからといって setenforce 0 や SELINUX=disabled に逃げません。enforcing を維持したままポリシーで解きます。ポートは semanage port、ファイルコンテキストは semanage fcontext + restorecon、動作許可は setsebool -P で処理します。

# enforcing 状態を確認 (必ず Enforcing であること)
getenforce

# 塞がれたときの原因診断
sudo ausearch -m AVC -ts recent

setenforce 0 は原因が SELinux かどうかを見分ける 確認用 として一瞬だけ使い、すぐに setenforce 1 で戻します。

3. firewalld は最小限だけ開く #

開ける必要のあるポートだけを永続的に開け、残りは閉じておきます。小さな Web サービスなら通常、22 (SSH)・80 (HTTP)・443 (HTTPS) の 3 つで十分です。

# 必要なサービスだけ永続許可
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

# 開いている項目を確認
sudo firewall-cmd --list-all

「とりあえず全部開けて後で閉じよう」は、ほぼ永遠に開いたまま残ります。最初から最小限で始めましょう。

4. バックアップは 3-2-1 原則を守る #

データを 3 部、異なる媒体 2 種、そのうち 1 部は別の場所に置きます。小さな Web サービスでバックアップ対象は 3 つです。PostgreSQL データ (pg_dump)、設定ファイル (/etc とコンテナ定義)、コンテナのデータボリュームです。

# DB 論理バックアップ
sudo -u postgres pg_dump appdb > /backup/appdb-$(date +%F).sql

# 設定・ボリュームは別媒体と遠隔地へ複製

復元テストまで行って初めてバックアップと言えます。定期的に復元を確認していないバックアップは、バックアップとは呼べません。

5. アップデートは dnf で定期適用する #

セキュリティパッチを後回しにしません。dnf upgrade で定期的に更新し、必要なら dnf-automatic でセキュリティアップデートを自動化します。

# セキュリティアップデートだけ事前確認
sudo dnf updateinfo list security

# 全体更新
sudo dnf upgrade -y

6. ログは journald 永続保存で残す #

デフォルトの journald は再起動時にログが揮発する場合があります。/var/log/journal ディレクトリを作って永続保存に切り替えると、ブート以前のログまで追跡できます。

# 永続保存ディレクトリを作成後に再起動
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

7. ユーザーは最小権限で運用する #

root で直接ログインしません。一般ユーザーに必要な分だけ sudo を与え、SSH は鍵認証のみ許可してパスワードログインを塞ぎます。

# SSH 鍵登録後、パスワード・root ログインを遮断
# /etc/ssh/sshd_config で
#   PasswordAuthentication no
#   PermitRootLogin no
sudo systemctl reload sshd

権限は与えられる最小値から始めて、必要なときに増やします。最初から広く与えると、後で狭めるのが難しくなります。

8. 時刻は chronyd で同期する #

ログの時刻、証明書の有効期間、データベースのタイムスタンプがすべて時計に依存します。chronyd で時刻を同期し、状態を確認します。

# 同期状態を確認
chronyc tracking
chronyc sources

セキュリティの基本 #

上のチェックリストのうちセキュリティに該当する 4 つは、別にまとめて強調します。小さなサービスでも、この 4 つは妥協しません。

  • SELinux enforcing を維持。アプリケーションが害を受けても、その影響がポリシー境界を越えないように止める最後の防壁です。
  • firewalld 最小開放。攻撃面を物理的に減らします。閉じたポートは破れません。
  • SSH 鍵認証。パスワード総当たりを根本から遮断します。鍵認証だけ残してパスワードと root ログインを塞ぎます。
  • 最小権限。各ユーザーとサービスに必要な分だけ権限を与えます。事故が起きても被害範囲を狭められます。

この 4 つは RHEL がデフォルトで強く推している領域でもあります。デフォルトを切らずそのまま生かして運用するだけで、かなりの水準のセキュリティを確保できます。

学習経路: 実務から資格まで #

このトラックで RHEL 運用の 1 サイクルを手に馴染ませました。次の段階へ進む道は 2 つに分かれます。より深い実務へ行くか、資格で知識を整理するかです。

これまでの流れを整理すると次のとおりです。RHEL 実務トラックで systemd・SELinux・firewalld・ストレージの 基礎機能 を身につけ、この RHEL 実践トラックでその機能を編み合わせて 実際のサービスを運用するシナリオ を追いました。この 2 段階を経れば、資格準備に必要な実務感覚はすでにかなりの部分が備わったことになります。

資格はこの感覚を体系へ整理し、客観的に証明する手段です。Red Hat の代表的な資格は 2 つです。

  • RHCSA。システム管理者の資格です。このトラックで扱ったサービス管理、ストレージ、SELinux、ユーザー・権限、ネットワーク基礎が試験範囲とそのまま重なります。
  • RHCE。自動化エンジニアの資格です。#5で扱った Ansible 自動化が中心テーマです。RHCSA を先に取得してから進む順序です。

どちらの試験も選択式ではなく 実際のシステムを扱う実技試験 です。このトラックのように手で直接構成した経験が、最も確実な準備になります。

トラックを終えて #

ここまで RHEL 実践トラック 6 記事を完走しました。おめでとうございます。パッケージを 1 つインストールして終わらない RHEL 運用の実際を、Web サーバから自動化まで 1 サイクルで通り抜けました。これで新しいサーバを受け取ったとき、何をどの順で積み、何を永続的に固定し、どこをロックすべきかについて、自分なりの基準が身についたはずです。

この記事の運用チェックリストはトラック全体の圧縮版です。現場で新しいサーバを立ち上げるたびに一度ずつ取り出して、抜けがないか点検してください。

次のステップ #

実務と実践を経たなら、資格で知識を整理する番です。2 つの資格トラックへつながります。

  • RHCSA トラックで、システム管理者資格の試験範囲を項目別に整理し、実技対策の流れを扱います。
  • RHCE トラックで、Ansible 自動化を中心としたエンジニア資格を RHCSA 以降の段階として準備する道を案内します。
X