第2章 クラスターのインストール

OpenShift Container Platform は開発環境の単一システムでのみインストールできます。オールインワン環境は実稼働環境として見なされません。

以下の表では、単一マスター (etcd が同じホストにインストールされている) および 2 つのノードのサンプル環境について説明しています。

以下の表では、単一マスター、3 つの etcd ホスト、および 2 つのノードのサンプル環境について説明しています。

以下では、ネイティブ HA メソッドを使用する、同一の場所に配置されたクラスター化された etcd を含む 3 つのマスター、1 つの HAProxy ロードバランサー、 2 つのノードのサンプル環境を説明しています。

以下では、ネイティブ HA メソッドを使用する、3 つの マスター、1 つの HAProxy ロードバランサー、3 つの外部のクラスター化された etcd ホスト、 2 つのノードのサンプル環境を説明しています。

OpenShift Container Platform は、OpenShift Container Platform の統合レジストリーを使用するスタンドアロンレジストリーとして機能するようにインストールすることもできます。このシナリオの詳細は、「スタンドアロンレジストリーのインストール」を参照してください。

まず、お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションがなければなりません。これがない場合は、営業担当者にお問い合わせください。

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

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

システムの一時ディレクトリーは、Python の標準ライブラリーにある tempfile モジュールで定義されるルールに基づいて決定されます。

コンテナーデーモンを実行する各システムにストレージを設定する必要があります。コンテナー化インストールの場合、マスターにストレージが必要です。また、デフォルトで Web コンソールがマスターのコンテナーで実行されますが、Web コンソールを実行するためにストレージがマスター上で必要になります。コンテナーはノードで実行されるため、ストレージは常にノード上で必要になります。ストレージのサイズは、ワークロード、コンテナーの数、実行されているコンテナーのサイズ、およびコンテナーのストレージ要件によって異なります。また、コンテナー化された etcd には設定済みのコンテナーストレージが必要です。

テストまたはサンプル環境は最小要件で機能します。実稼働環境の場合、以下の推奨事項が適用されます。

最低 3 つの etcd ホストと 1 つのロードバランサーが複数のマスターホスト間で必要になります。

パフォーマンスのガイダンスについては、「Recommended Practices for OpenShift Container Platform Master Hosts」を参照してください。

詳しくは、「サイジングに関する考慮事項」と「Cluster Limits」を参照してください。

Container-Native Storage または Container-Ready Storage クラスターで使用されるノードは、ストレージノードとみなされます。ストレージノードは異なるクラスターグループに分けられますが、単一ノードは複数のグループに属することはできません。ストレージノードの各グループについては、以下が当てはまります。

デフォルトで、OpenShift Container Platform マスターおよびノードは、それらが実行されるシステムで利用可能なすべてのコアを使用します。GOMAXPROCS 環境変数を設定することにより、OpenShift Container Platform で使用するコア数を選択することができます。GOMAXPROCS 環境変数の機能方法をはじめとする詳細については、Go Language ドキュメント を参照してください。

たとえば、以下を実行してからサーバーを起動し、OpenShift Container Platform が 1 つのコアでのみ実行されるようにします。

# export GOMAXPROCS=1

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

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」セクションを参照してください。

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 権限が必要) を参照してください。

詳細は、以下の記事を参照してください。

OpenShift Container Platform では、完全に機能する DNS サーバーが環境になければなりません。この場合、DNS ソフトウェアを実行する別個のホストを使用することが適しており、これによりプラットフォームで実行されるホストおよびコンテナーに対して名前解決を実行することができます。

OpenShift Container Platform の主要コンポーネントはコンテナーの内部で実行され、名前解決に以下のプロセスを使用します。

OpenShift Container Platform 3.2 の時点で、dnsmasq はすべてのマスターおよびノードで自動的に設定されます。Pod は DNS としてノードを使用し、ノードは要求を転送します。デフォルトで、dnsmasq はポート 53 をリッスンするようにノード上に設定されます。そのため、ノードはその他の種類の DNS アプリケーションを実行することができません。

以下は 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 環境がない場合には、以下に関連する障害が発生します。

*.cloudapps.example.com. 300 IN  A 192.168.133.2

