Red Hat Enterprise Linuxの主要機能まとめ。（コンテナ・Kubernetes含む）

はじめに

本記事では、Red Hat Enterprise Linux（RHEL）を基盤とした OS 運用、kernel live patching、運用自動化、container runtime、container registry、Kubernetes / OpenShift workload 実行基盤について整理します。

目的は、Linux 運用基盤から cloud-native application platform までの流れを、特定の個別環境に依存しない形で説明することです。サンプルコマンドも記載しますが、実環境では subscription、repository、network、security policy、組織の運用ルールに合わせて調整してください。

全体像

Red Hat 環境では、以下のように役割を分けて理解すると分かりやすいです。

領域	主な技術・製品	役割
OS 基盤	RHEL	enterprise Linux platform、OS patch、security、container host
OS lifecycle / patch 管理	Red Hat Satellite、RHEL management	repository、content、patch level、lifecycle の管理
Kernel live patching	kpatch / kernel live patching	再起動を減らしながら一部の kernel security fix を適用
運用自動化	Red Hat Ansible Automation Platform / Ansible	複数 host への構成変更、運用作業、監査性の向上
Container runtime	Podman	Docker daemon に依存しない container engine
Container registry	Red Hat Quay / private registry	container image の保管、配布、scan、access control
Kubernetes platform	Red Hat OpenShift	Kubernetes を中核にした enterprise application platform

1. RHEL の OS lifecycle / patch management

RHEL 環境では、OS package、security advisory、repository、subscription、compliance、fleet management を一貫して管理することが重要です。

特に本番環境では、個別 server ごとに ad hoc に update するのではなく、検証済み content を段階的に展開する運用モデルが求められます。

主なポイントは以下です。

• 複数 server に対する patch level の統制
• 本番環境に適用する package set の事前検証
• repository / content view / lifecycle environment による段階的な展開
• security advisory を基準にした優先順位付け
• 適用状況の可視化と監査証跡の確保

サンプルコマンド: RHEL の更新状況確認

# RHEL subscription の状態確認
sudo subscription-manager status

# 有効 repository の確認
sudo dnf repolist

# 適用可能な security update の確認
sudo dnf updateinfo list security

# security update のみ適用
sudo dnf update --security

# reboot が必要か確認
sudo dnf install -y dnf-utils
needs-restarting -r

アピールポイント

OS patch を個別 host ごとに手作業で適用するのではなく、環境単位、role 単位、application 単位で計画的に管理できる点が重要です。

本番環境では、検証済み content を test / staging / production のような段階を経て展開することで、patch 適用の再現性と安全性を高められます。

2. Kernel live patching / kpatch

Red Hat 環境では、kernel live patching / kpatch により、稼働中の kernel に対して一部の security fix や bug fix を適用し、再起動回数を削減する運用が可能です。

これは、停止時間の制約が大きい system で有効な技術です。

ただし、kernel live patching は再起動を完全になくす技術ではありません。すべての CVE や kernel update が live patching で解決できるわけではないため、通常の kernel package update と reboot planning は引き続き必要です。

サンプルコマンド: kpatch の確認

# kpatch 関連 package の導入
sudo dnf install -y kpatch

# 現在の kernel version を確認
uname -r

# 利用可能な live patch package を確認
sudo dnf search kpatch-patch

# 現在の kernel に対応する live patch package を導入する例
# 実際の package 名は環境と repository により異なる
sudo dnf install -y "kpatch-patch-$(uname -r)"

# 適用済み live patch の確認
sudo kpatch list

アピールポイント

kernel live patching / kpatch は、重要な kernel security fix を計画停止まで待たずに適用しやすくする技術です。

長時間稼働する workload や、停止時間の制約が大きい system では、reboot 回数や緊急停止の必要性を減らせる点が大きな価値になります。

3. Red Hat Ansible Automation Platform による運用自動化

Red Hat Ansible Automation Platform は、Linux host、middleware、network、cloud resource などに対する構成変更や運用作業を自動化するための platform です。

