Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

インストールと設定

OpenShift Container Platform 3.9

OpenShift Container Platform 3.9 のインストールおよび設定

Red Hat OpenShift Documentation Team

概要

『OpenShift のインストールおよび設定』では、ご使用の環境で OpenShift をインストールし、設定するための基本事項を説明します。扱われるトピックを参照して、OpenShift の稼働に必要な一度だけ実行するタスク (one-time task) を実行してください。

第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. ハードウェアの最小要件

システムの要件はホストのタイプによって異なります。

マスター

  • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
  • ベース OS: 「最低限の」インストールオプションと Extras チャンネルの最新パッケージを持つ RHEL 7.3、 7.4、7.5 または RHEL Atomic Host 7.4.5 以降
  • 4 つ以上の vCPU (追加することを強く推奨します)
  • 最小 16 GB RAM (特に etcd がマスター上の同一の場所に配置されている場合、メモリーの追加を強く推奨します)
  • /var/ を含むファイルシステムの最小 40 GB のハードディスク領域。 redcircle 1
  • /usr/local/bin/ を含む最小 1 GB のハードディスク領域。
  • システムの一時ディレクトリーを含むシステムの最小 1 GB のハードディスク領域。 redcircle 2
  • 同一の場所に配置された etcd を含むマスターは最小 4 コアを必要とします。2 コアのシステムは機能しません。

ノード

  • 物理または仮想システム、またはパブリックまたはプライベート IaaS で実行されるインスタンス。
  • ベース OS: リンク: 「最低限の」インストールオプションを持つ RHEL 7.3、7.4、7.5 または RHEL Atomic Host 7.4.5 以降
  • NetworkManager 1.0 以降。
  • 1 vCPU。
  • 最小 8 GB の RAM。
  • /var/ を含むファイルシステムの最小 15 GB のハードディスク領域。 redcircle 1
  • /usr/local/bin/ を含む最小 1 GB のハードディスク領域。
  • システムの一時ディレクトリーを含むシステムの最小 1 GB のハードディスク領域。 redcircle 2
  • Docker のストレージバックエンドのコンテナーを実行するシステムごとに使用する 15 GB 以上の追加の未割り当て領域。詳細は、「Docker ストレージの設定」を参照してください。ノード上で実行されるコンテナーのサイズおよび数によって、追加の領域が必要になる可能性があります。

外部 etcd ノード

  • etcd データ用の最小 20 GB のハードディスク領域。
  • etcd ノードを適切なサイズに設定する方法については、CoreOS etcd ドキュメントの「ハードウェア推奨」セクションを参照してください。
  • 現時点で、OpenShift Container Platform はイメージ、ビルド、およびデプロイメントメタデータを etcd に保存します。定期的に古いリソースを排除する必要があります。これらの多数のリソースを使用する予定の場合は、大量のメモリーと高速 SSD ドライブを搭載したマシンに etcd を配置します。

Ansible コントローラー

Ansible Playbook を実行するホストには、ホストあたり 75MiB 以上の空きメモリーがインベントリーで必要になります。

redcircle 1 /var/ ファイルシステムのサイジング要件を満たすには、デフォルト設定に変更を加える必要があります。インストール時またはインストール後にこの設定を行う方法については、「Managing Storage in Red Hat Enterprise Linux Atomic Host」を参照してください。

redcircle 2 システムの一時ディレクトリーは、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

2.2.1.6. SELinux

Security-Enhanced Linux (SELinux) をすべてのサーバーで有効にしてから OpenShift Container Platform をインストールする必要があります。そうでないと、インストーラーは失敗します。さらに、/etc/selinux/config ファイルで SELINUX=enforcing および SELINUXTYPE=targeted を設定します。

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

2.2.1.7. Red Hat Gluster Storage

GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、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

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 の主要コンポーネントはコンテナーの内部で実行され、名前解決に以下のプロセスを使用します。

  1. デフォルトで、コンテナーはホストから DNS 設定ファイル (/etc/resolv.conf) を受信します。
  2. 次に OpenShift Container Platform は 1 つの DNS 値を Pod に追加します (ノードのネームサーバー値の上)。その値は、dnsIP パラメーターによって /etc/origin/node/node-config.yaml ファイルに定義されます。このパラメーターは、ホストが dnsmasq を使用しているためにデフォルトではホストノードのアドレスに設定されます。
  3. 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_CONTROLLEDno に設定されている場合、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

適切に機能する 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 サーバーで解決できることを確認するには、以下を実行します。

  1. /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

    この例では、10.64.33.1 が DNS サーバーのアドレスです。

  2. /etc/resolv.conf に一覧表示されている DNS サーバーが OpenShift Container Platform 環境のすべてのマスターおよびノードの IP アドレスに対してホスト名を解決できることをテストします。

    $ dig <node_hostname> @<IP_address> +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.101
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

仮想マシンを参照するほとんどすべての場合に、ホスト名を使用する必要があり、使用するホスト名は、各ノードの 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_CONTROLLEDno に設定されている場合、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

この変数を true に設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。

注記

firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。

2.2.2.2.3. 必要なポート

OpenShift Container Platform のインストールは、iptables を使用して各ホストに内部のファイアウォールルール一式を自動的に作成します。ただし、ネットワーク設定でハードウェアベースのファイアウォールなどの外部ファイアウォールを使用する場合、インフラストラクチャーコンポーネントが、特定のプロセスまたはサービスの通信エンドポイントとして機能する特定ポートで相互に通信できることを確認する必要があります。

OpenShift Container Platform で必要な以下のポートがネットワーク上で開いており、ホスト間のアクセスを許可するよう設定されていることを確認してください。設定や使用状況によって、一部はポートはオプションになります。

表2.1 ノード間通信

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

表2.2 ノードからマスターへの通信

53 または 8053

TCP/UDP

クラスターサービス (SkyDNS) の DNS 解決に必要です。3.2 よりも前のインストールまたは 3.2 にアップグレードした環境はポート 53 を使用します。新規インストールはデフォルトで 8053 を使用するため、dnsmasq が設定されることがあります。

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

443 または 8443

TCP

ノードホストがマスター API と通信するために必要です。ノードホストがステータスをポストバックしたり、タスクを受信したりする際に使用します。

表2.3 マスターからノードへの通信

4789

UDP

別個のホストの Pod 間の SDN 通信に必要です。

10250

TCP

マスターは、oc コマンドについての Kubelet を使用してノードホストにプロキシーします。

10010

TCP

CRI-O を使用している場合は、このポートを開き、oc exec および oc rsh 操作を実行できるようにします。

表2.4 マスター間の通信

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 通信に必要です。

表2.5 外部からロードバランサーへの通信

9000

TCP

ネイティブ HA メソッドを選択している場合、HAProxy 統計ページへのアクセスを許可するためのオプションです。

表2.6 外部からマスターへの通信

443 または 8443

TCP

ノードホストがマスター API と通信するために必要です。ノードホストがステータスをポストバックしたり、タスクを受信したりする際に使用します。

8444

TCP

atomic-openshift-master-controllers サービスがリッスンするポートです。/metrics および /healthz エンドポイント用に開いている必要があります。

表2.7 IaaS デプロイメント

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

表2.8 集約ロギング

9200

TCP

Elasticsearch API 用です。Kibana が表示用にログを取得できるようにインフラストラクチャーノードの内部で開かれている必要があります。ルートを使用して Elasticsearch に直接アクセスできるよう外部に開くこともできます。ルートは oc expose を使用して作成できます。

9300

TCP

Elasticsearch のクラスター内での使用向けです。Elasticsearch クラスターのメンバーが相互に通信できるようにインフラストラクチャーノードで内部に開かれている必要があります。

2.2.2.3. 永続ストレージ

Kubernetes の永続ボリュームフレームワークにより、お使いの環境で利用可能なネットワークストレージを使用して、OpenShift Container Platform クラスターに永続ストレージをプロビジョニングできます。これは、アプリケーションのニーズに応じて初回 OpenShift Container Platform インストールの完了後に行うことができ、ユーザーは基礎となるインフラストラクチャーの知識がなくてもこれらのリソースを要求できるようになります。

インストールと設定ガイド』には、NFS, GlusterFSCeph RBDOpenStack CinderAWS Elastic Block Store (EBS)GCE Persistent DisksiSCSI を使用して OpenShift Container Platform クラスターに永続ストレージをプロビジョニングするためのクラスター管理者の手順を記載しています。

2.2.2.4. クラウドプロバイダーの留意事項

OpenShift Container Platform をクラウドプロバイダーにインストールする場合に考慮すべき事柄がいくつかあります。

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
重要

Amazon Web Services の場合は、「検出された IP アドレスとホスト名の上書き」のセクションを参照してください。

検出された共通の設定を確認してみましょう。それらが想定される内容と異なる場合にはそれらを上書きすることができます。

通常インストール (Advanced installation)」トピックでは、利用可能な Ansible 変数を詳しく説明します。

変数使用法

hostname

  • インスタンス自体から内部 IP に解決する。
  • openshift_hostname が上書きする。

ip

  • インスタンスの内部 IP。
  • openshift_ip が上書きする。

public_hostname

  • クラウド外のホストから外部 IP に解決する。
  • プロバイダーの openshift_public_hostname が上書きする。

public_ip

  • インスタンスに関連付けられた外部からアクセス可能な IP。
  • openshift_public_ip が上書きする。

use_openshift_sdn

  • クラウドが GCE でない限り、true になる。
  • openshift_use_openshift_sdn が上書きする。
警告

openshift_hostname がメタデータで提供される private-dns-name 値以外の値に設定される場合、それらのプロバイダーのネイティブクラウド統合は機能しなくなります。

2.2.2.4.2. クラウドプロバイダーのインストール後の設定

インストールプロセスの後に、AWSOpenStack、または 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 サブスクリプションがアタッチされている必要があります。

  1. 各ホストで RHSM に登録します。

    # subscription-manager register --username=<user_name> --password=<password>
  2. RHSM から最新サブスクリプションデータをプルします。

    # subscription-manager refresh
  3. 利用可能なサブスクリプションの一覧を表示します。

    # subscription-manager list --available --matches '*OpenShift*'
  4. 直前のコマンドの出力で、OpenShift Container Platform サブスクリプションのプール ID を見つけ、これをアタッチします。

    # subscription-manager attach --pool=<pool_id>
  5. Yum リポジトリーをすべて無効にします。

    1. 有効にされている RHSM リポジトリーをすべて無効にします。

      # subscription-manager repos --disable="*"
    2. 残りの Yum リポジトリーを一覧表示し、repo id にあるそれらの名前をメモします (ある場合) 。

      # yum repolist
    3. yum-config-manager を使用して、残りの Yum リポジトリーを無効にします。

      # yum-config-manager --disable <repo_id>

      または、すべてのリポジトリーを無効にします。

       yum-config-manager --disable \*

      利用可能なリポジトリーが多い場合には、数分の時間がかかることがあります。

  6. OpenShift Container Platform 3.9 で必要なリポジトリーのみを有効にします。

    # subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-server-ose-3.9-rpms" \
        --enable="rhel-7-fast-datapath-rpms" \
        --enable="rhel-7-server-ansible-2.4-rpms"
    注記

    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 システムの場合:

  1. 以下の基本パッケージをインストールします。

    # yum install wget git net-tools bind-utils yum-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
  2. システムを最新パッケージに更新します。

    # yum update
    # systemctl reboot
  3. RPM ベースのインストーラーを使用して通常インストール (Advanced installation) を実行することを計画している場合は、この手順を省略できます。ただし、 コンテナー化されたインストーラーの使用を計画している場合は、以下を実行します。

    1. atomic パッケージをインストールします。

      # yum install atomic
    2. Docker のインストール に進みます。
  4. RPM ベースの OpenShift Container Platform インストーラーユーティリティーを提供する以下のパッケージをインストールし、Ansible および関連する設定ファイルなどの クイックおよび通常インストール (Advanced installation)方式で必要となる他のツールをプルします。

    # yum install atomic-openshift-utils

RHEL Atomic Host 7 システムの場合:

  1. 最新の Atomic ツリーにアップグレードしてホストが最新の状態にあることを確認します (利用可能な場合)。

    # atomic host upgrade
  2. アップグレードが完了し、以下の起動の準備ができたら、ホストを再起動します。

    # systemctl reboot

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

パッケージのインストールが完了したら、バージョン 1.13 がインストールされていることを確認します。

# 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 はグラフドライバーにイメージとコンテナーを保存します。グラフドライバーは DeviceMapperOverlayFSBtrfs などのプラグ可能なストレージ技術です。これらにはそれぞれメリットとデメリットがあります。たとえば、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) などの一部のアプリケーションで問題が発生することが確認されています。

  1. 以下の 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

      次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。

      # docker-storage-setup                                                                                                                                                                                                                                [5/1868]
      0
      Checking that no-one is using this disk right now ...
      OK
      
      Disk /dev/vdc: 31207 cylinders, 16 heads, 63 sectors/track
      sfdisk:  /dev/vdc: unrecognized partition table type
      
      Old situation:
      sfdisk: No partitions found
      
      New situation:
      Units: sectors of 512 bytes, counting from 0
      
         Device Boot    Start       End   #sectors  Id  System
      /dev/vdc1          2048  31457279   31455232  8e  Linux LVM
      /dev/vdc2             0         -          0   0  Empty
      /dev/vdc3             0         -          0   0  Empty
      /dev/vdc4             0         -          0   0  Empty
      Warning: partition 1 does not start at a cylinder boundary
      Warning: partition 1 does not end at a cylinder boundary
      Warning: no primary partition is marked bootable (active)
      This does not matter for LILO, but the DOS MBR will not boot this disk.
      Successfully wrote the new partition table
      
      Re-reading the partition table ...
      
      If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
      to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
      (See fdisk(8).)
        Physical volume "/dev/vdc1" successfully created
        Volume group "docker-vg" successfully created
        Rounding up size to full physical extent 16.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted docker-vg/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
    • オプション B: 既存の指定されたボリュームグループを使用する。

      /etc/sysconfig/docker-storage-setup で、VG を必要なボリュームグループに設定します。以下は例になります。

      # cat <<EOF > /etc/sysconfig/docker-storage-setup
      VG=docker-vg
      EOF

      次に docker-storage-setup を実行し、出力で docker-pool ボリュームが作成されたことを確認します。

      # docker-storage-setup
        Rounding up size to full physical extent 16.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume docker-vg/docker-pool and docker-vg/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted docker-vg/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
    • オプション C: root ファイルシステムが置かれているボリュームグループの残りの空きスペースを使用する。

      root ファイルシステムが置かれているボリュームグループに必要な空きスペースがあることを確認してから、docker-storage-setup を実行して、出力で docker-pool ボリュームが作成されていることを確認します。

      # docker-storage-setup
        Rounding up size to full physical extent 32.00 MiB
        Logical volume "docker-poolmeta" created.
        Logical volume "docker-pool" created.
        WARNING: Converting logical volume rhel/docker-pool and rhel/docker-poolmeta to pool's data and metadata volumes.
        THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
        Converted rhel/docker-pool to thin pool.
        Logical volume "docker-pool" changed.
  2. 設定を確認します。/etc/sysconfig/docker-storage ファイルに dm.thinpooldev 値と docker-pool 論理ボリュームが含まれている必要があります。

    # cat /etc/sysconfig/docker-storage
    DOCKER_STORAGE_OPTIONS="--storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/rhel-docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true "
    
    # lvs
      LV          VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      docker-pool rhel twi-a-t---  9.29g             0.00   0.12
    重要

    Docker または OpenShift Container Platform を使用する前に、docker-pool 論理ボリュームが要求を満たす程度のサイズであることを確認します。docker-pool ボリュームは利用可能なボリュームグループの 60% である必要があり、これは LVM モニタリングによって拡張し、ボリュームグループを埋めていきます。

  3. Docker がホストでまだ起動されていない場合は、サービスを有効にしてから起動し、それが実行されていることを確認します。

    # systemctl enable docker
    # systemctl start docker
    # systemctl is-active docker

    Docker がすでに実行されている場合は、Docker を再初期化します。

    警告

    これは現在ホストにあるコンテナーまたはイメージを破棄します。

    # systemctl stop docker
    # rm -rf /var/lib/docker/*
    # systemctl restart docker

    /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

atomic trust サブコマンドは信頼設定を管理します。デフォルトの設定では、すべてのレジストリーをホワイトリストに入れます。これは、署名の検証が設定されていないことを意味します。

$ atomic trust show
* (default)                         accept

適切な設定として、特定のレジストリーまたは namespace をホワイトリストに入れ、信頼されていないレジストリーはブラックリストに入れ (拒否)、ベンダーレジストリーで署名検証が必要になるようにします。以下のコマンドセットは、この設定例を実行します。

Atomic の信頼の設定例

$ atomic trust add --type insecureAcceptAnything 172.30.1.1:5000

$ atomic trust add --sigstoretype atomic \
  --pubkeys pub@example.com \
  172.30.1.1:5000/production

$ atomic trust add --sigstoretype atomic \
  --pubkeys /etc/pki/example.com.pub \
  172.30.1.1:5000/production

$ atomic trust add --sigstoretype web \
  --sigstore https://access.redhat.com/webassets/docker/content/sigstore \
  --pubkeys /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release \
  registry.access.redhat.com

# atomic trust show
* (default)                         accept
172.30.1.1:5000                     accept
172.30.1.1:5000/production          signed security@example.com
registry.access.redhat.com          signed security@redhat.com,security@redhat.com

署名されたすべてのソースが検証される場合、グローバルの reject デフォルトによりノードをさらに強化できます。

$ atomic trust default reject

$ atomic trust show
* (default)                         reject
172.30.1.1:5000                     accept
172.30.1.1:5000/production          signed security@example.com
registry.access.redhat.com          signed security@redhat.com,security@redhat.com

追加の例として 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 ロギングドライバーを設定し、ログファイルのサイズと数を制限して管理できます。

オプション目的

--log-opt max-size

作成される新規ログファイルのサイズを設定します。

--log-opt max-file

ホストごとに保持するログファイルの最大数を設定します。

たとえば、最大ファイルサイズを 1MB に設定し、最新の 3 つのログファイルを保持するには、/etc/sysconfig/docker ファイルを編集して、max-size=1Mmax-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

2.3.6.6. 利用可能なコンテナーログの表示

コンテナーログは、コンテナーが実行されているノードの /var/lib/docker/containers/<hash>/ ディレクトリーに保存されます。以下は例になります。

# ls -lh /var/lib/docker/containers/f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8/
total 2.6M
-rw-r--r--. 1 root root 5.6K Nov 24 00:12 config.json
-rw-r--r--. 1 root root 649K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.1
-rw-r--r--. 1 root root 977K Nov 24 00:15 f088349cceac173305d3e2c2e4790051799efe363842fdab5732f51f5b001fd8-json.log.2
-rw-r--r--. 1 root root 1.3K Nov 24 00:12 hostconfig.json
drwx------. 2 root root    6 Nov 24 00:12 secrets

ロギングドライバーの設定方法に関する詳細は、Docker ドキュメントを参照してください。

2.3.6.7. ローカルボリュームの使用サポート

ボリュームのプロビジョニングが DockerfileVOLUME 指示または docker run -v <volumename> コマンドを使用して実行されると、ホストのストレージ領域が使用されます。このストレージを使用すると、予期しない領域不足の問題が生じ、ホストが停止する可能性があります。

OpenShift Container Platform では、独自のイメージを実行しようとするユーザーには、ノードホストのストレージ領域全体が一杯になるリスクがあります。この問題に対する 1 つの解決策として、ユーザーがボリュームを持つイメージを実行できないようにする方法があります。これにより、ユーザーがアクセスできるストレージのみを制限し、クラスター管理者はストレージのクォータを割り当てることができます。

docker-novolume-plugin を使用して、ローカルボリュームが定義されたコンテナーの起動を禁止することにより、この問題を解決することができます。とくに、このプラグインは以下を含む docker run コマンドをブロックします。

  • --volumes-from オプション
  • VOLUME が定義されたイメージ
  • docker volume コマンドを使ってプロビジョニングされた既存ボリュームの参照

プラグインはバインドマウントへの参照をブロックしません。

docker-novolume-plugin を有効にするには、各ノードホストで以下の手順を実行します。

  1. docker-novolume-plugin パッケージをインストールします。

    $ yum install docker-novolume-plugin
  2. docker-novolume-plugin サービスを有効にし、起動します。

    $ systemctl enable docker-novolume-plugin
    $ systemctl start docker-novolume-plugin
  3. /etc/sysconfig/docker ファイルを編集し、以下を OPTIONS 一覧に追加します。

    --authorization-plugin=docker-novolume-plugin
  4. docker サービスを再起動します。

    $ systemctl restart docker

このプラグインを有効にした後に、ローカルボリュームが定義されたコンテナーは起動に失敗し、以下のエラーメッセージを表示します。

runContainer: API error (500): authorization denied by plugin
docker-novolume-plugin: volumes are not allowed

2.3.7. ホストアクセスの確保

クイックおよび通常インストール (advanced installation)方式では、すべてのホストにアクセスできるユーザーが必要になります。インストーラーを非 root ユーザーとして実行する場合は、それぞれの宛先ホストでパスワードレス sudo 権限を設定する必要があります。

たとえば、インストールプロセスを起動するホストで SSH キーを生成できます。

# ssh-keygen

パスワードは使用しないでください。

SSH キーを配布する簡単な方法として、bash ループを使用できます。

# for host in master.example.com \
    master.example.com \
    node1.example.com \
    node2.example.com; \
    do ssh-copy-id -i ~/.ssh/id_rsa.pub $host; \
    done

設定に従って、上記コマンドのホスト名を変更します。

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

2.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コンテナー化

インストール方法

yum によるパッケージ

docker によるコンテナーイメージ

サービス管理

systemd

docker および systemd ユニット

オペレーティングシステム

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>

クイックインストール方式の場合、各ターゲットホストで以下の環境変数をエクスポートできます。

# 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 をスタンドアロンレジストリーとして インストールするには、「スタンドアロンレジストリーのインストール」を参照してください。

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

画面の手順に従って新規 OpenShift Container Platform クラスターをインストールします。

完了後に、作成される ~/.config/openshift/installer.cfg.yml インストール設定ファイル をバックアップします。このファイルは、後でインストールを再実行したり、ホストをクラスターに追加したり、クラスターをアップグレードしたりする場合に必要になります。次に インストールを検証します。

2.5.4. インストール設定ファイルの定義

インストーラーは、インストール、個別ホストおよびクラスターの情報が含まれる事前定義のインストールファイルを使用できます。対話型インストールを実行する際に、 回答に基づくインストール設定ファイルが ~/.config/openshift/installer.cfg.yml に作成されます。このファイルは、インストールを終了して手動で設定を変更することが求められる場合やインストールの完了時に作成されます。また、設定ファイルをゼロから手動で作成して無人インストールを実行することもできます。

インストール設定ファイルの仕様

