23- 第7章：OpenShiftインストール-1：Ansibleの用意の説明

type

status

date

slug

summary

OpenShift コンテナプラットフォームのインストール

目標

OpenShiftをインストールし、クラスターを構成する。

目的

インストールのためにサーバーを準備する。

インストール手順を実行して、OpenShiftクラスターを構築および構成する。

インストール後の作業を実行し、クラスターの構成を確認する。

セクション

インストールのためのサーバー準備（ガイド付き演習）

Red Hat OpenShift Container Platformのインストール（ガイド付き演習）

インストール後の作業実行（ガイド付き演習）

ラボ

なし

インストールの準備

目標

このセクションが終了した時点で、受講者はインストールのためにサーバーを準備できるようになります。

インストール概要

Red Hat OpenShift Container Platformは、RPMパッケージとコンテナイメージの組み合わせで提供されます。

RPMパッケージはRed Hatの標準リポジトリ（Yumリポジトリ）からサブスクリプションマネージャを使用してダウンロードされ、コンテナイメージはRed Hatのプライベートコンテナレジストリから取得されます。

インストールの方法

OpenShiftのインストールには2つの方法があります：

クイックインストール（Quick Installation）：シンプルなクラスター設定に使用されます。少数の質問に答えることでインストールが始まります。

高度なインストール（Advanced Installation）：複雑なインストールに使用され、Ansible Playbooksを用いて自動化します。

OpenShift 3.9以降、クイックインストール方式は廃止され、高度なインストール方式が推奨されるようになりました。このコースでは高度なインストール方式を使用します。

Ansibleの役割

Ansibleはオープンソースの自動化プラットフォームで、複数のサーバーを一貫した方法でカスタマイズおよび構成するために使用されます。Ansible Playbooksは、サーバーの望ましい構成を宣言するために使用され、サーバーが宣言された状態にない場合に構成が調整されます。Ansibleは「冪等性（idempotence）」を持ち、何度実行しても最終的な構成が変わりません。

OpenShiftのインストールにはAnsible Playbooksとロールが使用され、これらはatomic-openshift-utilsパッケージに含まれています。

インストール前の準備

OpenShiftをインストールするには、クラスターのホストサーバーを準備する必要があります。インストールが始まる前に以下の準備を行います：

パスワードレスSSHの設定：リモートの全てのマシンにおいて、ユーザーアカウントのパスワードなしSSH接続を設定します。また、リモートユーザーがrootでない場合、そのユーザーにはsudo権限を設定します。

通信確認：マスターサーバーとノードサーバー間で通信ができることを確認します。pingコマンドを使用して、ホスト間の通信ができるかどうかを確認します。

ワイルドカードDNSゾーンの設定： OpenShiftルーターコンポーネントが動作するノードのIPアドレスに解決するワイルドカードDNSゾーンを設定する必要があります。pingやdigコマンドで確認します。

💡

ワイルドカードDNSゾーンとは、特定のドメインに対するすべてのサブドメインを一括して指定できるDNSの設定です。たとえば、*.example.comというワイルドカードDNSゾーンを設定すると、foo.example.comやbar.example.comなど、example.comのすべてのサブドメインに対して同じIPアドレスやサービスを割り当てることができます。

OpenShiftのようなクラスタ環境では、動的に増減するサービスに対応するため、ワイルドカードDNSを使って、サブドメインをすべて一つのIPアドレス（通常はルーターのIPアドレス）に解決させることがあります。これにより、個別にDNSレコードを管理する必要がなくなり、運用が簡便になります。

サーバーの準備：サーバーはRed Hat Enterprise Linux 7.3、7.4、または7.5である必要があります。各ホストはRed Hat Subscription Management（RHSM）を使用して登録され、OpenShift Container Platformのサブスクリプションに紐付けられます。

必須リポジトリの有効化：必要なリポジトリが有効になっていることを確認します。rhel-7-server-rpms以外にも、rhel-7-server-extras-rpmsやrhel-7-server-ansible-2.4-rpmsなどを有効にします。

Ansibleのインストール

リポジトリの有効化： subscription-managerコマンドを使用して、Ansibleのリポジトリを有効化します。

Ansibleのインストール：リポジトリを有効化した後、yumコマンドを使ってAnsibleをインストールします。

Ansible Playbooksの使用

Ansible Playbooksは、構成タスクを自動化するために使用されます。PlaybookはYAML形式で書かれ、複数のプレイ（tasksの集まり）を含みます。各プレイは指定されたホストグループに対してタスクを実行します。