単なる command 実行ではなく、Playbook によって「望ましい状態」を定義し、複数 server に対して一貫した操作を行える点が重要です。

主なポイントは以下です。

• 複数 host に対する構成変更を一括で実行できる
• 手順を Playbook として残せるため、作業の再現性と監査性が高い
• GUI / API / schedule / approval workflow などを通じて、運用チーム内で作業を標準化できる
• application deployment、OS 設定変更、service restart、inventory 管理など幅広い用途に利用できる

サンプル: inventory file

[rhel_servers]
rhel-node1.example.com
rhel-node2.example.com

サンプル: /etc/hosts を更新する Playbook

単に hostname や uptime を取得するだけでなく、管理対象 host の設定ファイルを変更し、変更後の結果を確認する例の方が automation の価値を説明しやすくなります。

以下は、複数 RHEL host に対して name resolution 設定を追加し、対象 hostname が解決できることを確認する例です。

---
- name: Configure hostname resolution on RHEL hosts
  hosts: rhel_servers
  become: true
  vars:
    target_ip: "192.0.2.10"
    target_hostname: "appserver01.example.com"

  tasks:
    - name: Add target server entry to /etc/hosts
      ansible.builtin.lineinfile:
        path: /etc/hosts
        line: "{{ target_ip }} {{ target_hostname }}"
        state: present
        create: true
        backup: true

    - name: Verify hostname resolution
      ansible.builtin.command: getent hosts {{ target_hostname }}
      register: host_lookup
      changed_when: false

    - name: Show hostname resolution result
      ansible.builtin.debug:
        var: host_lookup.stdout

サンプルコマンド: Playbook 実行

ansible-playbook -i inventory.ini config_hosts.yml

Red Hat Ansible Automation Platform を利用する場合は、このような Playbook を project として登録し、inventory、credential、job template、schedule、approval workflow と組み合わせて運用できます。

4. Podman: Docker daemon に依存しない container engine

Podman は Red Hat 系 Linux を中心に広く使われる open source container engine です。RHEL 環境では、Docker daemon に依存せずに container image を実行・管理するための重要な選択肢となります。

重要ポイント: Podman は Kubernetes のような cluster orchestration platform の代替ではなく、Docker runtime / Docker daemon の代替として位置付けるのが正確です。単体 Linux host 上で container workload を実行し、systemd と連携して運用管理できる点が大きな強みです。

主なポイントは以下です。

• daemonless architecture により、常駐 Docker daemon に依存しない
• rootless container により、一般 user 権限で container を実行する構成を取りやすい
• systemd 連携により、container を Linux service として管理しやすい
• Open Container Initiative 互換の image を扱えるため、Docker、Podman、Kubernetes、OpenShift などの環境で image を再利用しやすい
• Podman pod により、複数 container を pod 単位でまとめて扱える

Container image は Docker だけで利用されるものではなく、Open Container Initiative などの標準仕様に基づく形式として広く利用されています。Podman は標準的な container image を扱えるため、Docker daemon に依存せずに container workload を実行できます。

サンプルコマンド: Podman の基本操作

# Podman の導入
sudo dnf install -y podman

# version 確認
podman --version

# container image の取得
podman pull registry.access.redhat.com/ubi9/httpd-24

# container の起動
podman run -d \
  --name rhel-httpd \
  -p 8080:8080 \
  registry.access.redhat.com/ubi9/httpd-24

# local access 確認
curl http://localhost:8080

# container 状態確認
podman ps

# container 停止・削除
podman stop rhel-httpd
podman rm rhel-httpd

サンプルコマンド: rootless container と systemd 連携

Podman の大きな強みは、container を systemd service として管理しやすい点です。

# 一般 user で container を起動
podman run -d \
  --name rhel-httpd \
  -p 8080:8080 \
  registry.access.redhat.com/ubi9/httpd-24

# systemd user service unit を生成
mkdir -p ~/.config/systemd/user
podman generate systemd --new --name rhel-httpd --files
mv container-rhel-httpd.service ~/.config/systemd/user/