version: v2 1
variant: openshift-enterprise 2
variant_version: 3.9 3
ansible_log_path: /tmp/ansible.log 4
deployment:
  ansible_ssh_user: root 5
  hosts: 6
  - ip: 10.0.0.1 7
    hostname: master-private.example.com 8
    public_ip: 24.222.0.1 9
    public_hostname: master.example.com 10
    roles: 11
      - master
      - node
    containerized: true 12
    connect_to: 24.222.0.1 13
  - ip: 10.0.0.2
    hostname: node1-private.example.com
    public_ip: 24.222.0.2
    public_hostname: node1.example.com
    node_labels: {'region': 'infra'} 14
    roles:
      - node
    connect_to: 10.0.0.2
  - ip: 10.0.0.3
    hostname: node2-private.example.com
    public_ip: 24.222.0.3
    public_hostname: node2.example.com
    roles:
      - node
    connect_to: 10.0.0.3
  roles: 15
    master:
      <variable_name1>: "<value1>" 16
      <variable_name2>: "<value2>"
    node:
      <variable_name1>: "<value1>" 17

1
このインストール設定ファイルのバージョン。OpenShift Container Platform 3.3 の時点で、有効なバージョンは v2 のみです。
2
インストールする OpenShift Container Platform バリアント。OpenShift Container Platform の場合、これを openshift-enterprise に設定します。
3
選択したバリアントの有効なバージョン: 3.93.73.63.53.43.33.23.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

対話型または無人モードでは、インストーラーはデフォルトで ~/.config/openshift/installer.cfg.yml にある設定ファイルを使用します (ある場合)。ファイルが存在しない場合は、無人インストールを開始できません。

または、-c オプションを使用して設定ファイルの別の場所を指定できますが、これを実行するには、インストールを実行するたびにファイルの場所を指定する必要があります。

$ atomic-openshift-installer -u -c </path/to/file> install

無人インストールの完了後、使用された ~/.config/openshift/installer.cfg.yml ファイルをバックアップします。これは、インストールを後で再実行したり、ホストをクラスターに追加したり、クラスターをアップグレードしたりする場合に必要になります。次に インストールを検証します。

2.5.6. インストールの検証

  1. マスターが起動しており、ノードが登録されており、Ready ステータスで報告されていることを確認します。マスターホストで 以下を root で実行します。

    # 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+a0ce1bc657
  2. Web コンソールが正常にインストールされているか確認するには、マスターホスト名と Web コンソールのポート番号を使用して Web ブラウザーで Web コンソールにアクセスします。

    たとえば、ホスト名が master.openshift.comで、デフォルトポート 8443 を使用するマスターホストの場合、Web コンソールは https://master.openshift.com:8443/console にあります。

  3. 次に、OpenShift Container Platform クラスターを設定する次の手順について「次のステップ」を確認します。

2.5.7. OpenShift Container Platform のアンインストール

インストーラーの uninstall コマンドを使用してクラスターのすべてのホストから OpenShift Container Platform をアンインストールできます。デフォルトで、インストーラーは ~/.config/openshift/installer.cfg.yml にあるインストール設定ファイルを使用します (ある場合)。

$ atomic-openshift-installer uninstall

または、-c オプションを使用して設定ファイルの別の場所を指定することができます。

$ atomic-openshift-installer -c </path/to/file> uninstall

その他のオプションについては、「通常インストール (advanced installation) 方式」を参照してください。

2.5.8. 次のステップ

これで OpenShift Container Platform インスタンスが機能し、以下を実行できるようになります。

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] セクションにそれぞれ単一行で指定します。以下は例になります。

[OSEv3:vars]

openshift_master_identity_providers=[{'name': 'htpasswd_auth',
'login': 'true', 'challenge': 'true',
'kind': 'HTPasswdPasswordIdentityProvider',
'filename': '/etc/origin/master/htpasswd'}]

openshift_master_default_subdomain=apps.test.example.com
重要

Ansible インベントリーファイルのパラメーター値に、#, { or } などの特殊文字が含まれている場合、値をダブルエスケープ (double-escape) する必要があります (値を単一と二重引用符で囲みます)。たとえば、mypasswordwith###hashsigns を変数 openshift_cloudprovider_openstack_password の値として使用し、これを Ansible ホストインベントリーファイルで openshift_cloudprovider_openstack_password='"mypasswordwith###hashsigns"' として宣言します。

以下の表は、クラスター全体に割り当てることのできる Ansible インストーラーで使用される変数について説明しています。

表2.9 一般的なクラスター変数

変数目的

ansible_ssh_user

この変数はインストーラーで使用する SSH ユーザーを設定します。デフォルトは root です。このユーザーはパスワードを必要としない SSH ベースの認証を許可する必要があります。SSH キーベースの認証を使用する場合、そのキーは SSH エージェントで管理される必要があります。

ansible_become

ansible_ssh_userroot でない場合、この変数は true に設定する必要があり、ユーザーをパスワードレスの sudo 用に設定する必要があります。

debug_level

この変数は、 ログを systemd-journald.service に記録する INFO メッセージを設定します。以下のいずれかを設定します。

  • 0: エラーおよび警告のみをログに記録
  • 2: 通常の情報をログに記録 (これはデフォルトのレベルです)
  • 4: デバッグレベルの情報をログに記録
  • 6: API レベルのデバッグ情報 (要求/応答) をログに記録
  • 8: 本体レベルの API デバッグ情報をログに記録

デバッグログのレベルについての詳細は、「ロギングレベルの設定」を参照してください。

containerized

true に設定されている場合、コンテナー化された OpenShift Container Platform サービスは RPM パッケージを使用してインストールされるのではなく、クラスターにあるすべてのターゲットマスターおよびノードホストで実行されます。false に設定されているか、または未設定の場合、デフォルトの RPM の方法が使用されます。RHEL Atomic Host はコンテナー化の方法を要求し、これは /run/ostree-booted ファイルの検出に基づいて自動的に選択されます。詳細は、「コンテナー化ホストでのインストール」を参照してください。コンテナー化インストールは OpenShift Container Platform 3.1.1 以降でサポートされています。

openshift_clock_enabled

クラスターノードでネットワークタイムプロトコル (NTP) を有効にするかどうか。デフォルトは true です。

重要

クラスター内のマスターおよびノードが同期されなくなる状態を防ぐには、このパラメーターのデフォルト値を変更しないでください。

openshift_master_admission_plugin_config

この変数は、インベントリーホストファイルの要件に基づいてパラメーターと任意の JSON 値を設定します。以下は例になります。

openshift_master_admission_plugin_config={"ClusterResourceOverride":{"configuration":{"apiVersion":"v1","kind":"ClusterResourceOverrideConfig","memoryRequestToLimitPercent":"25","cpuRequestToLimitPercent":"25","limitCPUToMemoryPercent":"200"}}}

openshift_master_audit_config

この変数は API サービスの監査を有効にします。詳細は、「監査の設定」を参照してください。

openshift_master_cluster_hostname

この変数はクラスターのホスト名を上書きします。デフォルトはマスターのホスト名です。

openshift_master_cluster_public_hostname

この変数はクラスターのパブリックホスト名を上書きします。デフォルトはマスターのホスト名です。外部ロードバランサーを使用する場合は、外部ロードバランサーのアドレスを指定します。

例を以下に示します。

openshift_master_cluster_public_hostname=openshift-ansible.public.example.com

openshift_master_cluster_method

オプションです。この変数は複数マスターのデプロイ時の HA 方法を定義します。native 方法をサポートします。詳細は、「複数マスター」を参照してください。

openshift_rolling_restart_mode

この変数は、アップグレード Playbook を直接実行する時に HA マスターのローリング再起動 (例: マスターは一度に 1 つずつ停止します) を有効にします。これはデフォルトで services となっており、マスターでのサービスのローリング再起動を許可します。また system に設定することもでき、これによりローリング、完全なシステム再起動が有効になります。これは単一マスタークラスターの場合にも機能します。

openshift_master_identity_providers

この変数は アイデンティティープロバイダーを設定します。デフォルト値はDeny Allです。サポートされているアイデンティティープロバイダーを使用する場合は OpenShift Container Platform がそれを使用するよう設定します。

openshift_master_named_certificates

これらの変数は、インストールの一部としてデプロイされるカスタム証明書を設定するために使用されます。詳細は、「カスタム証明書の設定」を参照してください。

openshift_master_overwrite_named_certificates

openshift_hosted_router_certificate

ホストされているルーターのカスタム証明書の場所を指定します。

openshift_hosted_registry_cert_expire_days

自動生成されるレジストリー証明書の有効日数。デフォルトで 730 (2 年) に設定されます。

openshift_ca_cert_expire_days

自動生成される CA 証明書の有効日数。デフォルトで 1825 (5 年) に設定されます。

openshift_node_cert_expire_days

自動生成されるノード証明書の有効日数。デフォルトで 730 (2 年) に設定されます。

openshift_master_cert_expire_days

自動生成されるマスター証明書の有効日数。デフォルトで 730 (2 年) に設定されます。

etcd_ca_default_days

自動生成される外部 etcd 証明書の有効日数。etcd CA、ピア、サーバー、クライアント証明書の有効性を管理します。デフォルトで 1825 (5 年) に設定されます。

os_firewall_use_firewalld

true に設定され、デフォルトの iptables ではなく firewalld が使用されます。RHEL Atomic Host では利用できません。詳細は「ファイアウォールの設定」のセクションを参照してください。

openshift_master_session_name

これらの変数は OAuth 設定のセッションオプションのデフォルトを上書きします。詳細は「 セッションオプションの設定」を参照してください。

openshift_master_session_max_seconds

openshift_master_session_auth_secrets

openshift_master_session_encryption_secrets

openshift_set_node_ip

この変数はノード設定の nodeIP を設定します。この変数は、ノードトラフィックでデフォルトネットワークインターフェース以外のインターフェースを使用する必要がある場合に必要となります。ホスト変数 openshift_ip もそれぞれのノードで設定でき、デフォルトルートの IP でない特定の IP を設定できます。

openshift_master_image_policy_config

マスター設定で imagePolicyConfig を設定します。詳細は 「イメージ設定」を参照してください。

openshift_router_selector

ルーター Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は「ノードホストラベルの設定」を参照してください。

openshift_registry_selector

レジストリー Pod を自動的にデプロイするためのデフォルトのノードセレクター。詳細は、「ノードホストラベルの設定」を参照してください。

openshift_template_service_broker_namespaces

この変数は、ブローカーが提供するテンプレートの 1 つ以上の namespace を指定することでテンプレートサービスブローカーを有効にします。

template_service_broker_selector

テンプレートサービスブローカー Pod を自動的にデプロイするためのデフォルトのノードセレクター。デフォルトで {"region": "infra"} に設定されています。詳細は「ノードホストラベルの設定」を参照してください。

osm_default_node_selector

この変数は、Pod を配置する際にプロジェクトがデフォルトで使用するノードセレクターを上書きします。デフォルトのセレクターはマスター設定ファイルの projectConfig.defaultNodeSelector フィールドで定義されます。OpenShift Container Platform 3.9 以降では、これが定義されていない場合はデフォルトで node-role.kubernetes.io/compute=true となります。

openshift_docker_additional_registries

OpenShift Container Platform は指定された追加レジストリーを docker 設定に追加します。これらは検索対象のレジストリーです。このレジストリーへのアクセスに必要なレジストリーが 80 以外の場合は、<address>:<port> の形式でポート番号を含める必要があります。

例を以下に示します。

openshift_docker_additional_registries=example.com:443

openshift_docker_insecure_registries

OpenShift Container Platform は指定された追加の非セキュアなレジストリーを docker 設定に追加します。それらのレジストリーの SSL (Secure Sockets Layer) は検証されません。さらに、それらのレジストリーを openshift_docker_additional_registries に追加します。

openshift_docker_blocked_registries

OpenShift Container Platform は指定されたブロック済みレジストリーを docker 設定に追加します。これは一覧表示されるレジストリーをブロックします。これを all に設定すると、他の変数で使用されていないすべてのレジストリーがブロックされます。

openshift_metrics_hawkular_hostname

この変数は、マスター設定でクラスターメトリクスの metricsPublicURL を上書きすることで、メトリクスコンソールと統合するホスト名を設定します。この変数を変更する場合は、ホスト名がルーター経由でアクセスできることを確認してください。

openshift_clusterid

この変数は AWS アベイラビリティーゾーン固有のクラスター識別子です。これを使用することで、複数のゾーンまたは複数のクラスターを持つ Amazon Web Service (AWS) での潜在的な問題を回避することができます。詳細は「AWS のクラスターへのラベル付け」を参照してください。

openshift_image_tag

この変数を使用して、インストールまたは設定するコンテナーイメージタグを指定します。

openshift_pkg_version

この変数を使用して、インストールまたは設定する RPM バージョンを指定します。

警告

クラスターのセットアップ後に openshift_image_tag または openshift_pkg_version 変数を変更する場合はアップグレードがトリガーされ、ダウンタイムが発生します。

  • openshift_image_tag が設定されている場合、この値は別のバージョンがインストールされている場合でもコンテナー化された環境のすべてのホストに使用されます。
  • openshift_pkg_version が設定されている場合、この値は別のバージョンがインストールされている場合でも RPM ベースの環境のすべてのホストに使用されます。

表2.10 ネットワーク変数

変数目的

openshift_master_default_subdomain

この変数は、公開されるルートに使用するデフォルトのサブドメインを上書きします。

os_sdn_network_plugin_name

この変数は、どの OpenShift SDN プラグインを Pod ネットワークに使用するかを設定します。デフォルトでは標準 SDN プラグインの redhat/openshift-ovs-subnet に設定されます。変数を redhat/openshift-ovs-multitenant に設定してマルチテナント SDN プラグインを使用します。

osm_cluster_network_cidr

この変数は SDN クラスターネットワーク CIDR ブロックを上書きします。これは、Pod IP の割り当て元のネットワークです。このネットワークブロックは非公開ブロックとし、Pod、ノード、またはマスターがアクセスする必要のある可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。デフォルトは 10.128.0.0/14 であり、デプロイ後は SDN マスター設定でこれに一部の変更を加えられることがありますが、任意に再設定することはできません。

openshift_portal_net

この変数は、サービスOpenShift Container Platform SDN 内で作成する際のサブネットを設定します。このネットワークブロックは非公開とし、Pod、ノード、またはマスターがアクセスする必要の可能性があるインフラストラクチャーの既存のネットワークブロックと競合しないようにする必要があります。そうでない場合、インストールは失敗します。デフォルトは 172.30.0.0/16 であり、デプロイ後はこれを再設定することはできません。デフォルトを変更する場合は、docker0 ネットワークブリッジがデフォルトで使用する 172.17.0.0/16 の使用を避けるようにするか、または docker0 ネットワークを変更します。

osm_host_subnet_length

この変数は、OpenShift Container Platform SDN により Pod IP のホストサブネットごとに割り当てられるサイズを指定します。デフォルトは 9 であり、これは各ホストにサイズが /23 のサブネットが割り当てられることを意味します。デフォルトの 10.128.0.0/14 クラスターネットワークの場合、これは 10.128.0.0/23、10.128.2.0/23、10.128.4.0/23 などを割り当てます。これはデプロイ後に再設定することはできません。

openshift_node_proxy_mode

この変数は、使用するサービスプロキシーモードを指定します。iptables (デフォルトの純粋な iptables 実装) または userspace (ユーザー空間プロキシー) のいずれかを指定します。

openshift_use_flannel

この変数は、デフォルトの SDN の代わりに flannel を代替ネットワーキングレイヤーとして有効にします。flannel を有効にする場合は、openshift_use_openshift_sdn 変数を使用してデフォルトの SDN を無効にしてください。詳細については、「Flannel の使用」を参照してください。

openshift_use_openshift_sdn

OpenShift SDN プラグインを無効にするには、false に設定します。

2.6.3.2. デプロイメントタイプの設定

Playbook 全体で使用される各種デフォルト値とインストーラーによって使用されるロールは、デプロイメントタイプの設定 (通常は Ansible インベントリーファイルで定義されます) に基づいて決定されます。

OpenShift Container Platform バリアントをインストールするには、インベントリーファイルの [OSEv3:vars] セクションにある openshift_deployment_type パラメーターが openshift-enterprise に設定されていることを確認してください。

[OSEv3:vars]
openshift_deployment_type=openshift-enterprise

2.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

以下の表は、Ansible インストーラーで使用され、個々のホストエントリーに割り当てることができる変数を示しています。

表2.11 ホスト変数

変数目的

openshift_hostname

この変数は、システムの内部クラスターホスト名を上書きします。システムのデフォルトの IP アドレスがシステムのホスト名に解決されない場合にこれを使用します。

openshift_public_hostname

この変数は、システムのパブリックホスト名を上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。

openshift_ip

この変数は、システムのクラスター内部 IP アドレスを上書きします。デフォルトルートが設定されていないインターフェースを使用する場合に使用します。etcd には openshift_ip を使用できます。

openshift_public_ip

この変数は、システムのパブリック IP アドレスを上書きします。クラウドインストールやネットワークアドレス変換 (NAT) を使用するネットワーク上のホストに使用します。

containerized

true に設定した場合、コンテナー化された OpenShift Container Platform サービスは、RPM パッケージを使用してインストールされる代わりに、ターゲットマスターとノードホスト上で実行されます。 false に設定するか、値を設定しない場合、デフォルトの RPM 方法が使用されます。RHEL Atomic Host では、コンテナー化方法を使用する必要があり、/run/ostree-booted ファイルの検出に基づいて自動的に選択されます。詳細については、「コンテナー化ホストでのインストール」を参照してください。コンテナー化インストールは、OpenShift Container Platform 3.1.1 以降でサポートされています。

openshift_node_labels

この変数は、インストール時にラベルをノードに追加します。詳細については、「ノードホストラベルの設定」を参照してください。

openshift_node_kubelet_args

この変数は、ノードに kubeletArguments を設定するために使用します。たとえば、コンテナーとイメージのガベージコレクションに使用される引数や、ノードごとのリソースを指定するために使用される引数などがこれに該当します。kubeletArguments は、Kubelet に直接渡されるキーと値のペアで、Kubelet のコマンドライン引数に一致します。kubeletArguments は移行または検証されず、使用される場合には無効になることがあります。これらの値がノード設定の他の設定を上書きすると、無効な設定が生じる可能性があります。使用例: {'image-gc-high-threshold': ['90'],'image-gc-low-threshold': ['80']}

openshift_docker_options

この変数は、/etc/sysconfig/docker 内に追加の docker オプションを設定します。たとえば、コンテナーログの管理で使用されるオプションなどがこれに該当します。json-file を使用することを推奨します。

次に、Docker が json-file ログドライバーを使用するように設定する例を示します。この例では、Docker は 1 MB のログファイル 3 つをローテーションします。

"--log-driver json-file --log-opt max-size=1M --log-opt max-file=3"

docker をシステムコンテナーとして実行している場合は使用しないでください。

openshift_schedulable

この変数は、ホストがスケジュール可能ノードとしてマークされているかどうか、つまり、新しい Pod を配置できるかどうかを設定します。マスターでのスケジュール可能性の設定を参照してください。

2.6.3.4. マスター API ポートの設定

マスター API で使用するデフォルトのポートを設定するには、/etc/ansible/hosts ファイルに以下の変数を定義します。

表2.12 マスター API ポート

変数目的

openshift_master_api_port

この変数は、OpenShift Container Platform API へのアクセスに使用するポート番号を設定します。

例を以下に示します。

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 インストールの前に実行される、使用可能なプレインストールチェックを示しています。

表2.13 プレインストールチェック

チェック名目的

memory_availability

このチェックでは、OpenShift Container Platform の特定のデプロイメントで推奨されるメモリー容量がホストにあることを確認します。デフォルト値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで openshift_check_min_host_memory_gb クラスター変数を設定することで、最小メモリー要件のユーザー定義値を設定できます。

disk_availability

このチェックは、etcd、マスター、およびノードホストに対してのみ実行され、OpenShift Container Platform インストールのマウントパスに十分なディスク領域が残っていることを確認します。推奨されるディスク値は、最新のインストールドキュメントから取得されたものです。インベントリーファイルで openshift_check_min_host_disk_gb クラスター変数を設定することで、最小ディスク領域のユーザー定義値を設定できます。

docker_storage

docker デーモン (ノードとコンテナー化インストール) に依存するホストでのみ実行され、 docker の合計使用率がユーザー定義の上限を超えていないことを確認します。ユーザー定義の上限が設定されていない場合、docker の最大使用率のしきい値はデフォルトで使用可能な合計サイズの 90% になります。合計使用率のしきい値上限は、インベントリーファイルで変数を使用して設定できます。( max_thinpool_data_usage_percent=90)。最大シンプール使用率のユーザー定義の上限は、インベントリーファイルで max_thinpool_data_usage_percent クラスター変数を設定することで設定できます。

docker_storage_driver

docker デーモンが OpenShift Containe Platform でサポートされているストレージドライバーを使用していることを確認します。devicemapper ストレージドライバーが使用されている場合は、ループバックデバイスが使用されていないことも確認します。詳細については、『Docker’s Use the Device Mapper Storage Driver 』ガイドを参照してください。

docker_image_availability

OpenShift Container Platform インストールで必要なイメージがローカルで、またはホストマシン上の 1 つ以上の設定済みコンテナーイメージレジストリー で使用可能であることの確認を試行します。

package_version

yum ベースのシステムで実行され、必要な OpenShift Container Platform パッケージの複数のリリースが利用可能かどうかを確認します。OpenShift のエンタープライズインストール時にパッケージの複数のリリースが利用可能である場合は、各リリース用に複数の yum リポジトリーが有効になっていることが示され、インストールの際に問題になることがあります。このチェックは、インベントリーファイルに openshift_release 変数が定義されていない場合には省略されます。

package_availability

OpenShift Container Platform の非コンテナー化インストールの前に実行され、現在のインストールに必要な RPM パッケージが利用可能であることを確認します。

package_update

yum アップデートまたはパッケージのインストールが成功するかどうかを、実際にインストールを行ったり、ホストで yum を実行したりせずに確認します。

特定のプレインストールチェックを無効にするには、カンマ区切りのチェック名の一覧を指定した変数 openshift_disable_check をインベントリーファイルに組み込みます。以下は例になります。

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 をシステムコンテナーとして実行するには、以下を実行します。

  1. RHEL 7 では、Docker 用のデフォルトのストレージバックエンドはループバックデバイス上のシンプールです。そのため RHEL システムでは、OpenShift Container Platform を実行する前に docker 用のシンプール論理ボリュームを設定する必要があります。RHEL Atomic Host システムでは、この手順を省略できます。

    RHEL システムについては、以下のセクションに記載されている手順を実行してください。

    ストレージの設定手順が完了したら、RPM をインストールしたままにしておくことができます。

  2. インベントリーファイルの [OSEv3:vars] セクションで以下のクラスター変数を True に設定します。

    openshift_docker_use_system_container=True

システムコンテナー方法を使用する場合、docker の以下のインベントリー変数は無視されます。

  • docker_version
  • docker_upgrade

また、以下のインベントリー変数は使用できません。

  • openshift_docker_options