Ansible Playbookの例：

最初のプレイ「Install a File」では、workstationsホストグループの各サーバーに対して/tmp/sample.txtというファイルをコピーします。

2番目のプレイ「Hello OpenShift Enterprise v3.x」では、OSEv3ホストグループのサーバーにhelloロールを適用します。

Ansibleインベントリファイル

インベントリファイルは、実行するプレイブックに関連するホストグループを定義します。以下のように、各ホストグループを定義し、それぞれのホストに必要な設定を行います。

ワークステーションホストグループの定義

workstations というホストグループを定義する。

このホストグループには workstation.lab.example.com という 1 台のホストが含まれる。

ホスト変数の定義

ホストごとに変数（ホスト変数）を定義できる。

ホスト変数の値は、同じ名前のグループ変数よりも優先される。

例として、master.lab.example.com の hello_message 変数の値は "I am an OSEv3 master." となる。

ホストグループの入れ子構造

ホストグループは、他のホストグループを含むことができる。

ホストグループ名に :children を付けると、その後のリストにあるグループがメンバーとなる。

例えば、OSEv3 グループには、指定された 4 つのホストグループのいずれかに所属するホストが含まれる。

グループ変数の定義

ホストグループ名に :vars を付けると、その後のリストがグループ変数として定義される。

グループに属するすべてのホストに、この変数が適用される。

例えば、ある Playbook の hello ロールが hello_message 変数を使用する場合、OSEv3 グループに属する全ホストでこの変数を定義する必要がある。

Ansible Playbook の実行

このクラスでは、関連する Playbook のファイルはプロジェクトディレクトリ内に整理されています。シンプルな Playbook プロジェクトには、次のようなファイルやディレクトリが含まれます：

インベントリファイル

playbooks ディレクトリ（Playbook の数が少ない場合は省略可能）

ansible.cfg ファイル（Ansible のコマンドラインツールの動作をカスタマイズするための設定ファイル）

SSH の設定を定義
Playbook のデフォルトのインベントリファイルを指定

このクラスでは、ansible.cfg ファイルは次のような設定になっています：

この設定により、Ansible は各タスクの実行時に SSH を使用して student ユーザーで接続し、その後 root ユーザーに昇格 します。

また、インベントリファイルは ansible.cfg と同じディレクトリにある inventory ファイルを使用します。

Playbook の実行方法

このプロジェクト構成では、Playbook の実行が簡単になります。

ターミナルでプロジェクトのルートディレクトリに移動し、以下のコマンドを実行すると Playbook が実行されます：

異なるインベントリファイルを使用して Playbook を実行する場合 は、-i オプションを指定します：

環境の準備

Playbook を実行する前に、以下の条件を満たしていることを確認してください：

パスワードなしの SSH 接続が設定されていること

すべてのリモートマシンのユーザーアカウントで、パスワードなしで SSH 接続できるように設定する必要があります。
リモートユーザーが root ではない場合、パスワードなしで sudo が実行できるように権限を付与する必要があります。
クラス環境では、student ユーザーがこの要件を満たしています。

マスターとノード間で通信できること

マスターとノードが相互に通信できることを確認してください。
ping コマンドを使用すると、接続が可能かどうかをテストできます：

このようにして、環境を適切に準備したうえで Ansible Playbook を実行できます。

ワイルドカード DNS ゾーンの設定と OpenShift の事前準備

ワイルドカード DNS ゾーンの設定

OpenShift のルーターコンポーネントが動作するノードの IP アドレスに、ワイルドカード DNS ゾーンが解決される必要があります。

これを確認するには、ping または dig コマンドを使用し、ドメイン内に存在しないホスト名を指定して実行します。

例えば、クラス環境では apps.lab.example.com というワイルドカードドメインが OpenShift 上で稼働するすべてのアプリケーションに使用されます。

ワイルドカード DNS ゾーンの設定について

RHCSA (Red Hat Certified System Administrator) または同等のスキルを持つシステム管理者であれば、サーバーの設定を行い、ほとんどの要件を満たすことができます。
ただし、ワイルドカード DNS ゾーンの設定には、DNS サーバー管理に関する高度な知識が必要なため、経験豊富なシステム管理者の支援が必要になる可能性があります。
OpenShift のルーターは OpenShift ノード上で動作するため、適切なノードの IP アドレスで DNS を設定する計画を立てる必要があります。