# systemd user service として有効化
systemctl --user daemon-reload
systemctl --user enable --now container-rhel-httpd.service

# logout 後も user service を維持したい場合
loginctl enable-linger "$USER"

# 状態確認
systemctl --user status container-rhel-httpd.service

5. Podman と Kubernetes YAML 連携

Podman には、Podman で作成した pod の構成を Kubernetes 形式の YAML として出力し、その YAML から Podman 上に pod を再作成する機能があります。

これにより、Podman は単体 host 上の container 実行だけでなく、Kubernetes 形式の構成ファイルとの連携機能も備えていることを説明できます。

ただし、ここで言う YAML 連携は、「Podman pod をそのまま本番 Kubernetes / OpenShift に完全移行できる」という意味ではありません。正確には、Podman と Kubernetes 形式の manifest に一定の連携性があり、local container / pod 構成を Kubernetes 的な記述で扱いやすい、という意味です。

サンプルコマンド: Podman pod を YAML に出力して再作成

# Podman pod を作成
podman pod create --name web-pod -p 8081:8080

# pod 内で container を起動
podman run -d \
  --pod web-pod \
  --name web \
  registry.access.redhat.com/ubi9/httpd-24

# local access 確認
curl http://localhost:8081

# Podman pod の構成を Kubernetes 形式の YAML に出力
podman generate kube web-pod > web-pod.yaml

# 一度 pod を削除
podman pod rm -f web-pod

# YAML から pod を再作成
podman play kube web-pod.yaml

# 再作成後の確認
podman pod ps
curl http://localhost:8081

6. Container registry と image lifecycle

Container workload を本番運用する場合、container image をどこで build し、どの registry に保管し、どの platform が pull して実行するかを明確にする必要があります。

Red Hat 環境では、private registry、Red Hat Quay、OpenShift integrated registry、または enterprise registry を使う構成が考えられます。

主なポイントは以下です。

• 開発環境で build した image を registry に push する
• registry 側で access control、image signing、vulnerability scanning、retention policy を管理する
• OpenShift / Kubernetes は registry から image を pull し、Pod として実行する
• private registry を使用する場合は、cluster 側に image pull 用の認証情報を安全に設定する

サンプル: Containerfile

FROM registry.access.redhat.com/ubi9/ubi

RUN dnf -y install httpd && \
    dnf clean all && \
    echo "Hello from a custom RHEL-based container image." > /var/www/html/index.html

EXPOSE 80

CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

サンプルコマンド: image build / push

# image build
podman build -t registry.example.com/team/sample-web:v1 .

# registry login
podman login registry.example.com

# image push
podman push registry.example.com/team/sample-web:v1

# image inspect
podman inspect registry.example.com/team/sample-web:v1 --format '{{.Architecture}}'

実運用では、custom application image を enterprise registry に登録し、OpenShift がその image を pull して workload として実行します。これにより、image build、registry 管理、deployment、rollback までの流れを platform として統制できます。

7. OpenShift と Kubernetes の関係

OpenShift は Kubernetes を中核にした enterprise application platform です。

Kubernetes は container orchestration の基盤であり、Pod、Deployment、Service、Ingress、ConfigMap、Secret などの resource を使って containerized application を管理します。

一方、OpenShift は Kubernetes の上に、enterprise 運用に必要な機能を統合した platform として位置付けられます。

重要ポイント: OpenShift は Kubernetes と競合する別物ではなく、Kubernetes を内包・拡張した enterprise platform として理解するのが分かりやすいです。Kubernetes が container orchestration の中核であり、OpenShift はその上に developer experience、security、operator、web console、observability、image build / deploy、cluster lifecycle management などを加えた製品です。

整理すると以下です。

• Kubernetes: containerized application を cluster 上で scheduling / scaling / self-healing する orchestration engine
• OpenShift: Kubernetes を中核に、enterprise security、developer workflow、cluster operation、operator、registry、monitoring などを統合した application platform
• OpenShift Container Platform: self-managed OpenShift。on-premises、private cloud、public cloud などで自社管理する形態
• Managed OpenShift services: Red Hat OpenShift Service on AWS、Azure Red Hat OpenShift、OpenShift Dedicated など、managed service として利用する形態