システムコンテナーの dockercontainer-engine イメージをプルするときに、デフォルトの registry.access.redhat.com/openshift3/ ではなく、特定のコンテナーレジストリーとリポジトリーを使用するように強制することもできます。これを行うには、インベントリーファイルの [OSEv3:vars] セクションで以下のクラスター変数を設定します。

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

2.6.3.7. レジストリーの場所の設定

registry.access.redhat.com にあるデフォルト以外のイメージレジストリーを使用する場合は、目的のレジストリーを /etc/ansible/hosts ファイル内に指定します。

oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

表2.14 レジストリー変数

変数目的

oreg_url

代わりのイメージの場所に設定します。registry.access.redhat.com にあるデフォルトレジストリーを使用しない場合は必須です。

openshift_examples_modify_imagestreams

デフォルト以外のレジストリーを参照している場合は true に設定します。イメージストリームの場所を oreg_url の値に変更します。

openshift_docker_additional_registries

1 つ以上の追加レジストリーを指定します。レジストリーにアクセスするために必要なレジストリーが 80 以外の場合は、<address>:<port> の形式で必要なポート番号を含めます。

openshift_cockpit_deployer_prefix

registry-console イメージが置かれる namespace の URL およびパスを指定します。この値は、ose- ではなく /openshift3 で終了する必要があります。これは、他のイメージの標準です。

openshift_web_console_prefix

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

openshift_service_catalog_image_prefix

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

ansible_service_broker_image_prefix

Ansible サービスブローカーのコンポーネントイメージのプレフィックスを指定します。

template_service_broker_prefix

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

openshift_crio_systemcontainer_image_override

CRI-O を使用している場合、および別のレジストリーからの他の CRI-O システムコンテナーイメージを使用している場合の設定です。

例を以下に示します。

oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true
openshift_docker_additional_registries=example.com:443
+openshift_crio_systemcontainer_image_override=<registry>/<repo>/<image>:<tag>
openshift_cockpit_deployer_prefix='registry.example.com/openshift3/'
openshift_web_console_prefix='registry.example.com/openshift3/ose-
openshift_service_catalog_image_prefix='registry.example.com/openshift3/ose-'
ansible_service_broker_image_prefix='registry.example.com/openshift3/ose-'
template_service_broker_prefix='registry.example.com/openshift3/ose-'

2.6.3.8. レジストリールートの設定

ユーザーが OpenShift Container Platform クラスターの外部からイメージをプルして内部の Docker レジストリーにプッシュできるように、/etc/ansible/hosts ファイルにレジストリールートを設定します。デフォルトでは、レジストリールートは docker-registry-default.router.default.svc.cluster.local です。

表2.15 レジストリールート変数

変数目的

openshift_hosted_registry_routehost

必要なレジストリールートの値に設定します。ルートには、ルーターによって通信が管理されるインフラストラクチャーノードに解決される名前、またはデフォルトのアプリケーションサブドメインのワイルドカード値として設定したサブドメインのいずれかが含まれます。たとえば、openshift_master_default_subdomain パラメーターを apps.example.com に設定し、*.apps.example.com がインフラストラクチャーノードまたはロードバランサーに解決される場合は、registry.apps.example.com をレジストリールートとして使用できます。

openshift_hosted_registry_routecertificates

レジストリー証明書へのパスを設定します。証明書の場所の値を指定しない場合、証明書が生成されます。以下の証明書の場所を定義できます。

  • certfile
  • keyfile
  • cafile

openshift_hosted_registry_routetermination

以下のいずれかの値に設定します。

  • edge ルーターで暗号化を終了し、送信先から提供される新しい証明書で再暗号化するには、reencrypt に設定します。
  • 送信先で暗号化を終了するには、passthrough に設定します。トラフィックは送信先で復号化されます。

例を以下に示します。

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>

表2.16 レジストリー変数

変数目的

openshift_cockpit_deployer_prefix

イメージが置かれているディレクトリーの URL とパスを指定します。

openshift_cockpit_deployer_version

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'

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 に関する考慮事項を参照してください。

  1. インベントリーファイルの [OSEv3:children] セクションに glusterfs を追加して、 [glusterfs] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    glusterfs
  2. GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs] セクションを追加します。ノードごとに、 glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスは、パーティションや LVM PV がないベアでなければなりません。変数は以下の形式で指定します。

    <hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

    例を以下に示します。

    [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" ]'
  3. [glusterfs] の下に一覧表示されているホストを [nodes] グループに追加します。

    [nodes]
    ...
    node11.example.com openshift_schedulable=True
    node12.example.com openshift_schedulable=True
    node13.example.com openshift_schedulable=True
2.6.3.10.2. Container-Ready Storage の設定
  1. インベントリーファイルの [OSEv3:children] セクションに glusterfs を追加して、 [glusterfs] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    glusterfs
  2. 以下の変数を [OSEv3:vars] セクションに追加し、お使いの設定に応じて調整します。

    [OSEv3:vars]
    ...
    openshift_storage_glusterfs_is_native=false
    openshift_storage_glusterfs_storageclass=true
    openshift_storage_glusterfs_heketi_is_native=true
    openshift_storage_glusterfs_heketi_executor=ssh
    openshift_storage_glusterfs_heketi_ssh_port=22
    openshift_storage_glusterfs_heketi_ssh_user=root
    openshift_storage_glusterfs_heketi_ssh_sudo=false
    openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"
  3. 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>", ... ]'

    例を以下に示します。

    [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" ]'

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 になります。

[OSEv3:vars]

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_nfs_options='*(rw,root_squash)'
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi
オプション B: 外部 NFS ホスト
注記

レジストリーストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。

外部の NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。次のオプションを使用した場合、リモートボリュームパスは nfs.example.com:/exports/registry になります。

[OSEv3:vars]

openshift_hosted_registry_storage_kind=nfs
openshift_hosted_registry_storage_access_modes=['ReadWriteMany']
openshift_hosted_registry_storage_host=nfs.example.com
openshift_hosted_registry_storage_nfs_directory=/exports
openshift_hosted_registry_storage_volume_name=registry
openshift_hosted_registry_storage_volume_size=10Gi
オプション C: OpenStack プラットフォーム

OpenStack ストレージ設定がすでに存在している必要があります。

[OSEv3:vars]

openshift_hosted_registry_storage_kind=openstack
openshift_hosted_registry_storage_access_modes=['ReadWriteOnce']
openshift_hosted_registry_storage_openstack_filesystem=ext4
openshift_hosted_registry_storage_openstack_volumeID=3a650b4f-c8c5-4e0a-8ca5-eaee11f16c57
openshift_hosted_registry_storage_volume_size=10Gi
オプション D: AWS または別の S3 ストレージソリューション

シンプルストレージソリューション (S3) バケットがすでに存在している必要があります。

[OSEv3:vars]

#openshift_hosted_registry_storage_kind=object
#openshift_hosted_registry_storage_provider=s3
#openshift_hosted_registry_storage_s3_accesskey=access_key_id
#openshift_hosted_registry_storage_s3_secretkey=secret_access_key
#openshift_hosted_registry_storage_s3_bucket=bucket_name
#openshift_hosted_registry_storage_s3_region=bucket_region
#openshift_hosted_registry_storage_s3_chunksize=26214400
#openshift_hosted_registry_storage_s3_rootdirectory=/registry
#openshift_hosted_registry_pullthrough=true
#openshift_hosted_registry_acceptschema2=true
#openshift_hosted_registry_enforcequota=true

Minio や ExoScale などの別の S3 サービスを使用している場合は、リージョンエンドポイントパラメーターも追加します。

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 に関する考慮事項を参照してください。

  1. インベントリーファイルの [OSEv3:vars] に次の変数を追加します。

    [OSEv3:vars]
    ...
    openshift_hosted_registry_storage_kind=glusterfs
  2. [OSEv3:children] セクションに glusterfs_registry を追加して、[glusterfs_registry] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    glusterfs_registry
  3. GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs_registry] セクションを追加します。ノードごとに、 glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。

    <hostname_or_ip> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

    例を以下に示します。

    [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" ]'
  4. [glusterfs_registry] の下に一覧表示されているホストを [nodes] グループに追加します。

    [nodes]
    ...
    node11.example.com openshift_schedulable=True
    node12.example.com openshift_schedulable=True
    node13.example.com openshift_schedulable=True
オプション F: Google Compute Engine (GCE) 上の Google Cloud Storage (GCS) バケット

GCS バケットがすでに存在している必要があります。

[OSEv3:vars]

openshift_hosted_registry_storage_provider=gcs
openshift_hosted_registry_storage_gcs_bucket=bucket01
openshift_hosted_registry_storage_gcs_keyfile=test.key
openshift_hosted_registry_storage_gcs_rootdirectory=/registry

2.6.3.12. グローバルプロキシーオプションの設定

ホストが外部ホストに接続するために HTTP または HTTPS プロキシーを使用する必要がある場合は、プロキシーを使用するためにマスター、Docker、ビルドなどの多数のコンポーネントを設定する必要があります。ノードサービスは外部アクセスを必要としないマスター API にのみ接続するため、プロキシーを使用するように設定する必要はありません。

この設定を単純化するため、クラスターまたはホストレベルで次の Ansible 変数を指定し、これらの設定を環境全体に均一に適用することができます。

注記

ビルド用のプロキシー環境の定義方法の詳細については、「グローバルビルドのデフォルトとオーバーライドの設定」を参照してください。

表2.17 クラスタープロキシー変数

変数目的

openshift_http_proxy

この変数はマスターおよび Docker デーモンの HTTP_PROXY 環境変数を指定します。

openshift_https_proxy

この変数は、マスターおよび Docker デーモンの HTTPS_PROXY 環境変数を指定します。

openshift_no_proxy

この変数は、マスターおよび Docker デーモンに NO_PROXY 環境変数を設定するために使用されます。定義されたプロキシーを使用しないホスト名、ドメイン名、またはワイルドカードホスト名のカンマ区切りの一覧を提供します。デフォルトでは、この一覧は、定義済みのすべての OpenShift Container Platform ホスト名の一覧で拡張されます。

openshift_generate_no_proxy_hosts

このブール変数は、すべての定義済み OpenShift ホストの名前と *.cluster.local が自動的に NO_PROXY 一覧に追加されるかどうかを指定します。デフォルトは true です。このオプションを上書きするには false に設定します。

openshift_builddefaults_http_proxy

この変数は、BuildDefaults 受付コントローラーを使用して、ビルドに挿入される HTTP_PROXY 環境変数を定義します。このパラメーターを定義せず、openshift_http_proxy パラメーターを定義する場合、openshift_http_proxy 値が使用されます。openshift_http_proxy の値を問わず、デフォルトの http プロキシーを無効にするには、openshift_builddefaults_http_proxy 値を False に設定します。

openshift_builddefaults_https_proxy

この変数は、BuildDefaults 受付コントローラーを使用して、ビルドに挿入される HTTPS_PROXY 環境変数を定義します。このパラメーターを定義せず、openshift_http_proxy パラメーターを定義する場合、openshift_https_proxy 値が使用されます。openshift_https_proxy の値を問わず、デフォルトの http プロキシーを無効にするには、openshift_builddefaults_https_proxy 値を False に設定します。

openshift_builddefaults_no_proxy

この変数は、BuildDefaults 受付コントローラーを使用して、ビルドに挿入される NO_PROXY 環境変数を定義します。openshift_no_proxy 値の種類を問わず、ビルドのデフォルトの no proxy 設定を無効にするには、openshift_builddefaults_no_proxy 値を False に設定します。

openshift_builddefaults_git_http_proxy

この変数は、ビルド時に git clone 操作で使用される HTTP プロキシーを定義します。これは BuildDefaults 受付コントローラーを使用して定義されます。openshift_http_proxy 値の種類を問わず、ビルド時に git clone 操作のデフォルトの https プロキシーを無効にするには、openshift_builddefaults_git_http_proxy 値を False に設定します。

openshift_builddefaults_git_https_proxy

この変数は、ビルド時に git clone 操作で使用される HTTPS プロキシーを定義します。これは BuildDefaults 受付コントローラーを使用して定義されます。openshift_https_proxy 値の種類を問わず、ビルド時に git clone 操作のデフォルトの https プロキシーを無効にするには、openshift_builddefaults_git_https_proxy 値を False に設定します。

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 1
1
この変数を true に設定することで、必要なポートが開き、ルールがデフォルトゾーンに追加されます。これにより、firewalld が適切に設定されていることを確認できます。
注記

firewalld のデフォルトの設定オプションを使用する際には設定オプションが制限され、これらをオーバーライドすることはできません。たとえば、ストレージネットワークを複数ゾーンのインターフェースでセットアップすることができますが、ノードが通信に使用するインターフェースはデフォルトゾーンになければなりません。

2.6.3.14. マスターでのスケジュール可能性の設定

インストールプロセス時にマスターとして指定するすべてのホストは、マスターが OpenShift SDN の一部として設定されるように、ノードとして設定される必要もあります。これらのホストのエントリーを [nodes] セクションに追加してこの設定を行う必要があります。

[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'}"

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'

レジストリーとルーターは、region=infra ラベルが付いた、専用インフラストラクチャーノードと見なされるノードホスト上でのみ実行できます。お使いの OpenShift Container Platform 環境に、region=infra ラベルが付いたノードホストが 1 つ以上存在することを確認してください。以下は例になります。

[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

デフォルトの registry.access.redhat.com 以外のイメージレジストリーを使用する場合は、/etc/ansible/hosts ファイルで 必要なレジストリーを指定する必要があります。

マスターでのスケジュール可能性の設定で説明されているように、マスターホストはデフォルトでスケジュール可能としてマークされます。マスターホストに region=infra ラベルを付けており、他に専用インフラストラクチャーノードがない場合、マスターホストはスケジュール可能としてマークされる必要もあります。そうでない場合には、レジストリーとルーター Pod をどこにも配置することができなくなります。

[nodes]
master.example.com openshift_node_labels="{'region': 'infra','zone': 'default'}" openshift_schedulable=true

2.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_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_encryption_secrets の場合、シークレットの長さは AES-128、AES-192、または AES-256 を選択するできるようにそれぞれ 16、24、または 32 文字にする必要があります。

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"}]

ファイルパスは、Ansible が実行されるシステムに対してローカルである必要があります。証明書はマスターホストにコピーされ、/etc/origin/master/named_certificates/ ディレクトリー内にデプロイされます。

Ansible は、証明書の Common NameSubject 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 を使用して設定される証明書はマスターにキャッシュされます。つまり、別の証明書セットで Ansible を実行するたびに、以前にデプロイされたすべての証明書がマスターホストとマスターの設定ファイル内に残ることになります。

openshift_master_named_certificates を指定した値 (または値なし) で上書きする場合は、openshift_master_overwrite_named_certificates クラスター変数を指定します。

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

後続の 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

2.6.3.18. 証明書の有効性の設定

デフォルトで、etcd、マスター、kubelet の管理に使用される証明書は 2 から 5 年で有効期限切れになります。自動生成されるレジストリー、CA、ノードおよびマスター証明書の有効性 (有効期限が切れるまでの日数) は、以下の変数 (デフォルト値が表示されています) を使用してインストール時に設定できます。

[OSEv3:vars]

openshift_hosted_registry_cert_expire_days=730
openshift_ca_cert_expire_days=1825
openshift_node_cert_expire_days=730
openshift_master_cert_expire_days=730
etcd_ca_default_days=1825

これらの値は、 Ansible のインストール後での 証明書の再デプロイ時にも使用されます。

2.6.3.19. クラスターメトリクスの設定

クラスターメトリクスは、自動的にデプロイされるように設定されていません。通常インストール (Advanced installation) 方式を使用している場合にクラスターメトリクスを有効にするには、以下を設定します。

[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

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 になります。

[OSEv3:vars]

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_nfs_options='*(rw,root_squash)'
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi
オプション C: 外部 NFS ホスト
重要

メトリクスストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。

外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。

[OSEv3:vars]

openshift_metrics_storage_kind=nfs
openshift_metrics_storage_access_modes=['ReadWriteOnce']
openshift_metrics_storage_host=nfs.example.com
openshift_metrics_storage_nfs_directory=/exports
openshift_metrics_storage_volume_name=metrics
openshift_metrics_storage_volume_size=10Gi

以下のオプションを使用した場合、リモートボリュームのパスは 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
2.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

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 になります。

[OSEv3:vars]

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_nfs_directory=/exports
openshift_logging_storage_nfs_options='*(rw,root_squash)'
openshift_logging_storage_volume_name=logging
openshift_logging_storage_volume_size=10Gi
オプション C: 外部 NFS ホスト
重要

ロギングストレージに NFS を使用することは、OpenShift Container Platform では推奨されていません。

外部 NFS ボリュームを使用するには、該当する NFS ボリュームがストレージホストの <nfs_directory>/<volume_name> パスにすでに存在している必要があります。

[OSEv3:vars]

openshift_logging_storage_kind=nfs
openshift_logging_storage_access_modes=['ReadWriteOnce']
openshift_logging_storage_host=nfs.example.com
openshift_logging_storage_nfs_directory=/exports
openshift_logging_storage_volume_name=logging
openshift_logging_storage_volume_size=10Gi

以下のオプションを使用した場合、リモートボリュームのパスは 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_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 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
2.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 の永続ストレージを設定できます。

表2.18 OpenShift Ansible Broker Storage Ansible 変数

変数目的

openshift_hosted_etcd_storage_kind

etcd PV に使用するストレージタイプ。nfs がこの方法でサポートされています。

openshift_hosted_etcd_storage_volume_name

etcd PV の名前。

openshift_hosted_etcd_storage_access_modes

デフォルトで ReadWriteOnce に設定されます。

openshift_hosted_etcd_storage_volume_size

etcd PV のサイズ。デフォルトで 1Gi に設定されます。

openshift_hosted_etcd_storage_labels

etcd PV に使用するラベル。デフォルトで {'storage': 'etcd'} に設定されます。

openshift_hosted_etcd_storage_nfs_options

使用する NFS オプション。デフォルトで *(rw,root_squash) に設定されます。

openshift_hosted_etcd_storage_nfs_directory

NFS エクスポートのディレクトリー。デフォルトで /exports に設定されます。

一部の Ansible Playbook Bundle (APB) でも、デプロイに専用の PV が必要になります。たとえば、APB の各データベースには 2 つのプランがあります。開発プランは一時的なストレージを使用し、PV を必要としませんが、実稼働プランは永続的であり、PV を必要とします。

APBPV が必要?

postgresql-apb

必要 (ただし実稼働プランの場合のみ必要)

mysql-apb

必要 (ただし実稼働プランの場合のみ必要)

mariadb-apb

必要 (ただし実稼働プランの場合のみ必要)

mediawiki-apb

Yes

OAB の永続ストレージを設定するには、以下の手順を実行します。

  1. インベントリーファイルの [OSEv3:children] セクションに nfs を追加して、 [nfs] グループを有効にします。

    [OSEv3:children]
    masters
    nodes
    nfs
  2. [nfs] グループセクションを追加し、NFS ホストになるシステムのホスト名を追加します。

    [nfs]
    master1.example.com
  3. [OSEv3:vars] セクションに以下を追加します。

    openshift_hosted_etcd_storage_kind=nfs
    openshift_hosted_etcd_storage_nfs_options="*(rw,root_squash,sync,no_wdelay)"
    openshift_hosted_etcd_storage_nfs_directory=/opt/osev3-etcd 1
    openshift_hosted_etcd_storage_volume_name=etcd-vol2 2
    openshift_hosted_etcd_storage_access_modes=["ReadWriteOnce"]
    openshift_hosted_etcd_storage_volume_size=1G
    openshift_hosted_etcd_storage_labels={'storage': 'etcd'}
    1 2
    NFS ボリュームが [nfs] グループ内のホストの <nfs_directory>/<volume_name> パスに作成されます。たとえば、これらのオプションを使用した場合、ボリュームパスは /opt/osev3-etcd/etcd-vol2 になります。

    これらの設定は、クラスターのインストール時に OAB の etcd インスタンスに割り当てられる永続ボリュームを作成します。

2.6.3.21.1.2. ローカルの APB 開発用の OpenShift Ansible ブローカーの設定

OpenShift Container レジストリーと OAB を組み合わせて APB 開発 を行うには、OAB がアクセスできるイメージのホワイトリストを定義する必要があります。ホワイトリストが定義されていない場合、ブローカーは APB を無視し、使用可能な APB がユーザーに表示されません。

デフォルトでは、ホワイトリストは空になっており、クラスター管理者がブローカーを設定するまでユーザーが APB イメージをブローカーに追加できないようになっています。-apb で終了するすべてのイメージをホワイトリスト化するには、以下の手順を実行します。

  1. インベントリーファイルの [OSEv3:vars] セクションに以下を追加します。

    ansible_service_broker_local_registry_whitelist=['.*-apb$']
2.6.3.21.2. テンプレートサービスブローカーの設定

テンプレートサービスブローカー (TSB) は、インストール時にデフォルトで有効になります。

TSB をインストールしない場合は、template_service_broker_install パラメーターの値を false に設定します。

template_service_broker_install=false

TSB を設定するには、テンプレートとイメージストリームをサービスカタログに読み込めるように 1 つ以上のプロジェクトをブローカーのソースの namespace として定義する必要があります。インベントリーファイルの [OSEv3:vars] セクションの以下の箇所を変更して、必要なプロジェクトを設定します。

openshift_template_service_broker_namespaces=['openshift','myproject']

デフォルトでは、TSB は Pod のデプロイにノードセレクター {"region": "infra"} を使用します。インベントリーファイルの [OSEv3:vars] セクションに必要なノードセレクターを設定してこれを変更できます。

template_service_broker_selector={"region": "infra"}

2.6.3.22. Web コンソールのカスタマイズの設定

以下の Ansible 変数は、Web コンソールをカスタマイズするためのマスター設定オプションを設定します。これらのカスタマイズオプションの詳細については、「Web コンソールのカスタマイズ」を参照してください。

表2.19 Web コンソールのカスタマイズ変数

変数目的

openshift_web_console_install

Web コンソールをインストールするかどうかを決定します。true または false に設定できます。デフォルトは true です。

openshift_web_console_prefix

コンポーネントイメージのプレフィックス。たとえば、openshift3/ose-web-console:v3.9 の場合は、プレフィックス openshift3/ose- と設定します。

openshift_web_console_version

コンポーネントイメージのバージョン。たとえば、openshift3/ose-web-console:v3.9 の場合は、プレフィックス openshift3/ose- を設定します。openshift3/ose-web-console:v3.9.11 の場合は、バージョンを v3.9.11 と設定します。または、常に最新の 3.9 イメージを取得できるようにするには、v3.9 を設定します。

openshift_master_logout_url

Web コンソールの設定で clusterInfo.logoutPublicURL を設定します。詳細については、「ログアウト URL の変更」を参照してください。値の例: https://example.com/logout

openshift_web_console_extension_script_urls

Web コンソールの設定で extensions.scriptURLs を設定します。詳細については、「拡張スクリプトとスタイルシートの読み込み」を参照してください。値の例: ['https://example.com/scripts/menu-customization.js','https://example.com/scripts/nav-customization.js']

openshift_web_console_extension_stylesheet_urls

Web コンソール設定で extensions.stylesheetURLs を設定します。詳細については、「拡張スクリプトとスタイルシートの読み込み」を参照してください。値の例: ['https://example.com/styles/logo.css','https://example.com/styles/custom-styles.css']

openshift_master_oauth_template

マスター設定で OAuth テンプレートを設定します。詳細については、「ログインページのカスタマイズ」を参照してください。値の例: ['/path/to/login-template.html']

openshift_master_metrics_public_url

マスター設定で metricsPublicURL を設定します。詳細については、「メトリクスのパブリック URL の設定」を参照してください。値の例: https://hawkular-metrics.example.com/hawkular/metrics

openshift_master_logging_public_url

マスター設定で loggingPublicURL を設定します。詳細については、「Kibana」を参照してください。値の例: https://kibana.example.com

openshift_web_console_inactivity_timeout_minutes

アクティブでない状態が一定期間続いた後にユーザーを自動的にログアウトするように Web コンソールを設定します。5 以上の整数を指定する必要があります。この機能を無効にする場合は 0 を指定します。デフォルトは 0 (無効) です。

openshift_web_console_cluster_resource_overrides_enabled

クラスターがオーバーコミット対応に設定されているかどうかを示すブール値。true の場合、リソースの上限の編集時に、Web コンソールには CPU 要求、CPU 制限およびメモリー要求のフィールドは表示されません。これらの値は、クラスターリソースのオーバーライド設定で設定する必要があるためです。

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

ノード (region=infra ラベル付き)

infra-node2.example.com

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters][etcd]、および [nodes] セクションに記載されています。

単一マスター、単一 etcd、および複数ノードのインベントリーファイル

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

# If ansible_ssh_user is not root, ansible_become must be set to true
#ansible_become=true

openshift_deployment_type=openshift-enterprise
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
master.example.com

# host group for nodes, includes region info
[nodes]
master.example.com
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
node2.example.com openshift_node_labels="{'region': 'primary', 'zone': 'west'}"
infra-node1.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
infra-node2.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"

重要

ノードホストラベルの設定」を参照し、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

ノード (region=infra ラベル付き)

infra-node2.example.com

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters][nodes]、および [etcd] セクションに記載されています。

単一マスター、複数 etcd、および複数ノードのインベントリーファイル

# Create an OSEv3 group that contains the masters, nodes, and etcd groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# host group for masters
[masters]
master.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# host group for nodes, includes region info
[nodes]
master.example.com
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
node2.example.com openshift_node_labels="{'region': 'primary', 'zone': 'west'}"
infra-node1.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
infra-node2.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"

重要

ノードホストラベルの設定」を参照し、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_hostnameopenshift_master_cluster_hostname の両方の値になります。

詳細については、「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

ノード (region=infra ラベル付き)

infra-node2.example.com

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters][etcd][lb] および [nodes] セクションに記載されています。

HAProxy インベントリーファイルを使用する複数マスター

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# Uncomment the following to enable htpasswd authentication; defaults to
# DenyAllPasswordIdentityProvider.
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# Native high availbility cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# apply updated node defaults
openshift_node_kubelet_args={'pods-per-core': ['10'], 'max-pods': ['250'], 'image-gc-high-threshold': ['90'], 'image-gc-low-threshold': ['80']}

# enable ntp on masters to ensure proper failover
openshift_clock_enabled=true

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
node2.example.com openshift_node_labels="{'region': 'primary', 'zone': 'west'}"
infra-node1.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
infra-node2.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"

重要

ノードホストラベルの設定」を参照し、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

ノード (region=infra ラベル付き)

infra-node2.example.com

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters][etcd][lb] および [nodes] セクションに記載されています。

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise
oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true

# Uncomment the following to enable htpasswd authentication; defaults to
# DenyAllPasswordIdentityProvider.
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# Native high availability cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
master1.example.com
master2.example.com
master3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
node2.example.com openshift_node_labels="{'region': 'primary', 'zone': 'west'}"
infra-node1.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
infra-node2.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
重要

ノードホストラベルの設定」を参照し、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 ベースのインストーラーを実行するには、以下の手順を実行します。

  1. prerequisites.yml Playbook を実行します。この Playbook にはソフトウェアパッケージが必要であり (ある場合)、コンテナーランタイムを変更します。コンテナーランタイムを設定する必要がない限り、この Playbook はクラスターの初回のデプロイ前に 1 度のみ実行します。

    # ansible-playbook [-i /path/to/inventory] \  1
        /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml
    1
    インベントリーファイルが /etc/ansible/hosts ディレクトリーにない場合、-i およびインベントリーファイルのパスを指定します。
  2. deploy_cluster.yml Playbook を実行してクラスターインストールを開始します。

    # ansible-playbook [-i /path/to/inventory] \
        /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml

何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に「既知の問題」に目を通し、特定の指示や回避策がないかどうか確認してください。

警告

インストーラーは、デフォルトで 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 ユーザーとして実行します。

  1. prerequisites.yml Playbook を実行します。

    # atomic install --system \
        --storage=ostree \
        --set INVENTORY_FILE=/path/to/inventory \ 1
        --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml \
        --set OPTS="-v" \
        registry.access.redhat.com/openshift3/ose-ansible:v3.9
    1
    ローカルホスト上にインベントリーファイルの場所を指定します。

    このコマンドは、指定されるインベントリーファイルと root ユーザーの SSH 設定を使用して一連の前提条件タスクを実行します。

  2. deploy_cluster.yml Playbook を実行します。

    # atomic install --system \
        --storage=ostree \
        --set INVENTORY_FILE=/path/to/inventory \ 1
        --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml \
        --set OPTS="-v" \
        registry.access.redhat.com/openshift3/ose-ansible:v3.9
    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 を実行するには、以下のコマンドを使用します。

# atomic install --system \
    --storage=ostree \
    --set INVENTORY_FILE=/path/to/inventory \
    --set PLAYBOOK_FILE=/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml \ 1
    --set OPTS="-v" \ 2
    registry.access.redhat.com/openshift3/ose-ansible:v3.9
1
PLAYBOOK_FILEplaybooks/ ディレクトリーで始まる Playbook のフルパスに設定します。 Playbook は、RPM ベースのインストーラーと同じ場所にあります。
2
OPTS を設定して、コマンドラインオプションを ansible-playbook に追加します。
2.6.5.2.3. インストーラーを Docker コンテナーとして実行する

インストーラーイメージは、docker が実行できる任意の場所で docker コンテナーとして実行することもできます。

警告

この方法は、設定されているホストのいずれかでインストーラーを実行するために使用しないでください。インストールによってホストで docker が再起動され、インストーラーコンテナーの実行が中断する可能性があります。

注記

この方法と上記のシステムコンテナー方法は同じイメージを使用しますが、それぞれ異なるエントリーポイントとコンテキストで実行されます。そのため、ランタイムパラメーターは同じではありません。

インストーラーを docker コンテナーとして実行する場合は、少なくとも以下を指定する必要があります。

  • SSH キー (Ansible がホストにアクセスできるようにするため)。
  • Ansible インベントリーファイル。
  • そのインベントリーに対して実行する Ansible Playbook の場所。

次に、docker 経由でインストールを実行する方法の例を示します。これは、docker へのアクセス権限を持つ非 root ユーザーとして実行する必要があります。

  1. まず、prerequisites.yml Playbook を実行します。

    $ docker run -t -u `id -u` \ 1
        -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \ 2
        -v $HOME/ansible/hosts:/tmp/inventory:Z \ 3
        -e INVENTORY_FILE=/tmp/inventory \ 4
        -e PLAYBOOK_FILE=playbooks/prerequisites.yml \ 5
        -e OPTS="-v" \ 6
        registry.access.redhat.com/openshift3/ose-ansible:v3.9
    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 を使用して省サイドを上げることができます)。
  2. 次に、deploy_cluster.yml playbook を実行してクラスターインストールを開始します。

    $ docker run -t -u `id -u` \
        -v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Z \
        -v $HOME/ansible/hosts:/tmp/inventory:Z \
        -e INVENTORY_FILE=/tmp/inventory \
        -e PLAYBOOK_FILE=playbooks/deploy_cluster.yml \
        -e OPTS="-v" \
        registry.access.redhat.com/openshift3/ose-ansible:v3.9
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

