25- 第7章：OpenShiftインストール-3：OCPインストールの説明

type

status

date

slug

summary

目的

このセクションを完了すると、受講者は Red Hat OpenShift Container Platform クラスターのインストールと設定ができるようになります。

アドバンストインストールの概要

ホストの準備が完了したら、アドバンストインストールの方法は以下の 4 つのステップで進めます：

クラスターの機能やアーキテクチャを定義する インベントリファイル を作成する。

OpenShift の prerequisites.yml プレイブック を実行する。

OpenShift の deploy_cluster.yml プレイブック を実行する。

インストールを検証する。

アドバンストインストールのインベントリファイル作成

前のセクションで説明したように、インベントリファイル はプロジェクトディレクトリに配置されます。プロジェクトディレクトリには、ansible.cfg ファイルも含まれます。

ansible.cfg の内容

ansible.cfg ファイルは、Ansible コマンドのデフォルトのインベントリファイルや SSH の設定を定義します。

OpenShift のインストールにおけるインベントリファイルの構成

OpenShift の アドバンストインストール では、インベントリファイルが特定のスキーマに従う必要があります。インベントリファイルには、以下の ホストグループ を定義します。

masters（必須）

OpenShift クラスターでマスターとして動作するホストを定義するグループ。

nodes（必須）

OpenShift クラスターでノードとして動作するホストを定義するグループ。
[masters] セクションに記載されたすべてのホストを、このセクションにも含める必要がある。

etcd

OpenShift クラスターで etcd サービス を実行するホストのグループ。

nfs（オプション）

1 台のみ指定可能。
インベントリファイル内に特定の変数が定義されている場合、OpenShift のプレイブックはこのマシンに NFS をインストール・設定する。

OSEv3 グループについて

このグループには OpenShift クラスターの一部となるすべてのマシン が含まれます。インストールプレイブックは、このグループを参照して クラスター全体に対するタスク を実行します。

以下は、前のガイド付き演習で使用した インベントリファイルの例 です：

このインベントリファイルは OpenShift アドバンストインストールの基本的な構成 となるものです。

ここに グループ変数 や ホスト変数 を追加し、インストールする クラスターの仕様 を定義していきます。

クラスルーム環境でのインベントリ要件

授業で使用する インベントリファイル では、以下の要件を満たす必要があります。

✅ 指定したバージョンの OpenShift Container Platform をインストールすること。

✅ ユーザー認証には「htpasswd 認証」を使用すること。

✅ 「apps.lab.example.com」というワイルドカード DNS エントリを、ホストされた OpenShift アプリケーションのサブドメインとして使用すること。

✅ NFS ストレージを以下の用途に使用すること。

OpenShift の etcd サービス

OpenShift の 内部レジストリ ✅ 外部レジストリとして「クラスルームコンテナレジストリ」を使用すること。

※ docker.io や registry.access.redhat.com には接続できないため。

インストール変数の設定

OpenShift のインストール変数は [OSEv3:vars] セクションで設定します。

これらの変数を使うことで、OpenShift のさまざまなコンポーネントを設定できます。

📌 主な設定可能項目

プライベートコンテナレジストリ の使用

永続ストレージ（Gluster、Ceph、またはその他のクラウドプロバイダー）

クラスターのメトリクス（監視）

クラスターのログ管理

カスタムのクラスター証明書

このように、インベントリファイルに変数を定義することで、環境に合わせた OpenShift クラスターの構築が可能 になります。

このセクションでは、クラスルーム環境での OpenShift インストールに必要な変数のみ を説明します。

注意
クラスルーム環境以外で OpenShift クラスターをインストールする場合は、利用可能なオプションや変数を十分に理解しておく必要があります。
詳細については、「インストールおよび設定ガイド」の「アドバンストインストール」 セクションを参照してください。

OpenShift インストールの設定

バージョンの設定

Red Hat は、OpenShift のメジャーバージョンを決定し、最新のマイナーバージョンを自動適用すること を推奨しています。

インストール時に OpenShift のデプロイタイプとバージョンを指定するには、[OSEv3:vars] セクションで以下の変数を設定します。