8. OpenShift / Kubernetes workload の基本操作

OpenShift / Kubernetes workload 検証としては、以下の観点を整理すると分かりやすいです。

• Deployment による application workload の定義と replica 管理
• Service / Route / Ingress / LoadBalancer による外部公開
• Pod 障害時の self-healing
• rolling update と rollback による application version 更新
• private registry からの custom image pull
• namespace、RBAC、NetworkPolicy による環境分離と security control

サンプルコマンド: project / namespace 作成

# OpenShift cluster に login
oc login https://api.cluster.example.com:6443

# project 作成
oc new-project demo-container-app

# 現在の project 確認
oc project

サンプルコマンド: custom image を OpenShift に deploy

# private registry を使う場合の image pull secret 作成例
oc create secret docker-registry registry-credential \
  --docker-server=registry.example.com \
  --docker-username='<registry-user>' \
  --docker-password='<registry-token>' \
  --docker-email='[e-mail]'

# default service account に image pull secret を紐付け
oc secrets link default registry-credential --for=pull

# deployment 作成
oc create deployment sample-web \
  --image=registry.example.com/team/sample-web:v1

# replica 数を変更
oc scale deployment/sample-web --replicas=3

# service 作成
oc expose deployment/sample-web --port=80 --target-port=80

# route 作成
oc expose service/sample-web

# route 確認
oc get route sample-web

サンプルコマンド: 状態確認と self-healing

# Pod / Deployment / Service / Route 確認
oc get pods -o wide
oc get deployment
oc get service
oc get route

# Pod を 1 つ削除して self-healing を確認
POD_NAME=$(oc get pods -l app=sample-web -o jsonpath='{.items[0].metadata.name}')
oc delete pod "$POD_NAME"

# 新しい Pod が再作成されることを確認
oc get pods -w

サンプルコマンド: rolling update / rollback

# image を v2 に更新
oc set image deployment/sample-web \
  sample-web=registry.example.com/team/sample-web:v2

# rollout 状態確認
oc rollout status deployment/sample-web

# rollout history 確認
oc rollout history deployment/sample-web

# rollback
oc rollout undo deployment/sample-web

# rollback 後の状態確認
oc rollout status deployment/sample-web

サンプルコマンド: Route 経由で access 確認

ROUTE_HOST=$(oc get route sample-web -o jsonpath='{.spec.host}')
curl "http://${ROUTE_HOST}"

9. Managed OpenShift と self-managed OpenShift

OpenShift は、self-managed と managed service の両方の選択肢を持ちます。

短期間で workload 検証を行う場合は managed OpenShift service が有効であり、platform 自体の設計・運用を含めて検証したい場合は self-managed OpenShift Container Platform が適しています。

• Managed OpenShift: cluster control plane や基盤運用の多くを service provider 側に任せ、application workload の検証や運用に集中しやすい
• Self-managed OpenShift: install、upgrade、node、network、storage、security policy などを自社側で設計・運用する
• RHEL / Red Hat CoreOS / OpenShift の lifecycle を含めて管理したい場合は self-managed 構成の理解が重要

サンプルコマンド: OpenShift installer の流れ

実際の install 手順は環境により大きく異なりますが、self-managed OpenShift では OpenShift installer を使って cluster を作成する流れになります。

# installer と pull secret を準備したうえで install-config を作成
openshift-install create install-config --dir=cluster-config

# cluster 作成
openshift-install create cluster --dir=cluster-config --log-level=info

# kubeconfig を指定して cluster に接続
export KUBECONFIG=cluster-config/auth/kubeconfig
oc get nodes

10. RHEL 上での Kubernetes 自力構築について

Red Hat 環境では、OpenShift を主な Kubernetes / application platform として説明できます。一方で、Kubernetes 環境を自力で構築する選択肢もあります。