2.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>

以下の表は、Playbook が実行される順序で Playbook を一覧表示しています。

表2.20 個別コンポーネント 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. インストールの検証

インストールが完了したら、次の手順を実行します。

  1. マスターが起動しており、ノードが登録されており、Ready ステータスで報告されていることを確認します。マスターホストで 以下を root で実行します。

    # 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+a0ce1bc657
  2. Web コンソールが正常にインストールされているか確認するには、マスターホスト名と Web コンソールのポート番号を使用して Web ブラウザーで Web コンソールにアクセスします。

    たとえば、ホスト名が master.openshift.comで、デフォルトポート 8443 を使用するマスターホストの場合、Web コンソールは https://master.openshift.com:8443/console にあります。

複数 etcd ホストの確認

複数 etcd ホストをインストールした場合は、以下の手順を実行します。

  1. まず、 etcdctl コマンドを提供する etcd パッケージがインストールされていることを確認します。

    # yum install etcd
  2. マスターホストで 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
  3. メンバーリストが正しいことも確認します。

    # 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
HAProxy を使用する複数マスターの確認

HAProxy を使用する複数マスターをロードバランサーとしてインストールした場合は、[lb] セクションの定義に従って次の URL に移動し、HAProxy のステータスを確認します。

http://<lb_hostname>:9000

HAProxy の設定に関するドキュメントを参照してインストールを検証できます。

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

2.6.8.1. ノードのアンインストール

uninstall.yml playbook を使用すると、ノードコンポーネントを特定のホストからアンインストールし、それ以外のホストとクラスターをそのままにしておくことができます。

警告

この方法は、特定のノードホストをアンインストールする場合にのみ使用してください。特定のマスターホストや etcd ホストのアンインストールには使用しないでください。これらのホストをアンインストールするには、クラスター内での追加の設定変更が必要になります。

  1. まず、「ノードの削除」の手順に従ってクラスターからノードオブジェクトを削除します。次に、この残りの手順を実行します。
  2. これらのホストのみを参照する別のインベントリーファイルを作成します。たとえば、1 つのノードのみからコンテンツを削除する場合は、以下を実行します。

    [OSEv3:children]
    nodes 1
    
    [OSEv3:vars]
    ansible_ssh_user=root
    openshift_deployment_type=openshift-enterprise
    
    [nodes]
    node3.example.com openshift_node_labels="{'region': 'primary', 'zone': 'west'}" 2
    1
    アンインストールするホストに関連するセクションのみを含めます。
    2
    アンインストールするホストのみを含めます。
  3. uninstall.yml playbook の実行時に、-i オプションを使用して新規インベントリーファイルを指定します。

    # ansible-playbook -i /path/to/new/file \
        /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml

Playbook が完了すると、すべての OpenShift Container Platform コンテンツが指定したホストから削除されます。

2.6.9. 既知の問題

  • 複数マスタークラスターでフェイルオーバーが発生すると、コントローラーマネージャーの過剰修正が生じ、結果として予定よりも多くの Pod がシステムで実行される可能性があります。ただし、これは一時的なイベントであり、後にシステムによって修正されます。詳細については、https://github.com/kubernetes/kubernetes/issues/10030 を参照してください。
  • Ansible インストーラーが失敗する場合でも、OpenShift Container Platform をインストールできます。

    • SDN 設定を変更しておらず、新規証明書を生成する場合は、deploy_cluster.yml Playbook を再度実行します。
    • SDN 設定を変更し、新規証明書を生成している場合、またはインストーラーが再び失敗する場合、クリーンなオペレーティングシステムインストールで起動し直すか、またはアンインストールし、再度インストールする必要があります。
    • 仮想マシンを使用する場合、新規イメージから起動するか、またはアンインストールを実行して再度インストールします。
    • ベアメタルマシンを使用する場合、再度アンインストールおよびインストールを実行します。
  • 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 インスタンスが機能し、以下を実行できるようになります。

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

キーをインポートしない場合、指定したパッケージはリポジトリーの同期後に削除されます。

必要なリポジトリーを同期するには、次の手順を実行します。

  1. サーバーを Red Hat カスタマーポータルに登録します。OpenShift Container Platform サブスクリプションにアクセスできるアカウントに関連付けられているログインとパスワードを使用する必要があります。

    $ subscription-manager register
  2. RHSM から最新サブスクリプションデータをプルします。

    $ subscription-manager refresh
  3. OpenShift Container Platform チャンネルを提供するサブスクリプションにアタッチします。使用可能なサブスクリプションの一覧は、以下のコマンドで確認できます。

    $ subscription-manager list --available --matches '*OpenShift*'

    次に、OpenShift Container Platform を提供するサブスクリプションのプール ID を見つけ、これをアタッチします。

    $ subscription-manager attach --pool=<pool_id>
    $ subscription-manager repos --disable="*"
    $ subscription-manager repos \
        --enable="rhel-7-server-rpms" \
        --enable="rhel-7-server-extras-rpms" \
        --enable="rhel-7-fast-datapath-rpms" \
        --enable="rhel-7-server-ansible-2.4-rpms" \
        --enable="rhel-7-server-ose-3.9-rpms"
  4. yum-utils コマンドは、reposync ユーティリティーを提供します。これによって yum リポジトリーをミラーリングでき、createrepo で使用可能な yum リポジトリーをディレクトリーから作成できます。

    $ sudo yum -y install yum-utils createrepo docker git

    ソフトウェアを同期するには、最大 110GB の空き容量が必要です。組織のポリシーの制限のレベルによっては、このサーバーを非接続 LAN に再接続し、これをリポジトリーサーバーとして使用できます。USB 接続ストレージを使用し、ソフトウェアをリポジトリーサーバーとして機能する別のサーバーに転送できます。このトピックでは、これらのオプションについて説明します。

  5. ソフトウェアを同期する場所へのパスを作成します (ローカル、USB その他デバイスのいずれか)。

    $ mkdir -p </path/to/repos>
  6. パッケージを同期し、各パッケージのリポジトリーを作成します。上記の手順で作成した適切なパスに合わせてコマンドを変更する必要がります。

    $ for repo in \
    rhel-7-server-rpms \
    rhel-7-server-extras-rpms \
    rhel-7-fast-datapath-rpms \
    rhel-7-server-ansible-2.4-rpms \
    rhel-7-server-ose-3.9-rpms
    do
      reposync --gpgcheck -lm --repoid=${repo} --download_path=/path/to/repos
      createrepo -v </path/to/repos/>${repo} -o </path/to/repos/>${repo}
    done

2.7.3.2. イメージの同期

コンテナーイメージを同期するには、以下を実行します。

  1. Docker デーモンを起動します。

    $ systemctl start docker
  2. 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>
  3. 必要な OpenShift Container Platform インフラストラクチャーコンポーネントイメージすべてをプルします。<tag> を最新バージョンの v3.9.43 に置き換えます。

    $ docker pull registry.access.redhat.com/openshift3/ose-ansible:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-cluster-capacity:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-deployer:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-docker-builder:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-docker-registry:<tag>
    $ docker pull registry.access.redhat.com/openshift3/registry-console:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-egress-http-proxy:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-egress-router:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-f5-router:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-haproxy-router:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-keepalived-ipfailover:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-pod:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-sti-builder:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-template-service-broker:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose-web-console:<tag>
    $ docker pull registry.access.redhat.com/openshift3/ose:<tag>
    $ docker pull registry.access.redhat.com/openshift3/container-engine:<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
    注記

    NFS を使用している場合は、ose-recycler イメージが必要です。これを使用しないと、ボリュームはリサイクルされず、エラーが発生する可能性があります。

    リサイクル回収ポリシーは動的プロビジョニングが優先されるために非推奨となり、今後のリリースでは削除されます。

  4. 追加の一元的なログ集約およびメトリクス集約コンポーネントに必要な OpenShift Container Platform のコンテナー化されたコンポーネントすべてをプルします。<tag> を最新バージョンの v3.9.43 に置き換えます。

    $ docker pull registry.access.redhat.com/openshift3/logging-auth-proxy:<tag>
    $ docker pull registry.access.redhat.com/openshift3/logging-curator:<tag>
    $ docker pull registry.access.redhat.com/openshift3/logging-elasticsearch:<tag>
    $ docker pull registry.access.redhat.com/openshift3/logging-fluentd:<tag>
    $ docker pull registry.access.redhat.com/openshift3/logging-kibana:<tag>
    $ docker pull registry.access.redhat.com/openshift3/oauth-proxy:<tag>
    $ docker pull registry.access.redhat.com/openshift3/metrics-cassandra:<tag>
    $ docker pull registry.access.redhat.com/openshift3/metrics-hawkular-metrics:<tag>
    $ docker pull registry.access.redhat.com/openshift3/metrics-hawkular-openshift-agent:<tag>
    $ docker pull registry.access.redhat.com/openshift3/metrics-heapster:<tag>
    $ docker pull registry.access.redhat.com/openshift3/prometheus:<tag>
    $ docker pull registry.access.redhat.com/openshift3/prometheus-alert-buffer:<tag>
    $ docker pull registry.access.redhat.com/openshift3/prometheus-alertmanager:<tag>
    $ docker pull registry.access.redhat.com/openshift3/prometheus-node-exporter:<tag>
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-postgresql
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-memcached
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-app-ui
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-app
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-embedded-ansible
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-openshift-httpd
    $ docker pull registry.access.redhat.com/cloudforms46/cfme-httpd-configmap-generator
    $ docker pull registry.access.redhat.com/rhgs3/rhgs-server-rhel7
    $ docker pull registry.access.redhat.com/rhgs3/rhgs-volmanager-rhel7
    $ docker pull registry.access.redhat.com/rhgs3/rhgs-gluster-block-prov-rhel7
    $ docker pull registry.access.redhat.com/rhgs3/rhgs-s3-server-rhel7
    重要

    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/ を参照してください。

  5. サービスカタログ、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>
  6. OpenShift 環境で使用する Red Hat 認定の Source-to-Image (S2I) ビルダーイメージをプルします。以下のイメージをプルできます。

    $ docker pull registry.access.redhat.com/jboss-amq-6/amq63-openshift
    $ docker pull registry.access.redhat.com/jboss-datagrid-7/datagrid71-openshift
    $ docker pull registry.access.redhat.com/jboss-datagrid-7/datagrid71-client-openshift
    $ docker pull registry.access.redhat.com/jboss-datavirt-6/datavirt63-openshift
    $ docker pull registry.access.redhat.com/jboss-datavirt-6/datavirt63-driver-openshift
    $ docker pull registry.access.redhat.com/jboss-decisionserver-6/decisionserver64-openshift
    $ docker pull registry.access.redhat.com/jboss-processserver-6/processserver64-openshift
    $ docker pull registry.access.redhat.com/jboss-eap-6/eap64-openshift
    $ docker pull registry.access.redhat.com/jboss-eap-7/eap70-openshift
    $ docker pull registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift
    $ docker pull registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat8-openshift
    $ docker pull registry.access.redhat.com/openshift3/jenkins-1-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-2-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-slave-maven-rhel7
    $ docker pull registry.access.redhat.com/openshift3/jenkins-slave-nodejs-rhel7
    $ docker pull registry.access.redhat.com/rhscl/mongodb-32-rhel7
    $ docker pull registry.access.redhat.com/rhscl/mysql-57-rhel7
    $ docker pull registry.access.redhat.com/rhscl/perl-524-rhel7
    $ docker pull registry.access.redhat.com/rhscl/php-56-rhel7
    $ docker pull registry.access.redhat.com/rhscl/postgresql-95-rhel7
    $ docker pull registry.access.redhat.com/rhscl/python-35-rhel7
    $ docker pull registry.access.redhat.com/redhat-sso-7/sso70-openshift
    $ docker pull registry.access.redhat.com/rhscl/ruby-24-rhel7
    $ docker pull registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift
    $ docker pull registry.access.redhat.com/redhat-sso-7/sso71-openshift
    $ docker pull registry.access.redhat.com/rhscl/nodejs-6-rhel7
    $ docker pull registry.access.redhat.com/rhscl/mariadb-101-rhel7

    必要なバージョン番号を示す適切なタグを指定してください。たとえば、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

2.7.3.3. イメージのエクスポートの準備

コンテナーイメージをシステムからエクスポートできます。これを行うには、まずコンテナーイメージを tarball に保存し、次にそれを転送します。

  1. リポジトリーのホームディレクトリーを作成し、これに移動します。

    $ mkdir </path/to/repos/images>
    $ cd </path/to/repos/images>
  2. 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
  3. OpenShift Container Platform インフラストラクチャーコンポーネントのイメージをエクスポートします。

    $ docker save -o ose3-images.tar \
        registry.access.redhat.com/openshift3/ose-ansible \
        registry.access.redhat.com/openshift3/ose-ansible-service-broker \
        registry.access.redhat.com/openshift3/ose-cluster-capacity \
        registry.access.redhat.com/openshift3/ose-deployer \
        registry.access.redhat.com/openshift3/ose-docker-builder \
        registry.access.redhat.com/openshift3/ose-docker-registry \
        registry.access.redhat.com/openshift3/registry-console
        registry.access.redhat.com/openshift3/ose-egress-http-proxy \
        registry.access.redhat.com/openshift3/ose-egress-router \
        registry.access.redhat.com/openshift3/ose-f5-router \
        registry.access.redhat.com/openshift3/ose-haproxy-router \
        registry.access.redhat.com/openshift3/ose-keepalived-ipfailover \
        registry.access.redhat.com/openshift3/ose-pod \
        registry.access.redhat.com/openshift3/ose-sti-builder \
        registry.access.redhat.com/openshift3/ose-template-service-broker \
        registry.access.redhat.com/openshift3/ose-web-console \
        registry.access.redhat.com/openshift3/ose \
        registry.access.redhat.com/openshift3/container-engine \
        registry.access.redhat.com/openshift3/node \
        registry.access.redhat.com/openshift3/openvswitch \
        registry.access.redhat.com/openshift3/prometheus \
        registry.access.redhat.com/openshift3/prometheus-alert-buffer \
        registry.access.redhat.com/openshift3/prometheus-alertmanager \
        registry.access.redhat.com/openshift3/prometheus-node-exporter \
        registry.access.redhat.com/cloudforms46/cfme-openshift-postgresql \
        registry.access.redhat.com/cloudforms46/cfme-openshift-memcached \
        registry.access.redhat.com/cloudforms46/cfme-openshift-app-ui \
        registry.access.redhat.com/cloudforms46/cfme-openshift-app \
        registry.access.redhat.com/cloudforms46/cfme-openshift-embedded-ansible \
        registry.access.redhat.com/cloudforms46/cfme-openshift-httpd \
        registry.access.redhat.com/cloudforms46/cfme-httpd-configmap-generator \
        registry.access.redhat.com/rhgs3/rhgs-server-rhel7 \
        registry.access.redhat.com/rhgs3/rhgs-volmanager-rhel7 \
        registry.access.redhat.com/rhgs3/rhgs-gluster-block-prov-rhel7 \
        registry.access.redhat.com/rhgs3/rhgs-s3-server-rhel7
    重要

    Red Hat サポートについては、CNS のサブスクリプションが rhgs3/ イメージに必要です。

  4. メトリクスとログ集約イメージを同期した場合は、それらをエクスポートします。

    $ docker save -o ose3-logging-metrics-images.tar \
        registry.access.redhat.com/openshift3/logging-auth-proxy \
        registry.access.redhat.com/openshift3/logging-curator \
        registry.access.redhat.com/openshift3/logging-elasticsearch \
        registry.access.redhat.com/openshift3/logging-fluentd \
        registry.access.redhat.com/openshift3/logging-kibana \
        registry.access.redhat.com/openshift3/metrics-cassandra \
        registry.access.redhat.com/openshift3/metrics-hawkular-metrics \
        registry.access.redhat.com/openshift3/metrics-hawkular-openshift-agent \
        registry.access.redhat.com/openshift3/metrics-heapster
  5. 前のセクションで同期した S2I ビルダーイメージをエクスポートします。たとえば、Jenkins イメージと Tomcat イメージのみを同期した場合は、以下を実行します。

    $ docker save -o ose3-builder-images.tar \
        registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:latest \
        registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:1.1 \
        registry.access.redhat.com/openshift3/jenkins-1-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-2-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-slave-maven-rhel7 \
        registry.access.redhat.com/openshift3/jenkins-slave-nodejs-rhel7