openshift_deployment_type=openshift-enterprise

OpenShift のデプロイタイプを指定します。
利用可能な値：

openshift-enterprise（Red Hat OpenShift Container Platform をインストールする場合）
origin（オープンソース版 OpenShift Origin をインストールする場合）

openshift_release=v3.9

インストールする メジャーバージョン を指定します。

クラスルーム環境で使用する追加の変数

openshift_image_tag=v3.9.14

コンテナ化された OpenShift サービスのイメージタグ を "v3.9.14" に固定する。
これにより、クラスターが自動的に新しいコンテナイメージへアップグレードされるのを防ぐ。

openshift_disable_check=disk_availability,docker_storage,memory_availability

システム要件のチェックを無効化する。
クラスルームの仮想マシン（VM）は、本番環境の推奨システム要件を満たしていない。
OpenShift のプレイブックは、ノードが最小要件を満たしていない場合にインストールを停止する設計 になっている。
本番環境以外のクラスターでは、一部のチェックを無効化してインストールを進めることができる。
無効化できるチェックの一覧 は、公式ドキュメントに記載されている。

認証の設定

OpenShift Container Platform の認証機能は OAuth に基づいています。

OAuth は HTTP ベースの API を提供し、対話型（ユーザー）と非対話型（アプリケーション） の両方の認証を可能にします。

OpenShift の OAuth 認証の仕組み

OpenShift マスターは OAuth サーバーとして動作 する。

さまざまな ID プロバイダーと統合可能。

組織独自の ID 管理システムとも連携できる。

OpenShift がサポートする ID プロバイダー

OpenShift では、以下の ID プロバイダーを使用できます：

認証方式	説明
HTTP Basic 認証	外部のシングルサインオン（SSO）システムに委任する。
GitHub / GitLab	GitHub / GitLab アカウントを使用して認証する。
OpenID Connect	OpenID 対応の SSO（Google アカウントを含む）を利用する。
OpenStack Keystone v3	OpenStack Keystone v3 サーバーを利用する。
LDAP v3	LDAP v3 サーバーを使用した認証を行う。

OAuth による認証設定を適切に行うことで、OpenShift クラスターへのアクセスを安全に管理することができます。

OpenShift インストーラーのデフォルトのセキュリティ設定

OpenShift のインストーラーは、デフォルトで セキュアな設定 を採用しています。

初期状態では、DenyAllPasswordIdentityProvider（すべてのパスワード認証を拒否するプロバイダー）が有効になっており、OpenShift クライアントコマンドや API を使用できるのは マスターノード上のローカル root ユーザーのみ です。

外部ユーザーが OpenShift クラスターにアクセスできるようにするには、別の ID プロバイダーを設定する必要があります。

HTPasswd 認証の設定

HTPasswdPasswordIdentityProvider は、Apache HTTPD の htpasswd ユーティリティで生成されたフラットファイルを使用して、ユーザーの認証を行います。

この方法は エンタープライズ向けの ID 管理には適していません が、PoC（概念実証） や小規模な OpenShift デプロイには十分な方法です。

htpasswd コマンドで生成されるファイルは、ユーザー名とパスワードがコロン（:）で区切られたプレーンテキスト形式。

パスワードは MD5 ハッシュ 化される。

ユーザーを追加・削除したり、パスワードを変更した場合、OpenShift の OAuth サーバーがこのファイルを自動で再読み込みする。

🔹 HTPasswd 認証を OpenShift に設定する

Ansible のインベントリファイルに、以下の変数を追加します：

kind: HTPasswdPasswordIdentityProvider → 使用する認証プロバイダーの種類

filename: /etc/origin/master/htpasswd → 認証情報ファイルの保存場所（マスターVM上）

🔹 初期ユーザーリストの設定

インベントリファイルで、最初に作成するユーザーとパスワードのハッシュを指定できます：

ユーザーとパスワードを手動で作成する場合

htpasswd コマンドで、ユーザーとハッシュ化されたパスワードを生成します：

または、openssl を使ってパスワードのハッシュのみを生成できます：

