Red Hat SummitThis documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.インストールと設定
OpenShift Container Platform 3.9 のインストールおよび設定
概要
第1章 概要
『OpenShift Container Platform のインストールおよび設定』では、ご使用の環境で OpenShift Container Platform をインストールし、設定するための基本事項を説明します。設定、管理、およびロギングについても説明します。扱われるトピックを参照し、OpenShift Container Platform 環境の迅速な設定および組織のニーズに基づく設定に必要な一度だけ実行するタスク (one-time task) を実行してください。
日常的なクラスターの管理タスクについては、『Cluster Administration』を参照してください。
第2章 クラスターのインストール
2.1. 計画
2.1.1. 初期計画
実稼働環境の場合には、インストールの際にいくつかの要素を考慮に入れる必要があります。本書を読み進める上で、以下の質問を考慮してください。
- どのインストール方式を使用するか? 「インストール方式」セクションでは、クイックインストール方式と通常インストール (Advanced installation) 方式について説明します。
- クラスターに必要な Pod の数はどの程度か? 「サイジングに関する考慮事項」セクションでは、ノードおよび Pod の制限について説明します。これらの制限に基づいて、必要な環境のサイズを計算できます。
- クラスターに必要なホストの数はどの程度か? 「環境シナリオ」セクションでは、単一マスターおよび複数マスターの複数の設定例について説明します。
- 高可用性 は必要か? フォールトトレランスを可能にするための高可用性の使用が推奨されています。この場合、ご使用の環境のベースとして ネイティブの高可用性 (HA) を使用する複数マスターサンプルの使用を検討されるかもしれません。
- どのインストールタイプを使用するか? RPM またはコンテナー化? いずれのインストールも、作業用の OpenShift Container Platform 環境を提供しますが、サービスをインストールし、管理し、更新するために使用する上で、優先する方法があるかもしれません。
- 認証にどのアイデンティティープロバイダーを使用するか?サポートされているアイデンティティープロバイダーをすでに使用している場合は、 通常インストール (Advanced installation)の実行時にそのアイデンティティープロバイダーを使用するよう OpenShift Container Platform を設定することを推奨します。
- 他のテクノロジーとの統合の際に使用するインストールはサポートされるか? テスト済みの統合テクノロジーの一覧は、「OpenShift Container Platform Tested Integrations」を参照してください。
2.1.2. インストール方式
OpenShift Container Platform 3.9 の時点で、クイックインストールは廃止予定です。今後のリリースでは完全になくなります。また、クイックインストーラーによるバージョン 3.7 から 3.9 へのアップグレードはサポートされていません。
クイックインストールと通常インストール (Advanced installation) 方式は、開発環境と実稼働環境でサポートされます。初回のトライアル用に OpenShift Container Platform を迅速に稼働する必要がある場合は、クイックインクストーラーを使用し、ご使用の環境に関連する設定オプションを説明する対話型の CLI を使用できます。
ほとんどの場合、クラスター設定の制御には通常インストール (Advanced installation) 方式を使用することができます。この方式は、Ansible をすでに使い慣れている場合にとくに適しています。ただし、OpenShift Container Platform ドキュメントと共に以下の情報をご利用いただくことで、Ansible Playbook を直接使用してクラスターを信頼できる方法でデプロイし、その設定のデプロイ後の管理を行うのに必要な十分な情報が整います。
初期インストールでクイックインストーラーを使用する場合も、クラスターの設定をいつでも調整し、同じインストーラーツールを使用してクラスター内のホスト数を調整することができます。後に通常インストール (Advanced installation) 方式の使用に切り換える必要がある場合も、設定のインベントリーファイルを作成してからそのまま続行することが可能です。
2.1.3. サイジングに関する考慮事項
OpenShift Container Platform クラスターに必要なノードと Pod の数を判別します。クラスターの拡張性はクラスター環境内の Pod の数に相関します。この数は、セットアップの他の数に影響を及ぼします。OpenShift Container Platform のオブジェクトの制限についての最新情報は、「クラスターの制限」を参照してください。
2.1.4. 環境シナリオ
本セクションでは、OpenShift Container Platform 環境の複数の異なるシナリオ例について説明します。これらのシナリオは、実際のサイジングに必要に応じて独自の OpenShift Container Platform クラスターを計画する際のベースとして使用してください。
インストール後の単一マスタークラスターから複数マスターへの移行はサポートされていません。
ラベルの更新に関する情報については、「ノードのラベルの更新」を参照してください。
2.1.4.1. 1 つのシステムの単一マスターおよびノード
OpenShift Container Platform は開発環境の単一システムでのみインストールできます。オールインワン環境は実稼働環境として見なされません。
2.1.4.2. 単一マスターおよび複数ノード
以下の表では、単一マスター (etcd が同じホストにインストールされている) および 2 つのノードのサンプル環境について説明しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master.example.com |
マスター、etcd、ノード |
|
node1.example.com |
ノード |
|
node2.example.com |
2.1.4.3. 単一マスター、複数 etcd、および複数ノード
以下の表では、単一マスター、3 つの etcd ホスト、および 2 つのノードのサンプル環境について説明しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master.example.com |
マスターおよびノード |
|
etcd1.example.com |
etcd |
|
etcd2.example.com | |
|
etcd3.example.com | |
|
node1.example.com |
ノード |
|
node2.example.com |
2.1.4.4. 同一の場所に配置されたクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター
以下では、ネイティブ HA メソッドを使用する、同一の場所に配置されたクラスター化された etcd を含む 3 つのマスター、1 つの HAProxy ロードバランサー、 2 つのノードのサンプル環境を説明しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master1.example.com |
マスター (クラスター化、ネイティブ HA を使用) およびノードおよびクラスター化された etcd |
|
master2.example.com | |
|
master3.example.com | |
|
lb.example.com |
API マスターエンドポイントの負荷分散を行う HAProxy |
|
node1.example.com |
ノード |
|
node2.example.com |
2.1.4.5. 外部のクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター
以下では、ネイティブ HA メソッドを使用する、3 つの マスター、1 つの HAProxy ロードバランサー、3 つの外部のクラスター化された etcd ホスト、 2 つのノードのサンプル環境を説明しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master1.example.com |
マスター (クラスター化、ネイティブ HA を使用) およびノード |
|
master2.example.com | |
|
master3.example.com | |
|
lb.example.com |
API マスターエンドポイントの負荷分散を行う HAProxy |
|
etcd1.example.com |
クラスター化された etcd |
|
etcd2.example.com | |
|
etcd3.example.com | |
|
node1.example.com |
ノード |
|
node2.example.com |
2.1.4.6. スタンドアロンレジストリー
OpenShift Container Platform は、OpenShift Container Platform の統合レジストリーを使用するスタンドアロンレジストリーとして機能するようにインストールすることもできます。このシナリオの詳細は、「スタンドアロンレジストリーのインストール」を参照してください。
2.1.5. RPM 対 コンテナー化
RPM インストールは、パッケージ管理経由ですべてのサービスをインストールし、サービスが同じユーザー空間で実行されるように設定します。コンテナーインストールは、コンテナーイメージを使用してサービスをインストールし、個別のコンテナーで別々のサービスを実行します。
コンテナー化したサービスの設定についての詳細は、「コンテナー化したホストでのインストール」のトピックを参照してください。
2.2. 前提条件
2.2.1. システム要件
以下のセクションでは、ハードウェアの仕様および OpenShift Container Platform 環境内のすべてのホストについてのシステムレベルの要件を示しています。
2.2.1.1. Red Hat サブスクリプション
まず、お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。
2.2.1.2. ハードウェアの最小要件
システムの要件はホストのタイプによって異なります。
| |
| |
|
外部 etcd ノード |
|
|
Ansible コントローラー |
Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。 |
/var/ ファイルシステムのサイジング要件を満たすには、デフォルト設定に変更を加える必要があります。インストール時またはインストール後にこの設定を行う方法については、「Managing Storage in Red Hat Enterprise Linux Atomic Host」を参照してください。
システムの一時ディレクトリーは、Python の標準ライブラリーにある tempfile モジュールで定義されるルールに基づいて決定されます。
OpenShift Container Platform は、x86_64 アーキテクチャー搭載のサーバーのみをサポートします。
コンテナーデーモンを実行する各システムにストレージを設定する必要があります。コンテナー化インストールの場合、マスターにストレージが必要です。また、デフォルトで Web コンソールがマスターのコンテナーで実行されますが、Web コンソールを実行するためにストレージがマスター上で必要になります。コンテナーはノードで実行されるため、ストレージは常にノード上で必要になります。ストレージのサイズは、ワークロード、コンテナーの数、実行されているコンテナーのサイズ、およびコンテナーのストレージ要件によって異なります。また、コンテナー化された etcd には設定済みのコンテナーストレージが必要です。
2.2.1.3. 実稼働環境レベルのハードウェア要件
テストまたはサンプル環境は最小要件で機能します。実稼働環境の場合、以下の推奨事項が適用されます。
- マスターホスト
- 外部 etcd を含む可用性の高い OpenShift Container Platform クラスターにおいて、マスターホストには、上記の表に記載の最小要件のほかに、1000 Pod に対して 1 CPU コアと 1.5 GB のメモリーが必要になります。したがって、2000 Pod で構成される OpenShift Container Platform クラスターのマスターホストの推奨されるサイズとして、2 CPU コアと 16 GB の RAM、および 2 CPU コアと 3 GB の RAM、つまり合計 4 CPU コアと 19 GB の RAM が最小要件として必要になります。
最低 3 つの etcd ホストと 1 つのロードバランサーが複数のマスターホスト間で必要になります。
パフォーマンスのガイダンスについては、「Recommended Practices for OpenShift Container Platform Master Hosts」を参照してください。
- ノードホスト
- ノードホストのサイズは、そのワークロードの予想されるサイズによって異なります。OpenShift Container Platform クラスターの管理者は、予想されるワークロードを計算し、オーバーヘッドの約 10 パーセントを追加する必要があります。実稼働環境の場合、ノードホストの障害が最大容量に影響を与えることがないよう、十分なリソースを割り当てるようにします。
詳しくは、「サイジングに関する考慮事項」と「Cluster Limits」を参照してください。
ノードでの物理リソースの過剰なサブスクライブは、Kubernetes スケジューラーが Pod の配置時に行うリソース保証に影響を与えます。メモリースワップを防ぐために取れる処置について確認してください。
2.2.1.4. Red Hat Gluster Storage ハードウェア要件
Container-Native Storage または Container-Ready Storage クラスターで使用されるノードは、ストレージノードとみなされます。ストレージノードは異なるクラスターグループに分けられますが、単一ノードは複数のグループに属することはできません。ストレージノードの各グループについては、以下が当てはまります。
- 1 グループあたり 3 つ以上のストレージノードが必要です。
各ストレージノードには 8 GB 以上の RAM が必要です。これにより、Red Hat Gluster Storage Pod、その他のアプリケーションおよび基礎となる OS を実行できます。
- 各 GlusterFS ボリュームはストレージクラスターにあるすべてのストレージノードのメモリー (約 30 MB) も消費します。RAM の合計量は、コンカレントボリュームがいくつ求められているか、またはいくつ予想されるかによって決める必要があります。
各ストレージノードには、現在のデータまたはメタデータを含まない 1 つ以上の raw ブロックデバイスが必要です。それらのブロックデバイス全体は GlusterFS ストレージで使用されます。以下が存在しないことを確認してください。
- パーティションテーブル (GPT または MSDOS)
- ファイルシステムまたは未処理のファイルシステムの署名
- 以前のボリュームグループの LVM2 署名および論理ボリューム
- LVM2 物理ボリュームの LVM2 メタデータ
不確かな場合には、
wipefs -a <device>で上記のすべてを消去する必要があります。
2 つのクラスター、つまりインフラストラクチャーアプリケーション (OpenShift Container レジストリーなど) のストレージ専用のクラスターと一般的なアプリケーションのストレージ専用のクラスターについて計画することをお勧めします。これには、合計で 6 つのストレージノードが必要となりますが、この設定は I/O およびボリューム作成のパフォーマンスへの潜在的な影響を回避するために推奨されます。
2.2.1.5. オプション: コアの使用についての設定
デフォルトで、OpenShift Container Platform マスターおよびノードは、それらが実行されるシステムで利用可能なすべてのコアを使用します。GOMAXPROCS 環境変数を設定することにより、OpenShift Container Platform で使用するコア数を選択することができます。GOMAXPROCS 環境変数の機能方法をはじめとする詳細については、Go Language ドキュメント を参照してください。
たとえば、以下を実行してからサーバーを起動し、OpenShift Container Platform が 1 つのコアでのみ実行されるようにします。
export GOMAXPROCS=1
# export GOMAXPROCS=12.2.1.6. SELinux
Security-Enhanced Linux (SELinux) をすべてのサーバーで有効にしてから OpenShift Container Platform をインストールする必要があります。そうでないと、インストーラーは失敗します。さらに、/etc/selinux/config ファイルで SELINUX=enforcing および SELINUXTYPE=targeted を設定します。
2.2.1.7. Red Hat Gluster Storage
GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。
yum install glusterfs-fuse
# yum install glusterfs-fuseこのパッケージはすべての RHEL システムにインストールされています。ただし、Red Hat Gluster Storage の最新バージョンにアップデートすることを推奨します。そのためには、以下の RPM リポジトリーを有効にする必要があります。
subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms
# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpmsglusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。
yum update glusterfs-fuse
# yum update glusterfs-fuseオプション: OverlayFS の使用
OverlayFS は、ファイルシステム上に別のファイルシステムを重ねる (オーバーレイする) ことができるユニオンファイルシステムです。
Red Hat Enterprise Linux 7.4 の時点で、OpenShift Container Platform 環境で OverlayFS を使用できるように設定するオプションがあります。古いバージョンの overlay ドライバーのほかにも、overlay2 グラフドライバーが完全にサポートされています。ただし、Red Hat では、速度と実装の単純さを考慮し、overlay ではなく overlay2 を使用することを推奨しています。
「Comparing the Overlay Versus Overlay2 Graph Drivers 」には、overlay および overlay2 ドライバーの詳細情報が記載されています。
Docker サービスの overlay2 グラフドライバーを有効化する方法については、Atomic Host ドキュメントの 「Overlay Graph Driver」セクションを参照してください。
2.2.1.8. セキュリティー警告
OpenShift Container Platform は、クラスター内のホストでコンテナーを実行し、ビルド操作やレジストリーサービスなど一部のケースでは特権付きコンテナーを使用して実行します。さらに、これらのコンテナーはホストの Docker daemon にアクセスし、docker build および docker push の操作を実行します。実質的に root アクセスが可能であるため、任意のイメージでの docker run 操作の実行については関連するセキュリティーリスクについてクラスター管理者が認識している必要があります。docker build の操作についてはとくに注意が必要です。
特定のビルドをノードに割り当てることで、対象のノードにしか、危害を加える可能性のあるコンテナーが公開されないように制限できます。これついては、『開発ガイド』の「特定のノードへのビルドの割り当て」のセクションを参照してください。クラスター管理者の場合は、『インストールと設定ガイド』の「グローバルビルドのデフォルト設定および上書きの設定」のセクションを参照してください。
「SCC (Security Context Constraints)」を使用して、Pod が実行可能なアクションおよび、アクセス可能な機能を制御できます。Dockerfile の USER で実行するイメージを有効にする方法は、「Managing Security Context Constraints」 (ユーザーには cluster-admin 権限が必要) を参照してください。
詳細は、以下の記事を参照してください。
2.2.2. 環境要件
以下のセクションでは、OpenShift Container Platform 設定を含む環境の要件を定義します。これには、ネットワークの考慮事項や Git リポジトリーのアクセス、ストレージおよびクラウドインフラストラクチャープロバイダーなどの外部サービスへのアクセスが含まれます。
2.2.2.1. DNS
OpenShift Container Platform では、完全に機能する DNS サーバーが環境になければなりません。この場合、DNS ソフトウェアを実行する別個のホストを使用することが適しており、これによりプラットフォームで実行されるホストおよびコンテナーに対して名前解決を実行することができます。
各ホストの /etc/hosts ファイルにエントリーを追加するだけでは不十分です。このファイルは、プラットフォームで実行されるコンテナーにはコピーされません。
OpenShift Container Platform の主要コンポーネントはコンテナーの内部で実行され、名前解決に以下のプロセスを使用します。
- デフォルトで、コンテナーはホストから DNS 設定ファイル (/etc/resolv.conf) を受信します。
-
次に OpenShift Container Platform は 1 つの DNS 値を Pod に追加します (ノードのネームサーバー値の上)。その値は、
dnsIPパラメーターによって /etc/origin/node/node-config.yaml ファイルに定義されます。このパラメーターは、ホストが dnsmasq を使用しているためにデフォルトではホストノードのアドレスに設定されます。 -
dnsIPパラメーターが node-config.yaml ファイルから省かれている場合、その値はデフォルトで kubernetes サービス IP になり、これは Pod の /etc/resolv.conf ファイルにおける最初のネームサーバーになります。
OpenShift Container Platform 3.2 の時点で、dnsmasq はすべてのマスターおよびノードで自動的に設定されます。Pod は DNS としてノードを使用し、ノードは要求を転送します。デフォルトで、dnsmasq はポート 53 をリッスンするようにノード上に設定されます。そのため、ノードはその他の種類の DNS アプリケーションを実行することができません。
NetworkManager はネットワークに自動的に接続するシステムの検出と設定を行うプログラムであり、dnsmasq を DNS IP アドレスで設定するためにノードで必要となります。
NM_CONTROLLED はデフォルトで yes に設定されます。NM_CONTROLLED が no に設定されている場合、NetworkManager のディスパッチスクリプトは関連する origin-upstream-dns.conf dnsmasq ファイルを作成せず、dnsmasq を手動で設定する必要があります。
同様に、ネットワークスクリプト (例: /etc/sysconfig/network-scripts/ifcfg-em1) で PEERDNS パラメーターが no に設定されている場合、dnsmasq ファイルは生成されず、Ansible のインストールは失敗します。PEERDNS 設定が yes に設定されていることを確認してください。
以下は DNS レコードのサンプルセットです。
master1 A 10.64.33.100 master2 A 10.64.33.103 node1 A 10.64.33.101 node2 A 10.64.33.102
master1 A 10.64.33.100
master2 A 10.64.33.103
node1 A 10.64.33.101
node2 A 10.64.33.102適切に機能する DNS 環境がない場合には、以下に関連する障害が発生します。
- Ansible ベースの参照スクリプトによる製品のインストール
- インフラストラクチャーコンテナー (レジストリー、ルーター) のデプロイ
- OpenShift Container Platform web コンソールへのアクセス (IP アドレスのみではアクセスできないため)
2.2.2.1.1. DNS を使用するようホストを設定する
環境内の各ホストが DNS サーバーのホスト名を解決するように設定されていることを確認します。ホストの DNS 解決の設定は、DHCP が有効にされているかどうかによって異なります。
- DHCP が無効にされている場合、ネットワークインターフェースを static (静的) に設定し、DNS ネームサーバーを NetworkManager に追加します。
DHCP が有効にされている場合、NetworkManager ディスパッチスクリプトは DHCP 設定に基づいて DNS を自動的に設定します。オプションとして、値を node-config.yaml ファイルの
dnsIPに追加し、Pod の resolv.conf ファイルを追加できます。次に 2 番目のネームサーバーがホストの 1 番目のネームサーバーによって定義されます。デフォルトでは、これはノードホストの IP アドレスになります。注記ほとんどの設定では、(Ansible の使用による) OpenShift Container Platform の拡張インストール時に
openshift_dns_ipオプションは設定しないでください。このオプションにより、dnsIPで設定されるデフォルト IP アドレスが上書きされるためです。代わりにインストーラーが各ノードを dnsmasq を使用し、要求を外部 DNS プロバイダーまたは SkyDNS (サービスと Pod の内部ホスト名のクラスター全体での DNS 解決を行うための内部 DNS サービス) に転送するよう設定できるようにします。
openshift_dns_ipオプションを設定する場合は、 最初に SkyDNS をクエリーする DNS IP か、SkyDNS サービスまたはエンドポイント IP (Kubernetes サービス IP) のいずれかに設定する必要があります。
ホストが DNS サーバーで解決できることを確認するには、以下を実行します。
/etc/resolv.conf の内容を確認します。
cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 10.64.33.1 nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh
$ cat /etc/resolv.conf # Generated by NetworkManager search example.com nameserver 10.64.33.1 # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、10.64.33.1 が DNS サーバーのアドレスです。
/etc/resolv.conf に一覧表示されている DNS サーバーが OpenShift Container Platform 環境のすべてのマスターおよびノードの IP アドレスに対してホスト名を解決できることをテストします。
dig <node_hostname> @<IP_address> +short
$ dig <node_hostname> @<IP_address> +shortCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
dig master.example.com @10.64.33.1 +short dig node1.example.com @10.64.33.1 +short
$ dig master.example.com @10.64.33.1 +short 10.64.33.100 $ dig node1.example.com @10.64.33.1 +short 10.64.33.101Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2.2.1.2. DNS ワイルドカードの設定
オプションとして、使用するルーターのワイルドカードを設定し、新規ルートが追加される際に DNS 設定を更新しなくてもよいようにします。
DNS ゾーンのワイルドカードは、最終的には OpenShift Container Platform ルーターの IP アドレスに解決される必要があります。
たとえば、有効期間 (TTL) の低い値が設定されていて、ルーターがデプロイされるホストのパブリック IP アドレスをポイントする cloudapps のワイルドカード DNS エントリーを作成します。
*.cloudapps.example.com. 300 IN A 192.168.133.2
*.cloudapps.example.com. 300 IN A 192.168.133.2
仮想マシンを参照するほとんどすべての場合に、ホスト名を使用する必要があり、使用するホスト名は、各ノードの hostname -f コマンドの出力と一致している必要があります。
各ノードホストの/etc/resolv.conf ファイルで、ワイルドカードエントリーを持つ DNS サーバーがネームサーバーとして一覧表示されていないこと、またはワイルドカードドメインが検索一覧に表示されていないことを確認してください。そうでない場合、OpenShift Container Platform が管理するコンテナーはホスト名を適切に解決できないことがあります。
2.2.2.2. ネットワークアクセス
共有ネットワークは、マスターとノードホスト間に存在する必要があります。通常インストール (Advanced installation) 方式を使用して高可用性のために複数のマスターを設定する計画をしている場合、インストールのプロセスで 仮想 IP (VIP) として設定される IP を選択する必要もあります。選択した IP はすべてのノード間でルーティングできる必要があり、FQDN を使用して設定する場合は、すべてのノード上で解決する必要があります。
2.2.2.2.1. NetworkManager
NetworkManager はネットワークに自動的に接続するシステムの検出と設定を行うプログラムであり、dnsmasq を DNS IP アドレスで設定するためにノードで必要となります。
NM_CONTROLLED はデフォルトで yes に設定されます。NM_CONTROLLED が no に設定されている場合、NetworkManager のディスパッチスクリプトは関連する origin-upstream-dns.conf dnsmasq ファイルを作成せず、dnsmasq を手動で設定する必要があります。
2.2.2.2.2. firewalld のファイアウォールとしての設定
デフォルトのファイアウォールは iptables ですが、新規のインストールには firewalld が推奨されます。 Ansible インベントリーファイル で os_firewall_use_firewalld=true を設定することで、firewalld を有効にすることができます。
[OSEv3:vars] os_firewall_use_firewalld=True
[OSEv3:vars]
os_firewall_use_firewalld=True
この変数を true に設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。
firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。
2.2.2.2.3. 必要なポート
OpenShift Container Platform のインストールは、iptables を使用して各ホストに内部のファイアウォールルール一式を自動的に作成します。ただし、ネットワーク設定でハードウェアベースのファイアウォールなどの外部ファイアウォールを使用する場合、インフラストラクチャーコンポーネントが、特定のプロセスまたはサービスの通信エンドポイントとして機能する特定ポートで相互に通信できることを確認する必要があります。
OpenShift Container Platform で必要な以下のポートがネットワーク上で開いており、ホスト間のアクセスを許可するよう設定されていることを確認してください。設定や使用状況によって、一部はポートはオプションになります。
|
4789 |
UDP |
別個のホストの Pod 間の SDN 通信に必要です。 |
|
53 または 8053 |
TCP/UDP |
クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。 |
|
4789 |
UDP |
別個のホストの Pod 間の SDN 通信に必要です。 |
|
443 または 8443 |
TCP |
ノードホストがマスター API と通信するために必要です。ノードホストがステータスをポストバックしたり、タスクを受信したりする際に使用します。 |
|
4789 |
UDP |
別個のホストの Pod 間の SDN 通信に必要です。 |
|
10250 |
TCP |
マスターは、 |
|
10010 |
TCP |
CRI-O を使用している場合は、このポートを開き、 |
|
53 または 8053 |
TCP/UDP |
クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。 |
|
2049 |
TCP/UDP |
NFS ホストをインストーラーの一部としてプロビジョニングする場合に必要です。 |
|
2379 |
TCP |
スタンドアロン etcd (クラスター化) が状態の変更を受け取るために使用されます。 |
|
2380 |
TCP |
etcd はスタンドアロン etcd (クラスター化) を使用する場合、リーダー選定とピアリング接続のためにこのポートがマスター間で開かれていることを要求します。 |
|
4789 |
UDP |
別個のホストの Pod 間の SDN 通信に必要です。 |
|
9000 |
TCP |
|
|
443 または 8443 |
TCP |
ノードホストがマスター API と通信するために必要です。ノードホストがステータスをポストバックしたり、タスクを受信したりする際に使用します。 |
|
8444 |
TCP |
|
|
22 |
TCP |
インストーラーまたはシステム管理者が SSH で必要とします。 |
|
53 または 8053 |
TCP/UDP |
クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。マスターホストの内部で開かれている必要があります。 |
|
80 または 443 |
TCP |
ルーターの HTTP/HTTPS 用です。ノードホスト、とくにルーターを実行しているノードで外部に開かれている必要があります。 |
|
1936 |
TCP |
(オプション) テンプレートルーターを実行して統計にアクセスする際に開かれている必要があります。統計をどのように公開する必要があるかによって、接続に対して外部または内部に開くことができます。この場合、追加の設定が必要になることがあります。詳しくは、以下の「注記」セクションを参照してください。 |
|
2379 および 2380 |
TCP |
スタンドアロン etcd 用です。マスターホストの内部で開かれている必要があります。2379 はサーバークライアント接続用です。2380 はサーバー間の接続用で、クラスター化された etcd がある場合にのみ必要となります。 |
|
4789 |
UDP |
VxLAN 用 (OpenShift SDN) です。ノードホストの内部で開かれている必要があります。 |
|
8443 |
TCP |
OpenShift Container Platform Web コンソール用で、API サーバーと共有します。 |
|
10250 |
TCP |
Kubelet 用です。ノード上で外部に開かれている必要があります。 |
注記
- 上記の例では、ポート 4789 は UDP (User Datagram Protocol) に使用されます。
- デプロイメントで SDN を使用している場合、レジストリーがデプロイされているのと同じノードからレジストリーにアクセスしているのでない限り、 Pod のネットワークはサービスプロキシー経由でアクセスされます。
-
OpenShift Container Platform の内部 DNS は SDN 経由で受け取ることができません。
openshift_factsの検出される値に応じて、またはopenshift_ipおよびopenshift_public_ip値が上書きされている場合、openshift_ipの計算された値が使用されます。非クラウドデプロイメントの場合、これはデフォルトで、マスターホストのデフォルトルートに関連付けられた IP アドレスになります。クラウドデプロイメントの場合は、デフォルトで、クラウドメタデータで定義される最初の内部インターフェースに関連付けられた IP アドレスになります。 -
マスターホストはポート 10250 を使用してノードに到達し、SDN を経由しません。デプロイメントのターゲットホストによって異なりますが、
openshift_hostnameおよびopenshift_public_hostnameの計算された値を使用します。 iptables ルールにより、ポート 1936 はアクセス不可能な状態になります。ポート 1936 を開くよう iptables を設定するには以下を使用してください。
iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp \ --dport 1936 -j ACCEPT# iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp \ --dport 1936 -j ACCEPTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
|
9200 |
TCP |
Elasticsearch API 用です。Kibana が表示用にログを取得できるようにインフラストラクチャーノードの内部で開かれている必要があります。ルートを使用して Elasticsearch に直接アクセスできるよう外部に開くこともできます。ルートは |
|
9300 |
TCP |
Elasticsearch のクラスター内での使用向けです。Elasticsearch クラスターのメンバーが相互に通信できるようにインフラストラクチャーノードで内部に開かれている必要があります。 |
2.2.2.3. 永続ストレージ
Kubernetes の永続ボリュームフレームワークにより、お使いの環境で利用可能なネットワークストレージを使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これは、アプリケーションのニーズに応じて初回 OpenShift Container Platform インストールの完了後に行うことができ、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。
『インストールと設定ガイド』には、NFS, GlusterFS、Ceph RBD、OpenStack Cinder、AWS Elastic Block Store (EBS)、GCE Persistent Disks、iSCSI を使用して OpenShift Container Platform クラスターに永続ストレージをプロビジョニングするためのクラスター管理者の手順を記載しています。
2.2.2.4. クラウドプロバイダーの留意事項
OpenShift Container Platform をクラウドプロバイダーにインストールする場合に考慮すべき事柄がいくつかあります。
- Amazon Web Services の場合は、「Permissions」および「Configuring a Security Group」のセクションを参照してください。
- OpenStack の場合は、「Permissions」および「Configuring a Security Group」のセクションを参照してください。
2.2.2.4.1. 検出された IP アドレスとホスト名の上書き
一部のデプロイメントでは、ユーザーがホストの検出されたホスト名と IP アドレスを上書きすることが必要です。デフォルト値を確認するには、openshift_facts Playbook を実行します。
ansible-playbook [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/byo/openshift_facts.yml
# ansible-playbook [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/byo/openshift_facts.ymlAmazon Web Services の場合は、「検出された IP アドレスとホスト名の上書き」のセクションを参照してください。
検出された共通の設定を確認してみましょう。それらが想定される内容と異なる場合にはそれらを上書きすることができます。
「通常インストール (Advanced installation)」トピックでは、利用可能な Ansible 変数を詳しく説明します。
| 変数 | 使用法 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
openshift_hostname がメタデータで提供される private-dns-name 値以外の値に設定される場合、それらのプロバイダーのネイティブクラウド統合は機能しなくなります。
2.2.2.4.2. クラウドプロバイダーのインストール後の設定
インストールプロセスの後に、AWS、OpenStack、または GCE 用に OpenShift Container Platform を設定することができます。
2.3. ホストの準備
2.3.1. PATH の設定
各ホストの root ユーザーの PATH には以下のディレクトリーが含まれている必要があります。
- /bin
- /sbin
- /usr/bin
- /usr/sbin
これらすべてはデフォルトで新規の RHEL 7.x インストールに含まれています。
2.3.2. オペレーティングシステムの要件
7.3、7.4、7.5 のベースインストール (Extras チャンネルの最新パッケージを含む) または RHEL Atomic Host 7.4.2 以降が、マスターおよびノードホストに必要となります。各インストール手順については、以下のドキュメントを参照してください。
2.3.3. ホスト登録
各ホストは Red Hat サブスクリプションマネージャー (RHSM) を使用して登録されており、必要なパッケージにアクセスできるようアクティブな OpenShift Container Platform サブスクリプションがアタッチされている必要があります。
各ホストで RHSM に登録します。
subscription-manager register --username=<user_name> --password=<password>
# subscription-manager register --username=<user_name> --password=<password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHSM から最新サブスクリプションデータをプルします。
subscription-manager refresh
# subscription-manager refreshCopy to Clipboard Copied! Toggle word wrap Toggle overflow 利用可能なサブスクリプションの一覧を表示します。
subscription-manager list --available --matches '*OpenShift*'
# subscription-manager list --available --matches '*OpenShift*'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。
subscription-manager attach --pool=<pool_id>
# subscription-manager attach --pool=<pool_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Yum リポジトリーをすべて無効にします。
有効にされている RHSM リポジトリーをすべて無効にします。
subscription-manager repos --disable="*"
# subscription-manager repos --disable="*"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りの Yum リポジトリーを一覧表示し、
repo idにあるそれらの名前をメモします (ある場合) 。yum repolist
# yum repolistCopy to Clipboard Copied! Toggle word wrap Toggle overflow yum-config-managerを使用して、残りの Yum リポジトリーを無効にします。yum-config-manager --disable <repo_id>
# yum-config-manager --disable <repo_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、すべてのリポジトリーを無効にします。
yum-config-manager --disable \*
yum-config-manager --disable \*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。
OpenShift Container Platform 3.9 で必要なリポジトリーのみを有効にします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記rhel-7-server-ansible-2.4-rpms リポジトリーの追加は、OpenShift Container Platform 3.9 時点での新たな要件です。
2.3.4. 基本パッケージのインストール
作業用のインベントリーファイルの準備ができたら、/usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml を使用し、デフォルト設定でコンテナーランタイムをインストールすることができます。コンテナーランタイムにカスタマイズが必要な場合には、本トピックのガイダンスに従ってください。
RHEL 7 システムの場合:
以下の基本パッケージをインストールします。
yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
# yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacctCopy to Clipboard Copied! Toggle word wrap Toggle overflow システムを最新パッケージに更新します。
yum update systemctl reboot
# yum update # systemctl rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow RPM ベースのインストーラーを使用して通常インストール (Advanced installation) を実行することを計画している場合は、この手順を省略できます。ただし、 コンテナー化されたインストーラーの使用を計画している場合は、以下を実行します。
atomic パッケージをインストールします。
yum install atomic
# yum install atomicCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Docker のインストール に進みます。
RPM ベースの OpenShift Container Platform インストーラーユーティリティーを提供する以下のパッケージをインストールし、Ansible および関連する設定ファイルなどの クイックおよび通常インストール (Advanced installation)方式で必要となる他のツールをプルします。
yum install atomic-openshift-utils
# yum install atomic-openshift-utilsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
RHEL Atomic Host 7 システムの場合:
最新の Atomic ツリーにアップグレードしてホストが最新の状態にあることを確認します (利用可能な場合)。
atomic host upgrade
# atomic host upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow アップグレードが完了し、以下の起動の準備ができたら、ホストを再起動します。
systemctl reboot
# systemctl rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.5. Docker のインストール
ここで、すべてのマスターおよびノードホストで Docker をインストールする必要があります。これにより、OpenShift Container Platform をインストールする前に Docker ストレージオプションを設定することができます。
RHEL 7 システムの場合は、Docker 1.13 をインストールします。
RHEL Atomic Host 7 システムには、Docker がデフォルトでインストールされ、設定され、実行されている必要があります。
yum install docker-1.13.1
# yum install docker-1.13.1パッケージのインストールが完了したら、バージョン 1.13 がインストールされていることを確認します。
rpm -V docker-1.13.1 docker version
# rpm -V docker-1.13.1
# docker version通常インストール (Advanced installation)方式は /etc/sysconfig/docker を自動的に変更します。
2.3.6. Docker ストレージの設定
作成元のコンテナーとイメージは Docker のストレージバックエンドに保存されます。このストレージは一時的なストレージであり、アプリケーションの必要を満たすために割り当てられる 永続ストレージ とは区別されます。一時ストレージ の場合、コンテナーに保存されるデータはコンテナーが削除されると失われます。永続ストレージ の場合、コンテナーに保存されるデータはコンテナーが削除されてもそのまま残ります。
コンテナーデーモンを実行する各システムにストレージを設定する必要があります。コンテナー化インストールの場合、マスターにストレージが必要です。また、デフォルトで Web コンソールがマスターのコンテナーで実行されますが、Web コンソールを実行するためにストレージがマスター上で必要になります。コンテナーはノードで実行されるため、ストレージは常にノード上で必要になります。ストレージのサイズは、ワークロード、コンテナーの数、実行されているコンテナーのサイズ、およびコンテナーのストレージ要件によって異なります。また、コンテナー化された etcd には設定済みのコンテナーストレージが必要です。
作業用のインベントリーファイルの準備ができたら、/usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml を使用し、デフォルト設定でコンテナーランタイムをインストールすることができます。コンテナーランタイムにカスタマイズが必要な場合には、本トピックのガイダンスに従ってください。
RHEL Atomic Host の場合
RHEL Atomic Host の Docker のデフォルトストレージバックエンドはシンプール論理ボリュームで、実稼働環境でサポートされています。システム要件にある Docker ストレージ要件に対して、このボリュームに十分なスペースが割り当てられていることを確認する必要があります。
十分なスペースが割り当てられていない場合、docker-storage-setup の使用と RHEL Atomic Host におけるストレージ管理の基本手順については、「Managing Storage with Docker Formatted Containers」を参照してください。
Red Hat Enterprise Linux の場合:
RHEL 7 の Docker のデフォルトストレージバックエンドは、ループバックデバイスにあるシンプールです。これは実稼働環境でサポートされておらず、概念実証向けの環境のみに適しています。実稼働環境の場合、シンプール論理ボリュームを作成し、Docker をそのボリュームを使用するよう再設定する必要があります。
Docker はグラフドライバーにイメージとコンテナーを保存します。グラフドライバーは DeviceMapper、OverlayFS、Btrfs などのプラグ可能なストレージ技術です。これらにはそれぞれメリットとデメリットがあります。たとえば、OverlayFS のコンテナーを起動し、停止するスピードは DeviceMapper よりも速いですが、Overlay FS はユニオンファイルシステムのアーキテクチャー上の制限により Portable Operating System Interface for Unix (POSIX) に準拠しておらず、Red Hat Enterprise Linux 7.2 よりも前のバージョンではサポートされていません。お使いの RHEL バージョンで OverlayFS を使用する方法についての情報は Red Hat Enterprise Linux リリースノートを参照してください。
DeviceMapper と OverlayFS のメリットと制限に関する情報は、「Choosing a Graph Driver」を参照してください。
2.3.6.1. OverlayFS の設定
OverlayFS はユニオンファイルシステムの一種です。これにより、あるファイルシステムを別のファイルシステムに重ねる (オーバーレイする) ことができます。上位のファイルシステムで変更が記録されても、下位のファイルシステムは変更されません。
「Comparing the Overlay Versus Overlay2 Graph Drivers 」には、overlay および overlay2 ドライバーの詳細情報が記載されています。
Docker サービスの OverlayFS ストレージドライバーの有効化については、Red Hat Enterprise Linux Atomic Host ドキュメントを参照してください。
2.3.6.2. シンプールストレージの設定
Docker に含まれる docker-storage-setup スクリプトを使用してシンプールデバイスを作成し、Docker ストレージドライバーを設定できます。これは Docker のインストール後に実行でき、イメージまたはコンテナーの作成前に実行する必要があります。このスクリプトは /etc/sysconfig/docker-storage-setup ファイルから設定オプションを読み取り、論理ボリュームを作成するための 3 つのオプションをサポートします。
- オプション A: 追加のブロックデバイスを使用する。
- オプション B: 既存の指定されたボリュームグループを使用する。
- オプション C: root ファイルシステムが置かれている残りのボリュームグループの空きスペースを使用する。
オプション A は最も信頼性の高いオプションですが、この場合 Docker ストレージを設定する前にブロックデバイスをホストに追加する必要があります。オプション B と C はどちらもホストのプロビジョニング時に利用可能な空きスペースを残しておく必要があります。オプション C は、Red Hat Mobile Application Platform (RHMAP) などの一部のアプリケーションで問題が発生することが確認されています。
以下の 3 つのオプションのいずれかを使用して docker-pool ボリュームを作成します。
オプション A: 追加のブロックデバイスを使用する。
/etc/sysconfig/docker-storage-setup で、使用するブロックデバイスのパスに DEVS を設定します。作成するボリュームグループ名に VG を設定します。docker-vg は適切なオプションになります。以下は例になります。
cat <<EOF > /etc/sysconfig/docker-storage-setup DEVS=/dev/vdc VG=docker-vg EOF
# cat <<EOF > /etc/sysconfig/docker-storage-setup DEVS=/dev/vdc VG=docker-vg EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション B: 既存の指定されたボリュームグループを使用する。
/etc/sysconfig/docker-storage-setup で、VG を必要なボリュームグループに設定します。以下は例になります。
cat <<EOF > /etc/sysconfig/docker-storage-setup VG=docker-vg EOF
# cat <<EOF > /etc/sysconfig/docker-storage-setup VG=docker-vg EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプション C: root ファイルシステムが置かれているボリュームグループの残りの空きスペースを使用する。
root ファイルシステムが置かれているボリュームグループに必要な空きスペースがあることを確認してから、docker-storage-setup を実行して、出力で docker-pool ボリュームが作成されていることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
設定を確認します。/etc/sysconfig/docker-storage ファイルに dm.thinpooldev 値と docker-pool 論理ボリュームが含まれている必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Docker または OpenShift Container Platform を使用する前に、docker-pool 論理ボリュームが要求を満たす程度のサイズであることを確認します。docker-pool ボリュームは利用可能なボリュームグループの 60% である必要があり、これは LVM モニタリングによって拡張し、ボリュームグループを埋めていきます。
Docker がホストでまだ起動されていない場合は、サービスを有効にしてから起動し、それが実行されていることを確認します。
systemctl enable docker systemctl start docker systemctl is-active docker
# systemctl enable docker # systemctl start docker # systemctl is-active dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Docker がすでに実行されている場合は、Docker を再初期化します。
警告これは現在ホストにあるコンテナーまたはイメージを破棄します。
systemctl stop docker rm -rf /var/lib/docker/* systemctl restart docker
# systemctl stop docker # rm -rf /var/lib/docker/* # systemctl restart dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow /var/lib/docker/ にコンテンツがある場合、これを削除する必要があります。OpenShift Container Platform のインストール前に Docker が使用されていた場合にはファイルが存在します。
2.3.6.3. Docker ストレージの再設定
docker-pool を作成した後に Docker ストレージを再設定する必要がある場合は、まず docker-pool 論理ボリュームを削除する必要があります。専用のボリュームグループを使用している場合は、上記の手順に従って、docker-storage-setup を再設定する前にそのボリュームグループと関連する物理ボリュームを削除する必要もあります。
LVM 管理の詳細は、「論理ボリュームマネージャー管理」を参照してください。
2.3.6.4. イメージ署名サポートの有効化
OpenShift Container Platform は、イメージが信頼済みのソースのものかを暗号で確認することができます。『Container Security Guide』には、イメージ署名の仕組みの概要が記載されています。
atomic コマンドラインインターフェース (CLI) (バージョン 1.12.5 以降) を使用してイメージ署名の検証を設定できます。atomic CLI は RHEL Atomic Host システムにプリインストールされています。
atomic CLI の詳細は、Atomic CLI についてのドキュメントを参照してください。
ホストシステムにインストールされていない場合は、atomic パッケージをインストールします。
yum install atomic
$ yum install atomicatomic trust サブコマンドは信頼設定を管理します。デフォルトの設定では、すべてのレジストリーをホワイトリストに入れます。これは、署名の検証が設定されていないことを意味します。
atomic trust show
$ atomic trust show
* (default) accept適切な設定として、特定のレジストリーまたは namespace をホワイトリストに入れ、信頼されていないレジストリーはブラックリストに入れ (拒否)、ベンダーレジストリーで署名検証が必要になるようにします。以下のコマンドセットは、この設定例を実行します。
Atomic の信頼の設定例
署名されたすべてのソースが検証される場合、グローバルの reject デフォルトによりノードをさらに強化できます。
追加の例として atomic man ページの man atomic-trust を使用します。
以下のファイルとディレクトリーは、ホストの信頼設定を構成しています。
- /etc/containers/registries.d/*
- /etc/containers/policy.json
信頼設定は、各ノードまたは個別のホストで管理される生成ファイル上で直接管理でき、 Ansible などを使用して適切なノードに配布できます。Ansible を使用したファイル配布の自動化の例については、『Container Image Signing Integration Guide』を参照してください。
2.3.6.5. コンテナーログの管理
コンテナーのログファイル (コンテナーが実行されているノード上の /var/lib/docker/containers/<hash>/<hash>-json.log ファイル) が問題を生じさせかねないサイズに拡張してしまうことがあります。これは、Docker の json-file ロギングドライバーを設定し、ログファイルのサイズと数を制限して管理できます。
| オプション | 目的 |
|---|---|
|
|
作成される新規ログファイルのサイズを設定します。 |
|
|
ホストごとに保持するログファイルの最大数を設定します。 |
たとえば、最大ファイルサイズを 1MB に設定し、最新の 3 つのログファイルを保持するには、/etc/sysconfig/docker ファイルを編集して、max-size=1M と max-file=3 を設定します。
OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=1M --log-opt max-file=3'
OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=1M --log-opt max-file=3'次に Docker サービスを再起動します。
systemctl restart docker
# systemctl restart docker2.3.6.6. 利用可能なコンテナーログの表示
コンテナーログは、コンテナーが実行されているノードの /var/lib/docker/containers/<hash>/ ディレクトリーに保存されます。以下は例になります。
ロギングドライバーの設定方法に関する詳細は、Docker ドキュメントを参照してください。
2.3.6.7. ローカルボリュームの使用サポート
ボリュームのプロビジョニングが Dockerfile の VOLUME 指示または docker run -v <volumename> コマンドを使用して実行されると、ホストのストレージ領域が使用されます。このストレージを使用すると、予期しない領域不足の問題が生じ、ホストが停止する可能性があります。
OpenShift Container Platform では、独自のイメージを実行しようとするユーザーには、ノードホストのストレージ領域全体が一杯になるリスクがあります。この問題に対する 1 つの解決策として、ユーザーがボリュームを持つイメージを実行できないようにする方法があります。これにより、ユーザーがアクセスできるストレージのみを制限し、クラスター管理者はストレージのクォータを割り当てることができます。
docker-novolume-plugin を使用して、ローカルボリュームが定義されたコンテナーの起動を禁止することにより、この問題を解決することができます。とくに、このプラグインは以下を含む docker run コマンドをブロックします。
-
--volumes-fromオプション -
VOLUMEが定義されたイメージ -
docker volumeコマンドを使ってプロビジョニングされた既存ボリュームの参照
プラグインはバインドマウントへの参照をブロックしません。
docker-novolume-plugin を有効にするには、各ノードホストで以下の手順を実行します。
docker-novolume-plugin パッケージをインストールします。
yum install docker-novolume-plugin
$ yum install docker-novolume-pluginCopy to Clipboard Copied! Toggle word wrap Toggle overflow docker-novolume-plugin サービスを有効にし、起動します。
systemctl enable docker-novolume-plugin systemctl start docker-novolume-plugin
$ systemctl enable docker-novolume-plugin $ systemctl start docker-novolume-pluginCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/sysconfig/docker ファイルを編集し、以下を
OPTIONS一覧に追加します。--authorization-plugin=docker-novolume-plugin
--authorization-plugin=docker-novolume-pluginCopy to Clipboard Copied! Toggle word wrap Toggle overflow docker サービスを再起動します。
systemctl restart docker
$ systemctl restart dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
このプラグインを有効にした後に、ローカルボリュームが定義されたコンテナーは起動に失敗し、以下のエラーメッセージを表示します。
runContainer: API error (500): authorization denied by plugin docker-novolume-plugin: volumes are not allowed
runContainer: API error (500): authorization denied by plugin
docker-novolume-plugin: volumes are not allowed2.3.7. ホストアクセスの確保
クイックおよび通常インストール (advanced installation)方式では、すべてのホストにアクセスできるユーザーが必要になります。インストーラーを非 root ユーザーとして実行する場合は、それぞれの宛先ホストでパスワードレス sudo 権限を設定する必要があります。
たとえば、インストールプロセスを起動するホストで SSH キーを生成できます。
ssh-keygen
# ssh-keygenパスワードは使用しないでください。
SSH キーを配布する簡単な方法として、bash ループを使用できます。
設定に従って、上記コマンドのホスト名を変更します。
bash ループの実行後に、SSH でループに一覧表示されている各ホストにアクセスできます。
2.3.8. プロキシーの上書きの設定
ノードの /etc/environment ファイルに http_proxy または https_proxy 値のいずれかが含まれる場合、OpenShift Container Platform コンポーネント間でのオープンな通信を可能にするため、そのファイルに no_proxy 値を設定する必要もあります。
/etc/environment ファイルの no_proxy パラメーターは、インベントリーファイルに設定するグローバルプロキシー値と同じ値ではありません。グローバルプロキシー値では、プロキシーの設定を使って特定の OpenShift Container Platform サービスを設定します。詳細は、「グローバルプロキシーオプションの設定」を参照してください。
/etc/environment ファイルにプロキシー値が含まれる場合、以下の値を、各ノードでこのファイルの no_proxy パラメーターに以下の値を定義します。
- マスターおよびノードのホスト名またはそれらのドメインサフィックス。
- 他の内部ホスト名またはそれらのドメインサフィックス。
- etcd IP アドレス。etcd アクセスはアドレスで制御されるので、ホスト名ではなく IP アドレスを指定する必要があります。
-
Kubernetes IP アドレス (デフォルトは
172.30.0.1)。インベントリーファイルのopenshift_portal_netパラメーターに設定される値である必要があります。 -
Kubernetes の内部ドメインサフィックス:
cluster.local。 -
Kubernetes の内部ドメインサフィックス:
.svc
no_proxy は CIDR をサポートしないので、ドメインサフィックスを使用できます。
http_proxy または https_proxy 値のいずれかを使用する場合、 no_proxy パラメーターの値は以下の例のようになります。
no_proxy=.internal.example.com,10.0.0.1,10.0.0.2,10.0.0.3,.cluster.local,.svc,localhost,127.0.0.1,172.30.0.1
no_proxy=.internal.example.com,10.0.0.1,10.0.0.2,10.0.0.3,.cluster.local,.svc,localhost,127.0.0.1,172.30.0.12.3.9. 次のステップ
コンテナー化メソッドを使用して OpenShift Container Platform をインストールする場合は (RHEL の場合はオプションですが、RHEL Atomic Host では必須です)、 「コンテナー化ホストでのインストール 」を参照し、ホストを準備してください。
準備ができたら、クイックインストール または 通常インストール(advanced installation)方式を使用して OpenShift Container Platform をインストールできます。
OpenShift Container Platform 3.9 の時点で、クイックインストールは廃止予定です。今後のリリースでは完全になくなります。また、クイックインストーラーによるバージョン 3.7 から 3.9 へのアップグレードはサポートされていません。
スタンドアロンレジストリーをインストールする場合は、スタンドアロンレジストリーのインストール を続行します。
2.4. コンテナー化ホストでのインストール
2.4.1. RPM 対コンテナー化インストール
RPM またはコンテナー化パッケージ方法を使用した OpenShift Container Platform のインストールを選択できます。いずれのインストール方法も作業環境を生成しますが、選択はオペレーティングシステムやホストの更新方法によって異なります。
Red Hat Enterprise Linux (RHEL) での OpenShift Container Platform のインストールには、デフォルトで RPM を使用します。Red Hat Atomic Host システムをターゲットとしている場合、選択できるのはコンテナー化方法のみで、/run/ostree-booted ファイルの検出に基づいて自動的に選択されます。
RPM を使用する場合、すべてのサービスが外部ソースのパッケージ管理によってインストールされ、更新されます。これらは、同じユーザー空間内のホストの既存設定を変更します。コンテナー化インストールの場合は、OpenShift Container Platform の各コンポーネントはコンテナーとして同梱され (自己完結型パッケージ)、ホストのカーネルを利用して起動と実行を行います。更新された新しいコンテナーはホストの既存のものに置き換わります。どのインストール方法を選択するかは、OpenShift Container Platform の今後の更新方法によって異なるでしょう。
以下の表は、RPM とコンテナー化方法の違いをさらに示しています。
| RPM | コンテナー化 | |
|---|---|---|
|
インストール方法 |
|
|
|
サービス管理 |
|
|
|
オペレーティングシステム |
Red Hat Enterprise Linux |
Red Hat Enterprise Linux または Red Hat Atomic Host |
2.4.2. コンテナー化されたホストのインストール方法
RPM インストールと同様に、コンテナー化インストールでも クイック および 通常 (advanced)インストール方式のいずれかを選べます。
クイックインストール方式の場合、対話型インストール時にホストごとに RPM または コンテナー化方法を選択できます。または インストール設定ファイルで値を手動で設定することができます。
通常インストール (advanced installation) 方式の場合は、クラスター全体か、またはホストごとに インベントリーファイル で Ansible 変数 containerized=true を設定できます。
2.4.3. 必須イメージ
コンテナー化インストールでは以下のイメージを使用します。
- openshift3/ose
- openshift3/node
- openshift3/openvswitch
- registry.access.redhat.com/rhel7/etcd
デフォルトで、上記のイメージはすべて registry.access.redhat.com の Red Hat Registry からプルされます。
プライベートレジストリーを使用してインストール中にこれらのイメージをプルする必要がある場合は、あらかじめレジストリー情報を指定できます。通常インストール (advanced installation) 方式の場合は、必要に応じてインベントリーファイルで以下の Ansible 変数を設定できます。
openshift_docker_additional_registries=<registry_hostname> openshift_docker_insecure_registries=<registry_hostname> openshift_docker_blocked_registries=<registry_hostname>
openshift_docker_additional_registries=<registry_hostname>
openshift_docker_insecure_registries=<registry_hostname>
openshift_docker_blocked_registries=<registry_hostname>クイックインストール方式の場合、各ターゲットホストで以下の環境変数をエクスポートできます。
export OO_INSTALL_ADDITIONAL_REGISTRIES=<registry_hostname> export OO_INSTALL_INSECURE_REGISTRIES=<registry_hostname>
# export OO_INSTALL_ADDITIONAL_REGISTRIES=<registry_hostname>
# export OO_INSTALL_INSECURE_REGISTRIES=<registry_hostname>現在、ブロックされた Docker レジストリーはクイックインストール方式で指定することはできません。
安全でないブロックされた追加の Docker レジストリーの設定はインストールプロセスの開始時に行われ、必要なイメージをプルする前にそれらの設定が適用されるようにします。
2.4.4. コンテナーの起動と停止
インストールプロセスは、通常の systemctl コマンドを使用してサービスの起動、停止、ポーリングを実行するために使われる関連の systemd ユニットを作成します。コンテナー化インストールの場合、それらのユニット名は RPM インストールのものと一致します。ただし、etcd_container という名前の etcd を除きます。
これは、RHEL Atomic Host には現在オペレーティングシステムの一部としてインストールされる etcd パッケージが同梱されるために必要な変更と言えます。そのため、OpenShift Container Platform インストールにはコンテナー化バージョンが代わりに使用されます。このインストールプロセスではデフォルトの etcd サービスを無効にします。
etcd パッケージは今後 RHEL Atomic Host から削除される予定です。
2.4.5. ファイルパス
すべての OpenShift Container Platform 設定ファイルは、コンテナー化インストール時に RPM ベースのインストールの場合と同じ場所に置かれ、 os-treeアップグレード後も存続します。
ただし、デフォルトのイメージストリームおよびテンプレートファイルは、標準の /usr/share/openshift/examples/ がRHEL Atomic Host では読み取り専用であるため、そのディレクトリーにではなくコンテナー化インストールの /etc/origin/examples/ にインストールされます。
2.4.6. ストレージ要件
RHEL Atomic Host インストールが持つ root ファイルシステムは通常非常に小さいサイズです。ただし、etcd、マスター、ノードコンテナーは /var/lib/ ディレクトリーにデータを維持します。そのため、OpenShift Container Platform をインストールする前に root ファイルシステムに十分な空き領域があることを確認してください。詳細は「システム要件」のセクションを参照してください。
2.4.7. Open vSwitch SDN の初期化
OpenShift SDN の初期化では、Docker ブリッジが再設定され、Docker が再起動される必要があります。ノードがコンテナー内で実行されている場合には状況は複雑になります。Open vSwitch (OVS) SDN を使用すると、ノードが起動し、Docker が再設定されるので、Docker を再起動すると (すべてのコンテナーも再起動されます)、最終的に正常に起動します。
この場合、マスターサービスも Docker と一緒に再起動されるため、ノードサービスは起動に失敗し、数回再起動される場合があります。現在の実装では、Docker ベースの systemd ユニットの Restart=always パラメーター設定に依存する回避策を使用できます。
2.5. クイックインストール
2.5.1. 概要
OpenShift Container Platform 3.9 の時点では、クイックインストール方式は非推奨になっています。今後のリリースでは完全に削除される予定です。さらに、クイックインストーラーを使用したバージョン 3.7 から 3.9 へのアップグレードはサポートされていません。通常インストール (advanced installation) 方式は、新規インストールおよびクラスターのアップグレードにおいて今後もサポートされます。
クイックインストール 方式により、対話型 CLI ユーティリティーの atomic-openshift-installer コマンドを使用して一連のホストで OpenShift Container Platform をインストールできます。このインストーラーは、RPM をインストールするか、コンテナー化サービスを実行することによってターゲットのホストで OpenShift Container Platform コンポーネントをデプロイできます。
RHEL Atomic Host はコンテナー化された OpenShift Container Platform サービスを実行するためにサポートされており、インストーラーは RPM で提供されます ( RHEL Atomic Host でデフォルトで利用することができません)。したがって、これは Red Hat Enterprise Linux 7 システムから実行される必要があります。インストールを開始するホストは、OpenShift Container Platform クラスターに組み込む必要はありませんが、組み込むことは可能です。
このインストール方式は、各ホストで実行するのに必要なデータをインタラクティブに収集することでより簡単にインストールを行えるようにするために提供されています。このインストーラーは、Red Hat Enterprise Linux (RHEL) 7 システムでの使用を目的とする自己完結型のラッパーです。
対話型インストールを最初から実行するだけでなく、atomic-openshift-installer コマンドは事前定義されたインストール設定ファイルを使用して実行または再実行することもできます。このファイルは、以下を実行するためにインストーラーで使用できます。
- 無人インストールの実行
- 既存クラスターへのノードの追加
- クラスターのアップグレード
- OpenShift Container Platform クラスターの完全な再インストール
OpenShift Container Platform をスタンドアロンレジストリーとして インストールするには、「スタンドアロンレジストリーのインストール」を参照してください。
2.5.2. 作業を開始する前に
インストーラーを使用して、定義されたホストで OpenShift Container Platform のマスターおよびノードコンポーネントをインストールできます。
デフォルトで、インストールプロセス時にマスターとして指定するホストは自動的にノードとして設定され、マスターは OpenShift Container Platform SDN の一部として設定されます。
以下の関連する技術上の変更点については、OpenShift Container Platform 3.9 リリースノートを参照してください。
OpenShift Container Platform をインストールする前に、まずホストの前提条件を満たしている必要があります。これには、システムと環境要件を確認し、Docker を正常にインストールし、設定することが含まれます。また、インストール時にターゲットホストのそれぞれについて以下の情報を指定するか、または確認できるようにしておく必要があります。
- Ansible ベースのインストールを実行するターゲットホストのユーザー名 (root または非 root)
- ホスト名
- マスター、ノード、またはその両方のコンポーネントをインストールするかどうか
- RPM またはコンテナー化方法を使用するかどうか
- 内部および外部 IP アドレス
コンテナー化方法を使用して OpenShift Container Platform をインストールする (RHEL の場合はオプションですが、RHEL Atomic Host の場合は必須です) 場合は、「コンテナー化ホストでのインストール」トピックを参照して、これらの方法の違いを確認してから、このトピックに戻って続行してください。
「前提条件」のトピックの手順に従い、RPM またはコンテナー化方法のどちらにするかを決めて、対話型または無人インストールの実行を続けることができます。
2.5.3. 対話型インストールの実行
必ず「作業を開始する前に」をすべてお読みください。
以下を実行して、対話型インストールを開始できます。
atomic-openshift-installer install
$ atomic-openshift-installer install画面の手順に従って新規 OpenShift Container Platform クラスターをインストールします。
完了後に、作成される ~/.config/openshift/installer.cfg.yml インストール設定ファイル をバックアップします。このファイルは、後でインストールを再実行したり、ホストをクラスターに追加したり、クラスターをアップグレードしたりする場合に必要になります。次に インストールを検証します。
2.5.4. インストール設定ファイルの定義
インストーラーは、インストール、個別ホストおよびクラスターの情報が含まれる事前定義のインストールファイルを使用できます。対話型インストールを実行する際に、 回答に基づくインストール設定ファイルが ~/.config/openshift/installer.cfg.yml に作成されます。このファイルは、インストールを終了して手動で設定を変更することが求められる場合やインストールの完了時に作成されます。また、設定ファイルをゼロから手動で作成して無人インストールを実行することもできます。
インストール設定ファイルの仕様
- 1
- このインストール設定ファイルのバージョン。OpenShift Container Platform 3.3 の時点で、有効なバージョンは
v2のみです。 - 2
- インストールする OpenShift Container Platform バリアント。OpenShift Container Platform の場合、これを
openshift-enterpriseに設定します。 - 3
- 選択したバリアントの有効なバージョン:
3.9、3.7、3.6、3.5、3.4、3.3、3.2、3.1。指定しない場合、これはデフォルトで指定したバリアントの最新バージョンになります。 - 4
- Ansible ログが保存される場所を定義します。デフォルトで、これは /tmp/ansible.log ファイルになります。
- 5
- Ansible がファクトの収集やインストールのためにリモートシステムに SSH で入るために使用するユーザーを定義します。デフォルトで、これは root ユーザーになりますが、sudo 権限を持つどのユーザーにも設定できます。
- 6
- OpenShift Container Platform マスターおよびノードコンポーネントをインストールするホストの一覧を定義します。
- 7 8
- 必須。これにより、インストーラーはインストールに進む前にシステムに接続し、ファクトを収集できます。
- 9 10
- 無人インストールの場合は必須。これらの詳細を指定しない場合、この情報はインストーラーによって収集されるファクトからプルされ、詳細を確認するよう求められます。無人インストールについて定義されていない場合にインストールは失敗します。
- 11
- インストールされるサービスの種類を決定します。一覧として指定されます。
- 12
- true に設定すると、コンテナー化された OpenShift Container Platform サービスは RPM パッケージを使用してインストールされるのではなく、ターゲットのマスターおよびノードホストで実行されます。false に設定するか、未設定の場合は、デフォルトの RPM 方法が使用されます。RHEL Atomic Host にはコンテナー化方法が必要となり、これは/run/ostree-booted ファイルの検出に基づいて自動的に選択されます。詳細は、「コンテナー化ホストでのインストール」を参照してください。
- 13
- Ansible がシステムのインストール、アップグレードまたはアンインストール時に接続を試みる IP アドレス。設定ファイルが自動生成された場合、これは対話型インストールプロセス時に最初に入力するホストの値になります。
- 14
- ノードラベルはホストごとにオプションで設定できます。
- 15
- デプロイメント全体でのロールの辞書を定義します。
- 16 17
- ロールを割り当てられたホストにのみ適用する Ansible 変数を定義できます。具体例については、「Ansible の設定」を参照してください。
2.5.5. 無人インストールの実行
必ず「作業を開始する前に」をお読みください。
無人インストールでは、インストーラーの実行前にインストール設定ファイルでホストとクラスター設定を定義できるので、対話型インストールの質問と回答すべて確認する必要はありません。また、これによって完了していない状態の対話型インストールを再開でき、インストール作業を中断した場所に簡単に戻ることができます。
無人インストールを実行するには、まず ~/.config/openshift/installer.cfg.yml で インストール設定ファイルを定義します。次に、 -u フラグを指定してインストーラーを実行します。
atomic-openshift-installer -u install
$ atomic-openshift-installer -u install対話型または無人モードでは、インストーラーはデフォルトで ~/.config/openshift/installer.cfg.yml にある設定ファイルを使用します (ある場合)。ファイルが存在しない場合は、無人インストールを開始できません。
または、-c オプションを使用して設定ファイルの別の場所を指定できますが、これを実行するには、インストールを実行するたびにファイルの場所を指定する必要があります。
atomic-openshift-installer -u -c </path/to/file> install
$ atomic-openshift-installer -u -c </path/to/file> install無人インストールの完了後、使用された ~/.config/openshift/installer.cfg.yml ファイルをバックアップします。これは、インストールを後で再実行したり、ホストをクラスターに追加したり、クラスターをアップグレードしたりする場合に必要になります。次に インストールを検証します。
2.5.6. インストールの検証
マスターが起動しており、ノードが登録されており、Ready ステータスで報告されていることを確認します。マスターホストで 以下を root で実行します。
oc get nodes
# oc get nodes NAME STATUS ROLES AGE VERSION master.example.com Ready master 7h v1.9.1+a0ce1bc657 node1.example.com Ready compute 7h v1.9.1+a0ce1bc657 node2.example.com Ready compute 7h v1.9.1+a0ce1bc657Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web コンソールが正常にインストールされているか確認するには、マスターホスト名と Web コンソールのポート番号を使用して Web ブラウザーで Web コンソールにアクセスします。
たとえば、ホスト名が
master.openshift.comで、デフォルトポート8443を使用するマスターホストの場合、Web コンソールはhttps://master.openshift.com:8443/consoleにあります。- 次に、OpenShift Container Platform クラスターを設定する次の手順について「次のステップ」を確認します。
2.5.7. OpenShift Container Platform のアンインストール
インストーラーの uninstall コマンドを使用してクラスターのすべてのホストから OpenShift Container Platform をアンインストールできます。デフォルトで、インストーラーは ~/.config/openshift/installer.cfg.yml にあるインストール設定ファイルを使用します (ある場合)。
atomic-openshift-installer uninstall
$ atomic-openshift-installer uninstall
または、-c オプションを使用して設定ファイルの別の場所を指定することができます。
atomic-openshift-installer -c </path/to/file> uninstall
$ atomic-openshift-installer -c </path/to/file> uninstallその他のオプションについては、「通常インストール (advanced installation) 方式」を参照してください。
2.5.8. 次のステップ
これで OpenShift Container Platform インスタンスが機能し、以下を実行できるようになります。
- 認証の設定。デフォルトで認証は Deny All に設定されています。
- 自動デプロイされる統合 Docker レジストリーの設定。
- 自動デプロイされるルーターの設定。
2.6. 通常インストール (Advanced Installation)
2.6.1. 概要
Ansible Playbook を使用して実装される参照設定は、 OpenShift Container Platform クラスターをインストールするための通常インストール (advanced installation)方式として使用できます。ただし Ansible に精通している場合、この設定を参照として使用し、選択する設定管理ツールを使用して独自の実装を作成することもできます。
RHEL Atomic Host はコンテナー化された OpenShift Container Platform サービスを実行するためにサポートされていますが、通常インストール (advanced installation) 方式は RHEL Atomic Host で利用できない Ansible を使用します。そのため、RPM ベースのインストーラーは RHEL 7 システムから実行される必要があります。インストールを開始するホストは OpenShift Container Platform クラスターに組み込まれる必要はありませんが、組み込みは可能です。または、インストーラーのコンテナー化バージョンを、RHEL Atomic Host システムから実行できるシステムコンテナーとして使用することもできます。
OpenShift Container Platform をスタンドアロンレジストリーとして インストールするには、「スタンドアロンレジストリーのインストール」を参照してください。
2.6.2. 作業を開始する前に
OpenShift Container Platform をインストールする前に、まず「前提条件」と「ホストの準備」のトピックを参照して、ホストを準備します。この準備では、コンポーネントタイプごとにシステムおよび環境要件を確認し、Docker を適切にインストールし、設定することが含まれます。さらに、通常インストール (advanced installation) 方式は Ansible Playbook をベースとしており、Ansible を直接起動する必要があるため、Ansible バージョン 2.4 以降をインストールことも含まれます。
コンテナー化方法を使用して OpenShift Container Platform をインストールする場合 (RHEL の場合はオプションですが、RHEL Atomic Host の場合は必須です) は、「コンテナー化ホストでのインストール」を参照して、それらの方法の違いを理解してから、このトピックに戻って続行してください。
インストール時間の最適化などの提案を含む大規模インストールについては、『Scaling and Performance Guide』を参照してください。
「前提条件」のトピックの手順に従い、RPM またはコンテナー化方法のいずれにするかを決めた後に「Ansible インベントリーファイルの設定」に進みます。
2.6.3. Ansible インベントリーファイルの設定
/etc/ansible/hosts ファイルは、OpenShift Container Platform をインストールするために使用される Playbook の Ansible インベントリーファイルです。インベントリーファイルは、OpenShift Container Platform クラスターの設定を記述します。ファイルのデフォルトの内容を必要な設定に置き換える必要があります。
以下のセクションでは、通常インストール (advanced installation) 時にインベントリーファイルに設定する一般的な変数を説明し、インストールの開始時に使用できるインベントリーファイルの例も紹介します。
記載される Ansible 変数の多くはオプションです。デフォルト値は開発環境には十分ですが、実稼働環境の場合は、利用可能な各種オプションを理解しておくことをお勧めします。
インベントリーの例は、「高可用性のための複数マスターの使用」などの各種の環境トポロジーを示しています。各自の要件に一致するサンプルを選択し、ご使用の環境に一致するよう修正し、通常インストール (advanced installation) の実行時にこれをインベントリーファイルとして使用できます。
イメージのバージョンポリシー
イメージには更新を維持するためにバージョン番号ポリシーが必要です。詳細は『Architecture Guide』の「Image Version Tag Policy」のセクションを参照してください。
2.6.3.1. クラスター変数の設定
Ansible インストールの実行時に OpenShift Container Platform クラスター全体にグローバルに適用される環境変数を割り当てるには、必要な変数を /etc/ansible/hosts ファイルの [OSEv3:vars] セクションにそれぞれ単一行で指定します。以下は例になります。
Ansible インベントリーファイルのパラメーター値に、#, { or } などの特殊文字が含まれている場合、値をダブルエスケープ (double-escape) する必要があります (値を単一と二重引用符で囲みます)。たとえば、mypasswordwith###hashsigns を変数 openshift_cloudprovider_openstack_password の値として使用し、これを Ansible ホストインベントリーファイルで openshift_cloudprovider_openstack_password='"mypasswordwith###hashsigns"' として宣言します。
以下の表は、クラスター全体に割り当てることのできる Ansible インストーラーで使用される変数について説明しています。
| 変数 | 目的 |
|---|---|
|
|
この変数はインストーラーで使用する SSH ユーザーを設定します。デフォルトは |
|
|
|
|
|
この変数は、 ログを
デバッグログのレベルについての詳細は、「ロギングレベルの設定」を参照してください。 |
|
|
|
|
|
クラスターノードでネットワークタイムプロトコル (NTP) を有効にするかどうか。デフォルトは 重要 クラスター内のマスターおよびノードが同期されなくなる状態を防ぐには、このパラメーターのデフォルト値を変更しないでください。 |
|
|
この変数は、インベントリーホストファイルの要件に基づいてパラメーターと任意の JSON 値を設定します。以下は例になります。 openshift_master_admission_plugin_config={"ClusterResourceOverride":{"configuration":{"apiVersion":"v1","kind":"ClusterResourceOverrideConfig","memoryRequestToLimitPercent":"25","cpuRequestToLimitPercent":"25","limitCPUToMemoryPercent":"200"}}}
|
|
|
この変数は API サービスの監査を有効にします。詳細は、「監査の設定」を参照してください。 |
|
|
この変数はクラスターのホスト名を上書きします。デフォルトはマスターのホスト名です。 |
|
|
この変数はクラスターのパブリックホスト名を上書きします。デフォルトはマスターのホスト名です。外部ロードバランサーを使用する場合は、外部ロードバランサーのアドレスを指定します。 例を以下に示します。 openshift_master_cluster_public_hostname=openshift-ansible.public.example.com |
|
|
オプションです。この変数は複数マスターのデプロイ時の HA 方法を定義します。 |
|
|
この変数は、アップグレード Playbook を直接実行する時に HA マスターのローリング再起動 (例: マスターは一度に 1 つずつ停止します) を有効にします。これはデフォルトで |
|
|
この変数は アイデンティティープロバイダーを設定します。デフォルト値はDeny Allです。サポートされているアイデンティティープロバイダーを使用する場合は OpenShift Container Platform がそれを使用するよう設定します。 |
|
|
これらの変数は、インストールの一部としてデプロイされるカスタム証明書を設定するために使用されます。詳細は、「カスタム証明書の設定」を参照してください。 |
|
| |
|
|
ホストされているルーターのカスタム証明書の場所を指定します。 |
|
|
自動生成されるレジストリー証明書の有効日数。デフォルトで |
|
|
自動生成される CA 証明書の有効日数。デフォルトで |
|
|
自動生成されるノード証明書の有効日数。デフォルトで |
|
|
自動生成されるマスター証明書の有効日数。デフォルトで |
|
|
自動生成される外部 etcd 証明書の有効日数。etcd CA、ピア、サーバー、クライアント証明書の有効性を管理します。デフォルトで |
|
|
|
|
|
これらの変数は OAuth 設定のセッションオプションのデフォルトを上書きします。詳細は「 セッションオプションの設定」を参照してください。 |
|
| |
|
| |
|
| |
|
|
この変数はノード設定の |
|
|
マスター設定で |
|
|
ルーター Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は「ノードホストラベルの設定」を参照してください。 |
|
|
レジストリー Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は、「ノードホストラベルの設定」を参照してください。 |
|
|
この変数は、ブローカーが提供するテンプレートの 1 つ以上の namespace を指定することでテンプレートサービスブローカーを有効にします。 |
|
|
テンプレートサービスブローカー Pod を自動的にデプロイするためのデフォルトのノードセレクター。デフォルトで |
|
|
この変数は、Pod を配置する際にプロジェクトがデフォルトで使用するノードセレクターを上書きします。デフォルトのセレクターはマスター設定ファイルの |
|
|
OpenShift Container Platform は指定された追加レジストリーを docker 設定に追加します。これらは検索対象のレジストリーです。このレジストリーへのアクセスに必要なレジストリーが 例を以下に示します。 openshift_docker_additional_registries=example.com:443 |
|
|
OpenShift Container Platform は指定された追加の非セキュアなレジストリーを docker 設定に追加します。それらのレジストリーの SSL (Secure Sockets Layer) は検証されません。さらに、それらのレジストリーを |
|
|
OpenShift Container Platform は指定されたブロック済みレジストリーを docker 設定に追加します。これは一覧表示されるレジストリーをブロックします。これを |
|
|
この変数は、マスター設定でクラスターメトリクスの |
|
|
この変数は AWS アベイラビリティーゾーン固有のクラスター識別子です。これを使用することで、複数のゾーンまたは複数のクラスターを持つ Amazon Web Service (AWS) での潜在的な問題を回避することができます。詳細は「AWS のクラスターへのラベル付け」を参照してください。 |
|
|
この変数を使用して、インストールまたは設定するコンテナーイメージタグを指定します。 |
|
|
この変数を使用して、インストールまたは設定する RPM バージョンを指定します。 |
クラスターのセットアップ後に openshift_image_tag または openshift_pkg_version 変数を変更する場合はアップグレードがトリガーされ、ダウンタイムが発生します。
-
openshift_image_tagが設定されている場合、この値は別のバージョンがインストールされている場合でもコンテナー化された環境のすべてのホストに使用されます。 -
openshift_pkg_versionが設定されている場合、この値は別のバージョンがインストールされている場合でも RPM ベースの環境のすべてのホストに使用されます。
| 変数 | 目的 |
|---|---|
|
|
この変数は、公開されるルートに使用するデフォルトのサブドメインを上書きします。 |
|
|
この変数は、どの OpenShift SDN プラグインを Pod ネットワークに使用するかを設定します。デフォルトでは標準 SDN プラグインの |
|
|
この変数は SDN クラスターネットワーク CIDR ブロックを上書きします。これは、Pod IP の割り当て元のネットワークです。このネットワークブロックは非公開ブロックとし、Pod、ノード、またはマスターがアクセスする必要のある可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。デフォルトは |
|
|
この変数は、サービスを OpenShift Container Platform SDN 内で作成する際のサブネットを設定します。このネットワークブロックは非公開とし、Pod、ノード、またはマスターがアクセスする必要の可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。そうでない場合、インストールは失敗します。デフォルトは |
|
|
この変数は、OpenShift Container Platform SDN により Pod IP のホストサブネットごとに割り当てられるサイズを指定します。デフォルトは |
|
|
この変数は、使用するサービスプロキシーモードを指定します。 |
|
|
この変数は、デフォルトの SDN の代わりに flannel を代替ネットワーキングレイヤーとして有効にします。flannel を有効にする場合は、 |
|
|
OpenShift SDN プラグインを無効にするには、 |
2.6.3.2. デプロイメントタイプの設定
Playbook 全体で使用される各種デフォルト値とインストーラーによって使用されるロールは、デプロイメントタイプの設定 (通常は Ansible インベントリーファイルで定義されます) に基づいて決定されます。
OpenShift Container Platform バリアントをインストールするには、インベントリーファイルの [OSEv3:vars] セクションにある openshift_deployment_type パラメーターが openshift-enterprise に設定されていることを確認してください。
[OSEv3:vars] openshift_deployment_type=openshift-enterprise
[OSEv3:vars]
openshift_deployment_type=openshift-enterprise2.6.3.3. ホスト変数の設定
Ansible のインストール時に環境変数をホストに割り当てるには、[masters] セクションまたは [nodes] セクションにホストを入力した後に /etc/ansible/hosts ファイルで必要な変数を指定します。以下は例を示しています。
[masters] ec2-52-6-179-239.compute-1.amazonaws.com openshift_public_hostname=ose3-master.public.example.com
[masters]
ec2-52-6-179-239.compute-1.amazonaws.com openshift_public_hostname=ose3-master.public.example.com以下の表は、Ansible インストーラーで使用され、個々のホストエントリーに割り当てることができる変数を示しています。
| 変数 | 目的 |
|---|---|
|
|
この変数は、システムの内部クラスターホスト名を上書きします。システムのデフォルトの IP アドレスがシステムのホスト名に解決されない場合にこれを使用します。 |
|
|
この変数は、システムのパブリックホスト名を上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。 |
|
|
この変数は、システムのクラスター内部 IP アドレスを上書きします。デフォルトルートが設定されていないインターフェースを使用する場合に使用します。etcd には |
|
|
この変数は、システムのパブリック IP アドレスを上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。 |
|
|
true に設定した場合、コンテナー化された OpenShift Container Platform サービスは、RPM パッケージを使用してインストールされる代わりに、ターゲットマスターとノードホスト上で実行されます。 false に設定するか、値を設定しない場合、デフォルトの RPM 方法が使用されます。RHEL Atomic Host では、コンテナー化方法を使用する必要があり、/run/ostree-booted ファイルの検出に基づいて自動的に選択されます。詳細については、「コンテナー化ホストでのインストール」を参照してください。コンテナー化インストールは、OpenShift Container Platform 3.1.1 以降でサポートされています。 |
|
|
この変数は、インストール時にラベルをノードに追加します。詳細については、「ノードホストラベルの設定」を参照してください。 |
|
|
この変数は、ノードに |
|
|
この変数は、/etc/sysconfig/docker 内に追加の
次に、Docker が "--log-driver json-file --log-opt max-size=1M --log-opt max-file=3"
|
|
|
この変数は、ホストがスケジュール可能ノードとしてマークされているかどうか、つまり、新しい Pod を配置できるかどうかを設定します。マスターでのスケジュール可能性の設定を参照してください。 |
2.6.3.4. マスター API ポートの設定
マスター API で使用するデフォルトのポートを設定するには、/etc/ansible/hosts ファイルに以下の変数を定義します。
| 変数 | 目的 |
|---|---|
|
|
この変数は、OpenShift Container Platform API へのアクセスに使用するポート番号を設定します。 |
例を以下に示します。
openshift_master_api_port=3443
openshift_master_api_port=3443
Web コンソールポート設定 (openshift_master_console_port) は、 API サーバーのポート (openshift_master_api_port) に一致している必要があります。
2.6.3.5. クラスターのプレインストールチェックの設定
プレインストールチェックは、openshift_health_checker Ansible ロールの一部として実行される診断タスクのセットです。OpenShift Container Platform の Ansible インストールの前に実行され、必要なインベントリー値が設定されていることを確認し、正常なインストールを妨げたり干渉したりする可能性があるホストの潜在的な問題を特定します。
以下の表は、OpenShift Container Platform のすべての Ansible インストールの前に実行される、使用可能なプレインストールチェックを示しています。
| チェック名 | 目的 |
|---|---|
|
|
このチェックでは、OpenShift Container Platform の特定のデプロイメントで推奨されるメモリー容量がホストにあることを確認します。デフォルト値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで |
|
|
このチェックは、etcd、マスター、およびノードホストに対してのみ実行され、OpenShift Container Platform インストールのマウントパスに十分なディスク領域が残っていることを確認します。推奨されるディスク値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで |
|
|
docker デーモン (ノードとコンテナー化インストール) に依存するホストでのみ実行され、 docker の合計使用率がユーザー定義の上限を超えていないことを確認します。ユーザー定義の上限が設定されていない場合、docker の最大使用率のしきい値はデフォルトで使用可能な合計サイズの 90% になります。合計使用率のしきい値上限は、インベントリーファイルで変数を使用して設定できます。( |
|
|
docker デーモンが OpenShift Containe Platform でサポートされているストレージドライバーを使用していることを確認します。 |
|
|
OpenShift Container Platform インストールで必要なイメージがローカルで、またはホストマシン上の 1 つ以上の設定済みコンテナーイメージレジストリー で使用可能であることの確認を試行します。 |
|
|
|
|
|
OpenShift Container Platform の非コンテナー化インストールの前に実行され、現在のインストールに必要な RPM パッケージが利用可能であることを確認します。 |
|
|
|
特定のプレインストールチェックを無効にするには、カンマ区切りのチェック名の一覧を指定した変数 openshift_disable_check をインベントリーファイルに組み込みます。以下は例になります。
openshift_disable_check=memory_availability,disk_availability
openshift_disable_check=memory_availability,disk_availability既存のクラスターの診断用に実行するための類似のヘルスチェックセットが Ansible ベースのヘルスチェックに用意されています。また、「証明書の再デプロイ」には証明書の有効期限を確認するためのチェックセットもあります。
2.6.3.6. システムコンテナーの設定
システムコンテナーを使用すると、docker デーモンを実行する前に実行する必要があるサービスをコンテナー化できます。システムコンテナーは、以下の機能を使用する Docker 形式のコンテナーです。
したがって、システムコンテナーは従来の docker サービスの外部で保存され、実行されます。システムコンテナーのテクノロジーについての詳細は、『Red Hat Enterprise Linux Atomic Host: Managing Containers』ドキュメントの「Running System Containers」を参照してください。
特定のコンポーネントを RPM や標準のコンテナー化方法の代わりにシステムコンテナーとして実行するように OpenShift Container Platform インストールを設定できます。現在 OpenShift Container Platform では、docker コンポーネントと etcd コンポーネントをシステムコンテナーとして実行できます。
現時点でシステムコンテナーは OS 固有のコンテナーです。特定のバージョンの atomic および systemd を必要とするためです。たとえば、 RHEL、Fedora、 CentOS 用に各種のシステムコンテナーが作成されます。使用するシステムコンテナーがコンテナーを実行するホストの OS に一致していることを確認してください。OpenShift Container Platform では、RHEL と RHEL Atomic のみがホスト OS としてサポートされています。そのため、RHEL 用のシステムコンテナーがデフォルトで使用されます。
2.6.3.6.1. Docker をシステムコンテナーとして実行する
OpenShift Container Platform クラスターでの docker の従来の使用法は RPM パッケージインストールを使用する方法です。Red Hat Enterprise Linux (RHEL) システムの場合は、これは別途インストールする必要があります。RHEL Atomic Host の場合は、これはデフォルトで提供されます。
ただし、docker をノードホストでシステムコンテナーとして実行するように OpenShift Container Platform インストールを設定できます。システムコンテナー方法を使用する場合は、docker パッケージとサービスの代わりに container-engine コンテナーイメージと systemd サービスがホストで使用されます。
docker をシステムコンテナーとして実行するには、以下を実行します。
RHEL 7 では、Docker 用のデフォルトのストレージバックエンドはループバックデバイス上のシンプールです。そのため RHEL システムでは、OpenShift Container Platform を実行する前に
docker用のシンプール論理ボリュームを設定する必要があります。RHEL Atomic Host システムでは、この手順を省略できます。RHEL システムについては、以下のセクションに記載されている手順を実行してください。
ストレージの設定手順が完了したら、RPM をインストールしたままにしておくことができます。
インベントリーファイルの
[OSEv3:vars]セクションで以下のクラスター変数をTrueに設定します。openshift_docker_use_system_container=True
openshift_docker_use_system_container=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
システムコンテナー方法を使用する場合、docker の以下のインベントリー変数は無視されます。
-
docker_version -
docker_upgrade
また、以下のインベントリー変数は使用できません。
-
openshift_docker_options
システムコンテナーの docker が container-engine イメージをプルするときに、デフォルトの registry.access.redhat.com/openshift3/ ではなく、特定のコンテナーレジストリーとリポジトリーを使用するように強制することもできます。これを行うには、インベントリーファイルの [OSEv3:vars] セクションで以下のクラスター変数を設定します。
openshift_docker_systemcontainer_image_override="<registry>/<user>/<image>:<tag>"
openshift_docker_systemcontainer_image_override="<registry>/<user>/<image>:<tag>"2.6.3.6.2. etcd をシステムコンテナーとして実行する
OpenShift Container Platform の RPM ベースのインストール方法を使用する場合、etcd は RPM パッケージを使用して RHEL システムにインストールされます。コンテナー化インストール方法を使用する場合は、代わりに RHEL または RHEL Atomic Host の rhel7/etcd イメージが使用されます。
ただし、etcd をシステムコンテナーとして実行するように OpenShift Container Platform インストールを設定できます。標準のコンテナー化方法では etcd_container という systemd サービスが使用されますが、システムコンテナー方法では RPM ベースの方法と同様にサービス名 etcd が使用されます。この方法を使用する etcd のデータディレクトリーは /var/lib/etcd です。
etcd をシステムコンテナーとして実行するには、インベントリーファイルの [OSEv3:vars] セクションで以下のクラスター変数を設定します。
openshift_use_etcd_system_container=True
openshift_use_etcd_system_container=True2.6.3.7. レジストリーの場所の設定
registry.access.redhat.com にあるデフォルト以外のイメージレジストリーを使用する場合は、目的のレジストリーを /etc/ansible/hosts ファイル内に指定します。
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true| 変数 | 目的 |
|---|---|
|
|
代わりのイメージの場所に設定します。 |
|
|
デフォルト以外のレジストリーを参照している場合は |
|
|
1 つ以上の追加レジストリーを指定します。レジストリーにアクセスするために必要なレジストリーが |
|
|
registry-console イメージが置かれる namespace の URL およびパスを指定します。この値は、 |
|
|
Web コンソールイメージのプレフィックスを指定します。 |
|
|
サービスカタログコンポートイメージのプレフィックスを指定します。 |
|
|
Ansible サービスブローカーのコンポーネントイメージのプレフィックスを指定します。 |
|
|
テンプレートサービスブローカーのコンポーネントイメージのプレフィックスを指定します。 |
|
|
CRI-O を使用している場合、および別のレジストリーからの他の CRI-O システムコンテナーイメージを使用している場合の設定です。 |
例を以下に示します。
2.6.3.8. レジストリールートの設定
ユーザーが OpenShift Container Platform クラスターの外部からイメージをプルして内部の Docker レジストリーにプッシュできるように、/etc/ansible/hosts ファイルにレジストリールートを設定します。デフォルトでは、レジストリールートは docker-registry-default.router.default.svc.cluster.local です。
| 変数 | 目的 |
|---|---|
|
|
必要なレジストリールートの値に設定します。ルートには、ルーターによって通信が管理されるインフラストラクチャーノードに解決される名前、またはデフォルトのアプリケーションサブドメインのワイルドカード値として設定したサブドメインのいずれかが含まれます。たとえば、 |
|
|
レジストリー証明書へのパスを設定します。証明書の場所の値を指定しない場合、証明書が生成されます。以下の証明書の場所を定義できます。
|
|
|
以下のいずれかの値に設定します。
|
例を以下に示します。
openshift_hosted_registry_routehost=<path>
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routecertificates= "{'certfile': '<path>/org-cert.pem', 'keyfile': '<path>/org-privkey.pem', 'cafile': '<path>/org-chain.pem'}"
openshift_hosted_registry_routehost=<path>
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routecertificates= "{'certfile': '<path>/org-cert.pem', 'keyfile': '<path>/org-privkey.pem', 'cafile': '<path>/org-chain.pem'}"2.6.3.9. レジストリーコンソールの設定
デフォルト以外の Cockpit レジストリーコンソールイメージを使用する場合や、特定のバージョンのコンソールが必要な場合は、以下のように必要なレジストリーを /etc/ansible/hosts ファイル内に指定します。
openshift_cockpit_deployer_prefix=<registry_name>/<namespace>/ openshift_cockpit_deployer_version=<cockpit_image_tag>
openshift_cockpit_deployer_prefix=<registry_name>/<namespace>/
openshift_cockpit_deployer_version=<cockpit_image_tag>| 変数 | 目的 |
|---|---|
|
|
イメージが置かれているディレクトリーの URL とパスを指定します。 |
|
|
Cockpit イメージのバージョンを指定します。 |
例: イメージが registry.example.com/openshift3/registry-console にあり、バージョン 3.9.3 が必要な場合は、以下を入力します。
openshift_cockpit_deployer_prefix='registry.example.com/openshift3/' openshift_cockpit_deployer_version='3.9.3'
openshift_cockpit_deployer_prefix='registry.example.com/openshift3/'
openshift_cockpit_deployer_version='3.9.3'2.6.3.10. Red Hat Gluster Storage の永続ストレージの設定
Red Hat Gluster Storage は、OpenShift Container Platform の永続ストレージと動的プロビジョニングを提供するように設定でき、OpenShift Container Platform 内のコンテナー化ストレージ (Container-Native Storage) としても、独自のノード上の非コンテナー化ストレージ (Container-Ready Storage) としても使用できます。
追加情報と以下を含む例については、「 Red Hat Gluster Storage を使用する永続ストレージ」を参照してください。
2.6.3.10.1. Container-Native Storage の設定
具体的なホストの準備と前提条件については、Container-Native Storage に関する考慮事項を参照してください。
インベントリーファイルの
[OSEv3:children]セクションにglusterfsを追加して、[glusterfs]グループを有効にします。[OSEv3:children] masters nodes glusterfs
[OSEv3:children] masters nodes glusterfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow GlusterFS ストレージをホストする各ストレージノードのエントリーを含む
[glusterfs]セクションを追加します。ノードごとに、glusterfs_devicesを GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスは、パーティションや LVM PV がないベアでなければなりません。変数は以下の形式で指定します。<hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
<hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
[glusterfs] node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
[glusterfs] node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow [glusterfs]の下に一覧表示されているホストを[nodes]グループに追加します。[nodes] ... node11.example.com openshift_schedulable=True node12.example.com openshift_schedulable=True node13.example.com openshift_schedulable=True
[nodes] ... node11.example.com openshift_schedulable=True node12.example.com openshift_schedulable=True node13.example.com openshift_schedulable=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.3.10.2. Container-Ready Storage の設定
インベントリーファイルの
[OSEv3:children]セクションにglusterfsを追加して、[glusterfs]グループを有効にします。[OSEv3:children] masters nodes glusterfs
[OSEv3:children] masters nodes glusterfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の変数を
[OSEv3:vars]セクションに追加し、お使いの設定に応じて調整します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow GlusterFS ストレージをホストする各ストレージノードのエントリーを含む
[glusterfs]セクションを追加します。ノードごとに、glusterfs_devicesを GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくと も 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。また、glusterfs_ipをノードの IP アドレスに設定します。変数は以下の形式で指定します。<hostname_or_ip> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
<hostname_or_ip> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
[glusterfs] gluster1.example.com glusterfs_ip=192.168.10.11 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' gluster2.example.com glusterfs_ip=192.168.10.12 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' gluster3.example.com glusterfs_ip=192.168.10.13 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
[glusterfs] gluster1.example.com glusterfs_ip=192.168.10.11 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' gluster2.example.com glusterfs_ip=192.168.10.12 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' gluster3.example.com glusterfs_ip=192.168.10.13 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.3.11. OpenShift Container レジストリーの設定
統合された OpenShift Container レジストリー は、通常インストーラー (Advanced Installer)を使用してデプロイできます。
2.6.3.11.1. レジストリーストレージの設定
レジストリーストレージオプションが使用されていない場合、デフォルトの OpenShift Container レジストリーは一時的で、Pod が存在しなくなるとすべてのデータが失われます。通常インストーラー (Advanced Installer) を使用する場合に、レジストリーストレージを有効にするオプションが複数用意されています。
オプション A: NFS ホストグループ
レジストリーストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。
次の変数が設定されている場合、通常インストール (Advanced installation) 時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に NFS ボリュームが作成されます。たとえば、次のオプションを使用した場合、ボリュームパスは /exports/registry になります。
オプション B: 外部 NFS ホスト
レジストリーストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。
外部の NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。次のオプションを使用した場合、リモートボリュームパスは nfs.example.com:/exports/registry になります。
オプション C: OpenStack プラットフォーム
OpenStack ストレージ設定がすでに存在している必要があります。
オプション D: AWS または別の S3 ストレージソリューション
シンプルストレージソリューション (S3) バケットがすでに存在している必要があります。
Minio や ExoScale などの別の S3 サービスを使用している場合は、リージョンエンドポイントパラメーターも追加します。
openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/
openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/オプション E: Container-Native Storage
Container-Native Storage の設定と同様に、Red Hat Gluster Storage はクラスターの初期インストール時に OpenShift Container レジストリーのストレージを提供するように設定できます。これにより、冗長で信頼性の高いレジストリーのストレージを確保できます。
具体的なホストの準備と前提条件については、Container-Native Storage に関する考慮事項を参照してください。
インベントリーファイルの
[OSEv3:vars]に次の変数を追加します。[OSEv3:vars] ... openshift_hosted_registry_storage_kind=glusterfs
[OSEv3:vars] ... openshift_hosted_registry_storage_kind=glusterfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow [OSEv3:children]セクションにglusterfs_registryを追加して、[glusterfs_registry]グループを有効にします。[OSEv3:children] masters nodes glusterfs_registry
[OSEv3:children] masters nodes glusterfs_registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow GlusterFS ストレージをホストする各ストレージノードのエントリーを含む
[glusterfs_registry]セクションを追加します。ノードごとに、glusterfs_devicesを GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。<hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
<hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
[glusterfs_registry] node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
[glusterfs_registry] node11.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node12.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]' node13.example.com glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow [glusterfs_registry]の下に一覧表示されているホストを[nodes]グループに追加します。[nodes] ... node11.example.com openshift_schedulable=True node12.example.com openshift_schedulable=True node13.example.com openshift_schedulable=True
[nodes] ... node11.example.com openshift_schedulable=True node12.example.com openshift_schedulable=True node13.example.com openshift_schedulable=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
オプション F: Google Compute Engine (GCE) 上の Google Cloud Storage (GCS) バケット
GCS バケットがすでに存在している必要があります。
2.6.3.12. グローバルプロキシーオプションの設定
ホストが外部ホストに接続するために HTTP または HTTPS プロキシーを使用する必要がある場合は、プロキシーを使用するためにマスター、Docker、ビルドなどの多数のコンポーネントを設定する必要があります。ノードサービスは外部アクセスを必要としないマスター API にのみ接続するため、プロキシーを使用するように設定する必要はありません。
この設定を単純化するため、クラスターまたはホストレベルで次の Ansible 変数を指定し、これらの設定を環境全体に均一に適用することができます。
ビルド用のプロキシー環境の定義方法の詳細については、「グローバルビルドのデフォルトとオーバーライドの設定」を参照してください。
| 変数 | 目的 |
|---|---|
|
|
この変数はマスターおよび Docker デーモンの |
|
|
この変数は、マスターおよび Docker デーモンの |
|
|
この変数は、マスターおよび Docker デーモンに |
|
|
このブール変数は、すべての定義済み OpenShift ホストの名前と |
|
|
この変数は、 |
|
|
この変数は、 |
|
|
この変数は、 |
|
|
この変数は、ビルド時に |
|
|
この変数は、ビルド時に |
2.6.3.13. ファイアウォールの設定
- デフォルトのファイアウォールを変更する場合は、不一致を防ぐために、クラスター内の各ホストが同じファイアウォールタイプを使用していることを確認してください。
- Atomic Host にインストールされた OpenShift Container Platform でファイアウォールを使用しないでください。ファイアウォールは Atomic Host ではサポートされていません。
iptables はデフォルトのファイアウォールですが、firewalld は新規インストールで推奨されるファイアウォールです。
OpenShift Container Platform は iptables をデフォルトのファイアウォールとして使用しますが、クラスターをインストールプロセス時に firewalld を使用するように設定できます。
iptables はデフォルトのファイアウォールであるため、OpenShift Container Platform は iptables を自動的に設定するように設計されています。ただし、iptables ルールが適切に設定されていない場合、iptables ルールによって OpenShift Container Platform が中断する可能性があります。 firewalld の利点の 1 つは、複数のオブジェクトでファイアウォールルールを安全に共有できることです。
firewalld を OpenShift Container Platform インストールのファイアウォールとして使用するには、インストール時に os_firewall_use_firewalld 変数を Ansible ホストファイルの設定変数の一覧に追加します。
[OSEv3:vars] os_firewall_use_firewalld=True
[OSEv3:vars]
os_firewall_use_firewalld=True - 1
- この変数を
trueに設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。
firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。
2.6.3.14. マスターでのスケジュール可能性の設定
インストールプロセス時にマスターとして指定するすべてのホストは、マスターが OpenShift SDN の一部として設定されるように、ノードとして設定される必要もあります。これらのホストのエントリーを [nodes] セクションに追加してこの設定を行う必要があります。
[nodes] master.example.com
[nodes]
master.example.com以前のバージョンの OpenShift Container Platform では、マスターホストはインストーラーによってデフォルトでスケジュール不能ノードとしてマークされました。そのため、マスターホストに新しい Pod を配置することができませんでした。しかし、OpenShift Container Platform 3.9 以降では、マスターはインストール時に自動的にスケジュール可能ノードとしてマークされます。この変更の主な目的は、以前はマスター自体の一部として実行されていた Web コンソールをマスターにデプロイされた Pod として実行できるようにすることです。
インストール後にホストのスケジュール可能性を変更したい場合は、「ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする」を参照してください。
2.6.3.15. ノードホストラベルの設定
Ansible のインストール時に /etc/ansible/hosts ファイルを設定することで、ノードホストにラベルを割り当てることができます。ラベルは、スケジューラーを使用して Pod のノードへの配置を決定するのに役立ちます。region=infra ( 専用インフラストラクチャーノードと呼ばれています。詳細は、「専用インフラストラクチャーノードの設定」を参照してください) を除き、実際のラベル名と値は任意に付けることができ、クラスターの要件に合わせて自由に割り当てることができます。
ラベルをAnsible のインストール時にノードホストに割り当てるには、openshift_node_labels 変数を、 [nodes] セクションの必要なノードホストエントリーに追加されたラベルと共に使用します。次の例では、primary というリージョンと east というゾーンのラベルを設定しています。
[nodes]
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
[nodes]
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
OpenShift Container Platform 3.9 以降では、マスターがデフォルトでスケジュール可能ノードとしてマークされるようになりました。そのため、デフォルトノードセレクター (マスター設定ファイルの projectConfig.defaultNodeSelector フィールドで定義され、Pod を配置する際にプロジェクトがデフォルトで使用するノードを決定するために使用されます。以前はデフォルトで空白にされていました。) がクラスターのインストール時にデフォルトで設定されるようになりました。デフォルトノードセレクターは、osm_default_node_selector Ansible 変数で上書きしない限り、node-role.kubernetes.io/compute=true に設定されます。
さらに、osm_default_node_selector が設定されているかどうかにかかわらず、以下の自動のラベル付けがインストール時にインベントリーファイルで定義されるホストに対して実行されます。
-
非マスター、非専用のインフラストラクチャーノードホスト (上記の
node1.example.comホストなど)には、node-role.kubernetes.io/compute=trueというラベルが付けられます。 -
マスターノードには
node-role.kubernetes.io/master=trueというラベルが付けられます。
これにより、Pod の配置を決定する際にデフォルトノードセレクターがノードを選択できるようになります。
インストール時にデフォルトノードセレクター node-role.kubernetes.io/compute=true を受け入れる場合、クラスターで非マスターノードとして定義されているのが専用インフラストラクチャーノードだけでないことを確認してください。この場合、アプリケーション Pod はデプロイに失敗します。 プロジェクトの Pod のスケジュール時に、デフォルトノードセレクターに一致するnode-role.kubernetes.io/compute=true ラベル付きのノードが存在しないためです。
インストール後に必要に応じてこの設定を調整する手順については、「クラスター全体でのデフォルトノードセレクターの設定」を参照してください。
2.6.3.15.1. 専用インフラストラクチャーノードの設定
実稼働環境では、レジストリー Pod とルーター Pod をユーザーアプリケーション用の Pod とは別に実行できる専用インフラストラクチャーノードを保持することを推奨します。
openshift_router_selector および openshift_registry_selector Ansible 設定は、レジストリー Pod とルーター Pod を配置する際に使用されるラベルセレクターを決定します。これらはデフォルトで region=infra に設定されます。
default selectors for router and registry services openshift_router_selector='region=infra' openshift_registry_selector='region=infra'
# default selectors for router and registry services
# openshift_router_selector='region=infra'
# openshift_registry_selector='region=infra'
レジストリーとルーターは、region=infra ラベルが付いた、専用インフラストラクチャーノードと見なされるノードホスト上でのみ実行できます。お使いの OpenShift Container Platform 環境に、region=infra ラベルが付いたノードホストが 1 つ以上存在することを確認してください。以下は例になります。
[nodes]
infra-node1.example.com openshift_node_labels="{'region': 'infra','zone': 'default'}"
[nodes]
infra-node1.example.com openshift_node_labels="{'region': 'infra','zone': 'default'}"
セレクター設定に一致するノードが [nodes] セクションにない場合、デフォルトのルーターとレジストリーはデプロイに失敗し、保留中ステータスになります。
レジストリーとルーターの管理に OpenShift Container Platform を使用しない場合は、次の Ansible 設定を設定します。
openshift_hosted_manage_registry=false openshift_hosted_manage_router=false
openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false
デフォルトの registry.access.redhat.com 以外のイメージレジストリーを使用する場合は、/etc/ansible/hosts ファイルで 必要なレジストリーを指定する必要があります。
マスターでのスケジュール可能性の設定で説明されているように、マスターホストはデフォルトでスケジュール可能としてマークされます。マスターホストに region=infra ラベルを付けており、他に専用インフラストラクチャーノードがない場合、マスターホストはスケジュール可能としてマークされる必要もあります。そうでない場合には、レジストリーとルーター Pod をどこにも配置することができなくなります。
[nodes]
master.example.com openshift_node_labels="{'region': 'infra','zone': 'default'}" openshift_schedulable=true
[nodes]
master.example.com openshift_node_labels="{'region': 'infra','zone': 'default'}" openshift_schedulable=true2.6.3.16. セッションオプションの設定
OAuth 設定のセッションオプションはインベントリーファイルで設定できます。デフォルトで、Ansible は sessionSecretsFile を生成された認証および暗号化シークレットで設定し、1 つのマスターで生成されたセッションが他のマスターによって復号化されるようにできます。デフォルトの場所は /etc/origin/master/session-secrets.yaml であり、このファイルはすべてのマスターで削除された場合にのみ再作成されます。
openshift_master_session_name および openshift_master_session_max_seconds を使用してセッション名と最大秒数を設定できます。
openshift_master_session_name=ssn openshift_master_session_max_seconds=3600
openshift_master_session_name=ssn
openshift_master_session_max_seconds=3600
設定されている場合、openshift_master_session_auth_secrets および openshift_master_encryption_secrets は同じ長さでなければなりません。
HMAC を使用したセッションの認証に使用される openshift_master_session_auth_secrets の場合、32 バイトまたは 64 バイトのシークレットを使用することを推奨します。
openshift_master_session_auth_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']
openshift_master_session_auth_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']
セッションの暗号化に使用される openshift_master_encryption_secrets の場合、シークレットの長さは AES-128、AES-192、または AES-256 を選択するできるようにそれぞれ 16、24、または 32 文字にする必要があります。
openshift_master_session_encryption_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']
openshift_master_session_encryption_secrets=['DONT+USE+THIS+SECRET+b4NV+pmZNSO']2.6.3.17. カスタム証明書の設定
OpenShift Container Platform API のパブリックホスト名と Web コンソールのカスタム提供証明書は、通常インストール (Advanced installation) 時にデプロイでき、インベントリーファイルで設定できます。
カスタム証明書は、publicMasterURL に関連付けられたホスト名にのみ設定する必要があります。これは openshift_master_cluster_public_hostname を使用して設定できます。masterURL (openshift_master_cluster_hostname) に関連付けられたホスト名のカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API に接続しようとするので TLS エラーが生じます。
証明書とキーファイルのパスは、openshift_master_named_certificates クラスター変数を使用して設定できます。
openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "cafile": "/path/to/custom-ca1.crt"}]
openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "cafile": "/path/to/custom-ca1.crt"}]ファイルパスは、Ansible が実行されるシステムに対してローカルである必要があります。証明書はマスターホストにコピーされ、/etc/origin/master/named_certificates/ ディレクトリー内にデプロイされます。
Ansible は、証明書の Common Name と Subject Alternative Names を検出します。検出された名前は、openshift_master_named_certificates の設定時に "names" キーを指定して上書きできます。
openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "names": ["public-master-host.com"], "cafile": "/path/to/custom-ca1.crt"}]
openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "names": ["public-master-host.com"], "cafile": "/path/to/custom-ca1.crt"}]
openshift_master_named_certificates を使用して設定される証明書はマスターにキャッシュされます。つまり、別の証明書セットで Ansible を実行するたびに、以前にデプロイされたすべての証明書がマスターホストとマスターの設定ファイル内に残ることになります。
openshift_master_named_certificates を指定した値 (または値なし) で上書きする場合は、openshift_master_overwrite_named_certificates クラスター変数を指定します。
openshift_master_overwrite_named_certificates=true
openshift_master_overwrite_named_certificates=trueさらに詳細の例が必要な場合には、次のクラスター変数をインベントリーファイルに追加することを検討してください。
openshift_master_cluster_method=native openshift_master_cluster_hostname=lb-internal.openshift.com openshift_master_cluster_public_hostname=custom.openshift.com
openshift_master_cluster_method=native
openshift_master_cluster_hostname=lb-internal.openshift.com
openshift_master_cluster_public_hostname=custom.openshift.com後続の Ansible 実行で証明書を上書きするには、以下を設定できます。
openshift_master_named_certificates=[{"certfile": "/root/STAR.openshift.com.crt", "keyfile": "/root/STAR.openshift.com.key", "names": ["custom.openshift.com"]}]
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"certfile": "/root/STAR.openshift.com.crt", "keyfile": "/root/STAR.openshift.com.key", "names": ["custom.openshift.com"]}]
openshift_master_overwrite_named_certificates=true2.6.3.18. 証明書の有効性の設定
デフォルトで、etcd、マスター、kubelet の管理に使用される証明書は 2 から 5 年で有効期限切れになります。自動生成されるレジストリー、CA、ノードおよびマスター証明書の有効性 (有効期限が切れるまでの日数) は、以下の変数 (デフォルト値が表示されています) を使用してインストール時に設定できます。
これらの値は、 Ansible のインストール後での 証明書の再デプロイ時にも使用されます。
2.6.3.19. クラスターメトリクスの設定
クラスターメトリクスは、自動的にデプロイされるように設定されていません。通常インストール (Advanced installation) 方式を使用している場合にクラスターメトリクスを有効にするには、以下を設定します。
[OSEv3:vars] openshift_metrics_install_metrics=true
[OSEv3:vars]
openshift_metrics_install_metrics=true
メトリクスのパブリック URL は、クラスターのインストール時に openshift_metrics_hawkular_hostname Ansible 変数を使用して設定できます。デフォルト値は以下の通りです。
https://hawkular-metrics.{{openshift_master_default_subdomain}}/hawkular/metrics
この変数を変更する場合は、お使いのルーターからホスト名にアクセスできることを確認してください。
openshift_metrics_hawkular_hostname=hawkular-metrics.{{openshift_master_default_subdomain}}
アップストリームの Kubernetes ルールに応じて、eth0 のデフォルトインターフェースでのみメトリクスを収集できます。
メトリクスをデプロイするために openshift_master_default_subdomain 値を設定する必要があります。
2.6.3.19.1. メトリクスストレージの設定
メトリクスに永続ストレージを使用するには、openshift_metrics_cassandra_storage_type 変数を設定する必要があります。openshift_metrics_cassandra_storage_type が設定されていない場合、クラスターのメトリクスデータは emptyDir ボリュームに保存されます。このボリュームは、Cassandra Pod が終了すると削除されます。
通常インストール (Advanced installation) を使用している場合にクラスターメトリクスストレージを有効にするには、次の 3 つのオプションを選択できます。
オプション A: 動的
OpenShift Container Platform 環境がクラウドプロバイダーの動的ボリュームプロビジョニングをサポートする場合、以下の変数を使用します。
[OSEv3:vars] openshift_metrics_cassandra_storage_type=dynamic
[OSEv3:vars]
openshift_metrics_cassandra_storage_type=dynamic
gluster-storage および glusterfs-storage-block などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。たとえば、openshift_metrics_cassandra_pvc_storage_class_name=glusterfs-storage-block のようになります。
動的プロビジョニングを有効または無効にするために DynamicProvisioningEnabled を使用する方法についての詳細は、「ボリュームの設定」を参照してください。
オプション B: NFS ホストグループ
メトリクスストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。
次の変数が設定されている場合、NFS ボリュームは通常インストール (Advanced installation) 時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に作成されます。たとえば、以下のオプションを使用した場合、ボリュームパスは /exports/metrics になります。
オプション C: 外部 NFS ホスト
メトリクスストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。
外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。
以下のオプションを使用した場合、リモートボリュームのパスは nfs.example.com:/exports/metrics になります。
NFS を使用した OpenShift Container Platform のアップグレードまたはインストール
Red Hat のテスト時に、NFS (RHEL 上) をレジストリーのストレージバックエンドとして使用する場合の問題が確認されました。そのため、(RHEL 上で) NFS をレジストリーのストレージバックエンドとして使用することは推奨していません。
市場で提供されている他の NFS の実装には Red Hat のテスト時に確認された問題がない可能性があります。実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
2.6.3.20. クラスターロギングの設定
クラスターロギングは、デフォルトでは自動的にデプロイされるように設定されていません。通常インストール (Advanced installation) 方式を使用している場合にクラスターロギングを有効にするには、以下を設定します。
[OSEv3:vars] openshift_logging_install_logging=true
[OSEv3:vars]
openshift_logging_install_logging=true2.6.3.20.1. ロギングストレージの設定
ロギングに永続ストレージを使用するには、openshift_logging_es_pvc_dynamic 変数を設定する必要があります。openshift_logging_es_pvc_dynamic が設定されていない場合、クラスターのロギングデータは emptyDir ボリュームに保存されます。このボリュームは、Elasticsearch Pod が終了すると削除されます。
通常インストール (Advanced installation) を使用している場合にクラスターロギングストレージを有効にするには、以下の 3 つのオプションを選択できます。
オプション A: 動的
OpenShift Container Platform 環境がクラウドプロバイダーの動的ボリュームプロビジョニングをサポートする場合、以下の変数を使用します。
[OSEv3:vars] openshift_logging_es_pvc_dynamic=true
[OSEv3:vars]
openshift_logging_es_pvc_dynamic=true
gluster-storage および glusterfs-storage-block などのデフォルトで動的にプロビジョニングされたボリュームタイプが複数ある場合、変数でプロビジョニングされたボリュームタイプを指定できます。たとえば、openshift_logging_es_pvc_storage_class_name=glusterfs-storage-block のようになります。
動的プロビジョニングを有効または無効にするために DynamicProvisioningEnabled を使用する方法についての詳細は、「ボリュームの設定」を参照してください。
オプション B: NFS ホストグループ
ロギングストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。
以下の変数が設定されている場合、通常インストール (Advanced installation) 時に [nfs] ホストグループ内のホストのパス <nfs_directory>/<volume_name> に NFS ボリュームが作成されます。たとえば、以下のオプションを使用した場合、ボリュームパスは /exports/logging になります。
オプション C: 外部 NFS ホスト
ロギングストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。
外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。
以下のオプションを使用した場合、リモートボリュームのパスは nfs.example.com:/exports/logging になります。
NFS を使用した OpenShift Container Platform のアップグレードまたはインストール
Red Hat のテスト時に、NFS (RHEL 上) をレジストリーのストレージバックエンドとして使用する場合の問題が確認されました。そのため、(RHEL 上で) NFS をレジストリーのストレージバックエンドとして使用することは推奨していません。
市場で提供されている他の NFS の実装には Red Hat のテスト時に確認された問題がない可能性があります。実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
2.6.3.21. サービスカタログオプションのカスタマイズ
サービスカタログはインストール時にデフォルトで有効にされます。サービスブローカーを有効にすると、サービスブローカーをカタログで登録できます。サービスカタログが有効にされると、OpenShift Ansible Broker およびテンプレートサービスブローカーが共にインストールされます。詳細は、「OpenShift Ansible Broker の設定」および「テンプレートサービスブローカーの設定」を参照してください。サービスカタログを無効にする場合は、OpenShift Ansible Broker およびテンプレートサービスブローカーはインストールされません。
サービスカタログの自動デプロイメントを無効にするには、以下のクラスター変数をインベントリーファイルに設定します。
openshift_enable_service_catalog=false
openshift_enable_service_catalog=false独自のレジストリーを使用する場合、以下を追加する必要があります。
-
openshift_service_catalog_image_prefix: サービスカタログイメージをプルする際に、特定のプレフィックス (例:registry) の使用を強制的に実行します。(イメージ名までの) 詳細なレジストリー名を指定する必要があります。 -
openshift_service_catalog_image_version: サービスカタログイメージをプルする際に、特定のイメージバージョンの使用を強制的に実行します。
例を以下に示します。
openshift_service_catalog_image="docker-registry.default.example.com/openshift/ose-service-catalog:${version}"
openshift_service_catalog_image_prefix="docker-registry-default.example.com/openshift/ose-"
openshift_service_catalog_image_version="v3.9.30"
template_service_broker_selector={"role":"infra"}
openshift_service_catalog_image="docker-registry.default.example.com/openshift/ose-service-catalog:${version}"
openshift_service_catalog_image_prefix="docker-registry-default.example.com/openshift/ose-"
openshift_service_catalog_image_version="v3.9.30"
template_service_broker_selector={"role":"infra"}サービスカタログを有効にすると、OpenShift Ansible Broker とテンプレートサービスブローカーも有効になります。詳細については、「OpenShift Ansible Broker の設定」および「テンプレートサービスブローカーの設定 」を参照してください。
2.6.3.21.1. OpenShift Ansible Broker の設定
OpenShift Ansible Broker (OAB) は、インストール時にデフォルトで有効になります。
OAB をインストールしない場合は、インベントリーファイルで ansible_service_broker_install パラメーター値を false に設定します。
ansible_service_broker_install=false
ansible_service_broker_install=false2.6.3.21.1.1. OpenShift Ansible Broker 用の永続ストレージの設定
OAB は、残りの OpenShift Container Platform クラスターが使用する etcd とは別に独自の etcd インスタンスをデプロイします。OAB の etcd インスタンスが機能するためには、永続ボリューム (PV) を使用する個別のストレージが必要です。使用可能な PV がない場合、etcd は PV の条件が満たされるまで待機します。OAB アプリケーションは、etcd インスタンスが使用可能になるまで CrashLoop 状態になります。
以下の変数でインストーラーを使用し、NFS を使用する OAB の永続ストレージを設定できます。
| 変数 | 目的 |
|---|---|
|
|
etcd PV に使用するストレージタイプ。 |
|
|
etcd PV の名前。 |
|
|
デフォルトで |
|
|
etcd PV のサイズ。デフォルトで |
|
|
etcd PV に使用するラベル。デフォルトで |
|
|
使用する NFS オプション。デフォルトで |
|
|
NFS エクスポートのディレクトリー。デフォルトで |
一部の Ansible Playbook Bundle (APB) でも、デプロイに専用の PV が必要になります。たとえば、APB の各データベースには 2 つのプランがあります。開発プランは一時的なストレージを使用し、PV を必要としませんが、実稼働プランは永続的であり、PV を必要とします。
| APB | PV が必要? |
|---|---|
|
postgresql-apb |
必要 (ただし実稼働プランの場合のみ必要) |
|
mysql-apb |
必要 (ただし実稼働プランの場合のみ必要) |
|
mariadb-apb |
必要 (ただし実稼働プランの場合のみ必要) |
|
mediawiki-apb |
Yes |
OAB の永続ストレージを設定するには、以下の手順を実行します。
インベントリーファイルの
[OSEv3:children]セクションにnfsを追加して、[nfs]グループを有効にします。[OSEv3:children] masters nodes nfs
[OSEv3:children] masters nodes nfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow [nfs]グループセクションを追加し、NFS ホストになるシステムのホスト名を追加します。[nfs] master1.example.com
[nfs] master1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow [OSEv3:vars]セクションに以下を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらの設定は、クラスターのインストール時に OAB の etcd インスタンスに割り当てられる永続ボリュームを作成します。
2.6.3.21.1.2. ローカルの APB 開発用の OpenShift Ansible ブローカーの設定
OpenShift Container レジストリーと OAB を組み合わせて APB 開発 を行うには、OAB がアクセスできるイメージのホワイトリストを定義する必要があります。ホワイトリストが定義されていない場合、ブローカーは APB を無視し、使用可能な APB がユーザーに表示されません。
デフォルトでは、ホワイトリストは空になっており、クラスター管理者がブローカーを設定するまでユーザーが APB イメージをブローカーに追加できないようになっています。-apb で終了するすべてのイメージをホワイトリスト化するには、以下の手順を実行します。
インベントリーファイルの
[OSEv3:vars]セクションに以下を追加します。ansible_service_broker_local_registry_whitelist=['.*-apb$']
ansible_service_broker_local_registry_whitelist=['.*-apb$']Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.3.21.2. テンプレートサービスブローカーの設定
テンプレートサービスブローカー (TSB) は、インストール時にデフォルトで有効になります。
TSB をインストールしない場合は、template_service_broker_install パラメーターの値を false に設定します。
template_service_broker_install=false
template_service_broker_install=false
TSB を設定するには、テンプレートとイメージストリームをサービスカタログに読み込めるように 1 つ以上のプロジェクトをブローカーのソースの namespace として定義する必要があります。インベントリーファイルの [OSEv3:vars] セクションの以下の箇所を変更して、必要なプロジェクトを設定します。
openshift_template_service_broker_namespaces=['openshift','myproject']
openshift_template_service_broker_namespaces=['openshift','myproject']
デフォルトでは、TSB は Pod のデプロイにノードセレクター {"region": "infra"} を使用します。インベントリーファイルの [OSEv3:vars] セクションに必要なノードセレクターを設定してこれを変更できます。
template_service_broker_selector={"region": "infra"}
template_service_broker_selector={"region": "infra"}2.6.3.22. Web コンソールのカスタマイズの設定
以下の Ansible 変数は、Web コンソールをカスタマイズするためのマスター設定オプションを設定します。これらのカスタマイズオプションの詳細については、「Web コンソールのカスタマイズ」を参照してください。
| 変数 | 目的 |
|---|---|
|
|
Web コンソールをインストールするかどうかを決定します。 |
|
|
コンポーネントイメージのプレフィックス。たとえば、 |
|
|
コンポーネントイメージのバージョン。たとえば、 |
|
|
Web コンソールの設定で |
|
|
Web コンソールの設定で |
|
|
Web コンソール設定で |
|
|
マスター設定で OAuth テンプレートを設定します。詳細については、「ログインページのカスタマイズ」を参照してください。値の例: |
|
|
マスター設定で |
|
|
マスター設定で |
|
|
アクティブでない状態が一定期間続いた後にユーザーを自動的にログアウトするように Web コンソールを設定します。5 以上の整数を指定する必要があります。この機能を無効にする場合は 0 を指定します。デフォルトは 0 (無効) です。 |
|
|
クラスターがオーバーコミット対応に設定されているかどうかを示すブール値。 |
2.6.4. インベントリーファイルの例
2.6.4.1. 単一マスターの例
単一マスターと複数ノード、単一または複数の外部 etcd ホストを含む環境を設定できます。
インストール後の単一マスタークラスターから複数マスターへの移行はサポートされていません。
単一マスター、単一 etcd および複数ノード
以下の表は、単一マスター (同じホストに単一 etcd がある)、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master.example.com |
マスター、etcd、ノード |
|
node1.example.com |
ノード |
|
node2.example.com | |
|
infra-node1.example.com |
ノード ( |
|
infra-node2.example.com |
これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[etcd]、および [nodes] セクションに記載されています。
単一マスター、単一 etcd、および複数ノードのインベントリーファイル
「ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。
この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。
単一マスター、複数 etcd、および複数ノード
以下の表は、単一マスター、3 つの etcd ホスト、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master.example.com |
マスターおよびノード |
|
etcd1.example.com |
etcd |
|
etcd2.example.com | |
|
etcd3.example.com | |
|
node1.example.com |
ノード |
|
node2.example.com | |
|
infra-node1.example.com |
ノード ( |
|
infra-node2.example.com |
これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[nodes]、および [etcd] セクションに記載されています。
単一マスター、複数 etcd、および複数ノードのインベントリーファイル
「ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。
この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。
2.6.4.2. 複数マスターの例
複数マスター、複数 etcd ホスト、複数ノードを含む環境を設定できます。高可用性 (HA) 対応複数マスターを設定すると、クラスターに単一障害点が設定されないようにすることができます。
インストール後の単一マスタークラスターから複数マスターへの移行はサポートされていません。
複数マスターを設定する際には、通常インストール (Advanced installation) でネイティブ高可用性 (HA) 方法がサポートされます。この方法は、OpenShift Container Platform に組み込まれているネイティブ HA マスター機能を活用するもので、 任意のロードバランシングソリューションと組み合わせことができます。
ホストがインベントリーファイルの [lb] セクションに定義されている場合、Ansible はロードバランシングソリューションとして HAProxy を自動的にインストールし、設定します。ホストが定義されていない場合、ユーザーが選択した外部のロードバランシングソリューションを事前に定義しており、マスター API (ポート 8443) をすべてのマスターホストで分散することが想定されます。
この HAProxy ロードバランサーは、API サーバーの HA モードを実証することを意図したものであり、実稼働環境での使用には推奨されません。クラウドプロバイダーにデプロイする場合は、クラウドネイティブの TCP ベースのロードバランサーをデプロイするか、または高可用性ロードバランサーを提供するための他の手順を実行することを推奨します。
外部のロードバランシングソリューションを使用する場合は、以下が必要になります。
- SSL パススルー対応に設定された、事前に作成されたロードバランサーの仮想 IP (VIP)
-
openshift_master_api_port値 (デフォルトは 8443) で指定されたポートでリッスンし、そのポートですべてのマスターホストにプロキシー送信する VIP。 DNS に登録されている VIP のドメイン名。
-
このドメイン名は、OpenShift Container Platform インストーラーで
openshift_master_cluster_public_hostnameとopenshift_master_cluster_hostnameの両方の値になります。
-
このドメイン名は、OpenShift Container Platform インストーラーで
詳細については、「External Load Balancer Integrations example in Github」を参照してください。高可用性マスターアーキテクチャーの詳細については、 「 Kubernetes Infrastructure」を参照してください。
現時点で、通常インストール (Advanced installation) 方式はアクティブ/パッシブ設定の複数の HAProxy ロードバランサーをサポートしていません。インストール後の修正については、ロードバランサー管理ドキュメントを参照してください。
複数マスターを設定するには、「複数 etcd を持つ複数マスター」を参照してください。
外部のクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター
以下の表は、 ネイティブ HA 方法を使用する 3 つのマスター、1 つの HAProxy ロードバランサー、3 つの etcd ホスト、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master1.example.com |
マスター (クラスター化、ネイティブ HA を使用) およびノード |
|
master2.example.com | |
|
master3.example.com | |
|
lb.example.com |
API マスターエンドポイントの負荷分散を行う HAProxy |
|
etcd1.example.com |
etcd |
|
etcd2.example.com | |
|
etcd3.example.com | |
|
node1.example.com |
ノード |
|
node2.example.com | |
|
infra-node1.example.com |
ノード ( |
|
infra-node2.example.com |
これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[etcd]、[lb] および [nodes] セクションに記載されています。
HAProxy インベントリーファイルを使用する複数マスター
「ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。
この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。
同一の場所に配置されたクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター
以下の表は、ネイティブ HA 方法を使用する 3 つのマスター (各ホストに etcd がある)、1 つの HAProxy ロードバランサー、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。
| ホスト名 | インストールするインフラストラクチャーコンポーネント |
|---|---|
|
master1.example.com |
各ホストに etcd があるマスター (ネイティブ HA を使用するクラスター化) とノード |
|
master2.example.com | |
|
master3.example.com | |
|
lb.example.com |
API マスターエンドポイントの負荷分散を行う HAProxy |
|
node1.example.com |
ノード |
|
node2.example.com | |
|
infra-node1.example.com |
ノード ( |
|
infra-node2.example.com |
これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[etcd]、[lb] および [nodes] セクションに記載されています。
「ノードホストラベルの設定」を参照し、OpenShift Container Platform 3.9 以降のデフォルトノードセレクター要件とノードラベルに関する考慮事項を確認してください。
この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。
2.6.5. 通常インストール (Advanced installation) の実行
/etc/ansible/hosts でインベントリーファイルを定義して Ansible の設定を完了した後に、通常インストール (Advanced installation) Playbook を Ansible を使用して実行します。
インストーラーはモジュール化された Playbook を使用します。そのため、管理者は必要に応じて特定のコンポーネントをインストールできます。ロールと Playbook を分けることで、アドホックな管理タスクをより適切にターゲット設定できます。その結果、インストール時の制御レベルが強化され、時間の節約が可能になります。
Playbook とその順序については、以下の「個別コンポーネント Playbook の実行」で詳しく説明しています。
既知の問題により、インストールの実行後、NFS ボリュームがいずれかのコンポーネント用にプロビジョニングされている場合、それらのコンポーネントが NFS ボリュームにデプロイされるかどうかにかかわらず、以下のディレクトリーが作成される可能性があります。
- /exports/logging-es
- /exports/logging-es-ops/
- /exports/metrics/
- /exports/prometheus
- /exports/prometheus-alertbuffer/
- /exports/prometheus-alertmanager/
インストール後にこれらのディレクトリーを随時削除することができます。
2.6.5.1. RPM ベースのインストーラーの実行
RPM ベースのインストーラーは、RPM パッケージでインストールされた Ansible を使用し、ローカルホストで使用可能な Playbook と設定ファイルを実行します。
OpenShift Ansible Playbook は nohup で実行しないでください。Playbook で nohup を使用すると、ファイル記述子が作成され、ファイルが閉じなくなります。その結果、システムでファイルをさらに開けなくなり、Playbook が失敗します。
RPM ベースのインストーラーを実行するには、以下の手順を実行します。
prerequisites.yml Playbook を実行します。この Playbook にはソフトウェアパッケージが必要であり (ある場合)、コンテナーランタイムを変更します。コンテナーランタイムを設定する必要がない限り、この Playbook はクラスターの初回のデプロイ前に 1 度のみ実行します。
ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml# ansible-playbook [-i /path/to/inventory] \1 /usr/share/ansible/openshift-ansible/playbooks/prerequisites.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インベントリーファイルが /etc/ansible/hosts ディレクトリーにない場合、
-iおよびインベントリーファイルのパスを指定します。
deploy_cluster.yml Playbook を実行してクラスターインストールを開始します。
ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml# ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に「既知の問題」に目を通し、特定の指示や回避策がないかどうか確認してください。
インストーラーは、デフォルトで 10 分間 Playbook の設定値をキャッシュします。システム、ネットワーク、またはインベントリー設定を変更してから 10 分以内にインストーラーを再実行する場合、新規の値は使用されず、代わりに以前の値が使用されます。キャッシュのコンテンツは削除できます。これは、/etc/ansible/ansible.cfg ファイルの fact_caching_connection の値で定義されます。このファイルのサンプルは、「Recommended Installation Practices」で説明されています。
2.6.5.2. コンテナー化インストーラーの実行
openshift3/ose-ansible イメージは、 OpenShift Container Platform インストーラーのコンテナー化バージョンです。このインストーラーイメージは、RPM ベースのインストーラーと同じ機能を提供しますが、ホストに直接インストールされるのではなく、そのすべての依存関係を提供するコンテナー化環境で実行されます。この使用にあたっての唯一の要件は、コンテナーを実行できることになります。
2.6.5.2.1. インストーラーをシステムコンテナーとして実行する
インストーラーイメージは、システムコンテナーとして使用できます。システムコンテナーは、従来の docker サービスの外部に保存して実行できます。これにより、ホストでのインストールによって docker が再起動されることを心配することなく、ターゲットホストのいずれかからインストーラーイメージを実行することが可能になります。
Atomic CLI を使用してインストーラーを 1 回だけ実行されるシステムコンテナーとして実行するには、以下の手順を root ユーザーとして実行します。
prerequisites.yml Playbook を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ローカルホスト上にインベントリーファイルの場所を指定します。
このコマンドは、指定されるインベントリーファイルと
rootユーザーの SSH 設定を使用して一連の前提条件タスクを実行します。deploy_cluster.yml Playbook を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ローカルホスト上にインベントリーファイルの場所を指定します。
このコマンドは、指定されるインベントリーファイルと
rootユーザーの SSH 設定を使用してクラスターインストールを開始します。出力のログを端末に記録し、さらに /var/log/ansible.log ファイルに保存します。このコマンドの初回実行時に、イメージは OSTree ストレージ (システムコンテナーは docker デーモンストレージではなくこのストレージを使用します) にインポートされます。後続の実行では、保存されたイメージが再利用されます。何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に「既知の問題」に目を通し、特定の指示や回避策がないかどうか確認してください。
2.6.5.2.2. その他の Playbook の実行
PLAYBOOK_FILE 環境変数を使用すると、コンテナー化インストーラーで実行するその他の Playbook を指定できます。 PLAYBOOK_FILE のデフォルト値は、メインのクラスターインストール Playbook である /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml ですが、これをコンテナー内の別の Playbook のパスに設定できます。
たとえば、インストールの前にプレインストールチェック Playbook を実行するには、以下のコマンドを使用します。
2.6.5.2.3. インストーラーを Docker コンテナーとして実行する
インストーラーイメージは、docker が実行できる任意の場所で docker コンテナーとして実行することもできます。
この方法は、設定されているホストのいずれかでインストーラーを実行するために使用しないでください。インストールによってホストで docker が再起動され、インストーラーコンテナーの実行が中断する可能性があります。
この方法と上記のシステムコンテナー方法は同じイメージを使用しますが、それぞれ異なるエントリーポイントとコンテキストで実行されます。そのため、ランタイムパラメーターは同じではありません。
インストーラーを docker コンテナーとして実行する場合は、少なくとも以下を指定する必要があります。
- SSH キー (Ansible がホストにアクセスできるようにするため)。
- Ansible インベントリーファイル。
- そのインベントリーに対して実行する Ansible Playbook の場所。
次に、docker 経由でインストールを実行する方法の例を示します。これは、docker へのアクセス権限を持つ非 root ユーザーとして実行する必要があります。
まず、prerequisites.yml Playbook を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-u `id -u`は、コンテナーが現在のユーザーと同じ UID で実行されるようにします。これにより、そのユーザーがコンテナー内の SSH キーを使用できるようになります (SSH プライベートキーは所有者のみが判読できることが予想されます)。- 2
-v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Zは、SSH キー ($HOME/.ssh/id_rsa) をコンテナーユーザーの$HOME/.ssh(/opt/app-root/src はコンテナー内のユーザーの$HOMEです) にマウントします。SSH キーを標準以外の場所にマウントする場合は、-e ANSIBLE_PRIVATE_KEY_FILE=/the/mount/pointで環境変数を追加するか、インベントリーでansible_ssh_private_key_file=/the/mount/pointを変数として設定し、Ansible がこれを参照するようにします。SSH キーは:Zフラグでマウントされることに注意してください。これは、コンテナーがその制限された SELinux コンテキストで SSH キーを読み取れるようにするために必要です。これはまた、元の SSH キーファイルのラベルがsystem_u:object_r:container_file_t:s0:c113,c247のようなラベルに変更されることも意味しています。:Zの詳細については、docker-run(1)の man ページを参照してください。これらの点は、このようなボリュームマウント仕様を提供する際に留意してください。これによって予期しない結果が生じる可能性があります。たとえば、$HOME/.sshディレクトリー全体をマウントすると (したがってラベルを変更すると)、ホストの sshd がログイン時にパブリックキーにアクセスできなくなります。このため、元のファイルラベルを変更しなくてもすむように SSH キー (またはディレクトリー) の別のコピーを使用することをお勧めします。- 3 4
-v $HOME/ansible/hosts:/tmp/inventory:Zと-e INVENTORY_FILE=/tmp/inventoryは、静的 Ansible インベントリーファイルを /tmp/inventory としてコンテナーにマウントし、これを参照する対応する環境変数を設定します。SSH キーと同様に、既存のラベルによっては、コンテナー内を読み取れるように、:Zフラグを使用してインベントリーファイルの SELinux ラベルを変更しなければならない場合があります (ユーザーの$HOMEディレクトリー内のファイルの場合、通常はラベルの変更が必要になります)。そのため、この場合もまた、マウント前にインベントリーを専用の場所にコピーすることをお勧めします。インベントリーファイルは、INVENTORY_URL環境変数を指定した場合には、Web サーバーからダウンロードすることもできます。またはDYNAMIC_SCRIPT_URLを使用して、動的なインベントリーを提供する実行可能スクリプトを指定することにより動的に生成することもできます。- 5
-e PLAYBOOK_FILE=playbooks/prerequisites.ymlは、実行する Playbook (この例では前提条件 Playbook) を、openshift-ansible コンテンツの最上位レベルのディレクトリーの相対パスとして指定します。RPM からのフルパスやコンテナー内のその他の Playbook へのパスも使用できます。- 6
-e OPTS="-v"は、コンテナー内で実行されるansible-playbookコマンドに任意のコマンドラインオプションを提供します (この例では、-vを使用して省サイドを上げることができます)。
次に、deploy_cluster.yml playbook を実行してクラスターインストールを開始します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6.5.2.4. OpenStack インストール Playbook の実行
OpenStack インストール Playbook はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
OpenShift Container Platform を既存の OpenStack インストールにインストールするには、OpenStack Playbook を使用します。詳細の前提条件を含む Playbook についての詳細は、OpenStack Provisioning readme ファイルを参照してください。
Playbook を実行するには、以下のコマンドを実行します。
ansible-playbook --user openshift \ -i openshift-ansible/playbooks/openstack/inventory.py \ -i inventory \ openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml
$ ansible-playbook --user openshift \
-i openshift-ansible/playbooks/openstack/inventory.py \
-i inventory \
openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml2.6.5.3. 個別コンポーネント playbook の実行
メインのインストール Playbook である /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.ymlは、一連の個別コンポーネント Playbook を特定の順序で実行します。実行の最後に、インストーラーから完了したフェーズが報告されます。インストールが失敗した場合は、そのフェーズが失敗したかについて Ansible の実行エラーと共に画面に表示されます。
エラーを解決した後に、インストールを継続できます。
- 残りのそれぞれのインストール Playbook を実行できます。
- 新規環境にインストールしている場合、deploy_cluster.yml を再度実行します。
残りの Playbook のみを実行する必要がある場合、失敗したフェーズの Playbook から実行し、その後に残りの Playbook を順番に実行します。
ansible-playbook [-i /path/to/inventory] <playbook_file_location>
# ansible-playbook [-i /path/to/inventory] <playbook_file_location>以下の表は、Playbook が実行される順序で Playbook を一覧表示しています。
| Playbook 名 | ファイルの場所 |
|---|---|
|
Health Check |
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml |
|
etcd Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/config.yml |
|
NFS Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-nfs/config.yml |
|
Load Balancer Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-loadbalancer/config.yml |
|
Master Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-master/config.yml |
|
Master Additional Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-master/additional_config.yml |
|
Node Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-node/config.yml |
|
GlusterFS Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml |
|
Hosted Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/config.yml |
|
Web Console Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-web-console/config.yml |
|
Metrics Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml |
|
Logging Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml |
|
Prometheus Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-prometheus/config.yml |
|
Service Catalog Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-service-catalog/config.yml |
|
Management Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/config.yml |
2.6.6. インストールの検証
インストールが完了したら、次の手順を実行します。
マスターが起動しており、ノードが登録されており、Ready ステータスで報告されていることを確認します。マスターホストで 以下を root で実行します。
oc get nodes
# oc get nodes NAME STATUS ROLES AGE VERSION master.example.com Ready master 7h v1.9.1+a0ce1bc657 node1.example.com Ready compute 7h v1.9.1+a0ce1bc657 node2.example.com Ready compute 7h v1.9.1+a0ce1bc657Copy to Clipboard Copied! Toggle word wrap Toggle overflow Web コンソールが正常にインストールされているか確認するには、マスターホスト名と Web コンソールのポート番号を使用して Web ブラウザーで Web コンソールにアクセスします。
たとえば、ホスト名が
master.openshift.comで、デフォルトポート8443を使用するマスターホストの場合、Web コンソールはhttps://master.openshift.com:8443/consoleにあります。
複数 etcd ホストの確認
複数 etcd ホストをインストールした場合は、以下の手順を実行します。
まず、
etcdctlコマンドを提供する etcd パッケージがインストールされていることを確認します。yum install etcd
# yum install etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow マスターホストで etcd クラスターの正常性を確認します。以下で実際の etcd ホストの FQDN の置き換えを実行します。
etcdctl -C \ https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \ --ca-file=/etc/origin/master/master.etcd-ca.crt \ --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file=/etc/origin/master/master.etcd-client.key cluster-health# etcdctl -C \ https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \ --ca-file=/etc/origin/master/master.etcd-ca.crt \ --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file=/etc/origin/master/master.etcd-client.key cluster-healthCopy to Clipboard Copied! Toggle word wrap Toggle overflow メンバーリストが正しいことも確認します。
etcdctl -C \ https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \ --ca-file=/etc/origin/master/master.etcd-ca.crt \ --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file=/etc/origin/master/master.etcd-client.key member list# etcdctl -C \ https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \ --ca-file=/etc/origin/master/master.etcd-ca.crt \ --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file=/etc/origin/master/master.etcd-client.key member listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
HAProxy を使用する複数マスターの確認
HAProxy を使用する複数マスターをロードバランサーとしてインストールした場合は、[lb] セクションの定義に従って次の URL に移動し、HAProxy のステータスを確認します。
http://<lb_hostname>:9000
http://<lb_hostname>:9000HAProxy の設定に関するドキュメントを参照してインストールを検証できます。
2.6.7. ビルドのオプションでのセキュリティー保護
docker build の実行は特権付きのプロセスのため、コンテナーにはマルチテナント環境で許可される以上のノードに対するアクセスがある場合があります。ユーザーを信頼しない場合、インストール時により多くのセキュアなオプションを使用できます。クラスターで Docker ビルドを無効にし、ユーザーに対してクラスター外でイメージをビルドするように要求できます。このオプションのプロセスについての詳細は、「Securing Builds by Strategy」を参照してください。
2.6.8. OpenShift Container Platform のアンインストール
クラスターの OpenShift Container Platform ホストをアンインストールするには、uninstall.yml playbook を実行します。この playbook は、Ansible によってインストールされた OpenShift Container Platform コンテンツを削除します。これには以下が含まれます。
- 設定
- コンテナー
- デフォルトのテンプレートとイメージストリーム
- イメージ
- RPM パッケージ
この Playbook は、Playbook の実行時に指定するインベントリーファイルで定義されているすべてのホストのコンテンツを削除します。クラスター内のすべてのホストで OpenShift Container Platform をアンインストールする場合、最初に OpenShift Container Platform をインストールしたときに使用したインベントリーファイルか、または最近実行したインベントリーファイルを使用して Playbook を実行します。
ansible-playbook [-i /path/to/file] \
/usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml
# ansible-playbook [-i /path/to/file] \
/usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml2.6.8.1. ノードのアンインストール
uninstall.yml playbook を使用すると、ノードコンポーネントを特定のホストからアンインストールし、それ以外のホストとクラスターをそのままにしておくことができます。
この方法は、特定のノードホストをアンインストールする場合にのみ使用してください。特定のマスターホストや etcd ホストのアンインストールには使用しないでください。これらのホストをアンインストールするには、クラスター内での追加の設定変更が必要になります。
- まず、「ノードの削除」の手順に従ってクラスターからノードオブジェクトを削除します。次に、この残りの手順を実行します。
これらのホストのみを参照する別のインベントリーファイルを作成します。たとえば、1 つのノードのみからコンテンツを削除する場合は、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow uninstall.yml playbook の実行時に、
-iオプションを使用して新規インベントリーファイルを指定します。ansible-playbook -i /path/to/new/file \ /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml# ansible-playbook -i /path/to/new/file \ /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Playbook が完了すると、すべての OpenShift Container Platform コンテンツが指定したホストから削除されます。
2.6.9. 既知の問題
- 複数マスタークラスターでフェイルオーバーが発生すると、コントローラーマネージャーの過剰修正が生じ、結果として予定よりも多くの Pod がシステムで実行される可能性があります。ただし、これは一時的なイベントであり、後にシステムによって修正されます。詳細については、https://github.com/kubernetes/kubernetes/issues/10030 を参照してください。
Ansible インストーラーが失敗する場合でも、OpenShift Container Platform をインストールできます。
-
OpenShift Container Platform 3.9 の初期 GA リリースには、インストール Playbook とアップグレード Playbook が以前のリリースよりも多くのメモリーを消費するという既知の問題があります。Ansible のノードスケールアップ Playbook とインストール Playbook は、コントロールホスト (Playbook の実行元のシステム) で想定よりも多くのメモリーを消費することがありました。これは
include_tasksが複数の場所で使用されていたためです。この問題は RHBA-2018:0600 のリリースで対応されています。現在これらのインスタンスの大半が、それほど多くのメモリーを消費しないimport_tasks呼び出しに変換されています。この変更により、コントロール ホストでのメモリー消費量は、ホストあたり 100MiB 未満になります。大規模な環境 (100 以上のホスト) では、16GiB 以上のメモリーを搭載したコントロールホストを使用することを推奨します。(BZ#1558672)
2.6.10. 次のステップ
これで OpenShift Container Platform インスタンスが機能し、以下を実行できるようになります。
- 統合 Docker レジストリーをデプロイします。
- ルーターをデプロイします。
2.7. 非接続インストール
2.7.1. 概要
データセンターの一部が、プロキシーサーバー経由でもインターネットにアクセスできないことがよくあります。このような環境での OpenShift Container Platform のインストールは非接続インストールと見なされます。
OpenShift Container Platform の非接続インストールは、主に次の 2 つの点で通常のインストールと異なります。
- OpenShift Container Platform のソフトウェアチャンネルとリポジトリーが、 Red Hat のコンテンツ配信ネットワーク (CDN) 経由で利用できません。
- OpenShift Container Platform は複数のコンテナー化されたコンポーネントを使用します。通常、これらのイメージは Red Hat の Docker レジストリーから直接プルされますが、非接続環境ではこれを実行できません。
非接続インストールでは、該当するサーバーで OpenShift Container Platform ソフトウェアを利用できるようにし、その後は標準の接続インストールと同じインストールプロセスに従います。このトピックでは、コンテナーイメージを手動でダウンロードし、これを関連するサーバーに転送する方法について詳しく説明します。
インストールが完了したら、OpenShift Container Platform を使用するため、ソース管理リポジトリー (Git など) にソースコードが必要です。このトピックでは、ソースコードをホストできる内部 Git リポジトリーが利用可能であり、OpenShift Container Platform ノードからこのリポジトリーにアクセスできることを前提とします。ソース管理リポジトリーのインストールについては、本書では扱いません。
また、アプリケーションを OpenShift Container Platform でビルドする場合、ビルドに何らかの外部の依存関係 (Maven リポジトリーや Ruby アプリケーション用の Gem ファイルなど) がある場合があります。このため、このような依存関係には特定のタグが必要な場合があるため、OpenShift Container Platform で提供される Quickstart テンプレートの多くは、非接続環境では動作しない可能性があります。ただし、 Red Hat コンテナーイメージはデフォルトで外部リポジトリーへのアクセスを試みますが、OpenShift Container Platform を独自の内部リポジトリーを使用するように設定することもできます。本書では、このような内部リポジトリーがすでに存在しており、OpenShift Container Platform ノードホストからアクセスできることを前提としています。このリポジトリーのインストールについては、本書では扱いません。
インターネットまたは LAN 経由で Red Hat コンテンツへのアクセスを提供する Red Hat Satellite サーバーを利用することもできます。 Satellite が導入されている環境では、OpenShift Container Platform ソフトウェアを Satellite に同期し、OpenShift Container Platform サーバーで使用できます。
Red Hat Satellite 6.1 では、Docker レジストリーとして動作する機能も導入されています。この機能を使用すると、OpenShift Container Platform のコンテナー化されたコンポーネントをホストできます。この実行方法については、本書では扱いません。
2.7.2. 前提条件
本書では、OpenShift Container Platform の全体的なアーキテクチャーを理解していることと、環境トポロジーが計画済みであることを前提としています。
2.7.3. 必要なソフトウェアとコンポーネント
必要なソフトウェアリポジトリーとコンテナーイメージをプルするには、インターネットにアクセスできる Red Hat Enterprise Linux (RHEL) 7 サーバーと少なくとも 100GB の空き容量が必要です。このセクションのすべての手順は、インターネットに接続されたサーバーで root システムユーザーとして実行する必要があります。
2.7.3.1. リポジトリーの同期
必要なリポジトリーを同期する前に、適切な GPG キーのインポートが必要になる場合があります。
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
$ rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-releaseキーをインポートしない場合、指定したパッケージはリポジトリーの同期後に削除されます。
必要なリポジトリーを同期するには、次の手順を実行します。
サーバーを Red Hat カスタマーポータルに登録します。OpenShift Container Platform サブスクリプションにアクセスできるアカウントに関連付けられているログインとパスワードを使用する必要があります。
subscription-manager register
$ subscription-manager registerCopy to Clipboard Copied! Toggle word wrap Toggle overflow RHSM から最新サブスクリプションデータをプルします。
subscription-manager refresh
$ subscription-manager refreshCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform チャンネルを提供するサブスクリプションにアタッチします。使用可能なサブスクリプションの一覧は、以下のコマンドで確認できます。
subscription-manager list --available --matches '*OpenShift*'
$ subscription-manager list --available --matches '*OpenShift*'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、OpenShift Container Platform を提供するサブスクリプションのプール ID を見つけ、これをアタッチします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow yum-utilsコマンドは、reposync ユーティリティーを提供します。これによって yum リポジトリーをミラーリングでき、createrepoで使用可能なyumリポジトリーをディレクトリーから作成できます。sudo yum -y install yum-utils createrepo docker git
$ sudo yum -y install yum-utils createrepo docker gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow ソフトウェアを同期するには、最大 110GB の空き容量が必要です。組織のポリシーの制限のレベルによっては、このサーバーを非接続 LAN に再接続し、これをリポジトリーサーバーとして使用できます。USB 接続ストレージを使用し、ソフトウェアをリポジトリーサーバーとして機能する別のサーバーに転送できます。このトピックでは、これらのオプションについて説明します。
ソフトウェアを同期する場所へのパスを作成します (ローカル、USB その他デバイスのいずれか)。
mkdir -p </path/to/repos>
$ mkdir -p </path/to/repos>Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッケージを同期し、各パッケージのリポジトリーを作成します。上記の手順で作成した適切なパスに合わせてコマンドを変更する必要がります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.2. イメージの同期
コンテナーイメージを同期するには、以下を実行します。
Docker デーモンを起動します。
systemctl start docker
$ systemctl start dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow Iコンテナー化インストールを実行する場合、必要な OpenShift Container Platform ホストコンポーネントイメージすべてをプルします。
<tag>を最新バージョンのv3.9.43に置き換えます。docker pull registry.access.redhat.com/rhel7/etcd docker pull registry.access.redhat.com/openshift3/ose:<tag> docker pull registry.access.redhat.com/openshift3/node:<tag> docker pull registry.access.redhat.com/openshift3/openvswitch:<tag>
# docker pull registry.access.redhat.com/rhel7/etcd # docker pull registry.access.redhat.com/openshift3/ose:<tag> # docker pull registry.access.redhat.com/openshift3/node:<tag> # docker pull registry.access.redhat.com/openshift3/openvswitch:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な OpenShift Container Platform インフラストラクチャーコンポーネントイメージすべてをプルします。
<tag>を最新バージョンのv3.9.43に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記NFS を使用している場合は、
ose-recyclerイメージが必要です。これを使用しないと、ボリュームはリサイクルされず、エラーが発生する可能性があります。リサイクル回収ポリシーは動的プロビジョニングが優先されるために非推奨となり、今後のリリースでは削除されます。
追加の一元的なログ集約およびメトリクス集約コンポーネントに必要な OpenShift Container Platform のコンテナー化されたコンポーネントすべてをプルします。
<tag>を最新バージョンのv3.9.43に置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Red Hat サポートについては、Container-Native Storage (CNS) のサブスクリプションが
rhgs3/イメージに必要です。重要OpenShift Container Platform 上での Prometheus はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
サービスカタログ、OpenShift Ansible ブローカー、およびテンプレートサービスブローカー機能 (「通常インストール (Advanced installation)」に記載) が必要な場合は、以下のイメージをプルします。
<tag>を最新バージョンのv3.9.43に置き換えます。docker pull registry.access.redhat.com/openshift3/ose-service-catalog:<tag> $ docker pull registry.access.redhat.com/openshift3/ose-ansible-service-broker:<tag> $ docker pull registry.access.redhat.com/openshift3/mediawiki-apb:<tag> $ docker pull registry.access.redhat.com/openshift3/postgresql-apb:<tag>
$ docker pull registry.access.redhat.com/openshift3/ose-service-catalog:<tag> $ docker pull registry.access.redhat.com/openshift3/ose-ansible-service-broker:<tag> $ docker pull registry.access.redhat.com/openshift3/mediawiki-apb:<tag> $ docker pull registry.access.redhat.com/openshift3/postgresql-apb:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift 環境で使用する Red Hat 認定の Source-to-Image (S2I) ビルダーイメージをプルします。以下のイメージをプルできます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なバージョン番号を示す適切なタグを指定してください。たとえば、Tomcat イメージの前のバージョンと最新バージョンの両方をプルするには、以下を実行します。
docker pull \ registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:latest docker pull \ registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:1.1
$ docker pull \ registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:latest $ docker pull \ registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.3.3. イメージのエクスポートの準備
コンテナーイメージをシステムからエクスポートできます。これを行うには、まずコンテナーイメージを tarball に保存し、次にそれを転送します。
リポジトリーのホームディレクトリーを作成し、これに移動します。
mkdir </path/to/repos/images> cd </path/to/repos/images>
$ mkdir </path/to/repos/images> $ cd </path/to/repos/images>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Iコンテナー化インストールを実行する場合、OpenShift Container Platform ホストコンポーネントイメージをエクスポートします。
docker save -o ose3-host-images.tar \ registry.access.redhat.com/rhel7/etcd \ registry.access.redhat.com/openshift3/ose \ registry.access.redhat.com/openshift3/node \ registry.access.redhat.com/openshift3/openvswitch# docker save -o ose3-host-images.tar \ registry.access.redhat.com/rhel7/etcd \ registry.access.redhat.com/openshift3/ose \ registry.access.redhat.com/openshift3/node \ registry.access.redhat.com/openshift3/openvswitchCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform インフラストラクチャーコンポーネントのイメージをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Red Hat サポートについては、CNS のサブスクリプションが
rhgs3/イメージに必要です。メトリクスとログ集約イメージを同期した場合は、それらをエクスポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前のセクションで同期した S2I ビルダーイメージをエクスポートします。たとえば、Jenkins イメージと Tomcat イメージのみを同期した場合は、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.4. リポジトリーサーバー
インストール時に (選択する場合はその後のアップデート時に)、リポジトリーをホストするための Web サーバーが必要となります。RHEL 7 では、Apache Web サーバーを提供しています。
オプション 1 : Web サーバーとしての再設定
ソフトウェアとイメージを LAN に同期しているサーバーに再接続ができる場合は、Apache をそのサーバーに単純にインストールできます。
sudo yum install httpd
$ sudo yum install httpdソフトウェアの配置に進んでください。
オプション 2: リポジトリーサーバーの構築
リポジトリーサーバーとして機能する別のサーバーを設定する必要がある場合には、110 GB 以上の空き領域を持つ新規の RHEL 7 システムをインストールしてください。インストール時に、このリポジトリーサーバーで Basic Web Server オプションが選択されていることを確認します。
2.7.4.1. ソフトウェアの配置
必要に応じて外部ストレージを割り当て、リポジトリーファイルを Apache のルートフォルダーにコピーします。同期に使用したサーバーを再利用している場合には、以下の copy の手順 (
cp -a) を move (mv) に置き換える必要があることに注意してください。cp -a /path/to/repos /var/www/html/ chmod -R +r /var/www/html/repos restorecon -vR /var/www/html
$ cp -a /path/to/repos /var/www/html/ $ chmod -R +r /var/www/html/repos $ restorecon -vR /var/www/htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ファイアウォールのルールを追加します。
sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --reload
$ sudo firewall-cmd --permanent --add-service=http $ sudo firewall-cmd --reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を有効にするには、Apache を有効にしてから起動します。
systemctl enable httpd systemctl start httpd
$ systemctl enable httpd $ systemctl start httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.5. OpenShift Container Platform システム
2.7.5.1. ホストの構築
この時点で、OpenShift Container Platform 環境の一部を構成するホストの初回作成を実行できます。最新バージョンの RHEL 7 を使用し、最小限のインストールを実行するようにしてください。また、OpenShift Container Platform に固有の前提条件にも注意する必要があります。
ホストの最初の構築が完了したら、リポジトリーのセットアップが可能になります。
2.7.5.2. リポジトリーの接続
OpenShift Container Platform のソフトウェアコンポーネントを必要とするすべての関連システムで、必須のリポジトリー定義を作成します。以下のテキストを /etc/yum.repos.d/ose.repo ファイルに入力し、 <server_IP> を、ソフトウェアリポジトリーをホストしている Apache サーバーの IP またはホスト名に置き換えます。
2.7.5.3. ホストの準備
この時点で、以下の OpenShift Container Platform ドキュメントに従ってシステムの準備を継続できます。
「ホスト登録」セクションを飛ばして、「基本パッケージのインストール」 に進んでください。
2.7.6. OpenShift Container Platform のインストール
2.7.6.1. OpenShift Container Platform Component イメージのインポート
関連するコンポーネントをインポートするには、接続したホストから OpenShift Container Platform の個々のホストにイメージを安全にコピーします。
scp /var/www/html/repos/images/ose3-images.tar root@<openshift_host_name>: ssh root@<openshift_host_name> "docker load -i ose3-images.tar" scp /var/www/html/images/ose3-builder-images.tar root@<openshift_master_host_name>: ssh root@<openshift_master_host_name> "docker load -i ose3-builder-images.tar"
$ scp /var/www/html/repos/images/ose3-images.tar root@<openshift_host_name>:
$ ssh root@<openshift_host_name> "docker load -i ose3-images.tar"
$ scp /var/www/html/images/ose3-builder-images.tar root@<openshift_master_host_name>:
$ ssh root@<openshift_master_host_name> "docker load -i ose3-builder-images.tar"インストールがコンテナー化される場合は、ホストコンポーネントに同じ手順を実行します。クラスターでメトリクスおよびロギングイメージを使用する場合は、それらについて同じ手順を実行します。
OpenShift Container Platform の各ホストで wget を使用して tar ファイルを取得し、Docker のインポートコマンドをローカルで実行することも可能です。
2.7.6.2. OpenShift Container Platform インストーラーの実行
ドキュメントに記載されている OpenShift Container Platform の クイックインストールまたは基本インストール (Advanced installation)方式のいずれかを選択できます。
コンテナー化インストールでは、etcd コンテナーをインストールする際に、Ansible 変数 osm_etcd_image をローカルレジストリーの etcd イメージの完全修飾名に設定します。例: registry.example.com/rhel7/etcd
2.7.6.3. 内部 Docker レジストリーの作成
ここで、内部 Docker レジストリーの作成が必要になります。
スタンドアロンレジストリーのインストールが必要な場合には、registry-console コンテナーイメージ をプルし、インベントリーファイルに deployment_subtype=registry を設定する必要があります。
2.7.7. インストール後の変更
上記の手順で、S2I イメージは、OpenShift Container Platform のいずれかのマスターホストで実行されている Docker デーモンにインポートされています。接続されたインストールにおいて、これらのイメージは、要求に応じて Red Hat のレジストリーからプルされます。これを実行するために必要なインターネットが使用できないため、イメージは別の Docker レジストリーで使用できるようにしておく必要があります。
OpenShift Container Platform は、S2I プロセスの結果としてビルドされるイメージを格納するための内部レジストリーを提供していますが、このレジストリーは S2I ビルダーイメージの保持するために使用することもできます。以下の手順は、ユーザーがサービス IP サブネット (172.30.0.0/16) または Docker レジストリーポート (5000) をカスタマイズしていない場合を想定しています。
2.7.7.1. S2I ビルダーイメージの再タグ付け
S2I ビルダーイメージをインポートしたマスターホストで、そのマスター上にインストールした Docker レジストリーのサービスアドレスを取得します。
export REGISTRY=$(oc get service -n default \ docker-registry --output=go-template='{{.spec.clusterIP}}{{"\n"}}')$ export REGISTRY=$(oc get service -n default \ docker-registry --output=go-template='{{.spec.clusterIP}}{{"\n"}}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、OpenShift Container Platform Docker レジストリーにプッシュする前に、同期し、エクスポートしたすべてのビルダーイメージにタグ付けします。たとえば、Tomcat イメージのみを同期し、エクスポートした場合、以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.7.2. レジストリーの場所の設定
registry.access.redhat.com にあるデフォルト以外のイメージレジストリーを使用する場合は、目的のレジストリーを /etc/ansible/hosts ファイル内に指定します。
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=trueレジストリーによっては、以下を設定することが必要になる場合があります。
openshift_docker_additional_registries=example.com openshift_docker_insecure_registries=example.com
openshift_docker_additional_registries=example.com
openshift_docker_insecure_registries=example.com
ホストの IP アドレスに openshift_docker_insecure_registries 変数を設定することもできます。0.0.0.0/0 は有効な設定ではありません。
| 変数 | 目的 |
|---|---|
|
|
代わりのイメージの場所に設定します。 |
|
|
デフォルト以外のレジストリーを参照している場合は |
|
|
|
|
|
|
2.7.7.3. 管理ユーザーの作成
コンテナーイメージを OpenShift Container Platform の Docker レジストリーにプッシュするには、ユーザーに cluster-admin 権限が必要です。OpenShift Container Platform のデフォルトのシステム管理者は標準の認証トークンを持っていないので、Docker レジストリーへのログインには使用できません。
管理ユーザーを作成するには、以下を実行します。
OpenShift Container Platform で使用している認証システムで新規ユーザーアカウントを作成します。たとえば、ローカルの
htpasswdベースの認証を使用している場合、以下のようになります。htpasswd -b /etc/openshift/openshift-passwd <admin_username> <password>
$ htpasswd -b /etc/openshift/openshift-passwd <admin_username> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、外部の認証システムにユーザーアカウントが作成されます。ただしユーザーは、アカウントが内部データベースに作成される前に OpenShift Container Platform にログインしている必要があります。作成されるアカウントで OpenShift Container Platform にログインしてください。ここでは、インストール時に OpenShift Container Platform で生成される自己署名証明書が使用されることを前提としています。
oc login --certificate-authority=/etc/origin/master/ca.crt \ -u <admin_username> https://<openshift_master_host>:8443$ oc login --certificate-authority=/etc/origin/master/ca.crt \ -u <admin_username> https://<openshift_master_host>:8443Copy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザーの認証トークンを取得します。
MYTOKEN=$(oc whoami -t) echo $MYTOKEN
$ MYTOKEN=$(oc whoami -t) $ echo $MYTOKEN iwo7hc4XilD2KOLL4V1O55ExH2VlPmLD-W2-JOd6FkoCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.7.4. セキュリティーポリシーの変更
oc loginを使用すると、新しいユーザーに切り替わります。ポリシーを変更するには、OpenShift Container Platform のシステム管理者に再度切り替えます。oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow イメージを OpenShift Container Platform Docker レジストリーにプッシュするには、アカウントに
image-builderセキュリティーロールが必要です。このロールを、OpenShift Container Platform 管理ユーザーに追加します。oc adm policy add-role-to-user system:image-builder <admin_username>
$ oc adm policy add-role-to-user system:image-builder <admin_username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、openshift プロジェクトのユーザーに管理者ロールを追加します。これで、管理ユーザーは openshift プロジェクトを編集できるようになります。ここでは、コンテナーイメージをプッシュします。
oc adm policy add-role-to-user admin <admin_username> -n openshift
$ oc adm policy add-role-to-user admin <admin_username> -n openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.7.5. イメージストリームの定義の編集
openshift プロジェクトでは、ビルダーイメージのすべてのイメージストリームはインストーラーによって作成されます。イメージストリームは、インストーラーが /usr/share/openshift/examples ディレクトリーから読み込まれます。OpenShift Container Platform のデータベースに読み込まれたイメージストリームを削除することですべての定義を変更し、これらを再作成します。
既存のイメージストリームを削除します。
oc delete is -n openshift --all
$ oc delete is -n openshift --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な場合、ファイルのバックアップを /usr/share/openshift/examples/ に作成します。次に、/usr/share/openshift/examples/image-streams フォルダーにあるファイル image-streams-rhel7.json を編集します。各ビルダーイメージにイメージストリームのセクションがあるはずです。
specスタンザを内部 Docker レジストリーを参照するように編集します。たとえば、以下のように変更します。
"from": { "kind": "DockerImage", "name": "registry.access.redhat.com/rhscl/httpd-24-rhel7" }"from": { "kind": "DockerImage", "name": "registry.access.redhat.com/rhscl/httpd-24-rhel7" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow これを以下のように変更します。
"from": { "kind": "DockerImage", "name": "172.30.69.44:5000/openshift/httpd-24-rhel7" }"from": { "kind": "DockerImage", "name": "172.30.69.44:5000/openshift/httpd-24-rhel7" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記では、リポジトリー名が rhscl から openshift に変更されています。リポジトリーが rhscl、openshift3、またはそれ以外のディレクトリーであるかどうかにかかわらず、変更を確認する必要があります。すべての定義に以下の形式が使用されます。
<registry_ip>:5000/openshift/<image_name>
<registry_ip>:5000/openshift/<image_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow この変更を、ファイル内のすべてのイメージストリームに対して繰り返し実行します。先の手順で判別した正しい IP アドレスが使用されていることを確認します。終了したら、保存して終了します。/usr/share/openshift/examples/xpaas-streams/jboss-image-streams.json ファイルにある JBoss イメージストリームについても同じ手順を繰り返します。
2.7.7.6. コンテナーイメージの読み込み
この時点で、システムはコンテナーイメージを読み込むことができます。
先の手順で取得したトークンとレジストリーのサービス IP を使って Docker レジストリーにログインします。
docker login -u adminuser -e mailto:adminuser@abc.com \ -p $MYTOKEN $REGISTRY:5000
$ docker login -u adminuser -e mailto:adminuser@abc.com \ -p $MYTOKEN $REGISTRY:5000Copy to Clipboard Copied! Toggle word wrap Toggle overflow Docker イメージをプッシュします。
docker push $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:1.1 docker push $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:1.2 docker push $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:latest
$ docker push $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:1.1 $ docker push $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:1.2 $ docker push $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新されたイメージストリームの定義を読み込みます。
oc create -f /usr/share/openshift/examples/image-streams/image-streams-rhel7.json -n openshift oc create -f /usr/share/openshift/examples/xpaas-streams/jboss-image-streams.json -n openshift
$ oc create -f /usr/share/openshift/examples/image-streams/image-streams-rhel7.json -n openshift $ oc create -f /usr/share/openshift/examples/xpaas-streams/jboss-image-streams.json -n openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのイメージストリームにタグが設定されていることを確認します。
oc get imagestreams -n openshift
$ oc get imagestreams -n openshift NAME DOCKER REPO TAGS UPDATED jboss-webserver30-tomcat7-openshift $REGISTRY/jboss-webserver-3/webserver30-jboss-tomcat7-openshift 1.1,1.1-2,1.1-6 + 2 more... 2 weeks ago ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.8. ルーターのインストール
この時点で、OpenShift Container Platform 環境はほとんど使用できる状態になります。ただし、ルーターのインストールと設定が必要になる場合もあります。
2.8. OpenShift Container レジストリーのスタンドアロンデプロイメントのインストール
2.8.1. OpenShift Container レジストリーについて
OpenShift Container Platform は、OpenShift Container レジストリー (OCR) と呼ばれる統合コンテナーレジストリーを含む完全な機能を備えたエンタープライズソリューションです。また、OpenShift Container Platform を開発者向けの完全な PaaS 環境としてデプロイする代わりに、 OCR をスタンドアロンのコンテナーレジストリーとしてインストールし、オンプレミスまたはクラウドで実行することも可能です。
OCR のスタンドアロンデプロイメントをインストールすると、標準的な OpenShift Container Platform のインストールと同様にマスターとノードのクラスターも引き続きインストールされます。次に、コンテナーレジストリーはそのクラスター上で実行されるようにデプロイされます。このスタンドアロンデプロイメントのオプションは、コンテナーレジストリーは必要だが、開発者向けの Web コンソールやアプリケーションのビルドおよびデプロイツールを含む OpenShift Container Platform の完全な環境は必要ない、という管理者に役立ちます。
OCR には以下の機能があります。
- ユーザー向けの レジストリー Web コンソール、Cockpit。
- デフォルトのセキュリティー保護されたトラフィック (TLS 経由で提供される)。
- グローバルなアイデンティティープロバイダー認証。
- チームがロールベースのアクセス制御 (RBAC) 認証を通じて連携できるようにするプロジェクト namespace モデル。
- サービスを管理するための Kubernetes ベースのクラスター。
- イメージ管理を強化するためのイメージストリームというイメージの抽象化。
管理者は、スタンドアロン OCR をデプロイすることで OpenShift Container Platform の複数のクラスターに対応しているレジストリーを個別に管理できます。また、スタンドアロン OCR を使うと、セキュリティーやコンプライアンスに関する独自の要件を満たすようにレジストリーを分離することも可能です。
2.8.2. ハードウェアの最小要件
スタンドアロン OCR をインストールするためのハードウェア要件は以下の通りです。
- 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
- ベース OS: RHEL 7.3、7.4、または 7.5 (RHEL 7 Extras チャンネルの「最小限の」インストールオプションおよび最新のパッケージ)、または、RHEL Atomic Host 7.4.5 以降。
- NetworkManager 1.0 以降
- 2 vCPU。
- 最小 16 GB の RAM。
- /var/ を含むファイルシステムの 15 GB 以上のハードディスク領域。
- Docker のストレージバックエンドに使用する 15 GB 以上の追加の未割り当て領域。詳細は「Docker ストレージの設定」を参照してください。
OpenShift Container Platform は、x86_64 アーキテクチャー搭載のサーバーのみをサポートします。
RHEL Atomic Host の /var/ のファイルシステムのサイジング要件を満たすには、デフォルト設定を変更する必要があります。インストール時またはインストール後にこの設定を行う方法については「Managing Storage in Red Hat Enterprise Linux Atomic Host」を参照してください。
2.8.3. サポートされているシステムトポロジー
以下のシステムトポロジーはスタンドアロン OCR でサポートされています。
|
オールインワン |
マスター、ノード、etcd、レジストリーの各コンポーネントを含む単一ホスト。 |
|
複数マスター (高可用性) |
すべてのコンポーネント (マスター、ノード、etcd、レジストリー) がそれぞれに含まれる 3 つのホスト。マスターはネイティブの高可用性を確保するように設定されます。 |
2.8.4. ホストの準備
スタンドアロン OCR をインストールする前に、完全な OpenShift Container Platform PaaS のインストールについて取り上げたホストの準備のトピックで説明している手順と同じ手順をすべて実行する必要があります。この手順には、適切なリポジトリーへのホストの登録とサブスクライブ、特定パッケージのインストールまたは更新、Docker とそのストレージ要件のセットアップなどが含まれます。
ホストの準備 の各手順を実行し、スタンドアロンレジストリーのインストール方法に進んでください。
2.8.5. スタンドアロンレジストリーのインストール方法
スタンドアロンレジストリーをインストールするには、OpenShift Container Platform の他のバージョンをインストールする際に使用した標準のインストール方式 (クイックインストールまたは通常インストール (Advanced installation)) のいずれかを使用します。
2.8.5.1. スタンドアロン OpenShift Container レジストリーのクイックインストール
OpenShift Container Platform 3.9 の時点で、クイックインストールは廃止予定です。今後のリリースでは完全になくなります。また、クイックインストーラーによるバージョン 3.7 から 3.9 へのアップグレードはサポートされていません。
以下では、OpenShift Container Platform をすべてインストールするのではなく、クイックインストールツールを実行して OpenShift Container レジストリーをインストールする方法を順を追って説明します。
対話型インストールを開始します。
atomic-openshift-installer install
$ atomic-openshift-installer installCopy to Clipboard Copied! Toggle word wrap Toggle overflow 画面の指示に従って新規レジストリーをインストールします。インストールに関する質問は、OpenShift Container Platform PaaS をすべてインストールする場合とほとんど同じです。以下の画面まで進んだら、
2を選択してレジストリーのインストールパスに従ってください。Which variant would you like to install? (1) OpenShift Container Platform (2) Registry
Which variant would you like to install? (1) OpenShift Container Platform (2) RegistryCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターを構成しているホストを指定します。
Enter hostname or IP address: Will this host be an OpenShift master? [y/N]: Will this host be RPM or Container based (rpm/container)? [rpm]:
Enter hostname or IP address: Will this host be an OpenShift master? [y/N]: Will this host be RPM or Container based (rpm/container)? [rpm]:Copy to Clipboard Copied! Toggle word wrap Toggle overflow RPM とコンテナー化ホストとの比較に関する情報は、コンテナー化ホストでのインストールのトピックを参照してください。
必要な場合は、クラスターのホスト名を変更します。
Enter hostname or IP address [None]:
Enter hostname or IP address [None]:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ストレージホストとして機能するホストを選択します (デフォルトではマスターホスト)。
Enter hostname or IP address [master.host.example.com]:
Enter hostname or IP address [master.host.example.com]:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な場合は、デフォルトのサブドメインを変更します。
New default subdomain (ENTER for none) []:
New default subdomain (ENTER for none) []:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記すべての証明書とルートはこのサブドメインで作成されます。インストール後に設定を変更しなくてすむように、これが適切なサブドメインに設定されていることを確認してください。
必要に応じて HTTP または HTTPS プロキシーを指定します。
Specify your http proxy ? (ENTER for none) []: Specify your https proxy ? (ENTER for none) []:
Specify your http proxy ? (ENTER for none) []: Specify your https proxy ? (ENTER for none) []:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
上記を入力したら、次ページでインストールの概要が示され、ホスト情報の収集が開始されます。
以下の手順を含む、一般的なクイックインストーラーの使用に関する詳細は、「クイックインストール」のトピックすべてを参照してください。
2.8.5.2. スタンドアロン OpenShift Container レジストリーの通常インストール (Advanced installation)
通常インストール (Advanced installation) 方式を使ってスタンドアロン OCR をインストールする際に、「通常インストール (Advanced installation)」のトピックで説明されている Ansible を使用した OpenShift Container Platform PaaS のインストールと同じ手順を使用します。大きな違いとして、ここでは Playbook がレジストリーのインストールパスをたどれるよう、インベントリーファイルの [OSEv3:vars] セクションに deployment_subtype=registry を設定する必要があります。
以下は、サポートされている複数の異なるシステムトポロジー用のインベントリーファイルの例です。
オールインワンのスタンドアロン OpenShift Container レジストリーインベントリーファイル
複数マスター (高可用性) スタンドアロン OpenShift Container レジストリーインベントリーファイル
- 1
deployment_subtype=registryを設定して、OpenShift Container Platform 環境のすべてではなく、スタンドアロン OCR がインストールされるようにします。
/etc/ansible/hosts でインベントリーファイルを定義して Ansible を設定した後に、以下を実行します。
prerequisites.yml Playbook を実行してベースパッケージと Docker を設定します。これは、新規クラスターをデプロイする前に 1 回だけ実行します。インベントリーファイルが /etc/ansible/hosts 以外の場所にある場合には、
-iを指定して以下のコマンドを実行します。重要Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。
ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml# ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/prerequisites.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow deploy_cluster.yml Playbook を実行してインストールを開始します。
ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml# ansible-playbook [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
通常インストール (Advanced installation) 方式に関する詳細 (使用可能な Ansible 変数の一覧を含む) は、「通常インストール (Advanced installation)」 のトピックすべてを参照してください。
第3章 レジストリーのセットアップ
3.1. レジストリーの概要
3.1.1. レジストリーについて
OpenShift Container Platform は、ソースコードからコンテナーイメージをビルドし、デプロイし、そのライフサイクルを管理することができます。これを有効にするために、OpenShift Container Platform は、イメージをローカルで管理するために OpenShift Container Platform 環境にデプロイできる内部の統合 Docker レジストリーを提供しています。
3.1.2. 統合レジストリーまたはスタンドアロンレジストリー
完全な OpenShift Container Platform クラスターの初回インストール時に、レジストリーはインストールプロセスで自動的にデプロイされている可能性があります。自動的にデプロイされていなかった場合やレジストリー設定のカスタマイズが追加で必要になる場合には、「既存クラスターへのレジストリーのデプロイ」を参照してください。
OpenShiftコンテナプラットフォームの完全な統合された部分として実行するために展開することができますが、OpenShiftコンテナプラットフォームのレジストリは、スタンドアロンのコンテナイメージレジストリとして別々にインストールすることもできます。
スタンドアロンレジストリーをインストールするには、スタンドアロンレジストリーのインストールの手順に従ってください。このインストールパスは、レジストリーと専用の Web コンソールを実行するオールインワンのクラスターをデプロイします。
3.2. 既存クラスターへのレジストリーのデプロイ
3.2.1. 概要
OpenShift Container Platform クラスターの初回インストール時に統合レジストリーが事前に自動的にデプロイされなかった場合や、正常に実行されず、既存のクラスターに再デプロイする必要がある場合は、以下のセクションで新規レジストリーをデプロイするためのオプションを参照してください。
スタンドアロンレジストリーをインストールしていない場合、このトピックは不要になります。
3.2.2. レジストリーのデプロイ
統合 Docker レジストリーをデプロイするには、クラスター管理者権限を持つユーザーとして oc adm registry コマンドを使用します。以下は例になります。
oc adm registry --config=/etc/origin/master/admin.kubeconfig \
--service-account=registry \
--images='registry.access.redhat.com/openshift3/ose-${component}:${version}'
$ oc adm registry --config=/etc/origin/master/admin.kubeconfig \
--service-account=registry \
--images='registry.access.redhat.com/openshift3/ose-${component}:${version}' これでサービスとデプロイメント設定が作成されます。これらは共に docker-registry と呼ばれます。正常にデプロイされると、Pod が docker-registry-1-cpty9 などの名前付きで作成されます。
レジストリーの作成時に指定できるオプションの詳細の一覧を表示するには、以下を実行します。
oc adm registry --help
$ oc adm registry --help
--fs-group の値は、レジストリーが使用している SCC (通常は制限付き SCC) によって許可されている必要があります。
3.2.3. レジストリーを DaemonSet としてデプロイする
レジストリーを --daemonset オプションを使用して DaemonSetとしてデプロイするには、 oc adm registry コマンドを使用します。
デーモンセットでは、ノードが作成されるときに、指定されたポッドのコピーが含まれます。ノードが削除されると、ポッドはガベージコレクションされます。
DaemonSetに関する詳細は、「Daemonset の使用」を参照してください。
3.2.4. レジストリーのコンピュートリソース
デフォルトでは、レジストリーはコンピュートリソースの要求や制限に関する設定がない状態で作成されます。実稼働環境では、レジストリーのデプロイメント設定を更新してレジストリー Pod のリソース要求や制限を設定しておくことが強く推奨されます。設定しない場合、レジストリー Pod は BestEffort Pod と判断されます。
要求や制限の設定に関する詳細は、「コンピュートリソース」を参照してください。
3.2.5. レジストリーのストレージ
レジストリーには、コンテナーのイメージとメタデータが格納されています。Pod をレジストリーと共に単純にデプロイする場合、Pod がすでに存在する場合に破棄される一時ボリュームが使用されます。この場合、誰かがビルドしたりレジストリーにプッシュしたりしたイメージは消えてしまいます。
以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。
次の一覧には、レジストリの構成ファイルで構成する必要があるストレージドライバが含まれています。
- ファイルシステム。ファイルシステムはデフォルトですので、設定の必要はありません。
- S3。詳細は、CloudFront の設定のドキュメントを参照してください。
- OpenStack Swift
- Google Cloud Storage (GCS)
- Microsoft Azure
- Aliyun OSS
レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。
以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。
サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。
3.2.5.1. 実稼働環境での使用
実稼働環境での使用の場合には、リモートボリュームを割り当てるか、または各自が選択した永続ストレージ方法を定義して使用します。
たとえば、既存の Persistent Volume Claim (永続ボリューム要求) を使用するには、以下を実行します。
oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
--claim-name=<pvc_name> --overwrite
$ oc volume deploymentconfigs/docker-registry --add --name=registry-storage -t pvc \
--claim-name=<pvc_name> --overwriteテストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
3.2.5.1.1. Amazon S3 をストレージのバックエンドとして使用する
Amazon Simple Storage Service のストレージを内部 Docker レジストリーと共に使用する方法もあります。Amazon Simple Storage Service は AWS マネジメントコンソールで管理できるセキュアなクラウドストレージです。これを使用するには、レジストリーの設定ファイルを手動で編集し、レジストリー Pod にマウントする必要があります。ただし、設定を開始する前にアップストリームの推奨される手順を確認してください。
デフォルトの YAML 設定ファイルをベースとして取得し、storageセクションのfilesystemエントリーを、以下のように s3 エントリーに置き換えます。これにより、ストレージのセクションは以下のようになります。
s3 のすべての設定オプションは、アップストリームのドライバー参照ドキュメントに記載されています。
レジストリー設定を上書きすると、設定ファイルを Pod にマウントするための追加の手順に進みます。
レジストリーが S3 ストレージのバックエンドで実行されると、問題が報告されます。
3.2.5.2. 非実稼働環境での使用
非実稼働環境の場合、--mount-host=<path> オプションを使って、永続ストレージに使用するレジストリーのディレクトリーを指定します。次に、レジストリーのボリュームがホストのマウントとして、指定された <path> に作成されます。
--mount-host オプションは、レジストリーのコンテナーが実行されているノードからディレクトリーをマウントします。docker-registry デプロイメント設定をスケールアップすると、レジストリー Pod とコンテナーが別々のノードで実行され、2 つ以上のレジストリーコンテナーがそれぞれのローカルストレージと共に作成される可能性があります。これは予期しない動作を生じさせます。その後に繰り返される同一イメージのプル要求が最終的に到達するコンテナーによっては必ずしも成功しない場合があるためです。
--mount-host オプションは、レジストリーコンテナーを特権モードで実行することを要求します。この要求は、ユーザーが --mount-host を指定すると自動的に有効にされます。ただしデフォルトでは、すべての Pod が特権付きコンテナー を実行できる訳ではありません。それでもこのオプションの使用する必要がある場合は、レジストリーを作成してから、レジストリーがインストール時に作成された registry サービスアカウントを使用するように指定してください。
oc adm registry --service-account=registry \
--config=/etc/origin/master/admin.kubeconfig \
--images='registry.access.redhat.com/openshift3/ose-${component}:${version}' \
--mount-host=<path>
$ oc adm registry --service-account=registry \
--config=/etc/origin/master/admin.kubeconfig \
--images='registry.access.redhat.com/openshift3/ose-${component}:${version}' \
--mount-host=<path>Docker レジストリー Pod は、ユーザー 1001 として実行されます。このユーザーは、ホストのディレクトリーへの書き込みができなければなりません。したがって、以下のコマンドでディレクトリーの所有権をユーザー ID 1001 に変更する必要がある場合があります。
sudo chown 1001:root <path>
$ sudo chown 1001:root <path>3.2.6. レジストリーコンソールの有効化
OpenShift Container Platform は、統合レジストリーへの Web ベースのインターフェースを提供します。このレジストリーコンソールは、イメージの参照と管理を行うためのオプションのコンポーネントであり、Pod として実行されるステートレスサービスとしてデプロイされます。
OpenShift Container Platform をスタンドアロンレジストリーとしてインストールした場合、レジストリーコンソールはインストール時にすでにデプロイされ、そのセキュリティーが自動的に保護されています。
Cockpit がすでに実行されている場合、レジストリーコンソールとのポート競合 (デフォルトでは9090) を避けるために、次に進む前にこれをシャットダウンする必要があります。
3.2.6.1. レジストリーコンソールのデプロイ
最初にレジストリーを公開しておく必要があります。
デフォルトのプロジェクトにパススルールートを作成します。このルートは、以下の手順でレジストリーコンソールのアプリケーションを作成する際に必要になります。
oc create route passthrough --service registry-console \ --port registry-console \ -n default$ oc create route passthrough --service registry-console \ --port registry-console \ -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーコンソールのアプリケーションをデプロイします。
<openshift_oauth_url>を OpenShift Container Platform OAuth プロバイダー の URL に置き換えます。通常これはマスターになります。oc new-app -n default --template=registry-console \ -p OPENSHIFT_OAUTH_PROVIDER_URL="https://<openshift_oauth_url>:8443" \ -p REGISTRY_HOST=$(oc get route docker-registry -n default --template='{{ .spec.host }}') \ -p COCKPIT_KUBE_URL=$(oc get route registry-console -n default --template='https://{{ .spec.host }}')$ oc new-app -n default --template=registry-console \ -p OPENSHIFT_OAUTH_PROVIDER_URL="https://<openshift_oauth_url>:8443" \ -p REGISTRY_HOST=$(oc get route docker-registry -n default --template='{{ .spec.host }}') \ -p COCKPIT_KUBE_URL=$(oc get route registry-console -n default --template='https://{{ .spec.host }}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記レジストリーコンソールへのログインの試行時にリダイレクト URL が間違っていた場合は、
oc get oauthclientsで OAuth クライアントを確認してください。- 最後に、Webブラウザを使用してルートURIを使用してコンソールを表示します。
3.2.6.2. レジストリーコンソールのセキュリティー保護
デフォルトでは、レジストリーコンソールは、レジストリーコンソールのデプロイの手順ごとに手動でデプロイされる場合に自己署名 TLS 証明書を生成します。詳細は、「レジストリーコンソールのトラブルシューティング」を参照してください。
組織の署名済み証明書をシークレットボリュームとして追加する際には、以下の手順に従ってください。ここでは、証明書が oc クライアントホストで利用可能であることを前提としています。
証明書とキーを含む .cert ファイルを作成します。以下を使用してファイルをフォーマットします。
- サーバー証明書と中間証明機関のための 1 つ以上数の BEGIN CERTIFICATE ブロック。
キーの BEGIN PRIVATE KEY または同種のものを含むブロック。キーは暗号化することができません。
例を以下に示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow セキュリティーの保護されたレジストリーには、以下の SAN (サブジェクトの別名: Subject Alternative Names) 一覧が含まれているはずです。
2 つのサービスのホスト名。
例を以下に示します。
docker-registry.default.svc.cluster.local docker-registry.default.svc
docker-registry.default.svc.cluster.local docker-registry.default.svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービス IP アドレス。
例を以下に示します。
172.30.124.220
172.30.124.220Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使って Docker レジストリーのサービス IP アドレスを取得します。
oc get service docker-registry --template='{{.spec.clusterIP}}'oc get service docker-registry --template='{{.spec.clusterIP}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow パブリックホスト名。
例を以下に示します。
docker-registry-default.apps.example.com
docker-registry-default.apps.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使って Docker レジストリーのパブリックホスト名を取得します。
oc get route docker-registry --template '{{.spec.host}}'oc get route docker-registry --template '{{.spec.host}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、サーバー証明書には以下のような SAN の詳細が記載されるはずです。
X509v3 Subject Alternative Name: DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98X509v3 Subject Alternative Name: DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98Copy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーコンソールは、証明書を /etc/cockpit/ws-certs.d ディレクトリーから読み込み、拡張子 .cert が付いたファイルをアルファベット順で (最後から) 使用します。したがって .cert ファイルには、 OpenSSL スタイルでフォーマットされた PEM ブロックが少なくとも 2 つ含まれている必要があります。
証明書がない場合、自己署名証明書が
opensslコマンドで作成され、0-self-signed.cert ファイルに保存されます。
シークレットを作成します。
oc create secret generic console-secret \ --from-file=/path/to/console.cert$ oc create secret generic console-secret \ --from-file=/path/to/console.certCopy to Clipboard Copied! Toggle word wrap Toggle overflow このシークレットを registry-console デプロイメント設定に追加します。
oc volume dc/registry-console --add --type=secret \ --secret-name=console-secret -m /etc/cockpit/ws-certs.d$ oc volume dc/registry-console --add --type=secret \ --secret-name=console-secret -m /etc/cockpit/ws-certs.dCopy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、レジストリーコンソールの新規デプロイメントがトリガーされ、署名済み証明書が組み込まれます。
3.2.6.3. レジストリーコンソールのトラブルシューティング
3.2.6.3.1. デバッグモード
レジストリーコンソールのデバッグモードは環境変数を使用して有効にされます。以下のコマンドは、レジストリーコンソールをデバッグモードで再デプロイします。
oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper
$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapperデバッグモードを有効にすると、より詳細なログがレジストリーコンソールの Pod ログに表示されます。
3.2.6.3.2. SSL 証明書パスの表示
レジストリーコンソールが使用している証明書を確認するには、コマンドをコンソール Pod から実行します。
デフォルト のプロジェクトに Pod を一覧表示して、レジストリーコンソールの Pod 名を検索します。
oc get pods -n default
$ oc get pods -n default NAME READY STATUS RESTARTS AGE registry-console-1-rssrw 1/1 Running 0 1dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 直前のコマンドで取得した Pod 名を使って、cockpit-ws プロセスが使用している証明書パスを取得します。以下は、自動生成された証明書を使用しているコンソールの例です。
oc exec registry-console-1-rssrw remotectl certificate
$ oc exec registry-console-1-rssrw remotectl certificate certificate: /etc/cockpit/ws-certs.d/0-self-signed.certCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. レジストリーへのアクセス
3.3.1. ログの表示
Docker レジストリーのログを表示するには、デプロイメント設定で oc logs コマンドを使用します。
3.3.2. ファイルストレージ
タグとイメージメタデータは OpenShift Container Platform に格納されますが、レジストリーは、レイヤーと署名データを /registry にあるレジストリーコンテナーにマウントされているボリュームに格納します。oc exec は特権付きコンテナーでは機能しないため、レジストリーの内容を確認するには、レジストリー Pod のコンテナーを格納しているノードに対して SSH を手動で実行し、コンテナー自体で docker exec を実行します。
現在の Pod を一覧表示し、Docker レジストリーの Pod 名を検索します。
oc get pods
# oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、
oc describeを使用して、コンテナーを実行しているノードのホスト名を検索します。oc describe pod <pod_name>
# oc describe pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なノードにログインします。
＃ssh node.example.com
＃ssh node.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードホストのデフォルトプロジェクトから実行中のコンテナーを一覧表示し、Docker レジストリーのコンテナー ID を特定します。
＃docker ps --filter = name = registry_docker-registry。* _ default_
＃docker ps --filter = name = registry_docker-registry。* _ default_Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc rshコマンドを使用してレジストリーの内容を一覧表示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このディレクトリーには、すべてのレイヤーと署名が Blob として格納されます。
- 2
- このファイルには、Blob の内容が含まれます。
- 3
- このディレクトリーには、すべてのイメージリポジトリーが格納されます。
- 4
- このディレクトリーは単一イメージリポジトリーの p1/pause 用です。
- 5
- このディレクトリーには、特定のイメージマニフェストリビジョンの署名が含まれます。
- 6
- このファイルには、Blob (署名データを含む) への参照が含まれます。
- 7
- このディレクトリーには、指定されたリポジトリーに対して現在アップロードされステージングされているすべてのレイヤーが含まれます。
- 8
- このディレクトリーには、このリポジトリーが参照するすべてのレイヤーへのリンクが含まれます。
- 9
- このファイルには、イメージを介してこのリポジトリーにリンクされている特定のレイヤーへの参照が含まれます。
3.3.3. レジストリーへの直接アクセス
さらに高度な使用方法として、レジストリーに直接アクセスし、docker コマンドを起動することが可能です。これにより、docker push や docker pull などの操作で直接イメージをプッシュするか、または統合レジストリーからイメージをプルすることができます。これを実行するには、docker login コマンドを使ってレジストリーにログインしている必要があります。実行できる操作は、以下のセクションで説明されているようにユーザーが持つ権限によって異なります。
3.3.3.1. ユーザーの前提条件
レジストリーに直接アクセスするには、使用するユーザーが、使用目的に応じて以下の前提条件を満たしている必要があります。
直接アクセスするには、ユーザーは選択するアイデンティティープロバイダーの通常ユーザーである必要があります。通常ユーザーは、レジストリーへのログインに必要なアクセストークンを生成できます。system:admin などのシステムユーザーはアクセストークンを取得できないため、レジストリーに直接アクセスすることはできません。
たとえば
HTPASSWD認証を使用している場合は、以下のコマンドを使用してこれを作成することができます。htpasswd /etc/origin/openshift-htpasswd <user_name>
# htpasswd /etc/origin/openshift-htpasswd <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow docker pullコマンドを使用する場合などにイメージをプルするには、ユーザーに registry-viewer ロールがなければなりません。このロールを追加するには、以下を実行します。oc policy add-role-to-user registry-viewer <user_name>
$ oc policy add-role-to-user registry-viewer <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow イメージの書き出しやプッシュを実行するには (
docker pushコマンドを使用する場合など)、ユーザーに registry-editor ロールが必要です。このロールを追加するには、以下を実行します。oc policy add-role-to-user registry-editor <user_name>
$ oc policy add-role-to-user registry-editor <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ユーザーパーミッションに関する詳細は、「ロールバインディングの管理」を参照してください。
3.3.3.2. レジストリーへのログイン
ユーザーが、レジストリーに直接アクセスできるための前提条件を満たしていることを確認してください。
レジストリーに直接ログインするには、以下を実行します。
OpenShift Container Platform に通常ユーザーとしてログインしていることを確認します。
oc login
$ oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow アクセストークンを使用して Docker レジストリーにログインします。
docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>
docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ユーザー名の任意の値を渡すことができ、トークンには必要な情報がすべて含まれます。コロンを含むユーザー名を渡すとログインに失敗します。
3.3.3.3. イメージのプッシュとプル
レジストリーにログインすると、レジストリーに docker pull および docker push 操作を実行できます。
任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。
以下の例では、以下を使用します。
|
コンポーネント |
値 |
|
<registry_ip> |
|
|
<port> |
|
|
<project> |
|
|
<image> |
|
|
<tag> |
省略 (デフォルトは |
任意のイメージをプルします。
docker pull docker.io/busybox
$ docker pull docker.io/busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規イメージに
<registry_ip>:<port>/<project>/<image>形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするには OpenShift Container Platform のプル仕様に必ず表示されている必要があります。dockerタグdocker.io/busybox 172.30.124.220:5000/openshift/busybox
$ dockerタグdocker.io/busybox 172.30.124.220:5000/openshift/busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記通常ユーザーには、指定されたプロジェクトの system:image-builder ロールが必要です。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。このロールが設定されていない場合には以下の手順の
docker pushが失敗します。新規プロジェクトを作成して busybox イメージをプッシュしてみることができます。新しくタグ付けされたイメージをレジストリーにプッシュします。
docker push 172.30.124.220:5000/openshift/busybox
$ docker push 172.30.124.220:5000/openshift/busybox ... cf2616975b4a: Image successfully pushed Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.4. レジストリーメトリクスへのアクセス
OpenShift Container レジストリーは、Prometheus メトリクス のエンドポイントを提供します。Prometheus はスタンドアロンのオープンソースシステムのモニタリングおよびアラートツールキットです。
メトリクスはレジストリーのエンドポイントの /extensions/v2/metrics パスに公開されます。ただし、このルートは最初に有効にされている必要があります。有効化の方法については、「レジストリー設定の拡張」を参照してください。
以下は、メトリクスクエリーの簡単な例です。
高度なクエリーと推奨されるビジュアライザーについては、アップストリームの Prometheus ドキュメントを参照してください。
3.4. レジストリーのセキュリティー保護および公開
3.4.1. 概要
デフォルトでは、OpenShift Container Platform レジストリーは、TLS 経由でトラフィックを提供できるようクラスターのインストール時にセキュリティー保護されます。サービスを外部に公開するために、パススルールートもデフォルトで作成されます。
何らかの理由でレジストリーが保護されていないか、または公開されていない場合は、これらを手動で実行する方法について以下のセクションを参照してください。
3.4.2. レジストリーを手動でセキュリティー保護する
レジストリーを手動でセキュリティー保護して TLS 経由でトラフィックを処理するには、以下を実行します。
- レジストリーをデプロイします。
レジストリーのサービス IP とポートを取得します。
oc get svc/docker-registry
$ oc get svc/docker-registry NAME LABELS SELECTOR IP(S) PORT(S) docker-registry docker-registry=default docker-registry=default 172.30.124.220 5000/TCPCopy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のサーバー証明書を使用するか、またはキーと、指定された CA で署名された指定 IP およびホスト名に有効なサーバー証明書を作成します。レジストリーのサービス IP と docker-registry.default.svc.cluster.local ホスト名のサーバー証明書を作成するには、Ansible ホストインベントリーファイル (デフォルトでは /etc/ansible/hosts) に一覧表示されている最初のマスターから以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルーターを外部に公開する場合、公開ルートのホスト名を
--hostnamesフラグに追加します。--hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \
--hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートを外部にアクセス可能にするためにデフォルトの証明書を更新する際のその他詳細については、「レジストリーとルーター証明書の再デプロイ」を参照してください。
注記oc adm ca create-server-certコマンドは、2 年間有効な証明書を生成します。この期間は--expire-daysオプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。レジストリー証明書のシークレットを作成します。
oc create secret generic registry-certificates \ --from-file=/etc/secrets/registry.crt \ --from-file=/etc/secrets/registry.key$ oc create secret generic registry-certificates \ --from-file=/etc/secrets/registry.crt \ --from-file=/etc/secrets/registry.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットをレジストリー Pod のサービスアカウント (デフォルトのサービスアカウントなど) に追加します。
oc secrets link registry registry-certificates oc secrets link default registry-certificates
$ oc secrets link registry registry-certificates $ oc secrets link default registry-certificatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記シークレットをそれを参照しているサービスアカウントのみに制限することは、デフォルトで無効にされています。つまり、マスターの設定ファイルで
serviceAccountConfig.limitSecretReferencesがfalse(デフォルトの設定) に設定されている場合、シークレットをサービスにリンクさせる必要はありません。docker-registryサービスを一時停止します。oc rollout pause dc / docker-registry
$ oc rollout pause dc / docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットボリュームをレジストリーのデプロイメント設定に追加します。
oc volume dc/docker-registry --add --type=secret \ --secret-name=registry-certificates -m /etc/secrets$ oc volume dc/docker-registry --add --type=secret \ --secret-name=registry-certificates -m /etc/secretsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の環境変数をレジストリーのデプロイメント設定に追加して TLS を有効にします。
oc set env dc/docker-registry \ REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \ REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key$ oc set env dc/docker-registry \ REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \ REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.keyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、「Docker ドキュメントのレジストリーの設定」セクションを参照してください。
レジストリーの liveness probe に使用されているスキームを HTTP から HTTPS に更新します。
oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{$ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{ "name":"registry", "livenessProbe": {"httpGet": {"scheme":"HTTPS"}} }]}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーを OpenShift Container Platform 3.2 以降に初めてデプロイした場合は、レジストリーの readiness probe として使用されているスキームを HTTP から HTTPS に更新します。
oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{$ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{ "name":"registry", "readinessProbe": {"httpGet": {"scheme":"HTTPS"}} }]}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow docker-registryサービスを再開します。oc rollout dc / docker-registryを再開する
$ oc rollout dc / docker-registryを再開するCopy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーが TLS モードで実行されていることを検証します。最後の docker-registry のデプロイメントが完了するまで待機し、Docker ログでレジストリーコンテナーを確認します。
listening on :5000, tlsのエントリーが見つかるはずです。oc logs dc/docker-registry | grep tls
$ oc logs dc/docker-registry | grep tls time="2015-05-27T05:05:53Z" level=info msg="listening on :5000, tls" instance.id=deeba528-c478-41f5-b751-dc48e4935fc2Copy to Clipboard Copied! Toggle word wrap Toggle overflow CA 証明書を Docker 証明書ディレクトリーにコピーします。これはクラスター内のすべてのノードで実行する必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ca.crt ファイルは、マスター上の /etc/origin/master/ca.crt のコピーです。
認証を使用している場合、
dockerのバージョンによっては、OS レベルで証明書を信頼するようにクラスターを設定することも必要になります。証明書をコピーします。
cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
$ cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下を実行します。
update-ca-trust enable
$ update-ca-trust enableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
/etc/sysconfig/docker ファイルのこの特定のレジストリーに対してのみ、
--insecure-registryオプションを削除します。次にデーモンを再度読み込み、 docker サービスを再起動して設定の変更を反映させます。sudo systemctl daemon-reload sudo systemctl restart docker
$ sudo systemctl daemon-reload $ sudo systemctl restart dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow dockerクライアント接続を検証します。レジストリーに対するdocker push、またはレジストリーからのdocker pullが正常に実行されるはずです。必ずこのレジストリーにログインしていることを確認してください。docker tag|push <registry/image> <internal_registry/project/image>
$ docker tag|push <registry/image> <internal_registry/project/image>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.3. セキュアなレジストリーの手動による公開
OpenShift Container Platform レジストリーに OpenShift Container Platform クラスター内からログインする代わりに、最初にレジストリーのセキュリティーを保護し、それをルートで公開しておくことによって、これに外部からアクセスすることも可能です。この方法を使うと、ルートアドレスを使ってクラスターの外部からレジストリーにログインし、ルートのホストを使ってイメージにタグ付けしたり、イメージをプッシュしたりできます。
以下の前提条件に関するそれぞれの手順は、標準的なクラスターのインストール時にデフォルトで実行されます。これが実行されていない場合は、手動で実行してください。
パススルールートは、クラスターの初回インストール時にこのレジストリーについてデフォルトで作成されている必要があります。
ルートが存在するかどうかを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Re-encrypt ルートはセキュアなレジストリーを公開するためにもサポートされています。
ルートが存在していない場合、
oc create route passthroughコマンドで、レジストリーをルートのサービスとして指定してルートを作成します。デフォルトでは、作成したルートの名前はサービス名と同じです。docker-registry サービスの詳細を取得します。
oc get svc
$ oc get svc NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE docker-registry 172.30.69.167 <none> 5000/TCP docker-registry=default 4h kubernetes 172.30.0.1 <none> 443/TCP,53/UDP,53/TCP <none> 4h router 172.30.172.132 <none> 80/TCP router=router 4hCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルートを作成します。
oc create route passthrough \ --service=docker-registry \ --hostname=<host>$ oc create route passthrough \ --service=docker-registry \1 --hostname=<host> route "docker-registry" created2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次に、ホストシステム上のレジストリーに使用されている証明書を信頼し、ホストによるイメージのプッシュおよびプルを許可する必要があります。参照される証明書は、レジストリーのセキュリティー保護を実行したときに作成されたものです。
sudo mkdir -p /etc/docker/certs.d/<host> sudo cp <ca_certificate_file> /etc/docker/certs.d/<host> sudo systemctl restart docker
$ sudo mkdir -p /etc/docker/certs.d/<host> $ sudo cp <ca_certificate_file> /etc/docker/certs.d/<host> $ sudo systemctl restart dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーのセキュリティー保護の実行時に得られた情報を使ってレジストリーにログインします。ただし、ここではサービス IP ではなくルートで使用されているホスト名を指定します。セキュリティーが保護され、公開されているレジストリーにログインする際は、必ず
docker loginコマンドのレジストリーを指定してください。docker login -e user@company.com \ -u f83j5h6 \ -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \ <host># docker login -e user@company.com \ -u f83j5h6 \ -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \ <host>Copy to Clipboard Copied! Toggle word wrap Toggle overflow これでルートのホストを使ってイメージのタグ付けとプッシュを実行できます。たとえば、
testという名前のプロジェクトにあるbusyboxイメージをタグ付けし、プッシュするには、以下を実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記イメージストリームにはルート名とポートではなく、レジストリーサービスの IP アドレスとポートが設定されます。詳細は
oc get imagestreamsを参照してください。
3.4.4. 非セキュアなレジストリーを手動で公開する
レジストリーのセキュリティーを確保してレジストリーを公開する代わりに、OpenShift Container Platform の非稼働環境に、セキュアでないレジストリーを簡単に公開できます。これにより、SSL 証明書を使用せずにレジストリーへの外部ルートを作成することができます。
非実稼働環境以外では、非セキュアなレジストリーを外部アクセスに公開すべきではありません。
非セキュアなレジストリーを公開するには、以下を実行します。
レジストリーを公開します。
oc expose service docker-registry --hostname=<hostname> -n default
# oc expose service docker-registry --hostname=<hostname> -n defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の JSON ファイルが作成されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートが正常に作成されたことを確認します。
oc get route
# oc get route NAME HOST/PORT PATH SERVICE LABELS INSECURE POLICY TLS TERMINATION docker-registry registry.example.com docker-registry docker-registry=defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーの健全性を確認します。
curl -v http://registry.example.com/healthz
$ curl -v http://registry.example.com/healthzCopy to Clipboard Copied! Toggle word wrap Toggle overflow HTTP 200 / OK メッセージが表示されるはずです。
レジストリーを公開したら、ポート番号を
OPTIONSエントリーに追加して /etc/sysconfig/docker ファイルを更新します。以下は例になります。OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'
OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要上記のオプションは、ログインしようとしているクライアントに追加してください。
また、Docker がクライアント上で実行されていることも確認してください。
公開されている非セキュアなレジストリーにログインする際に、docker login コマンドでレジストリーを指定していることを確認します。以下は例になります。
docker login -e user@company.com \
-u f83j5h6 \
-p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
<host>
# docker login -e user@company.com \
-u f83j5h6 \
-p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
<host>3.5. レジストリー設定の拡張
3.5.1. レジストリー IP アドレスの維持
OpenShift Container Platform はサービス IP アドレスによって統合レジストリーを参照します。したがって docker-registry サービスを削除し、再作成しようとする場合、古い IP アドレスを新しいサービスで再利用するように調整すると、完全に透過的な移行が可能になります。新規 IP アドレスを取得することが避けられない場合は、マスターのみを再起動してクラスターの中断を最小限に抑えられます。
- アドレスの再利用
- IP アドレスを再利用するには、古い docker-registry サービスの IP アドレスを削除する前に保存し、新たに割り当てられた IP アドレスを、新しい docker-registry サービスに保存されているアドレスに置き換えるように調整します。
サービスの
clusterIPを書き留めておきます。oc get svc/docker-registry -o yaml | grep clusterIP:
$ oc get svc/docker-registry -o yaml | grep clusterIP:Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスを削除します。
oc delete svc / docker-registry dc / docker-registry
$ oc delete svc / docker-registry dc / docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーの定義を registry.yaml に作成し、
<options>を、たとえば「非実稼働環境での使用」のセクションの手順 3 で使用されているものなどに置き換えます。oc adm registry <options> -o yaml > registry.yaml
$ oc adm registry <options> -o yaml > registry.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
registry.yaml を編集し、そこで
Serviceを検索して、clusterIPを手順 1 で書き留めたアドレスに変更します。 変更した registry.yaml を使ってレジストリーを作成します。
oc create -f registry.yaml
$ oc create -f registry.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- マスターの再起動
IP アドレスを再利用できない場合、古い IP アドレスを含むプル仕様を使った操作は失敗します。クラスターの中断を最小限に抑えるには、マスターを再起動する必要があります。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow これで、古い IP アドレスを含む古いレジストリー URL がキャッシュからクリアされます。
注記クラスター全体を再起動すると、Pod に不要なダウンタイムが発生し、実質、キャッシュのクリアが行われないので、これは推奨していません。
3.5.2. Docker レジストリーのホワイトリスト化
Docker レジストリーのホワイトリストを指定すると、OpenShift Container Platform ユーザーがダウンロードして入手できるイメージやテンプレートのセットをキュレートできます。このキュレートされたセットは、1 つまたは複数の Docker レジストリーに保管され、その後ホワイトリストに追加されます。ホワイトリストを使用する場合、OpenShift Container Platform からアクセスできるのは指定されたレジストリーのみで、その他すべてのレジストリーはデフォルトでアクセスが拒否されます。
ホワイトリストを設定するには、以下を実行します。
/etc/sysconfig/docker ファイルを編集し、すべてのレジストリーをブロックします。
BLOCK_REGISTRY = ' - ブロックレジストリ=すべて'
BLOCK_REGISTRY = ' - ブロックレジストリ=すべて'Copy to Clipboard Copied! Toggle word wrap Toggle overflow BLOCK_REGISTRY行のコメント解除が必要となる場合があります。同じファイルで、アクセスを許可するレジストリーを追加します。
ADD_REGISTRY='--add-registry=<registry1> --add-registry=<registry2>'
ADD_REGISTRY='--add-registry=<registry1> --add-registry=<registry2>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーへのアクセスの許可
ADD_REGISTRY = ' - add-registry = registry.access.redhat.com'
ADD_REGISTRY = ' - add-registry = registry.access.redhat.com'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の例では、Red Hat カスタマーポータルで入手できるイメージへのアクセスを制限しています。
ホワイトリストが設定されると、ホワイトリストにない Docker レジストリーからプルしようとすると、許可されていないレジストリーであることを示すエラーメッセージが表示されます。
3.5.3. レジストリーのホスト名の設定
内部参照と外部参照の両方でレジストリが認識されるホスト名とポートを構成できます。これにより、イメージストリームは画像のホスト名ベースのプッシュ/プル仕様を提供し、イメージのコンシューマはレジストリサービスのIPからの変更から隔離され、イメージストリームとその参照がクラスタ間で移植可能になる可能性があります。
クラスター内でレジストリーを参照するために使用されるホスト名を設定するには、マスター設定ファイルの imagePolicyConfig セクションで internalRegistryHostname を設定します。外部のホスト名は、同じ場所で externalRegistryHostname の値を設定することで管理されます。
イメージポリシーの設定
imagePolicyConfig: internalRegistryHostname: docker-registry.default.svc.cluster.local:5000 externalRegistryHostname: docker-registry.mycompany.com
imagePolicyConfig:
internalRegistryHostname: docker-registry.default.svc.cluster.local:5000
externalRegistryHostname: docker-registry.mycompany.com
レジストリー自体は、同じ内部ホスト名の値で設定する必要があります。これは、レジストリーのデプロイメント設定で REGISTRY_OPENSHIFT_SERVER_ADDR 環境変数を設定するか、またはレジストリー設定の OpenShift セクションで値を設定することで実行できます。
レジストリーで TLS を有効にしている場合、サーバー証明書にはレジストリーの参照に使用されるホスト名が含まれている必要があります。ホスト名をサーバー証明書に追加する方法については、「レジストリーのセキュリティー保護」を参照してください。
3.5.4. レジストリー設定の上書き
統合レジストリーのデフォルトの設定 (デフォルトでは実行中のレジストリーコンテナーの /config.yml にあります) は、独自の カスタム設定で上書きできます。
このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ミドルウェアのセクションは、環境変数を使って上書きできるオプションがごく少数であるため例外とします。特定の設定オプションを上書きする方法についてこちらを参照してください。
レジストリー設定ファイルの直接的な管理を可能にし、ConfigMap を使って更新された設定をデプロイするには、以下を実行します。
- レジストリーをデプロイします。
必要に応じて、レジストリー設定ファイルをローカルで編集します。以下は、レジストリーにデプロイされている初期 YAML ファイルです。サポートされているオプションを確認してください。
レジストリー設定ファイル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ファイルの内容を保持する
ConfigMapをこのディレクトリーに作成します。oc create configmap registry-config \ --from-file=</path/to/custom/registry/config.yml>/$ oc create configmap registry-config \ --from-file=</path/to/custom/registry/config.yml>/Copy to Clipboard Copied! Toggle word wrap Toggle overflow registry-config ConfigMap をボリュームとしてレジストリーのデプロイメント設定に追加し、カスタム設定ファイルを /etc/docker/registry/ にマウントします。
oc volume dc/docker-registry --add --type=configmap \ --configmap-name=registry-config -m /etc/docker/registry/$ oc volume dc/docker-registry --add --type=configmap \ --configmap-name=registry-config -m /etc/docker/registry/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の環境変数をレジストリーのデプロイメント設定に追加して、直前の手順の設定パスを参照するようにレジストリーを更新します。
oc set env dc/docker-registry \ REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yml$ oc set env dc/docker-registry \ REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
上記の手順は、必要な設定を行えるように繰り返し実行される場合があります。たとえば、トラブルシューティング時に、デバッグ モードに切り換えるよう設定が一時的に更新される場合があります。
既存の設定を更新するには、以下を実行します。
この手順を実行すると、現在デプロイされているレジストリー設定が上書きされます。
- ローカルのレジストリー設定ファイル config.yml を編集します。
registry-config configmap を削除します。
oc delete configmap registry-config
$ oc delete configmap registry-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新された設定ファイルを参照するよう configmap を再作成します。
oc create configmap registry-config\ --from-file=</path/to/custom/registry/config.yml>/$ oc create configmap registry-config\ --from-file=</path/to/custom/registry/config.yml>/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新された設定を読み取るためにレジストリーを再デプロイします。
oc rollout latest docker-registry
$ oc rollout latest docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
設定ファイルをソース管理リポジトリーに保持します。
3.5.5. レジストリー設定の参照
アップストリームの docker ディストリビューションライブラリーでは、多数の設定オプションを利用できます。ただし、すべての設定オプションがサポートされているか、または有効にされているわけではありません。このセクションは、レジストリー設定を上書きする際の参考としてご利用ください。
このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ただし、ミドルウェアのセクションは、環境変数を使って上書きすることはできません。特定の設定オプションを上書きする方法についてこちらを参照してください。
3.5.5.1. ログ
アップストリームのオプションはサポートされています。
例:
3.5.5.2. フック
メールフックはサポートされていません。
3.5.5.3. ストレージ
以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。
次の一覧には、レジストリの構成ファイルで構成する必要があるストレージドライバが含まれています。
- ファイルシステム。ファイルシステムはデフォルトですので、設定の必要はありません。
- S3。詳細は、CloudFront の設定のドキュメントを参照してください。
- OpenStack Swift
- Google Cloud Storage (GCS)
- Microsoft Azure
- Aliyun OSS
レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。
以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。
サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。
一般的なストレージ構成オプション
- 1
- このエントリーは、イメージのプルーニングが正常に機能するために必須です。
3.5.5.4. 認証
認証オプションは変更することができません。openshift の拡張がサポートされている唯一のオプションです。
auth:
openshift:
realm: openshift
auth:
openshift:
realm: openshift3.5.5.5. ミドルウェア
リポジトリーのミドルウェアの拡張を使用して、OpenShift Container Platform やイメージプロキシーとの対話を行う OpenShift Container Platform ミドルウェアの設定を行うことができます。
- 1 2 9
- これらの入力は必須です。これらの入力によって必要なコンポーネントが読み込まれていることを確認できます。これらの値は変更しないでください。
- 3
- レジストリーへのプッシュ時に manifest schema v2 を格納できます。詳細は、こちらを参照してください。
- 4
- レジストリーがリモート Blob のプロキシーとして機能できるようにします。詳細は、 こちらを参照してください。
- 5
- レジストリーキャッシュの Blob がリモートレジストリーから提供されるようにし、その後の迅速なアクセスを可能にします。Blob の初回アクセス時にミラーリングが開始されます。このオプションは、プルスルーが無効にされている場合は機能しません。
- 6
- ターゲットに設定されているプロジェクトで定義されているサイズ制限を超える Blob のアップロードを防止します。
- 7
- レジストリーにキャッシュされている制限の有効期限のタイムアウト。値が小さいほど、制限の変更がレジストリーに伝播するまでの時間が短くなります。ただし、レジストリーは制限をサーバーからより頻繁に照会するため、結果としてプッシュは遅くなります。
- 8
- Blob とリポジトリー間の記憶されている関連付けの有効期限のタイムアウト。値が高いほどルックアップが高速になり、レジストリー操作がより効率的になる可能性が高くなります。一方、アクセスできなくなったユーザーにイメージレイヤーを提供するリスクと同様にメモリー使用量も上昇します。
3.5.5.5.1. CloudFront ミドルウェア
CloudFront ミドルウェア拡張は、CloudFront CDN ストレージプロバイダーである AWS をサポートするために追加することができます。CloudFront ミドルウェアは、イメージコンテンツの海外への配信を高速化します。Blob は世界中の複数のエッジロケーションに配信されます。クライアントは常に最小の待機時間でエッジにアクセスできます。
CloudFront ミドルウェア拡張を使用できるストレージは S3 ストレージのみです。また、使用できるのは Blob が提供されている間のみです。したがって、高速化できるのは Blob のダウンロードのみで、アップロードは高速化しません。
以下は、CloudFront ミドルウェアを含む S3 ストレージドライバーの最小限の設定例です。
- 1
- S3 ストレージは、CloudFront ミドルウェアに関係なく同じ方法で設定する必要があります。
- 2
- CloudFront ストレージミドルウェアは、OpenShift ミドルウェアより前に一覧表示される必要があります。
- 3
- CloudFront ベースの URL。AWS マネジメントコンソールでは、これは CloudFront ディストリビューションの Domain Name として一覧表示されます。
- 4
- AWS のプライベートキーが格納されているファイルシステムの場所。Amazon EC2 のキーペアと混同しないよう注意してください。信頼される署名者の CloudFront キーペアの作成については、AWS ドキュメントを参照してください。このファイルは、レジストリー Pod にシークレットとしてマウントする必要があります。
- 5
- CloudfrontキーペアのID。
3.5.5.5.2. ミドルウェア設定オプションの上書き
middleware セクションは、環境変数を使って上書きできません。ただし例外がいくつかあります。以下は例になります。
- 1
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2で上書きできる設定オプション。manifest schema v2 をマニフェストの Put 要求で 受け入れる機能を有効にします。認識される値はtrueとfalse(以下の他のすべてのブール変数に適用されます) になります。 - 2
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PULLTHROUGHで上書きできる設定オプション。リモートレジストリーのプロキシーモードを有効にします。 - 3
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_MIRRORPULLTHROUGHで上書きできる設定オプション。リモート Blob が提供されている場合、レジストリーに対して Blob をローカルにミラーリングするように指示します。 - 4
- ブール環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTAで上書きできる設定オプション。クォータ実施をオンまたはオフにする機能を有効にします。デフォルトでは、クォータの実施はオフになっています。 - 5
- 環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_PROJECTCACHETTLで上書きできる設定オプション。プロジェクトのクォータオブジェクトのエビクションタイムアウトを指定します。有効な時間文字列 (例:2m) を取ります。空白の場合は、デフォルトのタイムアウトが取得されます。ゼロ (0m) の場合、キャッシングは無効にされます。 - 6
- 環境変数
REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_BLOBREPOSITORYCACHETTLで上書きできる設定オプション。Blob と含まれているレポジトリーの関連付けについてのエビクションタイムアウトを指定します。値のフォーマットはprojectcachettlのケースと同じです。
3.5.5.5.3. イメージのプルスルー
この機能を有効にすると、Blob がローカルに存在しない限り、レジストリーは要求された Blob をリモートレジストリーから取得しようと試みます。リモートの候補は、クライアントがプルする イメージストリームの状態で保存された DockerImage エントリーから算出されます。このエントリーのすべての固有のリモートレジストリーの参照は Blob が見つかるまで繰り返し試行されます。
プルスルーは、プルされているイメージのイメージストリームタグが存在する場合にのみ発生します。たとえば、プルされているイメージが docker-registry.default.svc:5000/yourproject/yourimage:prod である場合、レジストリーは、プロジェクト yourproject で yourimage:prod という名前のイメージストリームタグを検索します。タグが見つかると、レジストリーはそのイメージストリームタグに関連付けられた dockerImageReference を使ってイメージのプルを試行します。
プルスルーを実行すると、レジストリーは、参照されているイメージストリームタグに関連付けられたプロジェクトにあるプル認証情報を使用します。また、この機能を使用すると、ユーザーは、イメージを参照しているイメージストリームタグにアクセスできる限り、アクセスに必要な認証情報を持たないレジストリーのイメージをプルすることができます。
使用しているレジストリーに、プルスルーの実行対象である外部レジストリーを信頼するのに必要な証明書があることを確認してください。証明書は Pod の /etc/pki/tls/certs ディレクトリーに配置する必要があります。証明書は設定マップまたはシークレットを使ってマウントできます。ここで、/etc/pki/tls/certs ディレクトリー全体を置き換える必要があることに注意してください。新しい証明書を組み込み、マウントするシークレットまたは設定マップのシステム証明書を置き換えます。
デフォルトでは、イメージストリームタグは Source の参照ポリシータイプを使用することに注意してください。これは、イメージストリームの参照がイメージのプル仕様に対して解決される場合、使用される仕様はイメージのソースを参照することを意味します。外部レジストリーでホストされているイメージであれば、外部レジストリーが参照され、この結果としてリソースは外部レジストリーでイメージを参照し、プルします。この場合、registry.access.redhat.com/openshift3/jenkins-2-rhel7 とプルスルーは適用されません。イメージストリームを参照しているリソースが内部レジストリーを参照しているプル仕様を使用するようにするには、イメージストリームタグは Local の参照ポリシータイプを使用する必要があります。詳細は、「参照ポリシー」を参照してください。
この機能はデフォルトでオンになっています。ただし、設定オプションを使って無効にすることができます。
デフォルトでは、この方法で提供されるすべてのリモート Blob は、mirrorpullthrough が無効にされていない限りローカルに格納され、その後のアクセスが高速になります。ミラーリング機能の欠点はストレージの使用量が増えることにあります。
ミラーリングは、クライアントがBLOBの少なくとも1バイトをフェッチしようとすると開始されます。実際に必要となる前に特定のイメージを統合レジストリにプリフェッチするには、次のコマンドを実行します。
oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \
xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \
http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}
$ oc get imagestreamtag/${IS}:${TAG} -o jsonpath='{ .image.dockerImageLayers[*].name }' | \
xargs -n1 -I {} curl -H "Range: bytes=0-1" -u user:${TOKEN} \
http://${REGISTRY_IP}:${PORT}/v2/default/mysql/blobs/{}OpenShift Container Platform のミラーリング機能をアップストリームの レジストリーのプルスルーキャッシュ機能と混同しないようにしてください。これらは似ていますが、全く異なる機能です。
3.5.5.5.4. Manifest Schema v2 サポート
各イメージには、Blob を記述するマニフェスト、それを実行するための命令、および追加のメタデータがあります。マニフェストはバージョン管理されており、バージョンごとに構造やフィールドが異なります。同一イメージが複数のマニフェストバージョンで表現されます。それぞれのバージョンはそれぞれ異なるダイジェストがあります。
現在サポートされているレジストリーは manifest v2 schema 1 (schema1) と manifest v2 schema 2 (schema2) です。前者は古くなっていますが、今後もしばらくはサポートされます。
各種の Docker クライアントとの互換性の問題に注意する必要があります。
- Docker クライアントのバージョン 1.9 以前は、schema1 のみをサポートしています。このクライアントがプルまたはプッシュするマニフェストはレガシースキーマになります。
- Docker クライアントのバージョン 1.10 は、schema1 と schema2 の両方をサポートしています。デフォルトでは、新しい方のスキーマをサポートする場合はこちらをレジストリーにプッシュします。
イメージを schema1 で格納するレジストリーは、常にイメージを変更せずにクライアントに返します。Schema2 は新規の Docker クライアントにのみ変更しない状態で移動します。古いクライアントの場合は、オンザフライで schema1 に変換されます。
これにより、大きな影響が想定されます。たとえば、新規 Docker クライアントでレジストリーにプッシュされたイメージは、古い Docker のダイジェストでプルすることはできません。格納されたイメージのマニフェストは schema2 であり、そのダイジェストはこのバージョンのマニフェストをプルする場合にのみ使用できるためです。
このため、レジストリーはデフォルトでは schema2 を格納しないように設定されています。これにより、すべての Docker クライアントはクライアントのバージョンに関係なく、プッシュされたイメージをレジストリーからプルできます。
すべてのレジストリークライアントが schema2 をサポートしていることを確認できたら、そのサポートをレジストリーで有効にすることができます。特定のオプションについては、上記の「ミドルウェア設定の参照」を参照してください。
3.5.5.6. OpenShift
このセクションでは、OpenShift Container Platform に特有の機能のグローバル設定について説明します。今後のリリースでは、 Middleware セクションにある openshift 関連の設定は廃止される予定です。
現在、このセクションではレジストリーメトリクスの収集を設定できます。
- 1
- このセクションの設定バージョンを指定する必須エントリー。サポートされている値は
1.0のみです。 - 2
- レジストリーのホスト名。マスターで設定されている値と同じ値に設定される必要があります。これは環境変数
REGISTRY_OPENSHIFT_SERVER_ADDRで上書きされる可能性があります。 - 3
- メトリクスの収集を有効にするには
trueに設定します。これはブール環境変数REGISTRY_OPENSHIFT_METRICS_ENABLEDで上書きされる可能性があります。 - 4
- クライアント要求の承認に使用されるシークレット。メトリクスのクライアントは これを
Authorizationヘッダーでベアラートークンとして使用します。環境変数REGISTRY_OPENSHIFT_METRICS_SECRETで上書きできます。 - 5
- 同時に行えるプル要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXRUNNINGで上書きできます。ゼロは無制限を意味します。 - 6
- キューに入れられるプル要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXINQUEUEで上書きできます。ゼロは無制限を意味します。 - 7
- 拒否されるまでのキューにあるプル要求の最大待機時間。環境変数
REGISTRY_OPENSHIFT_REQUESTS_READ_MAXWAITINQUEUEで上書きできます。ゼロは無制限を意味します。 - 8
- 同時に行えるプッシュ要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXRUNNINGで上書きできます。ゼロは無制限を意味します。 - 9
- キューにあるプッシュ要求の最大数。環境変数
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXINQUEUEで上書きできます。ゼロは無制限を意味します。 - 10
- 拒否されるまでのキューにあるプッシュ要求の最大待機時間。環境変数
REGISTRY_OPENSHIFT_REQUESTS_WRITE_MAXWAITINQUEUEで上書きできます。ゼロは無制限を意味します。
使用状況の情報については レジストリーメトリクスへのアクセスを参照してください。
3.5.5.7. レポート (Reporting)
レポート (Reporting) はサポートされていません。
3.5.5.8. HTTP
アップストリームのオプションはサポートされています。環境変数を使って設定を変更する方法についてはこちらを参照してください。変更の必要があるのは tls セクションのみです。以下は例になります。
http:
addr: :5000
tls:
certificate: /etc/secrets/registry.crt
key: /etc/secrets/registry.key
http:
addr: :5000
tls:
certificate: /etc/secrets/registry.crt
key: /etc/secrets/registry.key3.5.5.9. 通知
アップストリームのオプションはサポートされています。REST API リファレンス はより包括的な統合オプションを提供します。
例:
3.5.5.10. Redis
Redis はサポートされていません。
3.5.5.11. 健全性
アップストリームのオプションはサポートされています。レジストリーのデプロイメント設定は、 /healthz で統合されたヘルスチェックを提供します。
3.5.5.12. プロキシー
プロキシー設定は有効にできません。この機能は OpenShift Container Platform リポジトリーのミドルウェア拡張、pullthrough: true で提供されます。
3.5.5.13. キャッシュ
統合レジストリーは、データをアクティブにキャッシュして、速度の遅い外部リソースに対する呼び出しの回数を減らします。キャッシュには 2 種類あります。
- Blob のメタデータのキャッシュに使用されるストレージキャッシュ。このキャッシュには有効期限がなく、データは明示的に削除されるまで残り続けます。
- アプリケーションキャッシュには、Blob とリポジトリーの関連付けが含まれます。このキャッシュ内のデータには有効期限があります。
キャッシュを完全にオフににするには設定を変更する必要があります。
3.6. 既知の問題
3.6.1. 概要
以下は、統合レジストリーのデプロイまたは使用時の既知の問題です。
3.6.2. 共有 NFS ボリュームとスケーリングされたレジストリーの使用時のイメージのプッシュエラー
スケーリングされたレジストリーを共有 NFS ボリュームで使用すると、イメージのプッシュ時に以下のいずれかのエラーが発生することがあります。
-
digest invalid: provided digest did not match uploaded content -
blob upload unknown -
blob upload invalid
これらのエラーは、Docker のイメージのプッシュの試行時に内部レジストリーサービスによって返されます。その原因は、ノード間のファイル属性の同期に起因します。NFS クライアント側のキャッシング、ネットワーク待機時間およびレイヤーサイズなどはすべて、デフォルトのラウンドロビンロードバランシング設定を使用してイメージをプッシュする際に発生するエラーの要因になる可能性があります。
このような障害の可能性を最小限に抑えるには、以下の手順を実行します。
docker-registry サービスの
sessionAffinityがClientIPに設定されていることを確認します。oc get svc / docker-registry --template = '{{。spec.sessionAffinity}}'$ oc get svc / docker-registry --template = '{{。spec.sessionAffinity}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより
ClientIPが返されるはずです。ClientIP は OpenShift Container Platform の最近のバージョンのデフォルトです。これが返されない場合は、以下のように変更してください。oc patch svc / docker-registry -p '{' spec '：{' sessionAffinity '：' ClientIP '}}'$ oc patch svc / docker-registry -p '{' spec '：{' sessionAffinity '：' ClientIP '}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
NFS サーバー上のレジストリーボリュームの NFS エクスポート行に
no_wdelayオプションが一覧表示されていることを確認します。no_wdelayオプションは、サーバーによる書き込みの遅延を防ぎ、このレジストリーの要件である、書き込み直後の読み取りの整合性を大幅に改善します。
テストにより、NFS サーバーを RHEL でコンテナーレジストリーのストレージバックエンドとして使用することに関する問題が検出されています。これには、OpenShift Container Registry および Quay が含まれます。そのため、コアサービスで使用される PV をサポートするために NFS を使用することは推奨されていません。
他の NFS の実装ではこれらの問題が検出されない可能性があります。OpenShift コアコンポーネントに対して実施された可能性のあるテストに関する詳細情報は、個別の NFS 実装ベンダーにお問い合わせください。
3.6.3. 内部で管理されたイメージのプルに失敗し「見つかりません (not found)」のエラーが表示される
このエラーは、プルされたイメージがプルされているイメージストリームとは異なるイメージストリームにプッシュされた場合に発生します。これは、ビルドされたイメージを任意のイメージストリームに再タグ付けすることによって発生します。
oc tag srcimagestream:latest anyproject/pullimagestream:latest
$ oc tag srcimagestream:latest anyproject/pullimagestream:latestその後、次のようなイメージ参照を使用して引き出します。
internal.registry.url：5000 / anyproject / pullimagestream：latest
internal.registry.url：5000 / anyproject / pullimagestream：latestDockerを手動でプルするときにも同様のエラーが発生します。
Error: image anyproject/pullimagestream:latest not found
Error: image anyproject/pullimagestream:latest not foundこのエラーを防ぐには、内部で管理されたイメージのタグ付けを完全に避けるか、またはビルドしたイメージを必要な namespace に 手動で再プッシュします。
3.6.4. S3 ストレージでのイメージのプッシュが失敗し「500 内部サーバーエラー (500 Internal Server Error)」と表示される
レジストリーが S3 ストレージのバックエンドで実行されると、問題が報告されます。 Docker レジストリーへのプッシュは、以下のエラーを出して失敗することがあります。
Received unexpected HTTP status: 500 Internal Server Error
Received unexpected HTTP status: 500 Internal Server Errorこれをデバッグするには、レジストリーのログを表示する必要があります。ログで、プッシュの失敗時に発生した同様のエラーメッセージを探します。
このようなエラーを確認した場合には、Amazon S3 サポートにお問い合わせください。リージョンや特定のバケットで問題がある可能性があります。
3.6.5. イメージのプルーニングの失敗
イメージのプルーニング時に以下のエラーが発生した場合:
BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob
BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blobさらに、レジストリーのログに以下の情報が含まれている場合。
error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported
error deleting blob \"sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c\": operation unsupported
上記に該当する場合、お使いのカスタム設定ファイルにはストレージセクションに必須のエントリー、つまり true に設定された storage:delete:enabled が含まれていないことを意味します。これらを追加し、レジストリーを再デプロイして、再度イメージプルーニングの操作を行ってください。
第4章 ルーターのセットアップ
4.1. ルーターの概要
4.1.1. ルーターについて
トラフィックをクラスターに送る方法は多数あります。最も一般的な方法として、 OpenShift Container Platform インストールで OpenShift Container Platform ルーターを、サービス向けの外部トラフィックの ingress ポイントとして使用できます。
OpenShift Container Platform は以下のルータープラグインを提供し、サポートしています。
- HAProxy テンプレートルーターはデフォルトのプラグインです。これは、openshift3/ose-haproxy-router イメージを使用して、OpenShift Container Platform のコンテナーにあるテンプレートルータープラグインと共に HAProxy インスタンスを実行します。現在は、HTTP(S) トラフィックと SNI を使用した TLS 対応のトラフィックをサポートしています。ルーターのコンテナーは、プライベート IP でのみリッスンする多数のコンテナーとは異なり、ホストのネットワークインターフェースでリッスンします。ルーターは、ルートに関連付けられたサービスで識別される実際の Pod の IP に対するルート名の外部要求をプロキシー処理します。
- F5 ルーターは、ルートを同期するためにお使いの環境で既存の F5 BIG-IP® システムに統合されます。F5 iControl REST API を使用するには、F5 BIG-IP® バージョン 11.4 以降が必要です。
F5 ルータープラグインは OpenShift Container Platform 3.0.2 以降で利用できます。
4.1.2. ルーターのサービスアカウント
OpenShift Container Platform クラスターをデプロイする前に、ルーターのサービスアカウントを取得する必要があります。OpenShift Container Platform 3.1 以降では、クイックインストールまたは通常インストール (Advanced installation) の実行時に、ルーターのサービスアカウントが自動的に作成されます (以前は手動で作成する必要がありました)。このサービスアカウントには、ホストポートを指定することを許可する SCC (security context constraint) のパーミッションがあります。
4.1.2.1. ラベルにアクセスするためのパーミッション
namespace ラベルが使用されている場合 (ルーターシャードを作成している場合など)、ルーターのサービスアカウントにはcluster-reader のパーミッションが必要になります。
oc adm policy add-cluster-role-to-user \
cluster-reader \
system:serviceaccount:default:router
$ oc adm policy add-cluster-role-to-user \
cluster-reader \
system:serviceaccount:default:routerサービスアカウントを準備したら、デフォルト HAProxy ルーター、カスタマイズ HAProxy ルーター、または F5 ルーターのインストールに進むことができます。
4.2. デフォルト HAProxy ルーターの使用
4.2.1. 概要
oc adm router コマンドには、新規インストールでのルーターのセットアップタスクを単純化する管理者 CLI が提供されます。 クイックインストールを実行している場合は、デフォルトのルーターが自動的に作成されます。oc adm router コマンドは、サービスとデプロイメント設定オブジェクトを作成します。 --service-account オプションを使用して、ルーターがマスターとの通信で使用するサービスアカウントを指定します。
ルーターサービスアカウントは事前に作成するか、oc adm router --service-account コマンドで作成することができます。
OpenShift Container Platform コンポーネント間のあらゆる形式の通信は TLS によって保護され、各種の証明書や認証方法を使用します。--default-certificate .pem フォーマットファイルは提供されるか、または oc adm router コマンドで作成されます。ルートが作成されると、ユーザーはルートの処理時にルーターが使用するルート証明書を提供できるようになります。
ルーターを削除する際に、デプロイ設定やサービス、およびシークレットも削除されていることを確認します。
ルーターは特定のノードにデプロイされます。これにより、クラスター管理者と外部ネットワークマネージャーはどの IP アドレスがルーターを実行し、ルーターがどのトラフィックを処理するかについて調整しやすくなります。ノードセレクターを使用してルーターを特定のノードにデプロイします。
お使いのルーターで個別の openshift-router サービスアカウントを使用することをお勧めします。--service-account フラグを oc adm router コマンドで使用してこれを指定できます。
oc adm router --dry-run --service-account=router
$ oc adm router --dry-run --service-account=router
oc adm router を使用して作成されるルーター Pod には、ルーター Pod がデプロイされるためにノードが満たさなければならないデフォルトのリソース要求が設定されます。デフォルトのリソース要求は、インフラストラクチャーコンポーネントの信頼性を向上させる取り組みとして、ルーター Pod の QoS 層をリソース要求を持たない Pod よりも高く設定するために使用されます。デフォルト値は、基本的なルーターがデプロイされるのに必要な最小限のリソースを表しており、ルーターデプロイメント設定で編集できます。また、ルーターの負荷に基づいてそれらの値を引き上げることもできます。
4.2.2. ルーターの作成
クイックインストールプロセスは、デフォルトルーターを自動的に作成します。ルーターが存在しない場合は、以下を実行してルーターを作成します。
oc adm router <router_name> --replicas=<number> --service-account=router
$ oc adm router <router_name> --replicas=<number> --service-account=router
高可用性の設定が作成されない限り、--replicas は通常 1 になります。
ルーターのホスト IP アドレスを見つけるには、以下を実行します。
oc get po <router-pod> --template={{.status.hostIP}}
$ oc get po <router-pod> --template={{.status.hostIP}}また、ルーターシャードを使用して、ルーターを特定の namespace またはルートに絞り込むか、ルーターの作成後に環境変数を設定できます。この場合には、シャードごとにルーターを作成します。
4.2.3. その他の基本ルーターコマンド
- デフォルトルーターの確認
- router という名前のデフォルトのルーターサービスアカウントは、クイックおよび通常インストール (Advanced installation) 時に自動的に作成されます。このアカウントがすでに存在することを確認するには、以下を実行します。
oc adm router --dry-run --service-account=router
$ oc adm router --dry-run --service-account=router- デフォルトルーターの表示
- デフォルトルーターが作成されている場合でそれを確認するには、以下を実行します。
oc adm router --dry-run -o yaml --service-account=router
$ oc adm router --dry-run -o yaml --service-account=router- ラベル付けされたノードへのルーターのデプロイ
- 指定されたノードラベルに一致するノードにルーターをデプロイするには、以下を実行します。
oc adm router <router_name> --replicas=<number> --selector=<label> \
--service-account=router
$ oc adm router <router_name> --replicas=<number> --selector=<label> \
--service-account=router
たとえば、router という名前のルーターを作成し、それを region=infra とラベルが付けられたノードに配置するには、以下を実行します。
oc adm router router --replicas=1 --selector='region=infra' \ --service-account=router
$ oc adm router router --replicas=1 --selector='region=infra' \
--service-account=router
通常インストール (Advanced installation) の実行時に、openshift_router_selector および openshift_registry_selector Ansible 設定はデフォルトで region=infra に設定されます。region=infra ラベルと一致するノードが存在する場合、デフォルトのルーターとレジストリーは自動的にデプロイされます。
ラベルの更新に関する情報については、「ノードのラベルの更新」を参照してください。
複数のインスタンスが スケジューラーポリシーに従って複数の異なるホストに作成されます。
- 複数の異なるルーターイメージの使用
- 複数の異なるルーターイメージを使用し、使用されるルーター設定を表示するには、以下を実行します。
oc adm router <router_name> -o <format> --images=<image> \
--service-account=router
$ oc adm router <router_name> -o <format> --images=<image> \
--service-account=router例を以下に示します。
oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
--service-account=router
$ oc adm router region-west -o yaml --images=myrepo/somerouter:mytag \
--service-account=router4.2.4. ルートを特定のルーターに絞り込む
ROUTE_LABELS 環境変数を使用してルートを絞り込むことで、特定のルーターによってのみ使用されるようできます。
たとえば、複数のルーターと 100 のルートがある場合、ラベルをルートに割り当てることで、それらの一部を 1 つのルーターで処理し、残りを別のルーターで処理するようにできます。
ルーターの作成後に、
ROUTE_LABELS環境変数を使用してルーターにタグ付けします。oc env dc/<router=name> ROUTE_LABELS="key=value"
$ oc env dc/<router=name> ROUTE_LABELS="key=value"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ラベルを必要なルートに追加します。
oc label route <route=name> key=value
oc label route <route=name> key=valueCopy to Clipboard Copied! Toggle word wrap Toggle overflow ラベルがルートに割り当てられていることを確認するには、ルートの設定をチェックします。
oc describe route/<route_name>
$ oc describe route/<route_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 同時接続の最大数の設定
-
ルーターはデフォルトで最大 20000 の接続を処理できるようになっています。この上限は必要に応じて変更できます。接続が少なすぎると、ヘルスチェックが機能せず、不必要な再起動が実行されます。システムをこの接続の最大数に対応するように設定する必要があります。
'sysctl fs.nr_open'と'sysctl fs.file-max'に示される上限は十分に大きな値である必要があります。そうでない場合には HAproxy は起動しません。
ルーターを作成したら、--max-connections= オプションで必要な上限を設定します。
oc adm router --max-connections=10000 ....
$ oc adm router --max-connections=10000 ....
ルーターのデプロイメント設定で ROUTER_MAX_CONNECTIONS 環境変数を編集し、値を変更します。ルーター Pod は新しい値で再起動されます。ROUTER_MAX_CONNECTIONS が存在しない場合は、デフォルト値の 20000 が使用されます。
接続にはフロントエンドおよび内部バックエンドが含まれます。これは 2 つの接続としてカウントされます。必ず ROUTER_MAX_CONNECTIONS の値を作成しようとしている接続数の 2 倍以上になるように設定してください。
4.2.5. HAProxy Strict SNI
HAProxy strict-sni は、ルーターのデプロイメント設定の ROUTER_STRICT_SNI 環境変数によって管理できます。また、これは --strict-sni コマンドラインオプションを使用してルーターを作成する時にも設定できます。
oc adm router --strict-sni
$ oc adm router --strict-sni4.2.6. TLS 暗号化スイート
ルーターの作成時に --ciphers オプションを使用して、ルーターの暗号化スイートを設定します。
oc adm router --ciphers=modern ....
$ oc adm router --ciphers=modern ....
値は modern、intermediate、または old で、デフォルトは intermediateです。または、 ":" で区切られた暗号セットを指定することもできます。暗号は以下によって表示されるセットから取られたものである必要があります。
openssl ciphers
$ openssl ciphers
また、既存のルーターには ROUTER_CIPHERS 環境変数を使用します。
4.2.7. 高可用性ルーター
IP フェイルオーバーを使用して OpenShift Container Platform クラスターで高可用性ルーターをセットアップできます。このセットアップには複数の異なるノードの複数のレプリカが含まれるため、フェイルオーバーソフトウェアは現在のレプリカが失敗したら別のレプリカに切り替えることができます。
4.2.8. ルーターサービスポートのカスタマイズ
環境変数の ROUTER_SERVICE_HTTP_PORT と ROUTER_SERVICE_HTTPS_PORT を設定することで、テンプレートルーターがバインドするサービスポートをカスタマイズできます。これは、テンプレートルーターを作成し、そのデプロイメント設定を編集することで実行できます。
以下の例では、0 レプリカのルーターデプロイメントを作成し、ルーターサービス HTTP と HTTPS ポートをカスタマイズし、これを適切に (1 レプリカに) スケーリングしています。
oc adm router --replicas=0 --ports='10080:10080,10443:10443'
oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080 \
ROUTER_SERVICE_HTTPS_PORT=10443
oc scale dc/router --replicas=1
$ oc adm router --replicas=0 --ports='10080:10080,10443:10443'
$ oc set env dc/router ROUTER_SERVICE_HTTP_PORT=10080 \
ROUTER_SERVICE_HTTPS_PORT=10443
$ oc scale dc/router --replicas=1- 1
- 公開されるポートがコンテナーネットワークモード
--host-network=falseを使用するルーターに対して適切に設定されていることを確認します。
テンプレートルーターサービスポートをカスタマイズする場合は、ルーター Pod が実行されるノードのファイアウォールでカスタムポートが開いているようにする必要があります (Ansible または iptables のいずれか、または firewall-cmd で使用するその他のカスタム方法を使用します)。
以下は、カスタムルーターサービスポートを開くために iptables を使用した例です。
iptables -A INPUT -p tcp --dport 10080 -j ACCEPT iptables -A INPUT -p tcp --dport 10443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 10080 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 10443 -j ACCEPT4.2.9. 複数ルーターの使用
管理者は同じ定義を使用して複数のルーターを作成し、同じルートのセットを提供することができます。各ルーターは複数の異なるノードに置かれ、異なる IP アドレスを持ちます。ネットワーク管理者は、各ノードに必要なトラフィックを送る必要があります。
複数のルーターをグループ化して、クラスター内や複数テナントでのルーティングの負荷を別のルーターまたはシャードに分散することができます。グループの各ルーターまたはシャードは、ルーターのセレクターに基づいてルートを許可します。管理者は ROUTE_LABELS を使用してクラスター全体でシャードを作成できます。ユーザーは NAMESPACE_LABELS を使用して namespace (プロジェクト) でシャードを作成できます。
4.2.10. デプロイメント設定へのノードセレクターの追加
特定のルーターを特定のノードにデプロイするには、2 つの手順を実行する必要があります。
ラベルを必要なノードに追加します。
oc label node 10.254.254.28 "router=first"
$ oc label node 10.254.254.28 "router=first"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードセレクターをルーターのデプロイメント設定に追加します。
oc edit dc <deploymentConfigName>
$ oc edit dc <deploymentConfigName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow template.spec.nodeSelectorフィールドに、ラベルに対応するキーと値を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
router=firstラベルに対応するキーと値はそれぞれrouterとfirstになります。
4.2.11. ルーターシャードの使用
ルーターのシャード化では NAMESPACE_LABELS と ROUTE_LABELS を使用してルーターの namespace とルートを絞り込みます。これにより、複数のルーターデプロイメントでルートのサブセットを分散させることができます。重複しないサブセットを使用することにより、ルートの設定のパーティション設定を効果的に行うことができます。または、ルートの重複するサブセットを構成するシャードを定義することもできます。
デフォルトで、ルーターはすべてのプロジェクト (namespace) からすべてのルートを選択します。シャード化によってラベルがルートまたはルーターの namespace およびラベルセレクターに追加されます。各ルーターシャードは特定のラベルのセットで選択されるルーターを構成するか、または特定のラベルセレクターで選択される namespace に属します。
ルーターサービスアカウントには [cluster reader] パーミッションセットを設定し、他の namespace のラベルにアクセスできるようにする必要があります。
ルーターのシャード化および DNS
外部 DNS サーバーは要求を必要なシャードにルートするために必要となるので、管理者はプロジェクトの各ルーターに個別の DNS エントリーを作成する必要があります。ルーターは不明なルートを別のルーターに転送することはありません。
以下は例を示しています。
-
Router A はホスト 192.168.0.5 にあり、
*.foo.comのルートを持つ。 -
Router B はホスト 192.168.1.9 にあり、
*.example.comのルートを持つ。
各 DNS エントリーは *.foo.com を Router A をホストするノードに解決し、*.example.com を Router B をホストするノードに解決する必要があります。
-
*.foo.com A IN 192.168.0.5 -
*.example.com A IN 192.168.1.9
ルーターのシャード化の例
このセクションでは、namespace およびルートラベルを使用するルーターのシャード化について説明します。
図4.1 namespace ラベルに基づくルーターのシャード化
namespace ラベルセレクターでルーターを設定します。
oc set env dc/router NAMESPACE_LABELS="router=r1"
$ oc set env dc/router NAMESPACE_LABELS="router=r1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルーターには namespace にセレクターがあるため、ルーターは一致する namespace のルートのみを処理します。このセレクターが namespace に一致させるようにするには、namespace に適宜ラベルを付けます。
oc label namespace default "router=r1"
$ oc label namespace default "router=r1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルートをデフォルトの namespace に作成すると、ルートはデフォルトのルーターで利用できるようになります。
oc create -f route1.yaml
$ oc create -f route1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規プロジェクト (namespace) を作成し、
route2というルートを作成します。oc new-project p1 oc create -f route2.yaml
$ oc new-project p1 $ oc create -f route2.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルートがルーターで利用できないことを確認します。
namespace
p1にrouter=r1のラベルを付けます。oc label namespace p1 "router=r1"
$ oc label namespace p1 "router=r1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
このラベルを追加すると、ルートはルーターで利用できるようになります。
- 例
ルーターのデプロイメント
finops-routerはルートセレクターNAMESPACE_LABELS="name in (finance, ops)"を使用して設定され、ルーターのデプロイメントdev-routerはラベルセレクターNAMESPACE_LABELS="name=dev"を使用して設定されます。すべてのルートが
name=finance、name=ops、およびname=devというラベルの付けられた namespace にある場合、この設定により、2 つのルーターのデプロイメント間でルートが効果的に分散されます。上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。
ルート選択の基準によって、ルートの分散方法が決まります。複数のルーターデプロイメントに重複するルートのサブセットを設定することも可能です。
- 例
上記の例では
finops-routerとdev-routerのほかにdevops-routerがあり、これはラベルセレクターNAMESPACE_LABELS="name in (dev, ops)"を使用して設定されます。name=devまたはname=opsというラベルが付けられた namespace のルートは 2 つの異なるルーターデプロイメントによって提供されるようになりました。これは、「namespace ラベルに基づくルーターのシャード化」の手順で説明されているように、ルートの重複するサブセットを定義するケースです。また、これによりさらに複雑なルーティングルールを作成し、優先度の高いトラフィックを専用の
finops-routerに転送し、優先度の低いトラフィックはdevops-routerに送信できます。
ルートラベルに基づくルーターのシャード化
NAMESPACE_LABELS によって、提供するプロジェクトをフィルターでき、それらのプロジェクトからすべてのルートを選択できますが、ルートはルート自体に関連する他の基準に基づいてパーティション設定する必要がある場合があります。ROUTE_LABELS セレクターを使用すると、ルート自体を細かくフィルターできます。
- 例
ルーターデプロイメント
prod-routerはルートセレクターROUTE_LABELS="mydeployment=prod"を使用して設定され、ルーターデプロイメントdevtest-routerはラベルセレクターROUTE_LABELS="mydeployment in (dev, test)"を使用して設定されます。この設定は、namespace の種類を問わず、ルートのラベルに基づいて 2 つのルーターデプロイメント間のルートのパーティション設定を行います。
この例では、提供されるルートすべてがラベル
"mydeployment=<tag>"でタグ付けされていることを想定しています。
4.2.11.1. ルーターシャードの作成
このセクションでは、ルーターシャードのさらに詳細な例を示します。さまざまなラベルを持つ a — z という 26 のルートがあることを想定してください。
ルートで使用可能なラベル
sla=high geo=east hw=modest dept=finance sla=medium geo=west hw=strong dept=dev sla=low dept=ops
sla=high geo=east hw=modest dept=finance
sla=medium geo=west hw=strong dept=dev
sla=low dept=opsこれらのラベルは、サービスレベルアグリーメント、地理的な場所、ハードウェア要件、部門などの概念を表しています。ルートは各列のラベルを最大 1 つ持つことができます。ルートによっては他のラベルを持つことことも、ラベルをまったく持たないこともあります。
| 名前 | SLA | Geo (地理的な場所) | HW | Dept (部門) | その他のラベル |
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
| ||
|
|
|
|
これは oc adm router、oc set env、oc scale がどのように連携してルーターシャードを作成するかを表している便利なスクリプト mkshard です。
mkshard を複数回実行して、複数のルーターを作成します。
| ルーター | 選択式 | ルート |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.11.2. ルーターシャードの変更
ルーターシャードはラベルに基づいた構成なので、(oc label を使用して) ラベルまたは (oc set env を使用して) 選択式のいずれかを変更できます。
このセクションでは「ルーターシャードの作成」セクションで扱った例をさらに詳細に取り上げ、選択式の変更方法を示します。
これは、新規の選択式を使用できるよう既存のルーターを変更する便利なスクリプト modshard です。
modshard では、router-shard-<id> のデプロイメントストラテジーが Rolling の場合、oc scale コマンドは不要です。
たとえば router-shard-3 の部門を拡張して ops と dev を含めるには、以下を実行します。
modshard 3 ROUTE_LABELS='dept in (dev, ops)'
$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'
結果として、router-shard-3 はルート g — s (g — k と l — s の組み合わせ) を選択します。
この例ではシャードから除外する 1 つの部門を指定します。このシナリオ例では 3 つの部門しかないため、これによって前述の例と同じ結果が得られます。
modshard 3 ROUTE_LABELS='dept != finance'
$ modshard 3 ROUTE_LABELS='dept != finance'
この例は 3 つのカンマで区切られた属性を指定しており、結果としてルート b のみが選択されます。
modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'
$ modshard 3 ROUTE_LABELS='hw=strong,type=dynamic,geo=west'
ルートのラベルを使用する ROUTE_LABELS と同様に、NAMESPACE_LABELS 環境変数を使用して、ルートはルートの namespace ラベルのラベルに基づいて選択できます。この例では、ラベル frequency=weekly を持つルートの namespace を提供するように router-shard-3 を変更します。
modshard 3 NAMESPACE_LABELS='frequency=weekly'
$ modshard 3 NAMESPACE_LABELS='frequency=weekly'
最後の例は ROUTE_LABELS と NAMESPACE_LABELS を組み合わせて、ラベルsla=low を持ち、ラベル frequency=weekly を持つ namespace のルート選択します。
modshard 3 \
NAMESPACE_LABELS='frequency=weekly' \
ROUTE_LABELS='sla=low'
$ modshard 3 \
NAMESPACE_LABELS='frequency=weekly' \
ROUTE_LABELS='sla=low'4.2.12. ルーターのホスト名の検索
サービスを公開する際に、ユーザーは外部ユーザーがアプリケーションにアクセスするために使用する DNS 名からの同じルートを使用できます。外部ネットワークのネットワーク管理者は、ホスト名がルートを許可したルーター名に解決することを確認する必要があります。ユーザーはこのホスト名を指す CNAME を使用して DNS をセットアップできます。ただし、ユーザーはルーターのホスト名を知らない場合があり、その場合はクラスター管理者がホスト名を知らせることができます。
クラスター管理者は、--router-canonical-hostname オプションをルーター作成時のルーターの正規ホスト名で使用できます。以下は例になります。
oc adm router myrouter --router-canonical-hostname="rtr.example.com"
# oc adm router myrouter --router-canonical-hostname="rtr.example.com"
これは、ルーターのホスト名を含む ROUTER_CANONICAL_HOSTNAME 環境変数をルーターのデプロイメント設定に作成します。
すでに存在しているルーターの場合、クラスター管理者はルーターのデプロイメント設定を編集し、ROUTER_CANONICAL_HOSTNAME 環境変数を追加します。
ROUTER_CANONICAL_HOSTNAME 値は、ルートを許可したすべてのルーターのルートステータスに表示されます。ルートステータスはルーターがリロードされるたびに更新されます。
ユーザーがルートを作成すると、すべてのアクティブなルーターはそのルートを評価し、条件を満たしていればそのルートを許可します。ROUTER_CANONICAL_HOSTNAME 環境変数を定義するルーターがルートを許可すると、ルーターはルートステータスの routerCanonicalHostname フィールドに値を入力します。ユーザーはルートステータスを検証して、どのルーターがルートを許可したかを確認でき、ルーターを一覧から選択し、ネットワーク管理者に渡すルーターのホスト名を見つけることができます (該当する場合)。
oc describe にはホスト名が含まれます (利用可能な場合)。
oc describe route/hello-route3
$ oc describe route/hello-route3
...
Requested Host: hello.in.mycloud.com exposed on router myroute (host rtr.example.com) 12 minutes ago
上記の情報を使用して、ユーザーは DNS 管理者に対し、ルートのホスト hello.in.mycloud.com から CNAME をルーターの正規ホスト名 rtr.example.com に応じてセットアップするよう依頼できます。この結果として、hello.in.mycloud.com へのトラフィックがユーザーのアプリケーションに到達するようになります。
4.2.13. デフォルトのルーティングサブドメインのカスタマイズ
マスター設定ファイル (デフォルトでは /etc/origin/master/master-config.yaml ファイル) を変更することで、お使いの環境のデフォルトルーティングサブドメインとして使用されるサフィックスをカスタマイズできます。ホスト名を指定しないルートの場合、このデフォルトのルーティングサブドメインを使用してホスト名が生成されます。
以下の例は、設定されたサフィックスを v3.openshift.test に設定する方法を示しています。
routingConfig: subdomain: v3.openshift.test
routingConfig:
subdomain: v3.openshift.testこの変更には、マスターを実行している場合は再起動が必要となります。
OpenShift Container Platform マスターが上記の設定を実行している場合、 namespace の mynamespace に追加されるホスト名を持たない no-route-hostname というルートの例では、生成されるホスト名は以下のようになります。
no-route-hostname-mynamespace.v3.openshift.test
no-route-hostname-mynamespace.v3.openshift.test4.2.14. カスタムルーティングサブドメインへのルートホスト名の強制
管理者がすべてのルートを特定のルーティングサブドメインに限定する場合、--force-subdomain オプションを oc adm router コマンドに渡すことができます。これはルートで指定されたホスト名を上書きし、--force-subdomain オプションに提供されるテンプレートに基づいてホスト名を生成するようルーターに強制します。
以下の例ではルーターを実行し、カスタムサブドメインテンプレート ${name}-${namespace}.apps.example.com を使用してルートホスト名を上書きしています。
oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'
$ oc adm router --force-subdomain='${name}-${namespace}.apps.example.com'4.2.15. ワイルドカード証明書の使用
証明書を含まない TLS 対応のルートはルーターのデフォルト証明書を代わりに使用します。ほとんどの場合、この証明書は信頼された認証局から提供されますが、利便性を考慮して OpenShift Container Platform CA を使用して証明書を作成することができます。以下は例になります。
CA=/etc/origin/master
oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
--signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
--hostnames='*.cloudapps.example.com' \
--cert=cloudapps.crt --key=cloudapps.key
$ CA=/etc/origin/master
$ oc adm ca create-server-cert --signer-cert=$CA/ca.crt \
--signer-key=$CA/ca.key --signer-serial=$CA/ca.serial.txt \
--hostnames='*.cloudapps.example.com' \
--cert=cloudapps.crt --key=cloudapps.key
oc adm ca create-server-cert コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。
Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。
ルーターは、証明書とキーが単一ファイルに PEM 形式で入力されていると予想します。
cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem
$ cat cloudapps.crt cloudapps.key $CA/ca.crt > cloudapps.router.pem
ここで --default-cert フラグを使用できます。
oc adm router --default-cert=cloudapps.router.pem --service-account=router
$ oc adm router --default-cert=cloudapps.router.pem --service-account=routerブラウザーは、ワイルドカードを 1 つ深いレベルのサブドメインに有効であると見なします。この例では、証明書は a.cloudapps.example.com に対して有効ですが、a.b.cloudapps.example.com には有効ではありません。
4.2.16. 証明書を手動で再デプロイする
ルーター証明書を手動で再デプロイするには、以下を実行します。
デフォルトのルーター証明書を含むシークレットがルーターに追加されているかどうかを確認します。
oc volumes dc/router
$ oc volumes dc/router deploymentconfigs/router secret/router-certs as server-certificate mounted at /etc/pki/tls/privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書が追加されている場合は、以下の手順を省略してシークレットを上書きします。
デフォルト証明書ディレクトリーが以下の変数
DEFAULT_CERTIFICATE_DIRに設定されていることを確認します。oc env dc/router --list
$ oc env dc/router --list DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 設定されていない場合は、以下のコマンドを使用してディレクトリーを作成します。
oc env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private
$ oc env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/privateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 証明書を PEM 形式にエクスポートします。
cat custom-router.key custom-router.crt custom-ca.crt > custom-router.crt
$ cat custom-router.key custom-router.crt custom-ca.crt > custom-router.crtCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルーター証明書シークレットを上書きするか、またはこれを作成します。
証明書シークレットがルーターに追加されている場合は、シークレットを上書きします。追加されていなければ、新規シークレットを作成します。
シークレットを上書きするには、以下のコマンドを実行します。
oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls -o json --dry-run | oc replace -f -
$ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls -o json --dry-run | oc replace -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規シークレットを作成するには、以下のコマンドを実行します。
oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls oc volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certs
$ oc create secret generic router-certs --from-file=tls.crt=custom-router.crt --from-file=tls.key=custom-router.key --type=kubernetes.io/tls $ oc volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルーターをデプロイします。
oc rollout latest dc/router
$ oc rollout latest dc/routerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.17. セキュリティー保護されたルートの使用
現時点で、パスワードで保護されたキーファイルはサポートされていません。HAProxy は開始時にパスワードのプロンプトを出しますが、このプロセスを自動化する方法は提供しません。キーファイルからパスフレーズを削除するために、以下を実行できます。
openssl rsa -in <passwordProtectedKey.key> -out <new.key>
# openssl rsa -in <passwordProtectedKey.key> -out <new.key>以下の例は、トラフィックが宛先にプロキシー処理される前に TLS 終端がルーターで生じる場合にセキュアな edge termination ルートを使用する方法を示しています。セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、ルーターのフロントエンドで提供されます。
最初にルーターインスタンスを起動します。
oc adm router --replicas=1 --service-account=router
# oc adm router --replicas=1 --service-account=router
次に、セキュアな edge ルートのプライベートキー、CSR、証明書を作成します。この手順はお使いの認証局やプロバイダーによって異なります。www.example.test というドメインの単純な自己署名証明書の場合は、以下の例を参照してください。
上記の証明書とキーを使用してルートを生成します。
oc create route edge --service=my-service \
--hostname=www.example.test \
--key=example-test.key --cert=example-test.crt
$ oc create route edge --service=my-service \
--hostname=www.example.test \
--key=example-test.key --cert=example-test.crt
route "my-service" createdその定義を確認します。
www.example.test の DNS エントリーがルーターインスタンスを指し、ドメインへのルートが利用できることを確認します。以下の例では、Curl をローカルリゾルバーと共に使用して DNS ルックアップのシミュレーションを行っています。
routerip="4.1.1.1" # replace with IP address of one of your router instances. curl -k --resolve www.example.test:443:$routerip https://www.example.test/
# routerip="4.1.1.1" # replace with IP address of one of your router instances.
# curl -k --resolve www.example.test:443:$routerip https://www.example.test/4.2.18. (サブドメインの) ワイルドカードルートの使用
HAProxy ルーターはワイルドカードルートをサポートしており、ROUTER_ALLOW_WILDCARD_ROUTES 環境変数を true に設定することでこれを有効にできます。ルーター許可のチェックをパスする Subdomain のワイルドカードポリシーを持つすべてのルートは HAProxy ルーターによって提供されます。次に、HAProxy ルーターはルートのワイルドカードポリシーに基づいて (ルートの) 関連サービスを公開します。
ルートのワイルドカードポリシーを変更するには、ルートを削除してから更新されたワイルドカードポリシーでこれを再作成する必要があります。ルートの .yaml ファイルでルートのワイルドカードポリシーのみを編集しても機能しません。
oc adm router --replicas=0 ... oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true oc scale dc/router --replicas=1
$ oc adm router --replicas=0 ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
$ oc scale dc/router --replicas=1Web コンソールでワイルドカードルートを設定する方法についてはこちらを参照してください。
セキュアなワイルドカード edge termination ルートの使用
以下の例では、トラフィックが宛先にプロキシー処理される前にルーターで生じる TLS 終端を反映しています。サブドメイン example.org (*.example.org) のホストに送られるトラフィックは公開されるサービスにプロキシーされます。
セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、サブドメイン (*.example.org) に一致するすべてのホストのルーターのフロントエンドによって提供されます。
ルーターインスタンスを起動します。
oc adm router --replicas=0 --service-account=router oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true oc scale dc/router --replicas=1
$ oc adm router --replicas=0 --service-account=router $ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true $ oc scale dc/router --replicas=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow セキュリティー保護された edge ルートについてのプライベートキー、証明書署名要求 (CSR) および証明書を作成します。
この手順はお使いの認証局やプロバイダーによって異なります。
*.example.testというドメインの単純な自己署名証明書の場合はこの例を参照してください。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 上記の証明書とキーを使用してワイルドカードのルートを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow *.example.testの DNS エントリーがお使いのルーターインスタンスを指し、ドメインへのルートが利用できることを確認します。この例では
curlをローカルリゾルバーと共に使用し、DNS ルックアップのシミュレーションを行います。routerip="4.1.1.1" # replace with IP address of one of your router instances. curl -k --resolve www.example.test:443:$routerip https://www.example.test/ curl -k --resolve abc.example.test:443:$routerip https://abc.example.test/ curl -k --resolve anyname.example.test:443:$routerip https://anyname.example.test/
# routerip="4.1.1.1" # replace with IP address of one of your router instances. # curl -k --resolve www.example.test:443:$routerip https://www.example.test/ # curl -k --resolve abc.example.test:443:$routerip https://abc.example.test/ # curl -k --resolve anyname.example.test:443:$routerip https://anyname.example.test/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ワイルドカードルートを許可しているルーター (ROUTER_ALLOW_WILDCARD_ROUTES を true に設定する) の場合、ワイルドカードルートに関連付けられたサブドメインの所有権についてのいくつかの注意点があります。
ワイルドカードルートの設定前に、所有権は、最も古いルートを持つ namespace のホスト名についての要求に基づいて設定されました (これはその他の要求を行うルートよりも優先されました)。たとえば、ルート r1 がルート r2 より古い場合、one.example.test の要求を持つ namespace ns1 のルート r1 は同じホスト名 one.example.test について namespace ns2 のルート ns2 よりも優先されます。
さらに、他の namespace のルートは重複しないホスト名を要求することを許可されていました。たとえば、namespace ns1 のルート rone は www.example.test を要求でき、namespace d2 の別のルート rtwo は c3po.example.test を要求できました。
これは、同じサブドメイン (上記の例では example.test) を要求するワイルドカードルートがない場合には同様になります。
ただし、ワイルドカードルートはサブドメイン内のホスト名 ( \*.example.test 形式のホスト名) をすべて要求する必要があります。ワイルドカードルートの要求は、そのサブドメイン (example.test) の最も古いルートがワイルドカードルートと同じ namespace 内にあるかどうかによって許可または拒否されます。最も古いルートは通常のルートまたはワイルドカードルートのいずれかになります。
たとえば、ホスト owner.example.test を要求する 最も古い ルートが namespace ns1 にすでに存在し、後からそのサブドメイン (example.test) のルートを要求する新規のワイルドカードルート wildthing が追加される場合、そのワイルドカードルートによる要求は、そのルートが所有ルートと同じ namespace (ns1) にある場合にのみ許可されます。
以下の例では、ワイルドカードルートの要求が成功する場合と失敗する場合のさまざまなシナリオを示しています。
以下の例では、ワイルドカードルートを許可するルーターは、ワイルドカードルートがサブドメインを要求していない限り、サブドメイン example.test のホストに対する重複しない要求を許可します。
以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 なので、owner.example.test または aname.example.test の要求を許可しません。
以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、そのワイルドカードルートが同じ namespace に属しているので、`\*.example.test の要求を許可します。
以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、ワイルドカードルートが別の namespace cyclone に属するため、`\*.example.test の要求を許可しません。
同様に、ワイルドカードルートを持つ namespace がサブドメインを要求すると、その namespace 内のルートのみがその同じサブドメインでホストを要求できます。
以下の例では、ワイルドカードルートを持つ namespace ns1 のルートがサブドメイン example.test を要求すると、namespace ns1 内のルートのみがその同じサブドメインのホストを要求することを許可されます。
以下の例では、所有権のあるルートが削除され、所有権が namespace 内または namespace 間で渡されるさまざまなシナリオが示されています。namespace ns1 のホスト eldest.example.test を要求するルートが存在する場合、その namespace 内のワイルドカードルートはサブドメイン example.test を要求できます。ホスト eldest.example.test のルートが削除されると、次に古いルート senior.example.test が最も古いルートになりますが、これは他のルートに影響を与えません。ホスト senior.example.test のルートが削除されると、次に古いルート junior.example.test が最も古いルートになり、ワイルドカードルートの要求をブロックします。
4.2.19. コンテナーネットワークスタックの使用
OpenShift Container Platform ルーターはコンテナー内で実行され、デフォルトの動作として、ホスト (例: ルーターコンテナーが実行されるノードなど) のネットワークスタックを使用します。このデフォルトの動作には、リモートクライアントからのネットワークトラフィックがターゲットサービスとコンテナーに到達するためにユーザー空間で複数のホップを使用する必要がないので、パフォーマンス上のメリットがあります。
さらに、このデフォルト動作によってルーターはノードの IP アドレスではなくリモート接続の実際のソース IP アドレスを取得できます。これは、発信元の IP に基づいて ingress ルールを定義し、スティッキーセッションをサポートし、他に使用されているものの中でトラフィックを監視するのに役立ちます。
このホストネットワークの動作は --host-network ルーターコマンドラインオプションによって制御でき、デフォルトの動作は --host-network=true を使用した場合と等しくなります。コンテナーネットワークスタックを使用してルーターを実行する場合は、ルーターを作成する際に --host-network=false オプションを使用します。以下は例になります。
oc adm router --service-account=router --host-network=false
$ oc adm router --service-account=router --host-network=false内部的には、これは外部ネットワークがルーターと通信するために、ルーターコンテナーが 80 と 443 ポートを公開する必要があることを意味します。
コンテナーネットワークスタックを使用して実行することで、ルーターは接続のソース IP アドレスを実際のリモート IP アドレスではなくノードの NAT された IP アドレスとして扱うことを意味します。
マルチテナントネットワークの分離を使用する OpenShift Container Platform クラスターでは、--host-network=false オプションを指定したデフォルト以外の namespace のルーターはクラスターのすべてのルートを読み込みますが、ネットワークの分離により複数の namespace にあるルートには到達できません。--host-network=true オプションを指定すると、ルートはコンテナーネットワークをバイパスし、クラスターの任意の Pod にアクセスできます。この場合、分離が必要な場合は、複数の namespace のルートを追加しないでください。
4.2.20. ルーターメトリクスの公開
HAProxy ルーターメトリクス は、外部メトリクス収集および集約システム (例: Prometheus、statsd) で使用されるようにデフォルトで Prometheus 形式で公開されます。メトリクスは独自の HTML 形式でブラウザーで閲覧したり CSV ダウンロードを実行するために HAProxy ルーターから直接利用することもできます。これらのメトリクスには、HAProxy ネイティブメトリクスおよび一部のコントローラーメトリクスが含まれます。
以下のコマンドを使用してルーターを作成する場合、OpenShift Container Platform は Prometheus 形式のメトリクスをデフォルトが 1936 の統計ポートで利用可能にします。
oc adm router --service-account=router
$ oc adm router --service-account=routerPrometheus 形式で未加工統計を抽出するには、以下を実行します。
curl <user>:<password>@<router_IP>:<STATS_PORT>
curl <user>:<password>@<router_IP>:<STATS_PORT>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
curl admin:sLzdR6SgDJ@10.254.254.35:1936/metrics
$ curl admin:sLzdR6SgDJ@10.254.254.35:1936/metricsCopy to Clipboard Copied! Toggle word wrap Toggle overflow メトリクスにアクセスするために必要な情報は、ルーターサービスのアノテーションで確認できます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow prometheus.io/portはデフォルトが 1936 の統計ポートです。アクセスを許可するようファイウォールを設定する必要がある場合があります。直前のユーザー名およびパスワードを使用してメトリクスにアクセスします。パスは /metrics です。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブラウザーでメトリクスを取得するには、以下を実行します。
以下の環境変数をデプロイメント設定ファイルから削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ブラウザーで以下の URL を使用して統計ウィンドウを起動します。ここでは、
STATS_PORT値はデフォルトで1936になります。http://admin:<Password>@<router_IP>:<STATS_PORT>
http://admin:<Password>@<router_IP>:<STATS_PORT>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ;csvを URL に追加して CVS 形式の統計を取得できます。例を以下に示します。
http://admin:<Password>@<router_IP>:1936;csv
http://admin:<Password>@<router_IP>:1936;csvCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルーター IP、管理者名、およびパスワードを取得するには、以下を実行します。
oc describe pod <router_pod>
oc describe pod <router_pod>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
メトリクスのコレクションを表示しないようにするには、以下を実行します。
oc adm router --service-account=router --stats-port=0
$ oc adm router --service-account=router --stats-port=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 大規模クラスターの ARP キャッシュのチューニング
(net.ipv4.neigh.default.gc_thresh3 の値 (デフォルトで65536) を上回る) 多数のルート を持つ OpenShift Container Platform クラスターでは、ARP キャッシュでより多くのエントリーを許可するためにルーター Pod を実行するクラスターの各ノードで sysctl 変数のデフォルト値を増やす必要があります。
問題が発生している場合、以下のようなカーネルメッセージが表示されます。
[ 1738.811139] net_ratelimit: 1045 callbacks suppressed [ 1743.823136] net_ratelimit: 293 callbacks suppressed
[ 1738.811139] net_ratelimit: 1045 callbacks suppressed
[ 1743.823136] net_ratelimit: 293 callbacks suppressed
この問題が発生すると、oc コマンドは以下のエラーを出して失敗することがあります。
Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument
Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argumentIPv4 の ARP エントリーの実際の量を確認するには、以下を実行します。
ip -4 neigh show nud all | wc -l
# ip -4 neigh show nud all | wc -l
数字が net.ipv4.neigh.default.gc_thresh3 しきい値に近づき始めたら、値を増やします。以下を実行して現在値を取得します。
以下の sysctl は変数を OpenShift Container Platform の現在のデフォルト値に設定します。
sysctl net.ipv4.neigh.default.gc_thresh1=8192 sysctl net.ipv4.neigh.default.gc_thresh2=32768 sysctl net.ipv4.neigh.default.gc_thresh3=65536
# sysctl net.ipv4.neigh.default.gc_thresh1=8192
# sysctl net.ipv4.neigh.default.gc_thresh2=32768
# sysctl net.ipv4.neigh.default.gc_thresh3=65536これらの設定を永続化するには、このドキュメントを参照してください。
4.2.21. DDoS 攻撃からの保護
timeout http-request をデフォルトの HAProxy ルーターイメージに追加して、分散型の denial-of-service (DDoS) 攻撃 (slowloris など) からデプロイメントを保護します。
- 1
- timeout http-request は最大 5 秒に設定されます。HAProxy は HTTP 要求全体の送信のための 5 秒をクライアントに対して指定します。この指定がないと、HAProxy はエラーを出して接続を切断します。
また、環境変数 ROUTER_SLOWLORIS_TIMEOUT が設定されている場合、クライアントが HTTP 要求全体を送信するためにかかる合計時間が制限されます。これが設定されていない場合、HAProxy は接続を切断します。
環境変数を設定することで、情報をルーターのデプロイメント設定の一部として取得でき、テンプレートを手動で変更することが不要になります。一方、HAProxy 設定を手動で追加すると、ルーター Pod の再ビルドとルーターテンプレートファイルの保守が必要になります。
アノテーションを使用して、以下を制限する機能を含む基本的な DDoS 保護を HAProxy テンプレートルーターに実装します。
- 同時 TCP 接続の数
- クライアントが TCP 接続を要求できるレート
- HTTP 要求を実行できるレート
アプリケーションによってはトラフィックのパターンが完全に異なる場合があるため、これらはルートごとに有効にされます。
| 設定 | 説明 |
|---|---|
|
|
設定した内容を有効にします (true に設定した場合など)。 |
|
|
このルートの同じ IP アドレスで接続できる同時 TCP 接続の数。 |
|
|
クライアント IP で開くことができる TCP 接続の数。 |
|
|
クライアント IP が 3 秒間で実行できる HTTP 要求の数。 |
4.3. カスタマイズされた HAProxy ルーターのデプロイ
4.3.1. 概要
デフォルトの HAProxy ルーターは多数のユーザーのニーズを対応することを目的としています。ただし、このルーターは HAProxy のすべての機能を公開している訳ではありません。そのため、ユーザーはそれぞれのニーズに合わせてルーターを変更する必要があります。
新機能をアプリケーションバックエンド内で実装したり、現在の操作を変更する必要がある場合があります。ルータープラグインはこのカスタマイズを行うために必要なすべての機能を提供します。
ルーター Pod はテンプレートファイルを使用して必要な HAProxy 設定ファイルを作成します。テンプレートファイルは golang テンプレート です。テンプレートを処理する際に、ルーターはルーターのデプロイメント設定、許可されたルートのセット、一部のヘルパー機能などの OpenShift Container Platform 情報にアクセスします。
ルーター Pod が起動し、リロードされるたびに、HAProxy 設定ファイルが作成され、HAProxy が起動します。『HAProxy 設定マニュアル』には HAProxy のすべての機能と有効な設定ファイルの作成方法が記載されています。
configMap を使用して新規テンプレートをルーター Pod に追加することができます。この方法により、ルーターデプロイメント設定を変更して、configMap をルーター Pod のボリュームとしてマウントできます。 TEMPLATE_FILE 環境変数はルーター Pod のテンプレートファイルのフルパス名に設定されます。
または、カスタムルーターイメージをビルドし、ルーターの一部またはすべてをデプロイする際にこれを使用することができます。すべてのルーターが同じイメージを実行する必要はありません。これを実行するには、 haproxy-template.config ファイルを変更し、ルーターイメージを再ビルドします。新しいイメージはクラスターの Docker リポジトリーにプッシュされ、ルーターのデプロイメント設定の image: フィールドが新しい名前で更新されます。クラスターが更新されたら、イメージを再ビルドし、プッシュする必要があります。
いずれの場合でも、ルーター Pod はテンプレートファイルを使用して起動します。
4.3.2. ルーター設定テンプレートの取得
HAProxy テンプレートファイルはかなり大きく複雑です。一部を変更するのであれば、すべてを書き換えるよりも既存のテンプレートを変更する方が簡単です。マスターでルーターを実行し、ルーター Pod を参照することで実行中のルーターから haproxy-config.templateファイルを取得できます。
oc get po oc rsh router-2-40fc3 cat haproxy-config.template > haproxy-config.template oc rsh router-2-40fc3 cat haproxy.config > haproxy.config
# oc get po
NAME READY STATUS RESTARTS AGE
router-2-40fc3 1/1 Running 0 11d
# oc rsh router-2-40fc3 cat haproxy-config.template > haproxy-config.template
# oc rsh router-2-40fc3 cat haproxy.config > haproxy.configまたは、ルーターを実行しているノードにログオンします。
docker run --rm --interactive=true --tty --entrypoint=cat \
registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7 haproxy-config.template
registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7 haproxy-config.template
# docker run --rm --interactive=true --tty --entrypoint=cat \
registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7 haproxy-config.templateイメージ名は docker イメージ から取られます。
この内容をカスタマイズされたテンプレートのベースとして使用するためにファイルに保存します。保存された haproxy.config は実際に実行されているものを示します。
4.3.3. ルーター設定テンプレートの変更
4.3.3.1. 背景
このテンプレートは golang テンプレートに基づいています。これは、ルーターのデプロイメント設定の環境変数や、以下に示す設定情報およびルーターが提供するヘルパー機能を参照することができます。
テンプレートファイルの構造は作成される HAProxy 設定ファイルを反映します。テンプレートの処理時に、{{" something "}} によって囲まれていないものはすべて設定ファイルに直接コピーされます。{{" something "}} で囲まれている部分は評価されます。生成されるテキスト (ある場合) は設定ファイルにコピーされます。
4.3.3.2. Go テンプレートアクション
define アクションは、処理されるテンプレートを含むファイルに名前を付けます。
{{define "/var/lib/haproxy/conf/haproxy.config"}}pipeline{{end}}
{{define "/var/lib/haproxy/conf/haproxy.config"}}pipeline{{end}}| 関数 | 意味 |
|---|---|
|
|
有効なエンドポイントの一覧を返します。アクションが「Shuffle」の場合、エンドポイントの順序はランダム化されます。 |
|
|
Pod からの名前付き環境変数の取得を試行します。これが定義されていないか、または空の場合、オプションの 2 つ目の引数が返されます。それ以外の場合には空の文字列を返します。 |
|
|
1 つ目の引数は正規表現を含む文字列で、2 つ目の引数はテストに使用できる変数です。1 つ目の引数として提供される正規表現が 2 つ目の引数として提供される文字列と一致するかどうかを示すブール値を返します。 |
|
|
指定された変数が整数かどうかを判別します。 |
|
|
所定の文字列を許可された文字列の一覧と比較します。左から右にスキャンし、最初の一致を返します。 |
|
|
所定の文字列を許可された文字列の一覧と比較します。文字列が許可される値の場合は「true」を返します。それ以外の場合は、「false」を返します。 |
|
|
ルートホスト (とパス) に一致する正規表現を生成します。最初の引数はホスト名であり、2 つ目はパス、3 つ目はワイルドカードブール値です。 |
|
|
証明書の提供/証明書のマッチングに使用するホスト名を生成します。1 つ目の引数はホスト名で、2 つ目はワイルドカードブール値です。 |
|
|
所定の変数に「true」が含まれるかどうかを判別します。 |
これらの関数は、HAProxy テンプレートルータープラグインによって提供されます。
4.3.3.3. ルーターが提供する情報
このセクションでは、ルーターがテンプレートで利用可能にする OpenShift Container Platform の情報について説明しますす。ルーター設定パラメーターは HAProxy ルータープラグインに与えられるデータセットです。フィールドには (dot) .Fieldname を使用してアクセスします。
以下のルーター設定パラメーター表は各種フィールドの定義を詳しく取り上げています。とくに .State には許可されたルートセットが設定されます。
| フィールド | 種別 | 説明 |
|---|---|---|
|
|
文字列 |
ファイルが書き込まれるディレクトリー。デフォルトは /var/lib/containers/router に設定されます。 |
|
|
|
ルート。 |
|
|
|
サービスのルックアップ。 |
|
|
文字列 |
pem 形式のデフォルト証明書へのフルパス名。 |
|
|
|
ピア。 |
|
|
文字列 |
統計の公開に使用するユーザー名 (テンプレートがサポートしている場合)。 |
|
|
文字列 |
統計の公開に使用するパスワード (テンプレートがサポートしている場合)。 |
|
|
整数 |
統計の公開に使用するポート (テンプレートがサポートしている場合)。 |
|
|
bool |
ルーターがデフォルトポートをバインドすべきかどうか。 |
| フィールド | 種別 | 説明 |
|---|---|---|
|
|
文字列 |
ルートのユーザー固有の名前。 |
|
|
文字列 |
ルートの namespace。 |
|
|
文字列 |
ホスト名。例: |
|
|
文字列 |
オプションのパス。例: |
|
|
|
このバックエンドの終了ポリシー。マッピングファイルとルーター設定を利用します。 |
|
|
|
このバックエンドをセキュリティー保護するために使用する証明書。証明書 ID で指定します。 |
|
|
|
永続化する必要がある設定のステータスを示します。 |
|
|
文字列 |
ユーザーが公開したいポートを示します。空の場合、サービスのポートが選択されます。 |
|
|
|
edge termination ルートへの非セキュアな接続の必要な動作を示します。 |
|
|
文字列 |
Cookie ID を隠すために使用するルート + namespace 名のハッシュ。 |
|
|
bool |
このサービスユニットが ワイルドカードサポートを必要とすることを示します。 |
|
|
|
このルートに割り当てられるアノテーション。 |
|
|
|
このルートをサポートするサービスコレクション。マップの他のエントリーに関連してサービス名で指定され、これに割り当てられた重みで評価されます。 |
|
|
整数 |
ゼロ以外の重みを持つ |
ServiceAliasConfig はサービスのルートです。ホスト + パスによって特定されます。デフォルトのテンプレートは {{range $cfgIdx, $cfg := .State }} を使用してルートを繰り返し処理します。その {{range}} ブロック内で、テンプレートは $cfg.Field を使用して現在の ServiceAliasConfig のフィールドを参照できます。
| フィールド | 種別 | 説明 |
|---|---|---|
|
|
文字列 |
名前はサービス名 + namespace に対応します。 |
|
|
|
サービスをサポートするエンドポイント。これはルーターの最終のバックエンド実装に変換されます。 |
ServiceUnit はサービスをカプセル化したものであり、そのサービスをサポートするエンドポイントであり、またサービスを参照するルートです。これは、ルーター設定ファイルの作成を進めるデータです。
| フィールド | 種別 |
|---|---|
|
|
文字列 |
|
|
文字列 |
|
|
文字列 |
|
|
文字列 |
|
|
文字列 |
|
|
文字列 |
|
|
bool |
Endpoint は、Kubernetes エンドポイントの内部表現です。
| フィールド | 種別 | 説明 |
|---|---|---|
|
|
文字列 |
パブリック/プライベートキーのペアを表します。これは ID で識別され、ファイル名になります。CA 証明書には |
|
|
文字列 |
この設定に必要なファイルがディスクに永続化されていることを示します。有効な値の例: "saved" または "" (ブランク)。 |
| フィールド | 種別 | 説明 |
|---|---|---|
|
ID |
文字列 | |
|
コンテンツ |
文字列 |
証明書。 |
|
PrivateKey |
文字列 |
プライベートキー。 |
| フィールド | 種別 | 説明 |
|---|---|---|
|
|
文字列 |
セキュアな通信が停止する場合を指示します。 |
|
|
文字列 |
ルートへの非セキュアな接続の必要な動作を示します。各ルーターは公開するポートを独自に決定することがありますが、通常はポート 80 になります。 |
TLSTerminationType と InsecureEdgeTerminationPolicyType はセキュアな通信が停止する場合を指示します。
| 定数 | 値 | 意味 |
|---|---|---|
|
|
|
edge ルーターでの暗号化を終了します。 |
|
|
|
宛先での暗号化を終了し、宛先でトラフィックを復号化します。 |
|
|
|
edge ルーターで暗号化を終了し、宛先で提供される新規の証明書を使用して再暗号化します。 |
| 種別 | 意味 |
|---|---|
|
|
トラフィックは非セキュアなポートのサーバーに送信されます (デフォルト)。 |
|
|
トラフィックは非セキュアなポートでは許可されません。 |
|
|
クライアントはセキュアなポートにリダイレクトされます。 |
なし ("") は Disable と同じです。
4.3.3.4. アノテーション
各ルートにはアノテーションが割り当てることができます。各アノテーションは名前と値のみで構成されます。
名前は既存のアノテーションと競合しないものにできます。値は文字列です。文字列では複数のトークンをスペースで区切ることができます (例: aa bb cc)。テンプレートは {{index}} を使用してアノテーションの値を抽出します。以下は例になります。
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}この例は、これをどのようにクライアントの相互承認に使用できるかを示しています。
このコマンドを使用してホワイトリストの CN を処理できます。
oc annotate route <route-name> --overwrite whiteListCertCommonName="CN1 CN2 CN3"
$ oc annotate route <route-name> --overwrite whiteListCertCommonName="CN1 CN2 CN3"詳細は、「Route-specific Annotations」を参照してください。
4.3.3.5. 環境変数
テンプレートはルーター Pod に存在する任意の環境変数を使用できます。環境変数はデプロイメント設定に設定できます。また、新規の環境変数を追加できます。
これらは env 関数で参照されます。
{{env "ROUTER_MAX_CONNECTIONS" "20000"}}
{{env "ROUTER_MAX_CONNECTIONS" "20000"}}
1 つ目の文字列は変数であり、変数がないか、または nil の場合には 2 つ目の文字列がデフォルトになります。ROUTER_MAX_CONNECTIONS が設定されていないか、または nil の場合、20000 が使用されます。環境変数はマップと言えます。ここでキーは環境変数名で、内容は変数の値になります。
詳細は、「Route-specific Environment variables」を参照してください。
4.3.3.6. 使用例
以下で HAProxy テンプレートファイルに基づく単純なテンプレートを示します。
以下のコメントで開始します。
{{/*
Here is a small example of how to work with templates
taken from the HAProxy template file.
*/}}
{{/*
Here is a small example of how to work with templates
taken from the HAProxy template file.
*/}}
テンプレートは任意の数の出力ファイルを作成できます。defineコンストラクトを使用して出力ファイルを作成します。ファイル名は定義する引数として指定され、define ブロック内の一致する終了部分までのすべての情報がそのファイルの内容として書き込まれます。
{{ define "/var/lib/haproxy/conf/haproxy.config" }}
global
{{ end }}
{{ define "/var/lib/haproxy/conf/haproxy.config" }}
global
{{ end }}
上記は global を /var/lib/haproxy/conf/haproxy.config ファイルにコピーし、ファイルを閉じます。
ロギングを環境変数に基づいてセットアップします。
{{ with (env "ROUTER_SYSLOG_ADDRESS" "") }}
log {{.}} {{env "ROUTER_LOG_FACILITY" "local1"}} {{env "ROUTER_LOG_LEVEL" "warning"}}
{{ end }}
{{ with (env "ROUTER_SYSLOG_ADDRESS" "") }}
log {{.}} {{env "ROUTER_LOG_FACILITY" "local1"}} {{env "ROUTER_LOG_LEVEL" "warning"}}
{{ end }}
env 関数は、環境変数の値を抽出します。環境変数が定義されていないか、または nil の場合、2 つ目の引数が返されます。
with コンストラクトは with ブロック内の "." (ドット) の値を with に引数として提供される値に設定します。with アクションは Dot で nil をテストします。nil ではない場合、その句はend (終了部分) まで処理されます。上記では、ROUTER_SYSLOG_ADDRESS に /var/log/msg が含まれ、ROUTER_LOG_FACILITY が定義されておらず、ROUTER_LOG_LEVEL に info が含まれていると想定しています。以下が出力ファイルにコピーされます。
log /var/log/msg local1 info
log /var/log/msg local1 info
許可された各ルートは設定ファイルの行を生成します。range を使用して、許可されたルートを確認します。
{{ range $cfgIdx, $cfg := .State }}
backend be_http_{{$cfgIdx}}
{{end}}
{{ range $cfgIdx, $cfg := .State }}
backend be_http_{{$cfgIdx}}
{{end}}
.State は ServiceAliasConfig のマップです。ここで、キーはルート名になります。range はマップを通じて、パスするたびに keyを使用して $cfgIdx を設定し、`$cfg がルートを記述する ServiceAliasConfig をポイントするよう設定します。 myroute と hisroute という 2 つのルートがある場合、上記により以下が出力ファイルにコピーされます。
backend be_http_myroute backend be_http_hisroute
backend be_http_myroute
backend be_http_hisroute
ルートアノテーション $cfg.Annotations もマップであり、アノテーション名がキーとなり、コンテンツの文字列が値になっています。ルートは必要な数だけアノテーションを持つことができ、テンプレートの作成者が使用方法を定義します。ユーザーはアノテーションをルートにコード化し、テンプレート作成者は HAProxy テンプレートをカスタマイズしてそのアノテーションを処理できるようにします。
通常はアノテーションをインデックス化して値を取得します。
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}
{{$balanceAlgo := index $cfg.Annotations "haproxy.router.openshift.io/balance"}}
インデックスは指定されたアノテーションの値を抽出します。そのため、`$balanceAlgo はアノテーションまたは nil に関連付けられた文字列が含まれます。上記のように、nil 以外の文字列についてテストし、with コンストラクトを使用して影響を確認することができます。
{{ with $balanceAlgo }}
balance $balanceAlgo
{{ end }}
{{ with $balanceAlgo }}
balance $balanceAlgo
{{ end }}
$balanceAlgo が nil でない場合、balance $balanceAlgo は出力ファイルにコピーされます。
2 つ目の例では、アノテーションのタイムアウト値の設定に基づいてサーバータイムアウトを設定します。
$value := index $cfg.Annotations "haproxy.router.openshift.io/timeout"
$value := index $cfg.Annotations "haproxy.router.openshift.io/timeout"
$value を評価して、適切に作成された文字列が含まれていることを確認できます。matchPattern 関数は正規表現を受け入れ、引数が表現を満たしていれば true を返します。
matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value
matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value
これにより 5000ms を受け入れますが、7y は受け取りません。この結果はテストで使用できます。
{{if (matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value) }}
timeout server {{$value}}
{{ end }}
{{if (matchPattern "[1-9][0-9]*(us\|ms\|s\|m\|h\|d)?" $value) }}
timeout server {{$value}}
{{ end }}これを使用してトークンに一致させることもできます。
matchPattern "roundrobin|leastconn|source" $balanceAlgo
matchPattern "roundrobin|leastconn|source" $balanceAlgo
または、matchValues を使用してトークンと一致させることもできます。
matchValues $balanceAlgo "roundrobin" "leastconn" "source"
matchValues $balanceAlgo "roundrobin" "leastconn" "source"4.3.4. ConfigMap を使用してルーター設定テンプレートを置き換える
ConfigMap を使用して、ルーターイメージを再ビルドすることなくルーターインスタンスをカスタマイズできます。ルーター環境変数の作成し、変更することができるだけでなく、haproxy-config.template、reload-haproxy その他のスクリプトを変更することもできます。
- 上記のように変更する haproxy-config.template をコピーして、必要に応じて変更します。
ConfigMap を作成します。
oc create configmap customrouter --from-file=haproxy-config.template
$ oc create configmap customrouter --from-file=haproxy-config.templateCopy to Clipboard Copied! Toggle word wrap Toggle overflow customrouterConfigMap には変更された haproxy-config.template ファイルのコピーが含まれています。ルーターデプロイメント設定を変更し、ConfigMap をファイルとしてマウントし、
TEMPLATE_FILE環境変数がこれをポイントするようにします。これは、oc set envとoc volumeコマンドを使用するか、またはルーターデプロイメント設定を編集して実行できます。ocコマンドの使用Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ルーターデプロイメント設定の編集
oc edit dc routerを使用して、テキストエディターでルーターデプロイメント設定を編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を保存し、エディターを終了します。ルーターが再起動します。
4.3.5. Stick Table の使用
以下のカスタマイズの例を高可用なルーティングセットアップで使用することで、ピア間の同期を行う stick-table を使用できます。
ピアセクションの追加
ピア間で stick-table を同期するには、HAProxy 設定でピアセクションを定義する必要があります。このセクションによって、HAProxy がどのようにピアを識別し、接続するかが決まります。プラグインはデータを .PeerEndpoints 変数にあるテンプレートに提供するので、ルーターサービスのメンバーを簡単に識別できます。以下を追加することで、ピアセクションをルーターイメージ内の haproxy-config.template ファイルに追加することができます。
リロードスクリプトの変更
stick-table を使用する場合、HAProxy にピアセクションでローカルホスト名として見なすものをオプションで指示することができます。エンドポイントの作成時に、プラグインは TargetName をエンドポイントの TargetRef.Name の値に設定するよう試みます。TargetRef が設定されていない場合、TargetName は IP アドレスに設定されます。TargetRef.Name は Kubernetes ホスト名に対応しているので、-L オプションを reload-haproxy スクリプトに追加してローカルホストをピアセクションで識別できます。
- 1
- ピアセクションで使用されるエンドポイントターゲット名と一致している必要があります。
バックエンドの変更
最後に、stick-table をバックエンド内で使用するために、HAProxy 設定を変更して stick-table およびピアセットを使用することができます。以下は、stick-table を使用するように TCP 接続の既存のバックエンドを変更している例です。
この変更を行った後に、ルーターを再ビルドできます。
4.3.6. ルーターの再ビルド
ルーターを再ビルドするには、実行中のルーターにある複数のファイルのコピーが必要になります。作業ディレクトリーを作成し、ルーターからファイルをコピーします。
これらのファイルのいずれも編集するか、または置き換えることができます。ただし、conf/haproxy-config.template と reload-haproxy が変更される可能性が高くなります。
ファイルの更新後:
docker build -t openshift/origin-haproxy-router-myversion . docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest
# docker build -t openshift/origin-haproxy-router-myversion .
# docker tag openshift/origin-haproxy-router-myversion 172.30.243.98:5000/openshift/haproxy-router-myversion
# docker push 172.30.243.98:5000/openshift/origin-haproxy-router-pc:latest
新規ルーターを使用するには、image: 文字列を変更するか、または --images=<repo>/<image>:<tag> フラグを oc adm router コマンドに追加してルーターデプロイ設定を編集します。
変更のデバッグ時に、デプロイメント設定で imagePullPolicy: Always を設定して各 Pod の作成時にイメージプルを強制的に実行すると便利です。デバッグが完了したら、これを imagePullPolicy: IfNotPresent に戻して各 Pod の起動時のプルを回避します。
4.4. HAProxy ルーターを設定して PROXY プロトコルを使用する
4.4.1. 概要
デフォルトで HAProxy ルーターは、非セキュアな edge および re-encrypt ルートへの受信接続に HTTP を使用することを想定しています。ただし、PROXY プロトコルを使用することで、ルーターが受信要求を予想するよう設定することができます。このトピックでは、HAProxy ルーターと外部ロードバランサーを PROXY プロトコルを使用するように設定する方法を説明しています。
4.4.2. PROXY プロトコルを使用する理由
プロキシーサーバーやロードバランサーなどの中間サービスが HTTP 要求を転送する際に、これは接続のソースアドレスを要求の「Forwarded」ヘッダーに追加して、この情報を後続の中間サービスと、要求が最終的に転送されるバックエンドサービスに提供できます。ただし、接続が暗号化されている場合、中間サービスは「Forwarded」ヘッダーを変更できません。この場合、要求が転送されても HTTP ヘッダーは元のソースアドレスを正確に通信することができません。
この問題を解決するために、一部のロードバランサーは、単純に HTTP を転送する代替手段として PROXY プロトコルを使用して HTTP 要求をカプセル化します。カプセル化によって、ロードバランサーは転送される要求自体を変更することなく、情報を要求に追加することができます。これにより、ロードバランサーは、暗号化された接続を転送する場合でもソースアドレスを通信できます。
HAProxy ルーターが PROXY プロトコルを受け入れ、HTTP 要求のカプセル化を解除するように設定できます。ルーターは edge および re-encrypt ルートの暗号化を終了するので、ルーターは要求の「Forwarded」HTTP ヘッダー (および関連する HTTP ヘッダー) を更新でき、PROXY プロトコルを使用して通信されるソースアドレスを追加できます。
PROXY プロトコルと HTTP は互換性がなく、組み合わせることはできません。ルーターの前にロードバランサーを使用する場合、これらがどちらも PROXY プロトコルまたは HTTP のいずれかを使用する必要があります。一方を PROXY プロトコルを使用するように設定し、他方を HTTP を使用するように設定すると、ルーティングが失敗します。
4.4.3. PROXY プロトコルの使用
デフォルトで、HAProxy ルーターは PROXY プロトコルを使用しません。ROUTER_USE_PROXY_PROTOCOL 環境変数を使用することで、ルーターが受信接続に PROXY プロコトルの使用を予想するように設定できます。
PROXY プロコトルの有効化
oc env dc/router ROUTER_USE_PROXY_PROTOCOL=true
$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=true
変数を true または TRUE 以外の値に設定し、PROXY プロコトルを無効にします。
PROXY プロトコルの無効化
oc env dc/router ROUTER_USE_PROXY_PROTOCOL=false
$ oc env dc/router ROUTER_USE_PROXY_PROTOCOL=falseルーターで PROXY プロトコルを有効にする場合、ルーターの前のロードバランサーが PROXY プロコトルを使用するように設定する必要があります。以下は、Amazon の Elastic Load Balancer (ELB) サービスを PROXY プロトコルを使用するように設定した例です。この例では、ELB がポート 80 (HTTP)、443 (HTTPS)、5000 (イメージレジストリーの場合) を 1 つ以上の EC2 インスタンスで実行されるルーターに転送することを想定しています。
Amazon ELB を設定して PROXY プロコトルを使用する
後続の手順を単純化するために、最初に一部の Shell 変数を設定します。
lb='infra-lb' instances=( 'i-079b4096c654f563c' ) secgroups=( 'sg-e1760186' ) subnets=( 'subnet-cf57c596' )
$ lb='infra-lb'1 $ instances=( 'i-079b4096c654f563c' )2 $ secgroups=( 'sg-e1760186' )3 $ subnets=( 'subnet-cf57c596' )4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、適切なリスナーやセキュリティーグループおよびサブネットを使用して ELB を作成します。
注記すべてのリスナーが HTTP プロトコルではなく TCP プロトコルを使用するよう設定する必要があります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ルーターインスタンスを ELB に登録します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ELB のヘルスチェックを設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 最後に、
ProxyProtocol属性を有効にしたロードバランサーのポリシーを作成し、ELB の TCP ポート 80 および 443 でポリシーを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
設定の確認
ロードバランサーを以下のように検証して、設定が正しいことを確認します。
または、ELB をすでに設定していても、PROXY プロトコルを使用するよう設定されていない場合は、 TCP ポート 80 の既存リスナーを、HTTP ではなく TCP プロコトルを使用するように変更する必要があります (TCP ポート 443 はすでに TCP プロトコルを使用しているはずです)。
aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \ --load-balancer-ports 80 aws elb create-load-balancer-listeners --load-balancer-name "$lb" \ --listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'
$ aws elb delete-load-balancer-listeners --load-balancer-name "$lb" \
--load-balancer-ports 80
$ aws elb create-load-balancer-listeners --load-balancer-name "$lb" \
--listeners 'Protocol=TCP,LoadBalancerPort=80,InstanceProtocol=TCP,InstancePort=80'プロコトル更新の確認
プロコトルが以下のように更新されていることを確認します。
- 1
- TCP ポート 80 のリスナーなど、すべてのリスナーが TCP プロコトルを使用している必要があります。
次にロードバランサーポリシーを作成し、上記の手順 5 に説明されているようにこれを ELB に追加します。
4.5. F5 ルータープラグインの使用
4.5.1. 概要
F5 ルータープラグインは OpenShift Container Platform 3.0.2 以降で利用できます。
F5 ルーターブラグインはコンテナーイメージとして提供され、デフォルトの HAProxy ルーターのように Pod として実行されます。
F5 と Red Hat 間のサポート体制により、Red Hat は F5 の統合を完全にサポートしています。F5 は F5 BIG-IP® 製品のサポートを提供しています。F5 と Red Hat は Red Hat OpenShift との統合を共同でサポートしています。Red Hat はバグフィックスおよび機能拡張を支援する一方で、すべての情報が F5 Networks に通信され、それらが開発サイクルの一部として管理されます。
4.5.2. 前提条件とサポート容易性
F5 ルータープラグインのデプロイ時に、以下の要件を満たしていることを確認してください。
F5 ホスト IPに以下が設定されている:
- API アクセスの認証情報
- プライベートキーによる SSH アクセス
- 高度な Shell アクセスを持つ F5 ユーザー
HTTP ルートの仮想サーバー:
- HTTP プロファイル は http である必要があります。
HTTP プロファイルルートを持つ仮想サーバー:
- HTTP プロファイル は http である必要があります。
- SSL プロファイル (クライアント) は clientssl である必要があります。
- SSL プロファイル (サーバー) は serverssl である必要があります。
edge 統合の場合 (非推奨):
- 稼働中の Ramp ノード
- Ramp ノードへの稼働中のトンネル
ネイティブ統合の場合:
- ポート 4789/UDP のすべてのノードと通信できるホストの内部 IP
- F5 ホストにインストールされた sdn-services アドオンライセンス
OpenShift Container Platform は以下の F5 BIG-IP® バージョンのみをサポートしています。
- 11.x
- 12.x
以下の機能は F5 BIG-IP® でサポートされていません。
- ワイルドカードルートと re-encrypt ルートの併用: ルートに証明書とキーを指定する必要があります。証明書、キー、認証局 (CA) を指定しても、CA は使用されません。
- 関連ルートを持たないサービスを含め、すべてのサービスのプールが作成されます。
- アプリケーションのアイドリング
-
redirect モードの暗号化されていない HTTP トラフィックと edge TLS 終端。(
insecureEdgeTerminationPolicy: Redirect) -
シャード化、つまり F5 で複数の
vserversを設定する。 -
SSL 暗号 (
ROUTER_CIPHERS=modern/old) - エンドポイントのヘルスチェックの間隔やチェックタイプのカスタマイズ。
- メトリクスサーバーの使用による F5 メトリクスの提供。
-
サービスでされるポートではない各種ターゲットポート (
PreferPort/TargetPort) の指定。 - ソース IP ホワイトリストのカスタマイズ。つまり特定の IP アドレスのルートのみに対してトラフィックを許可する。
-
max connect timeまたはtcp FIN timeoutなどのタイムアウト値のカスタマイズ。 - F5 BIG-IP® の HA モード。
4.5.2.1. 仮想サーバーの設定
openshift-F5 統合ルーターを使用する前提条件として、2 つの仮想サーバー (HTTP および HTTPS プロファイルのそれぞれに 1 つの仮想サーバー) を F5 BIG-IP® アプライアンスでセットアップする必要があります。
F5 BIG-IP® アプライアンスで仮想サーバーを設定するには、F5 の指示に従います。
仮想サーバーを作成する際に、以下の設定が有効であることを確認します。
-
HTTP サーバーの場合は、
ServicePortを'http'/80に設定します。 -
HTTPS サーバーの場合は、
ServicePortを'https'/443に設定します。 - 基本設定で、両方の仮想サーバーの HTTP プロファイルを /Common/http に設定します。
HTTPS サーバーの場合は、 デフォルトの client-ssl プロファイルを作成し、SSL プロファイル (クライアント) に対してこれを選択します。
- デフォルトのクライアント SSL プロファイルを作成するには、F5 の指示、とくに 「Configuring the fallback (default) client SSL profile」セクションに従います。このセクションでは、カスタム証明書がルートまたはサーバー名に提供されない場合にデフォルトで提供される証明書/キーのペアについて説明しています。
4.5.3. F5 ルーターのデプロイ
ルート証明書は scp コマンドを使用してコピーされるため、F5 ルーターは特権モードで実行される必要があります。
oc adm policy remove-scc-from-user hostnetwork -z router oc adm policy add-scc-to-user privileged -z router
$ oc adm policy remove-scc-from-user hostnetwork -z router
$ oc adm policy add-scc-to-user privileged -z router
oc adm router コマンドを使用して F5 ルーターをデプロイしますが、F5 BIG-IP® ホストの以下のパラメーターを指定する追加のフラグ (または環境変数) を提供します。
| フラグ | 説明 |
|---|---|
|
|
F5 ルーターの起動を指定します (デフォルトの |
|
|
F5 BIG-IP® ホストの管理インターフェースのホスト名または IP アドレスを指定します。 |
|
|
F5 BIG-IP® のユーザー名 (通常は admin) を指定します。F5 BIG-IP のユーザーアカウントは F5 BIG-IP システムの Advanced Shell (Bash) へのアクセスがなければなりません。 |
|
|
F5 BIG-IP® のパスワードを指定します。 |
|
|
HTTP 接続の F5 仮想サーバーの名前を指定します。これは、ルーター Pod の起動前にユーザーによって設定される必要があります。 |
|
|
HTTPS 接続の F5 仮想サーバーの名前を指定します。これは、ルーター Pod の起動前にユーザーによって設定される必要があります。 |
|
|
F5 BIG-IP® ホストの SSH プライベートキーファイルへのパスを指定します。ルートのキーと証明書ファイルをアップロードし、削除する必要があります。 |
|
|
F5 ルーターが F5 BIG-IP® ホストの証明書の厳しい検証を省略することを示す Boolean フラグ。 |
|
|
F5 BIG-IP® パーティションパス (デフォルトは /Common) を指定します。 |
例を以下に示します。
HAProxy ルーターの場合のように、oc adm router コマンドがサービスとデプロイメント設定オブジェクトを作成するため、F5 ルーター自体が実行されるレプリケーションコントローラーと Pod が作成されます。レプリケーションコントローラーはクラッシュが発生した場合に F5 ルーターを再起動します。F5 ルーターはルート、エンドポイント、ノードを監視し、F5 BIG-IP® を適宜設定するため、 F5 ルーターを適切に設定された F5 BIG-IP® デプロイメントで実行することは高可用性の要件を満たすはずです。
4.5.4. F5 ルーターのパーティションパス
パーティションパスによって、デフォルトの /Common パーティションではなく、カスタムの F5 BIG-IP® 管理パーティションで OpenShift Container Platform ルーティング設定を保存できます。カスタム管理パーティションを使用して F5 BIG-IP® 環境を保護することができます。つまり、F5 BIG-IP® システムオブジェクトに保存される OpenShift Container Platform 特有の設定が論理コンテナー内にあり、管理者はその管理パーティションでアクセス制御を定義できます。
管理パーティションの詳細については、F5 BIG-IP® ドキュメントを参照してください。
パーティションパスについて OpenShift Container Platform を設定するには、以下を実行します。
オプションで一部のクリーニング手順を実行できます。
- F5 が /Common および /Custom パスに切り替えられるよう設定されていることを確認してください。
-
vxlan5000の静的 FDB を削除します。詳細は、F5 BIG-IP® ドキュメントを参照してください。
- カスタムパーティションの仮想サーバーを設定します。
--external-host-partition-pathフラグを使用して F5 ルーターをデプロイし、パーティションパスを指定します。oc adm router --external-host-partition-path=/OpenShift/zone1 ...
$ oc adm router --external-host-partition-path=/OpenShift/zone1 ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.5. F5 ネイティブ統合のセットアップ
このセクションでは、OpenShift Container Platform への F5 ネイティブ統合のセットアップ方法を確認します。F5 アプライアンスと OpenShift Container Platform 接続の概念および F5 ネイティブ統合のデータフローはルートに関するトピックの「F5 Native Integration」セクションで説明されています。
F5 BIG-IP® アプライアンスのバージョン 12.x 以降のみが、このセクションに記載されているネイティブ統合に対応しています。また、適切に統合を行うために sdn-services アドオンライセンスが必要になります。バージョン 11.x の場合は、ramp ノード のセットアップ手順に従ってください。
OpenShift Container Platform バージョン 3.4 時点で、F5 の OpenShift Container Platform とのネイティブな統合により、F5 の Ramp ノードを OpenShift SDN で作成されるオーバーレイネットワークの Pod に到達するように設定する必要がありません。
F5 コントローラー Pod は、Pod に直接正常に接続できるようにするために必要な十分な情報を使って起動する必要があります。
OpenShift Container Platform クラスターにゴースト
hostsubnetを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 作成したゴースト
hostsubnetに割り当てるサブネットを決定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
新たに作成した
hostsubnetのSUBNETを確認します。この例では10.131.0.0/23です。 Pod ネットワーク全体の CIDR を取得します。
oc get clusternetwork
$ oc get clusternetworkCopy to Clipboard Copied! Toggle word wrap Toggle overflow この値は
10.128.0.0/14のように表示されます。マスク (この例では14) に注意してください。-
ゲートウェイアドレスを作成するには、
hostsubnetから任意の IP アドレス (例:10.131.0.5) を選択します。Pod ネットワークのマスク (14) を使用します。ゲートウェイアドレスは10.131.0.5/14になります。 こちらの指示に従って F5 コントローラー Pod を起動してください。さらに、サービスアカウントに「ノード」のクラスターリソースへのアクセスを許可し、VXLAN のネイティブ統合に 2 つの新しい追加オプションを使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記external-host-usernameは、F5 BIG-IP システムの Advanced Shell (Bash) へのアクセスを持つ F5 BIG-IP ユーザーアカウントです。
これで Ramp ノードを設定せずに F5 のセットアップを開始できます。
第5章 Red Hat CloudForms のデプロイ
5.1. {mgmt-app} の OpenShift Container Platform へのデプロイ
5.1.1. はじめに
OpenShift Container Platform インストーラーには、Red Hat CloudForms 4.6 (CloudForms Management Engine 5.9 または CFME) を OpenShift Container Platform にデプロイするための Ansible ロールの openshift-management と Playbook が含まれています。
現在の実装には、OpenShift Container Platform 3.6 ドキュメントで説明されているように、Red Hat CloudForms 4.5 のテクノロジープレビューのデプロイメントプロセスとの互換性はありません。
Red Hat CloudForms を OpenShift Container Platform にデプロイする際には、以下の 2 つ点について決定する必要があります。
- 外部またはコンテナー化された (Pod 化された とも言う) PostgreSQL データベースを使用するかどうか。
- 永続ボリューム (PV) をどのストレージクラスでサポートするか。
最初の点については、Red Hat CloudForms で使用する PostgreSQL データベースが置かれている場所によって Red Hat CloudForms を以下のいずれかの方法でデプロイできます。
| デプロイのバリアント | 説明 |
|---|---|
|
完全コンテナー化 |
すべてのアプリケーションサービスと PostgreSQL データベースは、OpenShift Container Platform で Pod として実行されます。 |
|
外部データベース |
アプリケーションは外部でホストされた PostgreSQL データベースサーバーを使用し、その他すべてのサービスは OpenShift Container Platform で Pod として実行されます。 |
2 つ目の点については、openshift-management ロールが、多くのデフォルトのデプロイメントパラメーターの上書き用にカスタマイズオプションを提供します。これには、 PV をサポートするための以下のストレージクラスのオプションが含まれています。
| ストレージクラス | 説明 |
|---|---|
|
NFS (デフォルト) |
ローカル、クラスター上 |
|
NFS (外部) |
NFS の他の場所 、ストレージアプライアンスなど |
|
クラウドプロバイダー |
クラウドプロバイダー (GCE または AWS) の自動ストレージプロビジョニングを使用 |
|
事前設定 (詳細) |
ユーザーが事前にすべてを作成済みであることを前提とする |
本書では、Red Hat CloudForms を OpenShift Container Platform で実行するための要件、利用可能な設定変数の説明、および OpenShift Container Platform の初回インストール時かクラスターのプロビジョニング後のいずれかでインストーラーを実行する方法などについてのトピックを扱います。
5.2. Red Hat CloudForms を OpenShift Container Platform で使用するための要件
デフォルトの要件は以下の表に記載されています。これらはテンプレートパラメーターをカスタマイズして上書きできます。
以下の要件を満たしていないと、アプリケーションのパフォーマンスが低下するか、またはデプロイに失敗する可能性があります。
| 項目 | 要件 | 説明 | カスタマイズパラメーター |
|---|---|---|---|
|
アプリケーションメモリー |
≥ 4.0 Gi |
アプリケーションのメモリー最小要件 |
|
|
アプリケーションストレージ |
≥ 5.0 Gi |
アプリケーションの PV サイズ最小要件 |
|
|
PostgreSQL メモリー |
≥ 6.0 Gi |
データベースのメモリー最小要件 |
|
|
PostgreSQL ストレージ |
≥ 15.0 Gi |
データベースの PV サイズ最小要件 |
|
|
クラスターホスト |
≥ 3 |
クラスター内のホスト数 |
該当なし |
以上の要件をまとめると以下のようになります。
- ユーザーにはいくつかのクラスターノードが必要である。
- クラスターノードには多くの利用可能なメモリーが必要である。
- ユーザーは、ローカルまたはクラウドプロバイダーに数 GiB の利用可能なストレージを持っている必要がある。
- PV サイズはテンプレートパラメーターの値を上書きして変更できる。
5.3. ロール変数の設定
5.3.1. 概要
以下のセクションでは、Ansible インベントリーファイル で使用されるロール変数について説明します。ロール変数は、インストーラーを実行する際に Red Hat CloudForms インストールの動作を制御するために使用されます。
5.3.2. 一般的な変数
| 変数 | 必須 | デフォルト | 説明 |
|---|---|---|---|
|
|
不可 |
|
ブール値。アプリケーションをインストールするには |
|
|
Yes |
|
CFME 4.6 は現在利用可能 (ベータ版は利用不可) ですが、この変数はインストールを開始するために |
|
|
Yes |
|
インストールする Red Hat CloudForms のデプロイメントバリアント。現時点では、これをデフォルトの |
|
|
不可 |
|
Red Hat CloudForms インストールの namespace (プロジェクト)。 |
|
|
不可 |
|
namespace (プロジェクト) の説明。 |
|
|
不可 |
|
デフォルトの管理ユーザー名。この値を変更してもユーザー名は変更されません。名前をすでに変更しており、統合スクリプト (コンテナープロバイダーを追加するためのスクリプトなど) を実行している場合にのみこの値を変更してください。 |
|
|
不可 |
|
デフォルトの管理パスワード。この値を変更してもパスワードは変更されません。このパスワードをすでに変更しており、統合スクリプト (コンテナープロバイダーを追加するためのスクリプトなど) を実行している場合にのみこの値を変更してください。 |
5.3.3. テンプレートパラメーターのカスタマイズ
openshift_management_template_parameters Ansible ロール変数は、アプリケーションまたは PV テンプレートで上書きする必要のあるテンプレートを指定するために使用します。
たとえば、PostgreSQL Pod のメモリー要件を減らしたい場合には、以下を設定します。
openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}
openshift_management_template_parameters={'POSTGRESQL_MEM_REQ': '1Gi'}
Red Hat CloudForms テンプレートが処理される際に、1Gi が POSTGRESQL_MEM_REQ テンプレートパラメーターの値に使用されます。
すべてのテンプレートパラメーターが (コンテナー化されたデータベースと外部データベースの) 両方 のテンプレートバリアントにある訳ではありません。たとえば、Pod 化されたデータベースのテンプレートには POSTGRESQL_MEM_REQ パラメーターがありますが、このパラメーターは外部のデータベーステンプレートにはありません。そこには Pod を必要とするデータベースが存在せず、この情報は必要とされないためです。
したがって、テンプレートパラメーターを上書きする場合には十分注意する必要があります。テンプレートで定義されていないパラメーターを追加するとエラーの原因になります。管理アプリケーションの作成を確認するタスクの実行時にエラーを受信した場合は、インストーラーを再度実行する前にアンインストールのスクリプトを実行してください。
5.3.4. データベース変数
5.3.4.1. コンテナー化された (Pod 化された) データベース
cfme-template.yaml ファイルにある POSTGRES_* または DATABASE_* テンプレートパラメーターは、インベントリーファイルの openshift_management_template_parameters ハッシュを使用してカスタマイズすることができます。
5.3.4.2. 外部データベース
cfme-template-ext-db.yaml ファイルにある POSTGRES_* または DATABASE_* テンプレートパラメーターは、インベントリーファイルの openshift_management_template_parameters ハッシュを使用してカスタマイズすることができます。
外部 PostgreSQL データベースは、ユーザーにデータベース接続パラメーターを指定するように要求します。必要な接続キーはインベントリーの openshift_management_template_parameters パラメーターに設定する必要があります。必要なキー以下の通りです。
-
DATABASE_USER -
DATABASE_PASSWORD -
DATABASE_IP -
DATABASE_PORT(ほとんどの PostgreSQL サーバーはポート5432で実行されます) -
DATABASE_NAME
外部データベースで PostgreSQL 9.5 が実行されていることを確認します。実行されていないと、CloudForms アプリケーションを正常にデプロイできない場合があります。
インベントリーに、以下のような行が含まれているはずです。
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}- 1
openshift_management_app_templateパラメーターをcfme-template-ext-dbに設定します。
5.3.5. ストレージクラス変数
| 変数 | 必須 | デフォルト | 説明 |
|---|---|---|---|
|
|
不可 |
|
使用されるストレージのタイプ。オプションには |
|
|
不可 |
|
NetApp アプライアンスなどの外部 NFS サーバーを使用している場合、ここにホスト名を設定する必要があります。外部 NFS を使用していない場合は値を |
|
|
不可 |
|
外部 NFS を使用している場合、ベースパスをこのエクスポートの位置に設定できます。ローカルの NFS の場合、ローカルの NFS エクスポートに使用されているデフォルトのパスを変更する必要がある場合にも、この値を変更します。 |
|
|
不可 |
|
|
5.3.5.1. NFS (デフォルト)
NFS ストレージクラスは、概念実証およびテストデプロイメントに最も適しています。このクラスは、デプロイメント用のデフォルトのステージクラスにもなります。これを選択した場合、追加の設定は不要です。
このストレージクラスは、必要な PV をサポートするように NFS をクラスターホスト (デフォルトではインベントリーファイルの最初のマスター) に設定します。アプリケーションは PV を必要とし、データベース (外部でホストされている可能性がある) は 2 番目の PV が必要となる場合があります。PV サイズの最小要件は、Red Hat CloudForms アプリケーションは 5GiB、PostgreSQL データベースは 15GiB です (NFS 専用で使用する場合は、ボリュームまたはパーティション上の使用可能な最小領域は 20GiB です)。
カスタマイズは、以下のロール変数を使って行われます。
-
openshift_management_storage_nfs_base_dir -
openshift_management_storage_nfs_local_hostname
5.3.5.2. NFS (外部)
外部 NFS は、必要な PV にエクスポートを提供するために事前設定された NFS サーバーを使用します。外部 NFS の場合、ユーザーは cfme-app とオプションで cfme-db (コンテナー化されたデータベース用) のエクスポートが必要です。
設定は、以下のロール変数を使って提供されます。
-
openshift_management_storage_nfs_external_hostname -
openshift_management_storage_nfs_base_dir
openshift_management_storage_nfs_external_hostnameパラメーターは、外部 NFS サーバーのホスト名または IP に設定する必要があります。
/exports がエクスポートの親ディレクトリーではない場合、ベースディレクトリーを openshift_management_storage_nfs_base_dir パラメーターで設定する必要があります。
たとえば、サーバーエクスポートが /exports/hosted/prod/cfme-app の場合は、openshift_management_storage_nfs_base_dir=/exports/hosted/prod を設定する必要があります。
5.3.5.3. クラウドプロバイダー
ストレージクラスに OpenShift Container Platform のクラウドプロバイダー統合を使用している場合、Red Hat CloudForms は必要な PV をサポートするためにこのクラウドプロバイダーを使用することができます。これを正常に実行するには、openshift_cloudprovider_kind 変数 (AWS または GCE 用)と、ユーザーが選択したクラウドプロバイダーに固有のすべての関連パラメーターを設定している必要があります。
アプリケーションがこのストレージクラスを使って作成されている場合、必要な PV は、設定済みのクラウドプロバイダーのストレージ統合を使って自動的にプロビジョニングされます。
このストレージクラスの動作を設定するために使用される追加の変数はありません。
5.3.5.4. 事前設定 (詳細)
preconfigured (事前設定されている) ストレージクラスの場合、ユーザーは各自の操作を正確に把握しており、すべてのストレージ要件が事前に配慮されていることを意味します。この場合、通常は適切なサイズに設定された PV がすでに作成されているので、インストーラーはストレージ設定を変更する必要がありません。
このストレージクラスの動作を設定するために使用される追加の変数はありません。
5.4. インストーラーの実行
5.4.1. OpenShift Container Platform のインストール時またはインストール後の Red Hat CloudForms のデプロイ
Red Hat CloudForms のデプロイを、OpenShift Container Platform の初回インストール時か、またはクラスターのプロビジョニング後のいずれかに実行することを選択できます。
以下が
[OSEv3:vars]セクションの下にあるインベントリーファイルに設定されていることを確認します。[OSEv3:vars] openshift_management_install_management=true openshift_management_install_beta=true
[OSEv3:vars] openshift_management_install_management=true openshift_management_install_beta=true1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- CFME 4.6 は現在利用可能 (ベータ版は利用不可) ですが、この変数はインストールを開始するために
trueに設定する必要があります。この要件は、今後のリリースでは取り除かれる予定です (BZ#1557909)。
- インベントリーファイルにある Red Hat CloudForms のその他のロール変数を、「ロール変数の設定」で説明されているように設定します。「インベントリーファイルの例」には、これを実行するのに役立つリソースがあります。
OpenShift Container Platform がすでにプロビジョニングされているかどうかに応じて、実行する Playbook を選択します。
- Red Hat CloudForms を、OpenShift Container Platform クラスターのインストールと同時にインストールする必要がある場合には、「通常インストール (Advanced installation) の実行」で説明されているように標準の config.yml Playbook を呼び出して、OpenShift Container Platform クラスターと Red Hat CloudForms のインストールを開始します。
Red Hat CloudForms を、すでにプロビジョニングされている OpenShift Container Platform クラスターにインストールする必要がある場合には、Red Hat CloudForms Playbook を直接呼び出してインストールを開始します。
ansible-playbook -v [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-management/config.yml# ansible-playbook -v [-i /path/to/inventory] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-management/config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2. インベントリーファイルの例
このセクションでは、インベントリーファイルのスニペットの例について説明し、使い始めに役立つ OpenShift Container Platform での Red Hat CloudForms の各種の設定について説明します。
変数の詳しい説明については、「ロール変数の設定」を参照してください。
5.4.2.1. すべてのデフォルト
以下は、すべてのデフォルト値と選択肢を使用した最も単純な例です。これで、Red Hat CloudForms のインストールが完全にコンテナー化 (Pod 化) されます。すべてのアプリケーションコンポーネントと PostgreSQL データベースが OpenShift Container Platform に Pod として作成されます。
[OSEv3:vars] openshift_management_app_template=cfme-template
[OSEv3:vars]
openshift_management_app_template=cfme-template5.4.2.2. 外部 NFS ストレージ
以下は、前述の例と同様に (ただしローカルの NFS サービスをクラスターで使用する代わりに)、既存の外部 NFS サーバー (ストレージアプライアンスなど) を使用しています。
[OSEv3:vars] openshift_management_app_template=cfme-template openshift_management_storage_class=nfs_external openshift_management_storage_nfs_external_hostname=nfs.example.com
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_storage_class=nfs_external
openshift_management_storage_nfs_external_hostname=nfs.example.com 外部 NFS ホストが /exports/hosted/prod などの異なる親ディレクトリーの下でエクスポートディレクトリーをホストしている場合は、以下の変数を追加します。
openshift_management_storage_nfs_base_dir=/exports/hosted/prod
openshift_management_storage_nfs_base_dir=/exports/hosted/prod5.4.2.3. PV サイズの上書き
以下の例では、永続ボリューム (PV) のサイズを上書きします。PV サイズは openshift_management_template_parameters で設定する必要があります。これにより、アプリケーションとデータベースは相互に干渉しあうことなく作成済みの PV で要求を実行できます。
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_VOLUME_CAPACITY': '10Gi', 'DATABASE_VOLUME_CAPACITY': '25Gi'}5.4.2.4. メモリー要件の上書き
テストまたは概念実証のインストールでは、アプリケーションとデータベースのメモリー要件を設定している容量内に収めるようにする必要がある場合があります。メモリーの上限を下げると、パフォーマンスが低下するか、またはアプリケーションの初期化に完全に失敗したりする可能性があることに注意してください。
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}
[OSEv3:vars]
openshift_management_app_template=cfme-template
openshift_management_template_parameters={'APPLICATION_MEM_REQ': '3000Mi', 'POSTGRESQL_MEM_REQ': '1Gi', 'ANSIBLE_MEM_REQ': '512Mi'}
この例では、インストーラーに対し、パラメーター APPLICATION_MEM_REQ を 3000Mi に、POSTGRESQL_MEM_REQ を 1Gi に、さらに ANSIBLE_MEM_REQ を 512Miに設定してアプリケーションテンプレートを処理するように指示します。
これらのパラメーターは、前述の例 PV サイズの上書きに示されているパラメーターと組み合せることができます。
5.4.2.5. 外部 PostgreSQL データベース
外部データベースを使用するには、openshift_management_app_template パラメーターの値を cfme-template-ext-db に変更する必要があります。
さらに、データベース接続情報を openshift_management_template_parameters 変数を使って入力する必要があります。詳細は、「ロール変数の設定」を参照してください。
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}
[OSEv3:vars]
openshift_management_app_template=cfme-template-ext-db
openshift_management_template_parameters={'DATABASE_USER': 'root', 'DATABASE_PASSWORD': 'mypassword', 'DATABASE_IP': '10.10.10.10', 'DATABASE_PORT': '5432', 'DATABASE_NAME': 'cfme'}PostgreSQL 9.5 が実行中であることを確認してください。実行されていないと、アプリケーションを正常にデプロイできない場合があります。
5.5. コンテナープロバイダー統合の有効化
5.5.1. 単一コンテナープロバイダーの追加
「インストーラーの実行」で説明されているように Red Hat CloudForms を OpenShift Container Platform にデプロイした後にコンテナープロバイダーの統合を有効にする方法として 、OpenShift Container Platform をコンテナープロバイダーとして手動で追加する方法と、このロールに含まれている Playbook を試行する方法の 2 つの方法があります。
5.5.1.1. 手動の追加
OpenShift Container Platform クラスターをコンテナープロバイダーとして手動で追加する手順については、以下の Red Hat CloudForms ドキュメントを参照してください。
5.5.1.2. 自動の追加
コンテナープロバイダーの自動的な統合は、このロールに含まれている Playbook を使用して実行できます。
この Playbook は以下を実行します。
- 必要な認証シークレットを収集します。
- Red Hat CloudForms アプリケーションとクラスター API への公開ルートを検索します。
- REST の呼び出しを実行し、OpenShift Container Platform クラスターをコンテナープロバイダーとして追加します。
コンテナープロバイダーの Playbook を実行するには、以下を実行します。
ansible-playbook -v [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/add_container_provider.yml
# ansible-playbook -v [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/add_container_provider.yml5.5.2. 複数のコンテナープロバイダー
このロールには、最新の OpenShift Container Platform クラスターを Red Hat CloudForms デプロイメントに統合するための Playbook に加え、複数のコンテナープラットフォームを任意の Red Hat CloudForms サーバーに コンテナープロバイダーとして追加することを可能にするスクリプトが含まれています。コンテナープラットフォームは、OpenShift Container Platform または OpenShift Origin です。
複数のプロバイダースクリプトを使用する場合、Playbook の実行時に EXTRA_VARS パラメーターを CLI に手動で設定することが必要になります。
5.5.2.1. スクリプトの作成
複数のプロバイダースクリプトを作成するには、以下の手動の設定を実行します。
- /usr/share/ansible/openshift-ansible/roles/openshift_management/files/examples/container_providers.yml のサンプルを、/tmp/cp.yml など別の場所にコピーします。このファイルは後で変更します。
-
Red Hat CloudForms の名前またはパスワードを変更している場合は、コピーしたcontainer_providers.yml ファイルの
management_serverキーにあるhostname、user、passwordの各パラメーターを更新します。 コンテナープロバイダーとして追加する必要のある各 Container Platform クラスターについて、
container_providersキーの下にエントリーを入力します。以下のパラメーターを設定する必要があります。
-
auth_key-cluster-admin権限を持つサービスアカウントのトークンです。 -
hostname- クラスター API をポイントしているホスト名です。各コンテナープロバイダーは固有のホスト名を持っている必要があります。 -
name- Red Hat CloudForms サーバーのコンテナープロバイダーの概要ページに表示されるクラスター名です。この名前は固有でなければなりません。
ヒントauth_keyベアラートークンをクラスターから取得するには、以下を実行します。oc serviceaccounts get-token -n management-infra management-admin
$ oc serviceaccounts get-token -n management-infra management-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
以下のパラメーターは任意で設定することができます。
-
port- Container Platform クラスターが API を8443以外のポートで実行している場合は、このキーを更新します。 -
endpoint- SSL 検証を有効にする (verify_ssl) か、または検証設定をssl-with-validationに変更することができます。現時点では、カスタムの信頼される CA 証明書のサポートは利用できません。
-
5.5.2.1.1. 例
例として以下のシナリオを見てみましょう。
- container_providers.yml ファイルを /tmp/cp.yml にコピーしている。
- 2 つの OpenShift Container Platform クラスターを追加する必要がある。
-
Red Hat CloudForms サーバーが
mgmt.example.comで実行されている。
このシナリオでは、/tmp/cp.yml を以下のようにカスタマイズします。
5.5.2.2. Playbook の実行
複数プロバイダー統合スクリプトを実行するには、コンテナープロバイダーの設定ファイルへのパスを EXTRA_VARS パラメーターとしてansible-playbook コマンドに指定する必要があります。container_providers_config を設定ファイルパスに設定するには、-e (または --extra-vars) パラメーターを使用します。
ansible-playbook -v [-i /path/to/inventory] \
-e container_providers_config=/tmp/cp.yml \
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/add_many_container_providers.yml
# ansible-playbook -v [-i /path/to/inventory] \
-e container_providers_config=/tmp/cp.yml \
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/add_many_container_providers.yml
Playbook が完成すると、Red Hat CloudForms サービスに 2 つの新しいコンテナープロバイダーが見つかるはずです。コンピュート → コンテナー → プロバイダー の順にページを進んで概要を確認してください。
5.5.3. プロバイダーの更新
単一または複数のコンテナープロバイダーを追加したら、新規プロバイダーを Red Hat CloudForms で更新し、コンテナープロバイダーと管理されているコンテナーに関する最新データをすべて取得する必要があります。そのためには、Red Hat CloudForms Web コンソールの各プロバイダーに進み、それぞれについて更新ボタンをクリックします。
手順については、以下の Red Hat CloudForms ドキュメントを参照してください。
5.6. Red Hat CloudForms のアンインストール
5.6.1. アンインストール Playbook の実行
Red Hat CloudForms をアンインストールする前に、クラスターを OpenShift Container Platform バージョン 3.9.16 以上にアップグレードする必要があります。それよりも前のバージョンを使用している場合、Red Hat CloudForms のアンインストールにより、クラスターのすべての PV が除去されます。
デプロイした Red Hat CloudForms インストールを OpenShift Container Platform からアンインストールして削除するには、以下の Playbook を実行します。
ansible-playbook -v [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/uninstall.yml
# ansible-playbook -v [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-management/uninstall.ymlNFS エクスポートの定義とNFS エクスポートに格納されているデータは自動的に削除されません。新規デプロイメントの初期化を試行する前に、古いアプリケーションまたはデータベースデプロイメントのデータを手動で消去することが推奨されます。
5.6.2. トラブルシューティング
古い PostgreSQL データの消去に失敗すると連鎖的なエラーが発生し、postgresql Pod が crashloopbackoff の状態になる可能性があります。この状態になると cfme Pod の起動が阻止されます。crashloopbackoff は、以前のデプロイ時に作成されたデータベース NFS エクスポートの不正なファイル権限に起因します。
次に進むには、PostgreSQL エクスポートからすべてのデータを削除し、Pod (デプロイヤー Pod ではない) を削除します。以下の Pod がある場合の例を示します。
この場合、以下を実行します。
- データベース NFS エクスポートのデータを消去します。
以下を実行します。
oc delete postgresql-1-6w2t4
$ oc delete postgresql-1-6w2t4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
PostgreSQL デプロイヤー Pod は、削除した Pod を置き換えるために新規の postgresql Pod の拡張を試みます。 postgresql Pod が実行された後に、cfme Pod は阻止する操作を停止し、アプリケーションの初期化を開始します。
第6章 マスターとノードの設定
openshift start コマンドとそのサブコマンド (マスターサーバーを起動する master と ノードサーバーを起動する node ) が受け取る引数のセット数は限定的ですが、これらは開発または実験環境でサーバーを起動するのには十分です。
ただしこれらの引数は、実稼働環境に必要な設定およびセキュリティーオプションのセットを詳細に記述し、管理するには不十分です。これらのオプションを指定するには、マスターとノードの設定ファイルを使用することが必要になります。
- マスターホストファイル (場所: /etc/origin/master/master-config.yaml)
- ノードホストファイル (場所: /etc/origin/node/node-config.yaml)
上記のファイルは、デフォルトプラグインの上書き、etcd への接続、サービスアカウントの自動作成、イメージ名の作成、プロジェクト要求のカスタマイズ、ボリュームプラグインの設定などの各種オプションを定義します。
このトピックでは、OpenShift Container Platform のマスターとノードのホストのカスタマイズに使用できるオプションについて説明し、インストール後に設定を変更する方法を紹介します。
これらのファイルはデフォルト値なしで完全に指定されます。したがって、空の値は、ユーザーがそのパラメーターを空の値で起動しようとしていることを意味します。これによりユーザーの設定を正確に推測することを簡単になりますが、指定する必要のあるすべてのオプションを思い出す必要があるという点では容易な作業にはなりません。これをより容易にするには、設定ファイルを --write-config オプションを使って作成し、次に --config オプションを指定して使用することができます。
6.1. インストールの依存関係
クイックインストールツールを使ってデプロイしたテスト環境では、マスターは 1 つあれば十分です。クイックインストール方式は実稼働環境では使用することができません。
実稼働環境は 通常インストール (Advanced installation) を使用してインストールする必要があります。実稼働環境では、高可用性 (HA) を維持するために複数のマスターを使用するのがよいでしょう。3 つのマスターで構成されるクラスターアーキテクチャーが推奨され、HAproxy の使用が推奨されるソリューションになります。
etcd が マスターホストにインストールされている場合は、etcd は権限を持つマスターを判別できないために、クラスターを 3 つ以上のマスターを使用するように設定する必要があります。2 つのマスターのみを正常に実行できるのは、etcd をマスター以外のホストにインストールしている場合です。
6.2. マスターとノードの設定
マスターとノードの設定ファイルの設定に使用する方法は、OpenShift Container Platform クラスターのインストールに使用した方法と同じでなければなりません。
- Ansible を使った通常インストール (Advanced installation) 方式を使用した場合は、Ansible Playbook で設定の変更を行ってください。
- クイックインストール方式を使用した場合は、それらの変更を設定ファイルで手動で実行してください。
6.3. Ansible を使用した設定の変更
このセクションは、Ansible に精通していることを前提に説明を行います。
Ansible に公開されているのは、利用可能なホスト設定オプションの一部のみです。OpenShift Container Platform のインストール後、Ansible は インベントリーファイルを置き換えられた値で作成します。このインベントリーファイルを変更し、Ansible インストーラー Playbook を再実行することで、OpenShift Container Platform クラスターをカスタマイズできます。
OpenShift Container Platform は Ansible を通常インストール (Advanced installation) 方式として使用することに対応していますが、Ansible Playbook とインベントリーファイルを使うことで、Puppet、Chef、Salt などの他の管理ツールを使用することもできます。
ユースケース: HTPasswd 認証を使用するようにクラスターを設定する
- このユースケースは、Playbook で参照されているすべてのノードに SSH キー がセットアップされていることを前提としています。
htpasswdユーティリティーはhttpd-toolsパッケージにあります。yum install httpd-tools
# yum install httpd-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Ansible インベントリーを変更し、設定の変更を行うには、以下を実行します。
./hosts インベントリーファイルを開きます。
例6.1 インベントリーファイルのサンプル:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規の変数をファイルの
[OSEv3:vars]セクションに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow HTPasswd 認証では、指定されたユーザーとパスワードを作成する
openshift_master_htpasswd_users変数か、またはすでに作成済みのユーザーとパスワードを持つ事前生成されたフラットファイル (htpasswd ファイル) を指定するopenshift_master_htpasswd_file変数のいずれかを使用できます。OpenShift Container Platform は、HTPasswd 認証を設定するためにハッシュ化されたパスワードを必要とします。以下のセクションに示されるように
htpasswdコマンドを使用してユーザー用のハッシュ化されたパスワードを生成するか、またはユーザーおよび関連付けられたハッシュ化されたパスワードを持つフラットファイルを作成することができます。以下の例では、認証方法をデフォルトの
deny all設定からhtpasswdに変更し、指定されたファイルを使ってjsmithおよびbloblawユーザーのユーザー ID とパスワードを生成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 変更を有効にするために、Ansible Playbook を再実行します。
ansible-playbook -b -i ./hosts ~/src/openshift-ansible/playbooks/deploy_cluster.yml
$ ansible-playbook -b -i ./hosts ~/src/openshift-ansible/playbooks/deploy_cluster.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Playbook が設定を更新し、OpenShift Container Platform マスターサービスを再起動して変更を適用します。
これで、Ansible を使用したマスターとノードの設定ファイルの変更が完了しました。ここまでは単純なユースケースですが、次は、どのマスターとノードの設定オプションが Ansibleに公開されているかを確認し、各自の Ansible インベントリーをカスタマイズします。
6.3.1. htpasswd コマンドの使用
OpenShift Container Platform クラスターを HTPasswd 認証を使用するように設定するには、ハッシュ化されたパスワードを持つ 1 名以上のユーザーをインベントリーファイルに追加する必要があります。
以下を実行することができます。
- ユーザー名とパスワードを生成して ./hosts インベントリーファイルに直接追加する。
- フラットファイルを作成して認証情報を ./hosts インベントリーファイルに渡す。
ユーザーおよびハッシュ化されたパスワードを作成するには、以下を実行します。
以下のコマンドを実行して指定されたユーザーを追加します。
htpasswd -n <user_name>
$ htpasswd -n <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記-bオプションを追加すると、パスワードをコマンドラインに指定できます。htpasswd -nb <user_name> <password>
$ htpasswd -nb <user_name> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザーのクリアテキストのパスワードを入力し、確定します。
例を以下に示します。
htpasswd -n myuser
$ htpasswd -n myuser New password: Re-type new password: myuser:$apr1$vdW.cI3j$WSKIOzUPs6QCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドはパスワードのハッシュ化バージョンを生成します。
これで、HTPasswd 認証を設定する際にハッシュ化パスワードを使用できます。ハッシュ化パスワードは、: の後に続く文字列です。上記の例では、次を入力します。
openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}
openshift_master_htpasswd_users={'myuser': '$apr1$wIwXkFLI$bAygtISk2eKGmqaJftB'}ユーザー名とハッシュ化パスワードを持つフラットファイルを作成するには、以下を実行します。
以下のコマンドを実行します。
htpasswd -c </path/to/users.htpasswd> <user_name>
$ htpasswd -c </path/to/users.htpasswd> <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記-bオプションを追加すると、パスワードをコマンドラインに指定できます。htpasswd -c -b <user_name> <password>
$ htpasswd -c -b <user_name> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザーのクリアテキストのパスワードを入力し、確定します。
例を以下に示します。
htpasswd -c users.htpasswd user1 New password: Re-type new password: Adding password for user user1
htpasswd -c users.htpasswd user1 New password: Re-type new password: Adding password for user user1Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、ユーザー名とユーザーパスワードのハッシュ化されたバージョンを含むファイルを生成します。
これで、HTPasswd 認証を設定する際にこのパスワードファイルを使用できます。
htpasswd コマンドについての詳細は、「HTPasswd Identity Provider」を参照してください。
6.4. 手動による設定変更
クイックインストールツールを使って OpenShift Container Platform をインストールすると、マスターとノードの設定ファイルを変更してクラスターをカスタマイズすることができます。
ユースケース: HTPasswd 認証を使用するようにクラスターを設定する
設定ファイルを手動で変更するには、以下を実行します。
- 変更する必要のある設定ファイルを開きます。ここでは /etc/origin/master/master-config.yaml ファイルです。
以下の新規変数をファイルの
identityProvidersスタンザに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 変更を保存してファイルを閉じます。
変更を有効にするために、マスターを再起動します。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
$ systemctl restart atomic-openshift-master-api atomic-openshift-master-controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これでマスターとノードの設定ファイルが手動で変更されました。ここまでは単純なユースケースです。次は、すべてのマスターとノードの設定オプションを確認し、変更を加えることでクラスターをさらにカスタマイズします。
6.5. マスター設定ファイル
このセクションでは、master-config.yaml ファイルに記述されているパラメーターについて説明します。
新規のマスター設定ファイルを作成して、OpenShift Container Platform のインストール済みバージョンに有効なオプションを確認できます。
master-config.yaml ファイルを変更する際には常にマスターを再起動して変更を有効にしてください。「OpenShift Container Platform サービスの再起動」を参照してください。
6.5.1. 受付制御の設定
| パラメーター名 | 説明 |
|---|---|
|
|
受付制御プラグイン設定が含まれています。OpenShift Container Platform には、API オブジェクトが作成または変更されるたびにトリガーされる、受付制御プラグインの設定可能な一覧が含まれます。このオプションを使用して、一部のプラグインの無効化、他の設定の追加、順序の変更や設定の指定など、デフォルトのプラグイン一覧を上書きできます。プラグインの一覧とその設定はどちらも Ansible で制御することができます。 |
|
|
API サーバーのコマンドライン引数に一致する Kube API サーバーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、 apiServerArguments: event-ttl: - "15m" |
|
|
Kube コントローラーマネージャーのコマンドライン引数に一致する、コントローラーマネージャーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、 |
|
|
各種の受付プラグインの有効化または無効化に使用されます。このタイプが |
|
|
設定ファイルを受付制御プラグインごとに指定することができます。 |
|
|
マスターにインストールされる受付制御プラグイン名の一覧です。順序には意味があります。空の場合は、プラグインのデフォルトの一覧が使用されます。 |
|
|
スケジューラーのコマンドライン引数に一致する、Kube スケジューラーに直接渡されるキーと値のペアです。これらは移行されませんが、存在しない値が参照されてもサーバーは起動しません。これらの値は、 |
6.5.2. アセットの設定
| パラメーター名 | 説明 |
|---|---|
|
|
これが存在する場合には、アセットサーバーは事前に定義されたパラメーターに基づいて起動します。以下は例になります。 |
|
|
異なるホスト名を使用して Web アプリケーションから API サーバーにアクセスするには、設定フィールドに |
|
|
起動することのできない機能の一覧です。null に設定してください。この機能を手動で無効にする必要性はほとんどなく、この操作を実行することも推奨されません。 |
|
|
サブコンテクストの下位のアセットサーバーファイルシステムから提供されるファイルです。 |
|
|
true に設定されている場合、起動時だけでなく要求が出されるたびに拡張機能スクリプトとスタイルシートをリロードするようアセットサーバーに指示します。変更のたびにサーバーを再起動しなくても、拡張機能を展開することができます。 |
|
|
コンソールのグローバル変数 |
|
|
Web コンソールが読み込む際にスクリプトとして読み込まれるアセットサーバーファイル上のファイルパスです。 |
|
|
Web コンソールが読み込む際にスタイルシートとして読み込まれるアセットサーバーファイル上のファイルパスです。 |
|
|
ロギング用のパブリックエンドポイント (オプション) です。 |
|
|
Web コンソールからログアウトした後に Web ブラウザーをリダイレクトするオプションの絶対 URL です。指定されていない場合は、ビルトインされたログアウトページが表示されます。 |
|
|
Web コンソールが OpenShift Container Platform サーバーにアクセスする方法について示します。 |
|
|
メトリクス用のパブリックエンドポイント (オプション) です。 |
|
|
アセットサーバーの URL です。 |
6.5.3. 認証と承認の設定
| パラメーター名 | 説明 |
|---|---|
|
|
認証および承認設定オプションを保持します。 |
|
|
キャッシュされる認証結果の数を示します。0 の場合は、デフォルトのキャッシュサイズが使用されます。 |
|
|
承認結果がキャッシュされる期間を示します。有効な時間文字列 (「5 m」など) を取り、空の場合はデフォルトのタイムアウトが取得されます。ゼロ (「0 m」など) の場合、キャッシシングは無効になります。 |
6.5.4. コントローラーの設定
| パラメーター名 | 説明 |
|---|---|
|
|
起動するコントローラーの一覧です。none に設定されている場合、コントローラーは自動的に起動されません。デフォルト値は * であり、これによりすべてのコントローラーが起動します。* を使用している場合は、コントローラーの名前の先頭に |
|
|
コントローラーの選択を有効にし、マスターに対してコントローラーが起動する前にリースを取得するように指示して、この値で定義された秒数内にリースを更新します。負の値以外の値を設定することで |
|
|
マスターに対してコントローラーを自動的に開始せず、起動前にサーバーへの通知が受信するまで待機するように指示します。 |
6.5.5. etcd の設定
| パラメーター名 | 説明 |
|---|---|
|
|
etcd へのクライアント接続用に公開される host:port です。 |
|
|
etcd に接続する方法についての情報が含まれます。etcd を組み込みまたは組み込み以外の方法で実行するかどうかを指定し、ホストを指定します。残りの設定は Ansible インベントリーで処理されます。以下は例になります。 |
|
|
これがある場合、etcd は定義されたパラメーターに基づいて起動します。以下は例になります。 |
|
|
API リソースを etcd に格納する方法についての情報が含まれます。これらの値は、etcd がクラスターのバッキングストアである場合にのみ関連する値になります。 |
|
|
Kubernetes のリソースがその下位に置かれる etcd 内のパスです。この値が変更されると etcd 内の既存のオブジェクトは検索できなくなります。デフォルトの値は kubernetes.io です。 |
|
|
etcd 内の Kubernetes リソースがシリアライズされる API バージョン。etcd から読み取りを行うクラスター内のすべてのクライアントが新規バージョンの読み取りを可能にするコードを取得するまでこの値を変更 することができません。 |
|
|
OpenShift Container Platform リソースがその下位に置かれる etcd 内のパスです。この値が変更されると、etcd 内の既存のオブジェクトは検索できなくなります。デフォルトの値は openshift.io です。 |
|
|
etcd 内の OS リソースがシリアライズされる API バージョンです。etcd から読み取りを行うクラスター内のすべてのクライアントが新規バージョンの読み取りを可能にするコードを取得するまで、この値を変更することができません。 |
|
|
etcd へのピア接続用に公開される host:port です。 |
|
|
etcd ピアの提供を開始する方法を記述します。 |
|
|
提供を開始する方法を記述します。以下は例になります。 |
|
|
etcd ストレージディレクトリーへのパスです。 |
6.5.6. 付与の設定
| パラメーター名 | 説明 |
|---|---|
|
|
付与を処理する方法を記述します。 |
|
|
クライアントの承認付与の要求を自動承認します。 |
|
|
クライアントの承認付与の要求を自動的に拒否します。 |
|
|
ユーザーに対し、クライアントの新規の承認付与要求を承認することを求めるプロンプトを出します。 |
|
|
OAuth クライアントが付与を要求したときに使用するデフォルトのストラテジーを決定します。この方法は特定の OAuth クライアントが独自のストラテジーを提供しない場合にのみ使用します。付与を処理するための有効な方法は以下の通りです。
|
6.5.7. イメージ設定
| パラメーター名 | 説明 |
|---|---|
|
|
システムコンポーネント用に作成される名前のフォーマットです。 |
|
|
最新のタグをレジストリーからプルするかどうかを決定します。 |
6.5.8. イメージポリシーの設定
| パラメーター名 | 説明 |
|---|---|
|
|
スケジュールされたイメージのバックグラウンドインポートの無効化を許可します。 |
|
|
ユーザーが Docker リポジトリーの一括インポートを行う際に、インポートされるイメージの数を制御します。デフォルトの値は 5 に設定され、ユーザーが誤って大量のイメージをインポートすることを防ぎます。-1 に設定すると無制限になります |
|
|
スケジュールされたイメージストリームがバックグラウンドでインポートされる 1 分あたりの最大数です。デフォルト値は 60 です。 |
|
|
バックグラウンドのインポートがスケジュールされているイメージストリームが、アップストリームのリポジトリーと照合される際の最小間隔 (秒単位) です。デフォルト値は 15 秒です。 |
|
|
標準ユーザーがイメージのインポートに使用する Docker レジストリーを制限します。この一覧を、有効な Docker イメージを含むものとユーザーが信頼し、アプリケーションのインポート元となるレジストリーに設定します。Images または ImageStreamMappings を API 経由で作成するパーミッションを持つユーザーは、このポリシーによる影響を受けません。通常、これらのパーミッションを持っているのは管理者またはシステム統合管理者のみです。 |
|
|
デフォルトの内部イメージレジストリーのホスト名を設定します。値は |
|
|
ExternalRegistryHostname は、デフォルトの外部イメージレジストリーのホスト名を設定します。この外部ホスト名は、イメージレジストリーが外部に公開される場合にのみ設定されます。値は ImageStreams の |
6.5.9. Kubernetes のマスター設定
| パラメーター名 | 説明 |
|---|---|
|
|
起動時に有効にする必要のある API レベルの一覧です (v1 など)。 |
|
|
無効にする必要のあるバージョン (または |
|
|
Kubelets に接続する方法についての情報が含まれます。 |
|
|
kubelet の KubernetesMasterConfig への接続方法についての情報が含まれます。これがある場合、Kubernetes のマスターをこのプロセスで起動します。 |
|
|
実行されていることが予想されるマスターの数です。デフォルトの値は 1 であり、正の整数に設定できますが、-1 に設定されている場合はそれがクラスターの一部であることを示します。 |
|
|
Kubernetes リソースのパブリック IP アドレスです。空の場合、 |
|
|
このノードをマスターに接続する方法を記述した .kubeconfig ファイルのファイル名です。 |
|
|
サービスのパブリックポートをホストに割り当てる際に使用される範囲です。デフォルトは 30000-32767 です。 |
|
|
サービス IP の割り当てに使用されるサブネットです。 |
|
|
静的に認識されるノードの一覧です。 |
6.5.10. ネットワーク設定
IPv4 アドレス領域はノード上のすべてのユーザーが共有するため、CIDR を以下のパラメーターで慎重に選択してください。OpenShift Container Platform はそれ自体に使用する CIDR を IPv4 アドレス領域から予約し、外部ユーザーとクラスターが共有するアドレス用の CIDR を IPv4 アドレス領域から予約します。
| パラメーター名 | 説明 |
|---|---|
|
|
グローバルなオーバーレイネットワークの L3 領域を指定する CIDR 文字列です。クラスターネットワークの内部使用のために予約されています。 |
|
|
サービスの外部 IP フィールドで許可される値を制御します。空の場合、 |
|
|
各ホストのサブネットに割り当てられるビット数です。たとえば 8 の場合は、ホスト上の /24 ネットワークを意味します。 |
|
|
ベアメタル上のタイプ LoadBalancer のサービス用に ingress IP を割り当てる範囲を制御します。そこから割り当てられる単一の CIDR を含めることができます。デフォルトは |
|
|
各ホストのサブネットに割り当てられるビット数です。たとえば 8 の場合は、ホスト上の /24 ネットワークを意味します。 |
|
|
compiled-in-network プラグインに渡されます。ここでのオプションの多くは Ansible インベントリーで制御されます。
以下は例になります。 |
|
|
使用されるネットワークプラグインの名前です。 |
|
|
サービスネットワークを指定する CIDR 文字列です。 |
6.5.11. OAuth 認証設定
| パラメーター名 | 説明 |
|---|---|
|
|
単一プロバイダーしかない場合でも、プロバイダーの選択ページを強制的にレンダリングします。 |
|
|
外部アクセス用の有効なクライアントのリダイレクト URL の作成に使用されます。 |
|
|
認証または付与フローでエラーページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定しない場合、デフォルトのエラーページが使用されます。 |
|
|
ユーザーが自身を確認する方法の順序付きの一覧です。 |
|
|
ログインページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定しない場合、デフォルトのログインページが使用されます。 |
|
|
TLS 接続が |
|
|
外部アクセス用の有効なクライアントのリダイレクト URL の作成に使用されます。 |
|
|
アクセストークンの承認コードを交換するためのサーバー間の呼び出しに使用されます。 |
|
|
これがある場合、/oauth エンドポイントは定義されたパラメーターに基づいて開始します。以下は例になります。 |
|
|
ログインページなどページのカスタマイズを許可します。 |
|
|
プロバイダーの選択ページのレンダリングに使用される Go テンプレートを含むファイルへのパスです。指定されていない場合、デフォルトのプロバイダー選択ページが使用されます。 |
|
|
セッションの設定に関する情報を保持します。 |
|
|
ログインページなどのページのカスタマイズを許可します。 |
|
|
承認とアクセストークンのオプションが含まれます。 |
6.5.12. プロジェクトの設定
| パラメーター名 | 説明 |
|---|---|
|
|
デフォルトのプロジェクトノードのラベルセレクターを保持します。 |
|
|
プロジェクト作成とデフォルトに関する情報を保持します。
|
|
|
この文字列は、プロジェクトの要求 API エンドポイントからプロジェクトを要求できない場合にユーザーに提示されます。 |
|
|
projectrequest への応答としてプロジェクトを作成する際に使用されるテンプレートです。フォーマットは namespace/template です。これはオプションであり、指定されていない場合はデフォルトのテンプレートが使用されます。 |
6.5.13. スケジューラーの設定
| パラメーター名 | 説明 |
|---|---|
|
|
スケジューラーのセットアップ方法を記述しているファイルをポイントします。空の場合、デフォルトのスケジューリングルールが取得されます。 |
6.5.14. セキュリティーアロケーターの設定
| パラメーター名 | 説明 |
|---|---|
|
|
namespace に割り当てられる MCS カテゴリーの範囲を定義します。フォーマットは |
|
|
UID と MCS ラベルのプロジェクトへの自動割り当てを制御します。空の場合、割り当ては無効にされます。 |
|
|
プロジェクトに自動的に割り当てられる Unix ユーザー ID (UID) の合計セット数と、各 namespace が取得するブロックのサイズを定義します。たとえば、1000-1999/10 は namespace ごとに 10 の UID を割り当て、空間を使い果たす前に最大 100 のブロックを割り当てることが可能です。デフォルトでは、1 万のブロックに 10 億から 20 億 (ユーザー namespace の起動時にコンテナーイメージが使用する範囲の予想されるサイズ) を割り当てます。 |
6.5.15. サービスアカウントの設定
| パラメーター名 | 説明 |
|---|---|
|
|
サービスアカウントに、明示的な参照なしに namespace のシークレットの参照を許可するかどうかを制御します。 |
|
|
すべての namespace に自動作成されるサービスアカウント名の一覧です。名前が指定されていない場合、 |
|
|
TLS 接続がマスターに戻っていることを確認する CA です。サービスアカウントのコントローラーは、マスターへの接続を検証できるようにこのファイルの内容を Pod に自動的に挿入します。 |
|
|
PEM でエンコードされた RSA プライベートキーを含むファイルです。これはサービスアカウントのトークンの署名に使用されます。プライベートキーが指定されていない場合、サービスアカウント |
|
|
PEM でエンコードされた RSA パブリックキーを含むファイルの一覧です。いずれかのファイルにプライベートキーが含まれている場合、そのキーのパブリックの部分が使用されます。パブリックキーの一覧は、表示されているサービスアカウントのトークンの確認に使用されます。それぞれのキーは、一覧がすべて使用されるまで、または確認が正常に実行されるまで順番に試行されます。キーが指定されていない場合、サービスアカウントの認証は使用できません。 |
|
|
サービスアカウントに関連するオプションを保持します。
|
6.5.16. 提供情報の設定
| パラメーター名 | 説明 |
|---|---|
|
|
マスター上の DNS サーバーがクエリーに再帰的に応答することを許可します。オープンリゾルバーは DNS アンプ攻撃に使用される可能であり、マスター DNS は公開ネットワークでアクセスできないようにする必要があることに注意してください。 |
|
|
提供に使用される ip:port です。 |
|
|
イメージをインポートするための制限と動作を制御します。 |
|
|
PEM でエンコードされた証明書を含むファイルです。 |
|
|
セキュアなトラフィックを提供するための TLS 証明書情報です。 |
|
|
クライアント証明書が受信される際にユーザーが認識するすべての署名者の証明書バンドルです。 |
|
|
これがある場合、DNS サーバーが定義されたパラメーターに基づいて起動します。以下は例になります。 dnsConfig: bindAddress: 0.0.0.0:8053 bindNetwork: tcp4 |
|
|
ドメインサフィックスを保持します。 |
|
|
IP を保持します。 |
|
|
|
|
|
マスターへの接続に使用されたクライアント接続を上書きします。 |
|
|
サーバーに許可されている同時要求数です。ゼロの場合は無制限です。 |
|
|
特定のホスト名への要求を保護するのに使用される証明書の一覧です。 |
|
|
要求がタイムアウトするまでの秒数です。デフォルトは 60 分です。-1 の場合、要求について無制限となります。 |
|
|
アセット用の HTTP 提供情報です。 |
6.5.17. ボリュームの設定
| パラメーター名 | 説明 |
|---|---|
|
|
動的なプロビジョニングを有効化または無効化するブール値です。デフォルトは true です。 |
|
FSGroup |
固有の FSGroup ID ごとにローカルストレージの使用量のクォータを有効にするために指定できます。現時点では、これは emptyDir ボリュームのみに、基礎となる |
|
|
ノードのローカルボリュームのクォータを制御するオプションが含まれます。 |
|
|
マスターノードのボリュームプラグインを設定するオプションが含まれます。 |
|
|
ノードのボリュームを設定するオプションが含まれます。 |
|
|
ノードのボリュームプラグインを設定するオプションが含まれます。
|
|
|
ボリュームがその下に保存されるディレクトリーです。 |
6.5.18. 基本的な監査
監査は、システムに影響を与えた一連のアクティビティーを個別のユーザー、管理者その他システムのコンポーネント別に記述したセキュリティー関連の時系列のレコードを提供します。
監査は API サーバーレベルで実行され、サーバーに送られるすべての要求をログに記録します。それぞれの監査ログには以下の 2 つのエントリーが含まれます。
以下を含む要求行。
- 応答行 (以下の 2 を参照してください) と一致する固有 ID
- 要求のソース IP
- 呼び出されている HTTP メソッド
- 操作を呼び出している元のユーザー
-
操作を実行するための偽装ユーザー (
selfはユーザー自身を指します) -
操作を実行するための偽装グループ (
lookupはユーザーのグループを指します) - 要求または <none> の namespace
- 要求される URI
以下を含む応答行。
- 上記 1 の固有の ID
- 応答コード
Pod の一覧を要求するユーザー admin の出力例。
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods" AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" ip="127.0.0.1" method="GET" user="admin" as="<self>" asgroups="<lookup>" namespace="default" uri="/api/v1/namespaces/default/pods"
AUDIT: id="5c3b8227-4af9-4322-8a71-542231c3887b" response="200"
openshift_master_audit_config 変数は、API サービス監査を有効にします。これは以下のオプションの配列を取ります。
| パラメーター名 | 説明 |
|---|---|
|
|
監査ログを有効または無効にするブール値です。デフォルト値は |
|
|
要求をログに記録するファイルパスです。設定されていない場合、ログはマスターログに出力されます。 |
|
|
ファイル名にエンコードされるタイムスタンプに基づいて古い監査ログファイルを保持する最大日数を指定します。 |
|
|
古い監査ログファイルを保持する最大数を指定します。 |
|
|
ログファイルがローテーションされる前に、ファイルの最大サイズをメガバイトで指定します。デフォルトは 100 MB です。 |
監査の設定例
監査ログの高度なセットアップ
監査ログの高度なセットアップを使用する必要がある場合には、以下を使用できます。
openshift_master_audit_config={"enabled": true}
openshift_master_audit_config={"enabled": true}
auditFilePath のディレクトリーが、存在していない場合に作成されます。
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/openpaas-oscp-audit/openpaas-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5}
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/openpaas-oscp-audit/openpaas-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5}6.5.19. 高度な監査
高度な監査機能は、詳細なイベントのフィルタリングや複数の出力バックエンドなど、基本的な監査機能に対するいくつかの改良機能を提供します。
高度な監査機能を有効にするには、以下の値を openshift_master_audit_config パラメーターに指定します。
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/oscp-audit/-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5, "policyFile": "/etc/security/adv-audit.yaml", "logFormat":"json"}
openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/log/oscp-audit/-oscp-audit.log", "maximumFileRetentionDays": 14, "maximumFileSizeMegabytes": 500, "maximumRetainedFiles": 5, "policyFile": "/etc/security/adv-audit.yaml", "logFormat":"json"}ポリシーファイル /etc/security/adv-audit.yaml は各マスターノードで利用可能でなければなりません。
以下の表には、使用できる追加のオプションが含まれています。
| パラメーター名 | 説明 |
|---|---|
|
|
監査ポリシー設定を定義するファイルへのパスです。 |
|
|
組み込まれる監査ポリシー設定です。 |
|
|
保存される監査ログのフォーマットを指定します。許可されている値は |
|
|
監査の Webhook 設定を定義する |
|
|
監査イベントを送信するためのストラテジーを指定します。許可される値は |
高度な監査機能を有効にするには、監査ポリシールールを記述する policyFile または policyConfiguration を指定する必要があります。
監査ポリシーの設定例
- 1 8
- すべてのイベントは以下の 4 つのレベルでログに記録できます。
-
None- このルールに一致するイベントは記録されません。 -
Metadata- 要求のメタデータ (要求しているユーザー、タイムスタンプ、リソース、verb など) をログに記録します。要求または応答本体はログに記録しません。基本的な監査で使用されるレベルと同じレベルになります。 -
Request- イベントのメタデータと要求本体をログに記録します。応答本体はログに記録しません。 -
RequestResponse- イベントのメタデータ、要求、および応答本体をログに記録します。
-
- 2
- このルールが適用されるユーザーの一覧です。一覧が空の場合はすべてのユーザーに適用されます。
- 3
- このルールが適用される verb の一覧です。一覧が空の場合はすべての verb に適用されます。これは API 要求に関連付けられる Kubernetes の verb です (
get、list、watch、create、update、patch、delete、deletecollection、proxyなど)。 - 4
- このルールが適用されるリソースの一覧です。一覧が空の場合はすべてのリソースに適用されます。各リソースは、それが割り当てられるグループ (例: 空の場合は Kubernetes core API、バッチ、build.openshift.io などを指します) 、およびそのグループのリソース一覧として指定されます。
- 5
- このルールが適用されるグループの一覧です。一覧が空の場合はすべてのグループに適用されます。
- 6
- このルールが適用されるリソース以外の URL の一覧です。
- 7
- このルールが適用される namespace の一覧です。一覧が空の場合はすべての namespace に適用されます。
- 9
- Web コンソールが使用するエンドポイントです。
- 10
- CLI が使用するエンドポイントです。
高度な監査についての詳細は、Kubernetes のドキュメントを参照してください。
6.5.20. etcd の TLS 暗号の指定
マスターと etcd サーバー間の通信で使用するサポートされている TLS 暗号を指定できます。
各 etcd ノードで、etcd をアップグレードします。
yum update etcd iptables-services
# yum update etcd iptables-servicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow お使いのバージョンが 3.2.22 以降であることを確認します。
etcd --version
# etcd --version etcd Version: 3.2.22Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各マスターホストで、
/etc/origin/master/master-config.yamlファイルで有効にする暗号を指定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各マスターホストで、マスターサービスを再起動します。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 暗号が適用されていることを確認します。たとえば、TLSv1.2 暗号
ECDHE-RSA-AES128-GCM-SHA256については、以下のコマンドを実行します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
etcd1.example.comは etcd ホストの名前です。
6.6. ノード設定ファイル
以下の node-config.yaml ファイルは、現時点でデフォルト値で生成されるノード設定ファイルのサンプルです。ユーザーは新規ノード設定ファイルを作成し、OpenShift Container Platform のインストール済みバージョンの有効なオプションを表示できます。
例6.2 ノード設定ファイルのサンプル
- 1
- ここにアドレスを追加することで、Pod の /etc/resolv.conf の先頭に追加される IP アドレスを設定します。
- 2
- 特定のノードセット上、またはすべてのノード上に、スケジューラーを介することなく Pod を直接配置することを許可します。ユーザーは、Pod を使って同じ管理タスクを実行し、各ノードで同じサービスをサポートすることができます。
- 3
- Pod のマニフェストファイルまたはディレクトリーへのパスを指定します。ディレクトリーの場合、1 つ以上のマニフェストファイルが含まれることが予想されます。これは、Pod をノード上に作成するために Kubelet によって使用されます。
- 4
- 新規データのマニフェストファイルをチェックする間隔 (秒単位) です。この値は正の値で入力する必要があります。
- 5
- 使用するサービスプロキシーの実装です。
- 6
- ローカルの emptyDir ボリュームのクォータの予備サポートです。この値を FSGroup ごと、ノードごとに必要なクォータを示すリソース量に設定します (1Gi、512Mi など)。現時点で、volumeDirectory は「gquota」オプションを指定してマウントされている、 XFS ファイルシステム上にある必要があり、一致する SCC (security context constraint) の fsGroup タイプは「MustRunAs」に設定する必要があります。
ノード設定ファイルはノードのリソースを決定します。詳細は、「Allocating node resources section in the Cluster Administrator guide」を参照してください。
6.6.1. Pod とノードの設定
| パラメーター名 | 説明 |
|---|---|
|
|
OpenShift Container Platform ノードを起動する完全に指定された設定です。 |
|
|
ノードは複数の IP を持つことがあるため、Pod のトラフィックルーティングに使用する IP を指定します。指定されていない場合、nodeName でネットワーク解析/ルックアップが実行され、最初の非ループバックアドレスが使用されます。 |
|
|
クラスターの特定ノードを識別するために使用される値です。可能な場合、この値はユーザーの完全修飾ホスト名にできます。ユーザーが静的ノードのセットをマスターに記述している場合、この値は一覧にある値のいずれかに一致している必要があります。 |
|
|
失敗したノード上の Pod を削除するための猶予期間を制御します。有効な時間文字列を取ります。空の場合、Pod のデフォルトのエビクションタイムアウトを取ります。 |
|
|
Pod へのプロキシー処理時に使用するクライアント証明書/キーを指定します。 |
6.6.2. Docker の設定
| パラメーター名 | 説明 |
|---|---|
|
|
true の場合、Kubelet は Docker のエラーを無視します。これは、Docker を起動させていないマシンでノードを起動できることを意味します。 |
|
|
Docker 関連の設定オプションを保持します。 |
|
|
Docker コンテナーでのコマンドの実行に使用するハンドラーです。 |
6.6.3. Docker 1.9 以降を使用したイメージの並行プル
Docker 1.9 以降を使用している場合は、イメージの並行プルを有効にしておくことができます。デフォルトでは、イメージは一度に 1 つずつプルされます。
Docker 1.9 よりも前のバージョンでは、データの破損による問題が発生する可能性があります。1.9 以降では破損の問題は解消し、並行プルに安全に切り替えることができます。
kubeletArguments: serialize-image-pulls: - "false"
kubeletArguments:
serialize-image-pulls:
- "false" - 1
- 並行プルを無効にするには true に変更します (デフォルトの設定)。
6.7. パスワードおよびその他の機密データ
認証設定によっては、LDAP bindPassword または OAuth clientSecret の値が必須になる場合があります。これらの値は、マスター設定ファイルに直接指定する代わりに、環境変数、外部ファイルまたは暗号化ファイルとして指定することができます。
環境変数の例
...
bindPassword:
env: BIND_PASSWORD_ENV_VAR_NAME
...
bindPassword:
env: BIND_PASSWORD_ENV_VAR_NAME外部ファイルの例
...
bindPassword:
file: bindPassword.txt
...
bindPassword:
file: bindPassword.txt暗号化された外部ファイルの例
...
bindPassword:
file: bindPassword.encrypted
keyFile: bindPassword.key
...
bindPassword:
file: bindPassword.encrypted
keyFile: bindPassword.key上記の例の暗号化ファイルとキーファイルを作成するには、以下を入力します。
oc adm ca encrypt --genkey=bindPassword.key --out=bindPassword.encrypted Data to encrypt: B1ndPass0rd!
$ oc adm ca encrypt --genkey=bindPassword.key --out=bindPassword.encrypted
> Data to encrypt: B1ndPass0rd!
Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。
暗号化データのセキュリティーレベルは復号化キーと同程度です。ファイルシステムのパーミッションとキーファイルへのアクセスを制限する際には十分な注意が必要です。
6.8. 新規設定ファイルの作成
OpenShift Container Platform 設定をゼロから定義するときは、新規設定ファイルを作成することから開始します。
マスターホストの設定ファイルでは、openshift start コマンドを --write-config オプションと共に使用して設定ファイルを作成します。ノードホストの場合は、oc adm create-node-config コマンドを使用して設定ファイルを作成します。
以下のコマンドは、関連する起動設定ファイル、証明書ファイルその他ファイルを指定された --write-config または --node-dir ディレクトリーに書き込みます。
生成される証明書ファイルは 2 年間有効です。一方、認証局 (CA) の証明書は 5 年間有効です。この値は --expire-days と --signer-expire-days のオプションを使用して変更できますが、セキュリティー上の理由によりこの値をこれ以上大きい値に変更しないことが推奨されます。
オールインワンサーバー (マスターとノードが同一ホスト上にある) の設定ファイルを指定されたディレクトリーに作成するには、以下を入力します。
openshift start --write-config=/openshift.local.config
$ openshift start --write-config=/openshift.local.configマスター設定ファイルとその他の必須ファイルを指定されたディレクトリーに作成するには、以下を実行します。
openshift start master --write-config=/openshift.local.config/master
$ openshift start master --write-config=/openshift.local.config/masterノード設定ファイルとその他の関連ファイルを指定されたディレクトリーに作成するには、以下を実行します。
ノード設定ファイルを作成する際に、--hostnames オプションは、サーバー証明書を有効にする必要のあるすべてのホスト名または IP アドレスのカンマ区切りの一覧を受け入れます。
6.9. 設定ファイルの使用によるサーバーの起動
マスターまたはノード設定ファイルをユーザー仕様に変更すると、これを引数として指定してサーバーを起動すると、使用できるようになります。設定ファイルを指定する場合は、ユーザーが渡す他のコマンドラインオプションはいずれも認識されないことに注意してください。
マスター設定およびノード設定ファイルを使用してオールインワンサーバーを起動するには、以下を実行します。
openshift start --master-config=/openshift.local.config/master/master-config.yaml --node-config=/openshift.local.config/node-<node_hostname>/node-config.yaml
$ openshift start --master-config=/openshift.local.config/master/master-config.yaml --node-config=/openshift.local.config/node-<node_hostname>/node-config.yamlマスター設定ファイルを使用してマスターサーバーを起動するには、以下を実行します。
openshift start master --config=/openshift.local.config/master/master-config.yaml
$ openshift start master --config=/openshift.local.config/master/master-config.yamlノード設定ファイルを使ってノードサーバーを起動するには、以下を実行します。
openshift start node --config=/openshift.local.config/node-<node_hostname>/node-config.yaml
$ openshift start node --config=/openshift.local.config/node-<node_hostname>/node-config.yaml6.10. ロギングレベルの設定
OpenShift Container Platform は、5 段階のログメッセージの重要度を用いて、systemd-journald.service を使ってデバッグ用にログメッセージを収集します。ロギングレベルは、以下のような Kubernetes のロギング規則に基づいています。
| オプション | 説明 |
|---|---|
|
0 |
エラーと警告のみ |
|
2 |
通常の情報 |
|
4 |
デバッグレベルの情報 |
|
6 |
API レベルのデバッグ情報 (要求 / 応答) |
|
8 |
本体レベルの API のデバッグ情報 |
ユーザーは、/etc/sysconfig/atomic-openshift-node、/etc/sysconfig/atomic-openshift-master-api ファイル、および /etc/sysconfig/atomic-openshift-master-controllers ファイルにログレベルのオプションを設定することにより、ログに記録する INFO メッセージを制御できます。すべてのメッセージを収集するようにログを設定すると、解釈が困難な膨大なログが生成され、多くの領域が占領されます。すべてのメッセージの収集は、デバッグで使用する場合にとどめる必要があります。
FATAL、ERROR、WARNING、および一部の INFO の重要度を伴うメッセージは、ログの設定に関係なくログに表示されます。
マスターまたはノードシステムのログは、以下のコマンドで表示できます。
journalctl -r -u <journal_name>
# journalctl -r -u <journal_name>
最新のエントリーから表示するには、-r オプションを使用します。
例を以下に示します。
journalctl -r -u atomic-openshift-master-controllers journalctl -r -u atomic-openshift-master-api journalctl -r -u atomic-openshift-node.service
# journalctl -r -u atomic-openshift-master-controllers
# journalctl -r -u atomic-openshift-master-api
# journalctl -r -u atomic-openshift-node.serviceロギングレベルを変更するには、以下を実行します。
- マスターの /etc/sysconfig/atomic-openshift-master ファイル、またはノードの /etc/sysconfig/atomic-openshift-node ファイルを編集します。
上記の Log Level Options 表の値を
OPTIONS=--loglevel=フィールドに入力します。例を以下に示します。
OPTIONS=--loglevel=4
OPTIONS=--loglevel=4Copy to Clipboard Copied! Toggle word wrap Toggle overflow - マスターまたはノードを再起動します。「OpenShift Container Platform サービスの再起動」を参照してください。
再起動後は、すべての新しいログメッセージは新しい設定に従ったメッセージに従います。古いメッセージは変更されません。
デフォルトのログレベルは、通常インストール (Advanced installation) を使って設定できます。詳細は「クラスター変数」を参照してください。
以下の例は、各種のログレベルのマスター journald ログの抜粋です。タイムスタンプとシステム情報はこれらの例では削除されています。
loglevel = 0 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋
loglevel = 2 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋
loglevel = 4 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋
loglevel = 8 の journalctl -u atomic-openshift-master-controllers.service 出力の抜粋
loglevel = 2 の journalctl -u atomic-openshift-master-api.service 出力の抜粋
6.11. OpenShift Container Platform サービスの再起動
設定の変更を適用するには、OpenShift Container Platform サービスを再起動する必要があります。
マスターを再起動するには、以下のコマンドを実行します。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノード上でノードホストを再起動するには、以下のコマンドを実行します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第7章 OpenShift Ansible Broker の設定
7.1. 概要
OpenShift Ansible Broker (OAB) をクラスターにデプロイする際に、その動作の大半は、起動時に読み込まれるブローカーの設定ファイルによって決定されます。ブローカーの設定は、ブローカーの namespace (デフォルトでは (openshift-ansible-service-broker) に ConfigMap オブジェクトとして格納されます。
OpenShift Ansible Broker 設定ファイルの例
7.2. OpenShift Ansible Broker 設定の変更
OAB のデフォルト設定をデプロイした後に変更するには、以下を実行します。
OAB の namespace の broker-config ConfigMap オブジェクトを、cluster-admin 権限を持つユーザーとして編集します。
oc edit configmap broker-config -n openshift-ansible-service-broker
$ oc edit configmap broker-config -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 更新内容を保存した後、変更を有効にするために OAB のデプロイメント設定を再デプロイします。
oc rollout latest dc/asb -n openshift-ansible-service-broker
$ oc rollout latest dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3. レジストリー設定
registry セクションでは、ブローカーが APB 用に参照する必要があるレジストリーを定義できます。
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
レジストリーの名前です。このレジストリーから APB を識別するためにブローカーによって使用されます。 |
Y |
|
|
レジストリーに対して認証するためのユーザー名です。 |
N |
|
|
レジストリーに対して認証するためのパスワードです。 |
N |
|
|
レジストリー認証情報が |
N |
|
|
読み取る必要があるレジストリー認証情報を格納しているシークレットまたはファイルの名前です。 |
N ( |
|
|
イメージが含まれている namespace または組織です。 |
N |
|
|
レジストリーのタイプです。使用可能なアダプターは |
Y |
|
|
|
N |
|
|
イメージ情報を取得するために使用される URL です。これは、RHCC の場合に広範囲に使用されます。 |
N |
|
|
このレジストリーが失敗した場合にブートストラップ要求を失敗させるかどうかを指定します。失敗させる場合、その他のレジストリーの読み込みの実行を停止します。 |
N |
|
|
許可されるイメージ名を定義するための正規表現の一覧です。カタログへの APB の追加を許可するホワイトリストを作成する必要があります。レジストリー内のすべての APB を取得する必要がある場合は、最も許容度の高い正規表現である |
N |
|
|
許可できないイメージ名を定義するために使用される正規表現の一覧です。詳細については、「APB のフィルタリング」を参照してください。 |
N |
|
|
OpenShift Container レジストリーで使用されるイメージの一覧です。 |
N |
7.3.1. 実稼働または開発
実稼働ブローカー設定は、Red Hat Container Catalog (RHCC) などの信頼できるコンテナーディストリビューションレジストリーを参照するように設計されています。
開発ブローカー設定は、主にブローカーの開発作業に取り組む開発者によって使用されます。開発者設定を有効にするには、レジストリー名を dev に設定し、broker セクションの dev_brokerフィールドを true に設定します。
registry: name: dev
registry:
name: devbroker: dev_broker: true
broker:
dev_broker: true7.3.2. レジストリー認証情報の保存
ブローカー設定は、ブローカーによるレジストリー認証情報の読み取り方法を決定します。レジストリー認証情報は、registry セクションの user 値と pass 値から読み取ることができます。以下は例になります。
これらの認証情報にパブリックにアクセスできないようにするには、registry セクションの auth_type フィールドを secret または file タイプに設定します。secret タイプは、ブローカーの namespace からシークレットを使用するようにレジストリーを設定します。一方、file タイプは、ボリュームとしてマウントされているシークレットを使用するようにレジストリーを設定します。
secret または file タイプを使用するには、以下を実行します。
関連するシークレットには、
usernameとpasswordの値が定義されている必要があります。シークレットを使用する場合は、openshift-ansible-service-brokernamespace が存在していることを確認する必要があります。シークレットはこの namespace から読み取られるためです。たとえば、reg-creds.yaml ファイルを作成します。
cat reg-creds.yaml --- username: <username> password: <password>
$ cat reg-creds.yaml --- username: <username> password: <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow このファイルから
openshift-ansible-service-brokernamespace にシークレットを作成します。oc create secret generic \ registry-credentials-secret \ --from-file reg-creds.yaml \ -n openshift-ansible-service-broker$ oc create secret generic \ registry-credentials-secret \ --from-file reg-creds.yaml \ -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow secretまたはfileのどちらのタイプを使用するか選択します。secretタイプを使用するには、以下を実行します。ブローカー設定で、
auth_typeをsecretに、auth_nameをシークレットの名前に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow シークレットが置かれている namespace を設定します。
openshift: namespace: openshift-ansible-service-broker
openshift: namespace: openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
fileタイプを使用するには、以下を実行します。asbデプロイメント設定を編集し、ファイルを /tmp/registry-credentials/reg-creds.yaml にマウントします。oc edit dc/asb -n openshift-ansible-service-broker
$ oc edit dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow containers.volumeMountsセクションに、以下を追加します。volumeMounts: - mountPath: /tmp/registry-credentials name: reg-authvolumeMounts: - mountPath: /tmp/registry-credentials name: reg-authCopy to Clipboard Copied! Toggle word wrap Toggle overflow volumesセクションに、以下を追加します。volumes: - name: reg-auth secret: defaultMode: 420 secretName: registry-credentials-secretvolumes: - name: reg-auth secret: defaultMode: 420 secretName: registry-credentials-secretCopy to Clipboard Copied! Toggle word wrap Toggle overflow ブローカー設定で、
auth_typeをfileに、auth_typeをファイルの場所に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.3.3. モックレジストリー
モックレジストリーは、ローカルの APB 仕様を読み取る場合に便利です。イメージ仕様を検索するために外部のレジストリーにアクセスする代わりに、ローカル仕様の一覧を使用します。 モックレジストリーを使用するには、レジストリーの名前を mock に設定します。
registry:
- name: mock
type: mock
registry:
- name: mock
type: mock7.3.4. Dockerhub レジストリー
dockerhub タイプを使用すると、DockerHub の特定の組織から APB を読み込むことができます (例: ansibleplaybookbundle)。
7.3.5. APB のフィルタリング
APB は、ブローカー設定内のレジストリーベースに設定された white_list または black_list パラメーターの組み合わせを使用して、イメージ名でフィルタリングできます。
これらはどちらもオプションの正規表現の一覧であり、特定のレジストリーで一致するものを判別できるように検出されたすべての APB に対して実行されます。
| 存在するパラメーター | 許可 | ブロック |
|---|---|---|
|
ホワイトリストのみ |
一覧の正規表現に一致。 |
一致しないすべての APB。 |
|
ブラックリストのみ |
一致しないすべての APB。 |
一覧の正規表現に一致する APB。 |
|
両方とも存在する |
ホワイトリストの正規表現に一致し、ブラックリストの正規表現に一致しない。 |
ブラックリストの正規表現に一致する APB。 |
|
なし |
レジストリーのどの APB も許可されない。 |
レジストリーのすべての APB。 |
例を以下に示します。
ホワイトリストのみ
white_list: - "foo.*-apb$" - "^my-apb$"
white_list:
- "foo.*-apb$"
- "^my-apb$"
この場合は、foo.*-apb$ と my-apb に一致する APB が許可されます。それ以外の APB はすべて拒否されます。
ブラックリストのみ
black_list: - "bar.*-apb$" - "^foobar-apb$"
black_list:
- "bar.*-apb$"
- "^foobar-apb$"
この場合は、bar.*-apb$ と foobar-apb に一致する APB がブロックされます。それ以外の APB はすべて許可されます。
ホワイトリストとブラックリスト
white_list: - "foo.*-apb$" - "^my-apb$" black_list: - "^foo-rootkit-apb$"
white_list:
- "foo.*-apb$"
- "^my-apb$"
black_list:
- "^foo-rootkit-apb$"
ここでは、foo-rootkit-apb はホワイトリストに一致するにもかかわらず、ブラックリストによって明確にブロックされます。これは、ホワイトリストの一致が上書きされるためです。
そうでない場合は、foo.*-apb$ と my-apb に一致する APB のみが許可されます。
ブローカー設定の registry セクションのサンプル:
7.3.6. ローカルの OpenShift Container レジストリー
local_openshift タイプを使用すると、OpenShift Container Platform クラスター内の OpenShift Container レジストリーから APB を読み込むことができます。公開された APB を検索する namespace を設定できます。
7.3.7. Red Hat Container Catalog レジストリー
rhcc タイプを使用すると、Red Hat Container Catalog (RHCC) レジストリーに公開された APB を読み込むことができます。
7.3.8. ISV レジストリー
openshift タイプを使用すると、 registry.connect.redhat.com にある ISV コンテナーレジストリーに公開された APB を読み込むことができます。
- 1
- その他の認証オプションについては、「レジストリー認証情報の保存」を参照してください。
- 2
- 現時点で
openshiftタイプは設定済みのレジストリーを検索できないため、ブローカーのブートストラップ時にソースとして使用するイメージの一覧でブローカーを設定する必要があります。イメージ名は、レジストリー URL のない完全修飾名でなければなりません。
7.3.9. 複数のレジストリー
複数のレジストリーを使用して APB を論理的な組織に分割し、それらを同じブローカーから管理できます。レジスターには一意の空でない名前が必要です。一意の名前がない場合、サービスブローカーは起動に失敗し、問題について警告するエラーメッセージを表示します。
7.4. DAO 設定
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
etcd ホストの URL です。 |
Y |
|
|
|
Y |
7.5. ログ設定
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
ブローカーのログを書き込む場所です。 |
Y |
|
|
ログを標準出力に書き込みます。 |
Y |
|
|
ログ出力のレベルです。 |
Y |
|
|
ログに色付けします。 |
Y |
7.6. OpenShift 設定
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
OpenShift Container Platform ホストです。 |
N |
|
|
認証局ファイルの場所です。 |
N |
|
|
使用するベアラートークンの場所です。 |
N |
|
|
イメージをプルするタイミングです。 |
Y |
|
|
ブローカーがデプロイされている namespace です。シークレットを介して渡されるパラメーター値などに重要です。 |
Y |
|
|
APB サンドボックス環境に対して指定するロールです。 |
Y |
|
|
APB の実行後に namespace を常に保持します。 |
N |
|
|
APB の実行でエラーが発生した後に namespace を保持します。 |
N |
7.7. ブローカー設定
broker セクションでは、有効/無効にする機能をブローカーに指示します。また、完全な機能を有効にするファイルがディスク上のどこにあるかをブローカーに指示します。
| フィールド | 説明 | デフォルト値 | 必須 |
|---|---|---|---|
|
|
開発ルートにアクセスできるようにします。 |
|
N |
|
|
バインドが no-op (無処理) になることを許可します。 |
|
N |
|
|
ブローカーが起動時に自らをブートストラップできるようにします。APB を設定済みのレジストリーから取得します。 |
|
N |
|
|
etcd にある保留中のジョブを処理することによって、ブローカーが自らをリカバリーできるようにします。 |
|
N |
|
|
デバッグを容易に行えるように、ブローカーが要求の受信時にそれをログファイルに出力できるようにします。 |
|
N |
|
|
TLS キーファイルがどこにあるかをブローカーに指示します。これが設定されない場合、API サーバーはキーファイルの作成を試みます。 |
|
N |
|
|
TLS .crt ファイルがどこにあるかをブローカーに指示します。これが設定されない場合、API サーバーはファイルの作成を試みます。 |
|
N |
|
|
レジストリーで新規イメージ仕様をクエリーする間隔です。 |
|
N |
|
|
ブローカーが APB の実行中にユーザーのパーミッションをエスカレーションできるようにします。 |
|
N |
|
|
ブローカーが予期する URL のプレフィックスを設定します。 |
|
N |
非同期のバインドまたはバインド解除は実験的な機能であり、サポートされていないか、デフォルトでは有効になっていません。非同期バインドがない場合に launch_apb_on_bind を true に設定すると、バインドアクションがタイムアウトになり、再試行が実行されます。これはパラメーターの異なる同じバインド要求であるため、ブローカーは「409 Conflicts」で処理します。
7.8. シークレット設定
secrets セクションでは、ブローカーの namespace のシークレットとブローカーが実行する APB 間の関連付けを作成します。ブローカーは、これらのルールに従って実行中の APB にシークレットをマウントします。これにより、ユーザーはシークレットを使用して、パラメーターをカタログやユーザーに公開せずに渡すことができます。
このセクションは一覧の形式であり、各エントリーは以下の構造を持ちます。
| フィールド | 説明 | 必須 |
|---|---|---|
|
|
ルールのタイトルです。表示と出力の目的でのみ使用されます。 |
Y |
|
|
指定されたシークレットに関連付けられる APB の名前です。これは完全修飾名 ( |
Y |
|
|
パラメーターをプルするシークレットの名前です。 |
Y |
create_broker_secret.py ファイルをダウンロードし、これを使用して、この設定セクションの作成とフォーマットを行うことができます。
secrets: - title: Database credentials secret: db_creds apb_name: dh-rhscl-postgresql-apb
secrets:
- title: Database credentials
secret: db_creds
apb_name: dh-rhscl-postgresql-apb7.9. プロキシー環境での実行
プロキシー化された OpenShift Container Platform クラスター内で OAB を実行する場合は、その中心的な概念を理解し、外部ネットワークアクセスに使用するプロキシーのコンテキストで検討することが重要です。
概要としては、ブローカー自体はクラスター内で Pod として実行され、そのレジスターの設定方法に応じて外部ネットワークにアクセスする必要があります。
7.9.1. レジストリーアダプターのホワイトリスト
ブローカーの設定済みレジストリーアダプターは、正常にブートストラップしてリモートの APB マニフェストを読み込むために、外部レジスターと通信できなければなりません。これらの要求はプロキシー経由で実行できますが、プロキシーでは必要なリモートホストにアクセスできるようにする必要があります。
必要なホワイトリスト化されたホストの例:
| レジストリーアダプターのタイプ | ホワイトリスト化されたホスト |
|---|---|
|
|
|
|
|
|
7.9.2. Ansible を使用したプロキシー環境でのブローカーの設定
初期インストール時に OpenShift Container Platform クラスターがプロキシーの環境下で実行されるように設定した場合 (「グローバルプロキシーオプションの設定」を参照)、OAB はデプロイ時に以下を実行します。
- クラスター全体のプロキシー設定を自動的に継承する
-
cidrフィールドおよびserviceNetworkCIDRを含む必要なNO_PROXY一覧を生成する
それ以外の設定は必要ありません。
7.9.3. プロキシー環境でのブローカーの手動設定
クラスターのグローバルプロキシーオプションが初期インストール時またはブローカーのデプロイ前に設定されていない場合や、グローバルプロキシー設定を変更した場合、ブローカーの外部アクセスについてプロキシー経由で手動で設定する必要があります。
OAB をプロキシー環境で実行する前に「HTTP プロキシーの使用」を確認し、クラスターがプロキシー環境で実行されるように適切に設定されていることを確認してください。
とくに、クラスターは内部クラスター要求をプロキシー処理しないように設定されている必要があります。通常、これは以下の
NO_PROXY設定を使用して設定されます。.cluster.local,.svc,<serviceNetworkCIDR_value>,<master_IP>,<master_domain>,.default
.cluster.local,.svc,<serviceNetworkCIDR_value>,<master_IP>,<master_domain>,.defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow その他の必要な
NO_PROXY設定も追加する必要があります。詳細については、「NO_PROXY の設定」を参照してください。注記バージョンなしまたは v1 の APB をデプロイするブローカーは、
172.30.0.1もNO_PROXYの一覧に追加する必要があります。v2 より前の APB は、シークレットの交換ではなく、execHTTP 要求を使用して実行中の APB Pod から認証情報を抽出しました。実験的なプロキシーサポートがあるブローカーを OpenShift Container Platform 3.9 より前のクラスターで実行していない限り、この点を心配する必要はおそらくありません。ブローカーの
DeploymentConfigを cluster-admin 権限を持つユーザーとして編集します。oc edit dc/asb -n openshift-ansible-service-broker
$ oc edit dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の環境変数を設定します。
-
HTTP_PROXY -
HTTPS_PROXY -
NO_PROXY
注記詳細については、「Pod でのプロキシー環境変数の設定」を参照してください。
-
更新内容を保存した後、変更を有効にするために OAB のデプロイメント設定を再デプロイします。
oc rollout latest dc/asb -n openshift-ansible-service-broker
$ oc rollout latest dc/asb -n openshift-ansible-service-brokerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.9.4. Pod でのプロキシー環境変数の設定
一般に、APB Pod 自体もプロキシー経由の外部アクセスを必要とします。ブローカーは、自らにプロキシー設定があることを認識すると、生成する APB Pod にこれらの環境変数を透過的に適用します。APB 内で使用されるモジュールが環境変数経由でプロキシー設定に従う限り、APB もこれらの設定に基づいて動作します。
最後に、APB によって生成されたサービスもプロキシー経由の外部ネットワークアクセスを必要とする場合があります。APB は、それ自体の実行環境でこのようなサービスを検出した場合にこれらの環境変数を明示的に設定するように作成されている必要があります。そうでない場合には、クラスターオペレーターが必要なサービスを変更してそれらを環境に組み込む必要があります。
第8章 ホストの既存クラスターへの追加
8.1. 概要
OpenShift Container Platform クラスターのインストール方式に応じて、インストールツールによるクイックインストールか、または scaleup.yml Playbook による通常インストール (Advanced installation) を使用して新規ホスト (ノードまたはマスター) をインストールに追加できます。
8.2. クイックインストーラーツールを使用したホストの追加
クイックインストールツールを使用して OpenShift Container Platform クラスターをインストールした場合は、クイックインストールツールを使用して新規ノードホストを既存クラスターに追加できます。
現時点では、クイックインストーラーツールを使用して新規マスターホストを追加することはできません。新規マスターホストを追加するには、通常インストール (Advanced installation) 方式を使用する必要があります。
インストーラーを対話型モードまたは無人モードのいずれかで使用した場合は、インストール設定ファイルが ~/.config/openshift/installer.cfg.ymlにある限り (または -c オプションで別の場所を指定して)、インストールを再実行できます。
推奨される最大ノード数については、「Cluster Limits」セクションを参照してください。
ノードをインストールに追加するには、以下を実行します。
atomic-openshift-utils パッケージを更新して最新のインストーラーと Playbook を取得します。
yum update atomic-openshift-utils
# yum update atomic-openshift-utilsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 対話型モードまたは無人モードで
scaleupサブコマンドを使用してインストーラーを実行します。atomic-openshift-installer [-u] [-c </path/to/file>] scaleup
# atomic-openshift-installer [-u] [-c </path/to/file>] scaleupCopy to Clipboard Copied! Toggle word wrap Toggle overflow インストーラーによって現在の環境が検出され、ノードを追加できるようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow (y) を選択し、画面の指示に従って必要なタスクを完了します。
8.3. ホストの追加
scaleup.yml Playbook を実行して新規ホストをクラスターに追加できます。この Playbook は、マスターをクエリーし、新規ホストの新規証明書を生成して配布し、これらの新規ホストでのみ、設定 Playbook を実行します。scaleup.yml Playbook を実行する前に、前提条件となるホストの準備手順をすべて完了してください。
scaleup.yml の Playbook は新規ホストの設定のみを実行します。マスターサービスの NO_PROXY の更新やマスターサービスの再起動は行いません。
scaleup.yml Playbook を実行するには、現在のクラスター設定を表す既存のインベントリーファイル (/etc/ansible/hosts など) が必要です。以前に atomic-openshift-installer コマンドを使用してインストールを実行した場合は、~/.config/openshift/hosts を調べて、インストーラーによって生成された最新のインベントリーファイルを見つけ、それをそのまま使用するか、インベントリーファイルの必要に応じて変更することができます。後で ansible-playbook を呼び出すときに、-i オプションを使用してそのファイルを指定する必要があります。
推奨される最大ノード数については、「Cluster Limits」セクションを参照してください。
手順
atomic-openshift-utils パッケージを更新して最新の Playbook を取得します。
yum update atomic-openshift-utils
# yum update atomic-openshift-utilsCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/ansible/hosts ファイルを編集し、 new_<host_type> を [OSEv3:children] セクションに追加します。
たとえば、新規ノードホストを追加するには、new_nodes を追加します。
[OSEv3:children] masters nodes new_nodes
[OSEv3:children] masters nodes new_nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規マスターホストを追加するには、new_masters を追加します。
[new_<host_type>] セクションを作成して、新規ホストのホスト情報を指定します。このセクションは、以下の新規ノードの追加例で示されているように、既存のセクションと同じような形式で作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow その他のオプションについては、「ホスト変数の設定」を参照してください。
新規マスターを追加する場合は、[new_masters] セクションと [new_nodes] セクションの両方に新規ホストを追加して。新規マスターホストが OpenShift SDN の一部となるようにします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要マスターホストに
region=infraラベルを付け、それ以外に専用インフラストラクチャーノードがない場合は、エントリーにopenshift_schedulable=trueを追加してホストにスケジュール可能であることを示すマークを明示的に付ける必要もあります。そうしないと、レジストリー Pod とルーター Pod をどこにも配置できなくなります。scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、
-iオプションで場所を指定します。ノードを追加する場合は、以下を指定します。
ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-node/scaleup.yml# ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-node/scaleup.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow マスターを追加する場合は、以下を実行します。
ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-master/scaleup.yml# ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-master/scaleup.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- Playbook の実行後に、インストールを確認します。
[new_<host_type>] セクションで定義したホストを適切なセクションに移動します。このようにホストを移動することで、このインベントリーファイルを使用するその後の Playbook の実行で、正しくノードが処理されるようになります。[new_<host_type>] セクションは空のままで結構です。たとえば、新規ノードを追加する場合は以下のように指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. etcd ホストの既存クラスターへの追加
etcd scaleup Playbook を実行して新規 etcd ホストを追加することができます。この Playbook は、マスターをクエリーし、新規ホストの新規証明書を生成してこれを配布し、設定 Playbook を新規ホストにのみ実行します。etcd scaleup.yml Playbook を実行する前に、前提条件となるホストの準備 手順をすべて完了してください。
etcd ホストを既存クラスターに追加するには、以下を実行します。
atomic-openshift-utils パッケージを更新して最新の Playbook を取得します。
yum update atomic-openshift-utils
$ yum update atomic-openshift-utilsCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/ansible/hosts ファイルを編集し、new_<host_type> を [OSEv3:children] グループに、ホストを new_<host_type> グループに追加します。
たとえば、新規 etcd を追加するには、new_etcd を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd scaleup.yml Playbook を実行します。インベントリーファイルがデフォルトの /etc/ansible/hosts 以外の場所にある場合は、
-iオプションで場所を指定します。ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/scaleup.yml
$ ansible-playbook [-i /path/to/file] \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/scaleup.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードラベルを
logging-infra-fluentd: "true"に設定します。oc label node/new-node.example.com logging-infra-fluentd: "true"
# oc label node/new-node.example.com logging-infra-fluentd: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Playbook が正常に完了したら、インストールを確認します。
8.5. 共存する etcd での既存のマスターの置き換え
マシンを別のデータセンターに移行し、割り当てられているネットワークと IP が変更される場合には、以下の手順を実行します。
プライマリー etcd およびマスターノードをバックアップします。
重要「etcd のバックアップ」の説明にあるように、/etc/etcd/ ディレクトリーがバックアップされていることを確認します。
- 置き換えるマスターの数だけ、新規マシンをプロビジョニングします。
クラスターを追加または拡張します。たとえば、etcd が共存するマスターを 3 つ追加する場合には、マスターノード 3 つまたは etcd ノード 3 つに拡張します。
-
マスターを追加します。このプロセスのステップ 3 で、
[new_masters]と[new_nodes]に新規データセンターのホストを追加して、マスターの scaleup.yml Playbook を実行します。 - 同じホストを etcd セクションに配置して、etcd scaleup.yml Playbook を実行します。
ホストが追加されたことを確認します。
oc get nodes
# oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow マスターホストの IP が追加されたことを確認します。
oc get ep kubernetes
# oc get ep kubernetesCopy to Clipboard Copied! Toggle word wrap Toggle overflow etcd が追加されたことを確認します。
ETCDCTL_APIの値は、使用するバージョンにより異なります。source /etc/etcd/etcd.conf ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
# source /etc/etcd/etcd.conf # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member listCopy to Clipboard Copied! Toggle word wrap Toggle overflow - /etc/origin/master ディレクトリーから、インベントリーファイルの最初に記載されている新規マスターホストに、/etc/origin/master/ca.serial.txt をコピーします。デフォルトでは、これは /etc/ansible/hosts です。
-
マスターを追加します。このプロセスのステップ 3 で、
etcd ホストを削除します。
- /etc/etcd/ca ディレクトリーを、インベントリーファイルの最初に記載されている新規 etcd ホストにコピーします。デフォルトでは、これは /etc/ansible/hosts です。
master-config.yaml ファイルから以前の etcd クライアントを削除します。
grep etcdClientInfo -A 11 /etc/origin/master/master-config.yaml
# grep etcdClientInfo -A 11 /etc/origin/master/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow マスターを再起動します。
systemctl restart atomic-openshift-master-*
# systemctl restart atomic-openshift-master-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターから以前の etcd メンバーを削除します。
ETCDCTL_APIの値は、使用するバージョンにより異なります。source /etc/etcd/etcd.conf ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member list
# source /etc/etcd/etcd.conf # ETCDCTL_API=2 etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URLS member listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上記のコマンドの出力から ID を取得して、この ID で以前のメンバーを削除します。
etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URL member remove 1609b5a3a078c227
# etcdctl --cert-file=$ETCD_PEER_CERT_FILE --key-file=$ETCD_PEER_KEY_FILE \ --ca-file=/etc/etcd/ca.crt --endpoints=$ETCD_LISTEN_CLIENT_URL member remove 1609b5a3a078c227Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以前の etcd ホストで etcd サービスを停止して、無効化します。
systemctl stop etcd systemctl disable etcd
# systemctl stop etcd # systemctl disable etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
以前のマスター API とコントローラーサービスをシャットダウンします。
systemctl stop atomic-openshift-master-api
# systemctl stop atomic-openshift-master-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ネイティブのインストールプロセス時にデフォルトでロードバランサーとしてインストールされていた、マスターノードを、HA プロキシー設定から削除します。
マシンの使用を停止します。
削除するマスター上の
atomic-openshift-nodeサービスを停止します。systemctl stop atomic-openshift-node
# systemctl stop atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードリソースを削除します。
oc delete node
# oc delete nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6. ノードの移行
ノード上のサービスの実行方法やスケーリング方法、慣れた方法により、ノードを個別での移行や、グループ (2、5、10 ずつなど) 単位での移行が可能です。
- 移行するノードについては、新規データセンターでのノードの使用のために新規の仮想マシンをプロビジョニングします。
- 新規ノードを追加するには、インフラストラクチャーを拡大します。新規ノードのラベルが適切に設定されており、新規 API サーバーがロードバランサーに追加され、トラフィックを適切に送信していることを確認します。
評価し、縮小します。
ノードを削除します。
- ノードが空であり、実行中のプロセスがないことを確認します。
- サービスを停止するか、またはノードを削除します。
第9章 デフォルトのイメージストリームとテンプレートの読み込み
9.1. 概要
OpenShift Container Platform インストールには、Red Hat が提供するイメージストリームとテンプレートの便利なセットが含まれています。このセットを使用すると、開発者は新規アプリケーションを簡単に作成できます。デフォルトでは、これらのセットは クイックインストール方式と通常インストール (Advanced installation) 方式で openshift プロジェクトに自動的に作成されます。このプロジェクトは、すべてのユーザーが表示アクセスを持つデフォルトのグローバルプロジェクトです。
9.2. サブスクリプションタイプ別のサービス
お使いの Red Hat アカウントのアクティブなサブスクリプションに応じて、以下のイメージストリームとテンプレートのセットが Red Hat によって提供され、サポートされます。サブスクリプションの詳細については、Red Hat の営業担当者にお問い合わせください。
9.2.1. OpenShift Container Platform サブスクリプション
アクティブな OpenShift Container Platform サブスクリプション により、イメージストリームとテンプレートのコアのセットが提供され、サポートされます。これには以下のテクノロジーが含まれます。
| 種別 | テクノロジー |
|---|---|
|
言語とフレームワーク | |
|
データベース | |
|
ミドルウェアサービス | |
|
他のサービス |
9.2.2. xPaaS ミドルウェアアドオンサブスクリプション
xPaaS ミドルウェアイメージのサポートは、xPaaS 製品ごとに提供されるサブスクリプションである xPaaS ミドルウエアアドオンサブスクリプション で提供されます。お使いのアカウントで該当するサブスクリプションがアクティブになっている場合は、以下のテクノロジーのイメージストリームとテンプレートが提供され、サポートされます。
9.3. 作業を開始する前に
このトピックのタスクの実行を検討する前に、以下のいずれかを実行してこれらのイメージストリームとテンプレートが OpenShift Container Platform クラスターにすでに登録されているかどうかを確認してください。
- Web コンソールにログインして Add to Project をクリックします。
CLI を使用して openshift プロジェクト用のイメージストリームとテンプレートの一覧を表示します。
oc get is -n openshift oc get templates -n openshift
$ oc get is -n openshift $ oc get templates -n openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトのイメージストリームとテンプレートが削除または変更されている場合は、このトピックに従ってデフォルトのオブジェクトを各自で作成できます。そうしない場合は、以下の指示に従う必要はありません。
9.4. 前提条件
デフォルトのイメージストリームとテンプレートを作成する前に、以下を確認してください。
- 統合 Docker レジストリーサービスが OpenShift Container Platform インストールにデプロイされている必要があります。
-
oc createコマンドを cluster-admin 権限で実行できる必要があります。デフォルトの openshift プロジェクト で動作できるようにするためです。 - atomic-openshift-utils RPM パッケージがインストールされている必要があります。手順については、「ソフトウェアの前提条件」を参照してください。
イメージストリームとテンプレートが含まれているディレクトリーのシェル変数を定義します。これにより、以降のセクションで使用するコマンドが大幅に短くなります。これを実行するには、以下のように入力します。
IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/image-streams"; \ XPAASSTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/xpaas-streams"; \ XPAASTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/xpaas-templates"; \ DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/db-templates"; \ QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/quickstart-templates"$ IMAGESTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/image-streams"; \ XPAASSTREAMDIR="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/xpaas-streams"; \ XPAASTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/xpaas-templates"; \ DBTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/db-templates"; \ QSTEMPLATES="/usr/share/ansible/openshift-ansible/roles/openshift_examples/files/examples/v3.9/quickstart-templates"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.5. OpenShift Container Platform イメージのイメージストリームの作成
ノードホストが Red Hat サブスクリプションマネージャーを使用してサブスクライブされていて、Red Hat Enterprise Linux (RHEL) 7 ベースのイメージを使用したイメージストリームのコアセットを使用する必要がある場合には、以下を実行します。
oc create -f $IMAGESTREAMDIR/image-streams-rhel7.json -n openshift
$ oc create -f $IMAGESTREAMDIR/image-streams-rhel7.json -n openshiftまたは、CentOS 7 ベースのイメージを使用するイメージストリームのコアセットを作成するには、以下を実行します。
oc create -f $IMAGESTREAMDIR/image-streams-centos7.json -n openshift
$ oc create -f $IMAGESTREAMDIR/image-streams-centos7.json -n openshiftCentOS と RHEL の両方のイメージストリームセットは同じ名前なので、両方を作成することはできません。両方のイメージストリームセットをユーザーが使用できるようにするには、一方のセットを別のプロジェクトに作成するか、いずれかのファイルを編集し、イメージストリームの名前を一意の名前に変更します。
9.6. xPaaS ミドルウェアイメージのイメージストリームの作成
xPaaS ミドルウェアイメージストリームは、JBoss EAP、JBoss JWS、JBoss A-MQ、JBoss Fuse Integration Services、Decision Server、JBoss Data Virtualization、および JBoss Data Grid のイメージを提供します。それらのイメージは、提供されるテンプレートを使用してこれらのプラットフォームのアプリケーションを作成するために使用できます。
xPaaS ミドルウェアイメージストリームセットを作成するには、以下を実行します。
oc create -f $XPAASSTREAMDIR/jboss-image-streams.json -n openshift
$ oc create -f $XPAASSTREAMDIR/jboss-image-streams.json -n openshiftこれらのイメージストリームによって参照されるイメージにアクセスするには、該当する xPaaS ミドルウェアサブスクリプションが必要です。
9.7. データベースサービステンプレートの作成
データベースサービステンプレートを使用すると、他のコンポーネントで利用できるデータベースイメージを簡単に実行できます。データベース (MongoDB、MySQL、および PostgreSQL) ごとに、2 つのテンプレートが定義されています。
1 つのテンプレートはコンテナー内の一時ストレージを使用します。つまり、保存データは Pod の移動などによってコンテナーが再起動されると失われます。このテンプレートは、デモ目的にのみ使用してください。
もう 1 つのテンプレートは永続ボリュームをストレージに使用しますが、OpenShift Container Platform インストールに永続ボリュームが設定されている必要があります。
データベーステンプレートのコアセットを作成するには、以下を実行します。
oc create -f $DBTEMPLATES -n openshift
$ oc create -f $DBTEMPLATES -n openshiftテンプレートを作成したら、ユーザーは各種のテンプレートを簡単にインスタンス化し、データベースデプロイメントにすばやくアクセスできるようになります。
9.8. インスタントアプリケーションおよびクイックスタートテンプレートの作成
インスタントアプリケーションおよびクイックスタートテンプレートでは、実行中のアプリケーションのオブジェクトの完全なセットを定義します。これには以下が含まれます。
いくつかのテンプレートでは、アプリケーションがデータベース操作を実行できるように、データベースデプロイメントとサービスも定義します。
データベースを定義するテンプレートでは、一時ストレージを使用してデータベースコンテンツを格納します。これらのテンプレートはデモ目的にのみ使用してください。何らかの理由でデータベース Pod が再起動すると、すべてのデータベースデータが失われるためです。
これらのテンプレートを使用すると、ユーザーは、OpenShift Container Platform で提供される各種の言語イメージを使用する完全なアプリケーションを簡単にインスタンス化できます。また、インストール時にテンプレートのパラメーターをカスタマイズし、サンプルリポジトリーではなく独自のリポジトリーからソースがビルドされるようにできます。つまり、これは新規アプリケーションのビルドの単純な開始点となります。
コアのインスタントアプリケーションおよびクイックスタートテンプレートを作成するには、以下を実行します。
oc create -f $QSTEMPLATES -n openshift
$ oc create -f $QSTEMPLATES -n openshift各種の xPaaS ミドルウェア製品 (JBoss EAP、JBoss JWS、JBoss A-MQ、JBoss Fuse Integration Services、Decision Server、および JBoss Data Grid) を使用するアプリケーションを作成するためのテンプレートのセットも用意されています。このテンプレートセットを登録するには、以下を実行します。
oc create -f $XPAASTEMPLATES -n openshift
$ oc create -f $XPAASTEMPLATES -n openshiftxPaaS ミドルウェアテンプレートには、xPaaS ミドルウェアイメージストリームが必要です。さらに、xPaaS ミドルウェアイメージストリームには、該当する xPaaS ミドルウェアサブスクリプションが必要です。
データベースを定義するテンプレートでは、一時ストレージを使用してデータベースコンテンツを格納します。これらのテンプレートはデモ目的にのみ使用してください。何らかの理由でデータベース Pod が再起動すると、すべてのデータベースデータが失われるためです。
9.9. 次のステップ
これらのアーティファクトを作成したら、開発者は Web コンソールにログインし、テンプレートからの作成フローを実行できるようになります。任意のデータベースまたはアプリケーションテンプレートを選択し、現在のプロジェクトで実行するデータベースサービスまたはアプリケーションを作成できます。一部のアプリケーションテンプレートでは独自のデータベースサービスも定義することに注意してください。
サンプルアプリケーションはすべて、SOURCE_REPOSITORY_URL パラメーター値が示すように、テンプレートのデフォルトの参照先である GitHub リポジトリーからビルドされます。これらのリポジトリーはフォークすることができ、テンプレートから作成する際にフォークを SOURCE_REPOSITORY_URL パラメーター値として指定できます。これにより、開発者は独自のアプリケーションの作成を試行することができます。
開発者は、開発者ガイドの「インスタントアプリおよびクイックスタートテンプレートの使用」セクションでこれらの手順を確認できます。
第10章 カスタム証明書の設定
10.1. 概要
管理者は、OpenShift Container Platform API のパブリックホスト名および Web コンソール用のカスタム提供証明書を設定できます。この設定は、通常インストール (Advanced installation) の実行時か、またはインストール後に行うことができます。
10.2. インストール時のカスタム証明書の設定
通常インストール (Advanced installation) の実行時に、カスタム証明書はインベントリーファイルで設定可能な openshift_master_named_certificates パラメーターと openshift_master_overwrite_named_certificates パラメーターを使用して設定できます。詳細については、「Ansible を使用したカスタム証明書の設定」を参照してください。
カスタム証明書の設定パラメーター
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]
openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"}
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]
openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"} - 1
openshift_master_named_certificatesパラメーターの値を指定した場合は、このパラメーターをtrueに設定します。- 2
- マスター API 証明書をプロビジョニングします。
- 3
- ワイルドカード API 証明書をプロビジョニングします。
以下は、マスター API 証明書のパラメーターの例です。
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"names": ["master.148.251.233.173.nip.io"], "certfile": "/home/cloud-user/master-bundle.cert.pem", "keyfile": "/home/cloud-user/master.148.251.233.173.nip.io.key.pem" ]
openshift_master_overwrite_named_certificates=true
openshift_master_named_certificates=[{"names": ["master.148.251.233.173.nip.io"], "certfile": "/home/cloud-user/master-bundle.cert.pem", "keyfile": "/home/cloud-user/master.148.251.233.173.nip.io.key.pem" ]以下は、ワイルドカード API 証明書のパラメーターの例です。
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}10.3. Web コンソールまたは CLI 用カスタム証明書の設定
Web コンソールおよび CLI 用のカスタム証明書は、マスター設定ファイルの servingInfo セクションで指定できます。
-
servingInfo.namedCertificatesセクションでは、Web コンソール用のカスタム証明書を指定します。 -
servingInfoセクションでは、CLI およびその他の API 呼び出し用のカスタム証明書を指定します。
この方法で複数の証明書を設定し、それぞれの証明書を複数のホスト名、複数のルーター、または OpenShift Container Platform イメージレジストリーに関連付けることができます。
デフォルトの証明書は、namedCertificates のほかにも servingInfo.certFile および servingInfo.keyFile 設定セクションに設定する必要があります。
namedCertificates セクションは、/etc/origin/master/master-config.yaml ファイルの masterPublicURL および oauthConfig.assetPublicURL 設定に関連付けられたホスト名についてのみ設定する必要があります。masterURL に関連付けられたホスト名にカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API と通信しようとするため、TLS エラーが発生します。
カスタム証明書の設定
Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) の openshift_master_cluster_public_hostname パラメーターと openshift_master_cluster_hostname パラメーターは異なっていなければなりません。これらが同じであると、名前付き証明書が失敗し、証明書の再インストールが必要になります。
Native HA with External LB VIPs
# Native HA with External LB VIPs
openshift_master_cluster_hostname=internal.paas.example.com
openshift_master_cluster_public_hostname=external.paas.example.comOpenShift Container Platform で DNS を使用する方法の詳細については、「DNS のインストールの前提条件」を参照してください。
この方法では、OpenShift Container Platformによって生成される自己署名証明書を利用して、必要に応じて信頼できるカスタム証明書を個々のコンポーネントに追加できます。
内部インフラストラクチャーの証明書は自己署名のままであることに注意してください。これは一部のセキュリティーチームや PKI チームから不適切な使用法と見なされる場合があります。ただし、これらの証明書を信頼するクライアントはクラスター内のその他のコンポーネントだけであるため、これに伴うリスクは最小限です。外部のユーザーとシステムはすべて、信頼できるカスタム証明書を使用します。
相対パスは、マスター設定ファイルの場所に基づいて解決されます。設定の変更が反映されるようにサーバーを再起動します。
10.4. カスタムマスターホスト証明書の設定
OpenShift Container Platform の外部ユーザーとの信頼できる接続を容易にするために、Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) の openshift_master_cluster_public_hostname パラメーターで指定されたドメイン名に一致する名前付き証明書をプロビジョニングできます。
この証明書は Ansible がアクセスできるディレクトリーに置き、以下のように Ansible インベントリーファイルにパスを追加する必要があります。
openshift_master_named_certificates=[{"certfile": "/path/to/console.ocp-c1.myorg.com.crt", "keyfile": "/path/to/console.ocp-c1.myorg.com.key", "names": ["console.ocp-c1.myorg.com"]}]
openshift_master_named_certificates=[{"certfile": "/path/to/console.ocp-c1.myorg.com.crt", "keyfile": "/path/to/console.ocp-c1.myorg.com.key", "names": ["console.ocp-c1.myorg.com"]}]パラメーター値は以下のようになります。
- certfile は、OpenShift Container Platform ルーター証明書を含むファイルへのパスです。
- keyfile は、OpenShift Container Platform ワイルドカードキーを含むファイルへのパスです。
- names は、クラスターのパブリックホスト名です。
ファイルパスは、Ansible が実行されるシステムにとってローカルでなければなりません。証明書はマスターホストにコピーされ、/etc/origin/master ディレクトリー内にデプロイされます。
レジストリーのセキュリティーを保護する場合、サービスのホスト名と IP アドレスをレジストリーのサーバー証明書に追加します。SAN (Subject Alternative Name) には以下の情報が含まれている必要があります。
2 つのサービスホスト名。
docker-registry.default.svc.cluster.local docker-registry.default.svc
docker-registry.default.svc.cluster.local docker-registry.default.svcCopy to Clipboard Copied! Toggle word wrap Toggle overflow サービス IP アドレス。
例を以下に示します。
172.30.252.46
172.30.252.46Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使って Docker レジストリーのサービス IP アドレスを取得します。
oc get service docker-registry --template='{{.spec.clusterIP}}'oc get service docker-registry --template='{{.spec.clusterIP}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow パブリックホスト名。
docker-registry-default.apps.example.com
docker-registry-default.apps.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使って Docker レジストリーのパブリックホスト名を取得します。
oc get route docker-registry --template '{{.spec.host}}'oc get route docker-registry --template '{{.spec.host}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
たとえば、サーバー証明書には以下のような SAN の詳細が記載されるはずです。
X509v3 Subject Alternative Name:
DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.98
X509v3 Subject Alternative Name:
DNS:docker-registry-public.openshift.com, DNS:docker-registry.default.svc, DNS:docker-registry.default.svc.cluster.local, DNS:172.30.2.98, IP Address:172.30.2.9810.5. デフォルトルーター用のカスタムワイルドカード証明書の設定
OpenShift Container Platform のデフォルトルーターをデフォルトのワイルドカード証明書を使って設定できます。デフォルトのワイルドカード証明書を使用すると、OpenShift Container Platform にデプロイされているアプリケーションでカスタム証明書を使用せずにデフォルトの暗号化を簡単に使用することができます。
デフォルトのワイルドカード証明書の使用は、非実稼働環境でのみ推奨されます。
デフォルトのワイルドカード証明書を設定するには、.<app_domain> で有効な証明書をプロビジョニングします。ここで、<app_domain> は、Ansible インベントリーファイル(デフォルトでは /etc/ansible/hosts) の openshift_master_default_subdomain の値です。プロビジョニングが完了したら、証明書、キー、CA 証明書ファイルを Ansible ホストに置き、以下の行を Ansible インベントリーファイルに追加します。
openshift_hosted_router_certificate={"certfile": "/path/to/apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/apps.c1-ocp.myorg.com.key", "cafile": "/path/to/apps.c1-ocp.myorg.com.ca.crt"}
openshift_hosted_router_certificate={"certfile": "/path/to/apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/apps.c1-ocp.myorg.com.key", "cafile": "/path/to/apps.c1-ocp.myorg.com.ca.crt"}例を以下に示します。
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}
openshift_hosted_router_certificate={"certfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.cert.pem", "keyfile": "/home/cloud-user/star-apps.148.251.233.173.nip.io.key.pem", "cafile": "/home/cloud-user/ca-chain.cert.pem"}パラメーター値は以下のようになります。
- certfile は、OpenShift Container Platform ルーター証明書を含むファイルへのパスです。
- keyfile は、OpenShift Container Platform ワイルドカードキーを含むファイルへのパスです。
- cafile は、このキーと証明書のルート CA を含むファイルへのパスです。中間 CA を使用している場合は、中間 CA とルート CA の両方がこのファイルに含まれている必要があります。
これらの証明書ファイルを OpenShift Container Platform クラスターで初めて使用する場合は、Ansible deploy_router.yml Playbook を実行し、これらのファイルを OpenShift Container Platform 設定ファイルに追加します。この Playbook は、証明書ファイルを /etc/origin/master/ ディレクトリーに追加します。
ansible-playbook [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/deploy_router.yml
# ansible-playbook [-i /path/to/inventory] \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/deploy_router.ymlこれらの証明書を使用するのが初めてでない場合、たとえば、既存の証明書を変更するか、期限切れの証明書を置き換える場合は、以下の Playbook を実行します。
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.ymlこの Playbook を実行する場合は、証明書名を変更しないでください。証明書名を変更した場合は、新規証明書の場合と同様に Ansible deploy_cluster.yml Playbook を再実行してください。
10.6. イメージレジストリー用のカスタム証明書の設定
OpenShift Container Platform イメージレジストリーは、ビルドとデプロイメントを容易にする内部サービスです。レジストリーとの通信の大部分は、OpenShift Container Platform の内部コンポーネントによって処理されます。そのため、レジストリーサービス自体が使用する証明書を置き換える必要はありません。
ただし、デフォルトでは、レジストリーは、外部のシステムとユーザーがイメージのプルとプッシュを実行できるルートを使用します。内部の自己署名証明書を使用する代わりに、外部ユーザーに提供されるカスタム証明書を使用してre-encrypt ルートを使用することができます。
これを設定するには、以下のコード行を Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts ファイル) の [OSEv3:vars] セクションに追加します。レジストリールートで使用する証明書を指定します。
openshift_hosted_registry_routehost=registry.apps.c1-ocp.myorg.com
openshift_hosted_registry_routecertificates={"certfile": "/path/to/registry.apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/registry.apps.c1-ocp.myorg.com.key", "cafile": "/path/to/registry.apps.c1-ocp.myorg.com-ca.crt"}
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routehost=registry.apps.c1-ocp.myorg.com
openshift_hosted_registry_routecertificates={"certfile": "/path/to/registry.apps.c1-ocp.myorg.com.crt", "keyfile": "/path/to/registry.apps.c1-ocp.myorg.com.key", "cafile": "/path/to/registry.apps.c1-ocp.myorg.com-ca.crt"}
openshift_hosted_registry_routetermination=reencrypt - 1
- レジストリーのホスト名です。
- 2
- cacert、root、および cafile ファイルの場所です。
- certfile は、OpenShift Container Platform ルーター証明書を含むファイルへのパスです。
- keyfile は、OpenShift Container Platform ワイルドカードキーを含むファイルへのパスです。
- cafile は、このキーと証明書のルート CA を含むファイルへのパスです。中間 CA を使用している場合は、中間 CA とルート CA の両方がこのファイルに含まれている必要があります。
- 3
- 暗号化を実行する場所を指定します。
-
edge ルーターで暗号化を終了し、送信先から提供される新規の証明書で再暗号化するには、
reencryptに設定し、re-encrypt ルートを指定します。 -
送信先で暗号化を終了するには、
passthroughに設定します。トラフィックは送信先で復号化されます。
-
edge ルーターで暗号化を終了し、送信先から提供される新規の証明書で再暗号化するには、
10.7. ロードバランサー用のカスタム証明書の設定
OpenShift Container Platform クラスターでデフォルトのロードバランサーか、またはエンタープライズレベルのロードバランサーを使用している場合、カスタム証明書の使用により、 パブリックに署名されたカスタム証明書を使って Web コンソールと API を外部で利用できるようにし、既存の内部証明書を内部のエンドポイント用に残しておくことができます。
カスタム証明書をこの方法で使用するように OpenShift Container Platform を設定するには、以下を実行します。
マスター設定ファイルの
servingInfoセクションを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記masterPublicURLおよびoauthConfig.assetPublicURL設定に関連付けられたホスト名についてのみnamedCertificatesセクションを設定します。masterURLに関連付けられたホスト名にカスタム提供証明書を使用すると、インフラストラクチャーコンポーネントが内部の masterURL ホストを使用してマスター API と通信しようとするため、TLS エラーが発生します。Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) で
openshift_master_cluster_public_hostnameパラメーターとopenshift_master_cluster_hostnameパラメーターを指定します。これらの値は異なっていなければなりません。同じ値を指定した場合、名前付き証明書が失敗します。Native HA with External LB VIPs
# Native HA with External LB VIPs openshift_master_cluster_hostname=paas.example.com1 openshift_master_cluster_public_hostname=public.paas.example.com2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
お使いのロードバランサー環境に固有の情報については、お使いのプロバイダーについての OpenShift Container Platform リファレンスアーキテクチャーと「Custom Certificate SSL Termination (Production)」を参照してください。
10.8. カスタム証明書の変更およびクラスターへの組み込み
カスタムマスター証明書とカスタムルーター証明書を変更して、既存の OpenShift Container Platform クラスターに組み込むことができます。これを行うには、Ansible インベントリーファイル (デフォルトでは /etc/ansible/hosts) を編集し、Playbook を実行します。
10.8.1. カスタムマスター証明書の変更およびクラスターへの組み込み
カスタム証明書を変更するには、以下を実行します。
-
Ansible インベントリーファイルを編集して
openshift_master_overwrite_named_certificates=trueを設定します。 openshift_master_named_certificatesパラメーターを使用して証明書へのパスを指定します。openshift_master_overwrite_named_certificates=true openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]openshift_master_overwrite_named_certificates=true openshift_master_named_certificates=[{"certfile": "/path/on/host/to/crt-file", "keyfile": "/path/on/host/to/key-file", "names": ["public-master-host.com"], "cafile": "/path/on/host/to/ca-file"}]1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- マスター API 証明書へのパスです。
以下の Playbook を実行します。
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.8.2. カスタムルーター証明書の変更およびクラスターへの組み込み
カスタムルーター証明書を変更し、これを組み込むには、以下を実行します。
-
Ansible インベントリーファイルを編集して
openshift_master_overwrite_named_certificates=trueを設定します。 openshift_hosted_router_certificateパラメーターを使用して証明書へのパスを指定します。openshift_master_overwrite_named_certificates=true openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"}openshift_master_overwrite_named_certificates=true openshift_hosted_router_certificate={"certfile": "/path/on/host/to/app-crt-file", "keyfile": "/path/on/host/to/app-key-file", "cafile": "/path/on/host/to/app-ca-file"}1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ワイルドカード API 証明書へのパスです。
以下の Playbook を実行します。
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.yml
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.9. その他のコンポーネントでのカスタム証明書の使用
ロギングやメトリクスなどのその他のコンポーネントでカスタム証明書を使用する方法については、「 Certificate Management」を参照してください。
第11章 証明書の再デプロイ
11.1. 概要
OpenShift Container Platform は、以下のコンポーネントで証明書を使用してセキュアな接続を提供します。
- マスター (API サーバーとコントローラー)
- etcd
- ノード
- レジストリー
- ルーター
インストーラーによって提供される Ansible Playbook を使用すると、クラスター証明書の有効期限を自動的にチェックできます。これらの証明書を自動的にバックアップしたり、再デプロイしたりするための Playbook も提供されます。これらの Playbook を使用すると、一般的な証明書エラーを修正できます。
証明書の再デプロイのユースケースとして以下が考えられます。
- インストーラーによって誤ったホスト名が検出され、そのことがすぐに判明しなかった。
- 証明書の有効期限が切れており、証明書を更新する必要がある。
- 新しい CA があり、その CA を代わりに使用する証明書を作成する。
11.2. 証明書の有効期限のチェック
インストーラーを使用して、設定可能な日数内に有効期限が切れる証明書に関する警告やすでに有効期限が切れた証明書に関する通知を受け取ることができます。証明書の有効期限 Playbook では、Ansible の openshift_certificate_expiry ロールが使用されます。
ロールによって検査される証明書には、以下が含まれます。
- マスターおよびノードサービス証明書
- etcd シークレットのルーターおよびレジストリーサービス証明書
- マスター、ノード、ルーター、レジストリー、および cluster-admin ユーザーの kubeconfig ファイル
- etcd 証明書 (組み込み証明書を含む)
11.2.1. ロールの変数
openshift_certificate_expiry ロールは、以下の変数を使用します。
| 変数名 | デフォルト値 | 説明 |
|---|---|---|
|
|
|
OpenShift Container Platform 基本設定ディレクトリーです。 |
|
|
|
現在を起点として指定された日数内に有効期限が切れる証明書にフラグを付けます。 |
|
|
|
正常な (期限切れや警告のない) 証明書を結果に組み込みます。 |
| 変数名 | デフォルト値 | 説明 |
|---|---|---|
|
|
|
有効期限切れのチェック結果に関する HTML レポートを生成します。 |
|
|
|
HTML レポートを保存するための完全パスです。 |
|
|
|
有効期限のチェック結果を JSON ファイルとして保存します。 |
|
|
|
JSON レポートを保存するための完全パスです。 |
11.2.2. 証明書の有効期限 Playbook の実行
OpenShift Container Platform インストーラーは、openshift_certificate_expiry ロールのさまざまな設定セットを使用して証明書の有効期限 Playbook のサンプル一式を提供します。
これらの Playbook は、クラスターを表す インベントリーファイルと一緒に使用する必要があります。最適な結果を得るには、ansible-playbook に -v オプションを指定して実行します。
easy-mode.yaml のサンプル Playbook を使用すると、ロールアウトを仕様に合わせて調整する前に試すことができます。この Playbook は以下を実行します。
- JSON レポートと定型化された HTML レポートを /tmp/ に生成します。
- ほぼ常に結果が得られるように警告期間を長い期間に設定します。
- すべての証明書 (正常であるかどうかを問わず) を結果に組み込みます。
easy-mode.yaml Playbook
easy-mode.yaml Playbook を実行するには、以下を実行します。
ansible-playbook -v -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/easy-mode.yaml
$ ansible-playbook -v -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/easy-mode.yaml他のサンプル Playbook
その他のサンプル Playbook も /usr/share/ansible/openshift-ansible/playbooks/certificate_expiry/ ディレクトリーから直接実行できます。
| ファイル名 | 使用法 |
|---|---|
|
default.yaml |
|
|
html_and_json_default_paths.yaml |
HTML および JSON アーティファクトをデフォルトのパスに生成します。 |
|
longer_warning_period.yaml |
有効期限切れの警告期間を 1500 日に変更します。 |
|
longer-warning-period-json-results.yaml |
有効期限切れの警告期間を 1500 日に変更し、結果を JSON ファイルとして保存します。 |
これらのサンプル Playbook を実行するには、以下を実行します。
ansible-playbook -v -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/<playbook>
$ ansible-playbook -v -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/<playbook>11.2.3. 出力形式
上述のように、チェックレポートは 2 つの形式で出力できます。機械の解析に適した JSON 形式と簡単にスキミングできる定型化された HTML ページを使用できます。
HTML レポート
インストーラーには、HTML レポートのサンプルが付属しています。以下のファイルをブラウザーで開いて表示できます。
/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.html
JSON レポート
保存された JSON の結果には、data と summary の 2 つの最上位レベルのキーがあります。
data キーは、検証された各ホストの名前がキーとして、該当するホストごとに特定された証明書の確認結果が値として含まれるハッシュです。
summary キーは、以下の条件に当てはまる証明書の合計数をまとめたハッシュです。
- クラスター全体で検査済み
- 問題なし
- 設定された警告期間内に有効期限が切れる
- すでに有効期限が切れている
完全な JSON レポートのサンプルについては、/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.json を参照してください。
JSON データのサマリーでは、さまざまなコマンドラインツールを使用して警告や有効期限を簡単にチェックできます。たとえば、grep を使用して summary という語を検索し、一致した箇所の後ろの 2 行を出力できます (-A2)。
grep -A2 summary /tmp/cert-expiry-report.json
$ grep -A2 summary /tmp/cert-expiry-report.json
"summary": {
"warning": 16,
"expired": 0
また、jq ツールが使用可能な場合は、このツールを使用して特定の値を選択できます。以下の最初の 2 つの例は、warning または expired のいずれかの値を選択する方法を示しています。3 つ目の例は、両方の値を一度に選択する方法を示しています。
11.3. 証明書の再デプロイ
該当するすべてのホストにマスター、etcd、ノード、レジストリーまたはルーター証明書を再デプロイするには、以下の Playbook を使用します。現在の CA を使用してこれらすべての証明書を一度に再デプロイすることも、特定のコンポーネント用の証明書のみを再デプロイすることも、新しく生成された CA またはカスタム CA 自体を再デプロイすることもできます。
証明書の有効期限 Playbook と同様に、これらの Playbook はクラスターを表すインベントリーファイルを使用して実行する必要があります。
とくにインベントリーでは、すべてのホスト名と IP アドレスが現在のクラスター設定に一致するように、以下の変数でそれらを指定するか、または上書きする必要があります。
-
openshift_hostname -
openshift_public_hostname -
openshift_ip -
openshift_public_ip -
openshift_master_cluster_hostname -
openshift_master_cluster_public_hostname
以下のコマンドを実行すると、必要な Playbook が利用できるようになります。
yum install atomic-openshift-utils
# yum install atomic-openshift-utils再デプロイ中に自動生成された証明書の有効性 (有効期限が切れるまでの日数) も Ansible で設定できます。「証明書の有効性の設定」を参照してください。
OpenShift Container Platform CA および etcd 証明書の有効期限は 5 年です。署名付きの OpenShift Container Platform 証明書の有効期限は 2 年です。
11.3.1. 現行の OpenShift Container Platform および etcd CA を使用したすべての証明書の再デプロイ
redeploy-certificates.yml Playbook は、OpenShift Container Platform CA 証明書を再生成しません。新しいマスター 、etcd、ノード、レジストリー、およびルーター証明書は、新規の証明書に署名するために現在の CA 証明書を使用して作成されます。
これには、以下の順次の再起動も伴います。
- etcd
- マスターサービス
- ノードサービス
現行の OpenShift Container Platform CA を使用してマスター、etcd、およびノード証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
$ ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml11.3.2. 新規またはカスタムの OpenShift Container Platform CA の再デプロイ
openshift-master/redeploy-openshift-ca.yml Playbook は、新規の CA 証明書を生成し、クライアントの kubeconfig ファイルとノードの信頼できる CA のデータベース (CA-trust) を含むすべてのコンポーネントに更新されたバンドルを配布することによって OpenShift Container Platform CA 証明書を再デプロイします。
これには、以下の順次の再起動も伴います。
- マスターサービス
- ノードサービス
- Docker
さらに、証明書を再デプロイする際には、OpenShift Container Platform によって生成される CA を使用する代わりに、カスタム CA 証明書を指定することもできます。
マスターサービスが再起動すると、レジストリーとルーターは、再デプロイされなくてもマスターと引き続き通信できます。これは、マスターの提供証明書が同一であり、レジストリーとルーターの CA が依然として有効であるためです。
新たに生成される CA またはカスタム CA を再デプロイするには、以下を実行します。
オプションで、カスタム CA を指定します。カスタム CA パラメーター
openshift_master_ca_certificateの一部として指定するcertfileには、OpenShift Container Platform 証明書に署名する単一証明書のみが含まれる必要があります。チェーンに中間証明書が含まれる場合、それらを別のファイルにバンドルする必要があります。中間証明書なしで CA を指定するには、インベントリーファイルに以下の変数を指定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 中間 CA によって発行された CA 証明書を指定するには、以下を実行します。
CA の中間およびルート証明書の詳細チェーンが含まれるバンドルされた証明書を作成します。
cat intermediate/certs/<intermediate.cert.pem> \ certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pem certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pem# cat intermediate/certs/<intermediate.cert.pem> \ certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の変数をインベントリーファイルに設定します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
openshift-master/redeploy-openshift-ca.yml Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-openshift-ca.yml$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-openshift-ca.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
新規の OpenShift Container Platform CA が導入されている場合、新規の CA によって署名された証明書をすべてのコンポーネントに再デプロイする必要がある場合にはいつでも openshift-master/redeploy-certificates.yml Playbook を使用できます。
11.3.3. 新規 etcd CA の再デプロイ
openshift-etcd/redeploy-ca.yml Playbook は、新規 CA 証明書を生成し、すべての etcd ピアとマスタークライアントに更新したバンドルを配布することによって etcd CA 証明書を再デプロイします。
これには、以下の順次の再起動も伴います。
- etcd
- マスターサービス
新たに生成された etcd CA を再デプロイするには、以下を実行します。
openshift-etcd/redeploy-ca.yml Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-ca.yml$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-ca.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
新規 etcd CA が導入されている場合、新規 CA によって署名された証明書を etcd ピアとマスタークライアントに再デプロイする必要がある場合にはいつでも openshift-etcd/redeploy-certificates.yml Playbook を使用できます。または、redeploy-certificates.yml Playbook を使用して、etcd ピアとマスタークライアントに加えて、OpenShift Container Platform コンポーネントの証明書も再デプロイできます。
11.3.4. マスター証明書のみの再デプロイ
openshift-master/redeploy-certificates.yml Playbook は、マスター証明書のみを再デプロイします。これには、マスターサービスの順次の再起動も伴います。
マスター証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-certificates.yml
$ ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-certificates.ymlこの Playbook を実行した後に、サービス提供証明書を含む既存のシークレットを削除するか、またはアノテーションを削除し、適切なサービスに再度追加して、サービス提供証明書またはキーペアを再生成する必要があります。
11.3.5. etcd 証明書のみの再デプロイ
openshift-etcd/redeploy-certificates.yml Playbook は、マスタークライアント証明書を含む etcd 証明書のみを再デプロイします。
これには、以下の順次の再起動も伴います。
- etcd
- マスターサービス
etcd 証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-certificates.yml
$ ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-certificates.yml11.3.6. ノード証明書のみの再デプロイ
openshift-node/redeploy-certificates.yml Playbook は、ノード証明書のみを再デプロイします。これには、ノードサービスの順次の再起動も伴います。
ノード証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します
ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-node/redeploy-certificates.yml
$ ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-node/redeploy-certificates.yml11.3.7. レジストリー証明書またはルーター証明書のみの再デプロイ
openshift-hosted/redeploy-registry-certificates.yml Playbook と openshift-hosted/redeploy-router-certificates.yml Playbook は、インストーラーによって作成されたレジストリー証明書とルーター証明書を置き換えます。レジストリーとルーターでカスタム証明書が使用されている場合にそれらを手動で置き換えるには、「 カスタムのレジストリー証明書またはルーター証明書の再デプロイ」を参照してください。
11.3.7.1. レジストリー証明書のみの再デプロイ
レジストリー証明書を再デプロイするには、以下の Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-registry-certificates.yml
$ ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-registry-certificates.yml11.3.7.2. ルーター証明書のみの再デプロイ
ルーター証明書を再デプロイするには、以下の Playbook を実行し、インベントリーファイルを指定します。
ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.yml
$ ansible-playbook -i <inventory_file> \
/usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.yml11.3.8. カスタムのレジストリー証明書またはルーター証明書の再デプロイ
再デプロイされた CA が原因でノードが退避させられると、レジストリー Pod とルーター Pod が再起動されます。レジストリー証明書とルーター証明書を新規 CA と共に再デプロイしなかった場合は、それらが古い証明書を使用してマスターにアクセスできなくなるため、停止状態が生じることがあります。
証明書を再デプロイする Playbook は、カスタムのレジストリー証明書またはルーター証明書を再デプロイできません。この問題を解決するため、レジストリー証明書とルーター証明書を手動で再デプロイする必要があります。
11.3.8.1. 手動によるレジストリー証明書の再デプロイ
レジストリー証明書を手動で再デプロイするには、新規レジストリー証明書を registry-certificates という名前のシークレットに追加してから、レジストリーを再デプロイする必要があります。
これ以降の手順では
defaultプロジェクトに切り替えます。oc project default
$ oc project defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 最初にレジストリーを OpenShift Container Platform 3.1 以前で作成した場合は、環境変数が証明書を保存するために使用されている場合があります (この方法は現在は推奨されていません。代わりにシークレットをご使用ください)。
以下のコマンドを実行し、
OPENSHIFT_CA_DATA、OPENSHIFT_CERT_DATA、およびOPENSHIFT_KEY_DATA環境変数を探します。oc env dc/docker-registry --list
$ oc env dc/docker-registry --listCopy to Clipboard Copied! Toggle word wrap Toggle overflow これらの環境変数が存在しない場合は、この手順を省略します。存在する場合は、以下の
ClusterRoleBindingを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、以下のコマンドを実行して環境変数を削除します。
oc env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
$ oc env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下の環境変数をローカルに設定し、後で使用するコマンドを単純化します。
REGISTRY_IP=`oc get service docker-registry -o jsonpath='{.spec.clusterIP}'` REGISTRY_HOSTNAME=`oc get route/docker-registry -o jsonpath='{.spec.host}'`$ REGISTRY_IP=`oc get service docker-registry -o jsonpath='{.spec.clusterIP}'` $ REGISTRY_HOSTNAME=`oc get route/docker-registry -o jsonpath='{.spec.host}'`Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規レジストリー証明書を作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから
oc admコマンドを実行します。registry-certificatesシークレットを新規レジストリー証明書で更新します。oc create secret generic registry-certificates \ --from-file=/etc/origin/master/registry.crt,/etc/origin/master/registry.key \ -o json --dry-run | oc replace -f -$ oc create secret generic registry-certificates \ --from-file=/etc/origin/master/registry.crt,/etc/origin/master/registry.key \ -o json --dry-run | oc replace -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow レジストリーを再デプロイします。
oc rollout latest dc/docker-registry
$ oc rollout latest dc/docker-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.3.8.2. 手動によるルーター証明書の再デプロイ
ルーターの初回デプロイ時に、アノテーションがサービス提供証明書シークレットを自動的に作成するルーターのサービスに追加されます。
ルーター証明書を手動で再デプロイするため、そのサービス提供証明書の再作成をトリガーできます。これは、シークレットを削除し、アノテーションを削除してから router サービスに再度追加し、ルーターを再デプロイして実行できます。
これ以降の手順では
defaultプロジェクトに切り替えます。oc project default
$ oc project defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 最初にレジストリーを OpenShift Container Platform 3.1 以前で作成した場合は、環境変数が証明書を保存するために使用されている場合があります (この方法は現在は推奨されていません。代わりにサービス提供証明書シークレットをご使用ください)。
以下のコマンドを実行し、
OPENSHIFT_CA_DATA、OPENSHIFT_CERT_DATA、およびOPENSHIFT_KEY_DATA環境変数を探します。oc env dc/router --list
$ oc env dc/router --listCopy to Clipboard Copied! Toggle word wrap Toggle overflow それらの変数が存在する場合は、以下の
ClusterRoleBindingを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow それらの変数が存在する場合は、以下のコマンドを実行してそれらを削除します。
oc env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
$ oc env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-Copy to Clipboard Copied! Toggle word wrap Toggle overflow
証明書を取得します。
- 外部の認証局 (CA) を使用して証明書に署名する場合、以下の内部プロセスに従って、新規の証明書を作成し、これを OpenShift Container Platform に指定します。
内部 OpenShift Container Platform CA を使用して証明書に署名する場合は、以下のコマンドを実行します。
重要以下のコマンドは、内部で署名される証明書を生成します。これは、OpenShift Container Platform CA を信頼するクライアントによってのみ信頼されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これらのコマンドは以下のファイルを生成します。
- router.crt という名前の新規の証明書
- 署名する CA 証明書チェーン /etc/origin/master/ca.crt のコピーです。このチェーンには中間の CA を使用する場合に複数の証明書が含まれる場合があります。
- router.key という名前の対応するプライベートキー。
生成された証明書を連結する新規ファイルを作成します。
cat router.crt /etc/origin/master/ca.crt router.key > router.pem
$ cat router.crt /etc/origin/master/ca.crt router.key > router.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規シークレットを生成する前に、現在のシークレットをバックアップします。
oc export secret router-certs > ~/old-router-certs-secret.yaml
$ oc export secret router-certs > ~/old-router-certs-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規の証明書およびキーを保持する新規シークレットを作成し、既存のシークレットの内容を置き換えます。
oc create secret tls router-certs --cert=router.pem \ --key=router.key -o json --dry-run | \ oc replace -f -$ oc create secret tls router-certs --cert=router.pem \1 --key=router.key -o json --dry-run | \ oc replace -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- router.pem は、生成した証明書の連結を含むファイルです。
以下のアノテーションを
routerサービスから削除します。oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name- \ service.alpha.openshift.io/serving-cert-signed-by-$ oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name- \ service.alpha.openshift.io/serving-cert-signed-by-Copy to Clipboard Copied! Toggle word wrap Toggle overflow アノテーションを再度追加します。
oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name=router-certs$ oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name=router-certsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ルーターを再デプロイします。
oc rollout latest dc/router
$ oc rollout latest dc/routerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第12章 認証およびユーザーエージェントの設定
12.1. 概要
OpenShift Container Platform マスターには、OAuth サーバーがビルトインされています。開発者と管理者は、API に対する認証を実行するために OAuth アクセストークンを取得します。
管理者はマスター設定ファイルを使用して OAuth を アイデンティティープロバイダーを指定するように設定できます。アイデンティティープロバイダーは、通常インストール (advanced installation) の実行中に設定するのが最適ですが、インストール後に設定することもできます。
/、:、および % を含む OpenShift Container Platform ユーザー名はサポートされません。
クイックインストールまたは通常インストール (Advanced installation) 方式を使用して OpenShift Container Platform をインストールした場合、Deny All アイデンティティープロバイダーがデフォルトで使用されます。このアイデンティティープロバイダーは、すべてのユーザー名とパスワードについてアクセスを拒否します。アクセスを許可するには、別のアイデンティティープロバイダーを選択し、マスター設定ファイル (デフォルトでは、/etc/origin/master/master-config.yamlにあります) を適宜設定する必要があります。
設定ファイルなしでマスターを実行する場合は、Allow All アイデンティティープロバイダーがデフォルトで使用されます。このアイデンティティープロバイダーは、空でないユーザー名とパスワードによるログインをすべて許可します。これはテストを行う場合に便利です。その他のアイデンティティープロバイダーを使用するか、token、grant、または session オプション を変更する場合は、設定ファイルからマスターを実行する必要があります。
外部ユーザーのセットアップを管理するためのロールが割り当てられている必要があります。
アイデンティティープロバイダーに変更を加えたら、変更を有効にするためにマスターサービスを再起動する必要があります。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers12.2. アイデンティティープロバイダーパラメーター
すべてのアイデンティティープロバイダーには共通する 4 つのパラメーターがあります。
| パラメーター | 説明 |
|---|---|
|
|
プロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。 |
|
|
true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、
ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは |
|
|
true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。これはすべてのアイデンティティープロバイダーによってサポートされている訳ではありません。
ユーザーがアイデンティティープロバイダーのログインにリダイレクトされる前にブランドページに移動するようにする場合、マスター設定ファイルで |
|
|
新規アイデンティティーがログイン時にユーザーにマップされる方法を定義します。以下の値のいずれかを入力します。
|
mappingMethod パラメーターを add に設定すると、アイデンティティープロバイダーの追加または変更時に新規プロバイダーのアイデンティティーを既存ユーザーにマッピングできます。
12.3. アイデンティティープロバイダーの設定
OpenShift Container Platform は単一のアイデンティティープロバイダーの設定のみをサポートします。ただし、LDAP フェイルオーバーなどのより複雑な設定の基本認証を拡張することが可能です。
これらのパラメーターを使用して、インストール時またはインストール後にアイデンティティープロバイダーを定義できます。
12.3.1. Ansible を使用したアイデンティティープロバイダーの設定
初回の 通常インストール (Advanced installation) では、Deny All アイデンティティープロバイダーがデフォルトで設定されます。ただし、これは、インベントリーファイルで設定可能な openshift_master_identity_providers パラメーターを使用してインストール時に上書きすることができます。OAuth 設定のセッションオプションもインベントリーファイルで設定できます。
例12.1 Ansible を使用したアイデンティティープロバイダー設定の例
- 1
openshift_master_identity_providersパラメーターに CA 証明書の場所を指定する場合、証明書の値をopenshift_master_ldap_caパラメーターに指定したり、パスをopenshift_master_ldap_ca_fileパラメーターに使用したりしないようにしてください。
12.3.2. マスター設定ファイルでのアイデンティティープロバイダーの設定
マスター設定ファイルを変更することで、必要なアイデンティティープロバイダーを使用してマスターホストで認証を設定できます。
例12.2 マスター設定ファイルでのアイデンティティープロバイダーの設定例
デフォルトの claim 値に設定されている場合、アイデンティティーを以前に存在していたユーザー名にマッピングすると OAuth が失敗します。
12.3.3. アイデンティティープロバイダーまたはメソッドの設定
12.3.3.1. lookup マッピング方法を使用する場合のユーザーの手動プロビジョニング
lookup マッピング方法を使用する場合、ユーザープロビジョニングは外部システムによって API 経由で行われます。通常、アイデンティティーは、ログイン時にユーザーに自動的にマッピングされます。「 lookup」マッピング方法は、この自動マッピングを自動的に無効にします。そのため、ユーザーを手動でプロビジョニングする必要があります。
identity オブジェクトの詳細については、Identity ユーザー API オブジェクトを参照してください。
lookup マッピング方法を使用する場合は、アイデンティティープロバイダーを設定した後にユーザーごとに以下の手順を使用してください。
OpenShift Container Platform ユーザーを作成します (まだ作成していない場合)。
oc create user <username>
$ oc create user <username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下のコマンドを実行して OpenShift Container Platform ユーザー
bobを作成します。oc create user bob
$ oc create user bobCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform アイデンティティーを作成します (まだ作成していない場合)。アイデンティティープロバイダーの名前と、アイデンティティープロバイダーの範囲でこのアイデンティティーを一意に表す名前を使用します。
oc create identity <identity-provider>:<user-id-from-identity-provider>
$ oc create identity <identity-provider>:<user-id-from-identity-provider>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <identity-provider>は、マスター設定のアイデンティティープロバイダーの名前であり、以下の該当するアイデンティティープロバイダーセクションに表示されています。たとえば、以下のコマンドを実行すると、アイデンティティープロバイダーが
ldap_provider、アイデンティティープロバイダーのユーザー名がbob_sのアイデンティティーが作成されます。oc create identity ldap_provider:bob_s
$ oc create identity ldap_provider:bob_sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 作成したユーザーとアイデンティティーのユーザー/アイデンティティーマッピングを作成します。
oc create useridentitymapping <identity-provider>:<user-id-from-identity-provider> <username>
$ oc create useridentitymapping <identity-provider>:<user-id-from-identity-provider> <username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、以下のコマンドを実行すると、アイデンティティーがユーザーにマッピングされます。
oc create useridentitymapping ldap_provider:bob_s bob
$ oc create useridentitymapping ldap_provider:bob_s bobCopy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3.4. Allow All
空でないユーザー名とパスワードによるログインを許可するには、 identityProviders スタンザに AllowAllPasswordIdentityProvider を設定します。
例12.3 AllowAllPasswordIdentityProvider を使用したマスター設定
- 1
- このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
12.3.5. Deny All
すべてのユーザー名とパスワードについてアクセスを拒否するには、 identityProviders スタンザに DenyAllPasswordIdentityProvider を設定します。
例12.4 DenyAllPasswordIdentityProvider を使用したマスター設定
- 1
- このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
12.3.6. HTPasswd
ユーザー名およびパスワードを htpasswd を使用して生成されたフラットファイルに対して検証するには、identityProviders スタンザに HTPasswdPasswordIdentityProvider を設定します。
htpasswd ユーティリティーは httpd-tools パッケージにあります。
yum install httpd-tools
# yum install httpd-tools
OpenShift Container Platform では、 Bcrypt、SHA-1、および MD5 暗号化ハッシュ関数がサポートされ、MD5 は htpasswd のデフォルトです。プレーンテキスト、暗号化テキスト、およびその他のハッシュ関数は、現時点ではサポートされていません。
フラットファイルは、その変更時間が変わると再度読み取られます。サーバーの再起動は必要ありません。
htpasswd コマンドを使用するには、以下の手順を実行します。
ユーザー名とハッシュされたパスワードを含むフラットファイルを作成するには、以下を実行します。
htpasswd -c </path/to/users.htpasswd> <user_name>
$ htpasswd -c </path/to/users.htpasswd> <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、ユーザーのクリアテキストのパスワードを入力し、確認します。コマンドにより、ハッシュされたバージョンのパスワードが生成されます。
例を以下に示します。
htpasswd -c users.htpasswd user1 New password: Re-type new password: Adding password for user user1
htpasswd -c users.htpasswd user1 New password: Re-type new password: Adding password for user user1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記-bオプションを追加すると、パスワードをコマンドラインに指定できます。htpasswd -c -b <user_name> <password>
$ htpasswd -c -b <user_name> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
htpasswd -c -b file user1 MyPassword!
$ htpasswd -c -b file user1 MyPassword! Adding password for user user1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ファイルにログインを追加するか、ログインを更新するには、以下のコマンドを実行します。
htpasswd </path/to/users.htpasswd> <user_name>
$ htpasswd </path/to/users.htpasswd> <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルからログインを削除するには、以下のコマンドを実行します。
htpasswd -D </path/to/users.htpasswd> <user_name>
$ htpasswd -D </path/to/users.htpasswd> <user_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例12.5 HTPasswdPasswordIdentityProvider を使用したマスター設定
- 1
- このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
htpasswdを使用して生成されたファイルです。
12.3.7. Keystone
Keystone は、アイデンティティー、トークン、カタログ、およびポリシーサービスを提供する OpenStack プロジェクトです。OpenShift Container Platform クラスターと Keystone を統合すると、内部データベースにユーザーを格納するように設定された OpenStack Keystone v3 サーバーによる共有認証を有効にできます。この設定を完了すると、ユーザーは Keystone 認証情報を使用して OpenShift Container Platform にログインできるようになります。
12.3.7.1. マスターでの認証の設定
状況に応じて以下のいずれかの手順を実行します。
Openshift のインストールがすでに完了している場合は、/etc/origin/master/master-config.yaml ファイルを新規ディレクトリーにコピーします。以下は例になります。
cd /etc/origin/master mkdir keystoneconfig; cp master-config.yaml keystoneconfig
$ cd /etc/origin/master $ mkdir keystoneconfig; cp master-config.yaml keystoneconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform をまだインストールしていない場合は、OpenShift Container Platform API サーバーを起動し、(将来の) OpenShift Container Platform マスターのホスト名と、起動コマンドによって作成された設定ファイルを格納するディレクトリーを指定します。
openshift start master --public-master=<apiserver> --write-config=<directory>
$ openshift start master --public-master=<apiserver> --write-config=<directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
openshift start master --public-master=https://myapiserver.com:8443 --write-config=keystoneconfig
$ openshift start master --public-master=https://myapiserver.com:8443 --write-config=keystoneconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Ansible を使用してインストールする場合は、
identityProvider設定を Ansible Playbook に追加する必要があります。Ansible を使用してインストールした後、以下の手順に従って設定を手動で変更した場合、インストールツールまたはアップグレードを再実行するたびに変更内容がすべて失われます。
新規の keystoneconfig/master-config.yaml ファイルの
identityProvidersスタンザを編集し、KeystonePasswordIdentityProviderの設定例をコピーして貼り付け、既存のスタンザを置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このプロバイダー名は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- Keystone のドメイン名です。Keystone では、ユーザー名はドメイン固有です。単一ドメインのみがサポートされます。
- 6
- Keystone サーバーへの接続に使用する URL (必須) です。
- 7
- オプション: 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。
- 8
- オプション: 設定された URL に対して要求を実行する際に提示するクライアント証明書です。
- 9
- クライアント証明書のキーです。
certFileが指定されている場合は必須です。
以下の変更を
identityProvidersスタンザに加えます。-
プロバイダーの
name(「my_keystone_provider」) を、使用する Keystone サーバーに合わせて変更します。この名前は、プロバイダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。 -
必要な場合、
mappingMethodを変更して、プロバイダーのアイデンティティーとユーザーオブジェクト間でマッピングを確立する方法を制御します。 -
domainNameを OpenStack Keystone サーバーのドメイン名に変更します。Keystone では、ユーザー名はドメイン固有です。単一ドメインのみがサポートされます。 -
OpenStack Keystone への接続に使用する
urlを指定します。 -
オプションで、設定された URL のサーバー証明書を検証できるように
caを使用する証明書バンドルに変更します。 -
オプションで、
certFileを、設定された URL に対する要求の実行時に提示するクライアント証明書に変更します。 -
certFileが指定されている場合は、keyFileをクライアント証明書のキーに変更する必要があります。
-
プロバイダーの
- 変更を保存してファイルを閉じます。
OpenShift Container Platform API サーバーを起動し、変更したばかりの設定ファイルを指定します。
openshift start master --config=<path/to/modified/config>/master-config.yaml
$ openshift start master --config=<path/to/modified/config>/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
設定が完了すると、OpenShift Container Platform Web コンソールにログインするすべてのユーザーに Keystone 認証情報を使用してログインすることを求めるプロンプトが出されます。
12.3.7.2. Keystone 認証を使用するユーザーの作成
外部認証プロバイダー (この場合は Keystone) と統合する場合、OpenShift Container Platform にはユーザーを作成しません。Keystone は「system of record」であり、ユーザーは Keystone データベースで定義され、設定された認証サーバーに対する有効な Keystone ユーザー名を持つ任意のユーザーがログインできます。
ユーザーを OpenShift Container Platform に追加するには、そのユーザーが Keystone データベースに存在している必要があります。また、必要な場合はそのユーザーの新しい Keystone アカウントを作成する必要があります。
12.3.7.3. ユーザーの確認
1 名以上のユーザーがログインしたら、oc get users を実行してユーザーの一覧を表示し、ユーザーが正しく作成されていることを確認できます。
例12.6 oc get users コマンドの出力
oc get users
$ oc get users
NAME UID FULL NAME IDENTITIES
bobsmith a0c1d95c-1cb5-11e6-a04a-002186a28631 Bob Smith keystone:bobsmith - 1
- OpenShift Container Platform のアイデンティティーは、Keystone ユーザー名とそれにプレフィックスとして付加されるアイデンティティープロバイダー名で構成されます。
ここからは、ユーザーロールの管理方法を学習することをお勧めします。
12.3.8. LDAP 認証
単純なバインド認証を使用してユーザー名とパスワードを LDAPv3 サーバーに対して検証するには、identityProviders スタンザに LDAPPasswordIdentityProvider を設定します。
これらの手順に従う代わりに LDAP サーバーのファイルオーバーを要求する場合には、LDAP フェイルオーバーに SSSD を設定して基本認証メソッドを拡張します。
認証時に、指定されたユーザー名に一致するエントリーが LDAP ディレクトリーで検索されます。単一の一意な一致が見つかった場合、エントリーの識別名 (DN) と指定されたパスワードを使用した単純なバインドが試みられます。
以下の手順が実行されます。
-
設定された
urlの属性およびフィルターとユーザーが指定したユーザー名を組み合わせて検索フィルターを生成します。 - 生成されたフィルターを使用してディレクトリーを検索します。検索によって 1 つもエントリーが返されない場合は、アクセスを拒否します。
- 検索で取得したエントリーの DN とユーザー指定のパスワードを使用して LDAP サーバーへのバインドを試みます。
- バインドが失敗した場合は、アクセスを拒否します。
- バインドが成功した場合は、アイデンティティー、電子メールアドレス、表示名、および推奨ユーザー名として設定された属性を使用してアイデンティティーを作成します。
設定される url は、LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です。URL の構文は以下のようになります。
ldap://host:port/basedn?attribute?scope?filter
ldap://host:port/basedn?attribute?scope?filter上記の例は、以下のコンポーネントで構成されています。
| URL コンポーネント | 説明 |
|---|---|
|
|
通常の LDAP の場合は、文字列 |
|
|
LDAP サーバーの名前とポートで。デフォルトは、ldap の場合は |
|
|
すべての検索が開始されるディレクトリーのブランチの DN です。これは少なくともディレクトリーツリーの最上位になければなりませんが、ディレクトリーのサブツリーを指定することもできます。 |
|
|
検索対象の属性です。RFC 2255 はカンマ区切りの属性の一覧を許可しますが、属性をどれだけ指定しても最初の属性のみが使用されます。属性を指定しない場合は、デフォルトで |
|
|
検索の範囲です。 |
|
|
有効な LDAP 検索フィルターです。指定しない場合、デフォルトは |
検索の実行時に属性、フィルター、指定したユーザー名が組み合わされて以下のような検索フィルターが作成されます。
(&(<filter>)(<attribute>=<username>))
(&(<filter>)(<attribute>=<username>))たとえば、以下の URL について見てみましょう。
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
ldap://ldap.example.com/o=Acme?cn?sub?(enabled=true)
クライアントが bob というユーザー名を使用して接続を試みる場合、生成される検索フィルターは (&(enabled=true)(cn=bob)) になります。
LDAP ディレクトリーの検索に認証が必要な場合は、エントリー検索の実行に使用する bindDN と bindPassword を指定します。
LDAPPasswordIdentityProvider を使用したマスターの設定
- 1
- このプロバイダー名は返されるユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- アイデンティティーとして使用する属性の一覧です。最初の空でない属性が使用されます。少なくとも 1 つの属性が必要です。一覧表示される属性のいずれにも値がない場合、認証は失敗します。
- 6
- メールアドレスとして使用する属性の一覧です。最初の空でない属性が使用されます。
- 7
- 表示名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 8
- このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用する属性の一覧です。最初の空でない属性が使用されます。
- 9
- 検索フェーズでバインドするために使用するオプションの DN です。
- 10
- 検索フェーズでバインドするために使用するオプションのパスワードです。この値は、環境変数、外部ファイル、または暗号化ファイルで指定することもできます。
- 11
- 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。空の場合、システムで信頼されたルートが使用されます。これは insecure: false の場合にのみ適用されます。
- 12
- true の場合、サーバーへの TLS 接続は確立されません。false の場合、
ldaps://URL は TLS を使用して接続し、ldap://URL は TLS にアップグレードされます。 - 13
- LDAP ホストと使用する検索パラメーターを指定する RFC 2255 URL です (上記を参照してください)。
LDAP 統合のためのユーザーのホワイトリストを作成するには、lookup マッピング方法を使用します。LDAP からのログインが許可される前に、クラスター管理者は各 LDAP ユーザーのアイデンティティーとユーザーオブジェクトを作成する必要があります。
12.3.9. Basic 認証 (リモート)
Basic 認証は、ユーザーがリモートのアイデンティティープロバイダーに対して検証した認証情報を使用して OpenShift Container Platform にログインすることを可能にする汎用バックエンド統合メカニズムです。
Basic 認証は汎用性があるため、このアイデンティティープロバイダー使用して詳細な認証設定を実行できます。詳細なリモート Basic 認証設定の開始点として、LDAP フェイルオーバーを設定したり、コンテナー化された Basic 認証リポジトリーを使用できます。
Basic 認証では、ユーザー ID とパスワードのスヌーピングを防ぎ、中間者攻撃を回避するためにリモートサーバーへの HTTPS 接続を使用する必要があります。
BasicAuthPasswordIdentityProvider を設定していると、ユーザーはユーザー名とパスワードを OpenShift Container Platform に送信し、サーバー間の要求を行い、認証情報を基本認証ヘッダーとして渡すことで、これらの認証情報をリモートサーバーに対して検証することができます。このため、ユーザーはログイン時に認証情報を OpenShift Container Platform に送信する必要があります。
これはユーザー名/パスワードログインの仕組みにのみ有効で、OpenShift Container Platform はリモート認証サーバーに対するネットワーク要求を実行できる必要があります。
identityProviders スタンザで BasicAuthPasswordIdentityProvider を設定し、サーバー間の基本認証要求を使用してユーザー名とパスワードをリモートサーバーに対して検証できるようにします。ユーザー名とパスワードは基本認証で保護されるリモート URL に対して検証され、JSON を返します。
401 応答は認証の失敗を示しています。
200 以外のステータスまたは空でない「エラー」キーはエラーを示しています。
{"error":"Error message"}
{"error":"Error message"}
sub (サブジェクト) キーを持つ 200 ステータスは、成功を示しています。
{"sub":"userid"}
{"sub":"userid"} - 1
- このサブジェクトは認証ユーザーに固有である必要があり、変更することができません。
正常な応答により、以下のような追加データがオプションで提供されることがあります。
nameキーを使用した表示名。以下は例になります。{"sub":"userid", "name": "User Name", ...}{"sub":"userid", "name": "User Name", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow emailキーを使用したメールアドレス。以下は例になります。{"sub":"userid", "email":"user@example.com", ...}{"sub":"userid", "email":"user@example.com", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow preferred_usernameキーを使用した推奨ユーザー名。これは、固有の変更できないサブジェクトがデータベースキーまたは UID であり、判読可能な名前が存在する場合に便利です。これは、認証された ID に対して OpenShift Container Platform ユーザーをプロビジョニングする場合にヒントとして使われます。以下は例を示しています。{"sub":"014fbff9a07c", "preferred_username":"bob", ...}{"sub":"014fbff9a07c", "preferred_username":"bob", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3.9.1. マスターでの認証の設定
状況に応じて以下のいずれかの手順を実行します。
Openshift のインストールがすでに完了している場合は、/etc/origin/master/master-config.yaml ファイルを新規ディレクトリーにコピーします。以下は例になります。
mkdir basicauthconfig; cp master-config.yaml basicauthconfig
$ mkdir basicauthconfig; cp master-config.yaml basicauthconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform をまだインストールしていない場合は、OpenShift Container Platform API サーバーを起動し、(将来の) OpenShift Container Platform マスターのホスト名と、起動コマンドによって作成された設定ファイルを格納するディレクトリーを指定します。
openshift start master --public-master=<apiserver> --write-config=<directory>
$ openshift start master --public-master=<apiserver> --write-config=<directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
openshift start master --public-master=https://myapiserver.com:8443 --write-config=basicauthconfig
$ openshift start master --public-master=https://myapiserver.com:8443 --write-config=basicauthconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Ansible を使用してインストールする場合は、
identityProvider設定を Ansible Playbook に追加する必要があります。Ansible を使用してインストールした後、以下の手順に従って設定を手動で変更した場合、インストールツールまたはアップグレードを再実行するたびに変更内容がすべて失われます。
新規の master-config.yaml ファイルの
identityProvidersスタンザを編集し、BasicAuthPasswordIdentityProvider設定のサンプルをコピーして貼り付け、既存のスタンザを置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このプロバイダー名は返されるユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの認証されていないトークン要求は、このプロバイダーがサポートするログインページにリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- Basic 認証ヘッダーで認証情報を受け入れる URL。
- 6
- オプション: 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。
- 7
- オプション: 設定された URL に対して要求を実行する際に提示するクライアント証明書です。
- 8
- クライアント証明書のキーです。
certFileが指定されている場合は必須です。
以下の変更を
identityProvidersスタンザに加えます。-
プロバイダーの
nameをデプロイメントに対して固有で関連するものに設定します。この名前は返されるユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。 -
必要な場合、
mappingMethodを設定して、プロバイダーのアイデンティティーとユーザーオブジェクト間でマッピングを確立する方法を制御します。 -
Basic 認証ヘッダーで認証情報を受け入れるサーバーへの接続に使用する HTTPS
urlを指定します。 -
オプションで、設定された URL のサーバー証明書を検証するために
caを使用する証明書バンドルに設定するか、またはこれを空にしてシステムで信頼されるルートを使用します。 -
オプションで、
certFileを削除するか、またはこれを設定された URL へ要求を行う時に提示するクライアント証明書に設定します。 -
certFileを指定する場合、keyFileをクライアント証明書のキーに設定する必要があります。
- 変更を保存してファイルを閉じます。
OpenShift Container Platform API サーバーを起動し、変更したばかりの設定ファイルを指定します。
openshift start master --config=<path/to/modified/config>/master-config.yaml
$ openshift start master --config=<path/to/modified/config>/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これが設定されると、OpenShift Container Platform Web コンソールにログインするユーザーには、Basic 認証の認証情報を使用してログインすることを求めるプロンプトが表示されます。
12.3.9.2. トラブルシューティング
最もよく起こる問題は、バックエンドサーバーへのネットワーク接続に関連しています。簡単なデバッグの場合は、マスターで curl コマンドを実行します。正常なログインをテストするには、以下のコマンド例の <user> と <password> を有効な認証情報に置き換えます。無効なログインをテストするには、それらを正しくない認証情報に置き換えます。
curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp
curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp正常な応答
sub (サブジェクト) キーを持つ 200 ステータスは、成功を示しています。
{"sub":"userid"}
{"sub":"userid"}サブジェクトは認証ユーザーに固有である必要があり、変更することはできません。
正常な応答により、以下のような追加データがオプションで提供されることがあります。
nameキーを使用した表示名:{"sub":"userid", "name": "User Name", ...}{"sub":"userid", "name": "User Name", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow emailキーを使用したメールアドレス:{"sub":"userid", "email":"user@example.com", ...}{"sub":"userid", "email":"user@example.com", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow preferred_usernameキーを使用した推奨ユーザー名:{"sub":"014fbff9a07c", "preferred_username":"bob", ...}{"sub":"014fbff9a07c", "preferred_username":"bob", ...}Copy to Clipboard Copied! Toggle word wrap Toggle overflow preferred_usernameキーは、固有の変更できないサブジェクトがデータベースキーまたは UID であり、判読可能な名前が存在する場合に便利です。これは、認証 ID に対して OpenShift Container Platform ユーザーをプロビジョニングする場合にヒントとして使われます。
失敗の応答
-
401応答は認証の失敗を示しています。 -
200以外のステータスまたは空でない「エラー」キーはエラーを示しています:{"error":"Error message"}
12.3.10. 要求ヘッダー
identityProviders スタンザで RequestHeaderIdentityProvider を設定して、X-Remote-User などの要求ヘッダー値からユーザーを識別します。これは通常、プロキシー認証と組み合わせて使用され、要求ヘッダー値を設定します。これは OpenShift Enterprise 2 のリモートユーザープラグイン によって管理者が Kerberos、LDAP、その他の数多くの形式のエンタープライズ認証を指定する方法と似ています。
さらに、SAML 認証などの詳細な設定に要求ヘッダーアイデンティティープロバイダーを使用できます。
ユーザーがこのアイデンティティープロバイダーを使用して認証を行うには、認証プロキシー経由で https://<master>/oauth/authorize (およびサブパス) にアクセスする必要があります。これを実行するには、OAuth トークンに対する非認証の要求を https://<master>/oauth/authorize にプロキシー処理するプロキシーエンドポイントにリダイレクトするよう OAuth サーバーを設定します。
ブラウザーベースのログインフローが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。
-
loginパラメーターを true に設定します。 -
provider.loginURLパラメーターをインタラクティブなクライアントを認証する認証プロキシー URL に設定してから、要求をhttps://<master>/oauth/authorizeにプロキシーします。
WWW-Authenticate チャレンジが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。
-
challengeパラメーターを true に設定します。 -
provider.challengeURLパラメーターをWWW-Authenticateチャレンジが想定されるクライアントを認証する認証プロキシー URL に設定し、要求をhttps://<master>/oauth/authorizeにプロキシーします。
provider.challengeURL および provider.loginURL パラメーターには、URL のクエリー部分に以下のトークンを含めることができます。
${url}は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。例:
https://www.example.com/sso-login?then=${url}${query}は最新のクエリー文字列と置き換えられ、エスケープされません。例:
https://www.example.com/auth-proxy/oauth/authorize?${query}
非認証要求が OAuth サーバーに到達することを想定する場合は、要求ヘッダーのユーザー名がチェックされる前に受信要求の有効なクライアント証明書をチェックするように、clientCA パラメーターをこのアイデンティティープロバイダーに対して設定する必要があります。これを設定しない場合、OAuth サーバーへの直接的な要求は、要求ヘッダーを設定するだけでこのプロバイダーのアイデンティティーになりすます可能性があります。
例12.7 RequestHeaderIdentityProvider を使用したマスター設定
- 1
- このプロバイダー名は要求ヘッダーのユーザー名にプレフィックスとして付加され、アイデンティティー名が作成されます。
- 2
- RequestHeaderIdentityProvider は、設定された
challengeURLにリダイレクトすることで、WWW-Authenticateチャレンジを要求するクライアントにのみ応答します。設定される URL はWWW-Authenticateチャレンジを使用して応答します。 - 3
- RequestHeaderIdentityProvider は、設定された
loginURLにリダイレクトすることで、ログインフローを要求するクライアントにのみ応答できます。設定される URL はログインフローを使用して応答します。 - 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- オプション: 非認証の
/oauth/authorize要求のリダイレクト先となる URLです。これは、ブラウザーベースのクライアントを認証し、その要求をhttps://<master>/oauth/authorizeにプロキシーします。https://<master>/oauth/authorizeにプロキシーする URL は/authorizeで終了し (末尾のスラッシュなし)、OAuth 承認フローが適切に機能するようサブパスもプロキシーします。${url}は現在の URL に置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query}は現在のクエリー文字列に置き換えられます。 - 6
- オプション: 非認証の
/oauth/authorize要求のリダイレクト先となる URL です。WWW-Authenticateチャレンジが想定されるクライアントを認証し、それらをhttps://<master>/oauth/authorizeにプロキシーします。${url}は現在の URL に置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query}は現在のクエリー文字列に置き換えられます。 - 7
- オプション: PEM でエンコードされた証明書バンドルです。これが設定されている場合、要求ヘッダーのユーザー名をチェックする前に、有効なクライアント証明書が提示され、指定ファイルで認証局に対して検証される必要があります。
- 8
- オプション: 共通名 (
cn) の一覧です。これが設定されている場合は、要求ヘッダーのユーザー名をチェックする前に指定される一覧の Common Name (cn) を持つ有効なクライアント証明書が提示される必要があります。空の場合、すべての Common Name が許可されます。これはclientCAとの組み合わせる場合にのみ使用できます。 - 9
- ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名です。値を含む最初のヘッダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。
- 10
- メールアドレスを順番にチェックする際に使用するヘッダー名です。値を含む最初のヘッダーはメールアドレスとして使用されます。これは任意であり、大文字小文字を区別します。
- 11
- 表示名を順番にチェックする際に使用するヘッダー名です。値を含む最初のヘッダーは表示名として使用されます。これは任意であり、大文字小文字を区別します。
- 12
- 推奨ユーザー名を順番にチェックする際に使用するヘッダー名です (
headersで指定されるヘッダーで決定される変更できないアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別します。
例12.8 RequestHeaderIdentityProvider を使用した Apache 認証
この例は、マスターと同じホストに認証プロキシーを設定しています。同じホストにプロキシーとマスターがあると便利ですが、ご使用中の環境に適さない場合があります。たとえば、すでにマスターでルーターを実行している場合、ポート 443 が利用できなくなります。
この参照設定は Apache の mod_auth_form を使用していますが、これは決して必須ではなく、以下の要件を満たしていれば他のプロキシーを簡単に使用することができます。
-
クライアント要求の
X-Remote-Userヘッダーをブロックして、スプーフィングを防ぎます。 - RequestHeaderIdentityProvider 設定でクライアント証明書認証を実施します。
-
チャレンジフローを使用してすべての認証要求についての
X-Csrf-Tokenヘッダーを設定する必要があります。 -
/oauth/authorizeエンドポイントとそのサブパスのみがプロキシーされる必要があります。バックエンドサーバーがクライアントを正しい場所へ送信できるようリダイレクトは書き換えないでください。 https://<master>/oauth/authorizeへプロキシーする URL は/authorizeで終了 (末尾のスラッシュなし) する必要があります。以下は例になります。-
https://proxy.example.com/login-proxy/authorize?…→https://<master>/oauth/authorize?…
-
https://<master>/oauth/authorizeにプロキシーされる URL のサブパスは、https://<master>/oauth/authorizeのサブパスにプロキシーする必要があります。以下は例になります。-
https://proxy.example.com/login-proxy/authorize/approve?…→https://<master>/oauth/authorize/approve?…
-
前提条件のインストール
mod_auth_form モジュールは Optional チャンネル にある mod_session パッケージの一部として同梱されます。
yum install -y httpd mod_ssl mod_session apr-util-openssl
# yum install -y httpd mod_ssl mod_session apr-util-openssl
信頼されたヘッダーを送信する要求を検証するために CA を生成します。この CA は マスターのアイデンティティープロバイダーの設定 の clientCA のファイル名として使用されます。
oc adm ca create-signer-cert \ --cert='/etc/origin/master/proxyca.crt' \ --key='/etc/origin/master/proxyca.key' \ --name='openshift-proxy-signer@1432232228' \ --serial='/etc/origin/master/proxyca.serial.txt'
# oc adm ca create-signer-cert \
--cert='/etc/origin/master/proxyca.crt' \
--key='/etc/origin/master/proxyca.key' \
--name='openshift-proxy-signer@1432232228' \
--serial='/etc/origin/master/proxyca.serial.txt'
oc adm ca create-signer-cert コマンドは、5 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれ以上大きくすることは推奨されません。
Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。
このプロキシー用のクライアント証明書を生成します。x509 証明書ツーリングを使用して実行することができます。oc adm CLI を使用すると便利です。
- 1
- ユーザー名は任意に指定できますが、ログにそのまま表示されるのでわかりやすい名前をつけると便利です。
- 2
- マスターと異なるホスト名で認証プロキシーを実行する場合、上記のようにデフォルトのマスター証明書を使用するのではなく、ホスト名と一致する証明書を生成することが重要です。/etc/origin/master/master-config.yaml ファイルの
masterPublicURLの値は、SSLCertificateFileに対して指定される証明書のX509v3 Subject Alternative Nameに含まれる必要があります。新規の証明書を作成する必要がある場合は、oc adm ca create-server-certコマンドを使用できます。
oc adm create-api-client-config コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれ以上大きくすることは推奨されません。Ansible ホストインベントリーファイル (デフォルトは /etc/ansible/hosts) に一覧表示される 1 つ目のマスターからのみ oc adm コマンドを実行します。
Apache の設定
このプロキシーはマスターと同じホストにある必要はありません。これはクライアント証明書を使用してマスターに接続し、X-Remote-User ヘッダーを信頼するように設定されます。
-
Apache 設定の証明書を作成します。
SSLProxyMachineCertificateFileパラメーターの値として指定する証明書は、プロキシーをサーバーに対して認証するために使用されるプロキシーのクライアント証明書です。これは、拡張されたキーのタイプとしてTLS Web Client Authenticationを使用する必要があります。 - 以下のそれぞれに対して Apache を設定します。
その他の mod_auth_form 要件
サンプルログインページは、openshift_extras リポジトリーから利用できます。このファイルは DocumentRoot (デフォルトでは /var/www/html) に配置する必要があります。
ユーザーの作成
ここで、Apache がアカウント情報を保存するために使用しているシステムでユーザーを作成することができます。たとえば、ファイルベース (file-backed) 認証が使用されます。
yum -y install httpd-tools touch /etc/origin/master/htpasswd htpasswd /etc/origin/master/htpasswd <user_name>
# yum -y install httpd-tools
# touch /etc/origin/master/htpasswd
# htpasswd /etc/origin/master/htpasswd <user_name>マスターの設定
/etc/origin/master/master-config.yaml ファイルの identityProviders スタンザも更新する必要があります。
サービスの再起動
最後に、以下のサービスを再起動します。
systemctl restart httpd systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart httpd
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers設定の検証
プロキシーをバイパスしてテストします。正しいクライアント証明書とヘッダーを指定すれば、トークンを要求できます。
curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://[MASTER]:8443/oauth/token/request
# curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://[MASTER]:8443/oauth/token/requestCopy to Clipboard Copied! Toggle word wrap Toggle overflow クライアント証明書を指定しない場合、要求は拒否されます。
curl -L -k -H "X-Remote-User: joe" \ https://[MASTER]:8443/oauth/token/request
# curl -L -k -H "X-Remote-User: joe" \ https://[MASTER]:8443/oauth/token/requestCopy to Clipboard Copied! Toggle word wrap Toggle overflow これは、設定された
challengeURL(追加のクエリーパラメーターを含む) へのリダイレクトを示します。curl -k -v -H 'X-Csrf-Token: 1' \ '<masterPublicURL>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'
# curl -k -v -H 'X-Csrf-Token: 1' \ '<masterPublicURL>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'Copy to Clipboard Copied! Toggle word wrap Toggle overflow これは、
WWW-Authenticate基本チャレンジの 401 応答を示します。curl -k -v -H 'X-Csrf-Token: 1' \ '<redirected challengeURL from step 3 +query>'# curl -k -v -H 'X-Csrf-Token: 1' \ '<redirected challengeURL from step 3 +query>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow これはアクセストークンを使用するリダイレクトを示します。
curl -k -v -u <your_user>:<your_password> \ -H 'X-Csrf-Token: 1' '<redirected_challengeURL_from_step_3 +query>'# curl -k -v -u <your_user>:<your_password> \ -H 'X-Csrf-Token: 1' '<redirected_challengeURL_from_step_3 +query>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3.11. GitHub
GitHub は OAuth を使用します。OpenShift Container Platform クラスターを統合して OAuth 認証を使用できます。OAuth は基本的にトークンの交換フローを促進します。
GitHub 認証を設定することによって、ユーザーは GitHub 認証情報を使用して OpenShift Container Platform にログインできます。GitHub ユーザー ID を持つすべてのユーザーが OpenShift Container Platform クラスターにログインできないようにするために、アクセスを特定の GitHub 組織のユーザーに制限することができます。
12.3.11.1. GitHub でのアプリケーションの登録
- GitHub で Settings → OAuth applications → Developer applications → Register an application を順番にクリックし、new OAuth application のページに移動します。
-
アプリケーション名を入力します。例:
My OpenShift Install -
ホームページの URL を入力します。例:
https://myapiserver.com:8443 - オプションで、アプリケーションの説明を入力します。
承認コールバック URL を入力します。ここで、URL の末尾にはアイデンティティープロバイダーの 名前 (マスター設定ファイル の
identityProvidersスタンザで定義されます。このトピックの以下のセクションで設定を行います) が含まれます。<apiserver>/oauth2callback/<identityProviderName>
<apiserver>/oauth2callback/<identityProviderName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
https://myapiserver.com:8443/oauth2callback/github/
https://myapiserver.com:8443/oauth2callback/github/Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Register application をクリックします。GitHub はクライアント ID とクライアントシークレットを提供します。このウィンドウを開いたままにして、それらの値をコピーし、マスター設定ファイルに貼り付けます。
12.3.11.2. マスターでの認証の設定
状況に応じて以下のいずれかの手順を実行します。
Openshift のインストールがすでに完了している場合は、/etc/origin/master/master-config.yaml ファイルを新規ディレクトリーにコピーします。以下は例になります。
cd /etc/origin/master mkdir githubconfig; cp master-config.yaml githubconfig
$ cd /etc/origin/master $ mkdir githubconfig; cp master-config.yaml githubconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Container Platform をまだインストールしていない場合は、OpenShift Container Platform API サーバーを起動し、(将来の) OpenShift Container Platform マスターのホスト名と、起動コマンドによって作成された設定ファイルを格納するディレクトリーを指定します。
openshift start master --public-master=<apiserver> --write-config=<directory>
$ openshift start master --public-master=<apiserver> --write-config=<directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例を以下に示します。
openshift start master --public-master=https://myapiserver.com:8443 --write-config=githubconfig
$ openshift start master --public-master=https://myapiserver.com:8443 --write-config=githubconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Ansible を使用してインストールする場合は、
identityProvider設定を Ansible Playbook に追加する必要があります。Ansible を使用してインストールした後、以下の手順に従って設定を手動で変更した場合、インストールツールまたはアップグレードを再実行するたびに変更内容がすべて失われます。注記openshift start masterを使用するとホスト名が自動的に検出されますが、GitHub はアプリケーション登録時に指定した正確なホスト名にリダイレクトできる必要があります。このため、ID は間違ったアドレスにリダイレクトする可能性があるために自動検出することはできません。代わりに、Web ブラウザーが OpenShift Container Platform クラスターとの対話に使用するホスト名を指定する必要があります。
新規 master-config.yaml ファイルの
identityProvidersスタンザを編集し、GitHubIdentityProvider設定例をコピーして貼り付け、既存のスタンザを置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このプロバイダー名は GitHub の数字ユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはコールバック URL を作成するためにも使用されます。
- 2
- GitHubIdentityProvider を使用して
WWW-Authenticateチャレンジを送信することはできません。 - 3
- true の場合、(Web コンソールの場合のように) Web クライアントからの非認証トークン要求はログインする GitHub にリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- 登録済みの GitHub OAuth アプリケーション のクライアント ID です。アプリケーションは、
<master>/oauth2callback/<identityProviderName>のコールバック URL を使用して設定する必要があります。 - 6
- GitHub で発行されるクライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
- 7
- 組織のオプションの一覧です。これが指定されている場合、少なくとも一覧のいずれかの組織のメンバーである GitHub ユーザーのみがログインできます。その組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定で実行できます。これは
teamsフィールドと組み合わせて使用することはできません。 - 8
- チームのオプションの一覧です。これが指定されている場合、少なくとも一覧のいずれかのチームのメンバーである GitHub ユーザーのみがログインできます。そのチームの組織が clientID で設定された GitHub OAuth アプリケーションを所有していない場合、組織の所有者はこのオプションを使用するためにサードパーティーのアクセスを付与する必要があります。これは組織の管理者が初回の GitHub ログイン時に、または GitHub の組織設定から実行できます。これは
organizationsフィールドと組み合わせて使用することはできません。
以下の変更を
identityProvidersスタンザに加えます。プロバイダーの
nameを変更して、GitHub で設定したコールバック URL に一致させます。たとえば、コールバック URL を
https://myapiserver.com:8443/oauth2callback/github/として定義した場合、nameはgithubにする必要があります。-
clientIDを以前に登録した GitHub のクライアント ID に変更します。 -
clientSecretを以前に登録した GitHub のクライアントシークレットに変更します。 -
organizationsまたはteamsを変更して、ユーザーが認証を行うためにメンバーシップを設定している必要がある 1 つ以上の GitHub 組織またはチームの一覧を組み込むようにします。これが指定されている場合、少なくとも一覧のいずれかの組織またはチームのメンバーである GitHub ユーザーのみがログインできます。これが指定されていない場合、有効な GitHub アカウントを持つすべてのユーザーがログインできます。
- 変更を保存してファイルを閉じます。
OpenShift Container Platform API サーバーを起動し、変更したばかりの設定ファイルを指定します。
openshift start master --config=<path/to/modified/config>/master-config.yaml
$ openshift start master --config=<path/to/modified/config>/master-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
これが設定されると、OpenShift Container Platform の Web コンソールにログインするユーザーには GitHub の認証情報を使用してログインすることを求めるプロンプトが出されます。初回ログイン時に、ユーザーは authorize application をクリックして GitHub が OpenShift Container Platform でのユーザー名、パスワードおよび組織のメンバーシップを使用することを許可する必要があります。その後、ユーザーは Web コンソールにリダイレクトされます。
12.3.11.3. GitHub 認証を持つユーザーの作成
GitHub などの外部認証プロバイダーを統合する場合は、ユーザーを OpenShift Container Platform では作成しません。GitHub は「system of record」であり、ユーザーは GitHub で定義され、指定される組織に属するすべてのユーザーがログインできることになります。
ユーザーを OpenShift Container Platform に追加するには、そのユーザーを GitHub で承認された組織に追加する必要があり、必要な場合は、そのユーザーの新しい GitHub アカウントを作成します。
12.3.11.4. ユーザーの確認
1 名以上のユーザーがログインしたら、oc get users を実行してユーザーの一覧を表示し、ユーザーが正しく作成されていることを確認できます。
例12.9 oc get users コマンドの出力
oc get users
$ oc get users
NAME UID FULL NAME IDENTITIES
bobsmith 433b5641-066f-11e6-a6d8-acfc32c1ca87 Bob Smith github:873654 - 1
- OpenShift Container Platform のアイデンティティーは、アイデンティティープロバイダー名と GitHub の内部の数字のユーザー ID で構成されます。そのため、ユーザーが GitHub のユーザー名またはメールアドレスを変更した場合でも、GitHub アカウントに割り当てられる認証情報に依存せず、OpenShift Container Platform にログインできます。これにより安定したログインが作成されます。
ここからは、ユーザーロールを制御する方法を学習することをお勧めします。
12.3.12. GitLab
OAuth 統合 を使用して、identityProviders スタンザで GitLabIdentityProvider を設定し、GitLab.com またはその他の GitLab インスタンスをアイデンティティープロバイダーとして使用するようにします。OAuth プロバイダー機能には GitLab バージョン 7.7.0 以降が必要です。
例12.10 GitLabIdentityProvider を使用したマスター設定
- 1
- このプロバイダー名は GitLab 数字ユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはコールバック URL を作成するためにも使用されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。これは Resource Owner Password Credentials 付与フローを使用して GitLab からアクセストークンを取得します。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの非認証トークン要求はログインする GitLab にリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- GitLab OAuth プロバイダーのホスト URL です。これは
https://gitlab.com/か、または他の GitLab の自己ホストインスタンスのいずれかになります。 - 6
- 登録済みの GitLab OAuth アプリケーションのクライアント ID です。アプリケーションは
<master>/oauth2callback/<identityProviderName>のコールバック URL で設定する必要があります。 - 7
- GitLab で発行されるクライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
- 8
- CA は、GitLab インスタンスへの要求を行う際に使用する任意の信頼される認証局バンドルです。空の場合、デフォルトのシステムルートが使用されます。
12.3.13. Google
Google の OpenID Connect 統合を使用して、identityProviders スタンザで GoogleIdentityProvider を設定し、アイデンティティープロバイダーとして Google を使用するようにします。
Google をアイデンティティープロバイダーとして使用するには、<master>/oauth/token/request を使用してトークンを取得し、コマンドラインツールで使用する必要があります。
Google をアイデンティティープロバイダーとして使用することで、Google ユーザーはサーバーに対して認証されます。以下のように hostedDomain 設定属性を使用して、特定のホストドメインのメンバーに認証を限定することができます。
例12.11 GoogleIdentityProvider を使用したマスター設定
- 1
- このプロバイダー名は Google の数字のユーザー ID にプレフィックスとして付加され、アイデンティティー名が作成されます。これはリダイレクト URL を作成するためにも使用されます。
- 2
- GoogleIdentityProvider を使用して
WWW-Authenticateチャレンジを送信することはできません。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの非認証トークン要求はログインする Google へリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- 登録済みの Google プロジェクト のクライアント ID です。プロジェクトは、
<master>/oauth2callback/<identityProviderName>のリダイレクト URI で設定する必要があります。 - 6
- Google で発行されるクライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
- 7
- サインインアカウントを制限するオプションの ホスト型ドメイン です。空の場合、すべての Google アカウントの認証が許可されます。
12.3.14. OpenID Connect
identityProviders スタンザで OpenIDIdentityProvider を設定し、Authorization Code Flow を使用して OpenID Connect アイデンティティープロバイダーと統合します。
OpenShift Container Platform の OpenID Connect アイデンティティープロバイダーとして Red Hat シングルサインオンを設定できます。
ID Token および UserInfo の復号化はサポートされていません。
デフォルトで、openid の範囲が要求されます。必要な場合は、extraScopes フィールドで追加の範囲を指定できます。
要求は、OpenID アイデンティティープロバイダーから返される JWT id_token から読み取られ、指定される場合は UserInfo URL によって返される JSON から読み取られます。
1 つ以上の要求をユーザーのアイデンティティーを使用するように設定される必要があります。標準のアイデンティティー要求は sub になります。
また、どの要求をユーザーの推奨ユーザー名、表示名およびメールアドレスとして使用するか指定することができます。複数の要求が指定されている場合、値が入力されている最初の要求が使用されます。標準のアイデンティティー要求は以下の通りです。
|
|
「subject identifier」の省略形です。発行側のユーザーのリモートアイデンティティーです。 |
|
|
ユーザーのプロビジョニング時に優先されるユーザー名です。 |
|
|
メールアドレス。 |
|
|
表示名。 |
詳細は、OpenID claim のドキュメントを参照してください。
OpenID Connect アイデンティティープロバイダーを使用するには、<master>/oauth/token/request を使用してトークンを取得し、コマンドラインツールで使用する必要があります。
OpenIDIdentityProvider を使用する標準マスター設定
- 1
- このプロバイダー名はアイデンティティー要求の値にプレフィックスとして付加され、アイデンティティー名が作成されます。これは、リダイレクト URL を作成するためにも使用されます。
- 2
- true の場合、非 Web クライアント (CLI など) からの認証されていないトークン要求は、このプロバイダーの
WWW-Authenticateチャレンジヘッダーと共に送信されます。この場合、OpenID プロバイダーが Resource Owner Password Credentials 付与フローをサポートしている必要があります。 - 3
- true の場合、Web クライアント (Web コンソールなど) からの非認証トークン要求は、ログインする認証 URL にリダイレクトされます。
- 4
- このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記を参照してください)。
- 5
- OpenID プロバイダーに登録されているクライアントのクライアント ID です。このクライアントは
<master>/oauth2callback/<identityProviderName>にリダイレクトすることを許可されている必要があります。 - 6
- クライアントシークレットです。この値は環境変数、外部ファイル、または暗号化されたファイルでも指定できます。
- 7
- アイデンティティーとして使用する要求の一覧です。空でない最初の要求が使用されます。1 つ以上の要求が必要になります。一覧表示される要求のいずれにも値がないと、認証は失敗します。たとえば、これは、ユーザーのアイデンティティーとして、返される
id_tokenのsub要求の値を使用します。 - 8
- OpenID 仕様に記述される承認エンドポイントです。
httpsを使用する必要があります。 - 9
- OpenID 仕様に記述されるトークンエンドポイントです。
httpsを使用する必要があります。
カスタム証明書バンドル、追加の範囲、追加の承認要求パラメーター、および userInfo URL も指定できます。
例12.12 OpenIDIdentityProvider を使用する完全なマスター設定
- 1
- 設定される URL のサーバー証明書を検証するために使用する証明書バンドルです。空の場合、システムで信頼されるルートを使用します。
- 2
- 承認トークン要求時に openid の範囲のほかに要求する範囲のオプションの一覧です。
- 3
- 承認トークン要求に追加する追加パラメーターのオプションのマップです。
- 4
- アイデンティティーとして使用する要求の一覧です。空でない最初の要求が使用されます。1 つ以上の要求が必要になります。一覧表示される要求のいずれにも値がないと、認証は失敗します。
- 5
- このアイデンティティーのユーザーをプロビジョニングする際に推奨ユーザー名として使用される要求の一覧です。空でない最初の要求が使用されます。
- 6
- 表示名として使用する要求の一覧です。空でない最初の要求が使用されます。
- 7
- メールアドレスとして使用する要求の一覧です。空でない最初の要求が使用されます。
- 8
- OpenID 仕様に記述される UserInfo エンドポイントです。
httpsを使用する必要があります。
12.4. トークンオプション
OAuth サーバーは以下の 2 種類のトークンを生成します。
|
アクセストークン |
API へのアクセスを付与する永続的なトークン。 |
|
認証コード |
アクセストークンの交換にのみ使われる一時的なトークン。 |
tokenConfig スタンザを使用してトークンオプションを設定します。
例12.13 マスター設定のトークンオプション
oauthConfig:
...
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
oauthConfig:
...
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
OAuthClient オブジェクト定義 により accessTokenMaxAgeSeconds 値を上書きできます。
12.5. 付与オプション
OAuth サーバーが、ユーザーが以前にパーミッションを付与していないクライアントに対するトークン要求を受信する場合、OAuth サーバーが実行するアクションは OAuth クライアントの付与ストラテジーによって変わります。
トークンを要求する OAuth クライアントが独自の付与ストラテジーを提供しない場合、サーバー全体でのデフォルトストラテジーが使用されます。デフォルトストラテジーを設定するには、grantConfig スタンザで method 値を設定します。method の有効な値は以下の通りです。
|
|
付与を自動承認し、要求を再試行します。 |
|
|
ユーザーに対して付与の承認または拒否を求めるプロンプトを出します。 |
|
|
付与を自動的に拒否し、失敗エラーをクライアントに返します。 |
例12.14 マスター設定の付与オプション
oauthConfig:
...
grantConfig:
method: auto
oauthConfig:
...
grantConfig:
method: auto12.6. セッションオプション
OAuth サーバーは、ログインおよびリダイレクトフローで署名および暗号化される Cookie ベースセッションを使用します。
sessionConfig スタンザを使用してセッションオプションを設定します。
例12.15 マスター設定のセッションオプション
- 1
- セッションの最大期間を制御します。トークン要求が完了すると、セッションは自動的に期限切れとなります。auto-grant が有効にされていない場合、ユーザーがクライアント承認要求を承認または拒否するためにかかると想定される時間の間、セッションは継続する必要があります。
- 2
- セッションを保存するために使用される Cookie の名前です。
- 3
- シリアライズされた
SessionSecretsオブジェクトを含むファイル名です。空の場合、サーバーが起動されるたびにランダムの署名および暗号化シークレットが生成されます。
sessionSecretsFile が指定されていない場合、マスターサーバーが起動されるたびにランダムの署名および暗号化シークレットが生成されます。つまりマスターが再起動されると、進行中のログインではセッションが無効になります。また、これは他のマスターのいずれかによって生成されるセッションを復号化することはできないことも意味します。
使用する署名および暗号化シークレットを指定するには、sessionSecretsFile を指定します。これにより、シークレット値と設定ファイルを分離でき、たとえば、設定ファイルをデバッグなどの目的に合わせて配布可能な状態とすることができます。
複数のシークレットを sessionSecretsFile に指定してローテーションを有効にできます。一覧の最初のシークレットを使用して、新しいセッションに署名し、これを暗号化します。既存のセッションは、成功するまで各シークレットによって復号化され、認証されます。
例12.16 セッションシークレット設定:
12.7. ユーザーエージェントによる CLI バージョンの不一致の防止
OpenShift Container Platform は、アプリケーション開発者の CLI が OpenShift Container Platform API にアクセスすることを防止するために使用されるユーザーエージェントを実装しています。
OpenShift Container Platform CLI のユーザーエージェントは、OpenShift Container Platform 内の値のセットで構成されています。
<command>/<version> (<platform>/<architecture>) <client>/<git_commit>
<command>/<version> (<platform>/<architecture>) <client>/<git_commit>たとえば、以下の場合を考慮しましょう。
-
<command> =
oc -
<version> = クライアントのバージョン。たとえば、
v3.3.0。/apiで Kubernetes API に対して行われる要求が Kubernetes のバージョンを受信し、/oapiで OpenShift Container Platform API に対して行われる要求が OpenShift Container Platform のバージョン (oc versionによって指定される) を受信します。 -
<platform> =
linux -
<architecture> =
amd64 -
<client> =
openshiftまたはkubernetes。要求が/apiで Kubernetes API に対して行われるか、/oapiで OpenShift Container Platform API に対して行われるかによって決まります。 -
<git_commit> = クライアントバージョンの Git コミット (例:
f034127)
上記の場合、ユーザーエージェントは以下のようになります。
oc/v3.3.0 (linux/amd64) openshift/f034127
oc/v3.3.0 (linux/amd64) openshift/f034127
OpenShift Container Platform 管理者として、マスター設定の userAgentMatching 設定を使用してクライアントが API にアクセスできないようにすることができます。そのため、クライアントが特定のライブラリーまたはバイナリーを使用している場合、クライアントは API にアクセスできなくなります。
以下のユーザーエージェントの例は、Kubernetes 1.2 クライアントバイナリー、OpenShift Origin 1.1.3 バイナリー、POST および PUT httpVerbs を拒否します。
管理者は、予想されるクライアントに正確に一致しないクライアントを拒否することもできます。
クライアントのユーザーエージェントが設定と一致しない場合にエラーが発生します。変更する要求が一致するように、ホワイトリストを実施します。ルールは特定の verb にマップされるので、変化する要求を禁止し、変化しない要求を許可することができます。
第13章 グループと LDAP の同期
13.1. 概要
OpenShift Container Platform 管理者として、グループを使用してユーザーを管理し、権限を変更し、連携を強化できます。組織ではユーザーグループをすでに作成し、それらを LDAP サーバーに保存している場合があります。OpenShift Container Platform はそれらの LDAP レコードを内部 OpenShift Container Platform レコードと同期できるので、グループを 1 つの場所で管理できます。現時点で OpenShift Container Platform はグループメンバーシップを定義するための 3 つの共通スキーマ (RFC 2307、Active Directory、拡張された Active Directory) を使用してグループと LDAP サーバーの同期をサポートしています。
グループを同期するには cluster-admin 権限を持っている必要があります。
13.2. LDAP 同期の設定
LDAP 同期を実行するには、同期設定ファイルが必要です。このファイルには LDAP クライアント設定の詳細が含まれます。
- LDAP サーバーへの接続の設定。
- LDAP サーバーで使用されるスキーマに依存する同期設定オプション。
同期設定ファイルには、OpenShift Container Platform Group 名を LDAP サーバーのグループにマップする管理者が定義した名前マッピングの一覧も含まれます。
13.2.1. LDAP クライアント設定
例13.1 LDAP クライアント設定
url: ldap://10.0.0.0:389 bindDN: cn=admin,dc=example,dc=com bindPassword: password insecure: false ca: my-ldap-ca-bundle.crt
url: ldap://10.0.0.0:389
bindDN: cn=admin,dc=example,dc=com
bindPassword: password
insecure: false
ca: my-ldap-ca-bundle.crt - 1
- データベースをホストする LDAP サーバーの接続プロトコル、 IP アドレス、および
scheme://host:portとしてフォーマットされる接続先のポートです。 - 2
- バインド DN として使用する任意の識別名 (DN) です。同期操作のエントリーを取得するために昇格した権限が必要となる場合、OpenShift Container Platform はこれを使用します。
- 3
- バインドに使用する任意のパスワードです。同期操作のエントリーを取得するために昇格した権限が必要となる場合、OpenShift Container Platform はこれを使用します。この値は環境変数、外部ファイル、または暗号化ファイルでも指定できます。
- 4
trueの場合、サーバーへの TLS 接続は行われません。falseの場合、セキュアな LDAP (ldaps://) URL は TLS を使用して接続し、非セキュアな LDAP (ldap://) URL は TLS にアップグレードされます。- 5
- 設定された URL のサーバー証明書を検証するために使用する証明書バンドルです。空の場合、OpenShift Container Platform はシステムで信頼されるルートを使用します。
insecureがfalseに設定されている場合にのみ、これが適用されます。
13.2.2. LDAP クエリー定義
同期設定は、同期に必要となるエントリーの LDAP クエリー定義で構成されています。LDAP クエリーの特定の定義は、LDAP サーバーにメンバーシップ情報を保存するために使用されるスキーマに依存します。
例13.2 LDAP クエリー定義
- 1
- すべての検索が開始されるディレクトリーのブランチの識別名 (DN) です。ディレクトリーツリーの上部を指定する必要がありますが、ディレクトリーのサブツリーを指定することもできます。
- 2
- 3
- LDAP ツリーのエイリアスに関連する検索の動作です。有効な値は
never、search、base、またはalwaysです。これを定義しない場合、デフォルトはalwaysとなり、エイリアスを逆参照します。逆参照の動作については以下の表で説明されています。 - 4
- クライアントによって検索に許可される時間制限です。秒単位で表示されます。0 の値はクライアント側の制限がないことを意味します。
- 5
- 有効な LDAP 検索フィルターです。これを定義しない場合、デフォルトは
(objectClass=*)になります。 - 6
- LDAP エントリーで測定される、サーバーからの応答ページの任意の最大サイズです。0 に設定すると、応答ページのサイズ制限はなくなります。クライアントまたはサーバーがデフォルトで許可しているエントリー数より多いエントリーをクエリーが返す場合、ページングサイズの設定が必要となります。
| LDAP 検索範囲 | 説明 |
|---|---|
|
|
クエリーに対して指定されるベース DN で指定するオブジェクトのみを考慮します。 |
|
|
クエリーについてベース DN とツリー内の同じレベルにあるすべてのオブジェクト考慮します。 |
|
|
クエリーに指定されるベース DN のサブツリー全体を考慮します。 |
| 逆参照動作 | 説明 |
|---|---|
|
|
LDAP ツリーにあるエイリアスを逆参照しません。 |
|
|
検索中に見つかったエイリアスのみを逆参照します。 |
|
|
ベースオブジェクトを検索中にエイリアスのみを逆参照します。 |
|
|
LDAP ツリーにあるすべてのエイリアスを常に逆参照します。 |
13.2.3. ユーザー定義の名前マッピング
ユーザー定義の名前マッピングは、OpenShift Container Platform Groups の名前を LDAP サーバーでグループを検出する固有の識別子に明示的にマップします。マッピングは通常の YAML 構文を使用します。ユーザー定義のマッピングには LDAP サーバーのすべてのグループのエントリーを含めることも、それらのグループのサブセットのみを含めることもできます。ユーザー定義の名前マッピングを持たないグループが LDAP サーバーにある場合、同期時のデフォルト動作では Group の名前として指定される属性が使用されます。
例13.3 ユーザー定義の名前マッピング
groupUIDNameMapping: "cn=group1,ou=groups,dc=example,dc=com": firstgroup "cn=group2,ou=groups,dc=example,dc=com": secondgroup "cn=group3,ou=groups,dc=example,dc=com": thirdgroup
groupUIDNameMapping:
"cn=group1,ou=groups,dc=example,dc=com": firstgroup
"cn=group2,ou=groups,dc=example,dc=com": secondgroup
"cn=group3,ou=groups,dc=example,dc=com": thirdgroup13.3. LDAP 同期の実行
同期設定ファイルを作成すると、同期を開始できます。OpenShift Container Platform では、管理者は同じサーバーを使用して多数の異なる同期タイプを実行できます。
デフォルトでは、すべてのグループ同期またはプルーニング操作がドライランされるので、OpenShift Container Platform Group レコードを変更するために sync-groups コマンドで --confirm フラグを設定する必要があります。
OpenShift Container Platform を使用して LDAP サーバーからすべてのグループを同期するには、以下を実行します。
oc adm groups sync --sync-config=config.yaml --confirm
$ oc adm groups sync --sync-config=config.yaml --confirm設定ファイルで指定された LDAP サーバーのグループに対応する OpenShift Container Platform の Group をすべて同期するには、以下を実行します。
oc adm groups sync --type=openshift --sync-config=config.yaml --confirm
$ oc adm groups sync --type=openshift --sync-config=config.yaml --confirmLDAP グループのサブセットと OpenShift Container Platform を同期するには、ホワイトリストファイル、ブラックリストファイル、またはその両方を使用します。
ブラックリストファイル、ホワイトリストファイル、またはホワイトリストのリテラルの組み合わせを使用できます。ホワイトリストのリテラルはコマンド自体に直接含めることができます。これは LDAP サーバーにあるグループと OpenShift Container Platform にすでにあるグループに適用されます。ファイルには 1 行ごとの 1 つの固有のグループ識別子を含める必要があります。
13.4. グループのプルーニングジョブの実行
グループを作成した LDAP サーバーのレコードが存在しなくなった場合、管理者は OpenShift Container Platform レコードからグループを削除することを選択できます。プルーニングジョブは、同期ジョブに使用されるものと同じ同期設定ファイルとホワイトまたはブラックリストを受け入れます。
たとえば、グループが config.yaml ファイルを使用して LDAP から同期されており、その一部のグループが LDAP サーバーに存在しなくなっている場合、以下のコマンドを使用して、どの OpenShift Container Platform の Group が LDAP で削除されたグループに対応するかを判断し、それらを OpenShift Container Platform から削除できます。
oc adm groups prune --sync-config=config.yaml --confirm
$ oc adm groups prune --sync-config=config.yaml --confirm13.5. 同期の例
このセクションでは、RFC 2307、Active Directory と 拡張された Active Directory スキーマの例を紹介しています。以下のすべての例では 2 名のメンバー (Jane と Jim) を持つ admins というグループを同期しています。それぞれの例では以下について説明しています。
- グループとユーザーが LDAP サーバーに追加される方法。
- LDAP 同期設定ファイルの概観。
- 同期後に生成される OpenShift Container Platform の Group レコード。
これらの例では、すべてのユーザーがそれぞれのグループの直接的なメンバーであることを想定しています。とくに、グループには他のグループがメンバーとして含まれません。ネスト化されたグループを同期する方法の詳細については、「ネスト化されたメンバーシップ同期の例」を参照してください。
13.5.1. RFC 2307
RFC 2307 スキーマでは、ユーザー (Jane と Jim) とグループの両方がファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはグループの属性に保存されます。以下の ldif のスニペットでは、このスキーマのユーザーとグループを定義しています。
例13.4 RFC 2307 スキーマを使用する LDAP エントリー: rfc2307.ldif
このグループを同期するには、まず設定ファイルを作成する必要があります。RFC 2307 スキーマでは、ユーザーとグループエントリー両方の LDAP クエリー定義と内部 OpenShift Container Platform レコードでそれらを表すのに使用する属性を指定する必要があります。
明確にするために、OpenShift Container Platform で作成するグループは (可能な場合) ユーザーまたは管理者に表示されるフィールドに識別名以外の属性を使用する必要があります。たとえば、メールによってグループのユーザーを識別し、一般名としてグループの名前を使用します。以下の設定ファイルでは、このような関係を作成しています。
ユーザー定義の名前マッピングを使用する場合は、設定ファイルが異なります。
例13.5 RFC 2307 スキーマを使用する LDAP 同期設定: rfc2307_config.yaml
- 1
- このグループのレコードが保存される LDAP サーバーの IP アドレスとホストです。
- 2
trueの場合、サーバーへの TLS 接続は行われません。falseの場合、セキュアな LDAP (ldaps://) URL は TLS を使用して接続し、非セキュアな LDAP (ldap://) URL は TLS にアップグレードされます。- 3
- LDAP サーバーのグループを一意に識別する属性です。groupUIDAttribute に DN を使用している場合、
groupsQueryフィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリスト方法を使用します。 - 4
- Group の名前として使用する属性です。
- 5
- メンバーシップ情報を保存するグループの属性です。
- 6
- LDAP サーバーでユーザーを一意に識別する属性です。userUIDAttribute に DN を使用している場合は、
usersQueryフィルターを指定できません。詳細のフィルターを実行するには、ホワイトリスト/ブラックリスト方法を使用します。 - 7
- OpenShift Container Platform Group レコードでユーザー名として使用される属性です。
rfc2307_config.yaml ファイルと同期するには、以下を実行します。
oc adm groups sync --sync-config=rfc2307_config.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config.yaml --confirmOpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。
例13.6 rfc2307_config.yaml を使用して作成される OpenShift Container Platform Group
13.5.1.1. ユーザー定義の名前マッピングに関する RFC2307
グループとユーザー定義の名前マッピングを同期する場合、設定ファイルは、以下に示すこれらのマッピングが含まれるように変更されます。
例13.7 ユーザー定義の名前マッピングに関する RFC 2307 スキーマを使用する LDAP 同期設定: rfc2307_config_user_defined.yaml
- 1
- ユーザー定義の名前マッピングです。
- 2
- ユーザー定義の名前マッピングでキーに使用される固有の識別属性です。groupUIDAttribute に DN を使用している場合は
groupsQueryフィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリスト方法を使用します。 - 3
- 固有の識別子がユーザー定義の名前マッピングに存在しない場合に OpenShift Container Platform Group に名前を付けるための属性です。
- 4
- LDAP サーバーでユーザーを一意に識別する属性です。userUIDAttribute に DN を使用している場合は、
usersQueryフィルターを指定できません。詳細のフィルターを実行するには、ホワイトリスト/ブラックリスト方法を使用します。
rfc2307_config_user_defined.yaml ファイルと同期するには、以下を実行します。
oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config_user_defined.yaml --confirmOpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。
例13.8 rfc2307_config_user_defined.yaml を使用して作成される OpenShift Container Platform Group
- 1
- ユーザー定義の名前マッピングが指定するグループ名です。
13.5.2. ユーザー定義のエラートレランスに関する RFC 2307
デフォルトでは、同期されるグループにメンバークエリーで定義された範囲外にあるエントリーを持つメンバーが含まれる場合、グループ同期は以下のエラーを出して失敗します。
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with dn="<user-dn>" would search outside of the base dn specified (dn="<base-dn>")".
これは usersQuery フィールドの baseDN が間違って設定されていることを示していることがよくあります。ただし、baseDN にグループの一部のメンバーが意図的に含まれていない場合、tolerateMemberOutOfScopeErrors: true を設定することでグループ同期が継続されます。範囲外のメンバーは無視されます。
同様に、グループ同期プロセスでグループのメンバーの検出に失敗した場合、同期はエラーを出して失敗します。
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry". Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" refers to a non-existent entry".
Error determining LDAP group membership for "<group>": membership lookup for user "<user>" in group "<group>" failed because of "search for entry with base dn="<user-dn>" and filter "<filter>" did not return any results".
これは、usersQuery フィールドが間違って設定されていることを示していることがよくあります。ただし、グループに欠落していると認識されているメンバーエントリーが含まれる場合、tolerateMemberNotFoundErrors: true を設定することでグループ同期が継続されます。問題のあるメンバーは無視されます。
LDAP グループ同期のエラートレランスを有効にすると、同期プロセスは問題のあるメンバーエントリーを無視します。LDAP グループ同期が正しく設定されていない場合、同期された OpenShift Container Platform グループにメンバーが欠落する可能性があります。
例13.9 問題のあるグループメンバーシップに関する RFC 2307 スキーマを使用する LDAP エントリー: rfc2307_problematic_users.ldif
上記の例でエラーを許容するには、以下を同期設定ファイルに追加する必要があります。
例13.10 エラーを許容する RFC 2307 スキーマを使用した LDAP 同期設定: rfc2307_config_tolerating.yaml
- 2
trueの場合、同期ジョブは一部のメンバーが見つからなかったグループを許容し、LDAP エントリーが見つからなかったメンバーは無視されます。グループのメンバーが見つからない場合、同期ジョブのデフォルト動作は失敗します。- 3
trueの場合、同期ジョブは、一部のメンバーがusersQueryベース DN で指定されるユーザー範囲外にいるグループを許容し、メンバークエリー範囲外のメンバーは無視されます。グループのメンバーが範囲外の場合、同期ジョブのデフォルト動作は失敗します。- 1
- LDAP サーバーでユーザーを一意に識別する属性です。userUIDAttribute に DN を使用している場合は、
usersQueryフィルターを指定できません。詳細のフィルターを実行するには、ホワイトリスト/ブラックリスト方法を使用します。
rfc2307_config_tolerating.yaml ファイルを使用して同期するには、以下を実行します。
oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirm
$ oc adm groups sync --sync-config=rfc2307_config_tolerating.yaml --confirmOpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。
例13.11 rfc2307_config.yaml を使用して作成される OpenShift Container Platform Group
- 1
- 同期ファイルで指定されるグループのメンバーのユーザーです。検索中に許容されるエラーがないメンバーです。
13.5.3. Active Directory
Active Directory スキーマでは、両方のユーザー (Jane と Jim) がファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはユーザーの属性に保存されます。以下の ldif のスニペットでは、このスキーマのユーザーとグループを定義しています。
例13.12 Active Directory スキーマを使用する LDAP エントリー: active_directory.ldif
- 1
- ユーザーのグループメンバーシップはユーザーの属性として一覧表示され、グループはサーバー上にエントリーとして存在しません。
memberOf属性はユーザーのリテラル属性である必要はありません。一部の LDAP サーバーでは、これは検索中に作成され、クライアントに返されますが、データベースにコミットされません。
このグループを同期するには、まず設定ファイルを作成する必要があります。Active Directory スキーマでは、ユーザーエントリーの LDAP クエリー定義と内部 OpenShift Container Platform Group レコードでそれらを表すのに使用する属性を指定する必要があります。
明確にするために、OpenShift Container Platform で作成したグループは (可能な場合) ユーザーまたは管理者に表示されるフィールドに識別名以外の属性を使用する必要があります。たとえば、メールによってグループのユーザーを識別しますが、LDAP サーバーのグループ名でグループの名前を定義します。以下の設定ファイルでは、このような関係を作成しています。
例13.13 Active Directory スキーマを使用する LDAP 同期設定: active_directory_config.yaml
active_directory_config.yaml ファイルを使用して同期するには、以下を実行します。
oc adm groups sync --sync-config=active_directory_config.yaml --confirm
$ oc adm groups sync --sync-config=active_directory_config.yaml --confirmOpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。
例13.14 active_directory_config.yaml を使用して作成される OpenShift Container Platform Group
13.5.4. 拡張された Active Directory
拡張された Active Directory スキーマでは、両方のユーザー (Jane と Jim) とグループがファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはユーザーの属性に保存されます。以下の ldif のスニペットではこのスキーマのユーザーとグループを定義しています。
例13.15 拡張された Active Directory スキーマを使用する LDAP エントリー: augmented_active_directory.ldif
このグループを同期するには、まず設定ファイルを作成する必要があります。拡張された Active Directory スキーマでは、ユーザーエントリーとグループエントリーの両方の LDAP クエリー定義と内部 OpenShift Container Platform Group レコードでそれらを表すのに使用する属性を指定する必要があります。
明確にするために、OpenShift Container Platform で作成するグループは (可能な場合) ユーザーまたは管理者に表示されるフィールドに識別名以外の属性を使用する必要があります。たとえば、メールによってグループのユーザーを識別し、一般名としてグループの名前を使用します。以下の設定ファイルではこのような関係を作成しています。
例13.16 拡張された Active Directory スキーマを使用する LDAP 同期設定: augmented_active_directory_config.yaml
- 1
- LDAP サーバーのグループを一意に識別する属性です。groupUIDAttribute に DN を使用している場合、
groupsQueryフィルターを指定できません。詳細なフィルターを実行するには、ホワイトリスト/ブラックリスト方法を使用します。 - 2
- Group の名前として使用する属性です。
- 3
- OpenShift Container Platform Group レコードでユーザー名として使用される属性です。
- 4
- メンバーシップ情報を保存するユーザーの属性です。
augmented_active_directory_config.yaml ファイルを使用して同期するには、以下を実行します。
oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirm
$ oc adm groups sync --sync-config=augmented_active_directory_config.yaml --confirmOpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。
例13.17 augmented_active_directory_config.yaml を使用して作成される OpenShift Group
13.6. ネスト化されたメンバーシップ同期の例
OpenShift Container Platform の Group はネスト化しません。LDAP サーバーはデータが使用される前にグループメンバーシップを平坦化する必要があります。Microsoft の Active Directory Server は、LDAP_MATCHING_RULE_IN_CHAIN ルールによりこの機能をサポートしており、これには OID 1.2.840.113556.1.4.1941 が設定されています。さらに、このマッチングルールを使用すると、明示的にホワイトリスト化されたグループのみを同期できます。
このセクションでは、拡張された Active Directory スキーマの例を取り上げ、1 名のユーザー Jane と 1 つのグループ otheradmins をメンバーとして持つ admins というグループを同期します。otheradmins グループには 1 名のユーザーメンバー Jim が含まれます。この例では以下のことを説明しています。
- グループとユーザーが LDAP サーバーに追加される方法。
- LDAP 同期設定ファイルの概観。
- 同期後に生成される OpenShift Container Platform の Group レコード。
拡張された Active Directory スキーマでは、ユーザー (Jane と Jim) とグループの両方がファーストクラスエントリーとして LDAP サーバーに存在し、グループメンバーシップはユーザーまたはグループの属性に保存されます。以下の ldif のスニペットはこのスキーマのユーザーとグループを定義します。
ネスト化されたメンバーを持つ拡張された Active Directory スキーマを使用する LDAP エントリー: augmented_active_directory_nested.ldif
Active Directory を使用してネスト化されたグループを同期するには、ユーザーエントリーとグループエントリーの両方の LDAP クエリー定義と内部 OpenShift Container Platform Group レコードでそれらを表すのに使用する属性を指定する必要があります。さらに、この設定では特定の変更が必要となります。
-
oc adm groups syncコマンドはグループを明示的にホワイトリスト化する必要があります。 -
ユーザーの
groupMembershipAttributesには"memberOf:1.2.840.113556.1.4.1941:"を含め、LDAP_MATCHING_RULE_IN_CHAINルールに従う必要があります。 -
groupUIDAttributeはdnに設定される必要があります。 groupsQuery:-
filterを設定しないでください。 -
有効な
derefAliasesを設定する必要があります。 -
baseDNを設定しないでください。この値は無視されます。 -
scopeを設定しないでください。この値は無視されます。
-
明確にするために、OpenShift Container Platform で作成するグループは (可能な場合) ユーザーまたは管理者に表示されるフィールドに識別名以外の属性を使用する必要があります。たとえば、メールによってグループのユーザーを識別し、一般名としてグループの名前を使用します。以下の設定ファイルではこれらの関係を作成しています。
ネスト化されたメンバーを持つ拡張された Active Directory スキーマを使用する LDAP 同期設定: augmented_active_directory_config_nested.yaml
- 1
groupsQueryフィルターは指定できません。groupsQueryベース DN とスコープ値は無視されます。groupsQueryは有効なderefAliasesを設定する必要があります。- 2
- LDAP サーバーのグループを一意に識別する属性です。
dnに設定される必要があります。 - 3
- Group の名前として使用する属性です。
- 4
- OpenShift Container Platform Group レコードでユーザー名として使用される属性です。
mailまたはsAMAccountNameがほとんどのインストールで推奨されます。 - 5
- メンバーシップ情報を保存するユーザーの属性です。
LDAP_MATCHING_RULE_IN_CHAINを使用することに注意してください。
augmented_active_directory_config_nested.yaml ファイルを使用して同期するには、以下を実行します。
oc adm groups sync \
'cn=admins,ou=groups,dc=example,dc=com' \
--sync-config=augmented_active_directory_config_nested.yaml \
--confirm
$ oc adm groups sync \
'cn=admins,ou=groups,dc=example,dc=com' \
--sync-config=augmented_active_directory_config_nested.yaml \
--confirm
cn=admins,ou=groups,dc=example,dc=com グループを明示的にホワイトリスト化する必要があります。
OpenShift Container Platform は、上記の同期操作の結果として以下のグループレコードを作成します。
augmented_active_directory_config_nested.yaml を使用して作成される OpenShift Group
13.7. LDAP 同期設定の仕様
設定ファイルのオブジェクト仕様は以下で説明されています。スキーマオブジェクトにはそれぞれのフィールドがあることに注意してください。たとえば、v1.ActiveDirectoryConfig は groupsQuery フィールドを持ちませんが、v1.RFC2307Config と v1.AugmentedActiveDirectoryConfig の両方にこのフィールドがあります。
バイナリー属性はサポートされていません。LDAP サーバーの全属性データは、UTF-8 エンコード文字列の形式である必要があります。たとえば、ID 属性として、バイナリー属性を使用することはできません (例: objectGUID)。代わりに sAMAccountName または userPrincipalName などの文字列属性を使用する必要があります。
13.7.1. v1.LDAPSyncConfig
LDAPSyncConfig は、LDAP グループ同期を定義するために必要な設定オプションを保持します。
| 名前 | 説明 | スキーマ |
|---|---|---|
|
|
このオブジェクトが表す REST リソースを表す文字列の値です。サーバーはクライアントが要求を送信するエンドポイントからこれを推測できることがあります。これを更新することはできません。CamelCase。詳細については、https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#types-kinds を参照してください。 |
文字列 |
|
|
オブジェクトのこの表現のバージョンスキーマを定義します。サーバーは認識されたスキーマを最新の内部値に変換し、認識されない値は拒否することがあります。詳細については、https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#resources を参照してください。 |
文字列 |
|
|
ホストは接続先の LDAP サーバーのスキーム、ホストおよびポートになります。 |
文字列 |
|
|
LDAP サーバーをバインドする任意の DN です。 |
文字列 |
|
|
検索フェーズでバインドする任意のパスワードです。 | |
|
|
|
ブール値 |
|
|
サーバーへ要求を行う際に使用する任意の信頼された認証局バンドルです。空の場合は、デフォルトのシステムルートが使用されます。 |
文字列 |
|
|
LDAP グループ UID の OpenShift Container Platform Group 名への任意の直接マッピングです。 |
object |
|
|
RFC2307 と同じ方法でセットアップされた LDAP サーバーからデータを抽出するための設定を保持します。ファーストクラスグループとユーザーエントリーを抽出し、グループメンバーシップはメンバーを一覧表示するグループエントリーの複数値の属性によって決定されます。 | |
|
|
Active Directory に使用されるのと同じ方法でセットアップされた LDAP サーバーからデータを抽出するための設定を保持します。ファーストクラスユーザーエントリーを抽出し、グループメンバーシップはメンバーが属するグループを一覧表示するメンバーの複数値の属性によって決定されます。 | |
|
|
上記の Active Directory で使用されるのと同じ方法でセットアップされた LDAP サーバーからデータを抽出するための設定を保持します。1 つの追加として、ファーストクラスグループエントリーが存在し、それらはメタデータを保持するために使用されますが、グループメンバーシップは設定されません。 |
13.7.2. v1.StringSource
StringSource によって文字列インラインを指定できます。または環境変数またはファイルを使用して外部から指定することもできます。文字列の値のみを含む場合、単純な JSON 文字列にマーシャルします。
| 名前 | 説明 | スキーマ |
|---|---|---|
|
|
クリアテキスト値、または |
文字列 |
|
|
クリアテキスト値、または |
文字列 |
|
|
クリアテキスト値、または |
文字列 |
|
|
値を復号化するために使用するキーを含むファイルを参照します。 |
文字列 |
13.7.3. v1.LDAPQuery
LDAPQuery は LDAP クエリーの作成に必要なオプションを保持します。
| 名前 | 説明 | スキーマ |
|---|---|---|
|
|
すべての検索が開始されるディレクトリーのブランチの DN です。 |
文字列 |
|
|
検索の (任意の) 範囲です。 |
文字列 |
|
|
エイリアスに関する検索の (任意の) 動作です。 |
文字列 |
|
|
応答の待機を中止するまでにサーバーへの要求を未処理のままにする時間制限 (秒単位) を保持します。これが |
整数 |
|
|
ベース DN を持つ LDAP サーバーから関連するすべてのエントリーを取得する有効な LDAP 検索フィルターです。 |
文字列 |
|
|
LDAP エントリーで測定される、推奨される最大ページサイズです。ページサイズ |
整数 |
13.7.4. v1.RFC2307Config
RFC2307Config は、RFC2307 スキーマを使用してどのように LDAP グループ同期が LDAP サーバーに相互作用するかを定義するために必要な設定オプションを保持します。
| 名前 | 説明 | スキーマ |
|---|---|---|
|
|
グループエントリーを返す LDAP クエリーのテンプレートを保持します。 | |
|
|
LDAP グループエントリーのどの属性が固有の識別子として解釈されるかを定義します。( |
文字列 |
|
|
LDAP グループエントリーのどの属性が OpenShift Container Platform グループに使用する名前として解釈されるかを定義します。 |
文字列の配列 |
|
|
LDAP グループエントリーのどの属性がメンバーとして解釈されるかを定義します。それらの属性に含まれる値は |
文字列の配列 |
|
|
ユーザーエントリーを返す LDAP クエリーのテンプレートを保持します。 | |
|
|
LDAP ユーザーエントリーのどの属性が固有の識別子として解釈されるかを定義します。 |
文字列 |
|
|
LDAP ユーザーエントリーのどの属性が順番に OpenShift Container Platform ユーザー名として使われるかを定義します。空でない値を持つ最初の属性が使用されます。これは |
文字列の配列 |
|
|
ユーザーエントリーがない場合の LDAP 同期ジョブの動作を決定します。 |
ブール値 |
|
|
範囲外のユーザーエントリーが検出される場合の LDAP 同期ジョブの動作を決定します。 |
ブール値 |
13.7.5. v1.ActiveDirectoryConfig
ActiveDirectoryConfig は必要な設定オプションを保持し、どのように LDAP グループ同期が Active Directory スキーマを使用して LDAP サーバーと相互作用するかを定義します。
| 名前 | 説明 | スキーマ |
|---|---|---|
|
|
ユーザーエントリーを返す LDAP クエリーのテンプレートを保持します。 | |
|
|
LDAP ユーザーエントリーのどの属性が OpenShift Container Platform ユーザー名として解釈されるかを定義します。OpenShift Container Platform Group レコードでユーザーの名前として使用する属性。ほとんどのインストールで、 |
文字列の配列 |
|
|
LDAP ユーザーのどの属性がメンバーの属するグループとして解釈されるかを定義します。 |
文字列の配列 |
13.7.6. v1.AugmentedActiveDirectoryConfig
AugmentedActiveDirectoryConfig は必要な設定オプションを保持し、どのように LDAP グループ同期が拡張された Active Directory スキーマを使用して LDAP サーバーに相互作用するかを定義します。
| 名前 | 説明 | スキーマ |
|---|---|---|
|
|
ユーザーエントリーを返す LDAP クエリーのテンプレートを保持します。 | |
|
|
LDAP ユーザーエントリーのどの属性が OpenShift Container Platform ユーザー名として解釈されるかを定義します。OpenShift Container Platform Group レコードでユーザーの名前として使用する属性。ほとんどのインストールで、 |
文字列の配列 |
|
|
LDAP ユーザーのどの属性がメンバーの属するグループとして解釈されるかを定義します。 |
文字列の配列 |
|
|
グループエントリーを返す LDAP クエリーのテンプレートを保持します。 | |
|
|
LDAP グループエントリーのどの属性が固有の識別子として解釈されるかを定義します。( |
文字列 |
|
|
LDAP グループエントリーのどの属性が OpenShift Container Platform グループに使用する名前として解釈されるかを定義します。 |
文字列の配列 |
第14章 LDAP フェイルオーバーの設定
OpenShift Container Platform は Lightweight Directory Access Protocol (LDAP) セットアップで使用するための 認証プロバイダーを提供しますが、接続できるのは単一の LDAP サーバーのみです。OpenShift Container Platform インストール時に、LDAP フェイルオーバーの System Security Services Daemon (SSSD) を設定し、ある LDAP サーバーが失敗した場合にクラスターにアクセスできるようにします。
この設定には、詳細な設定および通信先となる OpenShift Container Platform の認証サーバー (リモート Basic 認証サーバー とも呼ばれます) が別途必要となります。メールアドレスなどの追加の属性を OpenShift Container Platform に渡すようにこのサーバーを設定し、それらの属性を Web コンソールで表示できるようにします。
このトピックでは、専用の物理または仮想マシン (VM) のセットアップを完了する方法や、コンテナーでの SSSD の設定方法についても説明します。
このトピックのすべてのセクションを完了する必要があります。
14.1. 基本リモート認証の前提条件
セットアップを始める前に、LDAP サーバーの以下の情報について知っておく必要があります。
- ディレクトリーサーバーが FreeIPA、Active Directory、または別の LDAP ソリューションでサポートされているかどうか。
- LDAP サーバーの Uniform Resource Identifier (URI) (例: ldap.example.com)。
- LDAP サーバーの CA 証明書の場所。
- LDAP サーバーがユーザーグループの RFC 2307 または RFC2307bis に対応しているかどうか。
サーバーを準備します。
remote-basic.example.com: リモート基本認証サーバーとして使用する VM。
- Red Hat Enterprise Linux 7.0 以降などの、このサーバーの SSSD バージョン 1.12.0 を含むオペレーティングシステムを選択します。
openshift.example.com: OpenShift Container Platform の新規インストール。
- 認証方法をこのクラスターに設定することはできません。
- このクラスターで OpenShift Container Platform を起動することはできません。
14.2. 証明書の生成およびリモート Basic 認証サーバーとの共有
Ansible ホストインベントリーファイル (デフォルトは /etc/ansible/hosts) に一覧表示された 1 つ目のマスターホストで以下の手順を実行します。
リモート Basic 認証サーバーと OpenShift Container Platform 間の通信に新異性をもたせるために、このセットアップの他のフェーズで使用する Transport Layer Security (TLS) 証明書のセットを作成します。以下のコマンドを実行します。
openshift start \ --public-master=https://openshift.example.com:8443 \ --write-config=/etc/origin/# openshift start \ --public-master=https://openshift.example.com:8443 \ --write-config=/etc/origin/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、/etc/origin/master/ca.crt および /etc/origin/master/ca.key の署名用証明書が含まれます。
署名用証明書を使用してリモート Basic 認証サーバーで使用するキーを生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- リモート Basic 認証サーバーにアクセスする必要のある、すべてのホスト名およびインターネット IP アドレスのコンマ区切りの一覧です。
注記生成する証明書ファイルは 2 年間有効です。この期間は、
--expire-daysおよび--signer-expire-daysの値を変更して変更することができますが、セキュリティー上の理由により、730 より大きな値を設定しないでください。重要リモート Basic 認証サーバーにアクセスする必要のあるすべてのホスト名およびインターフェース IP アドレスを一覧表示しない場合、HTTPS 接続は失敗します。
必要な証明書およびキーをリモート Basic 認証サーバーにコピーします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.3. SSSD での LDAP フェイルオーバーの設定
リモート Basic 認証サーバーで以下の手順を実行します。
メールアドレスおよび表示名などの属性を取得し、それらを OpenShift Container Platform に渡して Web インターフェースに表示することができるように SSSD を設定します。以下の手順では、メールアドレスを OpenShift Container Platform に指定するように SSSD を設定します。
必要な SSSD および Web サーバーコンポーネントをインストールします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LDAP サーバーに対してこの VM を認証するように SSSD を設定します。LDAP サーバーが FreeIPA または Active Directory 環境の場合、realmd を使用してこのマシンをドメインに参加させることができます。
realm join ldap.example.com
# realm join ldap.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow より高度なケースの場合は、『システムレベル認証ガイド』を参照してください。
- SSSD を使用して LDAP のフェイルオーバーの状態を使用するには、ldap_uri 行の /etc/sssd/sssd.conf ファイルにその他のエントリーを追加します。FreeIPA に登録されたシステムは DNS SRV レコードを使用してフェイルオーバーを自動的に処理します。
/etc/sssd/sssd.conf ファイルの [domain/DOMAINNAME] セクションを変更し、この属性を追加します。
[domain/example.com] ... ldap_user_extra_attrs = mail
[domain/example.com] ... ldap_user_extra_attrs = mail1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- LDAP ソリューションのメールアドレスを取得するために正しい属性を指定します。IPA については、
mailを指定します。他の LDAP ソリューションはemailなどの別の属性を使用する可能性があります。
/etc/sssd/sssd.conf ファイルの domain パラメーターには [domain/DOMAINNAME] セクションに一覧表示されているドメイン名のみが含まれていることを確認します。
domains = example.com
domains = example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow メール属性を取得するために Apache パーミッションを付与します。以下の行を /etc/sssd/sssd.conf ファイルの [ifp] セクションに追加します。
[ifp] user_attributes = +mail allowed_uids = apache, root
[ifp] user_attributes = +mail allowed_uids = apache, rootCopy to Clipboard Copied! Toggle word wrap Toggle overflow すべての変更が適切に適用されていることを確認するには、SSSD を再起動します。
systemctl restart sssd.service
$ systemctl restart sssd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow ユーザー情報が適切に取得できるかどうかをテストします。
getent passwd <username>
$ getent passwd <username> username:*:12345:12345:Example User:/home/username:/usr/bin/bashCopy to Clipboard Copied! Toggle word wrap Toggle overflow 指定したメール属性がドメインからメールアドレスを返すことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - LDAP ユーザーとしての VM へのログインを試行し、LDAP 認証情報を使用してログインできることを確認します。ログインにはローカルコンソールまたは SSH などのリモートサービスを使用できます。
デフォルトで、すべてのユーザーは LDAP 認証情報を使用してリモート Basic 認証サーバーにログインできます。この動作は変更することができます。
- IPA に参加するシステムを使用する場合、ホストベースのアクセス制御を設定します。
- Active Directory に参加するシステムを使用する場合には、グループポリシーオブジェクトを使用します。
- その他のケースについては、SSSD 設定 についてのドキュメントを参照してください。
14.4. Apache での SSSD の使用の設定
以下の内容を含む /etc/pam.d/openshift ファイルを作成します。
auth required pam_sss.so account required pam_sss.so
auth required pam_sss.so account required pam_sss.soCopy to Clipboard Copied! Toggle word wrap Toggle overflow この設定により、認証要求が openshift スタックに対して発行された時に PAM (プラグ可能な認証モジュール) は pam_sss.so を使用して認証とアクセス制御を決定できるようになります。
/etc/httpd/conf.modules.d/55-authnz_pam.conf ファイルを編集して、以下の行のコメントを解除します。
LoadModule authnz_pam_module modules/mod_authnz_pam.so
LoadModule authnz_pam_module modules/mod_authnz_pam.soCopy to Clipboard Copied! Toggle word wrap Toggle overflow Apache httpd.conf ファイルをリモート基本認証用に設定するには、openshift-remote-basic-auth.conf ファイルを /etc/httpd/conf.d ディレクトリーに作成します。以下のテンプレートを使用して必要な設定および値を指定します。
重要テンプレートの詳細を確認し、その内容を環境に合うようにカスタマイズします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow check_user.php スクリプトを /var/www/html ディレクトリーに作成します。以下のコードを組み込みます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apache がモジュールを読み込めるようにします。/etc/httpd/conf.modules.d/55-lookup_identity.conf ファイルを変更し、以下の行のコメントを解除します。
LoadModule lookup_identity_module modules/mod_lookup_identity.so
LoadModule lookup_identity_module modules/mod_lookup_identity.soCopy to Clipboard Copied! Toggle word wrap Toggle overflow SELinux ブール値を設定し、SElinux が Apache が D-BUS を介して SSSD に接続することを許可するようにします。
setsebool -P httpd_dbus_sssd on
# setsebool -P httpd_dbus_sssd onCopy to Clipboard Copied! Toggle word wrap Toggle overflow SELinux に Apache による PAM サブシステムへの問い合わせを受け入れることを指示するブール値を設定します。
setsebool -P allow_httpd_mod_auth_pam on
# setsebool -P allow_httpd_mod_auth_pam onCopy to Clipboard Copied! Toggle word wrap Toggle overflow Apache を起動します。
systemctl start httpd.service
# systemctl start httpd.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
14.5. OpenShift Container Platform が SSSD を基本リモート認証サーバーとして使用する設定
作成した新規のアイデンティティープロバイダーのデフォルト設定を変更します。Ansible ホストインベンリーファイルに一覧表示される最初のマスターホストで以下の手順を実行します。
- /etc/origin/master/master-config.yaml ファイルを開きます。
identityProviders セクションの場所を見つけ、これを以下のコードに置き換えます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新された設定を使って OpenShift Container Platform を起動します。
openshift start \ --public-master=https://openshift.example.com:8443 \ --master-config=/etc/origin/master/master-config.yaml \ --node-config=/etc/origin/node-node1.example.com/node-config.yaml# openshift start \ --public-master=https://openshift.example.com:8443 \ --master-config=/etc/origin/master/master-config.yaml \ --node-config=/etc/origin/node-node1.example.com/node-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ocCLI を使用してログインをテストします。oc login https://openshift.example.com:8443
oc login https://openshift.example.com:8443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 有効な LDAP 認証情報のみを使用してログインすることができます。
アイデンティティーを一覧表示し、各ユーザー名のメールアドレスが表示されていることを確認します。以下のコマンドを実行します。
oc get identity -o yaml
$ oc get identity -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第15章 SDN の設定
15.1. 概要
OpenShift SDN は、OpenShift Container Platform クラスターでの Pod 間の通信を有効にして Pod ネットワークを構築します。現在利用可能な SDN プラグイン は 3 種類 (ovs-subnet、ovs-multitenant、ovs-networkpolicy) あり、これらは Pod ネットワークを設定するためのそれぞれ異なる方法を提供します。
15.2. 利用可能な SDN プロバイダー
アップストリームの Kubernetes プロジェクトはデフォルトのネットワークソリューションを備えていません。その代わりに、Kubernetes では Container Network Interface (CNI) を開発し、ネットワークプロバイダーが独自の SDN ソリューションを統合することを可能にしています。
Red Hat は、サードパーティーのプラグインのほかにも追加設定なしで使用できるいくつかの OpenShift SDN プラグインを提供しています。
Red Hat は数多くの SDN プロバイダーと協力し、Kubernetes CNI インターフェースを使用した OpenShift Container Platform 上での SDN ネットワークソリューション (これには、製品のエンタイトルメントプロセスでの SDN プラグインのサポートプロセスが含まれます) の認定を行っています。Red Hat は、ユーザーが OpenShift でサポートケースを作成される場合、両社が共にユーザーのニーズに対応できるよう交換プロセスを促進し、これを容易にできます。
以下は、サードパーティーのベンダーが OpenShift Container Platform で直接検証を行い、サポートしている SDN ソリューションです。
- Cisco Contiv (™)
- Juniper Contrail (™)
- Nokia Nuage (™)
- Tigera Calico (™)
- VMware NSX-T (™)
VMware NSX-T (™) の OpenShift Container Platform へのインストール
VMware NSX-T (™) は、クラウドネイティブなアプリケーション環境を構築するための SDN およびセキュリティー基盤を提供しています。これらの環境には、vSphere Hypervisors (ESX) のほかに KVM とネイティブなパブリッククラウドが含まれます。
現在の統合には、NSX-T と OpenShift Container Platform の両方の新規インストールが必要です。現時点で、NSX-T バージョン 2.1 がサポートされ、これは ESX と KVM のハイパーバイザーの使用のみに対応しています。
詳細は「NSX-T Container Plug-in for OpenShift - Installation and Administration Guide」を参照してください。
15.3. Ansible を使用した Pod ネットワークの設定
初回の通常インストール (Advanced installation) では、ovs-subnet プラグインはデフォルトでインストールされ、設定されますが、このプラグインは、os_sdn_network_plugin_name パラメーターを使ってインストール時に上書きできます。これは Ansible インベントリーファイルで設定できます。
たとえば、標準の ovs-subnet プラグインを上書きし、代わりに ovs-multitenant プラグインを使用するには、以下を実行します。
Configure the multi-tenant SDN plugin (default is 'redhat/openshift-ovs-subnet')
# Configure the multi-tenant SDN plugin (default is 'redhat/openshift-ovs-subnet')
os_sdn_network_plugin_name='redhat/openshift-ovs-multitenant'インベントリーファイルに設定できるネットワーキング関連の Ansible 変数の詳細については、「クラスター変数の設定」を参照してください。
初回のクイックインストールでも、ovs-subnet プラグインは同様にデフォルトでインストールされ、設定され、master-config.yaml ファイルの networkConfig スタンザを使って、インストール後に再設定することができます。
15.4. マスターでの Pod ネットワークの設定
クラスター管理者は、マスター設定ファイル (デフォルトの場所は /etc/origin/master/master-config.yaml) の networkConfig セクションにあるパラメーターを変更することで、マスターホスト上で Pod ネットワーク設定を管理できます。
単一 CIDR の Pod ネットワーク設定
また、複数の CIDR 範囲を持つ Pod ネットワークを作成することもできます。これは、個別の範囲をその範囲と hostSubnetLength を指定した clusterNetworks フィールドに追加して実行できます。
複数の範囲は同時に使用することができ、この範囲は拡張または縮小することが可能です。ノードは、ノードの退避、削除および再作成によってある範囲から別の範囲に移動できます。詳細は、「ノードの管理」セクションを参照してください。ノードの割り当ては一覧の順序で行われ、範囲が一杯になると以下の一覧に移行します。
複数 CIDR の Pod ネットワークの設定
clusterNetworks 値に要素を追加するか、その CIDR 範囲を使用しているノードがなければ要素を削除することができます。ただし変更を有効にするために、必ず atomic-openshift-master-api および atomic-openshift-master-controllers のサービスを再起動してください。
hostSubnetLength の値は、クラスターの初回作成後に変更することができません。cidr は、ノードが範囲内に割り当てられている場合に最初のネットワークが含まれるより大きいネットワークに変更することのみ可能です。また、serviceNetworkCIDR は拡張可能です。たとえば、デフォルト値が 10.128.0.0/14 の場合、cidr を 10.128.0.0/9 (上半分の net 10 を参照) に変更することは可能ですが、10.64.0.0/16 には元の値と重複しないために変更することができません。
serviceNetworkCIDR は 172.30.0.0/16 から 172.30.0.0/15 に変更できますが、172.28.0.0/14 に変更できません。元の範囲が新規の範囲内にある場合でも、その範囲が CIDR の開始部分になければならないためです。
15.5. ノードでの Pod ネットワークの設定
クラスター管理者は、ノード設定ファイル (デフォルトの場所は /etc/origin/node/node-config.yaml ) の networkConfig セクションにあるパラメーターを変更することで、ノード上に設定される Pod ネットワークを制御できます。
networkConfig: mtu: 1450 networkPluginName: "redhat/openshift-ovs-subnet"
networkConfig:
mtu: 1450
networkPluginName: "redhat/openshift-ovs-subnet" OpenShift Container Platform SDN を構成するすべてのマスターおよび ノードで MTU サイズを変更する必要があります。また、tun0 インターフェースの MTU サイズはクラスターを構成するすべてのノードで同一である必要があります。
15.6. SDN プラグイン間の移行
SDN プラグインをすでに 1 つ使用していて、別のプラグインへ切り替える場合には、以下を実行します。
-
設定ファイル内のすべてのマスターとノードで
networkPluginNameパラメーターを変更します。 - すべてのマスターで atomic-openshift-master-api および atomic-openshift-master-controllers サービスを再起動します。
- すべてのマスターおよびノードで atomic-origin-node サービスを停止します。
- OpenShift SDN プラグインを切り換える場合、すべてのマスターおよびノードで openvswitch サービスを再起動します。
- すべてのマスターおよびノードで atomic-openshift-node サービスを停止します。
- OpenShift SDN プラグインからサードパーティーのプラグインへ切り替える場合は、OpenShift SDN 固有のアーティファクトを消去します。
oc delete clusternetwork --all oc delete hostsubnets --all oc delete netnamespaces --all
$ oc delete clusternetwork --all
$ oc delete hostsubnets --all
$ oc delete netnamespaces --allovs-subnet から ovs-multitenant OpenShift SDN プラグインに切り替えると、クラスター内の既存のすべてのプロジェクトが完全に分離します (つまり、これらに固有の VNID が割り当てられます)。クラスター管理者は、管理者 CLI を使用してプロジェクトネットワークの変更を選択できます。
以下を実行して VNID をチェックします。
oc get netnamespace
$ oc get netnamespace15.6.1. ovs-multitenant から ovs-networkpolicy への移行
「SDN プラグイン間の移行」セクションでの上記の一般的なプラグインの移行に加え、ovs-multitenant プラグインから ovs-networkpolicy プラグインへの移行にはもう 1 つの追加の手順があります。つまり、すべての namespace に NetIDがあることを確認する必要があります。これは、以前にプロジェクトを結合している場合や、プロジェクトをグローバルにしている場合に、ovs-networkpolicy プラグインに切り換える前にこのやり直しを実行する必要があります。そうしない場合には、NetworkPolicy オブジェクトが適切に機能しなくなる可能性があります。
ヘルパースクリプトを使うと、NetID’s の修正、以前に分離した namespace を分離するための NetworkPolicy オブジェクトの作成、および以前に結合した namespace 間の接続の有効化を実行できます。
ovs-multitenant プラグインを実行した状態でヘルパースクリプトを使用して ovs-networkpolicy プラグインを移行するには、以下の手順に従ってください。
スクリプトをダウンロードし、実行ファイルパーミッションを追加します。
curl -O https://raw.githubusercontent.com/openshift/origin/master/contrib/migration/migrate-network-policy.sh chmod a+x migrate-network-policy.sh
$ curl -O https://raw.githubusercontent.com/openshift/origin/master/contrib/migration/migrate-network-policy.sh $ chmod a+x migrate-network-policy.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトを実行します (クラスター管理者ロールが必要です)。
./migrate-network-policy.sh
$ ./migrate-network-policy.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow
このスクリプトを実行すると、すべての namespace が他のすべての namespace から完全に分離されるので、ovs-networkpolicy プラグインへの移行が完了するまでは、異なる namespace にある Pod 間で接続を試行してもこれに失敗します。
新たに作成した namespace に同じポリシーをデフォルトで適用したい場合には、移行スクリプトで作成した default-deny および allow-from-global-namespaces ポリシーと一致する デフォルトの NetworkPolicy オブジェクトが作成されるように設定します。
スクリプトが失敗するか他のエラーが発生した場合、または ovs-multitenant プラグインに戻したい場合は、移行取り消し (un-migration) スクリプトを使用します。このスクリプトは移行スクリプトが実行した変更を取り消し、以前に結合した namespace を再度結合します。
15.7. クラスターネットワークへの外部アクセス
OpenShift Container Platform の外部にあるホストがクラスターネットワークへのアクセスを要求した場合、ユーザーには 2 つの選択肢があります。
- ホストを OpenShift Container Platform ノードとして設定する。ただし、これには スケジュール対象外 (unschedulable)のマークを付け、マスターがこれにコンテナーをスケジュールできないようにします。
- ユーザーのホストとクラスターネットワーク上のホストの間にトンネルを作成する。
上記のオプションはどちらも OpenShift SDN 内での edge ロードバランサーからコンテナーへのルーティングを設定するための実践的ユースケースの一部として本ドキュメントで紹介されています。
15.8. Flannel の使用
デフォルトの SDN の代わりとして、OpenShift Container Platform は、flannel ベースのネットワークをインストールするための Ansible Playbook を提供しています。これは、SDN に依存しているクラウドプロバイダーのプラットフォーム (Red Hat OpenStack Platform など) で OpenShift Container Platform を実行していて、両方のプラットフォームでパケットのカプセル化を 2 回実行することを避けたい場合に役立ちます。
Flannel は、すべてのコンテナーに単一の IP ネットワーク空間を使用し、隣接する空間のサブセットを各インスタンスに割り当てることを可能にします。これにより、コンテナーは何にも妨げられずに同じネットワーク空間内の任意の IP へ接続を試みることができます。これはネットワークを使ってアプリケーション内にあるコンテナーを別のアプリケーションから分離することができないために、マルチテナンシーを妨げます。
マルチテナンシーの分離とパフォーマンスのどちらを優先するかに応じて、内部ネットワークに OpenShift SDN (マルチテナンシー) と Flannel (パフォーマンス) のいずれか適切な方を選択する必要があります。
Flannel は、Red Hat OpenStack Platform の OpenShift Container Platform のみでサポートされています。
Neutron の現行バージョンはデフォルトで、各ポートに対するポートセキュリティーが有効になっているので、ポート自体のアドレスと異なる MAC アドレスを使ったパケットの送受信を実行できません。Flannel は、仮想の MAC アドレスと IP アドレスを作成し、パケットをポート上で送受信する必要があります。したがって、Flannel のトラフィックを実行するポートでは、ポートセキュリティーを無効にしておく必要があります。
OpenShift Container Platform クラスターで Flannel を無効にするには、以下を実行します。
Neutron のポートセキュリティーコントロールは、Flannel と互換性を持つように設定される必要があります。Red Hat OpenStack Platform のデフォルト設定では、
port_securityのユーザーコントロールは無効にされています。Neutron を、ユーザーが個々のポートでport_security設定を制御できるように設定します。Neutron サーバーで、以下を /etc/neutron/plugins/ml2/ml2_conf.ini ファイルに追加します。
[ml2] ... extension_drivers = port_security
[ml2] ... extension_drivers = port_securityCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次に、Neutron のサービスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Red Hat OpenStack Platform で OpenShift Container Platform インスタンスが作成されている間に、ポートのポートセキュリティーとセキュリティーグループの両方を無効にします。ここで、コンテナーネットワークの Flannel インターフェースは以下のようになります。
neutron port-update $port --no-security-groups --port-security-enabled=False
neutron port-update $port --no-security-groups --port-security-enabled=FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Flannel は、ノードのサブネットを設定し、割り当てるために etcd からの情報を収集します。したがって、etcd ホストに割り当てられるセキュリティーグループは、ノードからポート 2379/tcp へのアクセスを許可し、ノードのセキュリティーグループは etcd ホストでのそのポートへの egress 通信を許可する必要があります。
インストールを実行する前に以下の変数を Ansible インベントリーファイルに設定します。
openshift_use_openshift_sdn=false openshift_use_flannel=true flannel_interface=eth0
openshift_use_openshift_sdn=false1 openshift_use_flannel=true2 flannel_interface=eth0Copy to Clipboard Copied! Toggle word wrap Toggle overflow オプションで、
flannel_interface変数を使用してホスト間の通信に使用するインターフェースを指定することができます。この変数がない場合は、OpenShift Container Platform インストールではデフォルトのインターフェースが使用されます。注記Flannel を使用した Pod とサービスのカスタムのネットワーク CIDR は、今後のリリースでサポートされる予定です。BZ#1473858
OpenShift Container Platform をインストールした後、iptables の一連のルールを各 OpenShift Container Platform ノードに追加します。
iptables -A DOCKER -p all -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -A DOCKER -p all -j ACCEPT iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADECopy to Clipboard Copied! Toggle word wrap Toggle overflow これらの変更を /etc/sysconfig/iptables で永続化するには、すべてのノードで以下のコマンドを使用します。
cp /etc/sysconfig/iptables{,.orig} sh -c "tac /etc/sysconfig/iptables.orig | sed -e '0,/:DOCKER -/ s/:DOCKER -/:DOCKER ACCEPT/' | awk '"\!"p && /POSTROUTING/{print \"-A POSTROUTING -o eth1 -j MASQUERADE\"; p=1} 1' | tac > /etc/sysconfig/iptables"cp /etc/sysconfig/iptables{,.orig} sh -c "tac /etc/sysconfig/iptables.orig | sed -e '0,/:DOCKER -/ s/:DOCKER -/:DOCKER ACCEPT/' | awk '"\!"p && /POSTROUTING/{print \"-A POSTROUTING -o eth1 -j MASQUERADE\"; p=1} 1' | tac > /etc/sysconfig/iptables"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記iptables-saveコマンドは、現在の インメモリー の iptables ルールをすべて保存します。ただし、Docker、Kubernetes、OpenShift Container Platform では永続化することが意図されていない iptables ルール (サービスなど) が多数作成されるために、これらのルールを保存すると問題が発生する可能性があります。
コンテナーのトラフィックを OpenShift Container Platform の残りのトラフィックから分離するには、分離されたテナントネットワークを作成し、すべてのノードをこれに割り当てることを推奨します。異なるネットワークインターフェース (eth1) を使用している場合は、インターフェースをブート時に /etc/sysconfig/network-scripts/ifcfg-eth1 ファイルを使用して起動するように設定してください。
第16章 Nuage SDN の設定
16.1. Nuage SDN と OpenShift Container Platform
Nuage Networks Virtualized Services Platform (VSP) は、仮想ネットワークとソフトウェアによるネットワーク制御 (SDN) インフラストラクチャーを Docker コンテナー環境に提供し、IT 運用を単純化して OpenShift Container Platform のネイティブなネットワーク機能を拡張します。
Nuage Networks VSP は、OpenShift Container Platform で実行される Docker ベースのアプリケーションに対応し、Pod と従来のワークロード間の仮想ネットワークのプロビジョニングを加速化し、セキュリティーポリシーをクラウドインフラストラクチャー全体で有効にします。また、セキュリティーアプライアンスによる、コンテナーアプリケーション用の詳細なセキュリティーとマイクロセグメンテーションポリシーの組み込みを自動化します。
VSP を OpenShift Container Platform のアプリケーションワークフローに統合することにより、DevOps チームが直面するネットワークのラグを取り除き、ビジネスアプリケーションのより迅速な調整と更新を可能にします。また、VSP は OpenShift Container Platform のさまざまなワークフローに対応し、ユーザーがポリシーベースの自動化によって使いやすさと完全な制御のいずれかを選択できる各種シナリオに対応します。
VSP を OpenShift Container Platform に統合する方法についての詳細は、「Networking」を参照してください。
16.2. 開発者のワークフロー
ワークフローは開発者環境で使用され、ネットワークのセットアップ時に開発者のインプットはほとんど必要ありません。ここでは nuage-openshift-monitor は、OpenShift Container Platform プロジェクトで作成される Pod の適切なポリシーとネットワークを提供するために必要な、VSP 構成 (ゾーン、サブネットなど) を作成します。プロジェクトが作成されると、nuage-openshift-monitor がそのプロジェクトのデフォルトのゾーンとデフォルトのサブネットを作成します。指定のプロジェクトに作成されたデフォルトのサブネットが使い果たされると、nuage-openshift-monitor が追加のサブネットを動的に作成します。
プロジェクト間の分離を確保するため、各 OpenShift Container Platform プロジェクトに個別の VSP ゾーンが作成されます。
16.3. オペレーションワークフロー
このワークフローは、アプリケーションをロールアウトするオペレーションチームが使用します。このワークフローでは、まずネットワークとセキュリティーポリシーが、アプリケーションをデプロイするために組織が規定するルールに従って VSD に設定されます。管理ユーザーは、複数のゾーンとサブネットを作成し、ラベルを使ってそれらを同じプロジェクトにマップすることがあります。Pod をスピンアップする一方で、ユーザーは、Pod が接続すべきネットワークと、ポリシーが適用されるべきネットワークを Nuage Label を使って指定します。これにより、デプロイメントでプロジェクト間およびプロジェクト内のトラフィックを詳細に制御できます。たとえば、プロジェクト間の通信はプロジェクトベースで有効にされますが、この方法は、プロジェクトを共有プロジェクトにデプロイされている共通サービスに接続するために使用できます。
16.4. インストール
VSP と OpenShift Container Platform の統合は、仮想マシン (VM) とベアメタルの OpenShift Container Platform インストールの両方で機能します。
高可用性 (HA) を備えた環境は、複数マスターと複数ノードを使って設定することができます。
マルチマスターモードによる Nuage VSP 統合は、このセクションで説明するネイティブの HA 設定方法のみに対応しています。この統合は、負荷分散ソリューション (デフォルトは HAProxy) と組み合わせることもできます。インベントリーファイルには、3 つのマスターホスト、ノード、etcd サーバー、およびすべてのマスターホスト上でマスター API の負荷を分散するための HAProxy として機能するホストが含まれます。HAProxy ホストはインベントリーファイルの [lb] セクションに定義され、Ansible が HAProxy を負荷分散ソリューションとして自動的にインストールし、設定することを可能にします。
Ansible ノードファイルでは、Nuage VSP をネットワークプラグインとしてセットアップするために、以下のパラーメーターを指定する必要があります。
第17章 Amazon Web サービス (AWS) の設定
17.1. 概要
OpenShift Container Platform は、AWS ボリュームをアプリケーションデータの永続ストレージとして使用するなど、AWS EC2 インフラストラクチャーにアクセスできるように設定できます。これを実行するには、AWS を設定した後に OpenShift Container Platform ホストで追加の設定を行う必要があります。
17.2. パーミッション
OpenShift Container Platform で AWS を設定するには以下のパーミッションが必要です。
|
Elastic Compute Cloud(EC2) |
|
|
Elastic Load Balancing |
|
|
Elastic Compute Cloud(EC2) |
|
-
マスターホスト、ノードホスト、サブネットにはすべて、
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)のタグが必要です。 1 つのセキュリティーグループ (ノードにリンクされていることが望ましい) に
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)タグが必要です。-
すべてのセキュリティーグループに
kubernetes.io/cluster/<clusterid>,Value=(owned|shared)のタグを付けないでください。その場合、Elastic Load Balancing (ELB) がロードバランサーを作成できなくなります。
-
すべてのセキュリティーグループに
17.3. セキュリティーグループの設定
AWS に OpenShift Container Platform をインストールする際は、適切なセキュリティーグループがセットアップされていることを確認してください。
セキュリティーグループにはいくつかのポートを設定しておく必要があり、それらがないとインストールは失敗します。また、インストールしようとしているクラスターの設定によっては、追加のポートが必要になる場合があります。セキュリティーグループの詳細、およびその適切な調整方法については、「必要なポート」を参照してください。
|
すべての OpenShift Container Platform ホスト |
|
|
etcd セキュリティーグループ |
|
|
マスターのセキュリティーグループ |
|
|
ノードのセキュリティーグループ |
|
|
インフラストラクチャーノード (OpenShift Container Platform ルーターをホストできるノード) |
|
|
CRI-O |
CRI-O を使用している場合は、tcp/10010 を開き、 |
マスターまたはルートの負荷分散のために外部のロードバランサー (ELB) を設定する場合は、ELB の Ingress および Egress のセキュリティーグループを設定することも必要になります。
17.3.1. 検出された IP アドレスとホスト名の上書き
AWS では、以下のような場合に変数の上書きが必要になります。
| 変数 | 使用法 |
|---|---|
|
|
ユーザーが |
|
|
複数のネットワークインターフェースを設定しており、デフォルト以外のインターフェースを使用することを検討している。ユーザーは |
|
|
|
|
|
|
openshift_hostname がメタデータで提供される private-dns-name 値以外の値に設定される場合、それらのプロバイダーのネイティブクラウド統合は機能しなくなります。
EC2 ホストの場合にはとくに、DNS host names と DNS resolution の両方が有効にされている VPC にデプロイされる必要があります。openshift_hostname は上書きできません。
17.4. AWS 変数の設定
必要な AWS 変数を設定するには、OpenShift Container Platform のマスターとノード両方のすべてのホストに、/etc/origin/cloudprovider/aws.confファイルを以下の内容で作成します。
[Global] Zone = us-east-1c
[Global]
Zone = us-east-1c - 1
- これは AWS インスタンスのアベイラビリティーゾーンであり、EBS ボリュームがある場所です。この情報は AWS マネジメントコンソールから取得されます。
17.5. OpenShift Container Platform での AWS の設定
AWS は OpenShift Container Platform に 2 通りの方法で設定できます。
17.5.1. Ansible を使用した AWS についての OpenShift Container Platform の設定
AWS は、通常インストール (Advanced installation) の実行中に、openshift_cloudprovider_aws_access_key、openshift_cloudprovider_aws_secret_key、openshift_cloudprovider_kind、openshift_clusterid の各パラメーターを使って設定することができます。これらはインベントリーファイルで設定できます。
Ansible を使用した AWS の設定例
Ansible が AWS を設定する際に、必要な変更が以下のファイルに自動的に実行されます。
- /etc/origin/cloudprovider/aws.conf
- /etc/origin/master/master-config.yaml
- /etc/origin/node/node-config.yaml
- /etc/sysconfig/atomic-openshift-master-api
- /etc/sysconfig/atomic-openshift-master-controllers
- /etc/sysconfig/atomic-openshift-node
17.5.2. 手動による AWS についての OpenShift Container Platform マスターの設定
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、apiServerArguments と controllerArguments の各セクションの内容を更新します。
現時点では、クラウドプロバイダーの統合を正常に機能させるため、nodeName は AWS のインスタンス名と一致している必要があります。また、この名前は RFC1123 に準拠している必要もあります。
コンテナー化インストールをトリガーする場合、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、aws.conf は /etc/ ではなく /etc/origin/ になければなりません。
17.5.3. 手動による AWS についての OpenShift Container Platform ノードの設定
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、kubeletArguments セクションの内容を更新します。
kubeletArguments:
cloud-provider:
- "aws"
cloud-config:
- "/etc/origin/cloudprovider/aws.conf"
kubeletArguments:
cloud-provider:
- "aws"
cloud-config:
- "/etc/origin/cloudprovider/aws.conf"コンテナー化インストールをトリガーする場合、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、aws.conf は /etc/ ではなく /etc/origin/ になければなりません。
17.5.4. キーと値のアクセスペアの手動設定
以下の環境変数が、マスターの /etc/sysconfig/atomic-openshift-master-api ファイルと /etc/sysconfig/atomic-openshift-master-controllers ファイル、およびノードの /etc/sysconfig/atomic-openshift-node ファイルに設定されていることを確認します。
AWS_ACCESS_KEY_ID=<key_ID> AWS_SECRET_ACCESS_KEY=<secret_key>
AWS_ACCESS_KEY_ID=<key_ID>
AWS_SECRET_ACCESS_KEY=<secret_key>アクセスキーは、AWS IAM ユーザーを設定する際に取得されます。
17.6. 設定変更の適用
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-node
クラウドプロバイダーを不使用から使用に切り替えるとエラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id (クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードホストで OpenShift Container Platform サービスを再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に使用していた各ノードのラベルを再度追加します。
17.7. クラスターに対する AWS のラベリング
OpenShift Container Platform バージョン 3.7 以降の atomic-openshift-installer では、AWS プロバイダー認証情報を設定している場合に、すべてのホストにラベルが付けられていることを確認することも必要になります。
クラスターに関連付けられているリソースを正確に特定するには、キー kubernetes.io/cluster/<clusterid> でリソースにタグを付けます。
-
<clusterid>はクラスターに固有の名前です。
該当の値を、ノードがこのクラスターだけに所属する場合には owned に、また、他のシステムとリソースが共有されている場合には shared に設定します。
すべてのリソースに kubernetes.io/cluster/<clusterid>,Value=(owned|shared) タグを付けることで、複数ゾーンまたは複数クラスターに関連する潜在的な問題を回避できます。
OpenShift Container Platform 3.6 よりも前のバージョンでは、これは Key=KubernetesCluster,Value=clusterid でした。
OpenShift Container Platform へのラベル付けとタグ付けに関する詳細は、「Pods and Services」を参照してください。
17.7.1. タグを必要とするリソース
タグ付けが必要なリソースは以下の 4 種類です。
- インスタンス
- セキュリティーグループ
- ロードバランサー
- EBS ボリューム
17.7.2. 既存クラスターへのタグ付け
クラスターは kubernetes.io/cluster/<clusterid>,Value=(owned|shared) タグの値を使用して、AWS クラスターに所属するリソースを判断します。したがって、関連のリソースはすべて、そのキーの同じ値を使用して kubernetes.io/cluster/<clusterid>,Value=(owned|shared) タグでラベルを付ける必要があります。これらのリソースには以下が含まれます。
- 全ホスト
- AWS インスタンスで使用する関連のロードバランサーすべて
EBS ボリュームすべて。タグ付けが必要な EBS ボリュームは以下を使用して見つけることができます。
oc get pv -o json|jq '.items[].spec.awsElasticBlockStore.volumeID'
$ oc get pv -o json|jq '.items[].spec.awsElasticBlockStore.volumeID'Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS インスタンスで使用する関連のセキュリティーグループすべて
注記すべての既存セキュリティーグループに
kubernetes.io/cluster/<name>,Value=<clusterid>のタグを付けないでください。その場合、Elastic Load Balancing (ELB) がロードバランサーを作成できなくなります。
リソースにタグを付けた後に、マスターサービスをマスター上で、ノードサービスをすべてのノード上で再起動します。「設定変更の適用」を参照してください。
第18章 OpenStack の設定
18.1. 概要
OpenShift Container Platform は、OpenStack にデプロイする際に、OpenStack Cinder ボリュームをアプリケーションデータの永続ストレージとして使用など、OpenStack インフラストラクチャーにアクセスするように設定できます。
18.2. パーミッション
OpenShift Container Platform に OpenStack を設定するには、以下のロールが必要です。
|
member |
アセット (インスタンス、ネットワーキングポート、Floating IP、ボリュームなど) を作成するために、テナント member ロールが必要になります。 |
18.3. セキュリティーグループの設定
OpenStack に OpenShift Container Platform を インストールする際は、適切なセキュリティーグループがセットアップされていることを確認します。
セキュリティーグループにはいくつかのポートを設定しておく必要があり、それらがないとインストールは失敗します。また、インストールしようとしているクラスターの設定によっては、追加のポートが必要になる場合があります。セキュリティーグループの詳細、およびその適切な調整方法については、「必要なポート」を参照してください。
|
すべての OpenShift Container Platform ホスト |
|
|
etcd セキュリティーグループ |
|
|
マスターのセキュリティーグループ |
|
|
ノードのセキュリティーグループ |
|
|
インフラストラクチャーノード (OpenShift Container Platform ルーターをホストできるノード) |
|
|
CRI-O |
CRI-O を使用している場合は、tcp/10010 を開き、 |
マスターまたはルートの負荷分散のために外部のロードバランサー (ELB) を設定する場合は、ELB の Ingress および Egress のセキュリティーグループを設定することも必要になります。
18.4. OpenStack 変数の設定
必要な OpenStack 変数を設定するには、OpenShift Container Platform のマスターとノード両方のすべてのホストに、/etc/cloud.conf ファイルを以下の内容で作成します。
OS_ 変数の値については OpenStack の管理者にお問い合わせください。この値は通常 OpenStack の設定で使用されます。
18.5. OpenStack についての OpenShift Container Platform マスターの設定
OpenStack は、OpenShift Container Platform のマスターとノードの各ホストに以下の 2 通りの方法で設定できます。
18.5.1. Ansible を使用した OpenStack についての OpenShift Container Platform の設定
OpenStack は、通常インストール (Advanced installation) の実行中に以下のパラメーターを使って設定することができます。これらはインベントリーファイルで設定できます。
-
openshift_cloudprovider_kind -
openshift_cloudprovider_openstack_auth_url -
openshift_cloudprovider_openstack_username -
openshift_cloudprovider_openstack_password -
openshift_cloudprovider_openstack_domain_id -
openshift_cloudprovider_openstack_domain_name -
openshift_cloudprovider_openstack_tenant_id -
openshift_cloudprovider_openstack_tenant_name -
openshift_cloudprovider_openstack_region -
openshift_cloudprovider_openstack_lb_subnet_id
Ansible インベントリーファイルのパラメーター値に、#, { or } などの特殊文字が含まれている場合、値をダブルエスケープ (double-escape) する必要があります (値を単一と二重引用符で囲みます)。たとえば、mypasswordwith###hashsigns を変数 openshift_cloudprovider_openstack_password の値として使用し、これを Ansible ホストインベントリーファイルで openshift_cloudprovider_openstack_password='"mypasswordwith###hashsigns"' として宣言します。
例18.1 Ansible を使用した OpenStack の設定例
18.5.2. 手動による OpenStack についての OpenShift Container Platform マスターの設定
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、apiServerArguments と controllerArguments の各セクションの内容を更新します。
コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、cloud.conf は /etc/ ではなく /etc/origin/ になければなりません。
18.5.3. 手動による OpenStack についての OpenShift Container Platform ノードの設定
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、kubeletArguments と nodeName の各セクションの内容を更新します。
- 1
- ノードが実行される OpenStack インスタンスの名前 (仮想マシンの名前)。
現時点では、クラウドプロバイダーの統合を正常に機能させるため、nodeName は Openstack のインスタンス名と一致していなければなりません。また、この名前は RFC1123 に準拠している必要もあります。
コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、cloud.conf は /etc/ ではなく /etc/origin/ になければなりません。
18.5.4. Ansible Playbook を使用した OpenShift Container Platform のインストール
OpenStack インストール Playbook は、テクノロジープレビュー機能のみとなっています。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) ではサポートされていません。これらは、機能的に完全でない可能性があり、Red Hat では実稼働環境での使用を推奨しません。テクノロジープレビュー機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様に機能性をテストしていただき、開発プロセス中にフィードバックをお寄せいただくことを目的としています。Red Hat テクノロジープレビュー機能のサポート対象範囲に関する詳しい情報は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
OpenShift Container Platform を既存の OpenStack インストールにインストールするには、OpenStack Playbook を使用します。詳細の前提条件を含む Playbook についての詳細は、OpenStack Provisioning readme ファイルを参照してください。
Playbook を実行するには、以下のコマンドを実行します。
ansible-playbook --user openshift \ -i openshift-ansible/playbooks/openstack/inventory.py \ -i inventory \ openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml
$ ansible-playbook --user openshift \
-i openshift-ansible/playbooks/openstack/inventory.py \
-i inventory \
openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml18.6. 設定変更の適用
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-node
クラウドプロバイダーを不使用から使用に切り替えるとエラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id (クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードホストで OpenShift Container Platform サービスを再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に使用していた各ノードのラベルを再度追加します。
第19章 GCE の設定
19.1. 概要
OpenShift Container Platform は、Google Compute Engine (GCE) ボリュームをアプリケーションデータの永続ストレージとして使用するなど、GCE インフラストラクチャーにアクセスするように設定することが可能です。これを実行するには、GCE を適切に設定した後に OpenShift Container Platform ホストで追加の設定を行う必要があります。
19.2. パーミッション
OpenShift Container Platform に GCE を設定するには、以下のロールが必要です。
|
roles/owner |
サービスアカウント、クラウドストレージ、インスタンス、イメージ、テンプレート、Cloud DNS エントリーを作成し、ロードバランサーとヘルスチェックをデプロイします。さらに |
19.3. マスターの設定
GCE は、OpenShift Container Platform のマスターホストに 2 通りの方法で設定できます。
19.3.1. Ansible を使用した GCE についての OpenShift Container Platform マスターの設定
GCE は、通常インストール (Advanced installation) の実行中に openshift_cloudprovider_kind パラメーターを使って設定することができます。このパラメーターはインベントリーファイルで設定できます。
-
GCE を使用する際は、
openshift_gcp_projectとopenshift_gcp_prefixの各パラメーターを定義する必要があります。 -
Google Compute Platform を使用してロードバランサーサービスを実行する場合は、ノード (Compute Engine VM インスタンス) に
<openshift_gcp_prefix>ocpタグを付ける必要があります (ocpサフィックスを追加する)。たとえば、openshift_gcp_prefixパラメーターの値がmyclusterに設定される場合、ノードにはmyclusterocpのタグが付けられる必要があります。ネットワークタグを Compute Engine VM インスタンスに追加する方法についての詳細は、「Adding and Removing Network Tags」を参照してください。
Ansible を使用した GCE の設定例
Cloud Provider Configuration openshift_cloudprovider_kind=gce openshift_gcp_project=<projectid> openshift_gcp_prefix=<uid> openshift_gcp_multizone=False
# Cloud Provider Configuration
# openshift_cloudprovider_kind=gce
# openshift_gcp_project=<projectid>
# openshift_gcp_prefix=<uid>
# openshift_gcp_multizone=False Ansible が GCE を設定する際に、以下のファイルがユーザー用に作成されます。
- /etc/origin/cloudprovider/gce.conf
- /etc/origin/master/master-config.yaml
- /etc/origin/node/node-config.yaml
通常インストール (Advanced installation) は、デフォルトでシングルゾーンのサポートを設定します。マルチゾーンのサポートが必要な場合は、「GCE デプロイメントにおけるマルチゾーンサポートの設定」で説明されているように /etc/origin/cloudprovider/gce.conf を編集します。
19.3.2. 手動による GCE についての OpenShift Container Platform マスターの設定
GCE について OpenShift Container Platform マスターを設定するには、以下を実行します。
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、
apiServerArgumentsとcontrollerArgumentsの各セクションの内容を更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、master-config.yaml は/etc/ ではなく /etc/origin/master になければなりません。
OpenShift Container Platform サービスを起動または再起動します。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.4. ノードの設定
GCE について OpenShift Container Platform ノードを設定するには、以下を実行します。
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、
kubeletArgumentsセクションの内容を更新します。kubeletArguments: cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"kubeletArguments: cloud-provider: - "gce" cloud-config: - "/etc/origin/cloudprovider/gce.conf"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
現時点では、クラウドプロバイダーの統合を正常に機能させるため、nodeName は GCE のインスタンス名と一致している必要があります。また、この名前は RFC1123 に準拠している必要もあります。
コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、node-config.yaml は/etc/ ではなく /etc/origin/node になければなりません。
すべてのノードで OpenShift Container Platform サービスを起動または再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5. GCE デプロイメントにおけるマルチゾーンサポートの設定
GCE を手動で設定した場合、マルチゾーンのサポートはデフォルトでは設定されません。
通常インストール (Advanced installation) ではシングルゾーンのサポートがデフォルトで設定されます。
マルチゾーンのサポートを使用するには、以下を実行します。
- OpenShift Container Platform のマスターとノード両方のすべてのホストで、/etc/origin/cloudprovider/gce.confファイルを編集するか、または作成します。
以下の内容を追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
シングルゾーンのサポートに戻すには、multizone 値を false に設定します。
19.6. 設定変更の適用
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-node
クラウドプロバイダーを不使用から使用に切り替えるとエラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id (クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードホストで OpenShift Container Platform サービスを再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に使用していた各ノードのラベルを再度追加します。
第20章 Azure の設定
20.1. 概要
OpenShift Container Platform は、「Microsoft Azure ディスクをアプリケーションデータの永続ストレージとして使用する」など、「Azure インフラストラクチャー」にアクセスするように設定できます。これを実行するには、Microsoft Azure を適切に設定した後に OpenShift Container Platform ホストで追加の設定を行う必要があります。
20.2. パーミッション
OpenShift Container Platform 向けに Microsoft Azure を設定するには、以下のロールが必要です。
|
Contributor |
すべての種類の Microsoft Azure リソースを作成し、管理します。 |
管理者ロールの追加に関する詳細情報は、「Azure サブスクリプション管理者の追加または変更」を参照してください。
20.3. 前提条件
- OpenShift Container Platform バージョン 3.5 以降で、Microsoft Azure Disk を永続ボリュームとして使用する場合には、Azure Cloud Provider を有効化する必要があります。
- Microsoft Azure で実行している OpenShift Container Platform ノードの仮想マシン (VM) はすべて、単一のリソースグループに所属する必要があります。
- Microsoft Azure 仮想マシンは、OpenShift Container Platform ノードと同じにする必要があり、これには大文字を含めることはできません。
Azure Managed Disks を使用する予定の場合:
- OpenShift Container Platform バージョン 3.7 以降が必要です。
- Azure Managed Disks で、仮想マシンを作成する必要があります。
アンマネージドディスクを使用する予定の場合:
- アンマネージドディスクで、仮想マシンを作成する必要があります。
- OpenShift Container Platform クラスターに、カスタムの DNS 設定を使用する場合やクラスターノードが別の Microsoft Azure Virtual Networks (VNet) に含まれる場合には、クラスター内の各ノードが他のノードの IP アドレスを解決できるように、DNS を設定する必要があります。
20.4. Azure 設定ファイル
Azure ついて OpenShift Container Platform を設定するには、各ノードホストに /etc/azure/azure.conf ファイルが必要です。
ファイルが存在しない場合は、ファイルを作成し、以下を追加します。
- 1
- クラスターがデプロイされているサブスクリプションの AAD テナント ID。
- 2
- クラスターがデプロイされている Azure サブスクリプション ID。
- 3
- Azure RM API と対話するための RBAC アクセス権を持つ AAD アプリケーションのクライアント ID。
- 4
- Azure RM API と対話するための RBAC アクセス権を持つ AAD アプリケーションのクライアントシークレット。
- 5
- これがテナント ID と同一であることを確認します (オプション)。
- 6
- Azure VM が属する Azure のリソースグループ名。
- 7
- 特定のクラウドリージョン。
AzurePublicCloudなど。 - 8
- コンパクトな形式の Azure リージョン。
southeastasiaなど (オプション)。 - 9
- インスタンスを含む仮想ネットワーク。ロードバランサー作成時に使用します。
- 10
- インスタンスとロードバランサーに関連付けられているセキュリティーグループ名。
- 11
- ロードバランサーなどのリソースの作成時に使用するように設定されている可用性 (オプション)。
インスタンスへのアクセスに使用される NIC には internal-dns-name が設定されている必要があります。これがないと、ノードはクラスターに再結合できず、コンソールにビルドログを表示できず、oc rsh が正常に機能しなくなる可能性があります。
20.5. マスターの設定
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成し、apiServerArguments と controllerArguments の各セクションの内容を更新します。
コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、master-config.yaml は/etc/ ではなく /etc/origin/master になければなりません。
20.6. ノードの設定
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、
kubeletArgumentsセクションの内容を更新します。kubeletArguments: cloud-provider: - "azure" cloud-config: - "/etc/azure/azure.conf"kubeletArguments: cloud-provider: - "azure" cloud-config: - "/etc/azure/azure.conf"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、node-config.yaml は/etc/ ではなく /etc/origin/node になければなりません。
20.7. 設定変更の適用
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-node
クラウドプロバイダーを不使用から使用に切り替えるとエラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id (クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードホストで OpenShift Container Platform サービスを再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に使用していた各ノードのラベルを再度追加します。
第21章 VMWare vSphere の設定
21.1. 概要
OpenShift Container Platform は、VMWare vSphere VMDK ボリュームをアプリケーションデータの永続ストレージとして使用するなど、VMWare vSphere VMDK ボリュームにアクセスするように設定できます。
vSphere クラウドプロバイダーは、OpenShift Container Platform 内での vSphere の管理対象ストレージの使用を許可します。vSphere クラウドプロバイダーは以下に対応しています。
- ボリューム
- 永続ボリューム
- ストレージクラスとボリュームのプロビジョニング
21.2. VMWare vSphere クラウドプロバイダーの有効化
VMware vSphere を有効化すると、各ノードの仮想マシンに VMware ツールをインストールする必要があります。詳しい情報は、「VMware ツールのインストール」を参照してください。
OpenShift Container Platform で VMWare vSphere クラウドプロバイダーを有効にするには、以下を実行します。
- VM フォルダーを作成し、OpenShift Container Platform ノード VM をこのフォルダーに移動します。
ノードの VM 名が正規表現
[a-z](()?[0-9a-z])?(\.[a-z0-9](([-0-9a-z])?[0-9a-z])?)*に従っていることを確認します。重要VM 名では以下が禁止されています。
- 数字から始めることはできません。
- 大文字を含めることはできません。
-
-以外の特殊文字を含めることはできません。 - 文字数は 3 文字未満、64 文字以上に指定できません。
各ノード VM で
disk.EnableUUIDパラメーターをTRUEに設定します。これにより VMDK は常に一貫した UUID を VM に提供し、ディスクが適切にマウントされるようになります。クラスターに参加するすべての仮想マシンノードについては、以下の GOVC ツールを使用する手順に従ってください。GOVC 環境をセットアップします。
export GOVC_URL='vCenter IP OR FQDN' export GOVC_USERNAME='vCenter User' export GOVC_PASSWORD='vCenter Password' export GOVC_INSECURE=1
export GOVC_URL='vCenter IP OR FQDN' export GOVC_USERNAME='vCenter User' export GOVC_PASSWORD='vCenter Password' export GOVC_INSECURE=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノード VM パスを見つけます。
govc ls /datacenter/vm/<vm-folder-name>
govc ls /datacenter/vm/<vm-folder-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべての VM で disk.EnableUUID を true に設定します。
govc vm.change -e="disk.enableUUID=1" -vm='VM Path'
govc vm.change -e="disk.enableUUID=1" -vm='VM Path'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform ノード VM がテンプレート VM で作成されている場合、
disk.EnableUUID=1をテンプレート VM に設定することができます。このテンプレートからクローン作成される VM はこのプロパティーを継承します。
ロールを作成して、ロールを vSphere クラウドプロバイダーユーザーと vSphere エンティティーに割り当てます。vSphere クラウドプロバイダーでは、vCenter と対話するために以下の権限が必要になります。カスタムロール、ユーザーおよびロールの割り当てを作成する手順については、vSphere Documentation Center を参照してください。
Expand ロール 権限 エンティティー 子への伝播 manage-k8s-node-vms
Resource.AssignVMToPool System.Anonymous System.Read System.View VirtualMachine.Config.AddExistingDisk VirtualMachine.Config.AddNewDisk VirtualMachine.Config.AddRemoveDevice VirtualMachine.Config.RemoveDisk VirtualMachine.Inventory.Create VirtualMachine.Inventory.Delete
クラスター、ホスト、VM フォルダー
Yes
manage-k8s-volumes
Datastore.AllocateSpace Datastore.FileManagement System.Anonymous System.Read System.View
データストア
不可
k8s-system-read-and-spbm-profile-view
StorageProfile.View System.Anonymous System.Read System.View
vCenter
不可
ReadOnly
System.Anonymous System.Read System.View
データセンター、データストアクラスター、データストアストレージフォルダー
不可
vSphere クラウドプロバイダーを有効にすると、ノード名が vCenter インベントリーの VM 名に設定されます。
openshift_hostname 変数は仮想マシンの名前およびそのホスト名に一致する必要があります。openshift_hostname 変数は、node-config.yaml ファイルに nodeName 値を定義します。この値は、コマンド uname -n を使用して判別される nodeName 値と比較されます。不一致の場合、それらのプロバイダーのネイティブクラウド統合は機能しません。
21.3. VMWare vSphere 設定ファイル
VMWare vSphere について OpenShift Container Platform を設定するには、各ノードホストに /etc/origin/cloudprovider/vsphere.conf ファイルが必要です。
ファイルが存在しない場合は、ファイルを作成し、以下を追加します。
- 1
[Global]セクションに設定されるプロパティーは、個別の[VirtualCenter]セクションの設定で上書きされない限り、すべての指定される vcenter で使用されます。- 2
- vSphere クラウドプロバイダーの vCenter ユーザー名。
- 3
- 指定されたユーザーの vCenter パスワード。
- 4
- オプション。vCenter サーバーのポート番号。デフォルトはポート
443になります。 - 5
- vCenter が自己署名証明書を使用している場合は
1に設定します。 - 6
- ノード VM がデプロイされているデータセンターの名前。
- 7
- この Virtual Center の特定の
[Global]プロパティーを上書きします。使用できる設定は[Port]、[user]、[insecure-flag]、[datacenters]です。指定されない設定は[Global]セクションからプルされます。 - 8
- 各種の vSphere Cloud Provider 機能で使用されるプロパティーを設定します。たとえば、動的プロビジョニング、ストレージプロファイルベースのボリュームプロビジョニングなどがこれに含まれます。
- 9
- vCenter サーバーの IP アドレスまたは FQDN。
- 10
- ノード VM の VM ディレクトリーへのパス。
- 11
- ストレージクラスまたは動的プロビジョニングを使ったボリュームのプロビジョニングに使用されるデータストアの名前に設定されます。データストアがストレージディレクトリーにあるか、またはデータストアクラスターのメンバーである場合には、完全パスを指定する必要があります。
- 12
- オプション。ストレージプロファイルベースのボリュームプロビジョニングのダミー VM が作成される必要のあるリソースプールのパスに設定されます。
- 13
- vSphere がノードにアクセスするために使用されるネットワークポートグループに設定されます。これはデフォルトで VM ネットワークと呼ばれます。これは Kubernetes に登録されているノードホストの ExternalIP です。
21.4. マスターの設定
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または 作成し、apiServerArguments と controllerArguments の各セクションの内容を以下で更新します。
コンテナー化インストールをトリガーすると、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、master-config.yaml は/etc/ ではなく /etc/origin/master になければなりません。
21.5. ノードの設定
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成し、
kubeletArgumentsセクションの内容を更新します。kubeletArguments: cloud-provider: - "vsphere"kubeletArguments: cloud-provider: - "vsphere"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要コンテナー化インストールをトリガーする際は、/etc/origin と /var/lib/origin のディレクトリーのみがマスターとノードのコンテナーにマウントされます。したがって、node-config.yaml は/etc/ ではなく /etc/origin/node になければなりません。
21.6. 設定変更の適用
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
# systemctl restart atomic-openshift-node
クラウドプロバイダーを不使用から使用に切り替えるとエラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id (クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードを削除します。
oc delete node <node_name>
$ oc delete node <node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードホストで OpenShift Container Platform サービスを再起動します。
systemctl restart atomic-openshift-node
# systemctl restart atomic-openshift-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 以前に使用していた各ノードのラベルを再度追加します。
21.7. 永続ボリュームのバックアップ
OpenShift Container Platform は、自由にクラスターないのノードにあるボリュームをアタッチしたり、アタッチ解除できるように、「個別の永続ディスク」として新規ボリュームをプロビジョニングします。そのため、スナップショットを使用するボリュームはバックアップできません。
以下の方法で、PV のバックアップを作成します。
- PV を使用してアプリケーションを停止します。
- 永続ディスクのクローンを作成します。
- アプリケーションを再起動します。
- クローンしたディスクのバックアップを作成します。
- クローンしたディスクを削除します。
第22章 ローカルボリュームの設定
22.1. 概要
OpenShift Container Platform は、アプリケーションデータのローカルボリュームにアクセスするように設定できます。
ローカルボリュームは、ローカルにマウントされたファイルシステムを表す永続ボリューム (PV) です。今後は、これらが raw ブロックデバイスに拡張される可能性があります。
ローカルボリュームは hostPath とは異なります。これらには特殊なアノテーションがあり、このアノテーションを使用して PV を使用する Pod を、ローカルボリュームがマウントされているノードと同じノードにスケジュールします。
また、ローカルボリュームには、ローカルにマウントされたデバイスに PV を自動作成するプロビジョナーが含まれます。現時点で、このプロビジョナーは制限が付けられており、これは事前設定されたディレクトリーのみをスキャンします。ボリュームを動的にプロビジョニングする機能はありませんが、今後のリリースで実装される可能性はあります。
ローカルボリュームのプロビジョナーを使用すると、ローカルストレージを OpenShift Container Platform 内で使用することができます。ローカルボリュームのプロビジョナーは以下に対応しています。
- ボリューム
- PV
ローカルボリュームはアルファ機能であり、OpenShift Container Platform の今後のリリースで変更される場合があります。
22.1.1. ローカルボリュームの有効化
すべてのマスターとノードで PersistentLocalVolumes 機能ゲートを有効にします。
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成して
PersistentLocalVolumes=trueをapiServerArgumentsとcontrollerArgumentsの各セクションの下に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を編集するか、または作成して
PersistentLocalVolumes=true機能ゲートをkubeletArgumentsの下に追加します。kubeletArguments: feature-gates: - PersistentLocalVolumes=truekubeletArguments: feature-gates: - PersistentLocalVolumes=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
22.1.2. ローカルボリュームのマウント
すべてのローカルボリュームは、OpenShift Container Platform によって PV として使用される前に手動でマウントする必要があります。
すべてのボリュームは、/mnt/local-storage/<storage-class-name>/<volume> パスにマウントされる必要があります。管理者は、必要に応じてローカルデバイスを作成し (ディスクパーティションまたは LVM などの方法を使用する)、これらのデバイスに適切なファイルシステムを作成して、スクリプトまたは /etc/fstab エントリーを使用してそれらをマウントします。
/etc/fstab エントリーの例
すべてのボリュームは、Docker コンテナー内で実行されているプロセスからアクセスできる必要があります。そのためには、マウントしたファイルシステムのラベルを変更します。
chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/
$ chcon -R unconfined_u:object_r:svirt_sandbox_file_t:s0 /mnt/local-storage/22.1.3. ローカルプロビジョナーの設定
OpenShift Container Platform は、ローカルデバイス用に PV を作成する場合やそれら (の再利用の有効化) が不要になった際のクリーンアップ時に、外部のプロビジョナーを使用します。
- ローカルボリュームのプロビジョナーは大半のプロビジョナーとは異なり、動的なプロビジョニングに対応していません。
- ローカルボリュームのプロビジョナーは、管理者に対し、各ノードでローカルボリュームを事前設定し、それらを discovery ディレクトリーの下にマウントすることを要求します。その後にプロビジョナーは各ボリュームについて PV の作成とクリーンアップを実行してボリュームを管理します。
この外部のプロビジョナーは、ディレクトリーを StorageClasses に関連付けるために ConfigMap を使って設定される必要があります。この設定は、プロビジョナーをデプロイする前に作成する必要があります。
(オプション) ローカルボリュームのプロビジョナーおよびその設定用にスタンドアロンの namespace を作成します。例: oc new-project local-storage
上記の設定により、プロビジョナーは以下を作成します。
-
/mnt/local-storage/ssd のすべてのサブディレクトリーについて StorageClass が
local-ssdに設定されている 1 つの PV。 -
/mnt/local-storage/hdd のすべてのサブディレクトリーについて StorageClass が
local-hddに設定されている 1 つの PV。
LocalPersistentVolumes のアルファ機能には、VolumeScheduling のアルファ機能も必要になります。この変更に伴って以下の変更を実行することが必要になります。
-
VolumeScheduling機能ゲートを kube-scheduler と kube-controller-manager の各コンポーネントで有効にする。 -
NoVolumeNodeConflict述語を削除する。デフォルト以外のスケジューラーの場合、ユーザーのスケジューラーポリシーを更新する。 -
CheckVolumeBinding述語は、デフォルト以外のスケジューラーで有効にする必要があります。
22.1.4. ローカルプロビジョナーのデプロイ
プロビジョナーを起動する前に、すべてのローカルデバイスをマウントし、ストレージクラスとそれらのディレクトリーと共に ConfigMap を作成します。
local-storage-provisioner-template.yaml ファイルからローカルプロビジョナーをインストールします。
実行中の Pod を root ユーザーとして許可するサービスアカウントを作成し、hostPath ボリュームを使用して、SELinux コンテキストを使用してローカルボリュームの監視、管理、および消去を実行できるようにします。
oc create serviceaccount local-storage-admin oc adm policy add-scc-to-user privileged -z local-storage-admin
$ oc create serviceaccount local-storage-admin $ oc adm policy add-scc-to-user privileged -z local-storage-adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow プロビジョナー Pod で任意の Pod が作成したローカルボリュームのコンテンツを削除できるようにするには、root 権限と任意の SELinux コンテキストが必要です。ホスト上の /mnt/local-storage パスにアクセスするには hostPath が必要です。
テンプレートをインストールします。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/storage-examples/local-examples/local-storage-provisioner-template.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/storage-examples/local-examples/local-storage-provisioner-template.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow configmap、account、provisioner_imageのパラメーターの値を指定して、テンプレートをインスタンス化します。oc new-app -p CONFIGMAP=local-volume-config \ -p SERVICE_ACCOUNT=local-storage-admin \ -p NAMESPACE=local-storage \ -p PROVISIONER_IMAGE=registry.access.redhat.com/openshift3/local-storage-provisioner:v3.9 \ local-storage-provisioner
$ oc new-app -p CONFIGMAP=local-volume-config \ -p SERVICE_ACCOUNT=local-storage-admin \ -p NAMESPACE=local-storage \ -p PROVISIONER_IMAGE=registry.access.redhat.com/openshift3/local-storage-provisioner:v3.9 \1 local-storage-provisionerCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
v3.9を適切な OpenShift Container Platform のバージョンに置き換えます。
必要なストレージクラスを追加します。
oc create -f ./storage-class-ssd.yaml oc create -f ./storage-class-hdd.yaml
oc create -f ./storage-class-ssd.yaml oc create -f ./storage-class-hdd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow その他の設定オプションについては、テンプレート 参照してください。このテンプレートは、すべてのノード上で Pod を実行する DeamonSet を作成します。Pod は
ConfigMapに指定されるディレクトリーを監視し、それらの PV を自動的に作成します。プロビジョナーは、PV が解放され、すべてのデータの削除が必要になる場合にディレクトリーをクリーンアップできるよう root として実行されます。
22.1.5. 新規デバイスの追加
新規デバイスを追加するには、手動による操作がいくつか必要になります。
- プロビジョナーで DaemonSet を停止します。
- 新規デバイスを使ってノードの適切なディレクトリーにサブディレクトリーを作成し、これをマウントします。
- プロビジョナーを使って DeamonSet を起動します。
上記のいずれかの操作を省くと、適切な PV が作成されなくなることがあります。
第23章 Persistent Volume Claim (永続ボリューム要求) 保護の設定
23.1. 概要
OpenShift Container Platform は Persistent Volume Claim (永続ボリューム要求、PVC) の保護機能を有効にするように設定することができます。これは、Pod に使用されている PVC がシステムから削除されないようにするための機能です。削除するとデータが失われる可能性があるためです。
PVC 保護はアルファ機能であり、OpenShift Container Platform の今後のリリースで変更される場合があります。
23.1.1. PVC 機能の有効化
すべてのマスターとノードで PVCProtection 機能ゲートを有効にするには、以下を実行します。
すべてのマスターでマスター設定ファイル (デフォルトは /etc/origin/master/master-config.yaml) を編集するか、または作成します。
-
PVCProtection=trueをapiServerArgumentsおよびcontrollerArgumentsセクションの下に追加します。 PVCProtection受付プラグイン設定をadmissionConfigセクションの下に追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
すべてのノードでノード設定ファイル (デフォルトは /etc/origin/node/node-config.yaml) を作成し、
PVCProtection=true機能ゲートをkubeletArgumentsの下に追加します。kubeletArguments: feature-gates: - PVCProtection=true
kubeletArguments: feature-gates: - PVCProtection=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow - すべてのマスターとノードで OpenShift Container Platform を再起動して変更を有効にします。
第24章 永続ストレージの設定
24.1. 概要
Kubernetes の永続ボリュームフレームワークにより、お使いの環境で利用可能なネットワークストレージを使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これは、アプリケーションのニーズに応じて初回 OpenShift Container Platform インストールの完了後に行うことができ、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。
このトピックでは、以下のサポートされるボリュームプラグインを使って永続ボリュームを OpenShift Container Platform で設定する方法を説明します。
24.2. NFS を使用した永続ストレージ
24.2.1. 概要
OpenShift Container Platform クラスターは、NFS を使用している永続ストレージを使ってプロビジョニングすることが可能です。永続ボリューム (PV) および Persistent Volume Claim (永続ボリューム要求、PVC) は、プロジェクト全体でボリュームを共有するための便利な方法を提供します。PV 定義に含まれる NFS に固有の情報は、Pod 定義で直接定義することも可能ですが、この方法の場合にはボリュームが一意のクラスターリソースとして作成されされないため、ボリュームが競合の影響を受けやすくなります。
このトピックでは、NFS 永続ストレージタイプの具体的な使用方法について説明します。OpenShift Container Platform と NFS についてある程度理解していることを前提とします。OpenShift Container Platform 永続ボリューム (PV) の一般的なフレームワークの詳細は永続ストレージの概念に関するトピックを参照してください。
24.2.2. プロビジョニング
OpenShift Container Platform でストレージをボリュームとしてマウントするには、ストレージがあらかじめ基礎となるインフラストラクチャーに存在している必要があります。NFS ボリュームをプロビジョニングするには、NFS サーバーの一覧とエクスポートパスのみが必要です。
最初に、PV のオブジェクト定義を作成します。
例24.1 NFS を使用した PV オブジェクト定義
- 1
- ボリュームの名前。これは、各種の
oc <command> podコマンドの PV アイデンティティーです。 - 2
- このボリュームに割り当てられるストレージの量。
- 3
- これはボリュームへのアクセスの制御に関連するように見えますが、実際はラベルの場合と同様に、PVC を PV に一致させるために使用されます。現時点では、
accessModesに基づくアクセスルールは適用されていません。 - 4
- 使用されているボリュームタイプ。この場合は nfs プラグインです。
- 5
- NFS サーバーがエクスポートしているパス。
- 6
- NFS サーバーのホスト名または IP アドレス
- 7
- PV の回収ポリシー。ボリュームが要求から解放されるタイミングでボリュームで実行されることを定義します。有効な選択肢は Retain (デフォルト) と Recycle です。「リソースの回収」を参照してください。
各 NFS ボリュームは、クラスター内のスケジュール可能なすべてのノードによってマウント可能でなければなりません。
定義をファイル (nfs-pv.yaml など) に保存し、PV を作成します。
oc create -f nfs-pv.yaml
$ oc create -f nfs-pv.yaml
persistentvolume "pv0001" createdPV が作成されたことを確認します。
oc get pv
# oc get pv
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
pv0001 <none> 5368709120 RWO Available 31s以下の手順で PVC が作成されます。これは新規 PV にバインドされます。
例24.2 PVC オブジェクト定義
定義をファイル (nfs-claim.yaml など) に保存し、PVC を作成します。
oc create -f nfs-claim.yaml
# oc create -f nfs-claim.yaml24.2.3. ディスククォータの実施
ディスクパーティションを使用して、ディスククォータとサイズ制限を実施することができます。それぞれのパーティションを独自のエクスポートとすることができ、それぞれのエクスポートは 1 つの PV になります。OpenShift Container Platform は PV に固有の名前を適用しますが、NFS ボリュームのサーバーとパスの一意性については管理者に委ねられています。
この方法でクォータを実施すると、開発者は永続ストレージを具体的な量 (10Gi など) で要求することができ、同等かそれ以上の容量の対応するボリュームに一致させることができます。
24.2.4. NFS ボリュームのセキュリティー
このセクションでは、一致するパーミッションや SELinux の考慮点を含む、NFS ボリュームのセキュリティーについて説明します。ユーザーは、POSIX パーミッションやプロセス UID、補助グループおよび SELinux の基礎的な点を理解している必要があります。
NFS ボリュームを実装する前に 「ボリュームのセキュリティー」のトピックをすべてお読みください。
開発者は、Pod 定義の volumes セクションで、PVC を名前で参照するか、または NFS ボリュームのプラグインを直接参照して NFS ストレージを要求します。
NFS サーバーの /etc/exports ファイルにはアクセス可能な NFS ディレクトリーが含まれています。ターゲットの NFS ディレクトリーには、POSIX の所有者とグループ ID があります。OpenShift Container Platform NFS プラグインは、同じ POSIX の所有者とエクスポートされる NFS ディレクトリーにあるパーミッションを使って、コンテナーの NFS ディレクトリーをマウントします。ただし、コンテナーは NFS マウントの所有者と同等の実効 UID では実行されません。これは期待される動作です。
ターゲットの NFS ディレクトリーが NFS サーバーに表示される場合を例に取って見てみましょう。
ls -lZ /opt/nfs -d id nfsnobody
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 5555 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)コンテナーは SELinux ラベルと一致している必要があり、ディレクトリーにアクセスするために UID 65534 (nfsnobody 所有者) か、または補助グループの 5555 のいずれかを使って実行する必要があります。
ここで、所有者 ID 65534 は一例として使用されています。NFS の root_squash が root (0) を nfsnobody (65534) にマップしても、NFS エクスポートは任意の所有者 ID を持つことができます。所有者 65534 は NFS エクスポートには必要ありません。
24.2.4.1. グループ ID
NFS アクセスに対応する際の推奨される方法として、補助グループを使用することができます (NFS エクスポートのパーミッションを変更するオプションがないことを前提としています)。OpenShift Container Platform の補助グループは共有ストレージに使用されます (例: NFS)。これとは対照的に、Ceph RBD や iSCSI などのブロックストレージは、Pod の securityContext で fsGroup SCC ストラテジーと fsGroup の値を使用します。
一般的に、永続ストレージへのアクセスを取得する場合、ユーザー ID ではなく補助グループ ID を使用することが推奨されます。補助グループについては「ボリュームのセキュリティー」トピックで詳しく説明されています。
上記のターゲット NFS ディレクトリーの例で使用したグループ ID は 5555 なので、Pod は、supplementalGroups を使用してグループ ID を Pod レベルの securityContext 定義の下で定義することができます。以下は例になります。
Pod の要件を満たすカスタム SCC が存在しない場合、Pod は 制限付きの SCC に一致する可能性があります。この SCC では、supplementalGroups ストラテジーが RunAsAny に設定されています。これは、指定されるグループ ID は範囲のチェックなしに受け入れられることを意味します。
その結果、上記の Pod は受付をパスして起動します。しかし、グループ ID の範囲をチェックすることが望ましい場合は、「Pod のセキュリティーとカスタム SCC」で説明されているようにカスタム SCC の使用が推奨されます。カスタム SCC は、最小および最大のグループ ID が定義され、グループ ID の範囲チェックが実施され、グループ ID 5555 が許可されるように作成できます。
カスタム SCC を使用するには、最初にそこに適切なサービスアカウントを追加しておく必要があります。たとえば、所定のプロジェクトでは、Pod 仕様において別のサービスアカウントが指定されていない限り、default のサービスアカウントを使用してください。詳細は、「SCC のユーザー、グループまたはプロジェクトへの追加」を参照してください。
24.2.4.2. ユーザー ID
ユーザー ID は、コンテナーイメージまたは Pod 定義で定義できます。ユーザー ID に基づいてストレージアクセスを制御する方法については、「ボリュームのセキュリティー」のトピックで説明されています。NFS 永続ストレージをセットアップする前に、必ず読んでおいてください。
永続ストレージへのアクセスを取得する場合、通常はユーザー ID ではなく 補助グループ ID を使用することが推奨されます。
上記の ターゲット NFS ディレクトリーの例 では、コンテナーは UID を 65534 (ここではグループ ID を省略します) に設定する必要があります。したがって以下を Pod 定義に追加することができます。
デフォルトのプロジェクトと制限付き SCC を前提とする場合は、Pod が要求するユーザー ID 65534 は許可されず、Pod は失敗します。Pod が失敗する理由は以下の通りです。
- 65534 をユーザー ID として要求している。
- ユーザー ID 65534 を許可する SCC を確認するために Pod で利用できるすべての SCC が検査される (実際は SCC のすべてのポリシーがチェックされますが、ここでのフォーカスはユーザー ID になります)。
-
利用可能なすべての SCC は
runAsUserストラテジーに MustRunAsRange を使用するため、UID の範囲チェックが必要である。 - 65534 は SCC またはプロジェクトのユーザー ID 範囲に含まれていない。
一般に、事前定義された SCC は変更しないことが勧められています。ただし、この状況を改善するには、「ボリュームのセキュリティー」のトピックで説明されているようにカスタム SCC を作成することが推奨されます。カスタム SCC は、最小および最大のユーザー ID が定義され、UID 範囲のチェックの実施が設定されており、UID 65534 が許可されるように作成できます。
カスタム SCC を使用するには、最初にそこに適切なサービスアカウントを追加しておく必要があります。たとえば、所定のプロジェクトでは、Pod 仕様において別のサービスアカウントが指定されていない限り、default のサービスアカウントを使用してください。詳細は、「SCC のユーザー、グループまたはプロジェクトへの追加」を参照してください。
24.2.4.3. SELinux
SELinux を使用してストレージアクセスを制御する方法についての詳細は、「ボリュームのセキュリティー」を参照してください。
デフォルトでは、SELinux は Pod からリモートの NFS サーバーへの書き込みを許可していません。NFS ボリュームは正常にマウントされますが、読み取り専用です。
SELinux を各ノードで有効にした状態で NFS ボリュームへの書き込みを有効にするには、以下を実行します。
setsebool -P virt_use_nfs 1
# setsebool -P virt_use_nfs 1
上記の -P オプションは、ブール値をリブート間で継続させます。
virt_use_nfs ブール値は docker-selinux パッケージで定義されます。このブール値が定義されていないことを示すエラーが表示された場合は、このパッケージがインストールされていることを確認してください。
24.2.4.4. エクスポート設定
任意のコンテナーユーザーにボリュームの読み取りと書き出しを許可するには、NFS サーバーにエクスポートされる各ボリュームは以下の条件を満たしている必要があります。
各エクスポートを以下のように指定します。
/<example_fs> *(rw,root_squash)
/<example_fs> *(rw,root_squash)Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイアウォールは、マウントポイントへのトラフィックを許可するように設定する必要があります。
NFSv4 の場合、デフォルトのポート
2049(nfs) とポート111(portmapper) を設定します。NFSv4
iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPT
# iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT # iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPTCopy to Clipboard Copied! Toggle word wrap Toggle overflow NFSv3 の場合、以下の 3 つのポートを設定します。
2049(nfs)、20048(mountd)、111(portmapper)。NFSv3
iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT iptables -I INPUT 1 -p tcp --dport 20048 -j ACCEPT iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPT
# iptables -I INPUT 1 -p tcp --dport 2049 -j ACCEPT # iptables -I INPUT 1 -p tcp --dport 20048 -j ACCEPT # iptables -I INPUT 1 -p tcp --dport 111 -j ACCEPTCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
NFS エクスポートとディレクトリーは、ターゲット Pod からアクセスできるようにセットアップされる必要があります。この場合、エクスポートをコンテナーのプライマリー UID で所有されるように設定するか、または上記の「グループ ID」で説明したように、
supplementalGroupsを使用して Pod にグループアクセスを付与します。Pod のセキュリティーに関する追加情報は、「ボリュームのセキュリティー」のトピックを参照してください。
24.2.5. リソースの回収
NFS は OpenShift Container Platform の再利用可能な プラグインインターフェースを実装します。回収タスクは、それぞれの永続ボリュームに設定されるポリシーに基づいて自動プロセスによって処理されます。
デフォルトでは、PV は Retain に設定されます。Recycle に設定される NFS ボリュームは、要求からの解放後 (このボリュームにバインドされるユーザーの PersistentVolumeClaim の削除後) に除去されます ( rm -rf がこのボリュームで実行されます)。リサイクルされた NFS ボリュームは新規の要求にバインドさせることができます。
PV への要求が解除される (PVC が削除される) と、PV オブジェクトは再利用できません。代わりに、新規の PV が元のボリュームと同じ基本ボリューム情報を使って作成されます。
たとえば、管理者は nfs1 という名前の PV を作成するとします。
ユーザーは、nfs1 にバインドされる PVC1 を作成します。次にユーザーは PVC1 を削除し、nfs1 への要求を解除します。これにより、nfs1 は Released になります。管理者が同じ NFS 共有を利用可能にする必要がある場合には、同じ NFS サーバー情報を使って新規 PV を作成する必要があります。この場合、PV の名前は元の名前とは異なる名前にします。
元の PV を削除して、PV を同じ名前で再作成することは推奨されません。PV のステータスを Released から Available に手動で変更しようとすると、エラーが発生しデータが失われる可能性があります。
Recycle の保持ポリシーを持つ PV はデータを除去 (rm -rf を実行) し、要求について Available というマークを付けます。Recycle の保持ポリシーは、OpenShift Container Platform 3.6 以降で非推奨となっています。Recycler を利用しているユーザーは、代わりに動的プロビジョニングとボリュームの削除機能を使用してください。
24.2.6. 自動化
クラスターは、NFS を使用している永続ストレージを使って以下の方法でプロビジョニングすることができます。
- ディスクパーティションを使ってストレージクォータを実施する。
- 要求を持つプロジェクトにボリュームを制限してセキュリティーを実施する。
- 破棄されたリソースの回収を各 PV に設定する。
スクリプトを使って上記タスクを自動化する方法は多数あります。まずは Ansible Playbook のサンプルを使用して開始することができます。
24.2.7. その他の設定とトラブルシューティング
適切なエクスポートとセキュリティーマッピングを行うため、使用している NFS のバージョンおよびその設定方法に応じて追加の設定が必要になることがあります。以下は例になります。
|
NFSv4 のマウントにすべてのファイルの所有者が nobody:nobody と誤って表示される。 |
|
|
NFSv4 の ID マッピングが無効になっている |
|
24.3. Red Hat Gluster Storage を使用する永続ストレージ
24.3.1. 概要
Red Hat Gluster Storage は、OpenShift Container Platform の永続ストレージと動的プロビジョニングを提供するように設定でき、OpenShift Container Platform 内のコンテナー化ストレージ (Container-Native Storage) としても、独自のノード上の非コンテナー化ストレージ (Container-Ready Storage) としても使用できます。
24.3.1.1. Container-Native Storage
Red Hat Gluster Storage は、Container-Native Storage を使って、コンテナー化されたディレクトリーを OpenShift Container Platform ノードで実行します。それにより、コンピュートおよびストレージインスタンスをスケジュールでき、同じハードウェアのセットから実行することができます。
図24.1 アーキテクチャー: Container-Native Storage
Container-Native Storage は Red Hat Gluster Storage 3.1 update 3 より利用能になっています。詳細については、「Container-Native Storage for OpenShift Container Platform」を参照してください。
24.3.1.2. Container-Ready Storage
Container-Ready Storage を使用することで、Red Hat Gluster Storage は独自の専用ノードで実行され、GlusterFS のボリューム管理 REST サービスの heketi のインスタンスによって管理されます。heketi サービスは、スタンドアロンまたはコンテナー化のいずれかで実行できます。コンテナー化の場合、簡単なメカニズムで高可用性をサービスに提供できます。ここでは、heketi をコンテナー化した場合の設定に焦点を当てます。
24.3.1.3. スタンドアロンの Red Hat Gluster Storage
スタンドアロンの Red Hat Gluster Storage クラスターが環境で使用できる場合、OpenShift Container Platform の GlusterFS ボリュームプラグインを使用してそのクラスター上でボリュームを使用することができます。この方法は、アプリケーションが専用のコンピュートノード、OpenShift Container Platform クラスターで実行され、ストレージはその専用ノードから提供される従来のデプロイメントです。
図24.2 アーキテクチャー: OpenShift Container Platform の GlusterFS ボリュームプラグインを使用したスタンドアロンの Red Hat Gluster Storage クラスター
Red Hat Gluster Storage の詳細については、『Red Hat Gluster Storage Installation Guide』および『Red Hat Gluster Storage Administration Guide』を参照してください。
インフラストラクチャーにおけるストレージの高可用性は、基礎となるストレージのプロバイダーに委ねられています。
24.3.1.4. GlusterFS ボリューム
GlusterFS ボリュームは、POSIX に準拠したファイルシステムを提供し、クラスター上の 1 つ以上のノードにまたがる 1 つ以上の「ブリック」から構成されます。このブリックは所定のストレージノード上のディレクトリーであり、一般的にブロックストレージデバイスのマウントポイントになります。GlusterFS はボリュームの設定に応じて、所定のボリュームのブリック間でファイルの分散および複製を処理します。
heketi は、ボリューム管理において、作成、削除、サイズ変更といった一般的な操作に使用することが推奨されます。OpenShift Container Platform は、GlusterFS プロビジョナーを使用する際に heketi が存在していることを前提としています。heketi はデフォルトで、レプリカ数が 3 のボリュームを作成します。このボリュームの各ファイルには 3 つの異なるノードをまたがる 3 つのコピーがあります。したがって、heketi が使用する Red Hat Gluster Storage クラスターでは 3 つ以上のノードを利用可能にすることが推奨されます。
GlusterFS ボリュームに使用可能な機能は多数ありますが、これらについては本書では扱いません。
24.3.1.5. gluster-block ボリューム
gluster-block ボリュームは、iSCSI 上にマウントすることが可能なボリュームです。既存の GlusterFS ボリュームにファイルを作成し、そのファイルをブロックデバイスとして iSCSI ターゲットを介して提供することでマウントできます。このような GlusterFS ボリュームは、ブロックホスティングボリュームと呼ばれます。
gluster-block ボリュームにはトレードオフもあります。iSCSI ターゲットとして使用される場合、複数のノード/クライアントでマウントできる GlusterFS ボリュームとは対照的に、gluster-block ボリュームをマウントできるのは 1 回に 1 つのノード/クライアントのみです。ただし、バックエンドのファイルであるため、GlusterFS ボリュームでは一般にコストのかかる操作 (メタデータの参照など) を、GlusterFS ボリュームでの一般的により高速な操作 (読み取り、書き込みなど) に変換することが可能です。それにより、特定の負荷に対するパフォーマンスを大幅に改善できる可能性があります。
現時点では、gluster-block ボリュームは OpenShift ロギングと OpenShift メトリクスストレージにのみを使用することが推奨されます。
24.3.1.6. Gluster S3 ストレージ
Gluster S3 サービスは、ユーザーアプリケーションが S3 インターフェースを介して GlusterFS ストレージへアクセスすることを可能にします。このサービスは GlusterFS の、オブジェクトデータ用とオブジェクトメタデータ用の 2 つのボリュームにバインドされ、受信する S3 REST 要求をボリューム上のファイルシステム操作に変換します。このサービスは OpenShift Container Platform 内の Pod として実行することが推奨されます。
現時点では、Gluster S3 サービスの使用およびインストールはテクノロジープレビューの段階にあります。
24.3.2. 考慮事項
このセクションでは、Red Hat Gluster Storage を OpenShift Container Platform で使用する際に考慮すべきトピックについて取り上げます。
24.3.2.1. ソフトウェア要件
GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。
yum install glusterfs-fuse
# yum install glusterfs-fuseこのパッケージはすべての RHEL システムにインストールされています。ただし、Red Hat Gluster Storage の最新バージョンにアップデートすることを推奨します。そのためには、以下の RPM リポジトリーを有効にする必要があります。
subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms
# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpmsglusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。
yum update glusterfs-fuse
# yum update glusterfs-fuse24.3.2.2. ハードウェア要件
Container-Native Storage または Container-Ready Storage クラスターで使用されるノードは、ストレージノードとみなされます。ストレージノードは異なるクラスターグループに分けられますが、単一ノードは複数のグループに属することはできません。ストレージノードの各グループについては、以下が当てはまります。
- 1 グループあたり 3 つ以上のストレージノードが必要です。
各ストレージノードには 8 GB 以上の RAM が必要です。これにより、Red Hat Gluster Storage Pod、その他のアプリケーションおよび基礎となる OS を実行できます。
- 各 GlusterFS ボリュームはストレージクラスターにあるすべてのストレージノードのメモリー (約 30 MB) も消費します。RAM の合計量は、コンカレントボリュームがいくつ求められているか、またはいくつ予想されるかによって決める必要があります。
各ストレージノードには、現在のデータまたはメタデータを含まない 1 つ以上の raw ブロックデバイスが必要です。それらのブロックデバイス全体は GlusterFS ストレージで使用されます。以下が存在しないことを確認してください。
- パーティションテーブル (GPT または MSDOS)
- ファイルシステムまたは未処理のファイルシステムの署名
- 以前のボリュームグループの LVM2 署名および論理ボリューム
- LVM2 物理ボリュームの LVM2 メタデータ
不確かな場合には、
wipefs -a <device>で上記のすべてを消去する必要があります。
2 つのクラスター、つまりインフラストラクチャーアプリケーション (OpenShift Container レジストリーなど) のストレージ専用のクラスターと一般的なアプリケーションのストレージ専用のクラスターについて計画することをお勧めします。これには、合計で 6 つのストレージノードが必要となりますが、この設定は I/O およびボリューム作成のパフォーマンスへの潜在的な影響を回避するために推奨されます。
24.3.2.3. ストレージのサイジング
GlusterFS クラスターは、そのストレージを利用するアプリケーションの予想されるニーズに基づいてサイズを決定する必要があります。たとえば、OpenShift ロギングと OpenShift メトリクスの両方に適用できるサイジングについてのガイドを参照できます。
その他考慮すべき事項:
Container-Native Storage または Container-Ready Storage クラスターでは、デフォルトの動作により 3 通りのレプリケーションを持つ GlusterFS ボリュームが作成されます。そのため、合計のストレージの計画を立てる際には、必要な容量の 3 倍にする必要があります。
-
例として、各 heketi インスタンスは 2 GB の
heketidbstorageボリュームを作成する場合、ストレージクラスター内の 3 つのノードに合計で 6 GB の raw ストレージが必要になります。この容量は常に必要となり、これをサイジングの際に考慮する必要があります。 - 統合 OpenShift Container レジストリーなどのアプリケーションでは、GlusterFS の単一ボリュームがアプリケーションの複数インスタンスで共有されます。
-
例として、各 heketi インスタンスは 2 GB の
gluster-block ボリュームを使用する場合は、所定のブロックのボリューム容量をフルサイズで保持するための十分な容量を備えた GlusterFS ブロックホスティングボリュームがなければなりません。
- デフォルトでは、このようなブロックホスティングボリュームが存在しない場合、これが設定されたサイズで自動的に 1 つ作成されます。デフォルトのサイズは 100 GB です。クラスター内に新しいブロックホスティングボリュームを作成するための十分なスペースがない場合、ブロックボリュームの作成は失敗します。自動作成の動作、および自動作成されるボリュームのサイズはどちらも設定することが可能です。
- OpenShift ロギングや OpenShift メトリクスなどの gluster-block ボリュームを使用する複数のインスタンスを持つアプリケーションは、各インスタンスにつき 1 つのボリュームを使用します。
- Gluster S3 サービスは、2 つの GlusterFS ボリュームにバインドされます。通常インストーラー (Advanced Installer) を使用したデフォルトのインストールでは、ボリュームはそれぞれ 1 GB となり、合計 6 GB の raw ストレージを使用します。
24.3.2.4. ボリューム操作の動作
作成や削除などのボリューム操作は、さまざまな環境条件の影響を受けることもあれば、アプリケーションに影響を与えることもあります。
アプリケーション Pod が動的にプロビジョニングされた GlusterFS の Persistent Volume Claim (永続ボリューム要求、PVC) を要求する場合は、ボリュームの作成と対応する PVC へのバインドにかかる追加の時間を考慮する必要があります。これはアプリケーション Pod の起動時間に影響します。
注記GlusterFS ボリュームの作成時間は、ボリュームの数に応じて直線的に増加します。たとえば、クラスター内に推奨されるハードウェア仕様を使用する 100 のボリュームがある場合、各ボリュームの作成、割り当て、Pod へのバインドに約 6 秒の時間がかかりました。
PVC が削除されると、基礎となる GlusterFS ボリュームの削除がトリガーされます。PVC は
oc get pvcの出力からすぐに消えますが、ボリュームが完全に削除される訳ではありません。GlusterFS ボリュームは、heketi-cli volume listおよびgluster volume listのコマンドライン出力に表示されなくなったときにのみ削除されていると見なされます。注記GlusterF ボリュームの削除とそのストレージのリサイクルの時間は、アクティブな GlusterFS ボリュームの数に応じて直線的に増加します。保留中のボリューム削除は実行中のアプリケーションに影響しませんが、ストレージ管理者は、とくにリソース消費を大きな規模で調整している場合には、ボリュームの削除にかかる時間を認識し、それを見積もることができるようにしておく必要があります。
24.3.2.5. ボリュームのセキュリティー
このセクションでは、Portable Operating System Interface [Unix 向け] (POSIX) パーミッションや SELinux に関する考慮事項を含む、Red Hat Gluster Storage ボリュームのセキュリティーについて説明します。ボリュームのセキュリティー、POSIX パーミッションおよび SELinux に関する基本を理解していることを前提とします。
24.3.2.5.1. POSIX パーミッション
Red Hat Gluster Storage ボリュームは POSIX 準拠のファイルシステムを表します。そのため、chmod や chown などの標準コマンドラインツールを使用してアクセスパーミッションを管理できます。
Container-Native Storage と Container-Ready Storage では、ボリュームの作成時にボリュームのルートを所有するグループ ID を指定することもできます。静的プロビジョニングの場合、これは heketi-cli ボリューム作成コマンドの一部として指定されます。
heketi-cli volume create --size=100 --gid=10001000
$ heketi-cli volume create --size=100 --gid=10001000このボリュームに関連付けられる PersistentVolume には、PersistentVolume を使用する Pod がファイルシステムにアクセスできるように、グループ ID をアノテーションとして付加する必要があります。このアノテーションは以下の形式で指定します。
pv.beta.kubernetes.io/gid: "<GID>" ---
動的プロビジョニングの場合は、プロビジョナーがグループ ID を自動的に生成し、これを適用します。gidMin および gidMax StorageClass パラメーターを使用してこのグループ ID の選択範囲を制御できます (「動的プロビジョニング」を参照してください)。プロビジョナーは、生成される PersistentVolume にグループ ID をアノテーションとして付ける処理も行います。
24.3.2.5.2. SELinux
デフォルトでは、SELinux は Pod からリモート Red Hat Gluster Storage サーバーへの書き込みを許可しません。SELinux が有効な状態で Red Hat Gluster Storage ボリュームへの書き込みを有効にするには、GlusterFS を実行する各ノードで以下のコマンドを実行します。
sudo setsebool -P virt_sandbox_use_fusefs on sudo setsebool -P virt_use_fusefs on
$ sudo setsebool -P virt_sandbox_use_fusefs on
$ sudo setsebool -P virt_use_fusefs on- 1
-Pオプションを使用すると、再起動した後もブール値が永続化されます。
virt_sandbox_use_fusefs ブール値は、docker-selinux パッケージによって定義されます。このブール値が定義されていないというエラーが表示される場合は、このパッケージがインストールされていることを確認してください。
Atomic Host を使用している場合に、Atomic Host をアップグレードすると、SELinux のブール値が消去されるので、Atomic Host をアップグレードする場合には、これらのブール値を設定し直す必要があります。
24.3.3. サポート要件
Red Hat Gluster Storage と OpenShift Container Platform のサポートされる統合を作成するには、以下の要件が満たされている必要があります。
Container-Ready Storage または スタンドアロンの Red Hat Gluster Storage の場合:
- 最小バージョン: Red Hat Gluster Storage 3.1.3
- すべての Red Hat Gluster Storage ノードに Red Hat Network チャンネルとサブスクリプションマネージャーリポジトリーへの有効なサブスクリプションが必要です。
- Red Hat Gluster Storage ノードは、「Planning Red Hat Gluster Storage Installation」に記載されている要件に準拠している必要があります。
- Red Hat Gluster Storage ノードは、最新のパッチとアップグレードが適用された完全に最新の状態でなければなりません。最新バージョンへのアップグレードについては、『Red Hat Gluster Storage Installation Guide』を参照してください。
- 各 Red Hat Gluster Storage ノードには、完全修飾ドメイン名 (FQDN) が設定されている必要があります。適切な DNS レコードが存在すること、および FQDN が正引きと逆引きの両方の DNS ルックアップで解決できることを確認してください。
24.3.4. インストール
スタンドアロンの Red Hat Gluster Storage の場合、OpenShift Container Platform で使用するためにインストールする必要があるコンポーネントはありません。OpenShift Container Platform には組み込み GlusterFS ボリュームドライバーが付属しており、これを使用して既存のボリュームを既存のクラスターで活用できます。既存のボリュームの使用方法については、「