2.7.4. リポジトリーサーバー

インストール時に (選択する場合はその後のアップデート時に)、リポジトリーをホストするための Web サーバーが必要となります。RHEL 7 では、Apache Web サーバーを提供しています。

オプション 1 : Web サーバーとしての再設定

ソフトウェアとイメージを LAN に同期しているサーバーに再接続ができる場合は、Apache をそのサーバーに単純にインストールできます。

$ sudo yum install httpd

ソフトウェアの配置に進んでください。

オプション 2: リポジトリーサーバーの構築

リポジトリーサーバーとして機能する別のサーバーを設定する必要がある場合には、110 GB 以上の空き領域を持つ新規の RHEL 7 システムをインストールしてください。インストール時に、このリポジトリーサーバーで Basic Web Server オプションが選択されていることを確認します。

2.7.4.1. ソフトウェアの配置

  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
  2. ファイアウォールのルールを追加します。

    $ sudo firewall-cmd --permanent --add-service=http
    $ sudo firewall-cmd --reload
  3. 変更を有効にするには、Apache を有効にしてから起動します。

    $ systemctl enable httpd
    $ systemctl start httpd

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 またはホスト名に置き換えます。

[rhel-7-server-rpms]
name=rhel-7-server-rpms
baseurl=http://<server_IP>/repos/rhel-7-server-rpms
enabled=1
gpgcheck=0
[rhel-7-server-extras-rpms]
name=rhel-7-server-extras-rpms
baseurl=http://<server_IP>/repos/rhel-7-server-extras-rpms
enabled=1
gpgcheck=0
[rhel-7-fast-datapath-rpms]
name=rhel-7-fast-datapath-rpms
baseurl=http://<server_IP>/repos/rhel-7-fast-datapath-rpms
enabled=1
gpgcheck=0
[rhel-7-server-ansible-2.4-rpms]
name=rhel-7-server-ansible-2.4-rpms
baseurl=http://<server_IP>/repos/rhel-7-server-ansible-2.4-rpms
enabled=1
gpgcheck=0
[rhel-7-server-ose-3.9-rpms]
name=rhel-7-server-ose-3.9-rpms
baseurl=http://<server_IP>/repos/rhel-7-server-ose-3.9-rpms
enabled=1
gpgcheck=0

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"

インストールがコンテナー化される場合は、ホストコンポーネントに同じ手順を実行します。クラスターでメトリクスおよびロギングイメージを使用する場合は、それらについて同じ手順を実行します。

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 ビルダーイメージの再タグ付け

  1. S2I ビルダーイメージをインポートしたマスターホストで、そのマスター上にインストールした Docker レジストリーのサービスアドレスを取得します。

    $ export REGISTRY=$(oc get service -n default \
        docker-registry --output=go-template='{{.spec.clusterIP}}{{"\n"}}')
  2. 次に、OpenShift Container Platform Docker レジストリーにプッシュする前に、同期し、エクスポートしたすべてのビルダーイメージにタグ付けします。たとえば、Tomcat イメージのみを同期し、エクスポートした場合、以下のようになります。

    $ docker tag \
    registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:1.1 \
    $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:1.1
    $ docker tag \
    registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:latest \
    $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:1.2
    $ docker tag \
    registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:latest \
    $REGISTRY:5000/openshift/webserver30-tomcat7-openshift:latest

2.7.7.2. レジストリーの場所の設定

registry.access.redhat.com にあるデフォルト以外のイメージレジストリーを使用する場合は、目的のレジストリーを /etc/ansible/hosts ファイル内に指定します。

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
注記

ホストの IP アドレスに openshift_docker_insecure_registries 変数を設定することもできます。0.0.0.0/0 は有効な設定ではありません。

表2.21 レジストリー変数

変数目的

oreg_url

代わりのイメージの場所に設定します。registry.access.redhat.com にあるデフォルトレジストリーを使用しない場合は必須です。

openshift_examples_modify_imagestreams

デフォルト以外のレジストリーを参照している場合は true に設定します。イメージストリームの場所を oreg_url の値に変更します。

openshift_docker_additional_registries

openshift_docker_additional_registries を設定し、/etc/sysconfig/dockeradd_registry 行にその値を追加します。add_registry を使うと、独自のレジストリーを追加して Docker search とDocker pull に使用できます。先頭に --add-registry フラグを付けて一連のレジストリーを一覧表示するには、add_registry オプションを使用します。追加された最初のレジストリーが、検索される最初のレジストリーになります。例: add_registry=--add-registry registry.access.redhat.com --add-registry example.com

openshift_docker_insecure_registries

openshift_docker_insecure_registries を設定し、/etc/sysconfig/dockerinsecure_registry 行にその値を追加します。HTTPS でセキュリティー保護されている レジストリーがあるが、適切な証明書が配布されていない場合、 レジストリーを insecure_registry 行に追加してコメント解除すれば、Docker に対して完全な承認を要求しないように指示できます。例: insecure_registry—​insecure-registry example.com。ホスト名またはホストの IP アドレスに設定できます。0.0.0.0/0 は IP アドレスの有効な設定ではありません。

2.7.7.3. 管理ユーザーの作成

コンテナーイメージを OpenShift Container Platform の Docker レジストリーにプッシュするには、ユーザーに cluster-admin 権限が必要です。OpenShift Container Platform のデフォルトのシステム管理者は標準の認証トークンを持っていないので、Docker レジストリーへのログインには使用できません。

管理ユーザーを作成するには、以下を実行します。

  1. OpenShift Container Platform で使用している認証システムで新規ユーザーアカウントを作成します。たとえば、ローカルの htpasswd ベースの認証を使用している場合、以下のようになります。

    $ htpasswd -b /etc/openshift/openshift-passwd <admin_username> <password>
  2. これで、外部の認証システムにユーザーアカウントが作成されます。ただしユーザーは、アカウントが内部データベースに作成される前に 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
  3. ユーザーの認証トークンを取得します。

    $ MYTOKEN=$(oc whoami -t)
    $ echo $MYTOKEN
    iwo7hc4XilD2KOLL4V1O55ExH2VlPmLD-W2-JOd6Fko

2.7.7.4. セキュリティーポリシーの変更

  1. oc login を使用すると、新しいユーザーに切り替わります。ポリシーを変更するには、OpenShift Container Platform のシステム管理者に再度切り替えます。

    $ oc login -u system:admin
  2. イメージを OpenShift Container Platform Docker レジストリーにプッシュするには、アカウントに image-builder セキュリティーロールが必要です。このロールを、OpenShift Container Platform 管理ユーザーに追加します。

    $ oc adm policy add-role-to-user system:image-builder <admin_username>
  3. 次に、openshift プロジェクトのユーザーに管理者ロールを追加します。これで、管理ユーザーは openshift プロジェクトを編集できるようになります。ここでは、コンテナーイメージをプッシュします。

    $ oc adm policy add-role-to-user admin <admin_username> -n openshift

2.7.7.5. イメージストリームの定義の編集

openshift プロジェクトでは、ビルダーイメージのすべてのイメージストリームはインストーラーによって作成されます。イメージストリームは、インストーラーが /usr/share/openshift/examples ディレクトリーから読み込まれます。OpenShift Container Platform のデータベースに読み込まれたイメージストリームを削除することですべての定義を変更し、これらを再作成します。

  1. 既存のイメージストリームを削除します。

    $ oc delete is -n openshift --all
  2. 必要な場合、ファイルのバックアップを /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": "172.30.69.44:5000/openshift/httpd-24-rhel7"
    }

    上記では、リポジトリー名が rhscl から openshift に変更されています。リポジトリーが rhsclopenshift3、またはそれ以外のディレクトリーであるかどうかにかかわらず、変更を確認する必要があります。すべての定義に以下の形式が使用されます。

    <registry_ip>:5000/openshift/<image_name>

    この変更を、ファイル内のすべてのイメージストリームに対して繰り返し実行します。先の手順で判別した正しい IP アドレスが使用されていることを確認します。終了したら、保存して終了します。/usr/share/openshift/examples/xpaas-streams/jboss-image-streams.json ファイルにある JBoss イメージストリームについても同じ手順を繰り返します。

2.7.7.6. コンテナーイメージの読み込み

この時点で、システムはコンテナーイメージを読み込むことができます。

  1. 先の手順で取得したトークンとレジストリーのサービス IP を使って Docker レジストリーにログインします。

    $ docker login -u adminuser -e mailto:adminuser@abc.com \
       -p $MYTOKEN $REGISTRY:5000
  2. 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
  3. 更新されたイメージストリームの定義を読み込みます。

    $ 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
  4. すべてのイメージストリームにタグが設定されていることを確認します。

    $ 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
    ...

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 には以下の機能があります。

管理者は、スタンドアロン 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 レジストリーをインストールする方法を順を追って説明します。

  1. 対話型インストールを開始します。

    $ atomic-openshift-installer install
  2. 画面の指示に従って新規レジストリーをインストールします。インストールに関する質問は、OpenShift Container Platform PaaS をすべてインストールする場合とほとんど同じです。以下の画面まで進んだら、2 を選択してレジストリーのインストールパスに従ってください。

    Which variant would you like to install?
    
    
    (1) OpenShift Container Platform
    (2) Registry
  3. クラスターを構成しているホストを指定します。

    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]:

    RPM とコンテナー化ホストとの比較に関する情報は、コンテナー化ホストでのインストールのトピックを参照してください。

  4. 必要な場合は、クラスターのホスト名を変更します。

    Enter hostname or IP address [None]:
  5. ストレージホストとして機能するホストを選択します (デフォルトではマスターホスト)。

    Enter hostname or IP address [master.host.example.com]:
  6. 必要な場合は、デフォルトのサブドメインを変更します。

    New default subdomain (ENTER for none) []:
    注記

    すべての証明書とルートはこのサブドメインで作成されます。インストール後に設定を変更しなくてすむように、これが適切なサブドメインに設定されていることを確認してください。

  7. 必要に応じて HTTP または HTTPS プロキシーを指定します。

    Specify your http proxy ? (ENTER for none) []:
    Specify your https proxy ? (ENTER for none) []:

上記を入力したら、次ページでインストールの概要が示され、ホスト情報の収集が開始されます。

注記

以下の手順を含む、一般的なクイックインストーラーの使用に関する詳細は、「クイックインストール」のトピックすべてを参照してください。

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 レジストリーインベントリーファイル

# Create an OSEv3 group that contains the masters and nodes groups
[OSEv3:children]
masters
nodes
etcd

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
# SSH user, this user should allow ssh based auth without requiring a password
ansible_ssh_user=root

openshift_master_default_subdomain=apps.test.example.com

# If ansible_ssh_user is not root, ansible_become must be set to true
#ansible_become=true

openshift_deployment_type=openshift-enterprise
deployment_subtype=registry 1
openshift_hosted_infra_selector="" 2

# uncomment the following to enable htpasswd authentication; defaults to DenyAllPasswordIdentityProvider
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# host group for masters
[masters]
registry.example.com

# host group for etcd
[etcd]
registry.example.com

# host group for nodes
[nodes]
registry.example.com

1
deployment_subtype=registry を設定して、OpenShift Container Platform 環境のすべてではなく、スタンドアロン OCR がインストールされるようにします。
2
レジストリーとその Web コンソールが単一ホストでスケジュールされることを可能にします。

複数マスター (高可用性) スタンドアロン OpenShift Container レジストリーインベントリーファイル

# Create an OSEv3 group that contains the master, nodes, etcd, and lb groups.
# The lb group lets Ansible configure HAProxy as the load balancing solution.
# Comment lb out if your load balancer is pre-configured.
[OSEv3:children]
masters
nodes
etcd
lb

# Set variables common for all OSEv3 hosts
[OSEv3:vars]
ansible_ssh_user=root
openshift_deployment_type=openshift-enterprise
deployment_subtype=registry 1

openshift_master_default_subdomain=apps.test.example.com

# Uncomment the following to enable htpasswd authentication; defaults to
# DenyAllPasswordIdentityProvider.
#openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]

# Native high availability cluster method with optional load balancer.
# If no lb group is defined installer assumes that a load balancer has
# been preconfigured. For installation the value of
# openshift_master_cluster_hostname must resolve to the load balancer
# or to one or all of the masters defined in the inventory if no load
# balancer is present.
openshift_master_cluster_method=native
openshift_master_cluster_hostname=openshift-internal.example.com
openshift_master_cluster_public_hostname=openshift-cluster.example.com

# apply updated node defaults
openshift_node_kubelet_args={'pods-per-core': ['10'], 'max-pods': ['250'], 'image-gc-high-threshold': ['90'], 'image-gc-low-threshold': ['80']}

# enable ntp on masters to ensure proper failover
openshift_clock_enabled=true

# host group for masters
[masters]
master1.example.com
master2.example.com
master3.example.com

# host group for etcd
[etcd]
etcd1.example.com
etcd2.example.com
etcd3.example.com

# Specify load balancer host
[lb]
lb.example.com

# host group for nodes, includes region info
[nodes]
master[1:3].example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
node1.example.com openshift_node_labels="{'region': 'primary', 'zone': 'east'}"
node2.example.com openshift_node_labels="{'region': 'primary', 'zone': 'west'}"

1
deployment_subtype=registry を設定して、OpenShift Container Platform 環境のすべてではなく、スタンドアロン OCR がインストールされるようにします。

/etc/ansible/hosts でインベントリーファイルを定義して Ansible を設定した後に、以下を実行します。

  1. 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
  2. deploy_cluster.yml Playbook を実行してインストールを開始します。

    # ansible-playbook  [-i /path/to/inventory] \
        /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml
注記

通常インストール (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 \1
    --service-account=registry \2
    --images='registry.access.redhat.com/openshift3/ose-${component}:${version}' 3
1
--config は、クラスター管理者のための CLI 設定ファイルへのパスです。
2
--service-account は、レジストリーの Pod の実行に使用されるサービスアカウントです。
3
OpenShift Container Platform の適切なイメージをプルするために必要です。

これでサービスとデプロイメント設定が作成されます。これらは共に docker-registry と呼ばれます。正常にデプロイされると、Pod が docker-registry-1-cpty9 などの名前付きで作成されます。

レジストリーの作成時に指定できるオプションの詳細の一覧を表示するには、以下を実行します。

$ 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 レジストリーのドキュメントを参照してください。

次の一覧には、レジストリの構成ファイルで構成する必要があるストレージドライバが含まれています。

レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。

以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。

注記

サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。

3.2.5.1. 実稼働環境での使用

実稼働環境での使用の場合には、リモートボリュームを割り当てるか、または各自が選択した永続ストレージ方法を定義して使用します

たとえば、既存の Persistent Volume Claim (永続ボリューム要求) を使用するには、以下を実行します。

$ 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 エントリーに置き換えます。これにより、ストレージのセクションは以下のようになります。

storage:
  cache:
    layerinfo: inmemory
  delete:
    enabled: true
  s3:
    accesskey: awsaccesskey 1
    secretkey: awssecretkey 2
    region: us-west-1
    regionendpoint: http://myobjects.local
    bucket: bucketname
    encrypt: true
    keyid: mykeyid
    secure: true
    v4auth: false
    chunksize: 5242880
    rootdirectory: /s3/object/name/prefix
1
Amazon のアクセスキーに置き換えてください。
2
Amazon のシークレットキーに置き換えてください。

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>
重要

Docker レジストリー Pod は、ユーザー 1001 として実行されます。このユーザーは、ホストのディレクトリーへの書き込みができなければなりません。したがって、以下のコマンドでディレクトリーの所有権をユーザー ID 1001 に変更する必要がある場合があります。

$ sudo chown 1001:root <path>

3.2.6. レジストリーコンソールの有効化

OpenShift Container Platform は、統合レジストリーへの Web ベースのインターフェースを提供します。このレジストリーコンソールは、イメージの参照と管理を行うためのオプションのコンポーネントであり、Pod として実行されるステートレスサービスとしてデプロイされます。

注記

OpenShift Container Platform をスタンドアロンレジストリーとしてインストールした場合、レジストリーコンソールはインストール時にすでにデプロイされ、そのセキュリティーが自動的に保護されています。

重要

Cockpit がすでに実行されている場合、レジストリーコンソールとのポート競合 (デフォルトでは9090) を避けるために、次に進む前にこれをシャットダウンする必要があります。

3.2.6.1. レジストリーコンソールのデプロイ

重要

最初にレジストリーを公開しておく必要があります。

  1. デフォルトのプロジェクトにパススルールートを作成します。このルートは、以下の手順でレジストリーコンソールのアプリケーションを作成する際に必要になります。

    $ oc create route passthrough --service registry-console \
        --port registry-console \
        -n default
  2. レジストリーコンソールのアプリケーションをデプロイします。<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 }}')
    注記

    レジストリーコンソールへのログインの試行時にリダイレクト URL が間違っていた場合は、oc get oauthclients で OAuth クライアントを確認してください。

  3. 最後に、Webブラウザを使用してルートURIを使用してコンソールを表示します。

3.2.6.2. レジストリーコンソールのセキュリティー保護

デフォルトでは、レジストリーコンソールは、レジストリーコンソールのデプロイの手順ごとに手動でデプロイされる場合に自己署名 TLS 証明書を生成します。詳細は、「レジストリーコンソールのトラブルシューティング」を参照してください。

組織の署名済み証明書をシークレットボリュームとして追加する際には、以下の手順に従ってください。ここでは、証明書が oc クライアントホストで利用可能であることを前提としています。

  1. 証明書とキーを含む .cert ファイルを作成します。以下を使用してファイルをフォーマットします。

    • サーバー証明書と中間証明機関のための 1 つ以上数の BEGIN CERTIFICATE ブロック。
    • キーの BEGIN PRIVATE KEY または同種のものを含むブロック。キーは暗号化することができません。

      例を以下に示します。

      -----BEGIN CERTIFICATE-----
      MIIDUzCCAjugAwIBAgIJAPXW+CuNYS6QMA0GCSqGSIb3DQEBCwUAMD8xKTAnBgNV
      BAoMIGI0OGE2NGNkNmMwNTQ1YThhZTgxOTEzZDE5YmJjMmRjMRIwEAYDVQQDDAls
      ...
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      MIIDUzCCAjugAwIBAgIJAPXW+CuNYS6QMA0GCSqGSIb3DQEBCwUAMD8xKTAnBgNV
      BAoMIGI0OGE2NGNkNmMwNTQ1YThhZTgxOTEzZDE5YmJjMmRjMRIwEAYDVQQDDAls
      ...
      -----END CERTIFICATE-----
      -----BEGIN PRIVATE KEY-----
      MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCyOJ5garOYw0sm
      8TBCDSqQ/H1awGMzDYdB11xuHHsxYS2VepPMzMzryHR137I4dGFLhvdTvJUH8lUS
      ...
      -----END PRIVATE KEY-----
    • セキュリティーの保護されたレジストリーには、以下の SAN (サブジェクトの別名: Subject Alternative Names) 一覧が含まれているはずです。

      • 2 つのサービスのホスト名。

        例を以下に示します。

        docker-registry.default.svc.cluster.local
        docker-registry.default.svc
      • サービス IP アドレス。

        例を以下に示します。

        172.30.124.220

        以下のコマンドを使って Docker レジストリーのサービス IP アドレスを取得します。

        oc get service docker-registry --template='{{.spec.clusterIP}}'
      • パブリックホスト名。

        例を以下に示します。

        docker-registry-default.apps.example.com

        以下のコマンドを使って Docker レジストリーのパブリックホスト名を取得します。

        oc get route docker-registry --template '{{.spec.host}}'

        たとえば、サーバー証明書には以下のような 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

        レジストリーコンソールは、証明書を /etc/cockpit/ws-certs.d ディレクトリーから読み込み、拡張子 .cert が付いたファイルをアルファベット順で (最後から) 使用します。したがって .cert ファイルには、 OpenSSL スタイルでフォーマットされた PEM ブロックが少なくとも 2 つ含まれている必要があります。

        証明書がない場合、自己署名証明書が openssl コマンドで作成され、0-self-signed.cert ファイルに保存されます。

  2. シークレットを作成します。

    $ oc create secret generic console-secret \
        --from-file=/path/to/console.cert
  3. このシークレットを registry-console デプロイメント設定に追加します。

    $ oc volume dc/registry-console --add --type=secret \
        --secret-name=console-secret -m /etc/cockpit/ws-certs.d

    これにより、レジストリーコンソールの新規デプロイメントがトリガーされ、署名済み証明書が組み込まれます。

3.2.6.3. レジストリーコンソールのトラブルシューティング

3.2.6.3.1. デバッグモード

レジストリーコンソールのデバッグモードは環境変数を使用して有効にされます。以下のコマンドは、レジストリーコンソールをデバッグモードで再デプロイします。

$ oc set env dc registry-console G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper

デバッグモードを有効にすると、より詳細なログがレジストリーコンソールの Pod ログに表示されます。

3.2.6.3.2. SSL 証明書パスの表示

レジストリーコンソールが使用している証明書を確認するには、コマンドをコンソール Pod から実行します。

  1. デフォルト のプロジェクトに Pod を一覧表示して、レジストリーコンソールの Pod 名を検索します。

    $ oc get pods -n default
    NAME                       READY     STATUS    RESTARTS   AGE
    registry-console-1-rssrw   1/1       Running   0          1d
  2. 直前のコマンドで取得した Pod 名を使って、cockpit-ws プロセスが使用している証明書パスを取得します。以下は、自動生成された証明書を使用しているコンソールの例です。

    $ oc exec registry-console-1-rssrw remotectl certificate
    certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert

3.3. レジストリーへのアクセス