共有ネットワークは、マスターとノードホスト間に存在する必要があります。通常インストール (Advanced installation) 方式を使用して高可用性のために複数のマスターを設定する計画をしている場合、インストールのプロセスで 仮想 IP (VIP) として設定される IP を選択する必要もあります。選択した IP はすべてのノード間でルーティングできる必要があり、FQDN を使用して設定する場合は、すべてのノード上で解決する必要があります。

[OSEv3:vars]
os_firewall_use_firewalld=True

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

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

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

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

OverlayFS はユニオンファイルシステムの一種です。これにより、あるファイルシステムを別のファイルシステムに重ねる (オーバーレイする) ことができます。上位のファイルシステムで変更が記録されても、下位のファイルシステムは変更されません。

「Comparing the Overlay Versus Overlay2 Graph Drivers 」には、overlay および overlay2 ドライバーの詳細情報が記載されています。

Docker サービスの OverlayFS ストレージドライバーの有効化については、Red Hat Enterprise Linux Atomic Host ドキュメントを参照してください。

Docker に含まれる docker-storage-setup スクリプトを使用してシンプールデバイスを作成し、Docker ストレージドライバーを設定できます。これは Docker のインストール後に実行でき、イメージまたはコンテナーの作成前に実行する必要があります。このスクリプトは /etc/sysconfig/docker-storage-setup ファイルから設定オプションを読み取り、論理ボリュームを作成するための 3 つのオプションをサポートします。

オプション A は最も信頼性の高いオプションですが、この場合 Docker ストレージを設定する前にブロックデバイスをホストに追加する必要があります。オプション B と C はどちらもホストのプロビジョニング時に利用可能な空きスペースを残しておく必要があります。オプション C は、Red Hat Mobile Application Platform (RHMAP) などの一部のアプリケーションで問題が発生することが確認されています。

docker-pool を作成した後に Docker ストレージを再設定する必要がある場合は、まず docker-pool 論理ボリュームを削除する必要があります。専用のボリュームグループを使用している場合は、上記の手順に従って、docker-storage-setup を再設定する前にそのボリュームグループと関連する物理ボリュームを削除する必要もあります。

LVM 管理の詳細は、「論理ボリュームマネージャー管理」を参照してください。

OpenShift Container Platform は、イメージが信頼済みのソースのものかを暗号で確認することができます。『Container Security Guide』には、イメージ署名の仕組みの概要が記載されています。

atomic コマンドラインインターフェース (CLI) (バージョン 1.12.5 以降) を使用してイメージ署名の検証を設定できます。atomic CLI は RHEL Atomic Host システムにプリインストールされています。

ホストシステムにインストールされていない場合は、atomic パッケージをインストールします。

$ yum install atomic

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

$ atomic trust show
* (default)                         accept

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

$ 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 を使用します。

以下のファイルとディレクトリーは、ホストの信頼設定を構成しています。

信頼設定は、各ノードまたは個別のホストで管理される生成ファイル上で直接管理でき、 Ansible などを使用して適切なノードに配布できます。Ansible を使用したファイル配布の自動化の例については、『Container Image Signing Integration Guide』を参照してください。

コンテナーのログファイル (コンテナーが実行されているノード上の /var/lib/docker/containers/<hash>/<hash>-json.log ファイル) が問題を生じさせかねないサイズに拡張してしまうことがあります。これは、Docker の json-file ロギングドライバーを設定し、ログファイルのサイズと数を制限して管理できます。

たとえば、最大ファイルサイズを 1MB に設定し、最新の 3 つのログファイルを保持するには、/etc/sysconfig/docker ファイルを編集して、max-size=1M と max-file=3 を設定します。

OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=1M --log-opt max-file=3'

次に Docker サービスを再起動します。

# systemctl restart docker

コンテナーログは、コンテナーが実行されているノードの /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 ドキュメントを参照してください。

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

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

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

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

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

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

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

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 インストーラーで使用される変数について説明しています。

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

openshift_master_cluster_public_hostname=openshift-ansible.public.example.com

openshift_docker_additional_registries=example.com:443

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

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

[OSEv3:vars]
openshift_deployment_type=openshift-enterprise

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 インストーラーで使用され、個々のホストエントリーに割り当てることができる変数を示しています。

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

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

例を以下に示します。

openshift_master_api_port=3443

