管理ガイド
Red Hat CodeReady Workspaces 2.5 の管理
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージを参照してください。
第1章 CodeReady Workspaces アーキテクチャーの概要
Red Hat CodeReady Workspaces コンポーネントには以下が含まれます。
- 中央のワークスペースコントローラー: OpenShift API でユーザーワークスペースを管理する、常に実行中のサービス。
- ユーザーワークスペース: ユーザーがコーディングを停止する際にコントローラーが停止させるコンテナーベースの IDE。
図1.1 CodeReady Workspaces アーキテクチャーの概要
CodeReady Workspaces が OpenShift クラスターにインストールされる際、ワークスペースコントローラーはデプロイされている唯一のコンポーネントになります。CodeReady Workspaces ワークスペースは、ユーザーがこれをリクエストするとすぐに作成されます。
1.1. CodeReady Workspaces ワークスペースコントローラーについて
1.1.1. CodeReady Workspaces ワークスペースコントローラー
ワークスペースコントローラーは、コンテナーベースの開発環境 (CodeReady Workspaces ワークスペース) を管理します。以下のデプロイメントシナリオを利用できます。
- Single-user: デプロイメントには認証サービスは含まれません。開発環境のセキュリティーは保護されません。この設定に必要なリソースは少なくなります。これは、ローカルインストールにより適しています。
- Multi-user: これはマルチテナント設定です。開発環境のセキュリティーは保護され、この設定ではより多くのリソースが必要になります。クラウドインストールに適しています。
以下の図は、CodeReady Workspaces ワークスペースコントローラーの一部である各種サービスを示しています。RH-SSO および PostgreSQL は、マルチユーザー設定でのみ必要となることに注意してください。
図1.2 CodeReady Workspaces ワークスペースコントローラー
関連資料
1.1.2. CodeReady Workspaces サーバー
CodeReady Workspaces サーバーは、ワークスペースコントローラーの中心となるサービスです。これは HTTP REST API を公開して CodeReady Workspaces ワークスペースを管理し、マルチユーザーモードで CodeReady Workspaces ユーザーを管理する Java Web サービスです。
コンテナーイメージ |
|
1.1.3. CodeReady Workspaces ユーザーダッシュボード
ユーザーダッシュボードは、Red Hat CodeReady Workspaces のランディングページです。これは Angular フロントエンドアプリケーションです。CodeReady Workspaces ユーザーは、ユーザーダッシュボードでブラウザーから CodeReady Workspaces ワークスペースを作成し、起動し、管理します。
コンテナーイメージ |
|
1.1.4. CodeReady Workspaces Devfile レジストリー
CodeReady Workspaces devfile レジストリーは、そのまま使用できるワークスペースを作成するための CodeReady Workspaces スタックの一覧を提供するサービスです。このスタックの一覧は、Dashboard → Create Workspace ウィンドウで使用されます。devfile レジストリーはコンテナーで実行され、ユーザーダッシュボードが接続できる任意の場所にデプロイできます。
devfile レジストリーのカスタマイズに関する詳細は、「devfile レジストリーのカスタマイズ」についてのセクションを参照してください。
コンテナーイメージ |
|
1.1.5. CodeReady Workspaces プラグインレジストリー
CodeReady Workspaces プラグインレジストリーは、CodeReady Workspaces ワークスペースのプラグインおよびエディターの一覧を提供するサービスです。devfile は、CodeReady Workspaces プラグインレジストリーに公開されるプラグインのみを参照します。これはコンテナーで実行され、CodeReady Workspaces サーバーが接続するすべての場所にデプロイできます。
コンテナーイメージ |
|
1.1.6. CodeReady Workspaces および PostgreSQL
PostgreSQL データベースは、マルチユーザーモードで CodeReady Workspaces を設定するための前提条件です。CodeReady Workspaces 管理者は、CodeReady Workspaces を既存の PostgreSQL インスタンスに接続するか、または CodeReady Workspaces デプロイメントで新規の専用 PostgreSQL インスタンスを起動することを選択できます。
CodeReady Workspaces サーバーはデータベースを使用してユーザー設定(Workspaces メタデータ、Git 認証情報) を永続化させます。RH-SSO は、データベースをバックエンドとして使用し、ユーザー情報を永続化させます。
コンテナーイメージ |
|
1.1.7. CodeReady Workspaces および RH-SSO
RH-SSO は、マルチユーザーモードで CodeReady Workspaces を設定するための前提条件です。CodeReady Workspaces 管理者は、CodeReady Workspaces を既存の RH-SSO インスタンスに接続するか、または CodeReady Workspaces デプロイメントで新規の専用 RH-SSO インスタンスを起動することを選択できます。
CodeReady Workspaces サーバーは、OpenID Connect (OIDC) プロバイダーとして RH-SSO を使用して CodeReady Workspaces ユーザーの認証を行い、CodeReady Workspaces リソースへのアクセスのセキュリティーを保護します。
コンテナーイメージ |
|
1.2. CodeReady Workspaces ワークスペースアーキテクチャーについて
1.2.1. CodeReady Workspaces ワークスペースアーキテクチャー
クラスターの CodeReady Workspaces デプロイメントは、CodeReady Workspaces サーバーコンポーネント、ユーザープロファイルおよび設定を保存するデータベース、およびワークスペースをホストする多数の追加のデプロイメントで構成されます。CodeReady Workspaces サーバーは、ワークスペースコンテナーと有効にされたプラグイン、以下のような関連するコンポーネントを含むデプロイメントで構成されるワークスペースの作成をオーケストレーションします。
- ConfigMap
- service
- endpoint
- ingress/route
- Secret
- PV
CodeReady Workspaces ワークスペースは Web アプリケーションです。これは、エディター、言語の自動補完、デバッグツールなどの最新の IDE のすべてのサービスを提供するコンテナーで実行されるマイクロサービスで構成されます。IDE サービスは、OpenShift リソースとして定義されるコンテナーおよびユーザーランタイムアプリケーションにパッケージ化された開発ツールでデプロイされます。
CodeReady Workspaces ワークスペースのプロジェクトのソースコードは、OpenShift PersistentVolume
で永続化されます。マイクロサービスは、ソースコード(IDE サービス、開発ツール) への読み取り/書き込みアクセスを持つコンテナー内で実行され、ランタイムアプリケーションはこの共有ディレクトリーへの読み取り/書き込みアクセスがあります。
以下の図は、CodeReady Workspaces ワークスペースの詳細なコンポーネントを示しています。
図1.3 CodeReady Workspaces ワークスペースコンポーネント
この図では、実行中のワークスペースが 3 つあります。2 つは User A に属し、もう 1 つは User C に属します。4 つ目のワークスペースは、プラグインブローカーがワークスペース設定を検証および完了する場所でプロビジョニングされます。
devfile 形式を使用して、CodeReady Workspaces ワークスペースのツールおよびランタイムアプリケーションを指定します。
1.2.2. CodeReady Workspaces ワークスペースコンポーネント
本セクションでは、CodeReady Workspaces ワークスペースのコンポーネントについて説明します。
1.2.2.1. Che Editor
プラグイン
Che Editor
プラグインは、CodeReady Workspaces ワークスペースプラグインです。これは、ワークスペースでエディターとして使用される Web アプリケーションを定義します。デフォルトの CodeReady Workspaces ワークスペースエディターは Che-Theia です。これは、Visual Studio Code (VS Code) と同様の Web ベースのソースコードエディターです。これには、VS Code 拡張機能をサポートするプラグインシステムがあります。
ソースコード | |
コンテナーイメージ |
|
エンドポイント |
|
1.2.2.2. CodeReady Workspaces ユーザーランタイム
ユーザーランタイムとして終了しないユーザーコンテナーを使用します。コンテナーイメージまたは OpenShift リソースのセットとして定義できるアプリケーションは、CodeReady Workspaces ワークスペースに追加できます。これにより、CodeReady Workspaces ワークスペースでのアプリケーションのテストが容易になります。
CodeReady Workspaces ワークスペースでアプリケーションをテストするには、ワークスペース仕様にステージまたは実稼働環境で使用するアプリケーションの YAML 定義を含めます。これは、12-factor app の開発/実稼働環境のパリティーです。
ユーザーランタイムの例は Node.js、SpringBoot または MongoDB、および MySQL です。
1.2.2.3. CodeReady Workspaces ワークスペース JWT プロキシー
JWT プロキシーは、CodeReady Workspaces ワークスペースサービスの通信のセキュリティーを保護します。CodeReady Workspaces ワークスペース JWT プロキシーは、CodeReady Workspaces サーバーがマルチユーザーモードで設定されている場合のみ、CodeReady Workspaces ワークスペースに含まれます。
HTTP プロキシーは、ワークスペースサービスから CodeReady Workspaces サーバーへの送信要求に署名し、ブラウザーで実行されている IDE クライアントからの受信要求を認証するために使用されます。
ソースコード | |
コンテナーイメージ |
|
1.2.2.4. CodeReady Workspaces プラグインブローカー
プラグインブローカーは、プラグイン meta.yaml
ファイルに関連した特別なサービスです。以下を実行します。
- CodeReady Workspaces サーバーが認識するプラグイン定義を提供するためにすべての情報を収集します。
- ワークスペースプロジェクトで準備の各種アクションを実行する (ダウンロード、ファイルの展開、プロセス設定)。
プラグインブローカーの主な目的は、CodeReady Workspaces がサポートできる実際のプラグインから CodeReady Workspaces プラグイン定義を切り離すことにあります。ブローカーでは、CodeReady Workspaces は CodeReady Workspaces サーバーを更新せずに異なるプラグインをサポートできます。
CodeReady Workspaces サーバーはプラグインブローカーを起動します。プラグインブローカーは、ワークスペースと同じ OpenShift プロジェクトで実行されます。これには、プラグインおよびプロジェクトの永続ボリュームへのアクセスがあります。
プラグインブローカーはコンテナーイメージとして定義されます (例: eclipse/che-plugin-broker
)。プラグインタイプは、起動しているブローカーのタイプを判別します。Che Plugin
および Che Editor
の 2 種類のプラグインがサポートされます。
ソースコード | |
コンテナーイメージ |
|
1.2.3. CodeReady Workspaces ワークスペースの設定
本セクションでは、CodeReady Workspaces ワークスペースのプロビジョニングに影響を与える CodeReady Workspaces サーバーのプロパティーについて説明します。
1.2.3.1. codeready-workspaces ワークスペースのストレージストラテジー
ワークスペース Pod は、ReadWriteOnce アクセスモードで物理的な永続ボリューム (PV) にバインドされる Persistent Volume Claim(永続ボリューム要求、PVC)を使用します。CodeReady Workspaces サーバーがワークスペースに PVC を使用する方法を設定できます。この設定の個別の方法は PVC ストラテジーと呼ばれます。
ストラテジー | 詳細 | 利点 | 不利な点 |
---|---|---|---|
unique | ワークスペースボリュームまたはユーザー定義 PVC ごとに 1 つの PVC | ストレージの分離 | 定義されない数の PV が必要です |
per-workspace (デフォルト) | 1 つのワークスペースに 1 つの PVC | 一意のストラテジーと比較すると、ストレージの管理と制御が容易になります。 | PV 数は不明で、ワークスペース数により異なります。 |
common | 1 つの OpenShift namespace のすべてのワークスペースに 1 つの PVC | ストレージの管理と制御が容易になります。 | PV が ReadWriteMany (RWX) アクセスモードをサポートしない場合、ワークスペースは別の OpenShift namespace になければなりません。 または、1 つの namespace で 2 つ以上のワークスペースを同時に実行することはできません。 namespace ストラテジーの設定方法を参照してください。 |
Red Hat CodeReady Workspaces は、すべての CodeReady Workspaces ワークスペースがユーザーのプロジェクトで動作し、1 つの PVC を共有する場合に、common
PVC ストラテジーを「ユーザーごとに 1 プロジェクト」のプロジェクトストラテジーと共に使用します。
1.2.3.1.1. common
PVC ストラテジー
OpenShift プロジェクト内のすべてのワークスペースは、宣言されたボリュームに以下のようなデータを保存する際に、デフォルトのデータストレージと同じ Persistent Volume Claim(永続ボリューム要求、PVC)を使用します。
- プロジェクト
- ワークスペースログ
- 使用に基づいて定義される追加のボリューム
common
PVC ストラテジーが使用されている場合、ユーザー定義 PVC は無視され、これらのユーザー定義 PVC を参照するボリュームは共通 PVC を参照するボリュームに置き換えられます。このストラテジーでは、すべての CodeReady Workspaces ワークスペースが同じ PVC を使用します。ユーザーが 1 つのワークスペースを実行すると、一度にクラスター内の 1 つのノードにのみバインドします。
対応するコンテナーボリュームのマウントは共通ボリュームにリンクされ、サブパスには <workspace-ID>
または <original-PVC-name>
のプレフィックスが付けられます。詳細は、「サブパスが PVC で使用される方法」を参照してください。
CodeReady Workspaces ボリューム名は、ユーザー定義 PVC の名前と同じです。つまり、マシンがユーザー定義の PVC と同じ名前を持つ CodeReady Workspaces ボリュームを使用するように設定されている場合、それらは共通 PVC で同じ共有フォルダーを使用します。
ワークスペースが削除されると、対応するサブディレクトリー (${ws-id}
) が PV ディレクトリーで削除されます。
common
PVC ストラテジーの使用に関する制限
common
ストラテジーが使用され、ワークスペース PVC アクセスモードが ReadWriteOnce (RWO) の場合、1 つのノードのみが PVC を同時に使用できます。
ノードが複数ある場合には、common
ストラテジーを使用できますが、以下の点を注意してください。
-
ワークスペース PVC アクセスモードを
ReadWriteMany
(RWM)に再設定し、複数のノードがこの PVC を同時に使用できるようにする必要があります。 - 同じプロジェクトの 1 つのワークスペースのみを実行できます。https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/installation_guide/index#running-more-than-one-workspace-at-a-time_crw を参照してください。
common
PVC ストラテジーは、大規模なマルチノードクラスターには適していません。そのため、単一ノードクラスターで使用することが最も適しています。ただし、per-workspace
プロジェクトストラテジーと組み合わせにより、common
PVC ストラテジーは 75 ノードを超えるクラスターで使用できます。このストラテジーで使用する PVC は、1 つのプロジェクトが他のプロジェクトのリソースを使い切る状況を防ぐために、すべてのプロジェクトに対応するのに十分な大きさである必要があります。
1.2.3.1.2. per-workspace
PVC ストラテジー
per-workspace
ストラテジーは、common
PVC ストラテジーに似ています。すべてのワークスペースではなく、すべてのワークスペースのボリュームが以下についてデフォルトのデータストレージと同じ PVC を使用する点が唯一の違いになります。
- プロジェクト
- ワークスペースログ
- ユーザーが定義する追加のボリューム
このストラテジーでは、CodeReady Workspaces は単一の PVC によって割り当てられる割り当てられた PV にワークスペースのデータを保持します。
per-workspace
PVC ストラテジーは、利用可能な PVC ストラテジーの中でも最も汎用的なストラテジーであり、ユーザーの量が多い大規模なマルチノードクラスターの適切なオプションとして機能します。per-workspace
PVC ストラテジーを使用すると、ユーザーは複数のワークスペースを同時に実行できます。これにより、PVC がさらに作成されます。
1.2.3.1.3. unique
PVC ストラテジー
'unique 'PVC ストラテジーを使用する場合、ワークスペースのすべての CodeReady Workspaces ボリュームには独自の PVC があります。つまり、ワークスペース PVC は以下のようになります。
ワークスペースの初回起動時に作成されます。対応するワークスペースが削除されると削除されます。
ユーザー定義の PVC は以下の詳細で作成されます。
- これらは、プロジェクトの他の PVC との名前の競合を防ぐために、生成される名前でプロビジョニングされます。
-
ユーザー定義の PVC を参照するマウントされた物理的な永続ボリュームのサブパスには、
<workspace-ID>
または<PVC-name>
のプレフィックスが付けられます。これにより、同じ PV データ構造が異なる PVC ストラテジーで設定されます。詳細は、「サブパスが PVC で使用される方法」を参照してください。
unique
PVC ストラテジーは、ユーザーの量が少ない大規模なマルチノードクラスターに適しています。このストラテジーはワークスペースの各ボリュームについて別個の PVC で動作するため、さらに多くの PVC が作成されます。
1.2.3.1.4. サブパスが PVC で使用される方法
サブパスは、永続ボリューム (PV) のフォルダー階層を示しています。
/pv0001 /workspaceID1 /workspaceID2 /workspaceIDn /che-logs /projects /<volume1> /<volume2> /<User-defined PVC name 1 | volume 3> ...
ユーザーが devfile でコンポーネントのボリュームを定義すると、同じ名前のボリュームを定義するすべてのコンポーネントは、PV 内の <PV-name>
, <workspace-ID> または `<original-PVC-name>
と同じディレクトリーでサポートされます。各コンポーネントでは、コンテナー内の異なるパスにこの場所をマウントすることができます。
例
common
PVC ストラテジーを使用すると、ユーザー定義の PVC は共通 PVC のサブパスに置き換えられます。ユーザーがボリュームを my-volume
として参照すると、これは /workspace-id/my-volume
サブパスで common-pvc にマウントされます。
1.2.3.2. 永続ボリュームストラテジーを使用した CodeReady Workspaces ワークスペースの設定
永続ボリューム (PV) は、ボリュームをクラスターに追加する仮想ストレージインスタンスとして機能します。
永続ボリューム要求 (PVC)は、以下の CodeReady Workspaces ストレージ設定ストラテジーで利用可能な特定のタイプおよび設定の永続ストレージのプロビジョニング要求です。
- Common
- Per-workspace
- Unique
マウントされた PVC はコンテナーのファイルシステムのフォルダーとして表示されます。
1.2.3.2.1. Operator を使用した PVC ストラテジーの設定
以下のセクションでは、Operator を使用して CodeReady Workspaces サーバーのワークプレースの永続ボリューム要求 (PVC)ストラテジーを設定する方法を説明します。
既存のワークスペースを使用して既存の CodeReady Workspaces クラスターに PVC ストラテジーを再設定することは推奨されません。これを実行すると、データが失われます。
Operator は、カスタムリソースを使用してアプリケーションとそのコンポーネントを管理する OpenShift に対するソフトウェアの拡張機能です。
Operator を使用して CodeReady Workspaces をデプロイする場合は、CheCluster カスタムリソースオブジェクトの YAML ファイルの spec.storage.pvcStrategy
プロパティーを変更して、目的のストラテジーを設定します。
前提条件
-
oc
ツールが利用できる。
手順
以下の手順は、OpenShift コマンドラインツール「oc」で使用できます。
CheCluster YAML ファイルに変更を加えるには、以下のいずれかを選択します。
oc apply
コマンドを実行して新規クラスターを作成します。以下は例になります。$ oc apply -f <my-cluster.yaml>
oc patch
コマンドを実行して、すでに実行中のクラスターの YAML ファイルプロパティーを更新します。以下は例になります。$ oc patch checluster codeready-workspaces --type=json \ -p '[{"op": "replace", "path": "/spec/storage/pvcStrategy", "value": "<per-workspace>"}]'
使用されるストラテジーに応じて、上記の例の <per-workspace>
オプションを unique
または common
に置き換えます。
1.2.3.3. ワークスペース OpenShift プロジェクト設定
新規ワークスペース Pod がデプロイされる OpenShift プロジェクトは、CodeReady Workspaces サーバー設定によって異なります。デフォルトで、すべてのワークスペースは個別の OpenShift プロジェクトにデプロイされますが、ユーザーは CodeReady Workspaces サーバーを 1 つの特定の OpenShift プロジェクトにすべてのワークスペースをデプロイするように設定できます。OpenShift プロジェクトの名前は CodeReady Workspaces サーバー設定プロパティーとして指定される必要があり、実行時に変更することはできません。
1.2.4. CodeReady Workspaces ワークスペース作成フロー
以下は、CodeReady Workspaces ワークスペースの作成フローです。
ユーザーは、以下によって定義された CodeReady Workspaces ワークスペースを起動します。
- エディター (デフォルトは Che-Theia)
- プラグインの一覧(Java や OpenShift ツールなど)
- ランタイムアプリケーションの一覧
- CodeReady Workspaces サーバーは、プラグインレジストリーからエディターおよびプラグインメタデータを取得します。
- すべてのプラグインタイプに対して、CodeReady Workspaces サーバーは特定のプラグインブローカーを起動します。
CodeReady Workspaces プラグインブローカーは、プラグインのメタデータを Che Plugin 定義に変換します。これは以下の手順を実行します。
- プラグインをダウンロードし、そのコンテンツを展開します。
-
プラグインの
meta.yaml
ファイルを処理し、これを Che Plugin の形式で CodeReady Workspaces サーバーに戻します。
- CodeReady Workspaces サーバーはエディターとプラグインサイドカーを起動します。
- エディターは、プラグインの永続ボリュームからプラグインを読み込みます。
第2章 CodeReady Workspaces リソース要件の計算
本セクションでは、Red Hat CodeReady Workspaces の実行に必要なメモリーや CPU などのリソースを計算する方法を説明します。
CodeReady Workspaces 中央コントローラーとユーザーワークスペースはいずれもコンテナーのセットで構成されます。これらのコンテナーは、CPU および RAM の制限および要求の点でリソース消費に貢献します。
2.1. コントローラーの要件
Workspace コントローラーは、5 つの異なるコンテナーで実行される 5 つのサービスのセットで構成されます。以下の表は、これらの各サービスのデフォルトのリソース要件を示しています。
表2.1 ControllerServices
Pod | コンテナー名 | デフォルトのメモリー制限 | デフォルトのメモリー要求 |
---|---|---|---|
CodeReady Workspaces サーバーおよびダッシュボード | che | 1 GiB | 512 MiB |
PostgreSQL | postgres | 1 GiB | 512 MiB |
RH-SSO | keycloak | 2 GiB | 512 MiB |
devfile レジストリー | che-devfile-registry | 256 MiB | 16 MiB |
プラグインレジストリー | che-plugin-registry | 256 MiB | 16 MiB |
これらのデフォルト値は、CodeReady Workspaces Workspace Controller が小規模な CodeReady Workspaces ワークスペースを管理する場合に問題なく使用できます。大規模なデプロイメントの場合は、メモリー制限を増やします。デフォルトの要求および制限を上書きする方法については、https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/installation_guide/index#advanced-configuration-options-for-the-codeready-workspaces-server-component_crw の記事を参照してください。たとえば https://che.openshift.io で実行される CodeReady Workspaces のホストバージョンは 1 GB のメモリーを使用します。
2.2. ワークスペースの要件
本セクションでは、ワークスペースに必要なリソースを計算する方法を説明します。これは、このワークスペースの各コンポーネントに必要なリソースの合計です。
以下の例は、適切な計算の必要性について示しています。
- アクティブな 10 のプラグインがあるワークスペースには、これより少ないプラグインを持つ同じワークスペースよりも多くのリソースが必要になります。
- 標準の Java ワークスペースでは、ビルド、テスト、およびアプリケーションのデバッグにより多くのリソースが必要になるため、標準の Node.js ワークスペースよりも多くのリソースが必要になります。
手順
-
https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw の
components
セクションに明示的に指定されるワークスペースコンポーネントを特定します。 暗黙的なワークスペースコンポーネントを特定します。
-
CodeReady Workspaces はデフォルトの
cheEditor
:che-theia
と、コマンドの実行を許可するchePlugin
(che-machine-exec-plugin
)を暗黙的に読み込みます。CodeReady Workspaces がマルチユーザーモードで実行されている場合は、cheEditor
コンポーネントを読み込みます。 -
CodeReady Workspaces がマルチユーザーモードで実行されている場合は、
JWT Proxy
コンポーネントを読み込みます。JWT プロキシーは、ワークスペースコンポーネントの外部通信の認証および認可を行います。
-
CodeReady Workspaces はデフォルトの
各コンポーネントの要件を計算します。
デフォルト値:
以下の表は、すべてのワークスペースコンポーネントのデフォルト要件を示しています。また、デフォルトのクラスター全体を変更できるように対応する CodeReady Workspaces サーバープのロパティーも表示します。
表2.2 タイプ別のワークスペースコンポーネントのデフォルト要件
コンポーネントのタイプ CodeReady Workspaces サーバープロパティー デフォルトのメモリー制限 デフォルトのメモリー要求 chePlugin
che.workspace.sidecar.default_memory_limit_mb
128 MiB
128 MiB
cheEditor
che.workspace.sidecar.default_memory_limit_mb
128 MiB
128 MiB
kubernetes
、openshift
、dockerimage
che.workspace.default_memory_limit_mb
,che.workspace.default_memory_request_mb
1 Gi
512 MiB
JWT プロキシー
che.server.secure_exposer.jwtproxy.memory_limit
128 MiB
128 MiB
chePlugins
およびcheEditors
コンポーネントのカスタム要件:カスタムメモリー制限および要求:
存在する場合、
meta.yaml
ファイルのcontainers
セクションのmemoryLimit
およびmemoryRequest
属性は、chePlugins
またはcheEditors
コンポーネントのメモリー制限を定義します。CodeReady Workspaces は、明示的に指定されていない場合に、メモリー制限に一致するようにメモリー要求を自動的に設定します。例2.1
chePlugin
che-incubator/typescript/latest
meta.yaml
仕様セクション:spec: containers: - image: docker.io/eclipse/che-remote-plugin-node:next name: vscode-typescript memoryLimit: 512Mi memoryRequest: 256Mi
これにより、コンテナーには以下のメモリー制限および要求が設定されます。
メモリー制限
512 MiB
メモリー要求
256 MiB
注記chePlugin
のmeta.yaml
ファイルの検索方法コミュニティープラグインは、
v3/plugins/${organization}/${name}/${version}/
フォルダーの che-plugin-registry GitHub リポジトリーで利用できます。コミュニティー以外またはカスタマイズされたプラグインの場合、
meta.yaml
ファイルは${pluginRegistryEndpoint}/v3/plugins/${organization}/${name}/${version}/meta.yaml
のローカルの OpenShift クラスターで利用できます。カスタム CPU の制限および要求:
CodeReady Workspaces は、デフォルトで CPU の制限および要求を設定しません。ただし、
meta.yaml
ファイルまたは devfile でchePlugin
およびcheEditor
タイプの CPU 制限を、メモリー制限と同じ様に設定できます。例2.2
chePlugin
che-incubator/typescript/latest
meta.yaml
仕様セクション:spec: containers: - image: docker.io/eclipse/che-remote-plugin-node:next name: vscode-typescript cpuLimit: 2000m cpuRequest: 500m
これにより、コンテナーに以下の CPU 制限および要求が設定されます。
CPU 制限
2 コア
CPU 要求
0.5 コア
CPU 制限および要求をグローバルに設定するには、以下の専用の環境変数を使用します。
|
|
|
|
OpenShift プロジェクトの LimitRange
オブジェクトは、クラスター管理者によって設定される CPU 制限および要求のデフォルト値を指定できることに注意してください。リソースのオーバーランによる開始エラーを防ぐために、アプリケーションやワークスペースレベルでの制限がこれらの設定に準拠している必要があります。
dockerimage
コンポーネントのカスタム要件:存在する場合、devfileの
memoryLimit
属性とmemoryRequest
属性は、dockerimage
コンテナのメモリ制限を定義します。CodeReady Workspaces は、明示的に指定されていない場合に、メモリー制限に一致するようにメモリー要求を自動的に設定します。- alias: maven type: dockerimage image: eclipse/maven-jdk8:latest memoryLimit: 1536M
kubernetes
またはopenshift
コンポーネントのカスタム要件:参照されるマニフェストは、メモリー要件および制限を定義できます。
- 以前に計算された要件をすべて追加します。
2.3. ワークスペースの例
本セクションでは、CodeReady Workspaces ワークスペースの例を説明します。
以下の devfile は、CodeReady Workspaces ワークスペースを定義します。
apiVersion: 1.0.0 metadata: generateName: guestbook-nodejs-sample- projects: - name: guestbook-nodejs-sample source: type: git location: "https://github.com/l0rd/nodejs-sample" components: - type: chePlugin id: che-incubator/typescript/latest - type: kubernetes alias: guestbook-frontend reference: https://raw.githubusercontent.com/l0rd/nodejs-sample/master/kubernetes-manifests/guestbook-frontend.deployment.yaml mountSources: true entrypoints: - command: ['sleep'] args: ['infinity']
この表は、各ワークスペースコンポーネントのメモリー要件を示しています。
表2.3 ワークスペースメモリー要件および制限の合計
Pod | コンテナー名 | デフォルトのメモリー制限 | デフォルトのメモリー要求 |
---|---|---|---|
ワークスペース |
theia-ide(デフォルトの | 512 MiB | 512 MiB |
ワークスペース |
machine-exec (デフォルトの | 128 MiB | 128 MiB |
ワークスペース |
vscode-typescript ( | 512 MiB | 512 MiB |
ワークスペース |
frontend ( | 1 GiB | 512 MiB |
JWT プロキシー | verifier | 128 MiB | 128 MiB |
合計 | 2.25 GiB | 1.75 GiB |
-
devfile に含まれていない場合でも、
theia-ide
およびmachine-exec
コンポーネントは暗黙的にワークスペースに追加されます。 -
machine-exec
で必要なリソースは、chePlugin
のデフォルトです。 -
theia-ide
のリソースは、cheEditor
meta.yaml
でmemoryLimit
が 512 MiB に設定されます。 -
Typescript VS Code 拡張は、デフォルトのメモリー制限もオーバーライドします。
meta.yaml
ファイルでは、制限は明示的に 512 MiB に指定されます。 -
CodeReady Workspaces は、
kubernetes
コンポーネントタイプのデフォルト(メモリー制限 1 GiB とメモリー要求の 512 MiB) を適用します。これは、kubernetes
コンポーネントが、リソースの制限や要求のないコンテナー仕様を持つDeployment
マニフェストを参照するためです。 - JWT コンテナーには 128 MiB のメモリーが必要です。
すべての内容を追加すると、制限が 2.25 GiB の 1.75 GiB のメモリー要求が設定されます。
関連資料
- 1章CodeReady Workspaces アーキテクチャーの概要
- Kubernetes コンピュートリソース管理に関するドキュメント
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/installation_guide/index#configuring-the-codeready-workspaces-installation_crw
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/installation_guide/index#advanced-configuration-options-for-the-codeready-workspaces-server-component_crw
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/end-user_guide/index#a-minimal-devfile_crw
- 「ユーザーの認証」
- che-plugin-registry GitHub リポジトリー
第3章 レジストリーのカスタマイズ
本章では、CodeReady Workspaces のカスタムレジストリーをビルドし、実行する方法を説明します。
3.1. CodeReady Workspaces レジストリーについて
CodeReady Workspaces は、プラグインレジストリーと devfile レジストリーの 2 つのレジストリーを使用します。これらは、CodeReady Workspaces プラグインおよび devfile のメタデータを公開する静的な Web サイトです。オフラインモードでビルドする場合には、アーティファクトも含まれます。
devfile およびプラグインレジストリーは、2 つの Pod で実行されます。これらのデプロイメントは、CodeReady Workspaces インストールに含まれます。
devfile およびプラグインレジストリー
- devfile レジストリー
-
devfile レジストリーは、CodeReady Workspaces スタックの定義を保持します。スタックは、Create Workspace を選択すると CodeReady Workspaces ユーザーダッシュボードで利用できます。これには、サンプルプロジェクトを含む CodeReady Workspaces の技術的なスタックのサンプルの一覧が含まれます。オフラインモードでビルドする場合には、
zip
ファイルとして devfile で参照されるサンプルプロジェクトがすべて含まれます。 - プラグインレジストリー
- プラグインレジストリーを使用すると、CodeReady Workspaces の同じインスタンスのすべてのユーザーにプラグイン定義を共有できます。オフラインモードでビルドすると、すべてのプラグインまたは拡張アーティファクトも含まれます。
3.2. カスタムレジストリーイメージのビルド
本セクションでは、カスタム devfile およびプラグインレジストリーイメージを含むイメージをビルドする方法を説明します。この手順では、新規の devfile およびプラグインを追加する方法を説明します。devfile レジストリーイメージには、devfile で参照されるすべてのサンプルプロジェクトが含まれます。プラグインレジストリーイメージには、プラグインまたは拡張機能のメタデータが含まれます。
手順
devfile レジストリーリポジトリーのクローンを作成し、デプロイするバージョンをチェックアウトします。
$ git clone git@github.com:redhat-developer/codeready-workspaces.git $ cd codeready-workspaces $ git checkout crw-2.5-rhel-8
./dependencies/che-devfile-registry/devfiles/
ディレクトリーで、サブディレクトリー<devfile-name>/
を作成し、devfile.yaml
ファイルおよびmeta.yaml
ファイルを追加します。devfile のファイル編成
./dependencies/che-devfile-registry/devfiles/ └── <devfile-name> ├── devfile.yaml └── meta.yaml
-
devfile.yaml
ファイルに有効なコンテンツを追加します。devfile 形式の詳細については、https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw を参照してください。 meta.yaml
ファイルが以下の構造に準拠していることを確認します。表3.1 devfile
meta.yaml
のパラメーター属性 詳細 description
ユーザーダッシュボードに表示される説明。
displayName
ユーザーダッシュボードに表示される名前。
globalMemoryLimit
devfile が起動するすべてのコンポーネントによって消費されることが予想されるメモリーの合計。この数字はユーザーダッシュボードに表示されます。これは情報を示唆するように提供されますが、CodeReady Workspaces サーバーでは考慮されません。
icon
ユーザーダッシュボードに表示される
.svg
ファイルへのリンクtags
タグの一覧。タグには通常、スタックに含まれるツールが含まれます。
例3.1 devfile の例
meta.yaml
displayName: Rust description: Rust Stack with Rust 1.39 tags: ["Rust"] icon: https://www.eclipse.org/che/images/logo-eclipseche.svg globalMemoryLimit: 1686Mi
./dependencies/che-devfile-registry/devfiles/
ディレクトリーで、サブディレクトリー<devfile-name>/
を作成し、devfile.yaml
ファイルおよびmeta.yaml
ファイルを追加します。devfile のファイル編成
./dependencies/che-devfile-registry/devfiles/ └── <devfile-name> ├── devfile.yaml └── meta.yaml
-
devfile.yaml
ファイルに有効なコンテンツを追加します。devfile 形式の詳細については、https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw を参照してください。 meta.yaml
ファイルが以下の構造に準拠していることを確認します。表3.2 devfile
meta.yaml
のパラメーター属性 詳細 description
ユーザーダッシュボードに表示される説明。
displayName
ユーザーダッシュボードに表示される名前。
globalMemoryLimit
devfile が起動するすべてのコンポーネントによって消費されることが予想されるメモリーの合計。この数字はユーザーダッシュボードに表示されます。これは情報を示唆するように提供されますが、CodeReady Workspaces サーバーでは考慮されません。
icon
ユーザーダッシュボードに表示される
.svg
ファイルへのリンクtags
タグの一覧。タグには通常、スタックに含まれるツールが含まれます。
例3.2 devfile の例
meta.yaml
displayName: Rust description: Rust Stack with Rust 1.39 tags: ["Rust"] icon: https://www.eclipse.org/che/images/logo-eclipseche.svg globalMemoryLimit: 1686Mi
カスタム devfile レジストリーイメージをビルドします。
$ cd dependencies/che-devfile-registry $ ./build.sh --organization <my-org> \ --registry <my-registry> \ --tag <my-tag> \ --latest-only $ cd ../../dependencies/che-devfile-registry $ ./build.sh --organization <my-org> \ --registry <my-registry> \ --tag <my-tag> \ --latest-only
ヒントbuild.sh
スクリプトの詳細なオプションを表示するには--help
パラメーターを使用します。レジストリーイメージにプラグインバイナリーを含めるには、
--offline
パラメーターを追加します。
3.3. カスタムレジストリーの実行
前提条件
このセクションで使用される my-plug-in-registry
イメージおよび my-devfile-registry
イメージは、docker
コマンドを使用して構築されます。このセクションでは、これらのイメージが CodeReady Workspaces がデプロイされている OpenShift クラスターで利用できることを想定しています。
これらのイメージは以下にプッシュできます。
-
quay.io
または DockerHub などのパブリックコンテナーレジストリー。 - プライベートレジストリー
3.3.1. OpenShift でのレジストリーのデプロイ
手順
プラグインレジストリーをデプロイする OpenShift テンプレートは、GitHub リポジトリーの openshift/
ディレクトリーで利用できます。
OpenShift テンプレートを使用してプラグインレジストリーをデプロイするには、以下のコマンドを実行します。
NAMESPACE=<namespace-name> 1 IMAGE_NAME="my-plug-in-registry" IMAGE_TAG="latest" oc new-app -f openshift/che-plugin-registry.yml \ -n "$\{NAMESPACE}" \ -p IMAGE="$\{IMAGE_NAME}" \ -p IMAGE_TAG="$\{IMAGE_TAG}" \ -p PULL_POLICY="IfNotPresent"
- 1
- crwctl を使用してインストールされている場合、デフォルトの CodeReady Workspaces プロジェクトは
workspaces
になります。この OperatorHub のインストール方法では、CodeReady Workspaces を現在のプロジェクトユーザーにデプロイします。
devfile レジストリーには、GitHub リポジトリーの
deploy/openshift/
ディレクトリーに OpenShift テンプレートがあります。これをデプロイするには、以下のコマンドを実行します。NAMESPACE=<namespace-name> 1 IMAGE_NAME="my-devfile-registry" IMAGE_TAG="latest" oc new-app -f openshift/che-devfile-registry.yml \ -n "$\{NAMESPACE}" \ -p IMAGE="$\{IMAGE_NAME}" \ -p IMAGE_TAG="$\{IMAGE_TAG}" \ -p PULL_POLICY="IfNotPresent"
- 1
- crwctl を使用してインストールされている場合、デフォルトの CodeReady Workspaces プロジェクトは
workspaces
になります。この OperatorHub のインストール方法では、CodeReady Workspaces を現在のプロジェクトユーザーにデプロイします。
レジストリーが OpenShift に正常にデプロイされたかどうかを確認します。
新規プラグインがプラグインレジストリーに正しく公開されることを確認するには、レジストリーパス
/v3/plugins/index.json
(または devfile レジストリーの/devfiles/index.json
)に要求を実行します。$ URL=$(oc get -o 'custom-columns=URL:.spec.rules[0].host' \ -l app=che-plugin-registry route --no-headers) $ INDEX_JSON=$(curl -sSL http://${URL}/v3/plugins/index.json) $ echo ${INDEX_JSON} | grep -A 4 -B 5 "\"name\":\"my-plug-in\"" ,\{ "id": "my-org/my-plug-in/1.0.0", "displayName":"This is my first plug-in for CodeReady Workspaces", "version":"1.0.0", "type":"VS Code extension", "name":"my-plug-in", "description":"This plugin shows that we are able to add plugins to the registry", "publisher":"my-org", "links": \{"self":"/v3/plugins/my-org/my-plug-in/1.0.0" } } -- -- ,\{ "id": "my-org/my-plug-in/latest", "displayName":"This is my first plug-in for CodeReady Workspaces", "version":"latest", "type":"VS Code extension", "name":"my-plug-in", "description":"This plugin shows that we are able to add plugins to the registry", "publisher":"my-org", "links": \{"self":"/v3/plugins/my-org/my-plug-in/latest" } }
CodeReady Workspaces サーバーがレジストリーの URL を参照していることを確認します。これを実行するには、
che
ConfigMapのCHE_WORKSPACE_PLUGIN__REGISTRY__URL
(またはdevfileレジストリーのCHE_WORKSPACE_DEVFILE__REGISTRY__URL
)の値を比較します。$ oc get \ -o "custom-columns=URL:.data['CHE_WORKSPACE_PLUGINREGISTRYURL']" \ --no-headers cm/che URL http://che-plugin-registry-che.192.168.99.100.nip.io/v3
ルートの URL で以下を行います。
$ oc get -o 'custom-columns=URL:.spec.rules[0].host' \ -l app=che-plugin-registry route --no-headers che-plugin-registry-che.192.168.99.100.nip.io
一致しない場合は、ConfigMap を更新し、CodeReady Workspaces サーバーを再起動します。
$ oc edit cm/che (...) $ oc scale --replicas=0 deployment/che $ oc scale --replicas=1 deployment/che
新規レジストリーがデプロイされ、CodeReady Workspaces サーバーがそのレジストリーを使用するように設定されている場合、新しいプラグインはワークスペースの Plugin ビューに利用でき、新規スタックはユーザーダッシュボードの New Workspace タブに表示されます。
第4章 ユーザーの管理
本セクションでは、Red Hat CodeReady Workspaces で承認および認証を設定する方法と、ユーザーグループおよびユーザーを管理する方法を説明します。
4.1. ユーザーの認証
以下では、CodeReady Workspaces サーバー上とワークスペース内の両方で、Red Hat CodeReady Workspaces のユーザー認証のすべての側面について説明します。これには、すべての REST API エンドポイント、WebSocket または JSON RPC 接続、一部の Web リソースのセキュリティーを保護することが含まれます。
すべての認証タイプは、JWT オープン標準を、ユーザー ID 情報を転送するコンテナーとして使用します。さらに、CodeReady Workspaces サーバー認証は、RH-SSO によってデフォルトで提供される OpenID Connect プロトコル実装に基づいて行われます。
ワークスペースでの認証は、自己署名されたワークごとの JWT トークンの発行と、JWTProxy に基づく専用サービスでの検証について示唆します。
4.1.1. CodeReady Workspaces サーバーに対する認証
4.1.1.1. OpenID を使用した CodeReady Workspaces サーバーに対する認証
CodeReady Workspaces サーバー上の OpenID 認証は、外部の OpenID Connect プロバイダーが存在することを示し、以下の主な手順が実行されます。
- HTTP 要求から取得される JWT トークンを使用してユーザーを認証するか、またはトークンが見つからないか、正しくない場合に、ユーザーを RH-SSO ログインページにリダイレクトします。
- Authorization ヘッダーで認証トークンを送信します。Authorization ヘッダーを使用できない場合の限定的なケースでは、トークンはトークンクエリーパラメーターで送信できます。例: OAuth 認証の初期化。
-
CodeReady Workspaces サーバーコード内の現在のユーザーを表す内部
subject
オブジェクトを作成します。
サポートされ、テスト済みの OpenID プロバイダーは RH-SSO のみです。
手順
OpenID 認証を使用して CodeReady Workspaces サーバーに対して認証するには、以下を実行します。
-
クライアントが JSON 形式で返される、
jwks.endpoint
、token.endpoint
、logout.endpoint
、realm.name
、client_id
などの、クライアントが OpenId プロバイダーの必要なすべての URL およびプロパティーを見つけることができる OpenID 設定サービスを要求します。 サービス URL は
\https://codeready-<openshift_deployment_name>.<domain_name>/api/keycloak/settings
で、CodeReady Workspaces のマルチユーザーモードでのみ利用できます。URL にサービスが存在すると、現在のデプロイメントで認証が有効になっていることを確認できます。出力例:
{ "che.keycloak.token.endpoint": "http://172.19.20.9:5050/auth/realms/che/protocol/openid-connect/token", "che.keycloak.profile.endpoint": "http://172.19.20.9:5050/auth/realms/che/account", "che.keycloak.client_id": "che-public", "che.keycloak.auth_server_url": "http://172.19.20.9:5050/auth", "che.keycloak.password.endpoint": "http://172.19.20.9:5050/auth/realms/che/account/password", "che.keycloak.logout.endpoint": "http://172.19.20.9:5050/auth/realms/che/protocol/openid-connect/logout", "che.keycloak.realm": "che" }
このサービスを使用すると、JavaScript クライアントライブラリーをダウンロードし、
\https://codeready-<openshift_deployment_name>.<domain_name>/api/keycloak/OIDCKeycloak.js
URL を使用してプロバイダーと対話できます。-
client_id
を含む、必要なパラメーターすべてと共に、ユーザーを適切なプロバイダーのログインページにリダイレクトし、リダイレクトパスを返します。これは、クライアントライブラリー(JS または Java)を使用して実行できます。 -
ユーザーがプロバイダーにログインすると、クライアント側のコードが取得され、JWT トークンがトークンを検証し、
subject
の作成が開始します。
トークン署名の検証は、2 つの主なステップで実行されます。
Authentication: トークンは Authorization ヘッダーまたは
token
クエリーパラメーターから抽出され、プロバイダーから取得される公開鍵を使用して解析されます。トークンの有効期限が切れるか、無効になるか、またはトークンの形式が正常ではない場合、403
エラーがユーザーに送信されます。サポートが制限されており、今後のバージョンで完全に削除されるため、クエリーパラメーターの使用は最小限にすることが推奨されます。検証に成功すると、解析されたトークンの形式が環境の初期化ステップに渡されます。
環境の初期化: フィルターは JWT トークン要求からデータを抽出し、(ない場合は) ローカルデータベースにユーザーを作成します。また、
subject
オブジェクトを構築して、これを、どこからでも静的にアクセスできる要求別の EnvironmentContext に設定します。要求が JWT トークンのみを使用して作成される場合、以下の単一の認証フィルターが使用されます。
org.eclipse.che.multiuser.machine.authentication.server.MachineLoginFilter: フィルターは
userId
トークンが属するユーザーを検出し、ユーザーインスタンスを取得し、プリンシパルをセッションに設定します。CodeReady Workspaces サーバー間の要求は、EnvironmentContext
オブジェクトから取得された現在のサブジェクトトークンすべての要求に署名する専用の要求 Factory を使用して実行されます。
ユーザー固有のデータを提供します。
RH-SSO はユーザー固有の情報(名前および姓、電話番号、肩書き) を保存できるため、このデータをコンシューマーに提供できる ProfileDao の特別な実装を使用できます。この実装は読み取り専用であるため、ユーザーは作成および更新操作を実行できません。
4.1.1.1.1. RH-SSO を使用した認証情報からのトークンの取得
JavaScript またはその他のクライアント (コマンドラインクライアントや Selenium テストなど) を実行できないクライアントは、RH-SSO から直接認証トークンを要求する必要があります。
トークンを取得するには、ユーザー名とパスワードの認証情報でトークンエンドポイントに要求を送信します。この要求を図式化すると、以下の cURL リクエストとして記述できます。
$ curl --insecure --data "grant_type=password&client_id=codeready-public&username=<USERNAME>&password=<PASSWORD>" \ 1 2 https://<keyckloak_host>/auth/realms/codeready/protocol/openid-connect/token 3
CodeReady Workspaces ダッシュボードは、カスタマイズされた RH-SSO ログインページと grant_type=authorization_code
に基づく認証メカニズムを使用します。これは 2 ステップの認証プロセスです。
- ログインし、認証コードを取得します。
- この認証コードを使用してトークンを取得します。
4.1.1.1.2. RH-SSO を使用した OpenShift トークンからのトークンの取得
CodeReady Workspaces が Operator を使用して OpenShift にインストールされ、OpenShift OAuth 統合がデフォルトで有効にされている場合、ユーザーの CodeReady Workspaces 認証トークンはユーザーの OpenShift トークンから取得できます。
OpenShift トークンから認証トークンを取得するには、図式で記述された cURL リクエストを OpenShift トークンエンドポイントに送信します。
$ curl --insecure -X POST \ -d "client_id=codeready-public" \ -d "subject_token=<USER_OPENSHIFT_TOKEN>" \ 1 -d "subject_issuer=<OPENSHIFT_IDENTITY_PROVIDER_NAME>" \ 2 --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \ --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \ https://<KEYCKLOAK_HOST>/auth/realms/codeready/protocol/openid-connect/token 3
このトークンの交換機能を使用する前に、エンドユーザーは、少なくとも 1 回は OpenShift ログインページを使用して CodeReady Workspaces ダッシュボードに対話的にログインする必要があります。この手順は、OpenShift および RH-SSO ユーザーアカウントを適切にリンクし、必要なユーザープロファイル情報を設定するために必要です。
4.1.1.2. 他の認証の実装を使用した CodeReady Workspaces サーバーに対する認証
この手順では、RH-SSO 以外の OpenID Connect (OIDC) 認証の実装を使用する方法について説明します。
手順
-
multiuser.properties
ファイルに保存されている認証設定パラメーターを更新します (例: クライアント ID、認証 URL、レルム名)。 -
単一のフィルターまたはフィルターチェーンを作成してトークンを検証し、CodeReady Workspaces ダッシュボードでユーザーを作成し、
subject
オブジェクトを作成します。 - 新規の認証プロバイダーが OpenID プロトコルをサポートする場合、設定エンドポイントで利用可能な OIDC JS クライアントライブラリーを使用してください。これは特定の実装から分離されるためです。
- 選択されたプロバイダーがユーザー (名前および姓、肩書き) についての追加データを保存する場合、この情報を提供するプロバイダーに固有の ProfileDao 実装を作成することが推奨されます。
4.1.1.3. OAuth を使用した CodeReady Workspaces サーバーに対する認証
サードパーティーサービスとのユーザーの対話を容易にするために、CodeReady Workspaces サーバーは OAuth 認証をサポートします。OAuth トークンは、GitHub 関連のプラグインにも使用されます。
OAuth 認証には、2 つの主要なフローがあります。
- delegated
- デフォルトです。OAuth 認証を RH-SSO サーバーに委譲します。
- embedded
- ビルトイン CodeReady Workspaces サーバーメカニズムを使用して OAuth プロバイダーと通信します。
2 つの実装間で切り替えるには、che.oauth.service_mode=<embedded|delegated>
設定プロパティーを使用します。
OAuth API の主な REST エンドポイントは /api/oauth
であり、以下が含まれます。
-
OAuth 認証フローを開始できる認証メソッドの
/authenticate
。 -
プロバイダーからのコールバックを処理するコールバックメソッドの
/callback
。 -
現行ユーザーの OAuth トークンを取得するためのトークン GET メソッドの
/token
。 -
現行ユーザーの OAuth トークンを無効にするためのトークン DELETE メソッドの
/token
。 -
設定済みのアイデンティティープロバイダーの一覧を取得する GET メソッドの
/
。
4.1.1.4. Swagger または REST クライアントを使用したクエリーの実行
ユーザーの RH-SSO トークンを使用して、REST クライアントでユーザーの代わりにセキュアな API に対してクエリーを実行します。有効なトークンは、Request ヘッダーまたは ?token=$token
クエリーパラメーターとして割り当てる必要があります。
CodeReady Workspaces Swagger インターフェース \https://codeready-<openshift_deployment_name>.<domain_name>/swagger
にアクセスします。アクセストークンが Request ヘッダーに含まれるように、ユーザーは RH-SSO で署名する必要があります。
4.1.2. CodeReady Workspaces ワークスペースでの認証
ワークスペースコンテナーには、認証で保護される必要のあるサービスが含まれる場合があります。このように保護されるサービスは、セキュア なサービスと呼ばれます。これらのサービスのセキュリティーを保護するには、マシンの認証メカニズムを使用します。
JWT トークンを使用すると、RH-SSO トークンをワークスペースコンテナーに渡す必要がなくなります(セキュアではなくなる可能性があります)。また、RH-SSO トークンの有効期間は比較的短く、定期的な更新またはリフレッシュが必要になる場合があります。このため、クライアントの同じユーザーセッショントークンを管理し、これらとの同期を維持するのは容易ではありません。
図4.1 ワークスペース内の認証
4.1.2.1. セキュアなサーバーの作成
CodeReady Workspaces ワークスペースでセキュアなサーバーを作成するには、devfile の dockerimage
タイプコンポーネントで、エンドポイントの secure
属性を true
に設定します。
セキュアなサーバーの devfile スニペット
components: - type: dockerimage endpoints: - attributes: secure: 'true'
4.1.2.2. ワークスペース JWT トークン
ワークスペーストークンは、要求に以下の情報が含まれる JSON Web トークン (JWT) です。
-
uid
: このトークンを所有するユーザーの ID -
uname
: このトークンを所有するユーザーの名前 -
wsid
: このトークンでクエリーできるワークスペースの ID
すべてのユーザーには、各ワークスペースに固有の個人用トークンが提供されます。トークンと署名の構造は、RH-SSO の場合とは異なります。以下は、トークンビューの例です。
# Header { "alg": "RS512", "kind": "machine_token" } # Payload { "wsid": "workspacekrh99xjenek3h571", "uid": "b07e3a58-ed50-4a6e-be17-fcf49ff8b242", "uname": "john", "jti": "06c73349-2242-45f8-a94c-722e081bb6fd" } # Signature { "value": "RSASHA256(base64UrlEncode(header) + . + base64UrlEncode(payload))" }
RSA アルゴリズムを使用した SHA-256 暗号は、JWT トークンの署名に使用されます。これは設定不可です。また、トークンの署名に使用されるキーペアの公開部分を配布するパブリックサービスはありません。
4.1.2.3. マシントークンの検証
マシントークン (JWT トークン) の検証は、別の Pod で実行される JWTProxy
と共に専用の per-workspace サービスを使用して実行されます。ワークスペースが起動すると、このサービスは CodeReady Workspaces サーバーから SHA キーの公開部分を受信します。セキュアなサーバーごとに個別の検証エンドポイントが作成されます。トラフィックがそのエンドポイントに到達すると、JWTProxy
は cookie またはヘッダーからトークンを抽出し、公開鍵の部分を使用して検証します。
CodeReady Workspaces サーバーをクエリーするには、ワークスペースサーバーは CHE_MACHINE_TOKEN
環境変数で提供されるマシントークンを使用できます。このトークンは、ワークスペースを起動するユーザーのトークンです。このような要求の範囲は、現在のワークスペースにのみ制限されます。許可される操作の一覧も厳密に制限されます。
4.2. ユーザーの認証
CodeReady Workspaces でのユーザー認証は、パーミッションモデルに基づいて行われます。パーミッションは、ユーザーの許可されるアクションを制御し、セキュリティーモデルを確立するために使用されます。すべての要求は、認証にパスした後に、現行ユーザーのサブジェクトに必要なパーミッションがあるかどうかについて検証されます。CodeReady Workspaces が管理するリソースを制御し、ユーザーにパーミッションを割り当てることで特定のアクションを許可できます。
パーミッションは以下のエンティティーに適用できます。
- ワークスペース
- システム
すべてのパーミッションは、提供される REST API を使用して管理できます。API は、\https://codeready-<openshift_deployment_name>.<domain_name>/swagger/#!/permissions
で Swagger を使用して文書化されます。
4.2.1. CodeReady Workspaces ワークスペースパーミッション
ワークスペースを作成するユーザーはワークスペースの所有者です。デフォルトで、ワークスペースの所有者には、パーミッション read
、use
、run
、configure
、setPermissions
、および delete
があります。ワークスペースの所有者は、ユーザーをワークスペースに招待し、他のユーザーのワークスペースのパーミッションを制御できます。
ワークスペースには以下のパーミッションが関連付けられています。
表4.1 CodeReady Workspaces ワークスペースパーミッション
パーミッション | 詳細 |
---|---|
read | ワークスペース設定の読み取りを許可します。 |
use | ワークスペースの使用や、これとの対話を許可します。 |
run | ワークスペースの開始および停止を許可します。 |
configure | ワークスペース設定の定義および変更を許可します。 |
setPermissions | その他のユーザーのワークスペースパーミッションの更新を許可します。 |
削除 | ワークスペースの削除を許可します。 |
4.2.2. CodeReady Workspaces システムパーミッション
CodeReady Workspaces のシステムパーミッションは、CodeReady Workspaces インストール全体のさまざまな側面を制御します。以下のパーミッションがシステムに適用されます。
表4.2 CodeReady Workspaces システムパーミッション
パーミッション | 詳細 |
---|---|
manageSystem | システムおよびワークスペースの制御を許可します。 |
setPermissions | システムでのユーザーのパーミッションの更新を許可します。 |
manageUsers | ユーザーの作成および管理を許可します。 |
monitorSystem | サーバーの状態の監視に使用するエンドポイントへのアクセスを許可します。 |
すべてのシステムパーミッションは、CHE_SYSTEM_ADMIN__NAME
プロパティーで設定した管理ユーザーに付与されます (デフォルトは admin
です)。システムのパーミッションは CodeReady Workspaces サーバーの起動時に付与されます。ユーザーが CodeReady Workspaces ユーザーデータベースにない場合は、最初のユーザーのログイン後に表示されます。
4.2.3. manageSystem パーミッション
manageSystem パーミッションを 持つ ユーザーは、以下のサービスにアクセスできます。
パス | HTTP メソッド | 詳細 |
---|---|---|
/resource/free/ | GET | 空きリソース制限を取得します。 |
/resource/free/{accountId} | GET | 指定のアカウントの空きリソース制限を取得します。 |
/resource/free/{accountId} | POST | 指定のアカウントの空きリソース制限を編集します。 |
/resource/free/{accountId} | DELETE | 指定のアカウントの空きリソース制限を削除します。 |
/installer/ | POST | インストーラーをレジストリーに追加します。 |
/installer/{key} | PUT | レジストリーでインストーラーを更新します。 |
/installer/{key} | DELETE | レジストリーからインストーラーを削除します。 |
/logger/ | GET | CodeReady Workspaces サーバーのロギング設定を取得します。 |
/logger/{name} | GET | CodeReady Workspaces サーバーで、ロガーの名前でロガーの設定を取得します。 |
/logger/{name} | PUT | CodeReady Workspaces サーバーでロガーを作成します。 |
/logger/{name} | POST | CodeReady Workspaces サーバーでロガーを編集します。 |
/resource/{accountId}/details | GET | 指定のアカウントのリソースに関する詳細情報を取得します。 |
/system/stop | POST | すべてのシステムサービスをシャットダウンし、CodeReady Workspaces の停止に向けて準備します。 |
4.2.4. monitorSystem パーミッション
monitorSystem パーミッションを持つユーザーは、以下のサービスにアクセスできます。
パス | HTTP メソッド | 詳細 |
---|---|---|
/activity | GET | 一定期間に特定の状態に置かれているワークスペースを取得します。 |
4.2.5. CodeReady Workspaces パーミッションの一覧表示
特定の リソース に適用される CodeReady Workspaces パーミッションを一覧表示するには、GET /permissions
要求を実行します。
user に適用されるパーミッションを一覧表示するには、GET /permissions/{domain}
要求を実行します。
すべてのユーザー に適用されるパーミッションを一覧表示するには、GET /permissions/{domain}/all
要求を実行します。この情報を表示するには、ユーザーに manageSystem パーミッションが必要です。
適切なドメイン値は次のとおりです。
- system
- organization
- workspace
ドメインは任意です。ドメインを指定しないと、API はすべてのドメインについて想定されるすべてのパーミッションを返します。
4.2.6. CodeReady Workspaces パーミッションの割り当て
リソースにパーミッションを割り当てるには、POST /permissions
要求を実行します。適切なドメイン値は次のとおりです。
- system
- organization
- workspace
以下は、userId
を持つユーザーの workspaceID
を持つワークスペースに対するパーミッションを要求するメッセージの本体です。
CodeReady Workspaces ユーザーパーミッションの要求
{ "actions": [ "read", "use", "run", "configure", "setPermissions" ], "userId": "userID", 1 "domainId": "workspace", "instanceId": "workspaceID" 2 }
4.2.7. CodeReady Workspaces パーミッションの共有
setPermissions 権限を持つユーザーはワークスペースを共有し、他のユーザーの権限 read
、use
、run
、configure
、または setPermissions
を付与できます。
手順
ワークスペースパーミッションを共有するには、以下を実行します。
- ユーザーダッシュボードでワークスペースを選択します。
- Share タブに移動して、ユーザーのメール ID を入力します。複数のメールの区切り文字としてコンマまたはスペースを使用します。
4.3. 認証の設定
4.3.1. 認証およびユーザー管理
Red Hat CodeReady Workspaces は RH-SSO を使用してユーザーの作成、インポート、管理、削除、および認証を行います。RH-SSO は、ビルトイン認証メカニズムとユーザーストレージを使用します。サードパーティーのアイデンティティー管理システムを使用してユーザーを作成し、認証できます。CodeReady Workspaces リソースへのアクセスを要求する場合に、Red Hat CodeReady Workspaces には RH-SSO トークンが必要です。
ローカルユーザーおよびインポートされたフェデレーションユーザーは、プロファイルにメールアドレスが必要です。
デフォルトの RH-SSO 認証情報は admin:admin
です。Red Hat CodeReady Workspaces への初回ログイン時に、admin:admin
認証情報を使用できます。これにはシステム権限があります。
RH-SSO URL を特定します。
OpenShift Web コンソールに移動し、RH-SSO プロジェクトに移動します。
4.3.2. RH-SSO と連携する CodeReady Workspaces の設定
デプロイメントスクリプトは RH-SSO を設定します。以下のフィールドを使用して codeready-public
クライアントを作成します。
- Valid Redirect URIs: この URL を使用して CodeReady Workspaces にアクセスします。
- Web Origins
以下は、RH-SSO と連携するように CodeReady Workspaces を設定する場合の一般的なエラーです。
- 無効な
redirectURI
エラー -
エイリアスの
myhost
で CodeReady Workspaces にアクセスし、元のCHE_HOST
が1.1.1.1
の場合に発生します。このエラーが発生した場合は、RH-SSO 管理コンソールに移動し、有効なリダイレクト URI が設定されていることを確認してください。 - CORS エラー
- 無効な Web Origin がある場合に発生します。
4.3.3. RH-SSO トークンの設定
ユーザートークンの有効期間は、デフォルトで 30 分後に切れます。
以下の RH-SSO トークン設定を変更することができます。
4.3.4. ユーザーフェデレーションの設定
RH-SSO は、外部ユーザーデータベースのフェデレーションを行い、LDAP および Active Directory をサポートします。ストレージプロバイダーを選択する前に、接続をテストし、ユーザーを認証できます。
プロバイダーの追加方法については、RH-SSO ドキュメントのユーザーストレージのフェデーレーションについてのページを参照してください。
複数の LDAP サーバーを指定するには、RH-SSO ドキュメントの LDAP および Active Directory についてのページを参照してください。
4.3.5. ソーシャルアカウントおよびブローカーを使用した認証の有効化
RH-SSO は、GitHub、OpenShift、および Facebook や Twitter などの最も一般的に使用されるソーシャルネットワークの組み込みサポートを提供します。GitHub でログインを有効にする方法については、RH-SSO ドキュメントを参照してください。
SSH キーを有効にし、これを CodeReady Workspaces ユーザーの GitHub アカウントにアップロードすることもできます。
GitHub アイデンティティープロバイダーを登録する際にこの機能を有効にするには、以下を実行します。
-
scope を
repo,user,write:public_key
に設定します。 トークンを保存し、保存された読み取り可能なトークンを ON に設定します。
デフォルトの read-token ロールを追加します。
これは、マルチユーザー CodeReady Workspaces のデフォルトの delegated
OAuth サービスモードです。OAuth サービスモードを che.oauth.service_mode
プロパティーで設定できます。
4.3.6. プロトコルベースのプロバイダーの使用
RH-SSO は SAML v2.0 プロトコルおよび OpenID Connect v1.0 プロトコルをサポートします。
4.3.7. RH-SSO を使用したユーザーの管理
ユーザーインターフェースでユーザーを追加し、削除し、編集できます。詳細は、RH-SSO ユーザー管理について参照してください。
4.3.8. 外部 RH-SSO インストールを使用するように CodeReady Workspaces を設定する
デフォルトでは、CodeReady Workspaces インストールには、専用の RH-SSO インスタンスのデプロイメントが含まれます。ただし、外部の RH-SSO を使用することも可能です。このオプションは、すでに定義されたユーザーを含む既存の RH-SSO インスタンス (複数のアプリケーションが使用する会社全体の RH-SSO サーバーなど) がある場合に役立ちます。
表4.3 サンプルで使用されるプレースホルダー
| CodeReady Workspaces で使用することが意図されたアイデンティティープロバイダーのレルム名 |
|
|
| 外部 RH-SSO サーバーのベース URL |
前提条件
RH-SSO の外部インストールの管理コンソールで、CodeReady Workspaces に接続することが意図されたユーザーが含まれるレルムを定義します。
この
realm
では、CodeReady Workspaces がユーザーの認証に使用する OIDC クライアントを定義します。以下は、正しい設定のあるクライアントの例です。注記-
Client Protocol は
openid-connect
である必要があります。 -
Access Type は
public
である必要があります。CodeReady Workspaces はpublic
アクセスタイプのみをサポートします。 -
Valid Redirect URIs には、
http
プロトコルを使用する URL とhttps
を使用する URL の 2 つ以上の CodeReady Workspaces サーバーに関連する URI が含まれる必要があります。これらの URI には CodeReady Workspaces サーバーのベース URL (この後に/*
ワイルドカードが続く) が含まれる必要があります。 Web Origins には、
http
プロトコルを使用する URI とhttps
を使用する URI の 2 つ以上の CodeReady Workspaces サーバーに関連する URI が含まれる必要があります。これらの URI には、CodeReady Workspaces サーバーのベース URL (ホストの後はパスがない) が含まれる必要があります。URI の数は、インストールされている製品ツールの数によって異なります。
-
Client Protocol は
デフォルトの OpenShift OAuth サポートを使用する CodeReady Workspaces では、ユーザー認証は、OpenShift OAuth と RH-SSO の統合に依存します。これにより、ユーザーは OpenShift ログインで CodeReady Workspaces にログインでき、独自のワークスペースを個人の OpenShift プロジェクトに作成することができます。
これには、OpenShift アイデンティティープロバイダーを RH-SSO で設定する必要があります。外部 RH-SSO を使用する場合は、アイデンティティープロバイダーを手動で設定します。手順については、以下のいずれかのリンクについての該当する RH-SSO ドキュメントを参照してください:OpenShift 3[OpenShift 3] または OpenShift 4[OpenShift 4]
- 設定済みのアイデンティティープロバイダーでは、Store Tokens および Stored Tokens Readable オプションが有効にされている必要があります。
手順
CheCluster
カスタムリソース (CR) に以下のプロパティーを設定します。spec: auth: externalIdentityProvider: true identityProviderURL: <auth-base-url> identityProviderRealm: <provider-realm-name> identityProviderClientId: <oidc-client-name>
OpenShift OAuth サポートを有効にして CodeReady Workspaces をインストールする場合は、
CheCluster
カスタムリソース (CR) に以下のプロパティーを設定します。spec: auth: openShiftoAuth: true # Note: only if the OpenShift identity provider alias is different from 'openshift-v3' or 'openshift-v4' server: customCheProperties: CHE_INFRA_OPENSHIFT_OAUTH__IDENTITY__PROVIDER: <OpenShift identity provider alias>
4.3.9. SMTP およびメール通知の設定
Red Hat CodeReady Workspaces は事前に設定された MTP サーバーを提供しません。
RH-SSO で SMTP サーバーを有効にするには、以下を実行します。
-
che realm settings > Email
の順に移動します。 - ホスト、ポート、ユーザー名、およびパスワードを指定します。
Red Hat CodeReady Workspaces は、登録、メールの確認、パスワードの復旧、およびログインの失敗についてのデフォルトのテーマを使用します。
4.4. ユーザーデータの削除
4.4.1. GDPR に準拠したユーザーデータの削除
一般データ保護規則 (GDPR: General Data Protection Regulation) では、個人データの消去を求める個人の権利が施行されています。
以下の手順では、クラスターおよび RH-SSO データベースからユーザーのデータを削除する方法を説明します。
以下のコマンドは、-n
オプションのユーザー例として、デフォルトの OpenShift プロジェクト workspaces
を使用します。
前提条件
ユーザーまたは管理者の認証トークン。ユーザーアカウントにバインドされているデータ以外のデータを削除する場合は、
admin
権限が必要になります。admin
は、CHE_SYSTEM_ADMIN__NAME
およびCHE_SYSTEM_SUPER__PRIVILEGED__MODE = true
カスタムリソース定義を使用して事前に作成され、有効にされる特別な CodeReady Workspaces 管理者アカウントです。spec: server: customCheProperties: CHE_SYSTEM_SUPER__PRIVILEGED__MODE: 'true' CHE_SYSTEM_ADMIN__NAME: '<admin-name>'
必要に応じて、以下のコマンドを使用して
admin
ユーザーを作成します。$ oc patch checluster codeready-workspaces \ --type merge \ -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_SUPER__PRIVILEGED__MODE": "true"} } }}' \ -n workspaces
$ oc patch checluster codeready-workspaces \ --type merge \ -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_ADMIN__NAME": "<admin-name>"} } }}' \ -n workspaces
注記すべてのシステムパーミッションは、
CHE_SYSTEM_ADMIN__NAME
プロパティーで設定した管理ユーザーに付与されます (デフォルトはadmin
です)。システムのパーミッションは CodeReady Workspaces サーバーの起動時に付与されます。ユーザーが CodeReady Workspaces ユーザーデータベースにない場合は、最初のユーザーのログイン後に表示されます。認証トークンの権限:
-
admin
: すべてのユーザーのすべての個人データを削除できます。 -
user
: ユーザーに関連するデータのみを削除できます。
-
- ユーザーまたは管理者が、CodeReady Workspaces がデプロイされた状態で OpenShift クラスターにログインしている。
ユーザー ID が取得されます。以下のコマンドを使用してユーザー ID を取得します。
現行ユーザーの場合:
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user'
名前でユーザーを検索するには、以下を実行します。
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/find?name=<username>'
メールでユーザーを検索するには、以下を実行します。
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/find?email=<email>'
ユーザー ID を取得する例
この例では、ローカルユーザーの名前として
vparfono
を使用します。$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://che-vp-che.apps.che-dev.x6e0.p1.openshiftapps.com/api/user/find?name=vparfono'
ユーザー ID は、curl コマンド出力の下部にあります。
{ "name": "vparfono", "links": [ { . . . } ], "email": "vparfono@redhat.com", "id": "921b6f33-2657-407e-93a6-fb14cf2329ce" }
手順
codeready-workspaces
CheCluster Custom
リソース (CR) 定義を更新して、RH-SSO データベースからユーザーのデータの削除を許可します。$ oc patch checluster/codeready-workspaces \ --patch "{\"spec\":{\"server\":{\"customCheProperties\": {\"CHE_KEYCLOAK_CASCADE__USER__REMOVAL__ENABLED\": \"true\"}}}}" \ --type=merge -n workspaces
API を使用してデータを削除します。
$ curl -i -X DELETE \ --header 'Authorization: Bearer <user-token>' \ https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/<user-id>
検証
以下のコマンドを実行すると、コード 204
が API 応答として返されます。
$ curl -i -X DELETE \ --header 'Authorization: Bearer <user-token>' \ https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/<user-id>
第5章 CodeReady Workspaces ログの取得
CodeReady Workspaces で各種ログを取得する方法は、以下のセクションを参照してください。
5.1. OpenShift での OpenShift イベントへのアクセス
OpenShift プロジェクトのハイレベルのモニタリングについては、プロジェクトが実行する OpenShift イベントを表示します。
本セクションでは、OpenShift Web コンソールでこれらのイベントにアクセスする方法を説明します。
前提条件
- 実行中の OpenShift Web コンソール。
手順
- OpenShift Web コンソールの左側のパネルで、Home → Events をクリックします。
- 特定のプロジェクトのイベントの一覧を表示するには、一覧からプロジェクトを選択します。
- 現在のプロジェクトのイベントの詳細が表示されます。
関連資料
- OpenShift イベントの一覧については、OpenShift ドキュメントのイベントの詳細な一覧について参照してください。
5.2. OpenShift 4 CLI ツールを使用した CodeReady Workspaces クラスターデプロイメントの状態の表示
本セクションでは、OpenShift 4 CLI ツールを使用して CodeReady Workspaces クラスターのデプロイメントの状態を表示する方法を説明します。
前提条件
- OpenShift で実行している Red Hat CodeReady Workspaces のインスタンス。
-
OpenShift コマンドラインツール
oc
のインストール
手順
以下のコマンドを実行して
crw
プロジェクトを選択します。$ oc project <project_name>
以下のコマンドを実行して、選択したプロジェクトで実行されている Pod の名前およびステータスを取得します。
$ oc get pods
すべての Pod のステータスが
Running
であることを確認します。例5.1 ステータスが
Running
の PodNAME READY STATUS RESTARTS AGE codeready-8495f4946b-jrzdc 0/1 Running 0 86s codeready-operator-578765d954-99szc 1/1 Running 0 42m keycloak-74fbfb9654-g9vp5 1/1 Running 0 4m32s postgres-5d579c6847-w6wx5 1/1 Running 0 5m14s
CodeReady Workspaces クラスターデプロイメントの状態を表示するには、以下を実行します。
$ oc logs --tail=10 -f `(oc get pods -o name | grep operator)`
例5.2 Operator のログ:
time="2019-07-12T09:48:29Z" level=info msg="Exec successfully completed" time="2019-07-12T09:48:29Z" level=info msg="Updating eclipse-che CR with status: provisioned with OpenShift identity provider: true" time="2019-07-12T09:48:29Z" level=info msg="Custom resource eclipse-che updated" time="2019-07-12T09:48:29Z" level=info msg="Creating a new object: ConfigMap, name: che" time="2019-07-12T09:48:29Z" level=info msg="Creating a new object: ConfigMap, name: custom" time="2019-07-12T09:48:29Z" level=info msg="Creating a new object: Deployment, name: che" time="2019-07-12T09:48:30Z" level=info msg="Updating eclipse-che CR with status: CodeReady Workspaces API: Unavailable" time="2019-07-12T09:48:30Z" level=info msg="Custom resource eclipse-che updated" time="2019-07-12T09:48:30Z" level=info msg="Waiting for deployment che. Default timeout: 420 seconds"
5.3. CodeReady Workspaces サーバーログの表示
本セクションでは、コマンドラインを使用して CodeReady Workspaces サーバーログを表示する方法を説明します。
5.3.1. OpenShift CLI を使用した CodeReady Workspaces サーバーログの表示
本セクションでは、OpenShift CLI (コマンドラインインターフェース) を使用して CodeReady Workspaces サーバーログを表示する方法を説明します。
手順
ターミナルで以下のコマンドを実行し、Pod を取得します。
$ oc get pods
例
$ oc get pods NAME READY STATUS RESTARTS AGE codeready-11-j4w2b 1/1 Running 0 3m
デプロイメントのログを取得するには、以下のコマンドを実行します。
$ oc logs <name-of-pod>
例
$ oc logs codeready-11-j4w2b
5.4. 外部サービスログの表示
本セクションでは、CodeReady Workspaces サーバーに関連する外部サービスのログを表示する方法を説明します。
5.4.1. RH-SSO ログの表示
RH-SSO OpenID プロバイダーは、サーバーと IDE の 2 つの部分で構成されます。これは診断またはエラー情報を複数のログに書き込みます。
5.4.1.1. RH-SSO サーバーログの表示
このセクションでは、RH-SSO OpenID プロバイダーサーバーのログを表示する方法について説明します。
手順
- OpenShift Web コンソールで Deployments をクリックします。
-
Filter by label 検索フィールドに
keycloak
を入力し、RH-SSO ログを表示します。 -
Deployment Configs セクションで、
keycloak
リンクをクリックしてこれを開きます。 - History タブで、アクティブな RH-SSO デプロイメントについての View log リンクをクリックします。
- RH-SSO ログが表示されます。
関連資料
- RH-SSO IDE サーバーに関連する診断およびエラーメッセージについては、「CodeReady Workspaces サーバーログの表示」を参照してください。
5.4.1.2. Firefox での RH-SSO クライアントログの表示
このセクションでは、Firefox WebConsole で RH-SSO IDE クライアント診断またはエラー情報を表示する方法を説明します。
手順
- Menu > WebDeveloper > WebConsole をクリックします。
5.4.1.3. Google Chrome での RH-SSO クライアントログの表示
このセクションでは、Google Chrome Console タブで RH-SSO IDE クライアントの診断またはエラー情報を表示する方法を説明します。
手順
- Menu > More Tools > Developer Tools の順にクリックします。
- Console タブをクリックします。
5.4.2. CodeReady Workspaces データベースログの表示
本セクションでは、PostgreSQL サーバーログなどのデータベースログを CodeReady Workspaces に表示する方法を説明します。
手順
- OpenShift Web コンソールで Deployments をクリックします。
Find by label 検索フィールドに以下を入力します。
-
app=che
および Enter を押してください。 component=postgres
および Enter を押してください。OpenShift Web コンソールは、これら 2 つのキーでベースを検索し、PostgreSQL ログを表示するようになりました。
-
- postgres デプロイメントをクリックして開きます。
アクティブな PostgreSQL デプロイメントの View log リンクをクリックします。
OpenShift Web コンソールには、データベースログが表示されます。
関連資料
- PostgreSQL サーバーに関連する診断またはエラーメッセージは、アクティブな CodeReady Workspaces デプロイメントログにある場合があります。アクティブな CodeReady Workspaces デプロイメントログへのアクセスに関する詳細は、「CodeReady Workspaces サーバーログの表示」 セクションを参照してください。
5.5. プラグインブローカーログの表示
このセクションでは、プラグインブローカーログを表示する方法を説明します。
che-plugin-broker
Pod 自体は作業が完了すると削除されます。そのため、イベントログはワークスペースの起動時にのみ利用できます。
手順
一時 Pod からのログイベントを表示するには、以下を実行します。
- CodeReady Workspaces ワークスペースを起動します。
- メインの OpenShift Container Platform 画面から、Workload → Pods に移動します。
- Pod の Terminal タブにある OpenShift ターミナルコンソールを使用します。
検証手順
- ワークスペースの起動中に OpenShift ターミナルコンソールがプラグインブローカーログを表示します
5.6. crwctl を使用したログの収集
crwctl
ツールを使用して OpenShift クラスターからすべての Red Hat CodeReady Workspaces ログを取得できます。
-
crwctl server:deploy
は、Red Hat CodeReady Workspaces のインストール時に Red Hat CodeReady Workspaces サーバーログの収集を自動的に開始します。 -
crwctl server:logs
は、既存の Red Hat CodeReady Workspaces サーバーログを収集します。 -
crwctl workspace:logs
はワークスペースログを収集します
第6章 CodeReady Workspaces の監視
本章では、CodeReady Workspaces を設定してメトリクスを公開する方法と、CodeReady Workspaces でメトリクスとして公開されるデータを処理するために外部ツールを使用してモニタリングスタックのサンプルを構築する方法を説明します。
6.1. CodeReady Workspaces メトリクスの有効化および公開
本セクションでは、CodeReady Workspaces メトリクスを有効にし、公開する方法を説明します。
手順
-
che-master ホストで
8087
ポートをサービスとして公開するCHE_METRICS_ENABLED=true
環境変数を設定します。
Red Hat CodeReady Workspaces が OperatorHub でインストールされると、デフォルトの CheCluster
CR が使用されている場合に環境変数が自動的に設定されます。
spec: metrics: enable: true
6.2. Prometheus を使用した CodeReady Workspaces メトリクスの収集
このセクションでは、Prometheus モニタリングシステムを使用して、CodeReady Workspaces に関するメトリクスを収集し、保存し、クエリーする方法を説明します。
前提条件
-
CodeReady Workspaces はポート
8087
でメトリクスを公開している。che メトリクスの有効化および公開について参照してください。 -
Prometheus 2.9.1 以降が実行中である。Prometheus コンソールは、対応する service と route のあるポート
9090
で実行されている。Prometheus を初めて実行するための手順について参照してください。
手順
8087
ポートからメトリクスを収集するように Prometheus を設定する。Prometheus 設定の例
apiVersion: v1 kind: ConfigMap metadata: name: prometheus-config data: prometheus.yml: |- global: scrape_interval: 5s 1 evaluation_interval: 5s 2 scrape_configs: 3 - job_name: 'che' static_configs: - targets: ['[che-host]:8087'] 4
検証手順
Prometheus コンソールを使用して、メトリクスをクエリーし、表示します。
メトリックは、
http://<che-server-url>:9090/metrics
で入手できます。詳細は、Prometheus ドキュメントの「Using the expression browser」を参照してください。
6.3. CodeReady Workspaces モニタリングメトリクスの拡張
本セクションでは、CodeReady Workspaces が公開しているモニタリングメトリクスを拡張するために、メトリクスまたはメトリクスのグループを作成する方法を説明します。
CodeReady Workspaces には 2 つの主要なモジュールメトリクスがあります。
-
che-core-metrics-core
— コアメトリクスモジュールが含まれます。 -
che-core-api-metrics
— ワークスペースやユーザーマネージャーなどの CodeReady Workspaces のコアコンポーネントに依存するメトリクスが含まれます。
手順
MeterBinder
クラスを拡張するクラスを作成します。これにより、作成されたメトリクスをオーバーライドされたbindTo(MeterRegistry registry)
メソッドに登録することができます。以下は、その値を提供する機能が含まれるメトリクスの例です。
メトリクスの例
public class UserMeterBinder implements MeterBinder { private final UserManager userManager; @Inject public UserMeterBinder(UserManager userManager) { this.userManager = userManager; } @Override public void bindTo(MeterRegistry registry) { Gauge.builder("che.user.total", this::count) .description("Total amount of users") .register(registry); } private double count() { try { return userManager.getTotalCount(); } catch (ServerException e) { return Double.NaN; } }
または、メトリクスは参照情報と共に保存でき、コードの別の場所で手動で更新できます。
第7章 CodeReady Workspaces のトレース
トレースは、マイクロサービスアーキテクチャーのレイテンシーの問題をトラブルシューティングするためにタイミングデータを収集するのに役立ち、分散システムで伝播されるため、完全なトランザクションまたはワークフローを理解するのに役立ちます。すべてのトランザクションでは、新規サービスが独立したチームによって導入されると、早い段階でパフォーマンスの異常を反映する可能性があります。
CodeReady Workspaces アプリケーションの追跡は、ワークスペースの作成、ワークスペースの起動、サブ操作の実行期間の分解、ボトルネックの特定、プラットフォーム全体の状態を改善など、さまざまな操作の実行を分析するのに役立ちます。
トレーサーはアプリケーションに存在します。これらは、発生する操作に関するタイミングとメタデータを記録します。多くの場合、それらはライブラリーをインストルメント化し、使用がユーザーに透過的になるようにします。たとえば、インストルメント化された Web サーバーは、要求の受信時や応答の送信時を記録します。収集されるトレースデータは スパン と呼ばれます。スパンには、トレースやスパン識別子などの情報や、次のステップに伝播できる他の種類の情報が含まれるコンテキストがあります。
7.1. トレース API
CodeReady Workspaces はインストルメント化に OpenTracing API (ベンダーに依存しないフレームワーク) を使用します。これは、開発者が別のトレースバックエンドを試す場合、新規の分散トレースシステムのインストルメンテーションプロセスを繰り返すのではなく、開発者は単にトレーサーのバックエンドの設定を変更できることを意味します。
7.2. バックエンドの追跡
デフォルトでは、CodeReady Workspaces は Jaeger をトレースバックエンドとして使用します。Jaeger は Dapper および OpenZipkin によって提供され、Uber Technologies によってオープンソースとしてリリースされた分散トレーシングシステムです。Jaeger は、大規模な要求およびパフォーマンスに対応する、より複雑なアーキテクチャーを拡張します。
7.3. Jaeger トレースツールのインストール
以下のセクションでは、Jaeger トレーシングツールのインストール方法を説明します。その後、Jaeger は CodeReady Workspaces でメトリクスを収集するために使用できます。
利用可能なインストール方法:
Jaeger を使用して CodeReady Workspaces インスタンスをトレースするには、バージョン 1.12.0 以降が必要になります。Jaeger の詳細は、Jaeger の Web サイトを参照してください。
7.3.1. OpenShift 4 での OperatorHub を使用した Jaeger のインストール
このセクションでは、実稼働環境でテストおよび評価目的で Jaeger トレースツールを使用する方法についての情報を提供します。
OpenShift Container Platform の OperatorHub インターフェースから Jaeger トレースツールをインストールするには、以下の手順を実行します。
前提条件
- ユーザーが OpenShift Container Platform Web コンソールにログインしている。
- CodeReady Workspaces インスタンスはプロジェクトで利用できます。
手順
- OpenShift Container Platform コンソールを開きます。
- メインの OpenShift Container Platform 画面の左側のメニューから、Operators → OperatorHub に移動します。
-
Search by keyword 検索バーに、
Jaeger Operator
と入力します。 -
Jaeger Operator
タイルをクリックします。 -
Jaeger Operator
ポップアップウィンドウで Install ボタンをクリックします。 -
インストール方法を選択します。
A specific project on the cluster
の場合、CodeReady Workspaces はデプロイされ、残りをデフォルト値のままにします。 - Subscribe ボタンをクリックします。
- メインの OpenShift Container Platform 画面の左側のメニューから、Operators → Installed Operators ページ に移動します。
- Red Hat CodeReady Workspaces は、InstallSucceeded ステータスで示唆されるようにインストールされた Operator として表示されます。
- インストールされた Operator の一覧で、 Jaeger Operator 名をクリックします。
- Overview タブに移動します。
-
ページ下部の Conditions セクションで、メッセージ
install strategy completed with no errors
が表示されるのを待機します。 -
Jaeger Operator
および追加のElasticsearch Operator
がインストールされています。 - Operators → Installed Operators セクションに移動します。
- インストールされた Operator の一覧で Jaeger Operator をクリックします。
- Jaeger Cluster ページが表示されます。
- ウィンドウの左下にある Create Instance をクリックします。
- 保存をクリックします。
-
OpenShift は Jaeger クラスター
jaeger-all-in-one-inmemory
を作成します。 - メトリクスコレクションの有効化についての手順に従い、以下の手順を完了します。
7.3.2. OpenShift 4 での CLI を使用した Jaeger のインストール
このセクションでは、テストおよび評価の目的で Jaeger トレースツールを使用する方法について説明します。
OpenShift Container Platform の CodeReady Workspaces プロジェクトから Jaeger トレースツールをインストールするには、本セクションの手順に従います。
前提条件
- ユーザーが OpenShift Container Platform Web コンソールにログインしている。
- OpenShift Container Platform クラスターの CodeReady Workspaces のインスタンス。
手順
OpenShift Container Platform クラスターの CodeReady Workspaces インストールプロジェクトで、
oc
クライアントを使用して Jaeger デプロイメントの新規アプリケーションを作成します。$ oc new-app -f / ${CHE_LOCAL_GIT_REPO}/deploy/openshift/templates/jaeger-all-in-one-template.yml: --> Deploying template "<project_name>/jaeger-template-all-in-one" for "/home/user/crw-projects/crw/deploy/openshift/templates/jaeger-all-in-one-template.yml" to project <project_name> Jaeger (all-in-one) --------- Jaeger Distributed Tracing Server (all-in-one) * With parameters: * Jaeger Service Name=jaeger * Image version=latest * Jaeger Zipkin Service Name=zipkin --> Creating resources ... deployment.apps "jaeger" created service "jaeger-query" created service "jaeger-collector" created service "jaeger-agent" created service "zipkin" created route.route.openshift.io "jaeger-query" created --> Success Access your application using the route: 'jaeger-query-<project_name>.apps.ci-ln-whx0352-d5d6b.origin-ci-int-aws.dev.rhcloud.com' Run 'oc status' to view your app.
- メインの OpenShift Container Platform 画面の左側のメニューから Workloads → Deployments を使用して、Jaeger デプロイメントが正常に終了するまで監視します。
- メインの OpenShift Container Platform 画面の左側のメニューから Networking → Routes を選択し、URL リンクをクリックして Jaeger ダッシュボードにアクセスします。
- メトリクスコレクションの有効化についての手順に従い、以下の手順を完了します。
7.4. メトリクス収集の有効化
前提条件
- Jaeger v1.12.0 以降がインストールされている。「Jaeger トレースツールのインストール」 の手順を参照してください。
手順
Jaeger トレースを機能させるには、CodeReady Workspaces デプロイメントで以下の環境変数を有効にします。
# Activating CodeReady Workspaces tracing modules CHE_TRACING_ENABLED=true # Following variables are the basic Jaeger client library configuration. JAEGER_ENDPOINT="http://jaeger-collector:14268/api/traces" # Service name JAEGER_SERVICE_NAME="che-server" # URL to remote sampler JAEGER_SAMPLER_MANAGER_HOST_PORT="jaeger:5778" # Type and param of sampler (constant sampler for all traces) JAEGER_SAMPLER_TYPE="const" JAEGER_SAMPLER_PARAM="1" # Maximum queue size of reporter JAEGER_REPORTER_MAX_QUEUE_SIZE="10000"
次の環境変数を有効にするには、以下を実行します。
CodeReady Workspaces デプロイメントの
yaml
ソースコードで、spec.server.customCheProperties
に以下の設定変数を追加します。customCheProperties: CHE_TRACING_ENABLED: 'true' JAEGER_SAMPLER_TYPE: const DEFAULT_JAEGER_REPORTER_MAX_QUEUE_SIZE: '10000' JAEGER_SERVICE_NAME: che-server JAEGER_ENDPOINT: 'http://jaeger-collector:14268/api/traces' JAEGER_SAMPLER_MANAGER_HOST_PORT: 'jaeger:5778' JAEGER_SAMPLER_PARAM: '1'
JAEGER_ENDPOINT
の値を編集して、デプロイメントの Jaeger コレクターサービスの名前に一致するようにします。メインの OpenShift Container Platform 画面の左側のメニューから、Networking → Services に移動して JAEGER_ENDPOINT の値を取得します。または、以下の
oc
コマンドを実行します。$ oc get services
要求された値は
collector
文字列が含まれるサービス名に含まれます。
関連資料
- カスタム環境プロパティーや、CheCluster カスタムリソースでの定義方法に関する詳細は、https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html-single/installation_guide/index#advanced-configuration-options-for-the-codeready-workspaces-server-component_crw を参照してください。
- Jaeger のカスタム設定については、Jaeger クライアント環境変数の一覧を参照してください。
7.5. Jaeger UI での CodeReady Workspaces トレースの表示
このセクションでは、Jaeger UI を使用して CodeReady Workspaces 操作の追跡についての概要を示す方法を説明します。
手順
この例では、CodeReady Workspaces インスタンスはしばらく実行されており、1 つのワークスペースが起動しています。
ワークスペース開始のトレースを検査するには、以下を実行します。
左側の Search パネルで、操作名(スパン名)、タグ、または期間でスパンをフィルターします。
図7.1 Jaeger UI を使用した CodeReady Workspaces の追跡
トレースを選択して拡張し、ネストされたスパンのツリーと、タグや期間などの強調表示されたスパンに関する追加情報を表示します。
図7.2 拡張されたトレースツリー
7.6. CodeReady Workspaces トレーシングコードベースの概要および拡張ガイド
CodeReady Workspaces のトレース実装のコアの部分は、che-core-tracing-core
および che-core-tracing-web
モジュールにあります。
トレース API へのすべての HTTP 要求には独自のトレースがあります。これは、サーバーアプリケーション全体にバインドされる OpenTracing ライブラリー から TracingFilter
で実行されます。@Traced
アノテーションをメソッドに追加すると、TracingInterceptor
はトレーススパンを追加します。
7.6.1. タグ付け
スパンには、操作名、スパンの起点、エラー、およびユーザーのスパンのクエリーやフィルターに役立つその他のタグなど、標準のタグが含まれる場合があります。ワークスペース関連の操作(ワークスペースの開始または停止など)には、userId
、workspaceID
、stackId
などの追加のタグが使用されます。TracingFilter
によって作成されたスパンには、HTTP ステータスコードタグもあります。
トレースメソッドでのタグの宣言は、TracingTags
クラスからフィールドを設定して静的に実行されます。
TracingTags.WORKSPACE_ID.set(workspace.getId());
TracingTags
は、それぞれの AnnotationAware
タグ実装のように、一般的に使用されるすべてのタグが宣言されるクラスです。
関連資料
Jaeger UI の使用方法についての詳細は、Jaeger ドキュメントの『Jaeger Getting Started Guide』を参照してください。
第8章 バックアップおよび障害復旧
本セクションでは、CodeReady Workspaces のバックアップおよび障害復旧機能の複数の側面について説明します。
8.1. 外部データベースの設定
PostgreSQL データベースは、CodeReady Workspaces の状態に関するデータを永続化させるために、CodeReady Workspaces サーバーによって使用されます。これには、ユーザーアカウント、ワークスペース、設定についての情報、およびその他の詳細情報が含まれます。
デフォルトで、CodeReady Workspaces Operator はデータベースデプロイメントを作成し、管理します。
ただし、CodeReady Workspaces Operator はバックアップやリカバリーなどの完全なライフサイクル機能をサポートしません。
ビジネスに不可欠な環境では、以下の推奨される障害復旧オプションを使用して外部データベースを設定します。
- 高可用性 (HA)
- PITR (Point In Time Recovery)
オンプレミスの外部 PostgreSQL インスタンスを設定するか、または Amazon Relational Database Service (Amazon RDS) などのクラウドサービスを使用します。Amazon RDS を使用すると、通常の、およびオンデマンドのスナップショットを使用して、回復性のある障害復旧ストラテジーの Multi-Availability Zone 設定で実稼働データベースをデプロイできます。
データベースサンプルの設定例は以下のようになります。
パラメーター | 値 |
---|---|
インスタンスクラス | db.t2.small |
vCPU | 1 |
RAM | 2 GB |
Multi-az | true、2 つのレプリカ |
エンジンのバージョン | 9.6.11 |
TLS | enabled |
自動化されたバックアップ | 有効 (30 日) |
8.1.1. 外部 PostgreSQL の設定
手順
以下の SQL スクリプトを使用して、CodeReady Workspaces サーバーのユーザーおよびデータベースを作成し、ワークスペースのメタデータなどを永続化させます。
CREATE USER <database-user> WITH PASSWORD '<database-password>' 1 2 CREATE DATABASE <database> 3 GRANT ALL PRIVILEGES ON DATABASE <database> TO <database-user> ALTER USER <database-user> WITH SUPERUSER
以下の SQL スクリプトを使用して、RH-SSO バックエンドのデータベースを作成して、ユーザー情報を永続化させます。
CREATE USER <identity-database-user> WITH PASSWORD '<identity-database-password>' 1 2 CREATE DATABASE <identity-database> 3 GRANT ALL PRIVILEGES ON DATABASE <identity-database> TO <identity-database-user>
8.1.2. 外部 PostgreSQL と連携するように CodeReady Workspaces を設定する
前提条件
-
oc
ツールが利用できる。
手順
CodeReady Workspaces のプロジェクトを事前に作成します。
$ oc create namespace workspaces
CodeReady Workspaces サーバーデータベースの認証情報を保存するためにシークレットを作成します。
$ oc create secret generic <server-database-credentials> \ 1 --from-literal=user=<database-user> \ 2 --from-literal=password=<database-password> \ 3 -n workspaces
RH-SSO データベース認証情報を保存するためのシークレットを作成します。
$ oc create secret generic <identity-database-credentials> \ 1 --from-literal=user=<identity-database-user> \ 2 --from-literal=password=<identity-database-password> \ 3 -n workspaces
Operator がデータベースのデプロイを省略し、既存のデータベースの接続詳細を CodeReady Workspaces サーバーに渡すには、カスタムリソースに以下の値を設定します。
spec: database: externalDb: true chePostgresHostName: <hostname> 1 chePostgresPort: <port> 2 chePostgresSecret: <server-database-credentials> 3 chePostgresDb: <database> 4 spec: auth: identityProviderPostgresSecret: <identity-database-credentials> 5
関連資料
8.2. 永続ボリュームのバックアップ
永続ボリューム (PV) は、ローカルのハードドライブのデスクトップ IDE 用にワークスペースのデータを保存する方法と同様に、CodeReady Workspaces ワークスペースデータを保存します。
データの損失を防ぐには、PV を定期的にバックアップします。PV を含む OpenShift リソースのバックアップおよび復元には、ストレージに依存しないツールを使用することが推奨されます。
8.2.1. 推奨されるバックアップツール: Velero
Velero は、OpenShift アプリケーションおよびそれらの PV をバックアップするオープンソースツールです。Velero を使用すると、以下を実行できます。
- クラウドまたはオンプレミスでデプロイします。
- データ損失が発生した場合にクラスターをバックアップし、復元します。
- クラスターリソースを他のクラスターに移行します。
- 実稼働クラスターを開発およびテスト用に複製します。
または、基礎となるストレージシステムに依存するバックアップソリューションを使用できます。たとえば、Gluster や Ceph 固有のソリューションなどがこれに含まれます。
第9章 ワークスペースの起動を迅速化するイメージのキャッシュ
このセクションでは、クラスターノードでイメージをキャッシュするために CodeReady Workspaces クラスターに Image Puller をインストールする方法を説明します。
9.1. Image Puller の概要
Red Hat CodeReady Workspaces ワークスペースの起動速度は、基礎となるクラスターがリモートレジストリーからワークスペースで使用されるイメージをプルするのを待機します。このため、プル前のイメージにより、起動時間が大幅に短縮されます。Image Puller を使用すると、事前にプルし、ワークスペースの起動時間を短縮することができます。
Image Puller は、Red Hat CodeReady Workspaces と共に実行される追加のデプロイメントです。事前にプルするイメージの一覧が指定されると、アプリケーションはクラスター内で実行され、各ノードでイメージをプルする DaemonSet を作成します。
イメージを事前にプルする最小要件は sleep
コマンドの可用性です。これは、FROM scratch
イメージ(例: 'che-machine-exec')は現時点でサポートされていないことを示しています。また、dockerfile にボリュームをマウントするイメージは、OpenShift における事前プルではサポートされません。
アプリケーションはデプロイできます。
- OperatorHub の使用または Kubernetes Image Puller Operatorのインストール
- OpenShift テンプレートを処理および適用。
Image Puller は、以下の利用可能なパラメーターを使用して ConfigMap
から設定を読み込みます。
表9.1 Image Puller のデフォルトパラメーター
パラメーター | 使用法 | デフォルト |
---|---|---|
| DaemonSet の健全性をチェックする間隔(時間) |
|
| Puller の実行時にキャッシュされる各イメージのメモリー要求。 |
|
| Puller の実行時にキャッシュされる各イメージのメモリー制限。 |
|
| Puller の実行時にキャッシュされる各イメージの CPU 要求 |
|
| Puller の実行時にキャッシュされる各イメージの CPU 制限 |
|
| 作成される DaemonSet の名前 |
|
| DaemonSet が作成される namespace |
|
|
キャッシュされるイメージの一覧 ( | デフォルトのイメージ一覧が含まれます。デプロイ前に、現在の要件を満たすイメージで入力してください。 |
| DaemonSet によって作成される Pod に適用されるノードセレクター |
|
デフォルトのメモリー要求と制限により、コンテナーを起動するのに十分なメモリーが確保されます。CACHING_MEMORY_REQUEST
または CACHING_MEMORY_LIMIT
を変更する場合、クラスターの DaemonSet Pod に割り当てられるメモリーの合計を考慮する必要があります。
(memory limit) * (number of images) * (number of nodes in the cluster)
たとえば、コンテナーのメモリー制限が 20Mi
の 20 ノードで 5 つのイメージをキャッシュする Image Puller を実行するには、2000Mi
のメモリーが必要です。
9.2. Operator を使用した Image Puller のデプロイ
Image Puller をデプロイする方法として、Operator を使用することが推奨されます。
9.2.1. OperatorHub を使用した OpenShift への Image Puller のインストール
前提条件
-
Image Puller をホストするクラスター内のプロジェクト。本書では、プロジェクト
image-puller
をサンプルとして使用します。
手順
- OpenShift クラスターコンソールに移動し、Operators → OperatorHub に移動します。
-
Filter by keyword ボックスを使用して
Kubernetes Image Puller Operator
を検索します。Kubernetes Image Puller Operator をクリックします。 - Operator の説明を確認します。Continue → Install をクリックします。
- Installation Mode について A specific project on the cluster を選択します。ドロップダウンで、Image Puller をインストールするために作成したプロジェクトを見つけます。Subscribe をクリックします。
- Kubernetes Image Puller Operator のインストールを待機します。KubernetesImagePuller → Create instance をクリックします。
-
YAML エディターのあるリダイレクトされるウィンドウで、
KubernetesImagePuller
カスタムリソースに変更を加え、Create をクリックします。 - プロジェクトの Workloads および Pods メニューに移動し、Image Puller が利用可能であることを確認します。
9.3. OpenShift テンプレートを使用した Image Puller のデプロイ
Image Puller リポジトリーには、OpenShift にデプロイするための OpenShift テンプレートが含まれます。
前提条件
- 実行中の OpenShift クラスター。
-
oc
ツールが利用できる。
OpenShift テンプレートをさらに設定するには、以下のパラメーターを使用することができます。
表9.2 OpenShift テンプレートを使用してインストールするパラメーター
値 | 使用法 | デフォルト |
---|---|---|
|
ConfigMap に設定する |
|
|
|
|
| プルするイメージタグ |
|
| デプロイメントで使用される ServiceAccount の名前(インストールの一部として作成) |
|
|
ConfigMap に設定する |
|
|
ConfigMap に設定する |
|
|
ConfigMap に設定する |
|
|
ConfigMap に設定する |
|
DAEMONSET_NAME
、CACHING_INTERVAL_HOURS
、CACHING_MEMORY_REQUEST
などの設定値の詳細は、表9.1「Image Puller のデフォルトパラメーター」 を参照してください。
表9.3 事前にプルする推奨イメージの一覧
イメージ | URL | タグ |
---|---|---|
theia-rhel8 | codeready-workspaces/theia-rhel8 | 2.5 |
theia-endpoint-rhel8 | theia-endpoint-image | 2.5 |
pluginbroker-metadata-rhel8 | registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:2.5 | 2.5 |
pluginbroker-artifacts-rhel8 | registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:2.5 | 2.5 |
plugin-java8-rhel8 | registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:2.5 | 2.5 |
plugin-java11-rhel8 | registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:2.5 | 2.5 |
plugin-kubernetes-rhel8 | registry.redhat.io/codeready-workspaces/plugin-kubernetes-rhel8:2.5 | 2.5 |
plugin-openshift-rhel8 | registry.redhat.io/codeready-workspaces/plugin-openshift-rhel8:2.5 | 2.5 |
stacks-cpp-rhel8 | registry.redhat.io/codeready-workspaces/stacks-cpp-rhel8:2.5 | 2.5 |
stacks-dotnet-rhel8 | registry.redhat.io/codeready-workspaces/stacks-dotnet-rhel8:2.5 | 2.5 |
stacks-golang-rhel8 | registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:2.5 | 2.5 |
stacks-php-rhel8 | registry.redhat.io/codeready-workspaces/stacks-php-rhel8:2.5 | 2.5 |
DAEMONSET_NAME
、CACHING_INTERVAL_HOURS
、CACHING_MEMORY_REQUEST
などの設定値の詳細は、表9.1「Image Puller のデフォルトパラメーター」 を参照してください。
手順
インストール
Kubernetes Image Puller リポジトリーのクローンを作成します。
$ git clone https://github.com/che-incubator/kubernetes-image-puller $ cd kubernetes-image-puller
Puller をデプロイするために新規 OpenShift プロジェクトを作成します。
$ oc new-project k8s-image-puller
テンプレートを処理し、これを適用して Puller をデプロイします。
CodeReady Workspaces では、カスタム値を使用してイメージ Puller をデプロイする必要があります。カスタム値を設定するには、
oc process
オプション:-p <parameterName>=<value>
に追加します。$ oc process -f deploy/openshift/serviceaccount.yaml \ | oc apply -f - $ oc process -f deploy/openshift/configmap.yaml \ -p IMAGES='plugin-java8-rhel8=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:2.5;\ theia-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:2.5;\ stacks-golang-rhel8=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:2.5;\ plugin-java11-rhel8=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:2.5;\ theia-endpoint-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:2.5;\ pluginbroker-metadata-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:2.5;\ pluginbroker-artifacts-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:2.5;' \ | oc apply -f - $ oc process -f deploy/openshift/app.yaml \ -p IMAGE=registry.redhat.io/codeready-workspaces/imagepuller-rhel8 \ -p IMAGE_TAG='2.5' \ | oc apply -f -
インストールの検証
新規デプロイメント
kubernetes-image-puller
および DaemonSet(DAEMONSET_NAME
パラメーターの値に基づいた名前)が存在することを確認します。デーモンセットでは、クラスター内の各ノードに Pod が必要です。$ oc get deployment,daemonset,pod --namespace k8s-image-puller deployment.extensions/kubernetes-image-puller 1/1 1 1 2m19s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.extensions/kubernetes-image-puller 1 1 1 1 1 <none> 2m10s NAME READY STATUS RESTARTS AGE pod/kubernetes-image-puller-5495f46497-mkd4p 1/1 Running 0 2m18s pod/kubernetes-image-puller-n8bmf 3/3 Running 0 2m10s
k8s-image-puller
という名前のConfigMap
に、パラメーターの置換で指定した値、またはデフォルト値が含まれていることを確認します。$ oc get configmap k8s-image-puller --output yaml apiVersion: v1 data: CACHING_INTERVAL_HOURS: "1" CACHING_MEMORY_LIMIT: 20Mi CACHING_MEMORY_REQUEST: 10Mi DAEMONSET_NAME: kubernetes-image-puller IMAGES: | theia-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver}; theia-endpoint-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver}; pluginbroker-metadata-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:{prod-ver}; pluginbroker-artifacts-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:{prod-ver}; plugin-java8-rhel8=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:{prod-ver}; plugin-java11-rhel8=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:{prod-ver}; stacks-golang-rhel8=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:{prod-ver}; NAMESPACE: k8s-image-puller NODE_SELECTOR: '{}' kind: ConfigMap metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"CACHING_INTERVAL_HOURS":"1","CACHING_MEMORY_LIMIT":"20Mi","CACHING_MEMORY_REQUEST":"10Mi","DAEMONSET_NAME":"kubernetes-image-puller","IMAGES":"theia-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver}; theia-endpoint-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver}; pluginbroker-metadata-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:{prod-ver}; pluginbroker-artifacts-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:{prod-ver}; plugin-java8-rhel8=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:{prod-ver}; plugin-java11-rhel8=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:{prod-ver}; stacks-golang-rhel8=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:{prod-ver};\n","NAMESPACE":"k8s-image-puller","NODE_SELECTOR":"{}"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"k8s-image-puller","namespace":"k8s-image-puller"},"type":"Opaque"} creationTimestamp: 2020-02-17T22:40:13Z name: k8s-image-puller namespace: k8s-image-puller resourceVersion: "72250" selfLink: /api/v1/namespaces/k8s-image-puller/configmaps/k8s-image-puller uid: 76430ed6-51d6-11ea-9c19-52fdfc072182