3.3.1. ログの表示

Docker レジストリーのログを表示するには、デプロイメント設定で oc logs コマンドを使用します。

$ oc logs dc/docker-registry
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown"
2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler"
2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002

3.3.2. ファイルストレージ

タグとイメージメタデータは OpenShift Container Platform に格納されますが、レジストリーは、レイヤーと署名データを /registry にあるレジストリーコンテナーにマウントされているボリュームに格納します。oc exec は特権付きコンテナーでは機能しないため、レジストリーの内容を確認するには、レジストリー Pod のコンテナーを格納しているノードに対して SSH を手動で実行し、コンテナー自体で docker exec を実行します。

  1. 現在の Pod を一覧表示し、Docker レジストリーの Pod 名を検索します。

    # oc get pods

    次に、oc describe を使用して、コンテナーを実行しているノードのホスト名を検索します。

    # oc describe pod <pod_name>
  2. 必要なノードにログインします。

    #ssh node.example.com
  3. ノードホストのデフォルトプロジェクトから実行中のコンテナーを一覧表示し、Docker レジストリーのコンテナー ID を特定します。

    #docker ps --filter = name = registry_docker-registry。* _ default_
  4. oc rsh コマンドを使用してレジストリーの内容を一覧表示します。

    # oc rsh dc/docker-registry find /registry
    /registry/docker
    /registry/docker/registry
    /registry/docker/registry/v2
    /registry/docker/registry/v2/blobs 1
    /registry/docker/registry/v2/blobs/sha256
    /registry/docker/registry/v2/blobs/sha256/ed
    /registry/docker/registry/v2/blobs/sha256/ed/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810
    /registry/docker/registry/v2/blobs/sha256/ed/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810/data 2
    /registry/docker/registry/v2/blobs/sha256/a3
    /registry/docker/registry/v2/blobs/sha256/a3/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    /registry/docker/registry/v2/blobs/sha256/a3/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4/data
    /registry/docker/registry/v2/blobs/sha256/f7
    /registry/docker/registry/v2/blobs/sha256/f7/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845
    /registry/docker/registry/v2/blobs/sha256/f7/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845/data
    /registry/docker/registry/v2/repositories 3
    /registry/docker/registry/v2/repositories/p1
    /registry/docker/registry/v2/repositories/p1/pause 4
    /registry/docker/registry/v2/repositories/p1/pause/_manifests
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures 5
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810
    /registry/docker/registry/v2/repositories/p1/pause/_manifests/revisions/sha256/e9a2ac6418981897b399d3709f1b4a6d2723cd38a4909215ce2752a5c068b1cf/signatures/sha256/ede17b139a271d6b1331ca3d83c648c24f92cece5f89d95ac6c34ce751111810/link 6
    /registry/docker/registry/v2/repositories/p1/pause/_uploads 7
    /registry/docker/registry/v2/repositories/p1/pause/_layers 8
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4/link 9
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845
    /registry/docker/registry/v2/repositories/p1/pause/_layers/sha256/f72a00a23f01987b42cb26f259582bb33502bdb0fcf5011e03c60577c4284845/link
    1
    このディレクトリーには、すべてのレイヤーと署名が Blob として格納されます。
    2
    このファイルには、Blob の内容が含まれます。
    3
    このディレクトリーには、すべてのイメージリポジトリーが格納されます。
    4
    このディレクトリーは単一イメージリポジトリーの p1/pause 用です。
    5
    このディレクトリーには、特定のイメージマニフェストリビジョンの署名が含まれます。
    6
    このファイルには、Blob (署名データを含む) への参照が含まれます。
    7
    このディレクトリーには、指定されたリポジトリーに対して現在アップロードされステージングされているすべてのレイヤーが含まれます。
    8
    このディレクトリーには、このリポジトリーが参照するすべてのレイヤーへのリンクが含まれます。
    9
    このファイルには、イメージを介してこのリポジトリーにリンクされている特定のレイヤーへの参照が含まれます。

3.3.3. レジストリーへの直接アクセス

さらに高度な使用方法として、レジストリーに直接アクセスし、docker コマンドを起動することが可能です。これにより、docker pushdocker pull などの操作で直接イメージをプッシュするか、または統合レジストリーからイメージをプルすることができます。これを実行するには、docker login コマンドを使ってレジストリーにログインしている必要があります。実行できる操作は、以下のセクションで説明されているようにユーザーが持つ権限によって異なります。

3.3.3.1. ユーザーの前提条件

レジストリーに直接アクセスするには、使用するユーザーが、使用目的に応じて以下の前提条件を満たしている必要があります。

  • 直接アクセスするには、ユーザーは選択するアイデンティティープロバイダー通常ユーザーである必要があります。通常ユーザーは、レジストリーへのログインに必要なアクセストークンを生成できます。system:admin などのシステムユーザーはアクセストークンを取得できないため、レジストリーに直接アクセスすることはできません。

    たとえば HTPASSWD 認証を使用している場合は、以下のコマンドを使用してこれを作成することができます。

    # htpasswd /etc/origin/openshift-htpasswd <user_name>
  • docker pull コマンドを使用する場合などにイメージをプルするには、ユーザーに registry-viewer ロールがなければなりません。このロールを追加するには、以下を実行します。

    $ oc policy add-role-to-user registry-viewer <user_name>
  • イメージの書き出しやプッシュを実行するには (docker push コマンドを使用する場合など)、ユーザーに registry-editor ロールが必要です。このロールを追加するには、以下を実行します。

    $ oc policy add-role-to-user registry-editor <user_name>

ユーザーパーミッションに関する詳細は、「ロールバインディングの管理」を参照してください。

3.3.3.2. レジストリーへのログイン

注記

ユーザーが、レジストリーに直接アクセスできるための前提条件を満たしていることを確認してください。

レジストリーに直接ログインするには、以下を実行します。

  1. OpenShift Container Platform に通常ユーザーとしてログインしていることを確認します。

    $ oc login
  2. アクセストークンを使用して Docker レジストリーにログインします。

    docker login -u openshift -p $(oc whoami -t) <registry_ip>:<port>
注記

ユーザー名の任意の値を渡すことができ、トークンには必要な情報がすべて含まれます。コロンを含むユーザー名を渡すとログインに失敗します。

3.3.3.3. イメージのプッシュとプル

レジストリーにログインすると、レジストリーに docker pull および docker push 操作を実行できます。

重要

任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。

以下の例では、以下を使用します。

コンポーネント

<registry_ip>

172.30.124.220

<port>

5000

<project>

openshift

<image>

busybox

<tag>

省略 (デフォルトは latest)

  1. 任意のイメージをプルします。

    $ docker pull docker.io/busybox
  2. 新規イメージに <registry_ip>:<port>/<project>/<image> 形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするには OpenShift Container Platform のプル仕様必ず表示されている必要があります。

    $ dockerタグdocker.io/busybox 172.30.124.220:5000/openshift/busybox
    注記

    通常ユーザーには、指定されたプロジェクトの system:image-builder ロールが必要です。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。このロールが設定されていない場合には以下の手順の docker push が失敗します。新規プロジェクトを作成して busybox イメージをプッシュしてみることができます。

  3. 新しくタグ付けされたイメージをレジストリーにプッシュします。

    $ docker push 172.30.124.220:5000/openshift/busybox
    ...
    cf2616975b4a: Image successfully pushed
    Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55

3.3.4. レジストリーメトリクスへのアクセス

OpenShift Container レジストリーは、Prometheus メトリクス のエンドポイントを提供します。Prometheus はスタンドアロンのオープンソースシステムのモニタリングおよびアラートツールキットです。

メトリクスはレジストリーのエンドポイントの /extensions/v2/metrics パスに公開されます。ただし、このルートは最初に有効にされている必要があります。有効化の方法については、「レジストリー設定の拡張」を参照してください。

以下は、メトリクスクエリーの簡単な例です。

$ curl -s -u <user>:<secret> \ 1
    http://172.30.30.30:5000/extensions/v2/metrics | grep openshift | head -n 10

# HELP openshift_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which OpenShift was built.
# TYPE openshift_build_info gauge
openshift_build_info{gitCommit="67275e1",gitVersion="v3.6.0-alpha.1+67275e1-803",major="3",minor="6+"} 1
# HELP openshift_registry_request_duration_seconds Request latency summary in microseconds for each operation
# TYPE openshift_registry_request_duration_seconds summary
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.5"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.9"} 0
openshift_registry_request_duration_seconds{name="test/origin-pod",operation="blobstore.create",quantile="0.99"} 0
openshift_registry_request_duration_seconds_sum{name="test/origin-pod",operation="blobstore.create"} 0
openshift_registry_request_duration_seconds_count{name="test/origin-pod",operation="blobstore.create"} 5
1
<user> は任意ですが、<secret>レジストリー設定で指定された値と一致していなければなりません。

高度なクエリーと推奨されるビジュアライザーについては、アップストリームの Prometheus ドキュメントを参照してください。

3.4. レジストリーのセキュリティー保護および公開

3.4.1. 概要

デフォルトでは、OpenShift Container Platform レジストリーは、TLS 経由でトラフィックを提供できるようクラスターのインストール時にセキュリティー保護されます。サービスを外部に公開するために、パススルールートもデフォルトで作成されます。

何らかの理由でレジストリーが保護されていないか、または公開されていない場合は、これらを手動で実行する方法について以下のセクションを参照してください。

3.4.2. レジストリーを手動でセキュリティー保護する

レジストリーを手動でセキュリティー保護して TLS 経由でトラフィックを処理するには、以下を実行します。

  1. レジストリーをデプロイします
  2. レジストリーのサービス IP とポートを取得します。

    $ 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/TCP
  3. 既存のサーバー証明書を使用するか、またはキーと、指定された CA で署名された指定 IP およびホスト名に有効なサーバー証明書を作成します。レジストリーのサービス IP と docker-registry.default.svc.cluster.local ホスト名のサーバー証明書を作成するには、Ansible ホストインベントリーファイル (デフォルトでは /etc/ansible/hosts) に一覧表示されている最初のマスターから以下のコマンドを実行します。

    $ oc adm ca create-server-cert \
        --signer-cert=/etc/origin/master/ca.crt \
        --signer-key=/etc/origin/master/ca.key \
        --signer-serial=/etc/origin/master/ca.serial.txt \
        --hostnames='docker-registry.default.svc.cluster.local,docker-registry.default.svc,172.30.124.220' \
        --cert=/etc/secrets/registry.crt \
        --key=/etc/secrets/registry.key

    ルーターを外部に公開する場合、公開ルートのホスト名を --hostnames フラグに追加します。

    --hostnames='mydocker-registry.example.com,docker-registry.default.svc.cluster.local,172.30.124.220 \

    ルートを外部にアクセス可能にするためにデフォルトの証明書を更新する際のその他詳細については、「レジストリーとルーター証明書の再デプロイ」を参照してください。

    注記

    oc adm ca create-server-cert コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。

  4. レジストリー証明書のシークレットを作成します。

    $ oc create secret generic registry-certificates \
        --from-file=/etc/secrets/registry.crt \
        --from-file=/etc/secrets/registry.key
  5. シークレットをレジストリー Pod のサービスアカウント (デフォルトのサービスアカウントなど) に追加します。

    $ oc secrets link registry registry-certificates
    $ oc secrets link default  registry-certificates
    注記

    シークレットをそれを参照しているサービスアカウントのみに制限することは、デフォルトで無効にされています。つまり、マスターの設定ファイルで serviceAccountConfig.limitSecretReferencesfalse (デフォルトの設定) に設定されている場合、シークレットをサービスにリンクさせる必要はありません。

  6. docker-registry サービスを一時停止します。

    $ oc rollout pause dc / docker-registry
  7. シークレットボリュームをレジストリーのデプロイメント設定に追加します。

    $ oc volume dc/docker-registry --add --type=secret \
        --secret-name=registry-certificates -m /etc/secrets
  8. 以下の環境変数をレジストリーのデプロイメント設定に追加して TLS を有効にします。

    $ oc set env dc/docker-registry \
        REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt \
        REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key

    詳細は、「Docker ドキュメントのレジストリーの設定」セクションを参照してください。

  9. レジストリーの liveness probe に使用されているスキームを HTTP から HTTPS に更新します。

    $ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{
        "name":"registry",
        "livenessProbe":  {"httpGet": {"scheme":"HTTPS"}}
      }]}}}}'
  10. レジストリーを OpenShift Container Platform 3.2 以降に初めてデプロイした場合は、レジストリーの readiness probe として使用されているスキームを HTTP から HTTPS に更新します。

    $ oc patch dc/docker-registry -p '{"spec": {"template": {"spec": {"containers":[{
        "name":"registry",
        "readinessProbe":  {"httpGet": {"scheme":"HTTPS"}}
      }]}}}}'
  11. docker-registry サービスを再開します。

    $ oc rollout dc / docker-registryを再開する
  12. レジストリーが TLS モードで実行されていることを検証します。最後の docker-registry のデプロイメントが完了するまで待機し、Docker ログでレジストリーコンテナーを確認します。listening on :5000, 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-dc48e4935fc2
  13. CA 証明書を Docker 証明書ディレクトリーにコピーします。これはクラスター内のすべてのノードで実行する必要があります。

    $ dcertsdir=/etc/docker/certs.d
    $ destdir_addr=$dcertsdir/172.30.124.220:5000
    $ destdir_name=$dcertsdir/docker-registry.default.svc.cluster.local:5000
    
    $ sudo mkdir -p $destdir_addr $destdir_name
    $ sudo cp ca.crt $destdir_addr    1
    $ sudo cp ca.crt $destdir_name
    1
    ca.crt ファイルは、マスター上の /etc/origin/master/ca.crt のコピーです。
  14. 認証を使用している場合、docker のバージョンによっては、OS レベルで証明書を信頼するようにクラスターを設定することも必要になります。

    1. 証明書をコピーします。

      $ cp /etc/origin/master/ca.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
    2. 以下を実行します。

      $ update-ca-trust enable
  15. /etc/sysconfig/docker ファイルのこの特定のレジストリーに対してのみ、--insecure-registry オプションを削除します。次にデーモンを再度読み込み、 docker サービスを再起動して設定の変更を反映させます。

    $ sudo systemctl daemon-reload
    $ sudo systemctl restart docker
  16. docker クライアント接続を検証します。レジストリーに対する docker push、またはレジストリーからの docker pull が正常に実行されるはずです。必ずこのレジストリーにログインしていることを確認してください。

    $ docker tag|push <registry/image> <internal_registry/project/image>

    例を以下に示します。

    $ docker pull busybox
    $ docker tag docker.io/busybox 172.30.124.220:5000/openshift/busybox
    $ docker push 172.30.124.220:5000/openshift/busybox
    ...
    cf2616975b4a: Image successfully pushed
    Digest: sha256:3662dd821983bc4326bee12caec61367e7fb6f6a3ee547cbaff98f77403cab55

3.4.3. セキュアなレジストリーの手動による公開

OpenShift Container Platform レジストリーに OpenShift Container Platform クラスター内からログインする代わりに、最初にレジストリーのセキュリティーを保護し、それをルートで公開しておくことによって、これに外部からアクセスすることも可能です。この方法を使うと、ルートアドレスを使ってクラスターの外部からレジストリーにログインし、ルートのホストを使ってイメージにタグ付けしたり、イメージをプッシュしたりできます。

  1. 以下の前提条件に関するそれぞれの手順は、標準的なクラスターのインストール時にデフォルトで実行されます。これが実行されていない場合は、手動で実行してください。

  2. パススルールートは、クラスターの初回インストール時にこのレジストリーについてデフォルトで作成されている必要があります。

    1. ルートが存在するかどうかを確認します。

      $ oc get route/docker-registry -o yaml
      apiVersion: v1
      kind: Route
      metadata:
        name: docker-registry
      spec:
        host: <host> 1
        to:
          kind: Service
          name: docker-registry 2
        tls:
          termination: passthrough 3
      1
      ルートのホスト。この名前は、外部から DNS 経由でルーターの IP アドレスに解決できる必要があります。
      2
      レジストリーのサービス名。
      3
      このルートをパススルールートとして指定します。
      注記

      Re-encrypt ルートはセキュアなレジストリーを公開するためにもサポートされています。

    2. ルートが存在していない場合、oc create route passthrough コマンドで、レジストリーをルートのサービスとして指定してルートを作成します。デフォルトでは、作成したルートの名前はサービス名と同じです。

      1. docker-registry サービスの詳細を取得します。

        $ 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             4h
      2. ルートを作成します。

        $ oc create route passthrough    \
            --service=docker-registry    \1
            --hostname=<host>
        route "docker-registry" created     2
        1
        レジストリーをルートのサービスとして指定します。
        2
        ルート名はサービス名と同じです。
  3. 次に、ホストシステム上のレジストリーに使用されている証明書を信頼し、ホストによるイメージのプッシュおよびプルを許可する必要があります。参照される証明書は、レジストリーのセキュリティー保護を実行したときに作成されたものです。

    $ sudo mkdir -p /etc/docker/certs.d/<host>
    $ sudo cp <ca_certificate_file> /etc/docker/certs.d/<host>
    $ sudo systemctl restart docker
  4. レジストリーのセキュリティー保護の実行時に得られた情報を使ってレジストリーにログインします。ただし、ここではサービス IP ではなくルートで使用されているホスト名を指定します。セキュリティーが保護され、公開されているレジストリーにログインする際は、必ず docker login コマンドのレジストリーを指定してください。

    # docker login -e user@company.com \
        -u f83j5h6 \
        -p Ju1PeM47R0B92Lk3AZp-bWJSck2F7aGCiZ66aFGZrs2 \
        <host>
  5. これでルートのホストを使ってイメージのタグ付けとプッシュを実行できます。たとえば、test という名前のプロジェクトにある busybox イメージをタグ付けし、プッシュするには、以下を実行します。

    $ oc get imagestreams -n test
    NAME      DOCKER REPO   TAGS      UPDATED
    
    $ docker pull busybox
    $ docker tag busybox <host>/test/busybox
    $ docker push <host>/test/busybox
    The push refers to a repository [<host>/test/busybox] (len: 1)
    8c2e06607696: Image already exists
    6ce2e90b0bc7: Image successfully pushed
    cf2616975b4a: Image successfully pushed
    Digest: sha256:6c7e676d76921031532d7d9c0394d0da7c2906f4cb4c049904c4031147d8ca31
    
    $ docker pull <host>/test/busybox
    latest: Pulling from <host>/test/busybox
    cf2616975b4a: Already exists
    6ce2e90b0bc7: Already exists
    8c2e06607696: Already exists
    Digest: sha256:6c7e676d76921031532d7d9c0394d0da7c2906f4cb4c049904c4031147d8ca31
    Status: Image is up to date for <host>/test/busybox:latest
    
    $ oc get imagestreams -n test
    NAME      DOCKER REPO                       TAGS      UPDATED
    busybox   172.30.11.215:5000/test/busybox   latest    2 seconds ago
    注記

    イメージストリームにはルート名とポートではなく、レジストリーサービスの IP アドレスとポートが設定されます。詳細は oc get imagestreams を参照してください。

3.4.4. 非セキュアなレジストリーを手動で公開する

レジストリーのセキュリティーを確保してレジストリーを公開する代わりに、OpenShift Container Platform の非稼働環境に、セキュアでないレジストリーを簡単に公開できます。これにより、SSL 証明書を使用せずにレジストリーへの外部ルートを作成することができます。

警告

非実稼働環境以外では、非セキュアなレジストリーを外部アクセスに公開すべきではありません。

非セキュアなレジストリーを公開するには、以下を実行します。

  1. レジストリーを公開します。

    # oc expose service docker-registry --hostname=<hostname> -n default

    以下の JSON ファイルが作成されます。

    apiVersion: v1
    kind: Route
    metadata:
      creationTimestamp: null
      labels:
        docker-registry: default
      name: docker-registry
    spec:
      host: registry.example.com
      port:
        targetPort: "5000"
      to:
        kind: Service
        name: docker-registry
    status: {}
  2. ルートが正常に作成されたことを確認します。

    # oc get route
    NAME              HOST/PORT                    PATH      SERVICE           LABELS                    INSECURE POLICY   TLS TERMINATION
    docker-registry   registry.example.com            docker-registry   docker-registry=default
  3. レジストリーの健全性を確認します。

    $ curl -v http://registry.example.com/healthz

    HTTP 200 / OK メッセージが表示されるはずです。

    レジストリーを公開したら、ポート番号を OPTIONS エントリーに追加して /etc/sysconfig/docker ファイルを更新します。以下は例になります。

    OPTIONS='--selinux-enabled --insecure-registry=172.30.0.0/16 --insecure-registry registry.example.com:80'
    重要

    上記のオプションは、ログインしようとしているクライアントに追加してください。

    また、Docker がクライアント上で実行されていることも確認してください。

公開されている非セキュアなレジストリーにログインする際に、docker login コマンドでレジストリーを指定していることを確認します。以下は例になります。

# 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 サービスに保存されているアドレスに置き換えるように調整します。
  1. サービスの clusterIP を書き留めておきます。

    $ oc get svc/docker-registry -o yaml | grep clusterIP:
  2. サービスを削除します。

    $ oc delete svc / docker-registry dc / docker-registry
  3. レジストリーの定義を registry.yaml に作成し、<options> を、たとえば「非実稼働環境での使用」のセクションの手順 3 で使用されているものなどに置き換えます。

    $ oc adm registry <options> -o yaml > registry.yaml
  4. registry.yaml を編集し、そこで Service を検索して、clusterIP を手順 1 で書き留めたアドレスに変更します。
  5. 変更した registry.yaml を使ってレジストリーを作成します。

    $ oc create -f registry.yaml
マスターの再起動

IP アドレスを再利用できない場合、古い IP アドレスを含むプル仕様を使った操作は失敗します。クラスターの中断を最小限に抑えるには、マスターを再起動する必要があります。

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

これで、古い IP アドレスを含む古いレジストリー URL がキャッシュからクリアされます。

注記

クラスター全体を再起動すると、Pod に不要なダウンタイムが発生し、実質、キャッシュのクリアが行われないので、これは推奨していません。

3.5.2. Docker レジストリーのホワイトリスト化

Docker レジストリーのホワイトリストを指定すると、OpenShift Container Platform ユーザーがダウンロードして入手できるイメージやテンプレートのセットをキュレートできます。このキュレートされたセットは、1 つまたは複数の Docker レジストリーに保管され、その後ホワイトリストに追加されます。ホワイトリストを使用する場合、OpenShift Container Platform からアクセスできるのは指定されたレジストリーのみで、その他すべてのレジストリーはデフォルトでアクセスが拒否されます。

ホワイトリストを設定するには、以下を実行します。

  1. /etc/sysconfig/docker ファイルを編集し、すべてのレジストリーをブロックします。

    BLOCK_REGISTRY = ' - ブロックレジストリ=すべて'

    BLOCK_REGISTRY 行のコメント解除が必要となる場合があります。

  2. 同じファイルで、アクセスを許可するレジストリーを追加します。

    ADD_REGISTRY='--add-registry=<registry1> --add-registry=<registry2>'

    レジストリーへのアクセスの許可

    ADD_REGISTRY = ' -  add-registry = registry.access.redhat.com'

    上記の例では、Red Hat カスタマーポータルで入手できるイメージへのアクセスを制限しています。