ネットワーク要件の設定

ワイルドカード DNS

OpenShift では、インフラノード用のワイルドカード DNS エントリ を設定することで、新しく作成されたルート（アプリケーションへの外部アクセスの経路）を自動的にクラスターへルーティングできます。

ワイルドカード DNS は、apps.mycluster.com のように 一意のサブドメイン に設定する必要があります。

そのドメイン名が インフラノードのホスト名または IP アドレスに解決 される必要があります。

ワイルドカード DNS を設定するには、インベントリファイルに以下の変数を追加します：

この設定により、例えば myapp.apps.mycluster.com のようなアドレスで、ホストされた OpenShift アプリケーションにアクセスできるようになります。

🔹 まとめ（要約）

アクセス方法	可否	説明
`myapp.myproject.svc.cluster.local`	✅	クラスタ内部のみアクセス可能
`myapp-myproject.apps.mycluster.com`	✅	外部アクセス可能（Route 経由） `myapp-myproject` はルーター名

同じServiceに対して複数のRouteを作成したり、1つのRouteに複数のServiceを設定したりすることも可能ですが、最も一般的な構成は1対1です。

マスターサービスのポート

openshift_master_api_port 変数は、マスターAPIのリッスンポートを定義します。デフォルトではポート8443ですが、マスターとして専用ホストを使用する場合はポート443を使用することができ、接続URLからポート番号を省略できます。マスターコンソールポートは、openshift_master_console_port 変数の値に設定されます。デフォルトのポートは8443です。マスターコンソールもポート443を使用するように設定でき、接続URLからポート番号を省略できます。

ファイアウォール

OpenShiftノードでのデフォルトのファイアウォールサービスは iptables です。全てのノードでファイアウォールサービスとして firewalld を使用する場合は、os_firewall_use_firewalld 変数を true に設定します。

永続ストレージの設定

コンテナは、OpenShiftのいくつかのサービス（例：OpenShiftコンテナレジストリ）を提供するために使用されます。デフォルトでは、コンテナのデータは一時的で、コンテナが破棄されるとデータは失われます。Kubernetesの永続ボリュームフレームワークは、コンテナが永続ストレージを要求し、使用するためのメカニズムを提供します。データ損失を防ぐために、これらのサービスは永続ボリュームを使用するように設定されています。OpenShiftは、さまざまなストレージ技術を使用して永続ボリュームを作成するためのいくつかのプラグインをサポートしています。永続ボリュームは、NFS、iSCSI、GlusterFS、Ceph、または他の商用クラウドストレージを使用して作成できます。

このクラスでは、OpenShiftコンテナレジストリとOpenShift Ansible BrokerサービスがNFS永続ストレージを使用するように設定されています。

注記 NFS永続ストレージは、OpenShiftの本番クラスターではサポートされていません。本番以外のクラスターでNFS永続ストレージを許可するには、インベントリファイルに次の設定を追加します。

OpenShiftコンテナレジストリ

OpenShiftコンテナレジストリのためにNFS永続ストレージを設定するには、インベントリファイルに以下を追加します。

インストールのプレイブックは、NFSプラグインを使用して内部レジストリのための永続ボリュームを作成します。レジストリの永続ボリュームに書き込まれたデータは、NFSエクスポートに書き込まれます。NFSエクスポートは、インベントリファイルの [nfs] セクションにリストされたマシンでホストされます。

NFSサーバーの /exports/registry ディレクトリからNFSエクスポートが作成されます。

レジストリの永続ボリュームに対する推奨NFSマウントオプション。ここでのオプションは、NFSの /etc/exports ファイルに記載されているものと同じです。

OpenShift Ansible Broker

OpenShift Ansible Broker (OAB) は、独自の etcd サービスをデプロイするコンテナ化された OpenShift サービスです。永続的な Etcd ストレージに必要な変数は、レジストリのために必要な変数と似ています：

openshift_hosted_etcd_storage_kind=nfs

NFS を使用して Etcd のストレージを設定する。

openshift_hosted_etcd_storage_nfs_directory=/exports

