27- 第7章：OpenShiftインストール-5：インストール後タスク実行の説明

type

Post

status

Published

date

Feb 20, 2025

slug

summary

インストール後のタスク実行

目的

このセクションを完了した後、学生はインストール後のタスクを実行し、OpenShiftクラスターのインストールを確認できるようになります。

概要

Red Hat OpenShift Container Platformをインストールした後、すべてのOpenShiftコンポーネントをテストして確認する必要があります。サンプルコンテナイメージからポッドを単に起動するだけでは不十分です。なぜなら、これではOpenShiftビルダー、デプロイヤー、ルーター、内部レジストリを使用していないからです。OpenShiftインストールを検証するためには、以下の手順を実行します：

すべてのOpenShiftノードのステータスを確認

すべてのノードが「Ready」ステータスであるべきです。

OpenShiftレジストリおよびルーターポッドのステータスを確認

すべてのポッドが「Running」ステータスであるべきです。

OpenShiftクラスターからソースを使ってアプリケーションをビルド

OpenShiftはビルド結果からコンテナイメージを生成し、そのイメージからポッドを起動します。これにより、クラスターが内部レジストリからコンテナをプルし、プッシュできることが確認できます。また、アプリケーションが適切にスケジュールされ、OpenShiftノードにデプロイされることもテストします。

アプリケーションに外部からアクセスできるようにルートを作成

これにより、OpenShiftルーターが動作しており、外部からのリクエストをアプリケーションポッドにルーティングできることが確認できます。

これらの手順は、ocコマンドまたはOpenShift Webコンソールを使用して実行できます。このセクションでは、検証を行うために必要な最小限のコマンドが提供されています。ocコマンドの詳細については、Chapter 11「コマンドの実行」で説明します。

上記のタスクの一部は、クラスター管理者権限が必要です。これらの手順を実行する前に、適切なクラスター権限が付与されたユーザーアカウントを関連付ける必要があります。

クラスター管理者の設定

前のセクションのインストール手順に従うと、adminユーザーアカウントが存在し、OpenShiftクラスターに認証することができます：

ただし、adminユーザーアカウントにはクラスター管理者権限がありません。インストール直後、system:admin ユーザーのみがクラスター管理者権限を持っています。各マスターVMのrootユーザーは、system:admin ユーザーとしてOpenShiftクラスターに認証されます。

system:admin ユーザーとして、以下のコマンドで admin ユーザーに cluster-admin ロールを追加します：

これで、admin ユーザーはクラスター管理コマンドをリモートで実行できるようになります。

警告

cluster-admin ロールは非常に強力で、admin ユーザーにクラスターリソースを破壊したり変更したりする能力を与えます。もし admin アカウントのパスワードが漏洩すると、クラスター全体が危険にさらされることになります。致命的なクラスターダメージを防ぐためには、きめ細かいアクセス制御を実施するべきです。詳細は「第12章アクセス制御」に記載されています。

インストールの検証

admin ユーザーがクラスター管理者権限を持つようになったら、oc login コマンドを使用してクラスターに認証します：

もし以前にログインしていなければ、admin ユーザーのパスワードを入力するよう求められます。もし求められた場合は、インストールプロセスで作成された自己署名証明書を受け入れます。

ノードの状態確認

すべてのOpenShiftノードが「Ready」状態であることを確認するために、oc get nodes コマンドを実行します：

[student@workstation ~]$ oc get nodes

以下のような出力が表示されるはずです：

node1 と node2 が「compute」ノードとしてラベル付けされていることがわかります。これは、インベントリファイルで指定された node-role.kubernetes.io/compute=true ノードラベルの結果です。

ルーターとレジストリの状態確認

oc get pods コマンドを実行して、ルーターとレジストリのポッドが「Running」状態であることを確認します：

[student@workstation ~]$ oc get pods -n default

以下のような出力が表示されるはずです：

注意

レジストリは2種類のポッドをデプロイします。一つはDockerレジストリ用、もう一つはレジストリのイメージをブラウズするためのWebコンソール用です。

簡単に言うと、Dockerレジストリ はコンテナのイメージを保存する場所で、Webコンソール はそのイメージをブラウザを通じて閲覧・管理できるツールです。

OpenShiftでは、レジストリ が2つの異なるポッドをデプロイします：

1つはコンテナイメージを保存するためのポッド。

もう1つは、保存されたコンテナイメージをブラウザを使って簡単に見るためのWebコンソールのポッドです。

アプリケーションのビルド

OpenShiftのアプリケーションと関連するOpenShiftリソースは、OpenShiftプロジェクト内に含まれます。テストアプリケーションをソースコードからビルドするには、新しいプロジェクトが必要です。テストアプリケーションのために「smoke-test」という名前のプロジェクトを作成するには、oc new-projectコマンドを使用します：

このコマンドの出力は、oc new-appコマンドを使ってアプリケーションをビルドする方法を案内します：

oc new-appコマンドは、アプリケーションのビルダーイメージとアプリケーションのソースコードリポジトリURLを指定する必要があります。例えば、Python 3.4のアプリケーションを、http://gitserver.example.com/my-python-appにホストされたソースコードでビルドするには、次のコマンドを使用します：

注意

oc new-appコマンドでは、イメージの指定とソースコードリポジトリの間はチルダ（~）で区切られます。

再度、出力は次に実行すべきコマンドを案内します：

oc new-appコマンドの後に、このコマンドを実行します。これによりビルドプロセスのログを追跡します。このプロセスはソースコードをクローンすることから始まり、最終的にはアプリケーションイメージがOpenShift内部のレジストリにプッシュされます。

oc expose svcコマンドは、OpenShiftクラスター外部のクライアントからアプリケーションにアクセスできるようにします。このコマンドは、oc logs -fコマンドが完了した後に実行します。

公開されたアプリケーションサービスのFQDN（完全修飾ドメイン名）を取得するには、oc get routesコマンドを実行します：

この例では、アプリケーションはhttp://my-python-app-smoketest.apps.lab.example.comで利用できます。このエンドポイントでアプリケーションにアクセスできる場合、OpenShiftクラスターは正しく設定されています。

検証失敗の場合

上記のステップのいずれかが失敗した場合、Chapter 11, Executing Commandsの「トラブルシューティングコマンドの実行」セクションに詳細なトラブルシューティング手順が記載されています。

クラスルーム環境でOpenShiftクラスターのインストールと検証に問題がある場合、まずmaster、node1、node2ホストをリセットしてください。その後、次のコマンドをワークステーションホストで実行して、環境が正しく設定されていることを確認します：