Web コンソールポート設定 (openshift_master_console_port) は、 API サーバーのポート (openshift_master_api_port) に一致している必要があります。

プレインストールチェックは、openshift_health_checker Ansible ロールの一部として実行される診断タスクのセットです。OpenShift Container Platform の Ansible インストールの前に実行され、必要なインベントリー値が設定されていることを確認し、正常なインストールを妨げたり干渉したりする可能性があるホストの潜在的な問題を特定します。

以下の表は、OpenShift Container Platform のすべての Ansible インストールの前に実行される、使用可能なプレインストールチェックを示しています。

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

openshift_disable_check=memory_availability,disk_availability

システムコンテナーを使用すると、docker デーモンを実行する前に実行する必要があるサービスをコンテナー化できます。システムコンテナーは、以下の機能を使用する Docker 形式のコンテナーです。

したがって、システムコンテナーは従来の docker サービスの外部で保存され、実行されます。システムコンテナーのテクノロジーについての詳細は、『Red Hat Enterprise Linux Atomic Host: Managing Containers』ドキュメントの「Running System Containers」を参照してください。

特定のコンポーネントを RPM や標準のコンテナー化方法の代わりにシステムコンテナーとして実行するように OpenShift Container Platform インストールを設定できます。現在 OpenShift Container Platform では、docker コンポーネントと etcd コンポーネントをシステムコンテナーとして実行できます。

openshift_docker_systemcontainer_image_override="<registry>/<user>/<image>:<tag>"

openshift_use_etcd_system_container=True

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

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

例を以下に示します。

oreg_url=example.com/openshift3/ose-${component}:${version}
openshift_examples_modify_imagestreams=true
openshift_docker_additional_registries=example.com: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-'

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

例を以下に示します。

openshift_hosted_registry_routehost=<path>
openshift_hosted_registry_routetermination=reencrypt
openshift_hosted_registry_routecertificates= "{'certfile': '<path>/org-cert.pem', 'keyfile': '<path>/org-privkey.pem', 'cafile': '<path>/org-chain.pem'}"

デフォルト以外の Cockpit レジストリーコンソールイメージを使用する場合や、特定のバージョンのコンソールが必要な場合は、以下のように必要なレジストリーを /etc/ansible/hosts ファイル内に指定します。

openshift_cockpit_deployer_prefix=<registry_name>/<namespace>/
openshift_cockpit_deployer_version=<cockpit_image_tag>

例: イメージが registry.example.com/openshift3/registry-console にあり、バージョン 3.9.3 が必要な場合は、以下を入力します。

openshift_cockpit_deployer_prefix='registry.example.com/openshift3/'
openshift_cockpit_deployer_version='3.9.3'

Red Hat Gluster Storage は、OpenShift Container Platform の永続ストレージと動的プロビジョニングを提供するように設定でき、OpenShift Container Platform 内のコンテナー化ストレージ (Container-Native Storage) としても、独自のノード上の非コンテナー化ストレージ (Container-Ready Storage) としても使用できます。

追加情報と以下を含む例については、「 Red Hat Gluster Storage を使用する永続ストレージ」を参照してください。

統合された OpenShift Container レジストリー は、通常インストーラー (Advanced Installer)を使用してデプロイできます。