NFS サーバー上の Etcd データを保存するディレクトリを指定します。ここでは /exports と指定しています。

openshift_hosted_etcd_storage_volume_name=etcd-vol2

Etcd 用の永続的なストレージボリューム名を etcd-vol2 に設定します。

openshift_hosted_etcd_storage_nfs_options="*(rw,root_squash,sync,no_wdelay)"

NFS マウントのオプションを指定します。ここでは、すべてのホスト（*）に対して読み書き（rw）アクセスを許可し、root_squash によって root 権限を制限、sync と no_wdelay で同期的な書き込みを強制します。

openshift_hosted_etcd_storage_volume_size=1G

Etcd ストレージボリュームのサイズを 1GB に設定します。

openshift_hosted_etcd_storage_access_modes=["ReadWriteOnce"]

Etcd ボリュームのアクセスモードを ReadWriteOnce（1 回のホストで読み書き可能）に設定します。

openshift_hosted_etcd_storage_labels={'storage': 'etcd'}

Etcd ストレージにラベル {'storage': 'etcd'} を付与します。

注記

Red Hat ガイドの「インストールと構成」セクションで、他の OpenShift サービスの永続的ストレージ設定の例について確認できます。

切断された OpenShift クラスターの設定

デフォルトでは、OpenShift のインストールプレイブックはクラスターがインターネットに接続されていることを前提としています。RPM やコンテナイメージが必要な場合、外部のソース（例えば、access.redhat.com など）からダウンロードされます。これらの外部リソースに接続できないクラスターは「切断されたクラスター」（または切断されたインストール）と呼ばれます。この教室の OpenShift クラスターはインターネット接続がないため、切断されたインストールです。

切断された OpenShift クラスターをインストールする場合、必要な RPM パッケージとコンテナイメージは環境内で利用できる必要があります。教室では、RPM パッケージが http://content.example.com でホストされており、すべての OpenShift ノードで /etc/yum.repos.d/training.repo ファイルが適切に設定されています。

異なるレジストリの設定

registry.lab.example.com のコンテナレジストリは OpenShift にコンテナイメージを提供します。クラスターがプライベートレジストリからイメージを引き出すように設定するには、インベントリファイルに追加の変数が必要です：

oreg_url=registry.lab.example.com/openshift3/ose-${component}:${version}

イメージの URL を設定します。${component} と ${version} は動的に設定されます。

openshift_examples_modify_imagestreams=true

OpenShift のイメージストリームを変更する設定です。

openshift_docker_additional_registries=registry.lab.example.com

追加の Docker レジストリを指定します。

openshift_docker_blocked_registries=registry.access.redhat.com,docker.io

使用しない Docker レジストリを指定します。ここでは、registry.access.redhat.com と docker.io をブロックしています。

openshift_web_console_prefix=registry.lab.example.com/openshift3/ose

OpenShift Web コンソール用のイメージのプレフィックスを設定します。

openshift_cockpit_deployer_prefix='registry.lab.example.com/openshift3/'

OpenShift Cockpit Deployer のイメージのプレフィックスを設定します。

openshift_service_catalog_image_prefix=registry.lab.example.com/openshift3/ose

サービスカタログのイメージプレフィックスを設定します。

template_service_broker_prefix=registry.lab.example.com/openshift3/ose

テンプレートサービスブローカーのイメージプレフィックスを設定します。

openshift_ansible_service_broker_image_prefix=registry.lab.example.com/openshift3/ose

Ansible サービスブローカーのイメージプレフィックスを設定します。

openshift_ansible_service_broker_etcd_image_prefix=registry.lab.example.com/rhel7/

Ansible サービスブローカー用の etcd イメージのプレフィックスを設定します。

これで、OpenShift に関連するストレージと切断されたインストールの設定が説明されました。

1. OpenShift のイメージレジストリを設定する

OpenShift はコンテナの イメージ（画像） をダウンロードするために イメージレジストリ（Registry） を使用します。デフォルトでは Red Hat の公式レジストリ（registry.access.redhat.com） からダウンロードしますが、企業のセキュリティポリシーや、インターネットに接続できない環境（オフライン環境）では、プライベートレジストリ（社内専用のレジストリ） を使うことが多いです。