ホワイトリストが設定されると、ホワイトリストにない Docker レジストリーからプルしようとすると、許可されていないレジストリーであることを示すエラーメッセージが表示されます。

3.5.3. レジストリーのホスト名の設定

内部参照と外部参照の両方でレジストリが認識されるホスト名とポートを構成できます。これにより、イメージストリームは画像のホスト名ベースのプッシュ/プル仕様を提供し、イメージのコンシューマはレジストリサービスのIPからの変更から隔離され、イメージストリームとその参照がクラスタ間で移植可能になる可能性があります。

クラスター内でレジストリーを参照するために使用されるホスト名を設定するには、マスター設定ファイルの imagePolicyConfig セクションで internalRegistryHostname を設定します。外部のホスト名は、同じ場所で externalRegistryHostname の値を設定することで管理されます。

イメージポリシーの設定

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 を使って更新された設定をデプロイするには、以下を実行します。

  1. レジストリーをデプロイします
  2. 必要に応じて、レジストリー設定ファイルをローカルで編集します。以下は、レジストリーにデプロイされている初期 YAML ファイルです。サポートされているオプションを確認してください。

    レジストリー設定ファイル

    version: 0.1
    log:
      level: debug
    http:
      addr: :5000
    storage:
      cache:
        blobdescriptor: inmemory
      filesystem:
        rootdirectory: /registry
      delete:
        enabled: true
    auth:
      openshift:
        realm: openshift
    middleware:
      registry:
        - name: openshift
      repository:
        - name: openshift
          options:
            acceptschema2: true
            pullthrough: true
            enforcequota: false
            projectcachettl: 1m
            blobrepositorycachettl: 10m
      storage:
        - name: openshift
    openshift:
      version: 1.0
      metrics:
        enabled: false
        secret: <secret>

  3. 各ファイルの内容を保持する ConfigMap をこのディレクトリーに作成します。

    $ oc create configmap registry-config \
        --from-file=</path/to/custom/registry/config.yml>/
  4. registry-config ConfigMap をボリュームとしてレジストリーのデプロイメント設定に追加し、カスタム設定ファイルを /etc/docker/registry/ にマウントします。

    $ oc volume dc/docker-registry --add --type=configmap \
        --configmap-name=registry-config -m /etc/docker/registry/
  5. 以下の環境変数をレジストリーのデプロイメント設定に追加して、直前の手順の設定パスを参照するようにレジストリーを更新します。

    $ oc set env dc/docker-registry \
        REGISTRY_CONFIGURATION_PATH=/etc/docker/registry/config.yml

上記の手順は、必要な設定を行えるように繰り返し実行される場合があります。たとえば、トラブルシューティング時に、デバッグ モードに切り換えるよう設定が一時的に更新される場合があります。

既存の設定を更新するには、以下を実行します。

警告

この手順を実行すると、現在デプロイされているレジストリー設定が上書きされます。

  1. ローカルのレジストリー設定ファイル config.yml を編集します。
  2. registry-config configmap を削除します。

    $ oc delete configmap registry-config
  3. 更新された設定ファイルを参照するよう configmap を再作成します。

    $ oc create configmap registry-config\
        --from-file=</path/to/custom/registry/config.yml>/
  4. 更新された設定を読み取るためにレジストリーを再デプロイします。

    $ oc rollout latest docker-registry
ヒント

設定ファイルをソース管理リポジトリーに保持します。

3.5.5. レジストリー設定の参照

アップストリームの docker ディストリビューションライブラリーでは、多数の設定オプションを利用できます。ただし、すべての設定オプションがサポートされているか、または有効にされているわけではありません。このセクションは、レジストリー設定を上書きする際の参考としてご利用ください。

注記

このファイルのアップストリームの設定オプションも環境変数を使って上書きできます。ただし、ミドルウェアのセクションは、環境変数を使って上書きすることはできません特定の設定オプションを上書きする方法についてこちらを参照してください。

3.5.5.1. ログ

アップストリームのオプションはサポートされています。

例:

log:
  level: debug
  formatter: text
  fields:
    service: registry
    environment: staging

3.5.5.2. フック

メールフックはサポートされていません。

3.5.5.3. ストレージ

以下のセクションでは、サポートされているレジストリーのストレージドライバーの一覧を示しています。詳細は、Docker レジストリーのドキュメントを参照してください。

次の一覧には、レジストリの構成ファイルで構成する必要があるストレージドライバが含まれています。

レジストリーの一般的なストレージ設定オプションはサポートされています。詳細は、Docker レジストリーのドキュメントを参照してください。

以下のストレージオプションは、ファイルシステムドライバーで設定する必要があります。

注記

サポートされている永続ストレージドライバーの詳細は、「永続ストレージの設定」および「永続ストレージの例」を参照してください。

一般的なストレージ構成オプション

storage:
  delete:
    enabled: true 1
  redirect:
    disable: false
  cache:
    blobdescriptor: inmemory
  maintenance:
    uploadpurging:
      enabled: true
      age: 168h
      interval: 24h
      dryrun: false
    readonly:
      enabled: false

1
このエントリーは、イメージのプルーニングが正常に機能するために必須です。

3.5.5.4. 認証

認証オプションは変更することができません。openshift の拡張がサポートされている唯一のオプションです。

auth:
  openshift:
    realm: openshift

3.5.5.5. ミドルウェア

リポジトリーのミドルウェアの拡張を使用して、OpenShift Container Platform やイメージプロキシーとの対話を行う OpenShift Container Platform ミドルウェアの設定を行うことができます。

middleware:
  registry:
    - name: openshift 1
  repository:
    - name: openshift 2
      options:
        acceptschema2: true 3
        pullthrough: true 4
        mirrorpullthrough: true 5
        enforcequota: false 6
        projectcachettl: 1m 7
        blobrepositorycachettl: 10m 8
  storage:
    - name: openshift 9
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 ストレージドライバーの最小限の設定例です。

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache:
    blobdescriptor: inmemory
  delete:
    enabled: true
  s3: 1
    accesskey: BJKMSZBRESWJQXRWMAEQ
    secretkey: 5ah5I91SNXbeoUXXDasFtadRqOdy62JzlnOW1goS
    region: us-east-1
    bucket: docker.myregistry.com
auth:
  openshift:
    realm: openshift
middleware:
  registry:
    - name: openshift
  repository:
    - name: openshift
  storage:
    - name: cloudfront 2
      options:
        baseurl: https://jrpbyn0k5k88bi.cloudfront.net/ 3
        privatekey: /etc/docker/cloudfront-ABCEDFGHIJKLMNOPQRST.pem 4
        keypairid: ABCEDFGHIJKLMNOPQRST 5
    - name: openshift
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 セクションは、環境変数を使って上書きできません。ただし例外がいくつかあります。以下は例になります。

middleware:
  repository:
    - name: openshift
      options:
        acceptschema2: true 1
        pullthrough: true 2
        mirrorpullthrough: true 3
        enforcequota: false 4
        projectcachettl: 1m 5
        blobrepositorycachettl: 10m 6
1
ブール環境変数 REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ACCEPTSCHEMA2 で上書きできる設定オプション。manifest schema v2 をマニフェストの Put 要求で 受け入れる機能を有効にします。認識される値は truefalse (以下の他のすべてのブール変数に適用されます) になります。
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 である場合、レジストリーは、プロジェクト yourprojectyourimage: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/{}
注記

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 は、schema1schema2 の両方をサポートしています。デフォルトでは、新しい方のスキーマをサポートする場合はこちらをレジストリーにプッシュします。

イメージを schema1 で格納するレジストリーは、常にイメージを変更せずにクライアントに返します。Schema2 は新規の Docker クライアントにのみ変更しない状態で移動します。古いクライアントの場合は、オンザフライで schema1 に変換されます。

これにより、大きな影響が想定されます。たとえば、新規 Docker クライアントでレジストリーにプッシュされたイメージは、古い Docker のダイジェストでプルすることはできません。格納されたイメージのマニフェストは schema2 であり、そのダイジェストはこのバージョンのマニフェストをプルする場合にのみ使用できるためです。

このため、レジストリーはデフォルトでは schema2 を格納しないように設定されています。これにより、すべての Docker クライアントはクライアントのバージョンに関係なく、プッシュされたイメージをレジストリーからプルできます。

すべてのレジストリークライアントが schema2 をサポートしていることを確認できたら、そのサポートをレジストリーで有効にすることができます。特定のオプションについては、上記の「ミドルウェア設定の参照」を参照してください。

3.5.5.6. OpenShift

このセクションでは、OpenShift Container Platform に特有の機能のグローバル設定について説明します。今後のリリースでは、 Middleware セクションにある openshift 関連の設定は廃止される予定です。

現在、このセクションではレジストリーメトリクスの収集を設定できます。

openshift:
  version: 1.0 1
  server:
    addr: docker-registry.default.svc 2
  metrics:
    enabled: false 3
    secret: <secret> 4
  requests:
    read:
      maxrunning: 10 5
      maxinqueue: 10 6
      maxwaitinqueue 2m 7
    write:
      maxrunning: 10 8
      maxinqueue: 10 9
      maxwaitinqueue 2m 10
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

3.5.5.9. 通知

アップストリームのオプションはサポートされています。REST API リファレンス はより包括的な統合オプションを提供します。

例:

notifications:
  endpoints:
    - name: registry
      disabled: false
      url: https://url:port/path
      headers:
        Accept:
          - text/plain
      timeout: 500
      threshold: 5
      backoff: 1000

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 種類あります。

  1. Blob のメタデータのキャッシュに使用されるストレージキャッシュ。このキャッシュには有効期限がなく、データは明示的に削除されるまで残り続けます。
  2. アプリケーションキャッシュには、Blob とリポジトリーの関連付けが含まれます。このキャッシュ内のデータには有効期限があります。

キャッシュを完全にオフににするには設定を変更する必要があります。

version: 0.1
log:
  level: debug
http:
  addr: :5000
storage:
  cache: {} 1
openshift:
  version: 1.0
  cache:
    disabled: true 2
    blobrepositoryttl: 10m
1
ストレージのバックエンドでアクセスしたメタデータのキャッシュを無効にします。このキャッシュがない場合、レジストリーサーバーはメタデータのバックエンドに絶えずアクセスします。
2
Blob とリポジトリーの関連付けを含むキャッシュを無効にします。このキャッシュがない場合、レジストリーサーバーは継続的にマスター API のデータを照会し、関連付けを再計算します。

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 クライアント側のキャッシング、ネットワーク待機時間およびレイヤーサイズなどはすべて、デフォルトのラウンドロビンロードバランシング設定を使用してイメージをプッシュする際に発生するエラーの要因になる可能性があります。

このような障害の可能性を最小限に抑えるには、以下の手順を実行します。

  1. docker-registry サービスの sessionAffinityClientIP に設定されていることを確認します。

    $ oc get svc / docker-registry --template = '{{。spec.sessionAffinity}}'

    これにより ClientIP が返されるはずです。ClientIP は OpenShift Container Platform の最近のバージョンのデフォルトです。これが返されない場合は、以下のように変更してください。

    $ oc patch svc / docker-registry -p '{' spec ':{' sessionAffinity ':' ClientIP '}}'
  2. 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

その後、次のようなイメージ参照を使用して引き出します。

internal.registry.url:5000 / anyproject / pullimagestream:latest

Dockerを手動でプルするときにも同様のエラーが発生します。

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

これをデバッグするには、レジストリーのログを表示する必要があります。ログで、プッシュの失敗時に発生した同様のエラーメッセージを探します。

time="2016-03-30T15:01:21.22287816-04:00" level=error msg="unknown error completing upload: driver.Error{DriverName:\"s3\", Enclosed:(*url.Error)(0xc20901cea0)}" http.request.method=PUT
...
time="2016-03-30T15:01:21.493067808-04:00" level=error msg="response completed with error" err.code=UNKNOWN err.detail="s3: Put https://s3.amazonaws.com/oso-tsi-docker/registry/docker/registry/v2/blobs/sha256/ab/abe5af443833d60cf672e2ac57589410dddec060ed725d3e676f1865af63d2e2/data: EOF" err.message="unknown error" http.request.method=PUT
...
time="2016-04-02T07:01:46.056520049-04:00" level=error msg="error putting into main store: s3: The request signature we calculated does not match the signature you provided. Check your key and signing method." http.request.method=PUT
atest

このようなエラーを確認した場合には、Amazon S3 サポートにお問い合わせください。リージョンや特定のバケットで問題がある可能性があります。

3.6.5. イメージのプルーニングの失敗

イメージのプルーニング時に以下のエラーが発生した場合:

BLOB sha256:49638d540b2b62f3b01c388e9d8134c55493b1fa659ed84e97cb59b87a6b8e6c error deleting blob

さらに、レジストリーのログに以下の情報が含まれている場合。

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

サービスアカウントを準備したら、デフォルト 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 アドレスがルーターを実行し、ルーターがどのトラフィックを処理するかについて調整しやすくなります。ノードセレクターを使用してルーターを特定のノードにデプロイします。

重要

ルーターはデフォルトでホストネットワークを使用し、ホストのすべてのインターフェースのポート 80 と 443 に直接割り当てられます。ポート 80/443 が利用できるホストにルーターを制限し、他のサービスに使用されないようにします。これはノードセレクタースケジューラー設定を使用して設定します。たとえば、これはルートなどのサービスの実行用として専用のインフラストラクチャーノードを設定することで実行できます。

重要

お使いのルーターで個別の openshift-router サービスアカウントを使用することをお勧めします。--service-account フラグを oc adm router コマンドで使用してこれを指定できます。

$ oc adm router --dry-run --service-account=router 1
1
--service-account は、openshift-routerサービスアカウントの名前です。
重要

oc adm router を使用して作成されるルーター Pod には、ルーター Pod がデプロイされるためにノードが満たさなければならないデフォルトのリソース要求が設定されます。デフォルトのリソース要求は、インフラストラクチャーコンポーネントの信頼性を向上させる取り組みとして、ルーター Pod の QoS 層をリソース要求を持たない Pod よりも高く設定するために使用されます。デフォルト値は、基本的なルーターがデプロイされるのに必要な最小限のリソースを表しており、ルーターデプロイメント設定で編集できます。また、ルーターの負荷に基づいてそれらの値を引き上げることもできます。

4.2.2. ルーターの作成

クイックインストールプロセスは、デフォルトルーターを自動的に作成します。ルーターが存在しない場合は、以下を実行してルーターを作成します。

$ oc adm router <router_name> --replicas=<number> --service-account=router

高可用性の設定が作成されない限り、--replicas は通常 1 になります。

ルーターのホスト IP アドレスを見つけるには、以下を実行します。

$ 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 -o yaml --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