[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

[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

[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

[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

openshift_hosted_registry_storage_s3_regionendpoint=https://myendpoint.example.com/

[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

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

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

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

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

[nodes]
master.example.com

以前のバージョンの OpenShift Container Platform では、マスターホストはインストーラーによってデフォルトでスケジュール不能ノードとしてマークされました。そのため、マスターホストに新しい Pod を配置することができませんでした。しかし、OpenShift Container Platform 3.9 以降では、マスターはインストール時に自動的にスケジュール可能ノードとしてマークされます。この変更の主な目的は、以前はマスター自体の一部として実行されていた Web コンソールをマスターにデプロイされた Pod として実行できるようにすることです。

インストール後にホストのスケジュール可能性を変更したい場合は、「ノードをスケジュール対象外 (Unschedulable) またはスケジュール対象 (Schedulable) としてマークする」を参照してください。

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 が設定されているかどうかにかかわらず、以下の自動のラベル付けがインストール時にインベントリーファイルで定義されるホストに対して実行されます。

これにより、Pod の配置を決定する際にデフォルトノードセレクターがノードを選択できるようになります。

インストール後に必要に応じてこの設定を調整する手順については、「クラスター全体でのデフォルトノードセレクターの設定」を参照してください。

# default selectors for router and registry services
# openshift_router_selector='region=infra'
# openshift_registry_selector='region=infra'

[nodes]
infra-node1.example.com openshift_node_labels="{'region': 'infra','zone': 'default'}"

openshift_hosted_manage_registry=false
openshift_hosted_manage_router=false

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

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

OpenShift Container Platform API のパブリックホスト名と Web コンソールのカスタム提供証明書は、通常インストール (Advanced installation) 時にデプロイでき、インベントリーファイルで設定できます。

証明書とキーファイルのパスは、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 Name と Subject Alternative Names を検出します。検出された名前は、openshift_master_named_certificates の設定時に "names" キーを指定して上書きできます。

openshift_master_named_certificates=[{"certfile": "/path/to/custom1.crt", "keyfile": "/path/to/custom1.key", "names": ["public-master-host.com"], "cafile": "/path/to/custom-ca1.crt"}]

openshift_master_named_certificates を使用して設定される証明書はマスターにキャッシュされます。つまり、別の証明書セットで 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

デフォルトで、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 のインストール後での 証明書の再デプロイ時にも使用されます。

クラスターメトリクスは、自動的にデプロイされるように設定されていません。通常インストール (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}}

[OSEv3:vars]

openshift_metrics_cassandra_storage_type=dynamic

[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

[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

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

[OSEv3:vars]

openshift_logging_install_logging=true

[OSEv3:vars]

openshift_logging_es_pvc_dynamic=true

[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

[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

サービスカタログはインストール時にデフォルトで有効にされます。サービスブローカーを有効にすると、サービスブローカーをカタログで登録できます。サービスカタログが有効にされると、OpenShift Ansible Broker およびテンプレートサービスブローカーが共にインストールされます。詳細は、「OpenShift Ansible Broker の設定」および「テンプレートサービスブローカーの設定」を参照してください。サービスカタログを無効にする場合は、OpenShift Ansible Broker およびテンプレートサービスブローカーはインストールされません。

サービスカタログの自動デプロイメントを無効にするには、以下のクラスター変数をインベントリーファイルに設定します。

openshift_enable_service_catalog=false

独自のレジストリーを使用する場合、以下を追加する必要があります。

例を以下に示します。

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 の設定」および「テンプレートサービスブローカーの設定 」を参照してください。

ansible_service_broker_install=false

template_service_broker_install=false

openshift_template_service_broker_namespaces=['openshift','myproject']

template_service_broker_selector={"region": "infra"}

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

単一マスターと複数ノード、単一または複数の外部 etcd ホストを含む環境を設定できます。

単一マスター、単一 etcd および複数ノード

以下の表は、単一マスター (同じホストに単一 etcd がある)、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。

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

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

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

単一マスター、複数 etcd、および複数ノード

以下の表は、単一マスター、3 つの etcd ホスト、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [masters]、[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]
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'}"

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

複数マスター、複数 etcd ホスト、複数ノードを含む環境を設定できます。高可用性 (HA) 対応複数マスターを設定すると、クラスターに単一障害点が設定されないようにすることができます。

複数マスターを設定する際には、通常インストール (Advanced installation) でネイティブ高可用性 (HA) 方法がサポートされます。この方法は、OpenShift Container Platform に組み込まれているネイティブ HA マスター機能を活用するもので、 任意のロードバランシングソリューションと組み合わせことができます。

ホストがインベントリーファイルの [lb] セクションに定義されている場合、Ansible はロードバランシングソリューションとして HAProxy を自動的にインストールし、設定します。ホストが定義されていない場合、ユーザーが選択した外部のロードバランシングソリューションを事前に定義しており、マスター API (ポート 8443) をすべてのマスターホストで分散することが想定されます。

外部のロードバランシングソリューションを使用する場合は、以下が必要になります。

詳細については、「External Load Balancer Integrations example in Github」を参照してください。高可用性マスターアーキテクチャーの詳細については、 「 Kubernetes Infrastructure」を参照してください。

複数マスターを設定するには、「複数 etcd を持つ複数マスター」を参照してください。

外部のクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター

以下の表は、 ネイティブ HA 方法を使用する 3 つのマスター、1 つの HAProxy ロードバランサー、3 つの etcd ホスト、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [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 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'}"

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

同一の場所に配置されたクラスター化された etcd を含む、ネイティブ HA を使用した複数マスター

以下の表は、ネイティブ HA 方法を使用する 3 つのマスター (各ホストに etcd がある)、1 つの HAProxy ロードバランサー、ユーザーアプリケーションをホストする 2 つのノード、専用インフラストラクチャーをホストする region=infra ラベル付きの 2 つのノードの環境の例を示しています。

これらのサンプルホストは、以下のサンプルインベントリーファイルの [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'}"

この例を使用するには、お使いの環境と仕様に合わせてファイルを変更し、これを /etc/ansible/hosts として保存します。

RPM ベースのインストーラーは、RPM パッケージでインストールされた Ansible を使用し、ローカルホストで使用可能な Playbook と設定ファイルを実行します。

RPM ベースのインストーラーを実行するには、以下の手順を実行します。

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

openshift3/ose-ansible イメージは、 OpenShift Container Platform インストーラーのコンテナー化バージョンです。このインストーラーイメージは、RPM ベースのインストーラーと同じ機能を提供しますが、ホストに直接インストールされるのではなく、そのすべての依存関係を提供するコンテナー化環境で実行されます。この使用にあたっての唯一の要件は、コンテナーを実行できることになります。

# 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

$ ansible-playbook --user openshift \
  -i openshift-ansible/playbooks/openstack/inventory.py \
  -i inventory \
  openshift-ansible/playbooks/openstack/openshift-cluster/provision_install.yml

メインのインストール Playbook である /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.ymlは、一連の個別コンポーネント Playbook を特定の順序で実行します。実行の最後に、インストーラーから完了したフェーズが報告されます。インストールが失敗した場合は、そのフェーズが失敗したかについて Ansible の実行エラーと共に画面に表示されます。

エラーを解決した後に、インストールを継続できます。

残りの Playbook のみを実行する必要がある場合、失敗したフェーズの Playbook から実行し、その後に残りの Playbook を順番に実行します。

# ansible-playbook [-i /path/to/inventory] <playbook_file_location>

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

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

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

必要なリポジトリーを同期する前に、適切な GPG キーのインポートが必要になる場合があります。

$ rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

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

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

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

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

この時点で、OpenShift Container Platform 環境の一部を構成するホストの初回作成を実行できます。最新バージョンの RHEL 7 を使用し、最小限のインストールを実行するようにしてください。また、OpenShift Container Platform に固有の前提条件にも注意する必要があります。

ホストの最初の構築が完了したら、リポジトリーのセットアップが可能になります。

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

この時点で、以下の OpenShift Container Platform ドキュメントに従ってシステムの準備を継続できます。

「ホスト登録」セクションを飛ばして、「基本パッケージのインストール」 に進んでください。

関連するコンポーネントをインポートするには、接続したホストから 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 のインポートコマンドをローカルで実行することも可能です。

ドキュメントに記載されている OpenShift Container Platform の クイックインストールまたは基本インストール (Advanced installation)方式のいずれかを選択できます。

ここで、内部 Docker レジストリーの作成が必要になります。

スタンドアロンレジストリーのインストールが必要な場合には、registry-console コンテナーイメージ をプルし、インベントリーファイルに deployment_subtype=registry を設定する必要があります。

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

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

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

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

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

以下では、OpenShift Container Platform をすべてインストールするのではなく、クイックインストールツールを実行して OpenShift Container レジストリーをインストールする方法を順を追って説明します。

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

通常インストール (Advanced installation) 方式を使ってスタンドアロン OCR をインストールする際に、「通常インストール (Advanced installation)」のトピックで説明されている Ansible を使用した OpenShift Container Platform PaaS のインストールと同じ手順を使用します。大きな違いとして、ここでは Playbook がレジストリーのインストールパスをたどれるよう、インベントリーファイルの [OSEv3:vars] セクションに deployment_subtype=registry を設定する必要があります。

以下は、サポートされている複数の異なるシステムトポロジー用のインベントリーファイルの例です。

# 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

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

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