その場合、設定を変更して、OpenShift がプライベートレジストリからイメージを取得するようにします：

これにより、OpenShift は registry.lab.example.com からコンテナイメージをダウンロードするようになります。

2. Node Label（ノードラベル）とは？

Node Label（ノードラベル） は、OpenShift の 各サーバー（ノード） に設定する「タグ」のようなものです。これを使うと、特定のアプリケーションを 特定のノードにだけ配置 できます。

例えば：

GPU サーバー には gpu=true のラベルをつける

通常の Web サーバー には web=true のラベルをつける

設定例：

この設定をすると、AI のような GPU が必要なアプリケーション は GPU サーバー だけにデプロイされるようになります。

3. OpenShift の 3 つのノードタイプ

OpenShift の ノード（サーバー） は、一般的に 3 つの種類 に分かれています。それぞれ 特定の役割 を持ち、ラベルで管理されます。

ノードの種類	役割	デフォルトのラベル
Master（マスターノード）	OpenShift 全体を管理する（アプリは実行しない）	`node-role.kubernetes.io/master=true`
Infra（インフラノード）	ルーター（Router）、レジストリ（Registry）など OpenShift のシステムサービスを実行	`region=infra`
Compute（コンピュートノード）	ユーザーが作成したアプリケーション（Webアプリ、DBなど）を実行	`node-role.kubernetes.io/compute=true`

💡 具体例

3 台のサーバーを Master、Infra、Compute ノード として設定する場合：

この設定をすると：

master.example.com → 管理専用（アプリは動かない）

infra.example.com → ルーターや内部レジストリ専用

compute.example.com → ユーザーのアプリ専用（Webアプリ、DB など）

4. この設定は何をしているの？

この設定は OpenShift の etcd のデータを NFS（ネットワークストレージ）に保存する ためのものです。

📌 etcd とは？

etcd は OpenShift の データベース で、以下のような情報を保存しています：

どのアプリがデプロイされているか

どの Pod が実行中か

ネットワークやストレージの設定情報

📌 この設定の意味

ストレージの種類：NFS（ネットワークストレージ）を使用

データの保存場所：/exports ディレクトリに保存

ストレージのサイズ：最大 1GB まで保存可能

アクセス制限：1 台のサーバーのみが書き込み可能（ReadWriteOnce）

📌 なぜ NFS を使うの？

通常、etcd のデータは ローカルディスク に保存されます。しかし、サーバーが壊れるとデータが 消えてしまうリスク があります。

NFS（ネットワークストレージ）を使うと、サーバーがクラッシュしてもデータを失わずに済む ため、安全性が向上します。

まとめ

✅ OpenShift のイメージダウンロード先をプライベートレジストリに変更

✅ Node Label（ノードラベル）を使って、適切なノードにアプリやシステムサービスを配置

✅ etcd のデータを NFS に保存して、データを安全に管理

これにより：

セキュリティ強化 → プライベートレジストリを使用し、安全にイメージを管理

システムの安定化 → Node Label で適切なノードにアプリを配置

データの保護 → etcd のデータを NFS に保存し、障害時のデータ消失を防ぐ

要するに、OpenShift をより安全・安定して運用するための設定 です！ 🚀

OpenShift ノードの設定とインストール手順

1. ノードの役割とラベル設定

OpenShift クラスタのノード（サーバー）は、それぞれ異なる役割を持っています。以下の設定で、各ノードの役割を決めます。

🔹 各ノードの役割

master.lab.example.com

マスターノード（管理サーバー）として設定
node-role.kubernetes.io/master=true というラベルが自動的に付与される

node1.lab.example.com

インフラノード（Infra Node） として設定
region=infra というラベルを手動で設定
OpenShift のルーターやレジストリなど、システムの基盤となるコンポーネントを動かす

node2.lab.example.com

コンピュートノード（Compute Node）（アプリケーション実行用）
node-role.kubernetes.io/compute=true のラベルが自動的に付与される
ユーザーのアプリケーションが実行されるノード