自力構築では、RHEL host を control plane / worker node として準備し、container runtime、networking、storage、load balancer、ingress、monitoring、logging、security policy などを導入・設定して cluster を構築します。

これは Kubernetes 基盤そのものを学習・検証したい場合には有効ですが、本番運用では upgrade、security、CNI、CSI、certificate、backup、failure handling などの責任範囲が大きくなります。

サンプルコマンド: kubeadm による Kubernetes 初期化の流れ

以下は、一般的な Kubernetes 自力構築のイメージを示す例です。RHEL での本番構成では、support policy、repository、container runtime、CNI、security policy を事前に確認してください。

# container runtime の例
sudo dnf install -y containerd
sudo systemctl enable --now containerd

# kubelet / kubeadm / kubectl の導入例
# repository 設定は環境・version・support policy に合わせて準備する
sudo dnf install -y kubelet kubeadm kubectl
sudo systemctl enable --now kubelet

# control plane の初期化例
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# kubeconfig 設定例
mkdir -p "$HOME/.kube"
sudo cp /etc/kubernetes/admin.conf "$HOME/.kube/config"
sudo chown "$(id -u):$(id -g)" "$HOME/.kube/config"

# CNI plugin 導入例
# 実際には組織標準の CNI を選定する
kubectl apply -f <cni-manifest-url>

# node 状態確認
kubectl get nodes

OpenShift を使う意味

OpenShift は Kubernetes を中核にしつつ、cluster operation、developer workflow、security、operator、observability などを platform として統合します。

単なる Kubernetes cluster を構築するだけでなく、enterprise application platform として運用したい場合に有効です。

11. 本番利用に向けた追加検証項目

PoC では基本機能の確認に重点を置きますが、本番利用では security、operation、availability、governance の観点で追加検証が必要です。

特に OpenShift / Kubernetes では、application だけでなく cluster platform の運用設計が重要です。

項目	意味	本番検討時の観点
namespace 分離	Kubernetes cluster 内で、環境、チーム、アプリケーションごとに namespace を分けること	dev / test / prod、または app-a / app-b などを分離し、権限と運用範囲を明確にする
RBAC	誰が Kubernetes / OpenShift 上で何を操作できるかを制御する権限管理	開発者は参照中心、運用管理者は deployment 更新可能、platform 管理者は cluster 設定変更可能、などに分ける
NetworkPolicy	Pod 間通信を制御する Kubernetes のネットワークルール	Web Pod から DB Pod への通信は許可し、他の Pod から DB への通信は拒否する、など
image scanning	Container image に脆弱性や危険な package が含まれていないかを検査すること	Registry に格納した image を本番 deploy 前に scan し、脆弱性や policy violation を検出する
Secret 管理	Password、token、private key などの機密情報を安全に管理すること	平文で manifest に書かず、Kubernetes Secret、外部 secret store、platform 機能と連携する
multi-zone / node failure test	Availability zone や worker node に障害が起きても application が継続できるかを確認する試験	worker node 停止時の Pod 再配置、Service / LoadBalancer 経由の access 継続、application availability を確認する

12. まとめ

Red Hat 環境では、RHEL を OS 基盤、kpatch を kernel live patching、Ansible Automation Platform を運用自動化、Podman を daemonless container engine、OpenShift を Kubernetes-based enterprise application platform として整理すると分かりやすいです。

特に Podman と OpenShift の関係は重要です。

Podman は単体 host 上の container runtime / management tool であり、Docker daemon 代替として有効です。一方、OpenShift は Kubernetes を中核にした cluster orchestration / application platform であり、複数 node にまたがる workload 管理、security、deployment、observability を扱います。

両者は競合関係ではなく、local / host-level container execution と cluster-level application platform という役割の違いで説明するのが適切です。

参考情報

• Red Hat Enterprise Linux 9 Documentation: Applying patches with kernel live patching
• Red Hat Enterprise Linux 9 Documentation: Building, running, and managing containers
• Red Hat OpenShift product overview
• OpenShift Container Platform Documentation: Architecture
• Red Hat Quay product overview
• Red Hat Ansible Automation Platform product overview