第19章 OpenStack の設定
19.1. 概要
OpenShift Container Platform は、OpenStack にデプロイする場合に、アプリケーションデータ用にOpenStack Cinder ボリュームを永続ストレージとして使用するなど、OpenStack インフラストラクチャーにアクセスするように設定できます。
19.2. 作業開始前の準備
19.2.1. OpenShift Container Platform の前提条件
OpenShift Container Platform を正常にデプロイするには数多くの要件を満たす必要があります。これには、Ansible を使用して OpenShift Container Platform を実際にインストールする前に一連のインフラストラクチャーおよびホスト設定の手順を実行する必要があります。以下のサブセクションでは、OpenStack 環境の OpenShift Container Platform に必要な前提条件および設定変更について詳しく説明します。
このリファレンス環境でのすべての OpenStack CLI コマンドは、OpenStack director ノード内で CLI openstack
コマンドを使って実行されます。OpenStack director ノードではなくこれらのコマンドの実行にワークステーションまたはラップトップを使用する場合は、指定されたリポジトリーにある以下のパッケージをインストールするようにしてください。
例:
「リポジトリーの設定」に従い、rhel-7-server-openstack-13-rpms および必須の OpenShift Container Platform リポジトリーを有効にします。
$ sudo subscription-manager repos \ --enable rhel-7-server-openstack-13-rpms $ sudo yum install -y python2-openstackclient python2-heatclient python2-octaviaclient ansible
パッケージは以下のバージョン以上であることを確認します (rpm -q <package_name>
を使用します)。
-
python2-openstackclient
-3.14.1.-1
-
python2-heatclient
1.14.0-1
-
python2-octaviaclient
1.4.0-1
-
ansible > 2.4.3
19.2.1.1. Octavia の有効化: OpenStack の LBaaS (Load Balancing as a Service)
Octavia は、外部の受信トラフィックの負荷を分散し、各種アプリケーションについての OpenShift Container Platform マスターサービスの単一ビューを提供するために OpenShift Container Platform と併用することが推奨されているサポート対象のロードバランサーソリューションです。
Octavia を有効にするには、Octavia サービスを OpenStack オーバークラウドのインストール時に組み込むか、またはオーバークラウドがすでに存在する場合はアップグレードする必要があります。以下の手順は、Octavia を有効にするためのカスタム手順を含まない基本的な手順であり、これらはオーバークラウドのクリーンインストールまたはオーバークラウドの更新の両方に適用されます。
以下の手順では、Octavia を使用する場合に OpenStack のデプロイメント時に必要となる主な手順のみを説明します。さらに詳しい情報は、「Installation of OpenStack」のドキュメントを参照してください。また、レジストリーの方法が変更されることにも留意してください。詳細は、「Registry Methods」のドキュメントを参照してください。以下の例では、ローカルレジストリーの方法を使用しています。
ローカルレジストリーを使用している場合、イメージをレジストリーにアップロードするためのテンプレートを作成します。以下は例になります。
(undercloud) $ openstack overcloud container image prepare \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ --namespace=registry.access.redhat.com/rhosp13 \ --push-destination=<local-ip-from-undercloud.conf>:8787 \ --prefix=openstack- \ --tag-from-label {version}-{release} \ --output-env-file=/home/stack/templates/overcloud_images.yaml \ --output-images-file /home/stack/local_registry_images.yaml
作成された local_registry_images.yaml に Octavia イメージが含まれることを確認します。
ローカルレジストリーファイルの Octavia イメージ
... - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-api:13.0-43 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-health-manager:13.0-45 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-housekeeping:13.0-45 push_destination: <local-ip-from-undercloud.conf>:8787 - imagename: registry.access.redhat.com/rhosp13/openstack-octavia-worker:13.0-44 push_destination: <local-ip-from-undercloud.conf>:8787 ...
以下の手順では、registry.access.redhat.com からアンダークラウドノードにコンテナーイメージをプルします。これには、ネットワークおよびアンダークラウドディスクの速度に応じて多少の時間がかかる可能性があります。
(undercloud) $ sudo openstack overcloud container image upload \ --config-file /home/stack/local_registry_images.yaml \ --verbose
Octavia を使用してオーバークラウドをインストールまたは更新します。
openstack overcloud deploy --templates \ . . . -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \ . . .
上記のコマンドには、Octavia に関連付けられたファイルのみが含まれます。このコマンドは、OpenStack の特定のインストールに応じて変わります。詳細は、公式の OpenStack ドキュメントを参照してください。Octavia インストールのカスタマイズについての詳細は、「installation of Octavia using Director」を参照してください。
19.2.1.2. OpenStack ユーザーアカウント、プロジェクトおよびロールの作成
OpenShift Container Platform のインストール前に、Red Hat OpenStack Platform (RHOSP) 環境には テナント と呼ばれることの多いプロジェクトが必要になります。これは OpenShift Container Platform をインストールするために使用される OpenStack インスタンスを保管します。このプロジェクトには、ユーザーおよび _member_
に設定されるユーザーのロールによる所有権が必要になります。
以下の手順は上記を実行する方法を説明しています。
OpenStack オーバークラウド管理者として以下を実行します。
RHOSP インスタンスを保管するために使用されるプロジェクト (テナント) を作成します。
$ openstack project create <project>
以前に作成したプロジェクトの所有権を持つ RHOSP ユーザーを作成します。
$ openstack user create --password <password> <username>
ユーザーのロールを設定します。
$ openstack role add --user <username> --project <project> _member_
上記が完了すると、OpenStack 管理者は、OpenShift Container Platform 環境を実装するユーザーに対し、必要なすべての情報と共に RC ファイルを作成することができます。
RC ファイルのサンプル:
$ cat path/to/examplerc # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=<project-name> export OS_USERNAME=<username> export OS_PASSWORD=<password> export OS_AUTH_URL=http://<ip>:5000//v3 export OS_CLOUDNAME=<cloud-name> export OS_IDENTITY_API_VERSION=3 # Add OS_CLOUDNAME to PS1 if [ -z "${CLOUDPROMPT_ENABLED:-}" ]; then export PS1=${PS1:-""} export PS1=\${OS_CLOUDNAME:+"(\$OS_CLOUDNAME)"}\ $PS1 export CLOUDPROMPT_ENABLED=1 fi
OpenStack director ノードまたはワークステーション内で OpenShift Container Platform 環境を実装するユーザーとして、以下のように認証情報の source
を実行します。
$ source path/to/examplerc
19.2.1.3. OpenStack フレーバーの作成
OpenStack 内で、フレーバーは nova
コンピューティングインスタンスのコンピュート、メモリー、およびストレージ容量を定義することで仮想サーバーのサイズを定義します。このリファレンスアーキテクチャー内のベースイメージは Red Hat Enterprise Linux 7.5 であるため、m1.node
および m1.master
のサイズが設定されたフレーバーが 表19.1「OpenShift の最小システム要件」 に示されるような仕様で作成されます。
ノード種別 | CPU | メモリー | root ディスク | フレーバー |
---|---|---|---|---|
マスター |
4* |
16** GB |
45 GB |
|
ノード |
1 |
8 GB |
20 GB |
|
vCPU を追加することが推奨されます。
etcd がマスター上の同一の場所に配置されている場合はメモリーの追加が推奨されます。
OpenStack 管理者として以下を実行します。
$ openstack flavor create <flavor_name> \ --id auto \ --ram <ram_in_MB> \ --disk <disk_in_GB> \ --vcpus <num_vcpus>
以下の例は、このリファレンス環境内でのフレーバーの作成について示しています。
$ openstack flavor create m1.master \ --id auto \ --ram 16384 \ --disk 45 \ --vcpus 4 $ openstack flavor create m1.node \ --id auto \ --ram 8192 \ --disk 20 \ --vcpus 1
新規フレーバーを作成するために OpenStack 管理者権限にアクセスできない場合は、表19.1「OpenShift の最小システム要件」 の要件を満たす OpenStack 環境内で既存フレーバーを使用します。
以下を実行して OpenStack フレーバーを検証します。
$ openstack flavor list
19.2.1.4. OpenStack キーペアの作成
Red Hat OpenStack Platform は、インスタンスへの ssh
アクセスを許可するように作成されているため、cloud-init
を使用して ssh
パブリックキーを各インスタンスに配置します。Red Hat OpenStack Platform ではユーザーがプライベートキーを保持することを予想されています。
プライベートキーを失うと、インスタンスにアクセスできなくなります。
キーペアを生成するには、以下のコマンドを使用します。
$ openstack keypair create <keypair-name> > /path/to/<keypair-name>.pem
キーペアの作成は以下で検証できます。
$ openstack keypair list
キーペアが作成されたら、パーミッションを 600
に設定します。これにより、ファイルの所有者のみが該当ファイルの読み取り、および書き込みを行えるようになります。
$ chmod 600 /path/to/<keypair-name>.pem
19.2.1.5. OpenShift Container Platform の DNS の設定
DNS サービスは OpenShift Container Platform 環境における重要なコンポーネントです。DNS のプロバイダーの種類を問わず、組織は各種の OpenShift Container Platform コンポーネントを提供できるように特定のレコードを利用可能にしておく必要があります。
/etc/hosts
の使用は有効ではありません。適切な DNS サービスがなければなりません。
DNS のキーシークレットを使用して、情報を OpenShift Ansible インストールに提供することができ、これにより、ターゲットインスタンスの A レコードおよび各種の OpenShift Container Platform コンポーネントが自動的に追加されます。このプロセス設定については、後程 OpenShift Ansible インストーラーの設定との関連で説明します。
DNS サーバーへのアクセスが必要になることが予想されます。アクセスについてのヘルプが必要な場合は、Red Hat Labs DNS Helper を使用できます。
アプリケーション DNS
OpenShift で提供されるアプリケーションはポート 80/TCP および 443/TCP のルーターによってアクセス可能です。ルーターは ワイルドカード レコードを使用して特定のサブドメインにあるすべてのホスト名を同じ IP アドレスにマップできます。この際、それぞれの名前に別個のレコードを用意する必要はありません。
これにより、OpenShift Container Platform は任意の名前が該当するサブドメインにある限り、それらの名前のアプリケーションを追加することができます。
たとえば、*.apps.example.com
のワイルドカードレコードを使用すると、tax.apps.example.com
および home-goods.apps.example.com
の DNS 名検索により、同一の IP アドレス 10.19.x.y
が返されます。すべてのトラフィックは OpenShift ルーターに転送されます。ルーターはクエリーの HTTP ヘッダーを検査し、それらを正しい宛先に転送します。
Octavia などのロードバランサーを使用して、ホストアドレスの 10.19.x.y、ワイルドカード DNS レコードは以下のように追加できます。
IP アドレス | ホスト名 | 目的 |
---|---|---|
10.19.x.y |
|
アプリケーション Web サービスへのユーザーアクセス |
19.2.1.6. OpenStack 経由での OpenShift Container Platform ネットワークの作成
このセグメントで説明されているように OpenShift Container Platform を Red Hat OpenStack Platform でデプロイすると、 パブリック および 内部 の 2 つのネットワークが必要になります。
パブリックネットワーク
パブリック ネットワークは外部アクセスを含むネットワークであり、外部からアクセスできるものです。パブリック ネットワークは OpenStack 管理者によってのみ作成されます。
以下のコマンドは、パブリック ネットワークアクセス用の OpenStack プロバイダーネットワークを作成する例を示しています。
OpenStack 管理者として (overcloudrc アクセス)、以下を実行します。
$ source /path/to/examplerc $ openstack network create <public-net-name> \ --external \ --provider-network-type flat \ --provider-physical-network datacentre $ openstack subnet create <public-subnet-name> \ --network <public-net-name> \ --dhcp \ --allocation-pool start=<float_start_ip>,end=<float_end_ip> \ --gateway <ip> \ --subnet-range <CIDR>
ネットワークおよびサブネットが作成されたら、以下のように検証します。
$ openstack network list $ openstack subnet list
<float_start_ip>
および <float_end_ip>
は、パブリック ネットワークのラベルが付けられたネットワークに提供される関連付けられた Floating IP プールです。Classless Inter-Domain Routing (CIDR) は <ip>/<routing_prefix>
の形式を使用します (例: 10.0.0.1/24)。
内部ネットワーク
内部 ネットワークがネットワークの設定時にルーター経由で パブリック ネットワークに接続されます。これにより、内部 ネットワークに割り当てられている各 Red Hat OpenStack Platform インスタンスには、パブリックアクセス用の パブリック ネットワークから Floating IP を要求する機能が付与されます。内部 ネットワークは、openshift_openstack_private_network_name
を設定することにより OpenShift Ansible インストーラーによって自動的に作成されます。OpenShift Ansible インストーラーに必要な変更の詳細については、後で説明します。
19.2.1.7. OpenStack デプロイメントホストセキュリティーグループの作成
OpenStack ネットワークはユーザーがネットワーク上の各インスタンスに適用できる受信および送信トラフィックフィルターを定義することを許可します。これにより、ユーザーはインスタンスサービスの機能に基づいて各インスタンスへのネットワークトラフィックを制限でき、ホストベースのフィルターに依存する必要はありません。OpenShift Ansible インストーラーは、デプロイメントホスト以外の OpenShift Container Platform クラスターを構成するホストのそれぞれのタイプに必要なすべてのポートおよびサービスの作成を適切に処理します。
以下のコマンドは、デプロイメントホストにルールが設定されていない状態で空のセキュリティーグループを作成します。
$ source path/to/examplerc
$ openstack security group create <deployment-sg-name>
セキュリティーグループの作成を確認します。
$ openstack security group list
デプロイメントホストセキュリティーグループ
デプロイメントインスタンスの場合は、受信 ssh
のみを許可する必要があります。このインスタンスは、オペレーターに対して OpenShift Container Platform 環境をデプロイし、モニターし、管理するための安定したベースを提供することを目的として存在します。
ポート/プロトコル | サービス | リモートソース | 目的 |
---|---|---|---|
ICMP |
ICMP |
任意 |
ping、traceroute などを許可。 |
22/TCP |
SSH |
任意 |
セキュアなシェルログイン |
上記のセキュリティーグループルールの作成は以下のように行われます。
$ source /path/to/examplerc $ openstack security group rule create \ --ingress \ --protocol icmp \ <deployment-sg-name> $ openstack security group rule create \ --ingress \ --protocol tcp \ --dst-port 22 \ <deployment-sg-name>
セキュリティーグループルールの検証は以下のように行われます。
$ openstack security group rule list <deployment-sg-name>
+--------------------------------------+-------------+-----------+------------+-----------------------+
| ID | IP Protocol | IP Range | Port Range | Remote Security Group |
+--------------------------------------+-------------+-----------+------------+-----------------------+
| 7971fc03-4bfe-4153-8bde-5ae0f93e94a8 | icmp | 0.0.0.0/0 | | None |
| b8508884-e82b-4ee3-9f36-f57e1803e4a4 | None | None | | None |
| cb914caf-3e84-48e2-8a01-c23e61855bf6 | tcp | 0.0.0.0/0 | 22:22 | None |
| e8764c02-526e-453f-b978-c5ea757c3ac5 | None | None | | None |
+--------------------------------------+-------------+-----------+------------+-----------------------+
19.2.1.8. OpenStack Cinder ボリューム
OpenStack Block Storage は、cinder
サービスを使用して永続ブロックストレージを管理します。ブロックストレージは OpenStack ユーザーによる各種の OpenStack インスタンスに割り当て可能なボリュームの作成を可能にします。
19.2.1.8.1. Docker ボリューム
マスターおよびノードインスタンスには、docker
イメージを保管するためのボリュームが含まれます。このボリュームの目的は、大規模なイメージまたはコンテナーによりノードのパフォーマンスが下がったり、既存ノードの機能に影響が及ばないようにすることにあります。
コンテナーを実行するには、最小 15GB の docker ボリュームが必要です。これについては、各ノードが実行するコンテナーのサイズおよび数に応じて調整が必要になる可能性があります。
docker ボリュームは、変数 openshift_openstack_docker_volume_size
を使用して OpenShift Ansible インストーラーによって作成されます。OpenShift Ansible インストーラーに必要な変更についての詳細は後で説明します。
19.2.1.8.2. レジストリーボリューム
OpenShift イメージレジストリーには、レジストリーが別のノードに移行する必要がある場合でもイメージを保存できるようにするために cinder
ボリュームが必要です。以下の手順では、OpenStack を使用してイメージレジストリーを作成する方法を説明します。ボリュームが作成されると、後述されるようにボリューム ID がパラメーター openshift_hosted_registry_storage_openstack_volumeID
により OpenShift Ansible Installer OSEv3.yml ファイルに組み込まれます。
$ source /path/to/examplerc $ openstack volume create --size <volume-size-in-GB> <registry-name>
レジストリーのボリュームサイズは 30GB 以上である必要があります。
ボリュームの作成を確認します。
$ openstack volume list ----------------------------------------+------------------------------------------------+ | ID | Name | Status | Size | Attached to | +--------------------------------------+-------------------------------------------------+ | d65209f0-9061-4cd8-8827-ae6e2253a18d | <regisry-name>| available | 30 | | +--------------------------------------+-------------------------------------------------+
19.2.1.9. デプロイメントインスタンスの作成および設定
デプロイメントインスタンスのロールは、OpenShift Container Platform のデプロイメントおよび管理のユーティリティーホストとして機能することにあります。
デプロイメントホストのネットワークおよびルーターの作成
インスタンスの作成前に、内部ネットワークおよびルーターはデプロイメントホストとの通信用に作成される必要があります。以下のコマンドは、そのネットワークおよびルーターを作成します。
$ source path/to/examplerc $ openstack network create <deployment-net-name> $ openstack subnet create --network <deployment-net-name> \ --subnet-range <subnet_range> \ --dns-nameserver <dns-ip> \ <deployment-subnet-name> $ openstack router create <deployment-router-name> $ openstack router set --external-gateway <public-net-name> <deployment-router-name> $ openstack router add subnet <deployment-router-name> <deployment-subnet-name>
デプロイメントインスタンスのデプロイ
作成されるネットワークおよびセキュリティーグループで、インスタンスをデプロイします。
$ domain=<domain> $ netid1=$(openstack network show <deployment-net-name> -f value -c id) $ openstack server create \ --nic net-id=$netid1 \ --flavor <flavor> \ --image <image> \ --key-name <keypair> \ --security-group <deployment-sg-name> \ deployment.$domain
m1.small
フレーバーがデフォルトで存在しない場合、1 vCPU および 2GB RAM の要件を満たす既存フレーバーを使用します。
Floating IP の作成およびデプロイメントインスタンスへの追加
デプロイメントインスタンスの作成後に、Floating IP を作成し、これをインスタンスに割り当てる必要があります。以下は例になります。
$ source /path/to/examplerc
$ openstack floating ip create <public-network-name>
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| created_at | 2017-08-24T22:44:03Z |
| description | |
| fixed_ip_address | None |
| floating_ip_address | 10.20.120.150 |
| floating_network_id | 084884f9-d9d2-477a-bae7-26dbb4ff1873 |
| headers | |
| id | 2bc06e39-1efb-453e-8642-39f910ac8fd1 |
| port_id | None |
| project_id | ca304dfee9a04597b16d253efd0e2332 |
| project_id | ca304dfee9a04597b16d253efd0e2332 |
| revision_number | 1 |
| router_id | None |
| status | DOWN |
| updated_at | 2017-08-24T22:44:03Z |
+---------------------+--------------------------------------+
上記の出力の floating_ip_address
フィールドは Floating IP 10.20.120.150
が作成されていることを示しています。この IP をデプロイメントインスタンスに割り当てるには、以下のコマンドを実行します。
$ source /path/to/examplerc
$ openstack server add floating ip <deployment-instance-name> <ip>
たとえば、インスタンス deployment.example.com
に IP 10.20.120.150
が割り当てられる場合、コマンドは以下のようになります。
$ source /path/to/examplerc $ openstack server add floating ip deployment.example.com 10.20.120.150
RC ファイルのデプロイメントホストへの追加
デプロイメントホストの存在を確認したら、以下のように先に作成した RC ファイルを scp
でデプロイメントホストにコピーします。
scp <rc-file-deployment-host> cloud-user@<ip>:/home/cloud-user/
19.2.1.10. OpenShift Container Platform のデプロイメントホスト設定
以下のサブセクションでは、デプロイメントインスタンスを適切に設定するために必要なすべての手順について説明しています。
デプロイメントホストを Jumphost として使用できるように ~/.ssh/config を設定する
OpenShift Container Platform 環境に簡単に接続するには、以下の手順に従ってください。
OpenStack director ノードまたはローカルワークステーションで プライベートキー <keypair-name>.pem を使用して以下を実行します。
$ exec ssh-agent bash $ ssh-add /path/to/<keypair-name>.pem Identity added: /path/to/<keypair-name>.pem (/path/to/<keypair-name>.pem)
~/.ssh/config
ファイルに追加します。
Host deployment HostName <deployment_fqdn_hostname OR IP address> User cloud-user IdentityFile /path/to/<keypair-name>.pem ForwardAgent yes
認証エージェント接続の転送を有効にする -A
オプションを指定し、デプロイメントホストに対して ssh
を実行します。
パーミッションが ~/.ssh/config ファイルの所有者に対して読み取り/書き込み専用に設定されていることを確認します。
$ chmod 600 ~/.ssh/config
$ ssh -A cloud-user@deployment
デプロイメントホストにログインしたら、SSH_AUTH_SOCK
をチェックして ssh エージェント転送が機能することを確認します。
$ echo "$SSH_AUTH_SOCK" /tmp/ssh-NDFDQD02qB/agent.1387
Subscription Manager および OpenShift Container Platform リポジトリーの有効化
デプロイメントインスタンス内で、Red Hat Subscription Manager への登録を行います。これは認証情報を使用して実行できます。
$ sudo subscription-manager register --username <user> --password '<password>'
または、アクティベーションキーを使用できます。
$ sudo subscription-manager register --org="<org_id>" --activationkey=<keyname>
登録が完了したら、以下のようにレジストリーを有効にします。
$ sudo subscription-manager repos \ --enable="rhel-7-server-rpms" \ --enable="rhel-7-server-extras-rpms" \ --enable="rhel-7-server-ose-3.10-rpms" \ --enable="rhel-7-server-ansible-2.4-rpms" \ --enable="rhel-7-server-openstack-13-rpms" \ --enable="rhel-7-server-openstack-13-tools-rpms"
「リポジトリーの設定」を参照し、有効にする OpenShift Container Platform リポジトリーおよび Ansible バージョンを確認します。上記のファイルはサンプルです。
デプロイメントホストで必要なパッケージ
以下のパッケージがデプロイメントホストでインストールされる必要があります。
以下のパッケージをインストールします。
-
openshift-ansible
-
python-openstackclient
-
python2-heatclient
-
python2-octaviaclient
-
python2-shade
-
python-dns
-
git
-
ansible
$ sudo yum -y install openshift-ansible python-openstackclient python2-heatclient python2-octaviaclient python2-shade python-dns git ansible
Ansible の設定
ansible
は、マスターおよびノードインスタンスで登録やパッケージのインストール、および OpenShift Container Platform 環境のデプロイメントを実行するためにデプロイメントインスタンスにインストールされます。
Playbook を実行する前に、デプロイする環境を反映させるために ansible.cfg ファイルを作成する必要があります。
$ cat ~/ansible.cfg
[defaults]
forks = 20
host_key_checking = False
remote_user = openshift
gathering = smart
fact_caching = jsonfile
fact_caching_connection = $HOME/ansible/facts
fact_caching_timeout = 600
log_path = $HOME/ansible.log
nocows = 1
callback_whitelist = profile_tasks
inventory = /usr/share/ansible/openshift-ansible/playbooks/openstack/inventory.py,/home/cloud-user/inventory
[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=600s -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=false
control_path = %(directory)s/%%h-%%r
pipelining = True
timeout = 10
[persistent_connection]
connect_timeout = 30
connect_retries = 30
connect_interval = 1
以下のパラメーターの値は ansible.cfg ファイルで重要な値になります。
-
remote_user
はユーザー openshift のままにする必要があります。 - インベントリーパラメーターでは、2 つのインベントリー間にスペースが入っていないことを確認します。
例: inventory = path/to/inventory1,path/to/inventory2
上記のコードブロックはファイルのデフォルト値を上書きする可能性があります。<keypair-name> に、デプロイメントインスタンスにコピーしたキーペアを設定するようにしてください。
inventory フォルダーは 「プロビジョニング用のインベントリーの準備」 に作成されます。
OpenShift 認証
OpenShift Container Platform は多数の異なる認証プラットフォームを使用する機能を提供します。認証オプションの一覧については、「認証およびユーザーエージェントの設定」を参照してください。
デフォルトのアイデンティティープロバイダーを設定することは、デフォルト値が Deny All に設定されているので重要になります。
19.3. OpenShift Ansible Playbook を使用した OpenShift Container Platform インスタンスのプロビジョニング
デプロイメントホストの作成および設定が完了したら、Ansible を使用して OpenShift Container Platform のデプロイメント用に環境を準備します。以下のサブセクションでは、OpenShift Container Platform を OpenStack に適切にデプロイできるように Ansible が設定され、特定の YAML ファイルが変更されます。
19.3.1. プロビジョニング用のインベントリーの準備
これまでの手順で openshift-ansible
パッケージのインストールを完了したら、sample-inventory
ディレクトリーが用意されます。これをデプロイメントホストの cloud-user
ホームディレクトリーにコピーします。
デプロイメントホストで、以下を実行します。
$ cp -r /usr/share/ansible/openshift-ansible/playbooks/openstack/sample-inventory/ ~/inventory
インベントリーディレクトリー内の all.yml ファイルには、RHOCP インスタンスを正常にプロビジョニングするために設定する必要のある複数の異なるパラメーターすべてが含まれます。OSEv3.yml ファイルには、all.yml ファイルで必要な一部の参照と、カスタマイズできる利用可能な OpenShift クラスターパラメーターが含まれます。
19.3.1.1. all.yml 設定
all.yml ファイルには、特定にニーズに合わせて変更できる数多くのオプションがあります。このファイルに収集される情報は、OpenShift Container Platform の正常なデプロイメントに必要なインスタンスのプロビジョニングの部分に対応します。これらを注意深く確認するようにしてください。本書では all.yml ファイルの縮小バージョンを扱っており、適切なデプロイメントを実行するために設定する必要のある最重要のパラメーターに重点を置いています。
$ cat ~/inventory/group_vars/all.yml --- openshift_openstack_clusterid: "openshift" openshift_openstack_public_dns_domain: "example.com" openshift_openstack_dns_nameservers: ["10.19.115.228"] openshift_openstack_public_hostname_suffix: "-public" openshift_openstack_nsupdate_zone: "{{ openshift_openstack_public_dns_domain }}" openshift_openstack_keypair_name: "openshift" openshift_openstack_external_network_name: "public" openshift_openstack_default_image_name: "rhel75" openshift_openstack_num_masters: 3 openshift_openstack_num_infra: 3 openshift_openstack_num_cns: 0 openshift_openstack_num_nodes: 2 openshift_openstack_master_flavor: "m1.master" openshift_openstack_default_flavor: "m1.node" openshift_openstack_use_lbaas_load_balancer: true openshift_openstack_docker_volume_size: "15" # # Roll-your-own DNS openshift_openstack_external_nsupdate_keys: public: key_secret: '/alb8h0EAFWvb4i+CMA12w==' key_name: "update-key" key_algorithm: 'hmac-md5' server: '<ip-of-DNS>' private: key_secret: '/alb8h0EAFWvb4i+CMA12w==' key_name: "update-key" key_algorithm: 'hmac-md5' server: '<ip-of-DNS>' ansible_user: openshift ## cloud config openshift_openstack_disable_root: true openshift_openstack_user: openshift
外部 DNS サーバーを使用することにより、プライベートおよびパブリックのセクションは DNS サーバーのパブリック IP アドレスを使用します。DNS サーバーが OpenStack 環境内に置かれていないためです。
上記の強調表示されている値は、お使いの OpenStack 環境および DNS サーバーに応じて変更が必要になります。
all.yml の DNS の部分を適切に変更するには、DNS サーバーにログインし、以下のコマンドを実行してキー名、キーアルゴリズムおよびキーシークレットを取得します。
$ ssh <ip-of-DNS> $ sudo -i # cat /etc/named/<key-name.key> key "update-key" { algorithm hmac-md5; secret "/alb8h0EAFWvb4i+CMA02w=="; };
キー名は変わる可能性があり、上記はサンプルであることに注意してください。
以下の表は、それぞれの変数を簡単に説明しています。
変数 | 説明 |
---|---|
openshift_openstack_clusterid |
クラスターの固有名 |
openshift_openstack_public_dns_domain |
パブリック DNS ドメイン名 |
openshift_openstack_dns_nameservers |
DNS ネームサーバーの IP |
openshift_openstack_public_hostname_suffix |
パブリックおよびプライベートの両方について DNS レコードのノードホスト名にサフィックスを追加します。 |
openshift_openstack_nsupdate_zone |
OCP インスタンス IP で更新されるゾーン |
openshift_openstack_keypair_name |
OCP インスタンスにログインするために使用されるキーペア名 |
openshift_openstack_external_network_name |
OpenStack パブリックネットワーク名 |
openshift_openstack_default_image_name |
OCP インスタンスに使用される OpenStack イメージ |
openshift_openstack_num_masters |
デプロイするマスターノードの数 |
openshift_openstack_num_infra |
デプロイするインフラストラクチャーノードの数 |
openshift_openstack_num_cns |
デプロイするコンテナーネイティブストレージノードの数 |
openshift_openstack_num_nodes |
デプロイするアプリケーションノードの数 |
openshift_openstack_master_flavor |
マスターインスタンスに使用される OpenStack フレーバーの名前 |
openshift_openstack_default_flavor |
特定のフレーバーが指定されていない場合に、すべてのインスタンスに使用される Openstack フレーバーの名前 |
openshift_openstack_use_lbaas_load_balancer |
Octavia ロードバランサーを有効にするブール値 (Octavia はインストールされる必要があります) |
openshift_openstack_docker_volume_size |
Docker ボリュームの最小サイズ (必要な変数) |
openshift_openstack_external_nsupdate_keys |
DNS のインスタンス IP アドレスでの更新 |
ansible_user |
OpenShift Container Platform をデプロイするために使用される Ansible ユーザー。"openshift" は必須の名前であり、変更することはできません。 |
openshift_openstack_disable_root |
ルートアクセスを無効にするブール値 |
openshift_openstack_user |
このユーザーで使用される OCP インスタンス |
19.3.1.2. OSEv3.yml
OSEv3.yml ファイルは、OpenShift のインストールに関連するすべての異なるパラメーターおよびカスタマイズを指定します。
以下は、正常なデプロイメントに必要なすべての変数を含むファイルの縮小バージョンです。特定の OpenShift Container Platform デプロイメントに必要なカスタマイズの内容によって、追加の変数が必要になる場合があります。
$ cat ~/inventory/group_vars/OSEv3.yml --- openshift_deployment_type: openshift-enterprise openshift_release: v3.10 openshift_master_default_subdomain: "apps.{{ (openshift_openstack_clusterid|trim == '') | ternary(openshift_openstack_public_dns_domain, openshift_openstack_clusterid + '.' + openshift_openstack_public_dns_domain) }}" openshift_master_cluster_public_hostname: "console.{{ (openshift_openstack_clusterid|trim == '') | ternary(openshift_openstack_public_dns_domain, openshift_openstack_clusterid + '.' + openshift_openstack_public_dns_domain) }}" OpenStack Credentials: openshift_cloudprovider_kind: openstack openshift_cloudprovider_openstack_auth_url: "{{ lookup('env','OS_AUTH_URL') }}" openshift_cloudprovider_openstack_username: "{{ lookup('env','OS_USERNAME') }}" openshift_cloudprovider_openstack_password: "{{ lookup('env','OS_PASSWORD') }}" openshift_cloudprovider_openstack_tenant_name: "{{ lookup('env','OS_PROJECT_NAME') }}" openshift_cloudprovider_openstack_blockstorage_version: v2 openshift_cloudprovider_openstack_domain_name: "{{ lookup('env','OS_USER_DOMAIN_NAME') }}" # Use Cinder volume for Openshift registry: openshift_hosted_registry_storage_kind: openstack openshift_hosted_registry_storage_access_modes: ['ReadWriteOnce'] openshift_hosted_registry_storage_openstack_filesystem: xfs openshift_hosted_registry_storage_volume_size: 30Gi openshift_hosted_registry_storage_openstack_volumeID: d65209f0-9061-4cd8-8827-ae6e2253a18d openshift_hostname_check: false ansible_become: true #Setting SDN (defaults to ovs-networkpolicy) not part of OSEv3.yml #For more info, on which to choose, visit: #https://docs.openshift.com/container-platform/3.10/architecture/networking/sdn.html#overview networkPluginName: redhat/ovs-networkpolicy #networkPluginName: redhat/ovs-multitenant #Configuring identity providers with Ansible #For initial cluster installations, the Deny All identity provider is configured #by default. It is recommended to be configured with either htpasswd #authentication, LDAP authentication, or Allowing all authentication (not recommended) #For more info, visit: #https://docs.openshift.com/container-platform/3.10/install_config/configuring_authentication.html#identity-providers-ansible #Example of Allowing All #openshift_master_identity_providers: [{'name': 'allow_all', 'login': 'true', 'challenge': 'true', 'kind': 'AllowAllPasswordIdentityProvider'}] #Optional Metrics (uncomment below lines for installation) #openshift_metrics_install_metrics: true #openshift_metrics_cassandra_storage_type: dynamic #openshift_metrics_storage_volume_size: 25Gi #openshift_metrics_cassandra_nodeselector: {"node-role.kubernetes.io/infra":"true"} #openshift_metrics_hawkular_nodeselector: {"node-role.kubernetes.io/infra":"true"} #openshift_metrics_heapster_nodeselector: {"node-role.kubernetes.io/infra":"true"} #Optional Aggregated Logging (uncomment below lines for installation) #openshift_logging_install_logging: true #openshift_logging_es_pvc_dynamic: true #openshift_logging_es_pvc_size: 30Gi #openshift_logging_es_cluster_size: 3 #openshift_logging_es_number_of_replicas: 1 #openshift_logging_es_nodeselector: {"node-role.kubernetes.io/infra":"true"} #openshift_logging_kibana_nodeselector: {"node-role.kubernetes.io/infra":"true"} #openshift_logging_curator_nodeselector: {"node-role.kubernetes.io/infra":"true"}
一覧表示されている変数のいずれかについての詳細は、OpenShift-Ansible ホストインベントリーのサンプルを参照してください。
19.3.2. OpenStack 前提条件 Playbook
OpenShift Container Platform Ansible インストーラーは Playbook を提供し、OpenStack インスタンスのすべてのプロビジョニング手順が確実に実行されることを確認します。
Playbook の実行前に、RC ファイルを取得します。
$ source path/to/examplerc
デプロイメントホストで ansible-playbook
コマンドを使用し、prerequisites.yml
Playbook を使用してすべての前提条件を満たしていることを確認します。
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/prerequisites.yml
前提条件 Playbook が正常に完了した後に、プロビジョニング Playbook を以下のように実行します。
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/provision.yml
provision.yml が早期にエラーを出す場合、OpenStack スタックのステータスを確認し、これが終了するのを待機します。
$ watch openstack stack list +--------------------------------------+-------------------+--------------------+----------------------+--------------+ | ID | Stack Name | Stack Status | Creation Time | Updated Time | +--------------------------------------+-------------------+--------------------+----------------------+--------------+ | 87cb6d1c-8516-40fc-892b-49ad5cb87fac | openshift-cluster | CREATE_IN_PROGRESS | 2018-08-20T23:44:46Z | None | +--------------------------------------+-------------------+--------------------+----------------------+--------------+
スタックが CREATE_IN_PROGRESS
を表示する場合は、スタックが CREATE_COMPLETE
などの最終結果を出して完了するのを待機します。スタックが正常に完了しない場合は、それが追加で必要な手順を終了するように provision.yml Playbook を再実行します。
スタックが CREATE_FAILED
を表示する場合、以下のコマンドを実行してエラーの原因を確認します。
$ openstack stack failures list openshift-cluster
19.4. OpenShift Container Platform インスタンスについての Subscription Manager の登録
ノードが正常にプロビジョニングされると、次の手順としてすべてのノードを subscription-manager
で正常に登録し、正常な OpenShift Container Platform インストールに必要なすべてのパッケージをインストールする必要があります。これを簡単に実行できるように repos.yml ファイルが作成され、提供されています。
$ cat ~/repos.yml --- - name: Enable the proper repositories for OpenShift installation hosts: OSEv3 become: yes tasks: - name: Register with activationkey and consume subscriptions matching Red Hat Cloud Suite or Red Hat OpenShift Container Platform redhat_subscription: state: present activationkey: <key-name> org_id: <orig_id> pool: '^(Red Hat Cloud Suite|Red Hat OpenShift Container Platform)$' - name: Disable all current repositories rhsm_repository: name: '*' state: disabled - name: Enable Repositories rhsm_repository: name: "{{ item }}" state: enabled with_items: - rhel-7-server-rpms - rhel-7-server-extras-rpms - rhel-7-server-ansible-2.4-rpms - rhel-7-server-ose-3.10-rpms
「リポジトリーの設定」を参照し、有効にする適切なリポジトリーおよびバージョンを確認します。上記のファイルはサンプルであることに注意してください。
repos.yml を使用して ansible-playbook
コマンドを実行します。
$ ansible-playbook repos.yml
上記の例では、すべての登録に Ansible の redhat_subscription
および rhsm_repository
モジュールを使用し、リポジトリーの無効化および有効化を行います。この特定の例では、Red Hat アクティべーションキーを利用しています。アクティべーションキーがない場合は、Ansible の redhat_subscription
モジュールにアクセスして、例に示されるようにユーザー名およびパスワードを使用して変更を実行してください (https://docs.ansible.com/ansible/2.6/modules/redhat_subscription_module.html)。
redhat_subscription
モジュールは特定ノードで失敗することが時折あります。この問題が生じる場合は、subscription-manager
を使用して OpenShift Container Platform インスタンスを手動で登録してください。
19.5. Ansible Playbook を使用した OpenShift Container Platform のインストール
OpenStack インスタンスがプロビジョニングされると、OpenShift Container Platform のインストールに焦点が切り替わります。インストールおよび設定は、OpenShift RPM パッケージで提供される一連の Ansible Playbook およびロールで実行されます。事前に設定された OSEv3.yml ファイルで、すべてのオプションが適切に設定されていることを確認してください。
インストーラー Playbook を実行する前に、以下を実行してすべての {rhocp} 前提条件を満たしていることを確認します。
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml
インストーラー Playbook を実行して Red Hat OpenShift Container Platform をインストールします。
$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openstack/openshift-cluster/install.yml
19.6. 設定変更を既存の OpenShift Container Platform 環境に適用する
マスターおよびノードのすべてのホストで OpenShift Container Platform サービスを起動または再起動し、設定の変更を適用します。「OpenShift Container Platform サービスの再起動」を参照してください。
# master-restart api # master-restart controllers # systemctl restart atomic-openshift-node
クラウドプロバイダーを使用しない状態から、使用するように切り替えると、エラーメッセージが表示されます。クラウドプロバイダーを追加すると、ノードが hostname を externalID
として使用する (クラウドプロバイダーが使用されていなかった場合のケース) 代わりに、クラウドプロバイダーの instance-id
(クラウドプロバイダーによって指定される) の使用に切り替えるため、ノードの削除が試みられます。この問題を解決するには、以下を実行します。
- CLI にクラスター管理者としてログインします。
既存のノードラベルをチェックし、これらをバックアップします。
$ oc describe node <node_name> | grep -Poz '(?s)Labels.*\n.*(?=Taints)'
ノードを削除します。
$ oc delete node <node_name>
各ノードホストで OpenShift Container Platform サービスを再起動します。
# systemctl restart atomic-openshift-node
- 以前に使用していた各ノードのラベルを再度追加します。
19.6.1. 既存の OpenShift 環境での OpenStack 変数の設定
必要な OpenStack 変数を設定するには、OpenShift Container Platform のマスターとノード両方のすべてのホストにて、以下の内容で /etc/cloud.conf を変更します。
[Global] auth-url = <OS_AUTH_URL> username = <OS_USERNAME> password = <password> domain-id = <OS_USER_DOMAIN_ID> tenant-id = <OS_TENANT_ID> region = <OS_REGION_NAME> [LoadBalancer] subnet-id = <UUID of the load balancer subnet>
OS_
変数の値については OpenStack の管理者にお問い合わせください。この値は通常 OpenStack の設定で使用されます。
19.6.2. 動的に作成した OpenStack PV のゾーンラベルの設定
管理者は、動的に作成された OpenStack PV のゾーンラベルを設定できます。このオプションは、OpenStack Cinder ゾーン名がコンピュートゾーン名などに一致しない場合、Cinder ゾーンが 1 つだけで、コンピュートゾーンが多数ある場合に有用です。管理者は、動的に Cinder ボリュームを作成してから、ラベルをチェックできます。
PV のゾーンラベルを表示します。
# oc get pv --show-labels NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS pvc-1faa6f93-64ac-11e8-930c-fa163e3c373c 1Gi RWO Delete Bound openshift-node/pvc1 standard 12s failure-domain.beta.kubernetes.io/zone=nova
デフォルトの設定が有効になっています。oc get pv --show-labels
コマンドは、failure-domain.beta.kubernetes.io/zone=nova
ラベルを返します。
ゾーンラベルを無効にするには、cloud.conf ファイルに以下を追加して更新します。
[BlockStorage] ignore-volume-az = yes
マスターサービスの再起動後に作成された PV にはゾーンラベルがありません。