🔹 インフラノードとコンピュートノードを兼任させる場合

1 つのノードで インフラ用 Pod と アプリケーション用 Pod を両方実行したい場合、以下のように設定します。

この設定をすると、nodeX.example.com では、OpenShift のシステムコンポーネント（ルーターやレジストリなど）と、アプリケーション（Web アプリやデータベースなど）の両方を動かすことができます。

2. OpenShift のインストール手順

OpenShift のインストールは、Ansible の Playbook を使用して行います。インストールには 2 つの Playbook（prerequisites.yml と deploy_cluster.yml）を順番に実行します。

📌 必要なツール

OpenShift のインストールには atomic-openshift-utils パッケージが必要

Playbook を実行するマシン（例：ワークステーション）に 事前にインストール する必要がある

3. 事前チェック（prerequisites.yml の実行）

prerequisites.yml は、OpenShift をインストールする前に、クラスタ全体のシステム要件をチェックし、不足している設定を修正する Playbook です。

📌 実行コマンド

📌 実行後の出力（例）

📌 ポイント

ok= → 正常に完了したタスク数

changed= → 設定が変更されたタスク数

unreachable=0 failed=0 → 問題が発生していなければ、次のステップへ進める

4. OpenShift のインストール（deploy_cluster.yml の実行）

事前チェックが完了したら、deploy_cluster.yml を実行して OpenShift クラスタをインストールします。

📌 実行コマンド

この Playbook を実行すると、マスターノード、インフラノード、コンピュートノードが適切に設定され、OpenShift クラスタが動作するようになります。 🚀

まとめ

ノードの役割を決める

Master（管理用）、Infra（インフラ用）、Compute（アプリ用）に分ける

必要に応じて、Infra と Compute を兼用できる

Ansible Playbook を使って OpenShift をインストール

事前チェック（prerequisites.yml） → システム要件を満たしているか確認

クラスタの展開（deploy_cluster.yml） → OpenShift のインストールを実行

この手順を踏むことで、OpenShift クラスタが正しくセットアップされ、安定したコンテナ環境を構築 できます！ 🎉

OpenShift クラスタのデプロイ結果と確認方法

...（出力の一部省略）...

📌 デプロイ結果（PLAY RECAP の出力）

🔹 デプロイ成功の確認ポイント

failed=0 であれば、エラーなしで正常にインストール完了

changed=XXX は、変更された設定の数

unreachable=0 なら、通信エラーなし

→ failed=0 なら、OpenShift のデプロイは成功！ 🎉

OpenShift インストールの確認方法

deploy_cluster.yml の実行が完了したら、OpenShift の Web コンソール にアクセスし、インストールが正しく完了しているか確認します。

1. OpenShift Web コンソールの URL

クラスタにマスターノードが 1 台ある場合、Web コンソールの URL は以下の形式になります。

例（教室環境の場合）：

📌 注意点

OpenShift の Web コンソールは HTTPS（セキュアな接続）で動作

openshift_master_console_port 変数でポート番号が指定される

デフォルトの HTTPS ポートは 443 のため、URL を短縮できる

👉 最終的なアクセス URL:

2. Web コンソールへのログイン

ブラウザを開く

上記の URL を入力してアクセス

ログイン画面が表示されることを確認

✅ ログイン画面が表示されたら、OpenShift のインストールは成功！ 🎉

さらなる検証の必要性と追加情報

OpenShift のすべてのサービスが正常に稼働していることを確認するために、さらなる検証 が必要です。

次のセクションでは、インストール後に実施するべきタスクと、インストールを検証する手順について説明します。

参考資料

OpenShift のインストールプロセスに関する詳細情報は、「インストールおよび設定」ドキュメントの「高度なインストール」セクション に記載されています。

📌 公式ドキュメントへのリンク（OpenShift 3.9 用）

🔗 Red Hat OpenShift Container Platform 3.9 - インストールと設定

このドキュメントには、インストール手順の詳細や設定オプションが含まれています。

目的