通常インストール (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 region-west -o yaml --images=myrepo/somerouter:mytag \
    --service-account=router

4.2.4. ルートを特定のルーターに絞り込む

ROUTE_LABELS 環境変数を使用してルートを絞り込むことで、特定のルーターによってのみ使用されるようできます。

たとえば、複数のルーターと 100 のルートがある場合、ラベルをルートに割り当てることで、それらの一部を 1 つのルーターで処理し、残りを別のルーターで処理するようにできます。

  1. ルーターの作成後に、ROUTE_LABELS 環境変数を使用してルーターにタグ付けします。

    $ oc env dc/<router=name>  ROUTE_LABELS="key=value"
  2. ラベルを必要なルートに追加します。

    oc label route <route=name> key=value
  3. ラベルがルートに割り当てられていることを確認するには、ルートの設定をチェックします。

    $ oc describe route/<route_name>
同時接続の最大数の設定
ルーターはデフォルトで最大 20000 の接続を処理できるようになっています。この上限は必要に応じて変更できます。接続が少なすぎると、ヘルスチェックが機能せず、不必要な再起動が実行されます。システムをこの接続の最大数に対応するように設定する必要があります。'sysctl fs.nr_open''sysctl fs.file-max' に示される上限は十分に大きな値である必要があります。そうでない場合には HAproxy は起動しません。

ルーターを作成したら、--max-connections= オプションで必要な上限を設定します。

$ 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

4.2.6. TLS 暗号化スイート

ルーターの作成時に --ciphers オプションを使用して、ルーターの暗号化スイートを設定します。

$ oc adm router --ciphers=modern   ....

値は modernintermediate、または old で、デフォルトは intermediateです。または、 ":" で区切られた暗号セットを指定することもできます。暗号は以下によって表示されるセットから取られたものである必要があります。

$ openssl ciphers

また、既存のルーターには ROUTER_CIPHERS 環境変数を使用します。

4.2.7. 高可用性ルーター

IP フェイルオーバーを使用して OpenShift Container Platform クラスターで高可用性ルーターをセットアップできます。このセットアップには複数の異なるノードの複数のレプリカが含まれるため、フェイルオーバーソフトウェアは現在のレプリカが失敗したら別のレプリカに切り替えることができます。

4.2.8. ルーターサービスポートのカスタマイズ

環境変数の ROUTER_SERVICE_HTTP_PORTROUTER_SERVICE_HTTPS_PORT を設定することで、テンプレートルーターがバインドするサービスポートをカスタマイズできます。これは、テンプレートルーターを作成し、そのデプロイメント設定を編集することで実行できます。

以下の例では、0 レプリカのルーターデプロイメントを作成し、ルーターサービス HTTP と HTTPS ポートをカスタマイズし、これを適切に (1 レプリカに) スケーリングしています。

$ oc adm router --replicas=0 --ports='10080:10080,10443:10443' 1
$ 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

4.2.9. 複数ルーターの使用

管理者は同じ定義を使用して複数のルーターを作成し、同じルートのセットを提供することができます。各ルーターは複数の異なるノードに置かれ、異なる IP アドレスを持ちます。ネットワーク管理者は、各ノードに必要なトラフィックを送る必要があります。

複数のルーターをグループ化して、クラスター内や複数テナントでのルーティングの負荷を別のルーターまたはシャードに分散することができます。グループの各ルーターまたはシャードは、ルーターのセレクターに基づいてルートを許可します。管理者は ROUTE_LABELS を使用してクラスター全体でシャードを作成できます。ユーザーは NAMESPACE_LABELS を使用して namespace (プロジェクト) でシャードを作成できます。

4.2.10. デプロイメント設定へのノードセレクターの追加

特定のルーターを特定のノードにデプロイするには、2 つの手順を実行する必要があります。

  1. ラベルを必要なノードに追加します。

    $ oc label node 10.254.254.28 "router=first"
  2. ノードセレクターをルーターのデプロイメント設定に追加します。

    $ oc edit dc <deploymentConfigName>

    template.spec.nodeSelector フィールドに、ラベルに対応するキーと値を追加します。

    ...
      template:
        metadata:
          creationTimestamp: null
          labels:
            router: router1
        spec:
          nodeSelector:      1
            router: "first"
    ...
    1
    router=first ラベルに対応するキーと値はそれぞれ routerfirst になります。

4.2.11. ルーターシャードの使用

ルーターのシャード化では NAMESPACE_LABELSROUTE_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 ラベルに基づくルーターのシャード化

Router Sharding Based on Namespace Labels
  1. namespace ラベルセレクターでルーターを設定します。

    $ oc set env dc/router NAMESPACE_LABELS="router=r1"
  2. ルーターには namespace にセレクターがあるため、ルーターは一致する namespace のルートのみを処理します。このセレクターが namespace に一致させるようにするには、namespace に適宜ラベルを付けます。

    $ oc label namespace default "router=r1"
  3. ルートをデフォルトの namespace に作成すると、ルートはデフォルトのルーターで利用できるようになります。

    $ oc create -f route1.yaml
  4. 新規プロジェクト (namespace) を作成し、route2 というルートを作成します。

    $ oc new-project p1
    $ oc create -f route2.yaml

    ルートがルーターで利用できないことを確認します。

  5. namespace p1router=r1 のラベルを付けます。

    $ oc label namespace p1 "router=r1"

このラベルを追加すると、ルートはルーターで利用できるようになります。

ルーターのデプロイメント finops-router はルートセレクター NAMESPACE_LABELS="name in (finance, ops)" を使用して設定され、ルーターのデプロイメント dev-router はラベルセレクター NAMESPACE_LABELS="name=dev" を使用して設定されます。

すべてのルートが name=financename=ops、および name=dev というラベルの付けられた namespace にある場合、この設定により、2 つのルーターのデプロイメント間でルートが効果的に分散されます。

上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。

ルート選択の基準によって、ルートの分散方法が決まります。複数のルーターデプロイメントに重複するルートのサブセットを設定することも可能です。

上記の例では finops-routerdev-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

これらのラベルは、サービスレベルアグリーメント、地理的な場所、ハードウェア要件、部門などの概念を表しています。ルートは各列のラベルを最大 1 つ持つことができます。ルートによっては他のラベルを持つことことも、ラベルをまったく持たないこともあります。

名前SLAGeo (地理的な場所)HWDept (部門)その他のラベル

a

high

east

modest

finance

type=static

b

 

west

strong

 

type=dynamic

c, d, e

low

 

modest

 

type=static

g — k

medium

 

strong

dev

 

l — s

high

 

modest

ops

 

t — z

 

west

  

type=dynamic

これは oc adm routeroc set envoc scale がどのように連携してルーターシャードを作成するかを表している便利なスクリプト mkshard です。

#!/bin/bash
# Usage: mkshard ID SELECTION-EXPRESSION
id=$1
sel="$2"
router=router-shard-$id           1
oc adm router $router --replicas=0  2
dc=dc/router-shard-$id            3
oc set env   $dc ROUTE_LABELS="$sel"  4
oc scale $dc --replicas=3         5
1
作成されたルーターは router-shard-<id> という名前を持ちます。
2
ここではスケーリングを指定しません。
3
ルーターのデプロイメント設定。
4
oc set env を使用して選択式を設定します。選択式は環境変数 ROUTE_LABELS の値です。
5
拡張します。

mkshard を複数回実行して、複数のルーターを作成します。

ルーター選択式ルート

router-shard-1

sla=high

a, l — s

router-shard-2

geo=west

b, t — z

router-shard-3

dept=dev

g — k

4.2.11.2. ルーターシャードの変更

ルーターシャードはラベルに基づいた構成なので、(oc label を使用して) ラベルまたは (oc set env を使用して) 選択式のいずれかを変更できます。

このセクションでは「ルーターシャードの作成」セクションで扱った例をさらに詳細に取り上げ、選択式の変更方法を示します。

これは、新規の選択式を使用できるよう既存のルーターを変更する便利なスクリプト modshard です。

#!/bin/bash
# Usage: modshard ID SELECTION-EXPRESSION...
id=$1
shift
router=router-shard-$id       1
dc=dc/$router                 2
oc scale $dc --replicas=0     3
oc set env   $dc "$@"             4
oc scale $dc --replicas=3     5
1
変更後のルーターの名前は router-shard-<id> になります。
2
変更が発生するデプロイメント設定。
3
縮小します。
4
oc set env を使用して新しい選択式を設定します。「ルーターシャードの作成」セクションの mkshard とは異なり、modshardID 以外の引数として指定される選択式には環境変数名とその値が含まれている必要があります。
5
拡大して元に戻します。
注記

modshard では、router-shard-<id>デプロイメントストラテジーRolling の場合、oc scale コマンドは不要です。

たとえば router-shard-3 の部門を拡張して opsdev を含めるには、以下を実行します。

$ modshard 3 ROUTE_LABELS='dept in (dev, ops)'

結果として、router-shard-3 はルート g — s (g — kl — s の組み合わせ) を選択します。

この例ではシャードから除外する 1 つの部門を指定します。このシナリオ例では 3 つの部門しかないため、これによって前述の例と同じ結果が得られます。

$ modshard 3 ROUTE_LABELS='dept != finance'

この例は 3 つのカンマで区切られた属性を指定しており、結果としてルート b のみが選択されます。

$ 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'

最後の例は ROUTE_LABELSNAMESPACE_LABELS を組み合わせて、ラベルsla=low を持ち、ラベル frequency=weekly を持つ namespace のルート選択します。

$ 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"

これは、ルーターのホスト名を含む ROUTER_CANONICAL_HOSTNAME 環境変数をルーターのデプロイメント設定に作成します。

すでに存在しているルーターの場合、クラスター管理者はルーターのデプロイメント設定を編集し、ROUTER_CANONICAL_HOSTNAME 環境変数を追加します。

spec:
  template:
    spec:
      containers:
        - env:
          - name: ROUTER_CANONICAL_HOSTNAME
            value: rtr.example.com

ROUTER_CANONICAL_HOSTNAME 値は、ルートを許可したすべてのルーターのルートステータスに表示されます。ルートステータスはルーターがリロードされるたびに更新されます。

ユーザーがルートを作成すると、すべてのアクティブなルーターはそのルートを評価し、条件を満たしていればそのルートを許可します。ROUTER_CANONICAL_HOSTNAME 環境変数を定義するルーターがルートを許可すると、ルーターはルートステータスの routerCanonicalHostname フィールドに値を入力します。ユーザーはルートステータスを検証して、どのルーターがルートを許可したかを確認でき、ルーターを一覧から選択し、ネットワーク管理者に渡すルーターのホスト名を見つけることができます (該当する場合)。

status:
  ingress:
    conditions:
      lastTransitionTime: 2016-12-07T15:20:57Z
      status: "True"
      type: Admitted
      host: hello.in.mycloud.com
      routerCanonicalHostname: rtr.example.com
      routerName: myrouter
      wildcardPolicy: None

oc describe にはホスト名が含まれます (利用可能な場合)。

$ 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
注記

この変更には、マスターを実行している場合は再起動が必要となります。

OpenShift Container Platform マスターが上記の設定を実行している場合、 namespace の mynamespace に追加されるホスト名を持たない no-route-hostname というルートの例では、生成されるホスト名は以下のようになります。

no-route-hostname-mynamespace.v3.openshift.test

4.2.14. カスタムルーティングサブドメインへのルートホスト名の強制

管理者がすべてのルートを特定のルーティングサブドメインに限定する場合、--force-subdomain オプションを 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
注記

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

ここで --default-cert フラグを使用できます。

$ oc adm router --default-cert=cloudapps.router.pem --service-account=router
注記

ブラウザーは、ワイルドカードを 1 つ深いレベルのサブドメインに有効であると見なします。この例では、証明書は a.cloudapps.example.com に対して有効ですが、a.b.cloudapps.example.com には有効ではありません。

4.2.16. 証明書を手動で再デプロイする

ルーター証明書を手動で再デプロイするには、以下を実行します。

  1. デフォルトのルーター証明書を含むシークレットがルーターに追加されているかどうかを確認します。

    $ oc volumes dc/router
    
    deploymentconfigs/router
      secret/router-certs as server-certificate
        mounted at /etc/pki/tls/private

    証明書が追加されている場合は、以下の手順を省略してシークレットを上書きします。

  2. デフォルト証明書ディレクトリーが以下の変数 DEFAULT_CERTIFICATE_DIR に設定されていることを確認します。

    $ oc env dc/router --list
    
    DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private

    設定されていない場合は、以下のコマンドを使用してディレクトリーを作成します。

    $ oc env dc/router DEFAULT_CERTIFICATE_DIR=/etc/pki/tls/private
  3. 証明書を PEM 形式にエクスポートします。

    $ cat custom-router.key custom-router.crt custom-ca.crt > custom-router.crt
  4. ルーター証明書シークレットを上書きするか、またはこれを作成します。

    証明書シークレットがルーターに追加されている場合は、シークレットを上書きします。追加されていなければ、新規シークレットを作成します。

    シークレットを上書きするには、以下のコマンドを実行します。

    $ 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
    
    $ oc volume dc/router --add --mount-path=/etc/pki/tls/private --secret-name='router-certs' --name router-certs
  5. ルーターをデプロイします。

    $ oc rollout latest dc/router

4.2.17. セキュリティー保護されたルートの使用

現時点で、パスワードで保護されたキーファイルはサポートされていません。HAProxy は開始時にパスワードのプロンプトを出しますが、このプロセスを自動化する方法は提供しません。キーファイルからパスフレーズを削除するために、以下を実行できます。

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

以下の例は、トラフィックが宛先にプロキシー処理される前に TLS 終端がルーターで生じる場合にセキュアな edge termination ルートを使用する方法を示しています。セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、ルーターのフロントエンドで提供されます。

最初にルーターインスタンスを起動します。

# oc adm router --replicas=1 --service-account=router

次に、セキュアな edge ルートのプライベートキー、CSR、証明書を作成します。この手順はお使いの認証局やプロバイダーによって異なります。www.example.test というドメインの単純な自己署名証明書の場合は、以下の例を参照してください。

# sudo openssl genrsa -out example-test.key 2048
#
# sudo openssl req -new -key example-test.key -out example-test.csr  \
  -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=www.example.test"
#
# sudo openssl x509 -req -days 366 -in example-test.csr  \
      -signkey example-test.key -out 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

その定義を確認します。

$ oc get route/my-service -o yaml
apiVersion: v1
kind: Route
metadata:
  name:  my-service
spec:
  host: www.example.test
  to:
    kind: Service
    name: my-service
  tls:
    termination: edge
    key: |
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

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/

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

Web コンソールでワイルドカードルートを設定する方法についてはこちらを参照してください。

セキュアなワイルドカード edge termination ルートの使用

以下の例では、トラフィックが宛先にプロキシー処理される前にルーターで生じる TLS 終端を反映しています。サブドメイン example.org (*.example.org) のホストに送られるトラフィックは公開されるサービスにプロキシーされます。

セキュアな edge termination ルートは TLS 証明書とキー情報を指定します。TLS 証明書は、サブドメイン (*.example.org) に一致するすべてのホストのルーターのフロントエンドによって提供されます。

  1. ルーターインスタンスを起動します。

    $ oc adm router --replicas=0 --service-account=router
    $ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true
    $ oc scale dc/router --replicas=1
  2. セキュリティー保護された edge ルートについてのプライベートキー、証明書署名要求 (CSR) および証明書を作成します。

    この手順はお使いの認証局やプロバイダーによって異なります。*.example.test というドメインの単純な自己署名証明書の場合はこの例を参照してください。

    # sudo openssl genrsa -out example-test.key 2048
    #
    # sudo openssl req -new -key example-test.key -out example-test.csr  \
      -subj "/C=US/ST=CA/L=Mountain View/O=OS3/OU=Eng/CN=*.example.test"
    #
    # sudo openssl x509 -req -days 366 -in example-test.csr  \
          -signkey example-test.key -out example-test.crt
  3. 上記の証明書とキーを使用してワイルドカードのルートを生成します。

    $ cat > route.yaml  <<REOF
    apiVersion: v1
    kind: Route
    metadata:
      name:  my-service
    spec:
      host: www.example.test
      wildcardPolicy: Subdomain
      to:
        kind: Service
        name: my-service
      tls:
        termination: edge
        key: "$(perl -pe 's/\n/\\n/' example-test.key)"
        certificate: "$(perl -pe 's/\n/\\n/' example-test.cert)"
    REOF
    $ oc create -f route.yaml

    *.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/

ワイルドカードルートを許可しているルーター (ROUTER_ALLOW_WILDCARD_ROUTEStrue に設定する) の場合、ワイルドカードルートに関連付けられたサブドメインの所有権についてのいくつかの注意点があります。

ワイルドカードルートの設定前に、所有権は、最も古いルートを持つ namespace のホスト名についての要求に基づいて設定されました (これはその他の要求を行うルートよりも優先されました)。たとえば、ルート r1 がルート r2 より古い場合、one.example.test の要求を持つ namespace ns1 のルート r1 は同じホスト名 one.example.test について namespace ns2 のルート ns2 よりも優先されます。

さらに、他の namespace のルートは重複しないホスト名を要求することを許可されていました。たとえば、namespace ns1 のルート ronewww.example.test を要求でき、namespace d2 の別のルート rtwoc3po.example.test を要求できました。

これは、同じサブドメイン (上記の例では example.test) を要求するワイルドカードルートがない場合には同様になります。

ただし、ワイルドカードルートはサブドメイン内のホスト名 ( \*.example.test 形式のホスト名) をすべて要求する必要があります。ワイルドカードルートの要求は、そのサブドメイン (example.test) の最も古いルートがワイルドカードルートと同じ namespace 内にあるかどうかによって許可または拒否されます。最も古いルートは通常のルートまたはワイルドカードルートのいずれかになります。

たとえば、ホスト owner.example.test を要求する 最も古い ルートが namespace ns1 にすでに存在し、後からそのサブドメイン (example.test) のルートを要求する新規のワイルドカードルート wildthing が追加される場合、そのワイルドカードルートによる要求は、そのルートが所有ルートと同じ namespace (ns1) にある場合にのみ許可されます。

以下の例では、ワイルドカードルートの要求が成功する場合と失敗する場合のさまざまなシナリオを示しています。

以下の例では、ワイルドカードルートを許可するルーターは、ワイルドカードルートがサブドメインを要求していない限り、サブドメイン example.test のホストに対する重複しない要求を許可します。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test
$ oc expose service myservice --hostname=bname.example.test

$ oc project ns2
$ oc expose service anotherservice --hostname=second.example.test
$ oc expose service anotherservice --hostname=cname.example.test

$ oc project otherns
$ oc expose service thirdservice --hostname=emmy.example.test
$ oc expose service thirdservice --hostname=webby.example.test

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 なので、owner.example.test または aname.example.test の要求を許可しません。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test
$ oc expose service myservice --hostname=aname.example.test

$ oc project ns2
$ oc expose service secondservice --hostname=bname.example.test
$ oc expose service secondservice --hostname=cname.example.test

$ # Router will not allow this claim with a different path name `/p1` as
$ # namespace `ns1` has an older route claiming host `aname.example.test`.
$ oc expose service secondservice --hostname=aname.example.test --path="/p1"

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `owner.example.test`.
$ oc expose service secondservice --hostname=owner.example.test

$ oc project otherns

$ # Router will not allow this claim as namespace `ns1` has an older route
$ # claiming host name `aname.example.test`.
$ oc expose service thirdservice --hostname=aname.example.test

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、そのワイルドカードルートが同じ namespace に属しているので、`\*.example.test の要求を許可します。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will allow this claim.

以下の例では、ワイルドカードルートを許可するルーターは、所有している namespace が ns1 で、ワイルドカードルートが別の namespace cyclone に属するため、`\*.example.test の要求を許可しません。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ # Switch to a different namespace/project.
$ oc project cyclone

$ # Reusing the route.yaml from a prior example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  router will deny (_NOT_ allow) this claim.

同様に、ワイルドカードルートを持つ namespace がサブドメインを要求すると、その namespace 内のルートのみがその同じサブドメインでホストを要求できます。

以下の例では、ワイルドカードルートを持つ namespace ns1 のルートがサブドメイン example.test を要求すると、namespace ns1 内のルートのみがその同じサブドメインのホストを要求することを許可されます。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=owner.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service otherservice --hostname=other.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `other.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for deux.example.test
$ oc expose service mysecondservice --hostname=deux.example.test

$ # namespace `ns1` is allowed to claim for deux.example.test with path /p1
$ oc expose service mythirdservice --hostname=deux.example.test --path="/p1"

$ oc project otherns

$ # namespace `otherns` is not allowed to claim for deux.example.test
$ # with a different path '/otherpath'
$ oc expose service otherservice --hostname=deux.example.test --path="/otherpath"

$ # namespace `otherns` is not allowed to claim for owner.example.test
$ oc expose service yetanotherservice --hostname=owner.example.test

$ # namespace `otherns` is not allowed to claim for unclaimed.example.test
$ oc expose service yetanotherservice --hostname=unclaimed.example.test

以下の例では、所有権のあるルートが削除され、所有権が namespace 内または namespace 間で渡されるさまざまなシナリオが示されています。namespace ns1 のホスト eldest.example.test を要求するルートが存在する場合、その namespace 内のワイルドカードルートはサブドメイン example.test を要求できます。ホスト eldest.example.test のルートが削除されると、次に古いルート senior.example.test が最も古いルートになりますが、これは他のルートに影響を与えません。ホスト senior.example.test のルートが削除されると、次に古いルート junior.example.test が最も古いルートになり、ワイルドカードルートの要求をブロックします。

$ oc adm router ...
$ oc set env dc/router ROUTER_ALLOW_WILDCARD_ROUTES=true

$ oc project ns1
$ oc expose service myservice --hostname=eldest.example.test
$ oc expose service seniorservice --hostname=senior.example.test

$ oc project otherns

$ # namespace `otherns` is allowed to claim for other.example.test
$ oc expose service juniorservice --hostname=junior.example.test

$ oc project ns1

$ # Reusing the route.yaml from the previous example.
$ # spec:
$ #   host: www.example.test
$ #   wildcardPolicy: Subdomain

$ oc create -f route.yaml   #  Router will allow this claim.

$ #  In addition, route in namespace otherns will lose its claim to host
$ #  `junior.example.test` due to the wildcard route claiming the subdomain.

$ # namespace `ns1` is allowed to claim for dos.example.test
$ oc expose service mysecondservice --hostname=dos.example.test

$ # Delete route for host `eldest.example.test`, the next oldest route is
$ # the one claiming `senior.example.test`, so route claims are unaffacted.
$ oc delete route myservice

$ # Delete route for host `senior.example.test`, the next oldest route is
$ # the one claiming `junior.example.test` in another namespace, so claims
$ # for a wildcard route would be affected. The route for the host
$ # `dos.example.test` would be unaffected as there are no other wildcard
$ # claimants blocking it.
$ oc delete route seniorservice

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

内部的には、これは外部ネットワークがルーターと通信するために、ルーターコンテナーが 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
  • Prometheus 形式で未加工統計を抽出するには、以下を実行します。

    curl <user>:<password>@<router_IP>:<STATS_PORT>

    例を以下に示します。

    $ curl admin:sLzdR6SgDJ@10.254.254.35:1936/metrics

    メトリクスにアクセスするために必要な情報は、ルーターサービスのアノテーションで確認できます。

    $ oc edit router service <router-service-name>
    
    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        prometheus.io/port: "1936"
        prometheus.io/scrape: "true"
        prometheus.openshift.io/password: IImoDqON02
        prometheus.openshift.io/username: admin

    prometheus.io/port はデフォルトが 1936 の統計ポートです。アクセスを許可するようファイウォールを設定する必要がある場合があります。直前のユーザー名およびパスワードを使用してメトリクスにアクセスします。パスは /metrics です。

    $ curl <user>:<password>@<router_IP>:<STATS_PORT>
    for example:
    $ curl admin:sLzdR6SgDJ@10.254.254.35:1936/metrics
    ...
    # HELP haproxy_backend_connections_total Total number of connections.
    # TYPE haproxy_backend_connections_total gauge
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
    ...
    # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
    # TYPE haproxy_exporter_server_threshold gauge
    haproxy_exporter_server_threshold{type="current"} 11
    haproxy_exporter_server_threshold{type="limit"} 500
    ...
    # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_frontend_bytes_in_total gauge
    haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="public"} 119070
    ...
    # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_server_bytes_in_total gauge
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
    haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
    ...
  • ブラウザーでメトリクスを取得するには、以下を実行します。

    1. 以下の環境変数をデプロイメント設定ファイルから削除します。

      $ oc edit service router
      
      - name: ROUTER_LISTEN_ADDR
        value: 0.0.0.0:1936
      - name: ROUTER_METRICS_TYPE
        value: haproxy
    2. ブラウザーで以下の URL を使用して統計ウィンドウを起動します。ここでは、STATS_PORT 値はデフォルトで 1936 になります。

      http://admin:<Password>@<router_IP>:<STATS_PORT>

      ;csv を URL に追加して CVS 形式の統計を取得できます。

      例を以下に示します。

      http://admin:<Password>@<router_IP>:1936;csv

      ルーター IP、管理者名、およびパスワードを取得するには、以下を実行します。

      oc describe pod <router_pod>
  • メトリクスのコレクションを表示しないようにするには、以下を実行します。

    $ oc adm router --service-account=router --stats-port=0

    大規模クラスターの 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

この問題が発生すると、oc コマンドは以下のエラーを出して失敗することがあります。

Unable to connect to the server: dial tcp: lookup <hostname> on <ip>:<port>: write udp <ip>:<port>-><ip>:<port>: write: invalid argument

IPv4 の ARP エントリーの実際の量を確認するには、以下を実行します。

# ip -4 neigh show nud all | wc -l

数字が net.ipv4.neigh.default.gc_thresh3 しきい値に近づき始めたら、値を増やします。以下を実行して現在値を取得します。

# sysctl net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh1 = 128
# sysctl net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh2 = 512
# sysctl net.ipv4.neigh.default.gc_thresh3
net.ipv4.neigh.default.gc_thresh3 = 1024

以下の 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

これらの設定を永続化するには、このドキュメントを参照してください。

4.2.21. DDoS 攻撃からの保護

timeout http-request をデフォルトの HAProxy ルーターイメージに追加して、分散型の denial-of-service (DDoS) 攻撃 (slowloris など) からデプロイメントを保護します。

# and the haproxy stats socket is available at /var/run/haproxy.stats
global
  stats socket ./haproxy.stats level admin

defaults
  option http-server-close
  mode http
  timeout http-request 5s
  timeout connect 5s 1
  timeout server 10s
  timeout client 30s
1
timeout http-request は最大 5 秒に設定されます。HAProxy は HTTP 要求全体の送信のための 5 秒をクライアントに対して指定します。この指定がないと、HAProxy はエラーを出して接続を切断します。

また、環境変数 ROUTER_SLOWLORIS_TIMEOUT が設定されている場合、クライアントが HTTP 要求全体を送信するためにかかる合計時間が制限されます。これが設定されていない場合、HAProxy は接続を切断します。

環境変数を設定することで、情報をルーターのデプロイメント設定の一部として取得でき、テンプレートを手動で変更することが不要になります。一方、HAProxy 設定を手動で追加すると、ルーター Pod の再ビルドとルーターテンプレートファイルの保守が必要になります。

アノテーションを使用して、以下を制限する機能を含む基本的な DDoS 保護を HAProxy テンプレートルーターに実装します。

  • 同時 TCP 接続の数
  • クライアントが TCP 接続を要求できるレート
  • HTTP 要求を実行できるレート

アプリケーションによってはトラフィックのパターンが完全に異なる場合があるため、これらはルートごとに有効にされます。

表4.1 HAProxy テンプレートルーター設定

設定説明

haproxy.router.openshift.io/rate-limit-connections

設定した内容を有効にします (true に設定した場合など)。

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

このルートの同じ IP アドレスで接続できる同時 TCP 接続の数。

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

クライアント IP で開くことができる TCP 接続の数。

haproxy.router.openshift.io/rate-limit-connections.rate-http

クライアント 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
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

イメージ名は 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}}

表4.2 テンプレートルーター関数

関数意味

processEndpointsForAlias(alias ServiceAliasConfig, svc ServiceUnit, action string) []Endpoint

有効なエンドポイントの一覧を返します。アクションが「Shuffle」の場合、エンドポイントの順序はランダム化されます。

env(variable, default …​string) string

Pod からの名前付き環境変数の取得を試行します。これが定義されていないか、または空の場合、オプションの 2 つ目の引数が返されます。それ以外の場合には空の文字列を返します。

matchPattern(pattern, s string) bool

1 つ目の引数は正規表現を含む文字列で、2 つ目の引数はテストに使用できる変数です。1 つ目の引数として提供される正規表現が 2 つ目の引数として提供される文字列と一致するかどうかを示すブール値を返します。

isInteger(s string) bool

指定された変数が整数かどうかを判別します。

firstMatch(s string, allowedValues …​string) bool

所定の文字列を許可された文字列の一覧と比較します。左から右にスキャンし、最初の一致を返します。

matchValues(s string, allowedValues …​string) bool

所定の文字列を許可された文字列の一覧と比較します。文字列が許可される値の場合は「true」を返します。それ以外の場合は、「false」を返します。

generateRouteRegexp(hostname, path string, wildcard bool) string

ルートホスト (とパス) に一致する正規表現を生成します。最初の引数はホスト名であり、2 つ目はパス、3 つ目はワイルドカードブール値です。

genCertificateHostName(hostname string, wildcard bool) string

証明書の提供/証明書のマッチングに使用するホスト名を生成します。1 つ目の引数はホスト名で、2 つ目はワイルドカードブール値です。

isTrue(s string) bool

所定の変数に「true」が含まれるかどうかを判別します。

これらの関数は、HAProxy テンプレートルータープラグインによって提供されます。

4.3.3.3. ルーターが提供する情報

このセクションでは、ルーターがテンプレートで利用可能にする OpenShift Container Platform の情報について説明しますす。ルーター設定パラメーターは HAProxy ルータープラグインに与えられるデータセットです。フィールドには (dot) .Fieldname を使用してアクセスします。

以下のルーター設定パラメーター表は各種フィールドの定義を詳しく取り上げています。とくに .State には許可されたルートセットが設定されます。

表4.3 ルーター設定パラメーター

フィールド種別説明

WorkingDir

文字列

ファイルが書き込まれるディレクトリー。デフォルトは /var/lib/containers/router に設定されます。

State

map[string](ServiceAliasConfig)`

ルート。

ServiceUnits

map[string]ServiceUnit

サービスのルックアップ。

DefaultCertificate

文字列

pem 形式のデフォルト証明書へのフルパス名。

PeerEndpoints

`[]Endpoint

ピア。

StatsUser

文字列

統計の公開に使用するユーザー名 (テンプレートがサポートしている場合)。

StatsPassword

文字列

統計の公開に使用するパスワード (テンプレートがサポートしている場合)。

StatsPort

整数

統計の公開に使用するポート (テンプレートがサポートしている場合)。

BindPorts

bool

ルーターがデフォルトポートをバインドすべきかどうか。

表4.4 ルーター ServiceAliasConfig (Route)

<
フィールド種別説明