第6章 OpenShift Container Platform のインストール
OpenShift Container Platform クラスターをインストールするには、一連の Ansible Playbook を実行します。
Ansible Playbook を --tags または --check オプションを使用して実行することを、Red Hat ではサポートしていません。
OpenShift Container Platform をスタンドアロンレジストリーとして インストールするには、スタンドアロンレジストリーのインストール を参照してください。
6.1. 前提条件
OpenShift Container Platform をインストールする前に、クラスターホストを準備します。
- システムおよび環境の要件 を確認します。
- クラスターが大規模な場合は、インストールタイミングについての提案について、Scaling and Performance Guide を参照してください。
- ホストを準備します。このプロセスには、コンポーネントのタイプ別にシステムおよび環境の要件を確認すること、docker サービスをインストールして設定すること、および Ansible バージョン 2.6 以降をインストールすることが含まれます。インストール Playbook を実行するには、Ansible をインストールする必要があります。
- 環境および OpenShift Container Plat クラスター設定を定義するには、インベントリーファイルを設定 します。初期インストールおよび以降のクラスターアップグレードのいずれもこのインベントリーファイルに基づいて実行されます。
- OpenShift Container Platform を Red Hat Enterprise Linux にインストールしている場合は、RPM またはシステムコンテナー のインストール方式を使用するかどうかを決定します。システムコンテナー方式は RHEL Atomic Host システムに必要です。
6.1.1. RPM ベースのインストーラーの実行
RPM ベースのインストーラーは、RPM パッケージでインストールされた Ansible を使用し、ローカルホストで使用可能な Playbook と設定ファイルを実行します。
OpenShift Ansible Playbook は nohup で実行しないでください。Playbook で nohup を使用すると、ファイル記述子が作成され、ファイルが閉じなくなります。その結果、システムでファイルをさらに開けなくなり、Playbook が失敗します。
RPM ベースのインストーラーを実行するには、以下の手順を実行します。
Playbook ディレクトリーに切り替え、prerequisites.yml Playbook を実行します。この Playbook は必要なソフトウェアパッケージをインストールし (ある場合)、コンテナーランタイムを変更します。コンテナーランタイムを設定する必要がない限り、この Playbook はクラスターの初回のデプロイ前に 1 度のみ実行します。
$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook [-i /path/to/inventory] \ 1 playbooks/prerequisites.yml- 1
- インベントリーファイルが /etc/ansible/hosts ディレクトリーにない場合、
-iおよびインベントリーファイルのパスを指定します。
Playbook ディレクトリーに切り替え、deploy_cluster.yml Playbook を実行してクラスターインストールを開始します。
$ cd /usr/share/ansible/openshift-ansible $ ansible-playbook [-i /path/to/inventory] \ 1 playbooks/deploy_cluster.yml- 1
- インベントリーファイルが /etc/ansible/hosts ディレクトリーにない場合、
-iおよびインベントリーファイルのパスを指定します。
. インストールが正常に完了した場合は、インストールを確認します。 インストールが失敗した場合は、インストールを再試行します。
6.1.2. コンテナー化インストーラーの実行
openshift3/ose-ansible イメージは、 OpenShift Container Platform インストーラーのコンテナー化バージョンです。このインストーラーイメージは、RPM ベースのインストーラーと同じ機能を提供しますが、ホストに直接インストールされるのではなく、そのすべての依存関係を提供するコンテナー化環境で実行されます。この使用にあたっての唯一の要件は、コンテナーを実行できることになります。
6.1.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.redhat.io/openshift3/ose-ansible:v3.11- 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.redhat.io/openshift3/ose-ansible:v3.11- 1
- ローカルホスト上にインベントリーファイルの場所を指定します。
このコマンドは、指定されるインベントリーファイルと
rootユーザーの SSH 設定を使用してクラスターインストールを開始します。出力のログを端末に記録し、さらに /var/log/ansible.log ファイルに保存します。このコマンドの初回実行時に、イメージは OSTree ストレージ (システムコンテナーは docker デーモンストレージではなくこのストレージを使用します) にインポートされます。後続の実行では、保存されたイメージが再利用されます。何らかの理由でインストールが失敗した場合は、インストーラーを再実行する前に 既知の問題 に目を通し、特定の指示や回避策がないかどうか確認してください。
6.1.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.redhat.io/openshift3/ose-ansible:v3.116.1.2.3. インストーラーをコンテナーとして実行する
インストーラーイメージは、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.redhat.io/openshift3/ose-ansible:v3.11
- 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 を 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は、openshift-ansible コンテンツのトップレベルのディレクトリーからの相対パスとして実行する Playbook を指定します。この例では、前提条件の Playbook を指定します。また、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.redhat.io/openshift3/ose-ansible:v3.11
6.1.2.4. OpenStack インストール Playbook の実行
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.1.3. インストール Playbook について
インストーラーはモジュール化された Playbook を使用します。そのため、管理者は必要に応じて特定のコンポーネントをインストールできます。ロールと Playbook を分けることで、アドホックな管理タスクをより適切にターゲット設定できます。 その結果、インストール時の制御レベルが強化され、時間の節約が可能になります。
メインのインストール Playbook である /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.ymlは、一連の個別コンポーネント Playbook を特定の順序で実行します。実行の最後に、インストーラーから完了したフェーズが報告されます。 インストールが失敗した場合は、そのフェーズが失敗したかについて Ansible の実行エラーと共に画面に表示されます。
RHEL Atomic Host は OpenShift Container Platform サービスをシステムコンテナーとして実行するためにサポートされていますが、このインストール方式では RHEL Atomic Host で利用できない Ansible を使用します。そのため、RPM ベースのインストーラーは RHEL 7 システムから実行される必要があります。インストールを開始するホストは OpenShift Container Platform クラスターに組み込まれる必要はありませんが、組み込みは可能です。または、インストーラーのコンテナー化バージョン を、RHEL Atomic Host システムから実行できるシステムコンテナーとして使用することもできます。
