第6章 インストール Playbook の実行
6.1. インストールを開始する前に
OpenShift Container Platform をインストールする前に、以下を確認する必要があります。
- まず「前提条件」と「ホストの準備」のトピックを参照して、ホストを準備します。この準備では、コンポーネントタイプごとにシステムおよび環境要件を確認し、docker を適切にインストールし、設定することが含まれます。さらに、インストール方法は Ansible Playbook をベースとしており、Ansible を直接起動する必要があるため、Ansible バージョン 2.4 以降をインストールすることも含まれます。
環境および必要な OpenShift Container Platform クラスター設定を定義するには、「インベントリーファイルの設定」のトピックを参照してください。このインベントリーファイルはインストールを開始するために使用され、今後のクラスターアップグレード用にも保存され、維持される必要があります。
重要OpenShift Container Platform 3.10 以降、ホストごとに
openshift_node_group_nameをノードグループに設定することは、デフォルトのノードグループ定義または ConfigMaps を使用しているか、または独自の設定をカスタマイズしているかにかかわらず、すべてのクラスターインストールで必要です。それらをまだ設定していない場合は、詳細について「ノードグループおよびホストのマッピングの定義」を参照してください。
システムコンテナー方法を使用して OpenShift Container Platform をインストールする場合 (RHEL Atomic Host システムの場合は必須です) は、「RPM およびシステムコンテナーについての考慮事項」を参照し、それらの方法の違いを理解してから、このトピックに戻って続行してください。
インストール時間の最適化の提案などの大規模インストールについては、『Scaling and Performance Guide』を参照してください。
OpenShift Container Platform をスタンドアロンレジストリーとして インストールするには、「スタンドアロンレジストリーのインストール」を参照してください。
6.2. インストール Playbook の実行
インストーラーはモジュール化された Playbook を使用します。そのため、管理者は必要に応じて特定のコンポーネントをインストールできます。ロールと Playbook を分けることで、アドホックな管理タスクをより適切にターゲットに設定できます。その結果、インストール時の制御レベルが強化され、時間の節約が可能になります。Playbook およびそれらの順序については、「個別コンポーネント Playbook の実行」を参照してください。
RHEL Atomic Host はコンテナー化された OpenShift Container Platform サービスを実行するためにサポートされていますが、インストール方式では RHEL Atomic Host で利用できない Ansible を使用します。そのため、RPM ベースのインストーラーは RHEL 7 システムから実行される必要があります。インストールを開始するホストは OpenShift Container Platform クラスターに組み込まれる必要はありませんが、組み込みは可能です。または、インストーラーのコンテナー化バージョンを、RHEL Atomic Host システムから実行できるシステムコンテナーとして使用することもできます。
/etc/ansible/hosts でインベントリーファイルを定義して Ansible の設定を完了した後に、RPM ベースまたはコンテナー化されたインストーラーを使用し、Ansible 経由で Playbook を実行します。
既知の問題により、インストールの実行後、NFS ボリュームがいずれかのコンポーネント用にプロビジョニングされている場合、それらのコンポーネントが NFS ボリュームにデプロイされるかどうかにかかわらず、以下のディレクトリーが作成される可能性があります。
- /exports/logging-es
- /exports/logging-es-ops/
- /exports/metrics/
- /exports/prometheus
- /exports/prometheus-alertbuffer/
- /exports/prometheus-alertmanager/
インストール後にこれらのディレクトリーを随時削除することができます。
6.2.1. RPM ベースのインストーラーの実行
RPM ベースのインストーラーは、RPM パッケージでインストールされた Ansible を使用し、ローカルホストで使用可能な Playbook と設定ファイルを実行します。
OpenShift Ansible Playbook は nohup で実行しないでください。Playbook で nohup を使用すると、ファイル記述子が作成され、ファイルが閉じなくなります。その結果、システムでファイルをさらに開けなくなり、Playbook が失敗します。
RPM ベースのインストーラーを実行するには、以下の手順を実行します。
prerequisites.yml Playbook を実行します。この Playbook にはソフトウェアパッケージが必要であり (ある場合)、コンテナーランタイムを変更します。コンテナーランタイムを設定する必要がない限り、この Playbook はクラスターの初回のデプロイ前に 1 度のみ実行します。
# ansible-playbook [-i /path/to/inventory] \ 1 /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml- 1
- インベントリーファイルが /etc/ansible/hosts ディレクトリーにない場合、
-iおよびインベントリーファイルのパスを指定します。
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」で説明されています。
6.2.2. コンテナー化インストーラーの実行
openshift3/ose-ansible イメージは、 OpenShift Container Platform インストーラーのコンテナー化バージョンです。このインストーラーイメージは、RPM ベースのインストーラーと同じ機能を提供しますが、ホストに直接インストールされるのではなく、そのすべての依存関係を提供するコンテナー化環境で実行されます。この使用にあたっての唯一の要件は、コンテナーを実行できることになります。
6.2.2.1. インストーラーをシステムコンテナーとして実行する
インストーラーイメージは、システムコンテナーとして使用できます。システムコンテナーは、従来の docker サービスの外部に保存して実行できます。これにより、ホストでのインストールによって docker が再起動されることを心配することなく、ターゲットホストのいずれかからインストーラーイメージを実行することが可能になります。
Atomic CLI を使用してインストーラーを 1 回だけ実行されるシステムコンテナーとして実行するには、以下の手順を root ユーザーとして実行します。
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.10- 1
- ローカルホスト上にインベントリーファイルの場所を指定します。
このコマンドは、指定されるインベントリーファイルと
rootユーザーの SSH 設定を使用して一連の前提条件タスクを実行します。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.10- 1
- ローカルホスト上にインベントリーファイルの場所を指定します。
このコマンドは、指定されるインベントリーファイルと
rootユーザーの SSH 設定を使用してクラスターインストールを開始します。出力のログを端末に記録し、さらに /var/log/ansible.log ファイルに保存します。このコマンドの初回実行時に、イメージは OSTree ストレージ (システムコンテナーは docker デーモンストレージではなくこのストレージを使用します) にインポートされます。後続の実行では、保存されたイメージが再利用されます。何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に「既知の問題」に目を通し、特定の指示や回避策がないかどうか確認してください。
6.2.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.106.2.2.3. インストーラーを Docker コンテナーとして実行する
インストーラーイメージは、docker が実行できる任意の場所で docker コンテナーとして実行することもできます。
この方法は、設定されているホストのいずれかでインストーラーを実行するために使用しないでください。インストールによってホストで docker が再起動され、インストーラーコンテナーの実行が中断する可能性があります。
この方法と上記のシステムコンテナー方法は同じイメージを使用しますが、それぞれ異なるエントリーポイントとコンテキストで実行されます。そのため、ランタイムパラメーターは同じではありません。
インストーラーを docker コンテナーとして実行する場合は、少なくとも以下を指定する必要があります。
- SSH キー (Ansible がホストにアクセスできるようにするため)。
- Ansible インベントリーファイル。
- そのインベントリーに対して実行する Ansible Playbook の場所。
次に、docker 経由でインストールを実行する方法の例を示します。これは、docker へのアクセス権限を持つ非 root ユーザーとして実行する必要があります。
まず、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.10
- 1
-u `id -u`は、コンテナーが現在のユーザーと同じ UID で実行されるようにします。これにより、そのユーザーがコンテナー内の SSH キーを使用できるようになります (SSH プライベートキーは所有者のみが判読できることが予想されます)。- 2
-v $HOME/.ssh/id_rsa:/opt/app-root/src/.ssh/id_rsa:Zは、SSH キー ($HOME/.ssh/id_rsa) をコンテナーユーザーの$HOME/.ssh(/opt/app-root/src はコンテナー内のユーザーの$HOMEです) にマウントします。SSH キーを標準以外の場所にマウントする場合は、-e ANSIBLE_PRIVATE_KEY_FILE=/the/mount/pointで環境変数を追加するか、インベントリーでansible_ssh_private_key_file=/the/mount/pointを変数として設定し、Ansible がこれを参照するようにします。SSH キーは:Zフラグでマウントされることに注意してください。これは、コンテナーがその制限された SELinux コンテキストで SSH キーを読み取れるようにするために必要です。これはまた、元の SSH キーファイルのラベルがsystem_u:object_r:container_file_t:s0:c113,c247のようなラベルに変更されることも意味しています。:Zの詳細については、docker-run(1)の man ページを参照してください。これらの点は、このようなボリュームマウント仕様を提供する際に留意してください。これによって予期しない結果が生じる可能性があります。たとえば、$HOME/.sshディレクトリー全体をマウントすると (したがってラベルを変更すると)、ホストの sshd がログイン時にパブリックキーにアクセスできなくなります。このため、元のファイルラベルを変更しなくてもすむように SSH キー (またはディレクトリー) の別のコピーを使用することをお勧めします。- 3 4
-v $HOME/ansible/hosts:/tmp/inventory:Zと-e INVENTORY_FILE=/tmp/inventoryは、静的 Ansible インベントリーファイルを /tmp/inventory としてコンテナーにマウントし、これを参照する対応する環境変数を設定します。SSH キーと同様に、既存のラベルによっては、コンテナー内を読み取れるように、:Zフラグを使用してインベントリーファイルの SELinux ラベルを変更しなければならない場合があります (ユーザーの$HOMEディレクトリー内のファイルの場合、通常はラベルの変更が必要になります)。そのため、この場合もまた、マウント前にインベントリーを専用の場所にコピーすることをお勧めします。インベントリーファイルは、INVENTORY_URL環境変数を指定した場合には、Web サーバーからダウンロードすることもできます。またはDYNAMIC_SCRIPT_URLを使用して、動的なインベントリーを提供する実行可能スクリプトを指定することにより動的に生成することもできます。- 5
-e PLAYBOOK_FILE=playbooks/prerequisites.ymlは、実行する Playbook (この例では前提条件 Playbook) を、openshift-ansible コンテンツの最上位レベルのディレクトリーの相対パスとして指定します。RPM からのフルパスやコンテナー内のその他の Playbook へのパスも使用できます。- 6
-e OPTS="-v"は、コンテナー内で実行されるansible-playbookコマンドに任意のコマンドラインオプションを提供します (この例では、-vを使用して省サイドを上げることができます)。
次に、deploy_cluster.yml playbook を実行してクラスターインストールを開始します。
$ 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.10
6.2.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
6.2.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 を一覧表示しています。
| Playbook 名 | ファイルの場所 |
|---|---|
|
Health Check |
/usr/share/ansible/openshift-ansible/playbooks/openshift-checks/pre-install.yml |
|
Node Bootstrap |
/usr/share/ansible/openshift-ansible/playbooks/openshift-node/bootstrap.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 Join |
/usr/share/ansible/openshift-ansible/playbooks/openshift-node/join.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 |
|
Monitoring Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-monitoring/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 |
|
Availability Monitoring Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-monitor-availability/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 |
|
Descheduler Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-descheduler/config.yml |
|
Node Problem Detector Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-node-problem-detector/config.yml |
|
Autoheal Install |
/usr/share/ansible/openshift-ansible/playbooks/openshift-autoheal/config.yml |
6.3. インストールの検証
インストールが完了したら、次の手順を実行します。
マスターが起動しており、ノードが登録されており、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
Web コンソールが正常にインストールされているか確認するには、マスターホスト名と Web コンソールのポート番号を使用して Web ブラウザーで Web コンソールにアクセスします。
たとえば、ホスト名が
master.openshift.comで、デフォルトポート8443を使用するマスターホストの場合、Web コンソールはhttps://master.openshift.com:8443/consoleにあります。
複数 etcd ホストの確認
複数 etcd ホストをインストールした場合は、以下の手順を実行します。
まず、
etcdctlコマンドを提供する etcd パッケージがインストールされていることを確認します。# yum install etcd
マスターホストで etcd クラスターの正常性を確認します。以下で実際の etcd ホストの FQDN の置き換えを実行します。
# etcdctl -C \ https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \ --ca-file=/etc/origin/master/master.etcd-ca.crt \ --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file=/etc/origin/master/master.etcd-client.key cluster-healthメンバーリストが正しいことも確認します。
# etcdctl -C \ https://etcd1.example.com:2379,https://etcd2.example.com:2379,https://etcd3.example.com:2379 \ --ca-file=/etc/origin/master/master.etcd-ca.crt \ --cert-file=/etc/origin/master/master.etcd-client.crt \ --key-file=/etc/origin/master/master.etcd-client.key member list
HAProxy を使用する複数マスターの確認
HAProxy を使用する複数マスターをロードバランサーとしてインストールした場合は、[lb] セクションの定義に従って次の URL に移動し、HAProxy のステータスを確認します。
http://<lb_hostname>:9000
HAProxy の設定に関するドキュメントを参照してインストールを検証できます。
6.4. ビルドのオプションでのセキュリティー保護
docker build の実行は特権付きのプロセスのため、コンテナーにはマルチテナント環境で許可される以上のノードに対するアクセスがある場合があります。ユーザーを信頼しない場合、インストール時により多くのセキュアなオプションを使用できます。クラスターで Docker ビルドを無効にし、ユーザーに対してクラスター外でイメージをビルドするように要求できます。このオプションのプロセスについての詳細は、「Securing Builds by Strategy」を参照してください。
6.5. 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.yml6.5.1. ノードのアンインストール
uninstall.yml Playbook を使用すると、ノードコンポーネントを特定のホストからアンインストールし、それ以外のホストとクラスターをそのままにしておくことができます。
この方法は、特定のノードホストをアンインストールする場合にのみ使用してください。特定のマスターホストや etcd ホストのアンインストールには使用しないでください。これらのホストをアンインストールするには、クラスター内での追加の設定変更が必要になります。
- まず、「ノードの削除」の手順に従ってクラスターからノードオブジェクトを削除します。次に、この残りの手順を実行します。
これらのホストのみを参照する別のインベントリーファイルを作成します。たとえば、1 つのノードのみからコンテンツを削除する場合は、以下を実行します。
[OSEv3:children] nodes 1 [OSEv3:vars] ansible_ssh_user=root openshift_deployment_type=openshift-enterprise [nodes] node3.example.com openshift_node_group_name='node-config-infra' 2
uninstall.yml Playbook の実行時に、
-iオプションを使用して新規インベントリーファイルを指定します。# ansible-playbook -i /path/to/new/file \ /usr/share/ansible/openshift-ansible/playbooks/adhoc/uninstall.yml
Playbook が完了すると、すべての OpenShift Container Platform コンテンツが指定したホストから削除されます。
6.6. 既知の問題
- 複数マスタークラスターでフェイルオーバーが発生すると、コントローラーマネージャーの過剰修正が生じ、結果として予定よりも多くの pod がシステムで実行される可能性があります。ただし、これは一時的なイベントであり、後にシステムによって修正されます。詳細については、https://github.com/kubernetes/kubernetes/issues/10030 を参照してください。
Ansible インストーラーが失敗する場合でも、OpenShift Container Platform をインストールできます。
6.7. 次のステップ
これで OpenShift Container Platform インスタンスが機能し、以下を実行できるようになります。
- 統合 Docker レジストリーをデプロイします。
- ルーターをデプロイします。
