インストールガイド

Red Hat CodeReady Workspaces 2.5

Red Hat CodeReady Workspaces 2.5のインストール

概要

管理者による Red Hat CodeReady Workspaces のインストールについての情報

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージを参照してください。

第1章 サポートされるプラットフォーム

このセクションでは、OpenShift Container Platform の CodeReady Workspaces 2.5 の可用性およびサポートされるインストール方法を説明します。

Red Hat CodeReady Workspaces をサポートする最小の OpenShift Container Platform バージョンは OpenShift Container Platform 3.11 です。

表1.1 OpenShift Container Platform の CodeReady Workspaces 2.5 でサポートされるデプロイメント環境

プラットフォーム

アーキテクチャー

デプロイメント方法

OpenShift Container Platform 3.11

AMD64 および Intel 64 (x86_64)

crwctl

OpenShift Container Platform 4.5

AMD64 および Intel 64 (x86_64)

OperatorHub

OpenShift Container Platform 4.5

IBM Z (s390x)

OperatorHub

OpenShift Container Platform 4.5

IBM Power Systems (ppc64le)

OperatorHub

OpenShift Container Platform 4.6

AMD64 および Intel 64 (x86_64)

OperatorHub

OpenShift Container Platform 4.6

IBM Power Systems (ppc64le)

OperatorHub

注記
  • OpenShift Container Platform 4.5 および 4.6 では、OperatorHub インストール方法が利用できない場合に crwctl を非公式のインストール方法を使用することを検討してください。
注記

IBM Power Systems (ppc64le) および IBM Z (s390x) での OpenShift Container Platform への CodeReady Workspaces のデプロイのサポートは、現在テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。テクノロジープレビュー機能のサポートレベルの詳細は、テクノロジープレビュー機能のサポート範囲を参照してください。

第2章 CodeReady Workspaces インストールの設定

以下のセクションでは、Operator を使用して Red Hat CodeReady Workspaces をインストールする設定オプションについて説明します。

2.1. CheCluster カスタムリソースについて

CodeReady Workspaces のデフォルトデプロイメントは、Red Hat CodeReady Workspaces Operator によって準仮想化された CheCluster カスタムリソースのアプリケーションで構成されています。

CheCluster カスタムリソース
  • CodeReady Workspaces インストール全体の設定を記述する YAML ドキュメント。
  • 各コンポーネントを設定するセクション(authdatabaseserverstorage)が含まれます。
Red Hat CodeReady Workspaces Operator の役割
  • CheCluster カスタムリソースを、CodeReady Workspaces インストールの各コンポーネントで使用できる設定 (ConfigMap) に変換します。
OpenShift プラットフォームの役割
  • 各コンポーネントの設定 (ConfigMap) を適用するには、以下を実行します。
  • 必要な Pod を作成するには、以下を実行します。
  • OpenShift がコンポーネントの設定で変更を検知すると、Pod を適宜再起動します。

例2.1 CodeReady Workspaces サーバーコンポーネントの主なプロパティーの設定

  1. ユーザーは、server に関連する一部の設定が含まれる CheCluster カスタムリソースを適用します。
  2. Operator は che という必要な ConfigMap を生成します。
  3. OpenShift は ConfigMap の変更を検知し、CodeReady Workspaces Pod の再起動をトリガーします。

関連資料

2.2. CheCluster カスタムリソースフィールドの参照

このセクションでは、CheCluster カスタムリソースのカスタマイズに使用できるすべてのフィールドについて説明します。

例2.2 最小の CheCluster カスタムリソースの例。

apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: codeready-workspaces
spec:
  auth:
    externalIdentityProvider: false
  database:
    externalDb: false
  server:
    selfSignedCert: false
    gitSelfSignedCert: false
    tlsSupport: true
  storage:
    pvcStrategy: 'common'
    pvcClaimSize: '1Gi'

表2.1 CodeReady Workspaces サーバーコンポーネントに関連する CheCluster カスタムリソースの server 設定。

プロパティーデフォルト値詳細

airGapContainerRegistryHostname

省略

イメージのプルに使用する別のコンテナーレジストリーに対する、任意のホスト名または URL。この値は、CodeReady Workspaces デプロイメントに関連するすべてのデフォルトコンテナーイメージで定義されるコンテナーレジストリーのホスト名を上書きします。これは、エアギャップされた環境で CodeReady Workspaces をインストールする場合にとくに便利です。

airGapContainerRegistryOrganization

省略

イメージのプルに使用する別のコンテナーレジストリーのオプションのリポジトリー名。この値は、CodeReady Workspaces デプロイメントに関連するすべてのデフォルトコンテナーイメージで定義されるコンテナーレジストリーの組織を上書きします。これは、エアギャップされた環境で CodeReady Workspaces をインストールする場合にとくに便利です。

cheDebug

false

CodeReady Workspaces サーバーのデバッグモードを有効にします。

cheFlavor

codeready-workspaces

インストールのフレーバー。

cheHost

Operator は値を自動的に設定します。

インストールされた CodeReady Workspaces サーバーのパブリックホスト名。

cheImagePullPolicy

nightly または latest イメージの場合は Always で、他の場合は IfNotPresent

CodeReady Workspaces デプロイメントで使用されるイメージプルポリシーを上書きします。

cheImageTag

省略

CodeReady Workspaces デプロイメントで使用されるコンテナーイメージのタグを上書きします。Operator によって提供されるデフォルトのイメージタグを使用するには、これを省略するか、または空のままにします。

cheImage

省略

CodeReady Workspaces デプロイメントで使用されるコンテナーイメージを上書きします。これには、コンテナーイメージタグは含まれません。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、または空のままにします。

cheLogLevel

INFO

CodeReady Workspaces サーバーのログレベル: INFO または DEBUG

cheWorkspaceClusterRole

省略

CodeReady Workspaces ワークスペースのユーザーにバインドされるカスタムロール。デフォルトロールを使用するには、省略するか、または空のままにします。

customCheProperties

省略

CheCluster カスタムリソース (CR) の他のフィールドからすでに生成されている値に加えて、CodeReady Workspaces サーバーによって使用される生成された codeready-workspaces ConfigMap に適用される追加の環境変数のマップ。customCheProperties に他の CR フィールドから codeready-workspaces ConfigMap に生成されるプロパティーが含まれる場合、代わりに customCheProperties に定義された値が使用されます。

devfileRegistryImage

省略

Devfile レジストリーのデプロイメントで使用されるコンテナーイメージを上書きします。これには、イメージタグが含まれます。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、または空のままにします。

devfileRegistryMemoryLimit

256Mi

Devfile レジストリーのデプロイメントで使用されるメモリー制限を上書きします。

devfileRegistryMemoryRequest

16Mi

Devfile レジストリーのデプロイメントで使用されるメモリー要求を上書きします。

devfileRegistryPullPolicy

nightly または latest イメージの場合は Always で、他の場合は IfNotPresent

Devfile レジストリーのデプロイメントで使用されるイメージプルポリシーを上書きします。

devfileRegistryUrl

Operator は値を自動的に設定します。

サンプルのすぐに使用できる devfile を提供する Devfile レジストリーの公開 URL。外部の devfile レジストリーを使用する場合にこれを設定します(externalDevfileRegistry フィールドを参照)。

externalDevfileRegistry

false

Operator に対して専用の Devfile レジストリーサーバーをデプロイするよう指示します。デフォルトでは、専用の devfile レジストリーサーバーが起動します。externalDevfileRegistrytrue に設定されている場合、Operator は専用のレジストリーサーバーを自動的に開始せず、devfileRegistryUrl フィールドを手動で設定する必要があります。

externalPluginRegistry

false

Operator に対して専用の Plugin レジストリーサーバーをデプロイするよう指示します。デフォルトでは、専用のプラグインレジストリーサーバーが起動します。externalPluginRegistrytrue に設定されている場合、Operator は専用サーバーを自動的にデプロイせず、pluginRegistryUrl フィールドを手動で設定する必要があります。

nonProxyHosts

省略

設定されたプロキシーを使用しないホストの一覧。|` を区切り文字として使用します。たとえば、localhost|my.host.com|123.42.12.32 のようになります。これは、プロキシーの設定が必要な場合にのみ使用します(proxyURL フィールドも参照してください)。

pluginRegistryImage

省略

Plugin レジストリーのデプロイメントで使用されるコンテナーイメージを上書きします。これには、イメージタグが含まれます。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、または空のままにします。

pluginRegistryMemoryLimit

256Mi

Plugin レジストリーのデプロイメントで使用されるメモリー制限を上書きします。

pluginRegistryMemoryRequest

16Mi

Plugin レジストリーのデプロイメントで使用されるメモリー要求を上書きします。

pluginRegistryPullPolicy

nightly または latest イメージの場合は Always で、他の場合は IfNotPresent

Plugin レジストリーのデプロイメントで使用されるイメージプルポリシーを上書きします。

pluginRegistryUrl

Operator は値を自動的に設定します。

サンプルのすぐに使できる devfile を提供する Plugin レジストリーの公開 URL。外部の devfile レジストリーを使用する場合のみこれを設定します(externalPluginRegistry フィールドを参照)。

proxyPassword

省略

プロキシーサーバーのパスワード。プロキシー設定が必要である場合にのみ使用します。

proxyPort

省略

プロキシーサーバーのポート。プロキシーの設定が必要な場合にのみ使用します(proxyURL フィールドも参照してください)。

proxyURL

省略

プロキシーサーバーの URL (プロトコル+ホスト名)。これにより、CodeReady Workspaces サーバーおよびワークスペースコンテナーの JAVA_OPTS および https_proxy 変数に適切な変更が加えられます。プロキシーの設定が必要な場合にのみ使用します。

proxyUser

省略

プロキシーサーバーのユーザー名。プロキシーの設定が必要な場合にのみ使用します(proxyURL フィールドも参照してください)。

serverMemoryLimit

1Gi

CodeReady Workspaces サーバーのデプロイメントで使用されるメモリー制限を上書きします。

serverMemoryRequest

512Mi

CodeReady Workspaces サーバーのデプロイメントで使用されるメモリー要求を上書きします。

tlsSupport

true

Operator に対して CodeReady Workspaces を TLS モードでデプロイするように指示します。

表2.2 CodeReady Workspaces で使用されるデータベースに関連する CheCluster カスタムリソース database 設定。

プロパティーデフォルト値詳細

chePostgresDb

dbche

CodeReady Workspaces サーバーがデータベースへの接続に使用する PostgreSQL データベース名。

chePostgresHostName

Operator は値を自動的に設定します。

CodeReady Workspaces サーバーが接続する PostgreSQL Database のホスト名。デフォルトは postgres です。外部データベースを使用する場合、この値のみを上書きします。externalDb フィールドを参照してください。

chePostgresPassword

自動生成される値

CodeReady Workspaces サーバーがデータベースへの接続に使用する PostgreSQL パスワード。

chePostgresPort

5432

CodeReady Workspaces サーバーが接続する PostgreSQL Database ポート。外部データベースを使用する場合、この値のみを上書きします(フィールド externalDbを参照)。

chePostgresUser

pgche

CodeReady Workspaces サーバーがデータベースへの接続に使用する PostgreSQL ユーザー。

externalDb

false

Operator に対して専用のデータベースをデプロイするよう指示します。デフォルトでは、専用の PostgreSQL データベースは CodeReady Workspaces インストールの一部としてデプロイされます。true に設定すると、Operator は専用のデータベースを自動的にデプロイしません。また、外部データベースへの接続の詳細を指定する必要があります。chePostgres で始まるすべてのフィールドを参照してください。

postgresImagePullPolicy

nightly または latest イメージの場合は Always で、他の場合は IfNotPresent

PostgreSQL データベースのデプロイメントで使用されるイメージプルポリシーを上書きします。

postgresImage

省略

PostgreSQL データベースのデプロイメントで使用されるコンテナーイメージを上書きします。これには、イメージタグが含まれます。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、または空のままにします。

表2.3 CheCluster CodeReady Workspaces インストールで使用される認証に関連するカスタムリソース auth 設定。

プロパティーデフォルト値詳細

externalIdentityProvider

false

デフォルトで、専用のアイデンティティープロバイダーサーバーは CodeReady Workspaces インストールの一部としてデプロイされます。ただし、externalIdentityProvidertrue の場合、専用のアイデンティティープロバイダーは Operator によってデプロイされず、使用する外部アイデンティティープロバイダーの詳細を指定しなければいけない場合があります。identityProvider で始まるその他のフィールドもすべて参照してください。

identityProviderAdminUserName

admin

アイデンティティープロバイダーの管理者ユーザーの名前を上書きします。

identityProviderClientId

省略

CodeReady Workspaces に使用するアイデンティティープロバイダー(RH-SSO) client-id の名前。これは、外部アイデンティティープロバイダーを使用する場合のみオーバーライドするのに役立ちます(externalIdentityProvider フィールドを参照)。省略されているか、または空のままの場合は、サフィックスが -publicflavor フィールドの値に設定されます。

identityProviderImagePullPolicy

nightly または latest イメージの場合は Always で、他の場合は IfNotPresent

アイデンティティープロバイダー (RH-SSO) デプロイメントで使用するイメージプルポリシーを上書きします。

identityProviderImage

省略

アイデンティティープロバイダー(RH-SSO)デプロイメントで使用されるコンテナーイメージを上書きします。これには、イメージタグが含まれます。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、または空のままにします。

identityProviderPassword

省略

RH-SSO admin ユーザーのパスワードを上書きします。外部アイデンティティープロバイダーを使用する場合にのみ上書きします(externalIdentityProvider フィールドを参照)。自動生成されるパスワードを設定するには省略するか、空のままにします。

identityProviderPostgresPassword

Operator は値を自動的に設定します。

データベースに接続するために使用するアイデンティティープロバイダー (RH-SSO) のパスワードこれは、外部アイデンティティープロバイダーを使用する場合のみオーバーライドするのに役立ちます(externalIdentityProvider フィールドを参照)。

identityProviderRealm

省略

アイデンティティープロバイダー(RH-SSO)レルムの名前。外部アイデンティティープロバイダーを使用する場合にのみ上書きします(externalIdentityProvider フィールドを参照)。flavor フィールドの値に設定する場合は、省略するか、空欄のままにします。

identityProviderURL

Operator は値を自動的に設定します。

専用のアイデンティティープロバイダー (RH-SSO インスタンス) をデプロイすることを Operator に指示します。アイデンティティープロバイダーサーバー (RH-SSO サーバー) の公開 URL。外部アイデンティティープロバイダーを使用する場合にのみ設定します(externalIdentityProvider フィールドを参照)。

oAuthClientName

Operator は値を自動的に設定します。

OpenShift 側でアイデンティティーフェデレーションを設定するために使用される OpenShift OAuthClient リソースの名前。OpenShiftoAuth フィールドも参照してください。

oAuthSecret

Operator は値を自動的に設定します。

OpenShift 側でアイデンティティーフェデレーションを設定するために使用される OpenShift OAuthClient リソースに設定されたシークレットの名前。OAuthClientName フィールドも参照してください。

openShiftoAuth

OpenShift 上の true

アイデンティティープロバイダー (RH-SSO / RHSSO) と OpenShift OAuth の統合を有効にします。これにより、ユーザーは OpenShift ログインでログインでき、独自のワークスペースを個人の OpenShift プロジェクトに作成することができます。kubeadmin ユーザーはサポートされておらず、CodeReady Workspaces ダッシュボードへのアクセスを許可しません。

updateAdminPassword

false

デフォルトの admin CodeReady Workspaces ユーザーの初回ログイン時のパスワードの更新を強制します。

表2.4 CodeReady Workspaces で使用される永続ストレージに関連する CheCluster カスタムリソース storage 設定。

プロパティーデフォルト値詳細

postgresPVCStorageClassName

省略

PostgreSQL データベース専用の Persistent Volume Claim (永続ボリューム要求、PVC) のストレージクラス。デフォルトのストレージクラスを使用するには省略されるか、または空のままにします。

preCreateSubPaths

false

CodeReady Workspace サーバーに対し、永続ボリュームでサブパスを事前に起動するために特別な Pod を起動するように指示します。K8S クラスターの設定に合わせて有効にします。

pvcClaimSize

1Gi

ワークスペースの永続ボリューム要求 (PVC) のサイズ。

pvcJobsImage

省略

永続ボリュームでサブパスを作成するために使用されるコンテナーイメージを上書きします。これには、イメージタグが含まれます。Operator によって提供されるデフォルトのコンテナーイメージを使用するには、これを省略するか、または空のままにします。preCreateSubPaths フィールドも参照してください。

pvcStrategy

common

利用可能なオプション: 'common' (1 つのボリュームにすべてのワークスペース PVC)、per-workspace (すべての宣言されたボリュームについてワークスペースごとに 1 つの PVC)、および unique (宣言されたボリュームごとに 1 つの PVC) を指定できます。

workspacePVCStorageClassName

省略

CodeReady Workspace ワークスペース専用の Persistent Volume Claim(永続ボリューム要求、PVC)のストレージクラス。デフォルトのストレージクラスを使用するには、省略するか、または空のままにします。

表2.5 OpenShift の CodeReady Workspaces インストールに固有の CheCluster カスタムリソース k8s 設定。

プロパティーデフォルト値詳細

ingressClass

nginx

Ingress を管理するコントローラーを定義する Ingress クラス。

ingressDomain

省略

K8S クラスターのグローバル Ingress ドメイン。このフィールドは明示的に指定する必要があります。これは CodeReady Workspaces 関連の Ingress で kubernetes.io/ingress.class アノテーションを実行します。

ingressStrategy

multi-host

Ingress 作成のストラテジー。これは、multi-host (ホストは Ingress で明示的に指定されます)、single-host (ホストは指定される、パスベースのルール)、および default-host.* (ホストは指定されない、パスベースのルール)。

securityContextFsGroup,omitempty

1724

CodeReady Workspaces Pod および Workspace Pod コンテナを実行する FSGroup。

securityContextRunAsUser

1724

CodeReady Workspaces Pod および Workspace Pod コンテナーを実行するユーザーの ID。

tlsSecretName

省略

TLS が有効になっている場合に Ingress TLS 終端を設定するために使用されるシークレットの名前。tlsSupport フィールドも参照してください。

表2.6 CheCluster カスタムリソース status は、CodeReady Workspaces インストールの観察される状態を定義します。

プロパティー詳細

cheClusterRunning

CodeReady Workspaces インストールのステータス。AvailableUnavailable まてゃあ Available, Rolling Update in Progress を使用できます。

cheURL

CodeReady Workspaces サーバーへの公開 URL。

cheVersion

現在インストールされている CodeReady Workspaces バージョン。

dbProvisioned

PostgreSQL インスタンスが正しくプロビジョニングされているかどうかを示します。

devfileRegistryURL

Devfile レジストリーへの公開 URL。

helpLink

現在の Operator ステータスに関連するヘルプの検索に使用する URL。

keycloakProvisioned

アイデンティティープロバイダーインスタンス (RH-SSO / RH SSO) がレルム、クライアント、およびユーザーと共にプロビジョニングされているかどうかを示します。

keycloakURL

アイデンティティープロバイダーサーバー (RH-SSO / RH SSO) の公開 URL。

message

Pod がこの状態にある理由の詳細を含む、人間が判読できるメッセージ。

openShiftoAuthProvisioned

アイデンティティープロバイダーインスタンス (RH-SSO / RH SSO) が OpenShift OAuth と統合するように設定されているかどうかを示します。

pluginRegistryURL

Plugin レジストリーへの公開 URL。

reason

Pod がこの状態にある理由の詳細を含む簡単な CamelCase メッセージ。

第3章 CodeReady Workspaces のインストール

本セクションでは、Red Hat CodeReady Workspaces をインストールする手順を説明します。インストール方法は、ターゲットプラットフォームと環境の制限によって異なります。

3.1. OperatorHub を使用した OpenShift 4 への CodeReady Workspaces のインストール

本セクションでは、OpenShift 4 Web コンソールで利用可能な CodeReady Workspaces Operator を使用して CodeReady Workspaces をインストールする方法を説明します。

Operator は、OpenShift アプリケーションをパッケージ化し、デプロイし、管理する方法です。これは、以下も提供します。

  • インストールおよびアップグレードの再現性。
  • すべてのシステムコンポーネントの定期的なヘルスチェック。
  • OpenShift コンポーネントおよび独立ソフトウェアベンダー (ISV) コンテンツの OTA (Over-the-air) 更新。
  • フィールドエンジニアの知識をカプセル化し、すべてのユーザーに展開する場所。

前提条件

  • OpenShift 4 の実行中のインスタンスの管理者アカウント

3.1.1. OpenShift Web コンソールでのプロジェクトの作成

プロジェクトを使用すると、クラスターの異なるリソースを分離された単位で編成し、管理できます。まずプロジェクトを作成し、Red Hat CodeReady Workspaces Operator をホストします。

手順

  1. OpenShift Web コンソールを開きます。左側のパネルで HomeProjects セクションに移動します。
  2. Create Project をクリックします。
  3. プロジェクトの詳細を指定します。

    • Name: workspaces
    • Display Name: Red Hat CodeReady Workspaces
    • Description: Red Hat CodeReady Workspaces

3.1.2. Red Hat CodeReady Workspaces Operator のインストール

Red Hat CodeReady Workspaces Operator は、PostgreSQL、RH-SSO、イメージレジストリー、CodeReady Workspaces サーバーなどの CodeReady Workspaces を実行するためのすべてのリソースを提供し、これらのすべてのサービスも設定します。

前提条件

  • クラスターの Web コンソールへのアクセス。

手順

  1. Red Hat CodeReady Workspaces Operator をインストールするには、左側のパネルで OperatorsOperatorHub セクションに移動します。
  2. Filter by keyword フィールドに Red Hat CodeReady Workspaces を入力し、Red Hat CodeReady Workspaces タイルをクリックします。
  3. Red Hat CodeReady Workspaces のポップアップウィンドウで、Install ボタンをクリックします。
  4. Install Operator 画面で、以下のオプションを指定します。

    • Installation mode: A specific project on the cluster
    • Installed Namespace: *既存プロジェクトを選択 → workspaces

検証手順

  1. Red Hat CodeReady Workspaces Operator が正しくインストールされたことを確認するには、左側のパネルで OperatorsInstalled Operators セクションに移動します。
  2. Installed Operators 画面で、Red Hat CodeReady Workspaces 名をクリックし、Details タブに移動します。
  3. ページの下部にある ClusterServiceVersion Details セクションで、以下のメッセージを待機します。

    • Status: Succeeded
    • Status Reason: install strategy completed with no errors
  4. Events タブに移動し、install strategy completed with no errors メッセージが表示されるまで待機します。

3.1.3. Red Hat CodeReady Workspaces Operator のインスタンスの作成

以下の手順に従って、デフォルト設定で Red Hat CodeReady Workspaces をインストールします。設定を変更する場合は、2章CodeReady Workspaces インストールの設定 を参照してください。

手順

  1. Red Hat CodeReady Workspaces Operator のインスタンスを作成するには、左側のパネルで OperatorsInstalled Operators セクションに移動します。
  2. Installed Operators 画面で、Red Hat CodeReady Workspaces 名をクリックします。
  3. Operator Details 画面の Provided APIs セクション内の Details タブで Create Instance リンクをクリックします。
  4. Create CheCluster ページには、作成する CodeReady Workspaces インスタンス全体の設定が含まれます。これは、CheCluster カスタムリソースです。デフォルト値を維持します。
  5. codeready-workspaces クラスターを作成するには、ウィンドウの左下にある Create ボタンをクリックします。
  6. Operator Details 画面の、Red Hat CodeReady Workspaces Cluster タブで、codeready-workspaces リンクをクリックします。
  7. codeready-workspaces インスタンスに移動するには、Red Hat CodeReady Workspaces URL の下にあるリンクをクリックします。

    注記

    インストールには 5 分以上かかる場合があります。Red Hat CodeReady Workspaces インストールが完了すると、URL が表示されます。

検証手順

  1. Red Hat CodeReady Workspaces インスタンスが正しくインストールされたことを確認するには、CodeReady Workspaces Cluster タブに移動します。CheClusters 画面には、Red Hat CodeReady Workspaces インスタンスの一覧とそのステータスが表示されます。
  2. テーブルの codeready-workspaces CheCluster をクリックし、Details タブに移動します。
  3. 以下のフィールドの内容を参照してください。

    • Message: このフィールドにはエラーメッセージが含まれます (ある場合)。予想される内容は None です。
    • Red Hat CodeReady Workspaces URL: デプロイメントが成功した場合に、Red Hat CodeReady Workspaces インスタンスの URL を表示します。
  4. Resources タブに移動します。画面には、CodeReady Workspaces デプロイメントに割り当てられたリソースの一覧が表示されます。
  5. リソースの状態の詳細を確認するには、その名前をクリックして、利用可能なタブの内容を検査します。

関連資料

3.2. CodeReady Workspaces の OpenShift Container Platform 3.11 へのインストール

3.2.1. crwctl CLI 管理ツールのインストール

本セクションでは、CodeReady Workspaces CLI 管理ツールを使用して crwctl をインストールする方法を説明します。

手順

  1. https://developers.redhat.com/products/codeready-workspaces/download に移動します。
  2. バージョン 2.5 の CodeReady Workspaces CLI 管理ツールアーカイブをダウンロードします。
  3. ${HOME}/crwctl または /opt/crwctl などのフォルダーにアーカイブを展開します。
  4. 展開したフォルダーから crwctl の実行可能ファイルを実行します。この例では ${HOME}/crwctl/bin/crwctl version です。
  5. オプションで、binフォルダーを $PATH (例: PATH=${PATH}:${HOME}/crwctl/bin)に追加し、完全パスの指定なしで crwctl の実行を有効にします。

検証手順

crwctl version を実行すると、ツールの現在のバージョンが表示されます。

3.2.2. Operator を使用した CodeReady Workspaces の OpenShift 3 へのインストール

本セクションでは、crwctl CLI 管理ツールを使用して、OpenShift 3 に CodeReady Workspaces をインストールする方法を説明します。このインストールの方法では Operator を使用し、TLS (HTTPS) を有効にします。

注記

直前の CodeReady Workspaces インストールから更新し、同じ OpenShift Container Platform 3.11 クラスターで複数のインスタンスを有効にする方法は、インストール手順で説明されます。

Operator は、OpenShift アプリケーションをパッケージ化し、デプロイし、管理する方法です。これは、以下も提供します。

  • インストールおよびアップグレードの再現性。
  • すべてのシステムコンポーネントの定期的なヘルスチェック。
  • OpenShift コンポーネントおよび独立ソフトウェアベンダー (ISV) コンテンツの OTA (Over-the-air) 更新。
  • フィールドエンジニアの知識をカプセル化し、すべてのユーザーに展開する場所。
注記

この方法は、OpenShift Container Platform および OpenShift Dedicated バージョン 3.11 でのみサポートされますが、OpenShift Container Platform および OpenShift Dedicated の新しいバージョンでも機能し、OperatorHub を使用したインストール方法が利用できない場合にバックアップのインストール方法として機能します。

前提条件

  • OpenShift 3.11 の実行中のインスタンスでの管理者権限
  • oc OpenShift 3.11 CLI 管理ツールのインストール。「Installing the OpenShift 3.11 CLI」を参照してください。
  • crwctl 管理ツールのインストール。「crwctl CLI 管理ツールのインストール」 を参照してください。
  • 主な crwctl コマンドラインパラメーターが設定できない設定を適用するには、Operator で使用される CheCluster カスタムリソースのデフォルト値を上書きする設定ファイル operator-cr-patch.yaml を準備します。2章CodeReady Workspaces インストールの設定 を参照してください。
  • <namespace> はターゲットインストールのプロジェクトを表します。

手順

  1. OpenShift にログインします。「Basic Setup and Login」を参照してください。

    $ oc login
  2. 以下のコマンドを実行して、oc OpenShift CLI 管理ツールのバージョンが 3.11 であることを確認します。

    $ oc version
    oc v3.11.0+0cbc58b
  3. 以下のコマンドを実行して、CodeReady Workspaces インスタンスを作成します。

    • ユーザー定義の <namespace> で以下を行います。

      $ crwctl server:deploy -n <namespace> -p openshift
    • workspaces というデフォルトプロジェクトで以下を実行します。

      $ crwctl server:deploy -p openshift

検証手順

  1. 上記のコマンドの出力は以下で終わります。

    Command server:deploy has completed successfully.
  2. CodeReady Workspaces クラスターインスタンス: \https://codeready-<openshift_deployment_name>.<domain_name> に移動します。

複数の CodeReady Workspaces デプロイメントの指定

  • 同じ OpenShift Container Platform 3.11 クラスターで異なるバージョンを使用し、複数の CodeReady Workspaces デプロイメントを並行して利用可能にするには、新規デプロイメント用に新規のサービスアカウントを作成します。ただし、バージョンの組み合わせによって予期しない結果やサポートされていない結果が発生する可能性があるため、以前のすべての CodeReady Workspaces デプロイメントを最新バージョンに更新することが強く推奨されます。

    $ oc patch clusterrolebinding codeready-operator \
        --type='json' \
        -p '[{"op": "add", "path": "/subjects/0", "value": {"kind":"ServiceAccount", "namespace": "<workspaces>", "name": "codeready-operator"} }]'

3.3. 制限された環境での CodeReady Workspaces のインストール

デフォルトでは、Red Hat CodeReady Workspaces は、パブリックレジストリーで利用可能なコンテナーイメージを主として、各種の外部リソースを使用します。

これらの外部リソースが利用できない環境に CodeReady Workspaces をデプロイするには (例: 公開インターネットに公開されていないクラスターなど)、以下を実行します。

  1. OpenShift クラスターによって使用されるイメージレジストリーを特定し、これにプッシュできることを確認します。
  2. CodeReady Workspaces の実行に必要なすべてのイメージをこのレジストリーにプッシュします。
  3. レジストリーにプッシュされたイメージを使用するように CodeReady Workspaces を設定します。
  4. CodeReady Workspaces インストールに進みます。

制限された環境で CodeReady Workspaces をインストールする手順は、使用するインストール方法によって異なります。

制限された環境でのネットワーク接続に関する注

ネットワークが制限された環境は、クラウドプロバイダーのプライベートサブネットから、公開インターネットから切断された会社が所有する別個のネットワークに制限されます。ネットワーク設定に関係なく、CodeReady Workspaces は、CodeReady Workspaces コンポーネント (codeready-workspaces-server、アイデンティティープロバイダー、devfile、およびプラグインレジストリー) 用に作成されたルートが OpenShift クラスター内からアクセスできる場合 に機能します。

環境のネットワークトポロジーを考慮して、これを実行する最も良い方法を判断します。たとえば、会社または組織が所有するネットワークでは、ネットワーク管理者は、クラスターからのトラフィックがルートホスト名にルーティングできるようにする必要があります。たとえば、AWS で、トラフィックがノードを出て、外部に表示されるロードバランサーに到達できるようにプロキシー設定を作成します。

ネットワークが制限された環境にプロキシーが必要な場合は、「プロキシーの後ろでインストールするための CodeReady Workspaces カスタムリソースの準備」 に記載の手順に従います。

3.3.1. OperatorHub を使用した制限された環境での CodeReady Workspaces のインストール

前提条件

ネットワークが制限された環境で実行される非接続 OpenShift 4 クラスターでは、Operator が ネットワークが制限された環境についての Operator の有効化について定義された追加要件を満たす場合にのみ、Operator を OperatorHub からインストールできます。

CodeReady Workspaces Operator はこれらの要件を満たしているので、ネットワークが制限された環境での OLM に関する公式ドキュメントに記載の内容と互換性があります。

手順

OperatorHub から CodeReady Workspaces をインストールするには、以下を実行します。

  1. redhat-operators カタログイメージをビルドします。「Building an Operator catalog image」を参照してください。
  2. OperatorHub を、Operator のインストールにこのカタログイメージを使用するように設定します。「Configuring OperatorHub for restricted networks」を参照してください。
  3. 「OperatorHub を使用した OpenShift 4 への CodeReady Workspaces のインストール」 の説明に従って、通常通りに CodeReady Workspaces のインストールに進みます。

3.3.2. CLI 管理ツールを使用した制限された環境での CodeReady Workspaces のインストール

注記

OperatorHub を使用したインストールが利用できない場合、CodeReady Workspaces CLI 管理ツールを使用して制限されたネットワークに CodeReady Workspaces をインストールします。この方法は OpenShift Container Platform 3.11 でサポートされます。

前提条件

3.3.2.1. プライベートレジストリーの準備

前提条件

  • oc ツールが利用できる。
  • skopeo ツール(バージョン 0.1.40 以降)が利用できる。
  • podman ツールが利用できる。
  • OpenShift クラスターからアクセスできるイメージ、および V2 イメージマニフェスト (スキーマバージョン 2) フォーマットのサポート。インターネットへのアクセスが一時的に可能な場所から、これにプッシュできることを確認します。

表3.1 サンプルで使用されるプレースホルダー

<source-image>

レジストリー、組織、およびダイジェストなどのソースイメージの詳細な組み合わせ (coordinate)。

<target-registry>

ターゲットコンテナーイメージレジストリーのホスト名およびポート。

<target-organization>

ターゲットのコンテナーイメージレジストリー内の組織

<target-image>

ターゲットのコンテナーイメージレジストリーのイメージ名とダイジェスト。

<target-user>

ターゲットのコンテナーイメージレジストリーのユーザー名。

<target-password>

ターゲットのコンテナーイメージレジストリーのユーザーパスワード。

手順

  1. 内部イメージレジストリーにログインします。

    $ podman login --username <user> --password <password> <target-registry>
    警告

    内部レジストリーへのプッシュを試行する際に x509: certificate signed by unknown authority などのエラーが発生した場合には、以下のいずれかの回避策を試してください。

    • OpenShift クラスターの証明書を /etc/containers/certs.d/<target-registry>に追加します。
    • /etc/containers/registries.conf にある Podman 設定ファイルに以下の行を追加して、レジストリーを非セキュアなレジストリーとして追加する。
    [registries.insecure]
    registries = ['<target-registry>']
  2. ダイジェストを変更せずにイメージをコピーします。以下の表のすべてのイメージに対して、この手順を繰り返します。

    $ skopeo copy --all docker://<source-image> docker://<target-registry>/<target-organization>/<target-image>
    注記

    表3.2 名前に含まれるプレフィックスまたはキーワードからの container-images の使用について

    使用プレフィックスまたはキーワード

    Essential

    stacks-, plugin- または -openj9- ではない

    Workspaces

    stacks-, plugin-

    IBM Z および IBM Power Systems

    -openj9-

    表3.3 プライベートレジストリーでコピーするイメージ

    <source-image><target-image>

    registry.redhat.io/codeready-workspaces/configbump-rhel8@sha256:30f61524365f0d36bbe1208df77dd5cbe75b3f9e5c979305566e46ccac139dac

    configbump-rhel8@sha256:30f61524365f0d36bbe1208df77dd5cbe75b3f9e5c979305566e46ccac139dac

    registry.redhat.io/codeready-workspaces/crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    registry.redhat.io/codeready-workspaces/crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    registry.redhat.io/codeready-workspaces/devfileregistry-rhel8@sha256:58e961fa91492fd13ccb2c39afb201431f187301a2a192ab683ee202c9fe8c55

    devfileregistry-rhel8@sha256:58e961fa91492fd13ccb2c39afb201431f187301a2a192ab683ee202c9fe8c55

    registry.redhat.io/codeready-workspaces/jwtproxy-rhel8@sha256:79783bfaedce74edcb9681baab0a33dd40268f721642c31ca5319b4b47219cb7

    jwtproxy-rhel8@sha256:79783bfaedce74edcb9681baab0a33dd40268f721642c31ca5319b4b47219cb7

    registry.redhat.io/codeready-workspaces/machineexec-rhel8@sha256:a493fcb94465bdbc2c61250a0cacd95b0b5bb46618e9b5fd49e5902341ed0fcd

    machineexec-rhel8@sha256:a493fcb94465bdbc2c61250a0cacd95b0b5bb46618e9b5fd49e5902341ed0fcd

    registry.redhat.io/codeready-workspaces/plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    registry.redhat.io/codeready-workspaces/plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    registry.redhat.io/codeready-workspaces/plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    registry.redhat.io/codeready-workspaces/plugin-java11-rhel8@sha256:641e223f5efbc32bab3461aa000e3a50a5dcca063331322158d1c959129ffd99

    plugin-java11-rhel8@sha256:641e223f5efbc32bab3461aa000e3a50a5dcca063331322158d1c959129ffd99

    registry.redhat.io/codeready-workspaces/plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    registry.redhat.io/codeready-workspaces/plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    registry.redhat.io/codeready-workspaces/plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    registry.redhat.io/codeready-workspaces/plugin-java8-rhel8@sha256:5b2df65e7ec4676a43b763b431744790a89acd5c6d197316b694693b58c19770

    plugin-java8-rhel8@sha256:5b2df65e7ec4676a43b763b431744790a89acd5c6d197316b694693b58c19770

    registry.redhat.io/codeready-workspaces/plugin-kubernetes-rhel8@sha256:5821febf70c74ed560a372f990e9fab9baa47f659ef9450b7881072e3cb40399

    plugin-kubernetes-rhel8@sha256:5821febf70c74ed560a372f990e9fab9baa47f659ef9450b7881072e3cb40399

    registry.redhat.io/codeready-workspaces/plugin-openshift-rhel8@sha256:7772bc9073e64713ebbfc1a950cc3cbe21ed7301c65f84bb509fa2b6e71fa81d

    plugin-openshift-rhel8@sha256:7772bc9073e64713ebbfc1a950cc3cbe21ed7301c65f84bb509fa2b6e71fa81d

    registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8@sha256:dc191ef97b01d0afedab6ccdb8c303f32d046f7eccf9f452eb30e615f2a0bf0e

    pluginbroker-artifacts-rhel8@sha256:dc191ef97b01d0afedab6ccdb8c303f32d046f7eccf9f452eb30e615f2a0bf0e

    registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8@sha256:dbd839715c80db641c1505a0fa6f96969cf8cc4aa8c4db95b40626f95854a525

    pluginbroker-metadata-rhel8@sha256:dbd839715c80db641c1505a0fa6f96969cf8cc4aa8c4db95b40626f95854a525

    registry.redhat.io/codeready-workspaces/pluginregistry-rhel8@sha256:c9f48f247cff27280587aeff54cea5d8a27e0eb55c99a73726cd7d575db7fbcc

    pluginregistry-rhel8@sha256:c9f48f247cff27280587aeff54cea5d8a27e0eb55c99a73726cd7d575db7fbcc

    registry.redhat.io/codeready-workspaces/server-rhel8@sha256:feb6c83be2b1e6edc56287d2c9ed66a82522a297f88b495aeddd0778fb9d1f57

    server-rhel8@sha256:feb6c83be2b1e6edc56287d2c9ed66a82522a297f88b495aeddd0778fb9d1f57

    registry.redhat.io/codeready-workspaces/stacks-cpp-rhel8@sha256:4bc877635a0feae47d259a232cca84130dc1f36890f76e39f422024372830bcb

    stacks-cpp-rhel8@sha256:4bc877635a0feae47d259a232cca84130dc1f36890f76e39f422024372830bcb

    registry.redhat.io/codeready-workspaces/stacks-dotnet-rhel8@sha256:a61038e596c0c6104ae86cf4c5af5c60a6126feefa6e6585c540de2c48b723a2

    stacks-dotnet-rhel8@sha256:a61038e596c0c6104ae86cf4c5af5c60a6126feefa6e6585c540de2c48b723a2

    registry.redhat.io/codeready-workspaces/stacks-golang-rhel8@sha256:4ecb4f5fe6917a0e54cdaa8bb8332a06472debc8a12e8c948d7abbb6e90a95f0

    stacks-golang-rhel8@sha256:4ecb4f5fe6917a0e54cdaa8bb8332a06472debc8a12e8c948d7abbb6e90a95f0

    registry.redhat.io/codeready-workspaces/stacks-php-rhel8@sha256:d07364b8556e2f6689fa59fafefbaad3bb8c63b47e3e51be59521d38816a13db

    stacks-php-rhel8@sha256:d07364b8556e2f6689fa59fafefbaad3bb8c63b47e3e51be59521d38816a13db

    registry.redhat.io/codeready-workspaces/theia-endpoint-rhel8@sha256:bbd5b5fce80594d68a266128f607176a2f392829b969deafd848306d90c265e3

    theia-endpoint-rhel8@sha256:bbd5b5fce80594d68a266128f607176a2f392829b969deafd848306d90c265e3

    registry.redhat.io/codeready-workspaces/theia-rhel8@sha256:3713798c7f61c3863afd4f501806df2fe462d8e3be37ab9e572940bf7a6facc0

    theia-rhel8@sha256:3713798c7f61c3863afd4f501806df2fe462d8e3be37ab9e572940bf7a6facc0

    registry.redhat.io/codeready-workspaces/traefik-rhel8@sha256:c7ab18087c660f35386268053f29ebd2dc55163d2fd7956f0fdc227938b136ed

    traefik-rhel8@sha256:c7ab18087c660f35386268053f29ebd2dc55163d2fd7956f0fdc227938b136ed

    registry.redhat.io/jboss-eap-7/eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    registry.redhat.io/jboss-eap-7/eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    registry.redhat.io/jboss-eap-7/eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    registry.redhat.io/jboss-eap-7/eap-xp1-openjdk11-openshift-rhel8@sha256:94e1cd4eb4196a358e301c1992663258c0016c80247f507fd1c39cf9a73da833

    eap-xp1-openjdk11-openshift-rhel8@sha256:94e1cd4eb4196a358e301c1992663258c0016c80247f507fd1c39cf9a73da833

    registry.redhat.io/jboss-eap-7/eap73-openjdk8-openshift-rhel7@sha256:24dea0cfc154a23c1aeb6b46ade182d0f981362f36b7e6fb9c7d8531ac639fe0

    eap73-openjdk8-openshift-rhel7@sha256:24dea0cfc154a23c1aeb6b46ade182d0f981362f36b7e6fb9c7d8531ac639fe0

    registry.redhat.io/rh-sso-7/sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    registry.redhat.io/rh-sso-7/sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    registry.redhat.io/rh-sso-7/sso74-openshift-rhel8@sha256:c0045cd676e06eb17083a44c4b90b29b11ddb40e1fb6a7b651384cf0960f5158

    sso74-openshift-rhel8@sha256:c0045cd676e06eb17083a44c4b90b29b11ddb40e1fb6a7b651384cf0960f5158

    registry.redhat.io/rhel8/postgresql-96@sha256:5b5bf623d89deda89250f422d352b122bce9533b902b5474f9c63a9facc7a6f1

    postgresql-96@sha256:5b5bf623d89deda89250f422d352b122bce9533b902b5474f9c63a9facc7a6f1

    registry.redhat.io/rhscl/mongodb-36-rhel7@sha256:9f799d356d7d2e442bde9d401b720600fd9059a3d8eefea6f3b2ffa721c0dc73

    mongodb-36-rhel7@sha256:9f799d356d7d2e442bde9d401b720600fd9059a3d8eefea6f3b2ffa721c0dc73

    registry.redhat.io/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187aadb32e89fd83fa455ebaa6

    ubi8ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187aadb32e89fd83fa455ebaa6

検証手順

  • イメージに同じダイジェストがあることを確認します。

    $ skopeo inspect docker://<source-image>
    $ skopeo inspect docker://<target-registry>/<target-organization>/<target-image>

関連資料

3.3.2.2. 制限された環境用の CodeReady Workspaces カスタムリソースの準備

crwctl または OperatorHub を使用して制限された環境で CodeReady Workspaces をインストールする場合は、CheCluster カスタムリソースに追加の情報を提供します。

3.3.2.2.1. デフォルトの CheCluster カスタムリソースのダウンロード

手順

  1. デフォルトのカスタムリソース YAML ファイルをダウンロードします。
  2. ダウンロードしたカスタムリソース org_v1_che_cr.yaml に名前を付けます。追加の変更および使用に備えてこれを保持します。
3.3.2.2.2. 制限された環境での CheCluster カスタムリソース のカスタマイズ

前提条件

  • CodeReady Workspaces がデプロイされる OpenShift クラスターに表示されるイメージレジストリーの利用可能な必要なすべてのイメージ。これについては、「プライベートレジストリーの準備」で説明されています。ここでは、以下の例で使用されているプレースホルダーも定義されています。

手順

  1. CodeReady Workspaces Operator によって管理される CheCluster カスタムリソースで、制限された環境で CodeReady Workspaces のインスタンスのデプロイを容易にするために使用されるフィールドを追加します。

    # [...]
    spec:
      server:
        airGapContainerRegistryHostname: '<target-registry>'
        airGapContainerRegistryOrganization: '<target-organization>'
    # [...]

3.3.2.3. CodeReady Workspaces CLI 管理ツールを使用した制限された環境での CodeReady Workspaces インストールの開始

本セクションでは、CodeReady Workspaces CLI 管理ツールを使用して、制限された環境で CodeReady Workspaces インストールを開始する方法を説明します。

前提条件

  • CodeReady Workspaces CLI 管理ツールがインストールされている。「crwctl CLI 管理ツールのインストール」 を参照してください。
  • oc ツールがインストールされている。
  • OpenShift インスタンスへのアクセス。

手順

  1. OpenShift Container Platform にログインします。

    $ oc login ${OPENSHIFT_API_URL} --username ${OPENSHIFT_USERNAME} \
                                    --password ${OPENSHIFT_PASSWORD}
  2. カスタマイズされたカスタムリソースで CodeReady Workspaces をインストールし、制限された環境に関連するフィールドを追加します。

    $ crwctl server:start \
      --che-operator-image=<target-registry>/<target-organization>/crw-2-rhel8-operator:2.5 \
      --che-operator-cr-yaml=org_v1_che_cr.yaml
注記

低速なシステムまたはインターネット接続の場合は、--k8spodwaittimeout=1800000 フラグオプションを crwctl server:start コマンドに追加し、Pod のタイムアウト期間を 1800000 ms 以上に拡張します。

3.3.3. プロキシーの後ろでインストールするための CodeReady Workspaces カスタムリソースの準備

この手順では、CodeReady Workspaces をプロキシーの後ろでインストールする際に、CheCluster カスタムリソースに必要な追加情報を提供する方法を説明します。

手順

  1. CodeReady Workspaces Operator によって管理される CheCluster カスタムリソースで、制限された環境で CodeReady Workspaces のインスタンスのデプロイを容易にするために使用されるフィールドを追加します。

    # [...]
    spec:
      server:
        proxyURL: '<URL of the proxy, with the http protocol, and without the port>'
        proxyPort: '<Port of proxy, typically 3128>'
    # [...]
  2. これらの基本設定のほかに、プロキシー設定では通常、プロキシーを使用せずに CodeReady Workspaces からアクセスされるホストの一覧に外部 OpenShift クラスター API URL のホストを追加する必要があります。

    このクラスター API ホストを取得するには、OpenShift クラスターに対して以下のコマンドを実行します。

    $ oc whoami --show-server | sed 's#https://##' | sed 's#:.*$##'

    CheCluster カスタムリソースの対応するフィールドは nonProxyHosts です。ホストがこのフィールドにすでに存在する場合は、| を区切り文字として使用し、クラスター API ホストを追加します。

    # [...]
    spec:
      server:
        nonProxyHosts: 'anotherExistingHost|<cluster api host>'
    # [...]

第4章 CodeReady Workspaces の設定

本章では、いくつかのーザーストーリーを例として使用し、Red Hat CodeReady Workspaces の設定方法とオプションについて説明します。

次のセクションでは、特定のユーザーストーリーを説明します。

4.1. CodeReady Workspaces サーバーコンポーネントの詳細な設定オプション

以下のセクションでは、CodeReady Workspaces サーバーコンポーネントの詳細なデプロイメントおよび設定方法を説明します。

4.1.1. Operator を使用した CodeReady Workspaces サーバーの詳細設定について

以下のセクションでは、Operator を使用したデプロイメントの CodeReady Workspaces サーバーコンポーネントの詳細な設定方法について説明します。

詳細設定は以下を実行するために必要です。

  • 標準の CheCluster カスタムリソースフィールドから Operator によって自動的に生成されない環境変数を追加します。
  • 標準の CheCluster カスタムリソースフィールドから Operator によって自動的に生成されるプロパティーを上書きします。

CheCluster カスタムリソースの server 設定の一部である customCheProperties フィールドには、CodeReady Workspaces サーバーコンポーネントに適用する追加の環境変数のマップが含まれます。

例4.1 ワークスペースのデフォルトのメモリー制限の上書き

  • CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB プロパティーを customCheProperties に追加します。
apiVersion: org.eclipse.che/v1
kind: CheCluster
# [...]
spec:
  server:
    # [...]
    customCheProperties:
      CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB: "2048"
# [...]
注記

以前のバージョンの CodeReady Workspaces Operator には、このロールを実行するために custom という名前の configMap が含まれていました。CodeReady Workspaces Operator が custom という名前の configMap を見つけると、これに含まれるデータを customCheProperties フィールドに追加し、CodeReady Workspaces を再デプロイし、custom configMap を削除します。

関連資料

4.1.2. CodeReady Workspaces サーバーコンポーネントのシステムプロパティー参照

以下のドキュメントでは、CodeReady Workspaces サーバーコンポーネントのすべての使用可能な設定プロパティーについて説明します。

表4.1 Che サーバー

環境変数名デフォルト値詳細

CHE_DATABASE

${che.home}/storage

CodeReady Workspaces が内部データオブジェクトを保存するフォルダー。

CHE_API

http://${CHE_HOST}:${CHE_PORT}/api

API サービス。ブラウザーは、この URL を使用して CodeReady Workspaces サーバーへの REST 通信を開始します。

CHE_WEBSOCKET_ENDPOINT

ws://${CHE_HOST}:${CHE_PORT}/api/websocket

CodeReady Workspaces websocket の主なエンドポイント。主な websocket の対話とメッセージング用の基本的な通信エンドポイントを提供します。

CHE_WEBSOCKET_ENDPOINT__MINOR

ws://${CHE_HOST}:${CHE_PORT}/api/websocket-minor

CodeReady Workspaces websocket マイナーエンドポイント。マイナーな websocket の対話とメッセージング用の基本的な通信エンドポイントを提供します。

CHE_WORKSPACE_STORAGE

${che.home}/workspaces

プロジェクトは、CodeReady Workspaces サーバーから各ワークスペースを実行するマシンに同期されます。これは、プロジェクトがマウントされるワークスペースランタイムのディレクトリーです。

CHE_WORKSPACE_PROJECTS_STORAGE

/projects

プロジェクトは、CodeReady Workspaces サーバーから各ワークスペースを実行するマシンに同期されます。これは、プロジェクトが配置されているマシンのディレクトリーです。

CHE_WORKSPACE_PROJECTS_STORAGE_DEFAULT_SIZE

1Gi

devfile 要求の OpenShift タイプのコンポーネントがプロジェクト PVC 作成を要求する場合に使用されます ('unique' および 'per workspace' PVC ストラテジーの場合に適用されます。'common' PVC ストラテジーの場合は、これは che.infra.kubernetes.pvc.quantity プロパティーの値で書き換えられます)。

CHE_WORKSPACE_LOGS_ROOT__DIR

/workspace_logs

すべてのワークスペースログが置かれるマシン内のディレクトリーを定義します。環境変数などの値として、この値をマシンに指定します。これは、エージェントの開発者がこのディレクトリーを使用してエージェントのログをバックアップできるようにするためのものです。

CHE_WORKSPACE_HTTP__PROXY

 

ワークスペースを駆動するランタイムで使用されるプロキシーを設定します。

CHE_WORKSPACE_HTTPS__PROXY

 

ワークスペースを駆動するランタイムで使用されるプロキシーを設定します。

CHE_WORKSPACE_NO__PROXY

 

ワークスペースを駆動するランタイムで使用されるプロキシーを設定します。

CHE_TRUSTED__CA__BUNDLES__CONFIGMAP

NULL

クラスター全体のプロキシーが設定される場合、che-operator は特殊な configmap を作成し、OpenShift Network Operator が ca-bundle をこれに挿入することを許可します。さらに、CodeReady Workspacesサーバーのconfigmap (および対応する環境変数)に、このconfigmap の名前を持つCHE_TRUSTED__CA__BUNDLES__CONFIGMAPキーを追加します。そのため、その存在を使用して、プロキシーモードが有効かどうかを検出できます。このプロパティーで必要でない限り、このプロパティーは手動で設定しないでください。

CHE_WORKSPACE_AUTO__START

true

デフォルトでは、ユーザーがこの URL を使用してワークスペースにアクセスすると、ワークスペースは自動的に起動します (現時点で停止している場合)。この動作を無効にするには、このパラメーターを false に設定します。

CHE_WORKSPACE_POOL_TYPE

固定:

ワークスペーススレッドプールの設定。このプールは、非同期の実行が必要なワークスペース関連の操作 (例: 起動/停止) に使用されます。設定可能な値は fixed および cached です。

CHE_WORKSPACE_POOL_EXACT__SIZE

30

プールタイプが fixed と異なる場合に、このプロパティーは無視されます。これはプールのサイズを設定します。設定されると、multiplier プロパティーは無視されます。このプロパティーが設定されていない場合 (0, <0, NULL)、プールサイズはコア数と等しくなります。che.workspace.pool.cores_multiplier も参照してください。

CHE_WORKSPACE_POOL_CORES__MULTIPLIER

2

プールタイプが fixed に設定されておらず、che.workspace.pool.exact_size が設定されている場合は、このプロパティーは無視されます。設定されている場合、プールサイズは N_CORES * multiplier になります。

CHE_WORKSPACE_PROBE__POOL__SIZE

10

このプロパティーは、ワークスペースサーバーの liveness プローブに使用するスレッドの数を指定します。

CHE_WORKSPACE_HTTP__PROXY__JAVA__OPTIONS

NULL

ワークスペース JVM の HTTP プロキシー設定。

CHE_WORKSPACE_JAVA__OPTIONS

-XX:MaxRAM=150m-XX:MaxRAMFraction=2 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xms20m -Djava.security.egd=file:/dev/./urandom

ワークスペースで実行されている JVM に追加される Java コマンドラインオプション。

CHE_WORKSPACE_MAVEN__OPTIONS

-XX:MaxRAM=150m-XX:MaxRAMFraction=2 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xms20m -Djava.security.egd=file:/dev/./urandom

ワークスペースでエージェントを実行する JVM に追加される Maven コマンドラインオプション。

CHE_WORKSPACE_MAVEN__SERVER__JAVA__OPTIONS

-XX:MaxRAM=128m-XX:MaxRAMFraction=1 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xms20m -Djava.security.egd=file:/dev/./urandom

Maven サーバーを実行している JVM に追加される Java コマンドラインオプション。

CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB

1024

環境に RAM 設定のない各マシンの RAM 制限のデフォルト。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_DEFAULT__MEMORY__REQUEST__MB

200

環境内に明示的な RAM 設定のない各コンテナーの RAM 要求。この量はワークスペースコンテナーの作成時に割り当てられます。このプロパティーは、すべてのインフラストラクチャー実装でサポートされる訳ではありません。現時点で、これは OpenShift によってサポートされます。メモリー制限を超えるメモリー要求は無視され、制限サイズのみが使用されます。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_DEFAULT__CPU__LIMIT__CORES

-1

環境に CPU 設定のない各コンテナーの CPU 制限。浮動小数点のコア数 (例: 0.125) で、または OpenShift 形式(125mなどの整数のミリコア数) を使用して指定します。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_DEFAULT__CPU__REQUEST__CORES

-1

環境内に CPU 設定のない各コンテナーの CPU 要求。CPU 制限を超える CPU 要求は無視され、制限の数値のみが使用されます。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_SIDECAR_DEFAULT__MEMORY__LIMIT__MB

128

CodeReady Workspaces プラグイン設定に RAM 設定のない各サイドカーの RAM 制限および要求。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_SIDECAR_DEFAULT__MEMORY__REQUEST__MB

64

CodeReady Workspaces プラグイン設定に RAM 設定のない各サイドカーの RAM 制限および要求。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_SIDECAR_DEFAULT__CPU__LIMIT__CORES

-1

CodeReady Workspaces プラグイン設定に CPU 設定のない各サイドカーの CPU 制限および要求のデフォルト。浮動小数点のコア数 (例: 0.125) で、または OpenShift 形式(125mなどの整数のミリコア数) を使用して指定します。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_SIDECAR_DEFAULT__CPU__REQUEST__CORES

-1

CodeReady Workspaces プラグイン設定に CPU 設定のない各サイドカーの CPU 制限および要求のデフォルト。浮動小数点のコア数 (例: 0.125) で、または OpenShift 形式(125mなどの整数のミリコア数) を使用して指定します。0 以下の値値は、制限を無効にするものとして解釈されます。

CHE_WORKSPACE_SIDECAR_IMAGE__PULL__POLICY

Always

サイドカーのイメージプルストラテジーを定義します。使用できる値は AlwaysNeverIfNotPresent です。その他の値については、Always:latest タグが付いたイメージに、その他の場合は IfNotPresent が想定されます。

CHE_WORKSPACE_ACTIVITY__CHECK__SCHEDULER__PERIOD__S

60

非アクティブなワークスペースの一時停止ジョブの実行期間。

CHE_WORKSPACE_ACTIVITY__CLEANUP__SCHEDULER__PERIOD__S

3600

アクティビティーテーブルのクリーンアップ期間。アクティビティーテーブルには、サーバーが特定の時点でクラッシュするなどの予想されないエラーが生じる場合に、無効なデータまたは古いデータを含まれることがあります。デフォルトでは、クリーンアップジョブは 1 時間ごとに実行されます。

CHE_WORKSPACE_ACTIVITY__CLEANUP__SCHEDULER__INITIAL__DELAY__S

60

サーバーの起動後から最初のアクティビティーのクリーンアップジョブを開始するまでの遅延。

CHE_WORKSPACE_ACTIVITY__CHECK__SCHEDULER__DELAY__S

180

ws マスターが非アクティブのタイムアウトまでの期間利用できない場合の、大規模な一時停止を回避するために最初のワークスペースのアイドルチェックジョブが開始されるまでの遅延。

CHE_WORKSPACE_CLEANUP__TEMPORARY__INITIAL__DELAY__MIN

5

停止した一時的なワークスペースのクリーンアップジョブの実行期間。

CHE_WORKSPACE_CLEANUP__TEMPORARY__PERIOD__MIN

180

停止した一時的なワークスペースのクリーンアップジョブの実行期間。

CHE_WORKSPACE_SERVER_PING__SUCCESS__THRESHOLD

1

サーバーへの正常に順次実行される ping の数。この数を超えると、サーバーは利用可能な状態にあるものとして処理されます。注: このプロパティーはすべてのサーバー (ワークスペースのエージェント、ターミナル、exec など) に共通です。

CHE_WORKSPACE_SERVER_PING__INTERVAL__MILLISECONDS

3000

ワークスペースサーバーへの連続する ping の間隔 (ミリ秒単位)。

CHE_WORKSPACE_SERVER_LIVENESS__PROBES

wsagent/http,exec-agent/http,terminal,theia,jupyter,dirigible,cloud-shell,intellij

liveness プローブを必要とするサーバー名の一覧

CHE_WORKSPACE_STARTUP__DEBUG__LOG__LIMIT__BYTES

10485760

ワークスペースの起動をデバッグする際に che-server で観察される単一コンテナーから収集されるログの制限サイズ。デフォルト値は 10MB=10485760 です。

CHE_WORKSPACE_STOP_ROLE_ENABLED

true

true の場合、OpenShift OAuth が有効な場合に、編集権限を持つ「stop-workspace」ロールが「che」 ServiceAccount に付与されます。この設定は、OpenShift OAuth が有効な場合にワークスペースのアイドリングに主に必要になります。

表4.2 テンプレート

環境変数名デフォルト値詳細

CHE_TEMPLATE_STORAGE

${che.home}/templates

コードテンプレートおよびサンプルが含まれる JSON ファイルが含まれるフォルダー

表4.3 認証パラメーター

環境変数名デフォルト値詳細

CHE_AUTH_USER__SELF__CREATION

false

CodeReady Workspaces には単一のアイデンティティー実装があるため、これによるユーザーエクスペリエンスへの変更はありません。true の場合、API レベルでのユーザー作成を有効にします。

CHE_AUTH_ACCESS__DENIED__ERROR__PAGE

/error-oauth

認証エラーページアドレス

CHE_AUTH_RESERVED__USER__NAMES

 

予約済みのユーザー名

CHE_OAUTH_GITHUB_CLIENTID

NULL

GitHub OAuth を設定して、リモートリポジトリーへの認証を自動化できます。最初に、このアプリケーションを GitHub OAuth に登録する必要があります。

CHE_OAUTH_GITHUB_CLIENTSECRET

NULL

GitHub OAuth を設定して、リモートリポジトリーへの認証を自動化できます。最初に、このアプリケーションを GitHub OAuth に登録する必要があります。

CHE_OAUTH_GITHUB_AUTHURI

https://github.com/login/oauth/authorize

GitHub OAuth を設定して、リモートリポジトリーへの認証を自動化できます。最初に、このアプリケーションを GitHub OAuth に登録する必要があります。

CHE_OAUTH_GITHUB_TOKENURI

https://github.com/login/oauth/access_token

GitHub OAuth を設定して、リモートリポジトリーへの認証を自動化できます。最初に、このアプリケーションを GitHub OAuth に登録する必要があります。

CHE_OAUTH_GITHUB_REDIRECTURIS

http://localhost:${CHE_PORT}/api/oauth/callback

GitHub OAuth を設定して、リモートリポジトリーへの認証を自動化できます。最初に、このアプリケーションを GitHub OAuth に登録する必要があります。

CHE_OAUTH_OPENSHIFT_CLIENTID

NULL

OpenShift OAuth クライアントの設定。OpenShift OAuth トークンの取得に使用されます。

CHE_OAUTH_OPENSHIFT_CLIENTSECRET

NULL

OpenShift OAuth クライアントの設定。OpenShift OAuth トークンの取得に使用されます。

CHE_OAUTH_OPENSHIFT_OAUTH__ENDPOINT

NULL

Configurationof OpenShift OAuth クライアント。OpenShift OAuth トークンの取得に使用されます。

CHE_OAUTH_OPENSHIFT_VERIFY__TOKEN__URL

NULL

ConfigurationofOpenShiftOAuth クライアント。OpenShift OAuth トークンの取得に使用されます。

表4.4 内部

環境変数名デフォルト値詳細

SCHEDULE_CORE__POOL__SIZE

10

CodeReady Workspaces 拡張には、時間ベースでスケジュールされる実行をスケジュールできます。これにより、繰り返されるスケジュールで起動する拡張に割り当てられるスレッドプールのサイズが設定されます。

ORG_EVERREST_ASYNCHRONOUS

false

Everrest は、JAX-RS および Web ソケット通信ユーザーを管理する Java Web Services ツールキットで、これを設定する必要はほとんどありません。Everrestに組み込まれている非同期メカニズムを無効にします。

ORG_EVERREST_ASYNCHRONOUS_POOL_SIZE

20

同時に処理できる非同期要求の数量

ORG_EVERREST_ASYNCHRONOUS_QUEUE_SIZE

500

キューのサイズ非同期要求が消費後に処理できない場合は、キューに追加されます。

ORG_EVERREST_ASYNCHRONOUS_JOB_TIMEOUT

10

リクエストのタイムアウト(分単位)。タイムアウトリクエストが完了しなかったり、リクエストの結果を取得できなかった場合は、破棄される可能性があります。

ORG_EVERREST_ASYNCHRONOUS_CACHE_SIZE

1024

待機、実行中、および終了要求のキャッシュのサイズ。

ORG_EVERREST_ASYNCHRONOUS_SERVICE_PATH

/async/

非同期サービスへのパス

DB_SCHEMA_FLYWAY_BASELINE_ENABLED

true

DB の初期化および移行設定

DB_SCHEMA_FLYWAY_BASELINE_VERSION

5.0.0.8.1

DB の初期化および移行設定

DB_SCHEMA_FLYWAY_SCRIPTS_PREFIX

 

DB の初期化および移行設定

DB_SCHEMA_FLYWAY_SCRIPTS_SUFFIX

.sql

DB の初期化および移行設定

DB_SCHEMA_FLYWAY_SCRIPTS_VERSION__SEPARATOR

__

DB の初期化および移行設定

DB_SCHEMA_FLYWAY_SCRIPTS_LOCATIONS

classpath:che-schema

DB の初期化および移行設定

表4.5 OpenShift インフラパラメーター

環境変数名デフォルト値詳細

CHE_INFRA_KUBERNETES_MASTER__URL

 

インフラが使用する OpenShift クライアントの設定

CHE_INFRA_KUBERNETES_TRUST__CERTS

 

インフラが使用する OpenShift クライアントの設定

CHE_INFRA_KUBERNETES_SERVER__STRATEGY

multi-host

サーバーが OpenShift インフラでグローバルに公開される方法を定義します。CodeReady Workspaces に実装されたストラテジーの一覧: default-host、multi-host、single-host

CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_EXPOSURE

native

ワークスペースのプラグインとエディターを単一ホストモードで公開する方法を定義します。サポートされる公開: - 'native': OpenShift Ingress を使用してサーバーを公開します。OpenShift でのみ機能します。'gateway': リバースプロキシーゲートウェイを使用してサーバーを公開します。

CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_DEVFILE__ENDPOINT__EXPOSURE

multi-host

single-host サーバーストラテジーで devfile エンドポイント、エンドユーザーのアプリケーションを公開する方法を定義します。これらは single-host ストラテジーに従い、サブパスで公開されるか、またはサブドメイン上で公開できます。'multi-host': サブドメインで公開される - 'single-host': サブパスで公開される

CHE_INFRA_KUBERNETES_SINGLEHOST_GATEWAY_CONFIGMAP__LABELS

app=che,component=che-gateway-config

single-host ゲートウェイを設定する ConfigMap に設定されるラベルを定義します。

CHE_INFRA_KUBERNETES_INGRESS_DOMAIN

 

che.infra.kubernetes.server_strategy プロパティーが multi-hostに設定されている場合に、ワークスペースでサーバーのドメインを生成するために使用されます。

CHE_INFRA_KUBERNETES_NAMESPACE

 

非推奨: このプロパティーの値は変更しないでください。変更すると、既存のワークスペースでデータが失われます。これは新規インストールに設定しないでください。すべてのワークスペースが作成される OpenShift namespace を定義します。これが設定されないと、すべてのワークスペースが新しい namespace に作成されます。ここで、namespace = ワークスペース ID になります。<username> および <userid> プレースホルダー (例: che-workspace-<username>) を使用できます。この場合、ユーザーごとに新規 namespace が作成されます。新規 namespace を作成するパーミッションを持つサービスアカウントを使用する必要があります。OpenShift インフラでは無視されます。代わりに che.infra.openshift.project を使用します。このプロパティーで参照される namespace が存在する場合、これはすべてのワークスペースで使用されます。これが存在しない場合、che.infra.kubernetes.namespace.default によって指定される namespace が作成され、使用されます。

CHE_INFRA_KUBERNETES_NAMESPACE_CREATION__ALLOWED

true

CodeReady Workspaces サーバーがユーザーワークスペースの namespace/プロジェクトを作成できるかどうか、またはそれらはクラスター管理者によって手動で作成されるかどうかを示します。このプロパティーは OpenShift infra によっても使用されます。

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT

<username>-che

ユーザーが上書きしない場合に、ユーザーのワークスペースが作成される OpenShift のデフォルトの namespace を定義します。<username>、<userid> および <workspaceid> プレースホルダー (例: che-workspace-<username>)を使用できます。この場合、新規 namespace が各ユーザー (またはワークスペース) について作成されます。OpenShift インフラによってプロジェクトの指定にも使用されます。

CHE_INFRA_KUBERNETES_NAMESPACE_ALLOW__USER__DEFINED

false

ユーザーがデフォルトとは異なる OpenShift namespace (OpenShift プロジェクト) を指定できるかどうかを定義します。OAuth が設定されていない場合に true に設定することは推奨されません。このプロパティーは OpenShift infra によっても使用されます。

CHE_INFRA_KUBERNETES_SERVICE__ACCOUNT__NAME

NULL

すべてのワークスペース Pod にバインドされるように指定する必要のある OpenShift サービスアカウント名を定義します。OpenShift インフラストラクチャーはサービスアカウントを作成しないため、これは存在するはずであることに注意してください。OpenShift インフラストラクチャーは、プロジェクトが事前に定義されているかどうかをチェックします(che.infra.openshift.project が空でない場合)。これが事前に定義されている場合はサービスアカウントが存在するはずです。これが 'NULL' または空の文字列の場合、インフラストラクチャーはワークスペースごとに新しい OpenShift プロジェクトを作成し、必要なロールを持つワークスペーのスサービスアカウントをここに準備します。

CHE_INFRA_KUBERNETES_WORKSPACE__SA__CLUSTER__ROLES

NULL

ワークスペースのサービスアカウントで使用するオプションの追加クラスターロールを指定します。クラスターのロール名がすでに存在している必要があり、CodeReady Workspaces サービスアカウントはロールバインディングを作成して、これらのクラスターロールをワークスペースのサービスアカウントに関連付ける必要があることに注意してください。名前はコンマで区切られます。このプロパティーは 'che.infra.kubernetes.cluster_role_name' を非推奨にします。

CHE_INFRA_KUBERNETES_WORKSPACE__START__TIMEOUT__MIN

8

OpenShift ワークスペースの開始時間を制限する時間枠を定義します。

CHE_INFRA_KUBERNETES_INGRESS__START__TIMEOUT__MIN

5

OpenShift Ingress が準備状態になる期間を制限するタイムアウトを分単位で定義します。

CHE_INFRA_KUBERNETES_WORKSPACE__UNRECOVERABLE__EVENTS

FailedMount,FailedScheduling,MountVolume.SetUpfailed,Failed to pull image,FailedCreate

ワークスペースの起動中に、プロパティーに定義されるリカバリー不可能なイベントが発生する場合、タイムアウトまで待機するのではなく、ワークスペースをすぐに終了します。これには 'Failed' の理由が含めることができないことに注意してください。これにより、リカバリー不可能なイベントがキャッチされる可能性があるためです。失敗したコンテナーの起動は、CodeReady Workspaces サーバーで明示的に処理されます。

CHE_INFRA_KUBERNETES_PVC_ENABLED

true

che ワークスペースに Persistent Volume Claim(永続ボリューム要求、PVC)を使用するかどうか (バックアッププロジェクト、ログなどをが必要かどうか) を定義します。またはこれを無効にします。

CHE_INFRA_KUBERNETES_PVC_STRATEGY

common

ワークスペース用に PVC を選択する際に使用するストラテジーを定義します。サポートされるストラテジー: - 'common' 同じ OpenShift namespace 内のすべてのワークスペースは同じ PVC を再利用します。PVC の名前は 'che.infra.kubernetes.pvc.name' で設定できます。既存の PVC が使用されるか、または新規 PVC が存在しない場合にはこれが作成されます。- 'unique' 各ワークスペースのボリュームに別個の PVC が使用されます。PVC の名前は '{che.infra.kubernetes.pvc.name} + '-' + {generated_8_chars}' として評価されます。既存の PVC が使用されるか、または新規 PVC が存在しない場合にはこれが作成されます。- 'per-workspace' 各ワークスペースの別個の PVC が使用されます。PVC の名前は '{che.infra.kubernetes.pvc.name} + '-' + {WORKSPACE_ID}' として評価されます。既存の PVC が使用されるか、または新規 PVC が存在しない場合にはこれが作成されます。

CHE_INFRA_KUBERNETES_PVC_PRECREATE__SUBPATHS

true

ワークスペースを起動する前に、「common」ストラテジーの永続ボリュームでワークスペースのサブパスディレクトリーを作成するジョブを実行するかどうかを定義します。ワークスペースのサブパスのボリュームマウントは root 権限で作成され、ユーザーとして実行するワークスペースで変更できないため(CodeReady Workspace のワークスペースへのプロジェクトのインポートエラーが表示される)、一部の OpenShift/OpenShift のバージョンで必要です。デフォルトは 'true' ですが、Openshift/OpenShift のバージョンがユーザーパーミッションでサブディレクトリーを作成する場合は false に設定する必要があります。関連する問題: https://github.com/kubernetes/kubernetes/issues/41638 このプロパティーは、「common」 PVC ストラテジーが使用される場合にのみ有効であることに注意してください。

CHE_INFRA_KUBERNETES_PVC_NAME

claim-che-workspace

che ワークスペースの PVC 名の設定を定義します。それぞれの PVC ストラテジーは、この値を異なる方法で指定します。che.infra.kubernetes.pvc.strategy プロパティーについてドキュメントを参照してください。

CHE_INFRA_KUBERNETES_PVC_STORAGE__CLASS__NAME

 

ワークスペースの Persistent Volume Claim(永続ボリューム要求、PVC)のストレージクラスを定義します。空の文字列は「use default」を意味します。

CHE_INFRA_KUBERNETES_PVC_QUANTITY

10Gi

che workspace の Persistent Volume Claim(永続ボリューム要求、PVC)のサイズを定義します。形式については https://docs.openshift.com/container-platform/4.4/storage/understanding-persistent-storage.html を参照してください

CHE_INFRA_KUBERNETES_PVC_JOBS_IMAGE

centos:centos7

OpenShift で永続ボリューム要求 (PVC)のメンテナンスジョブを実行する際に起動する Pod

CHE_INFRA_KUBERNETES_PVC_JOBS_IMAGE_PULL__POLICY

IfNotPresent

Openshift/OpenShift クラスターのメンテナンスジョブに使用されるコンテナーのイメージプルポリシー

CHE_INFRA_KUBERNETES_PVC_JOBS_MEMORYLIMIT

250Mi

永続ボリューム要求のメンテナンスジョブの Pod メモリー制限を定義します。

CHE_INFRA_KUBERNETES_PVC_ACCESS__MODE

ReadWriteOnce

Persistent Volume Claim(永続ボリューム要求、PVC)のアクセスモードを定義します。common PVC ストラテジーの変更の場合、アクセスモードの変更は、同時に実行されるワークスペースの数に影響を与えることに注意してください。実行されている che が RWX アクセスモードので PV を使用している OpenShift フレーバーの場合、同時に実行されるワークスペースの制限は (RAM、CPU などの) che 制限の設定によってのみバインドされます。アクセスモードの詳細は、https://docs.openshift.com/container-platform/4.4/storage/understanding-persistent-storage.html を参照してください。

CHE_INFRA_KUBERNETES_PVC_WAIT__BOUND

true

CodeReady Workspaces Server がワークスペース PVC が作成後にバインドされるまで待機するかどうかを定義します。これは、すべての PVC ストラテジーによって使用されます。volumeBindingModeWaitForFirstConsumer に設定されている場合は、false に設定する必要があります。それ以外の場合は、ワークスペースの起動が PVC の待機フェーズでハングします。デフォルト値は true (PVC がバインドされるまで待機する必要あることを意味します) です。

CHE_INFRA_KUBERNETES_INSTALLER__SERVER__MIN__PORT

10000

インストーラーサーバーの定義されたポート範囲。デフォルトで、インストーラーは独自のポートを使用しますが、これが別のインストーラーサーバーと競合する場合は、OpenShift インフラストラクチャーはインストーラーを再設定し、この範囲から最初に利用可能になるものを使用できるようにします。

CHE_INFRA_KUBERNETES_INSTALLER__SERVER__MAX__PORT

20000

インストーラーサーバーの定義されたポート範囲。デフォルトで、インストーラーは独自のポートを使用しますが、これが別のインストーラーサーバーと競合する場合は、OpenShift インフラストラクチャーはインストーラーを再設定し、この範囲から最初に利用可能になるものを使用できるようにします。

CHE_INFRA_KUBERNETES_INGRESS_ANNOTATIONS__JSON

NULL

サーバーを公開するために使用される Ingress のアノテーションを定義します。値は Ingress コントローラーの種類によって異なります。OpenShift インフラストラクチャーは ingress の代わりにルートを使用するため、このプロパティーを無視します。単一ホストのデプロイメントストラテジーが機能するには、URL の書き換えをサポートするコントローラーを使用する必要があります(URL が異なるサーバーをポイントでき、サーバーはアプリケーションのルートの変更をサポートする必要がないようにします)。che.infra.kubernetes.ingress.path.rewrite_transform プロパティーは、Ingress のパスが URL の書き換えをサポートするよう変換する方法を定義します。このプロパティーは、選択した Ingress コントローラーに対して実際に URL の書き換えを実行するように指示する ingress 自体のアノテーションのセットを定義します (選択された Ingress コントローラーで必要な場合)。たとえば、nginx ingress コントローラー 0.22.0 以降の場合、以下の値が推奨されます: {'ingress.kubernetes.io/rewrite-target': '/$1','ingress.kubernetes.io/ssl-redirect': 'false',\ 'ingress.kubernetes.io/proxy-connect-timeout': '3600','ingress.kubernetes.io/proxy-read-timeout': '3600'} che.infra.kubernetes.ingress.path.rewrite_transform は 0.22.0 よりも前の '%s(.*)' nginx ingress コントローラーに設定する必要があり、rewrite-target は単に '/' に設定し、path transform は '%s' に設定する必要があります ( che.infra.kubernetes.ingress.path.rewrite_transform プロパティーを参照してください)。Ingress コントローラーが Ingress パスにある正規表現を使用する方法と、URL の書き換えを実行する方法についての説明は、nginx Ingress コントローラーのドキュメントを参照してください。

CHE_INFRA_KUBERNETES_INGRESS_PATH__TRANSFORM

NULL

サーバーを公開する Ingress のパスを宣言する方法についての「recipe」(レシピ) を定義します。'%s' はサーバーのベース公開 URL を表し、スラッシュで終了することが保証されています。このプロパティーは String.format()メソッドへの有効な入力であり、%s への参照が 1 つだけ含まれる必要があります。Ingress のアノテーションとパスを指定する際にこれら 2 つのプロパティーの相互作用を確認するには、che.infra.kubernetes.ingress.annotations_json プロパティーの説明を参照してください。これが定義されていない場合、このプロパティーはデフォルトで '%s' (引用符なし) に設定されます。これは、パスが Ingress コントローラーで使用する場合に変換されないことを意味します。

CHE_INFRA_KUBERNETES_INGRESS_LABELS

NULL

明確化できるように、CodeReady Workspaces サーバーによって作成されるすべての Ingress に追加する追加のラベル。

CHE_INFRA_KUBERNETES_POD_SECURITY__CONTEXT_RUN__AS__USER

NULL

OpenShift インフラによって作成される Pod のセキュリティーコンテキストを定義します。これは OpenShift インフラによって無視されます。

CHE_INFRA_KUBERNETES_POD_SECURITY__CONTEXT_FS__GROUP

NULL

OpenShift インフラによって作成される Pod のセキュリティーコンテキストを定義します。これは OpenShift インフラによって無視されます。

CHE_INFRA_KUBERNETES_POD_TERMINATION__GRACE__PERIOD__SEC

0

OpenShift / OpenShift インフラストラクチャーによって作成される Pod の強制終了の猶予期間を定義します。OpenShift / OpenShift ワークスペースの Pod の強制終了の猶予期間はデフォルトで '0' に設定されます。これにより、Pod をほぼ即時に終了し、ワークスペースを停止するのに必要な時間を短縮できます。注: terminationGracePeriodSeconds が OpenShift / OpenShift recipe で明示的に設定されている場合、これは上書きされません。

CHE_INFRA_KUBERNETES_CLIENT_HTTP_ASYNC__REQUESTS_MAX

1000

OpenShiftClient インスタンスの基礎となる共有 http クライアントでサポートされる同時の非同期 Web リクエスト (http 要求または継続的な Web ソケット呼び出し) の最大数。デフォルト値は 64 および 1 ホストに 5 になります。これは、CodeReady Workspaces が (コマンドまたは ws-agent ログ用などに) 開かれた接続の数を維持することを考慮すると、マルチユーザーのシナリオでは正しい値のように見えない場合があります。

CHE_INFRA_KUBERNETES_CLIENT_HTTP_ASYNC__REQUESTS_MAX__PER__HOST

1000

OpenShiftClient インスタンスの基礎となる共有 http クライアントでサポートされる同時の非同期 Web リクエスト (http 要求または継続的な Web ソケット呼び出し) の最大数。デフォルト値は 64 および 1 ホストに 5 になります。これは、CodeReady Workspaces が (コマンドまたは ws-agent ログ用などに) 開かれた接続の数を維持することを考慮すると、マルチユーザーのシナリオでは正しい値のように見えない場合があります。

CHE_INFRA_KUBERNETES_CLIENT_HTTP_CONNECTION__POOL_MAX__IDLE

5

OpenShift クライアント共有 http クライアントの接続プールにおけるアイドル状態の接続の最大数

CHE_INFRA_KUBERNETES_CLIENT_HTTP_CONNECTION__POOL_KEEP__ALIVE__MIN

5

OpenShift クライアント共有 http クライアントの接続プールのキープアライブのタイムアウト (分単位)

CHE_INFRA_KUBERNETES_TLS__ENABLED

false

OpenShift インフラストラクチャーで TLS (Transport Layer Security) を有効にして Ingress を作成します。ルートは TLS 対応になります。

CHE_INFRA_KUBERNETES_TLS__SECRET

 

OpenShift インフラストラクチャーによって無視される TLS でワークスペース Ingress を作成する際に使用するシークレットの名前

CHE_INFRA_KUBERNETES_TLS__KEY

NULL

ワークスペースの Ingresss 証明書およびキーに使用する必要のある TLS Secret のデータは Base64 アルゴリズムでエンコードされる必要があります。これらのプロパティーは OpenShift インフラストラクチャーで無視されます。

CHE_INFRA_KUBERNETES_TLS__CERT

NULL

ワークスペースの Ingresss 証明書およびキーに使用する必要のある TLS Secret のデータは Base64 アルゴリズムでエンコードされる必要があります。これらのプロパティーは OpenShift インフラストラクチャーで無視されます。

CHE_INFRA_KUBERNETES_RUNTIMES__CONSISTENCY__CHECK__PERIOD__MIN

-1

ランタイムの整合性チェックが実行される期間を定義します。ランタイムに一貫性のない状態がある場合、ランタイムは自動的に停止します。値は 0 をより大きな値、または -1 である必要があります。ここで、-1 はチェックが実行されないことを意味します。これはデフォルトで無効にされます。CodeReady Workspaces Server は操作がユーザーによって呼び出しされない場合に OpenShift API と対話できくなる CodeReady Workspaces サーバーの設定があることが予想されるためです。これは以下の設定で機能します。- ワークスペースオブジェクトが CodeReady Workspaces Server がある同じ namespace で作成される。- クラスター管理のサービスアカウントトークンが CodeReady Workspaces Server Pod にマウントされる。これは、以下の設定では機能しません。- CodeReady Workspaces Server が OAuth プロバイダーのトークンを使用して OpenShift API と通信する。

表4.6 OpenShift インフラパラメーター

環境変数名デフォルト値詳細

CHE_INFRA_OPENSHIFT_PROJECT

 

非推奨: このプロパティーの値は変更しないでください。変更すると、既存のワークスペースでデータが失われます。これは新規インストールに設定しないでください。すべてのワークスペースが作成される OpenShift namespace を定義します。これが設定されないと、すべてのワークスペースが新しい namespace に作成されます。ここで、プロジェクト名 = ワークスペース ID になります。<username> および <userid> プレースホルダー (例: che-workspace-<username>) を使用できます。この場合、ユーザーごとに新規プロジェクトが作成されます。新規プロジェクトを作成するパーミッションを持つ OpenShift oauth またはサービスアカウントを使用する必要があります。このプロパティーで参照されるプロジェクトが存在する場合、これはすべてのワークスペースで使用されます。これが存在しない場合、che.infra.kubernetes.namespace.default によって指定される namespace が作成され、使用されます。

CHE_INFRA_OPENSHIFT_TRUSTED__CA__BUNDLES__CONFIG__MAP

ca-certs

CA バンドルが Openshift 4 に保存されるトラストストア設定マップの名前を設定します。このマップは、基本的には名前を使用して CodeReady Workspaces インストーラー(operator など)によって最初に作成され、CodeReady Workspaces サーバーはワークスペースの起動時に特定のラベル(以下を参照)で検索し、同じマップをワークスペースの namespace に作成し、マウントします。プロパティーは、ワークスペース namespace のマップの名前を定義します。

CHE_INFRA_OPENSHIFT_TRUSTED__CA__BUNDLES__CONFIG__MAP__LABELS

config.openshift.io/inject-trusted-cabundle=true

Openshift 4 での証明書の自動挿入に使用される設定マップのラベル名。

CHE_INFRA_OPENSHIFT_TRUSTED__CA__BUNDLES__MOUNT__PATH

/public-certs

CA バンドルがマウントされるワークスペースコンテナーでパスを設定します。

CHE_INFRA_OPENSHIFT_ROUTE_LABELS

NULL

明確化できるように、CodeReady Workspaces サーバーによって作成されるすべての Route に追加する追加のラベル。

CHE_SINGLEPORT_WILDCARD__DOMAIN_HOST

NULL

単一ポートモードのワイルドカードドメインホストおよびポート。デフォルトで nip.io が使用されます。

CHE_SINGLEPORT_WILDCARD__DOMAIN_PORT

NULL

単一ポートモードのワイルドカードドメインホストおよびポート。デフォルトで nip.io が使用されます。

CHE_SINGLEPORT_WILDCARD__DOMAIN_IPLESS

false

IP を挿入せずに単一ポートのカスタム DNS の有効化

表4.7 実験的なプロパティー

環境変数名デフォルト値詳細

CHE_WORKSPACE_PLUGIN__BROKER_METADATA_IMAGE

quay.io/eclipse/che-plugin-metadata-broker:v3.4.0

ワークスペースツール設定を解決し、プラグインの依存関係をワークスペースにコピーする CodeReady Workspaces プラグインブローカーアプリケーションの Docker イメージ。これらのイメージはデフォルトで CodeReady Workspaces Operator によって上書きされることに注意してください。ここでイメージを変更しても、CodeReady Workspaces が Operator でインストールされている場合は影響がありません。

CHE_WORKSPACE_PLUGIN__BROKER_ARTIFACTS_IMAGE

quay.io/eclipse/che-plugin-artifacts-broker:v3.4.0

ワークスペースツール設定を解決し、プラグインの依存関係をワークスペースにコピーする CodeReady Workspaces プラグインブローカーアプリケーションの Docker イメージ。これらのイメージはデフォルトで CodeReady Workspaces Operator によって上書きされることに注意してください。ここでイメージを変更しても、CodeReady Workspaces が Operator でインストールされている場合は影響がありません。

CHE_WORKSPACE_PLUGIN__BROKER_DEFAULT__MERGE__PLUGINS

false

プラグインをワークスペースにプロビジョニングする際にプラグインブローカーのデフォルト動作を設定します。true に設定すると、プラグインブローカーは可能な場合にプラグインのマージを試行します(つまり、それらは同じサイドカーイメージで実行され、設定が競合することはありません)。この値は、devfile が指定していない場合に、 'mergePlugins' 属性を使用して使用されるデフォルト設定です。

CHE_WORKSPACE_PLUGIN__BROKER_PULL__POLICY

Always

ワークスペースツール設定を解決し、プラグインの依存関係をワークスペースにコピーする CodeReady Workspaces プラグインブローカーアプリケーションの Docker イメージ

CHE_WORKSPACE_PLUGIN__BROKER_WAIT__TIMEOUT__MIN

3

プラグインブローカーの待機中に結果の最大期間を制限するタイムアウトを分単位で定義します。

CHE_WORKSPACE_PLUGIN__REGISTRY__URL

https://che-plugin-registry.prod-preview.openshift.io/v3

ワークスペースツールプラグインレジストリーのエンドポイント。有効な HTTP URL でなければなりません。例: http://che-plugin-registry-eclipse-che.192.168.65.2.nip.io CodeReady Workspaces プラグインツールが不要な場合、値 'NULL' を使用する必要があります。

CHE_WORKSPACE_DEVFILE__REGISTRY__URL

https://che-devfile-registry.prod-preview.openshift.io/

devfile レジストリーエンドポイント。有効な HTTP URL でなければなりません。例: http://che-devfile-registry-eclipse-che.192.168.65.2.nip.io http://che-devfile-registry-eclipse-che.192.168.65.2.nip.io CodeReady Workspaces プラグインが不要な場合、値 'NULL' を使用する必要があります。

CHE_WORKSPACE_STORAGE_AVAILABLE__TYPES

persistent,ephemeral,async

ダッシュボードなどのクライアントがワークスペースの作成/更新時にユーザーに提案するストレージタイプに使用できる値を定義する設定プロパティー。使用できる値: - 'persistent': 永続ストレージの I/O は低速だが永続性がある。- 'ephemeral': 一時ストレージは、高速 I/O を可能にするが、ストレージには制限があり、永続性がない。- 'async': 実験的機能: 非同期ストレージは一時ストレージと永続ストレージの組み合わせ。高速な I/O を可能にし、変更を維持し、停止時にバックアップを実行し、ワークスペースの開始時に復元します。che.infra.kubernetes.pvc.strategy='common' - che.limits.user.workspaces.run.count=1 - che.infra.kubernetes.namespace.allow_user_defined=false - che.infra.kubernetes.namespace.default に <username> が含まれる場合にのみ機能します。それ他の場合は、一覧から 'async' を削除します。

CHE_WORKSPACE_STORAGE_PREFERRED__TYPE

永続

ダッシュボードなどのクライアントがワークスペースの作成/更新時にユーザーに提案するストレージタイプのデフォルト値を定義する設定プロパティー。「async」値は実験的な値のため、デフォルトタイプとしての使用は推奨されません。

CHE_SERVER_SECURE__EXPOSER

jwtproxy

セキュアなサーバーが認証で保護される方法を設定します。適切な値: 'default': jwtproxy はパススルーモードで設定されます。そのため、サーバーは要求を認証する必要があります。'jwtproxy': jwtproxy は要求を認証します。そのため、サーバーは認証済みのもののみを受信します。

CHE_SERVER_SECURE__EXPOSER_JWTPROXY_TOKEN_ISSUER

wsmaster

署名のない要求をルーティングするための Jwtproxy 発行側の文字列、トークンの有効期間およびオプションの認証ページのパス。

CHE_SERVER_SECURE__EXPOSER_JWTPROXY_TOKEN_TTL

8800h

署名のない要求をルーティングするための Jwtproxy 発行側の文字列、トークンの有効期間およびオプションの認証ページのパス。

CHE_SERVER_SECURE__EXPOSER_JWTPROXY_AUTH_LOADER_PATH

/_app/loader.html

署名のない要求をルーティングするための Jwtproxy 発行側の文字列、トークンの有効期間およびオプションの認証ページのパス。

CHE_SERVER_SECURE__EXPOSER_JWTPROXY_IMAGE

quay.io/eclipse/che-jwtproxy:0.10.0

署名のない要求をルーティングするための Jwtproxy 発行側の文字列、トークンの有効期間およびオプションの認証ページのパス。

CHE_SERVER_SECURE__EXPOSER_JWTPROXY_MEMORY__LIMIT

128mb

署名のない要求をルーティングするための Jwtproxy 発行側の文字列、トークンの有効期間およびオプションの認証ページのパス。

CHE_SERVER_SECURE__EXPOSER_JWTPROXY_CPU__LIMIT

0.5

署名のない要求をルーティングするための Jwtproxy 発行側の文字列、トークンの有効期間およびオプションの認証ページのパス。

表4.8 主な「/websocket」エンドポイントの設定

環境変数名デフォルト値詳細

CHE_CORE_JSONRPC_PROCESSOR__MAX__POOL__SIZE

50

JSON RPC 処理プールの最大サイズ。プールサイズが超過すると、メッセージの実行が拒否されます。

CHE_CORE_JSONRPC_PROCESSOR__CORE__POOL__SIZE

5

初期 json 処理プール。主な JSON RPC メッセージを処理するために使用されるスレッドの最小数。

CHE_CORE_JSONRPC_PROCESSOR__QUEUE__CAPACITY

100000

Json RPC メッセージの処理に使用するキューの設定。

表4.9 主な"/websocket-minor"エンドポイントの設定

環境変数名デフォルト値詳細

CHE_CORE_JSONRPC_MINOR__PROCESSOR__MAX__POOL__SIZE

100

JSON RPC 処理プールの最大サイズ。プールサイズが超過すると、メッセージの実行が拒否されます。

CHE_CORE_JSONRPC_MINOR__PROCESSOR__CORE__POOL__SIZE

15

初期 json 処理プール。マイナーな JSON RPC メッセージを処理するために使用されるスレッドの最小数。

CHE_CORE_JSONRPC_MINOR__PROCESSOR__QUEUE__CAPACITY

10000

Json RPC メッセージの処理に使用するキューの設定。

CHE_METRICS_PORT

8087

Prometheus メトリクスで公開される http サーバーエンドポイントのポート

表4.10 CORS 設定

環境変数名デフォルト値詳細

CHE_CORS_ALLOWED__ORIGINS

*

WS Master の CORS フィルターはデフォルトで無効にされます。環境変数 'CHE_CORS_ENABLED=true' を使用して 'cors.allowed.origins' でこれを有効にし、許可される要求元を示唆します。

CHE_CORS_ALLOW__CREDENTIALS

false

'cors.support.credentials' は、認証情報 (cookie、ヘッダー、TLS クライアント証明書) を使用して要求の処理を許可するかどうかを示します。

表4.11 Factory のデフォルト

環境変数名デフォルト値詳細

CHE_FACTORY_DEFAULT__EDITOR

eclipse/che-theia/7.20.1

CodeReady Workspaces 固有のワークスペース記述子(.factory.jsonの.devfile)が含まれないリモート git リポジトリーから作成される Factory 用に作成されるエディターおよびプラグイン。複数のプラグインは、以下のようにコンマで区切る必要があります。例: pluginFooPublisher/pluginFooName/pluginFooVersion,pluginBarPublisher/pluginBarName/pluginBarVersion

CHE_FACTORY_DEFAULT__PLUGINS

eclipse/che-machine-exec-plugin/7.20.1

CodeReady Workspaces 固有のワークスペース記述子が含まれないリモート git リポジトリーから作成される Factory 用に作成されるエディターおよびプラグイン。複数のプラグインは、以下のようにコンマで区切る必要があります。例: pluginFooPublisher/pluginFooName/pluginFooVersion,pluginBarPublisher/pluginBarName/pluginBarVersion

CHE_FACTORY_DEFAULT__DEVFILE__FILENAMES

devfile.yaml,.devfile.yaml

リポジトリーベースの Factory (GitHub など) を検索する devfile のファイル名。Factory は、プロパティーで列挙される順序でこれらのファイルの特定を試みます。

表4.12 devfile のデフォルト

環境変数名デフォルト値詳細

CHE_WORKSPACE_DEVFILE_DEFAULT__EDITOR

eclipse/che-theia/7.20.1

指定されていない場合に Devfile にプロビジョニングする必要があるデフォルトのエディター。エディター形式は、editorPublisher/editorName/editorVersion 値になります。NULL または値がない場合は、デフォルトのエディターはプロビジョニングされません。

CHE_WORKSPACE_DEVFILE_DEFAULT__EDITOR_PLUGINS

eclipse/che-machine-exec-plugin/7.20.1

デフォルトのエディター用にプロビジョニングする必要があるデフォルトのプラグイン。ユーザー定義の devfile で明示的に参照されていないこの一覧のすべてのプラグインはプロビジョニングされますが、これはデフォルトのエディターが使用されているか、またはユーザー定義のエディターが (異なるバージョンの場合でも) デフォルトと同じである場合に限ります。形式は、コンマ区切りの pluginPublisher/pluginName/pluginVersion 値および URL です。例: eclipse/che-theia-exec-plugin/0.0.1,eclipse/che-theia-terminal-plugin/0.0.1,https://cdn.pluginregistry.com/vi-mode/meta.yaml プラグインが URL の場合、プラグインの meta.yaml はその URL から取得されます。

CHE_WORKSPACE_PROVISION_SECRET_LABELS

app.kubernetes.io/part-of=che.eclipse.org,app.kubernetes.io/component=workspace-secret

ユーザー namespace からシークレットを選択するためにラベルのコンマ区切りの一覧を定義します。これは、ファイルまたは環境変数としてワークスペースコンテナーにマウントされます。すべての指定されるラベルに一致するシークレットのみが選択されます。

CHE_WORKSPACE_DEVFILE_ASYNC_STORAGE_PLUGIN

eclipse/che-async-pv-plugin/nightly

非同期ストレージ機能がワークスペース設定で有効にされ、環境でサポートされる場合に、プラグインが追加されます

CHE_INFRA_KUBERNETES_ASYNC_STORAGE_IMAGE

quay.io/eclipse/che-workspace-data-sync-storage:latest

CodeReady Workspaces 非同期ストレージの Docker イメージ

CHE_WORKSPACE_POD_NODE__SELECTOR

NULL

オプションでワークスペース Pod のノードセレクターを設定します。形式は、コンマ区切りの key=value ペアです (例: disktype=ssd,cpu=xlarge,foo=bar)。

CHE_INFRA_KUBERNETES_ASYNC_STORAGE_SHUTDOWN__TIMEOUT__MIN

120

最後に使用されたワークスペースの停止後の非同期ストレージ Pod のシャットダウンのタイムアウト。0 以下の値は、シャットダウン機能を無効にするものとして解釈されます。

CHE_INFRA_KUBERNETES_ASYNC_STORAGE_SHUTDOWN__CHECK__PERIOD__MIN

30#

非同期ストレージ Pod が機能を停止する期間を定義します (デフォルトでは 30 分ごと)。

表4.13 Che システム

環境変数名デフォルト値詳細

CHE_SYSTEM_SUPER__PRIVILEGED__MODE

false

System Super Privileged Mode (システムのスーパー特権モード)。getByKey、getByNameSpace、stopWorkspaces、および getResources の manageSystem パーミッションの追加パーミッションをユーザーに付与します。これらは、デフォルトでは管理者には提供されず、これらのパーミッションにより、管理者はadmin 権限でそれらのワークスペースに名前を指定し、ワークスペースへの可視性を得ることができます。

CHE_SYSTEM_ADMIN__NAME

admin

'che.admin.name' ユーザーのシステムパーミッションを付与します。ユーザーがすでに存在する場合は、これはコンポーネントの起動時に生じます。ユーザーがすでに存在しない場合は、ユーザーがデータベースで永続化される初回のログイン時に発生します。

表4.14 Workspace の制限

環境変数名デフォルト値詳細

CHE_LIMITS_WORKSPACE_ENV_RAM

16gb

ワークスペースは、開発を行う際のユーザー向けの基本的なランタイムです。ワークスペースの作成方法や、消費されるリソースを制限するパラメーターを設定できます。ユーザーが新規ワークスペースの作成時にワークスペースに割り当てることができる RAM の最大量。RAM スライダーは、この最大値に合わせて調整されます。

CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT

1800000

システムがワークスペースを一時停止した後にこれを停止する際に、ユーザーがワークスペースでアイドル状態になる期間。アイドル状態は、ユーザーがワークスペースと対話しない期間です。つまり、エージェントのいずれも対話を受け取っていない期間を意味します。ブラウザーウィンドウを開いたままにするとアイドル状態になります。

CHE_LIMITS_WORKSPACE_RUN_TIMEOUT

0

システムが一時停止するまでの、アクティビティーを問わず、ワークスペースが実行される期間 (ミリ秒単位)。一定期間後にワークスペースを自動的に停止する場合は、このプロパティーを設定します。デフォルトはゼロで、実行タイムアウトがないことを意味します。

表4.15 ユーザーワークスペースの制限

環境変数名デフォルト値詳細

CHE_LIMITS_USER_WORKSPACES_RAM

-1

単一ユーザーがワークスペースの実行に割り当てることができる RAM の合計量。ユーザーは、この RAM を単一のワークスペースに割り当てるか、または複数のワークスペースに分散することができます。

CHE_LIMITS_USER_WORKSPACES_COUNT

-1

ユーザーが作成できるワークスペースの最大数。追加のワークスペースを作成しようとすると、ユーザーにはエラーメッセージが表示されます。これは、実行中および停止中のワークスペースの合計数に適用されます。

CHE_LIMITS_USER_WORKSPACES_RUN_COUNT

1

単一ユーザーが持てる実行中のワークスペースの最大数。ユーザーがこのしきい値に達し、追加のワークスペースを開始しようとすると、エラーメッセージと共にプロンプトが表示されます。ユーザーは、実行中のワークスペースを停止してから別のワークスペースをアクティべートする必要があります。

表4.16 組織ワークスペースの制限

環境変数名デフォルト値詳細

CHE_LIMITS_ORGANIZATION_WORKSPACES_RAM

-1

単一組織 (チーム) がワークスペースの実行に割り当てることができる RAM の合計量。組織の所有者はこの RAM を割り当てることができますが、チームのワークスペース全体で適切に割り当てられているように見えます。

CHE_LIMITS_ORGANIZATION_WORKSPACES_COUNT

-1

組織が所有できるワークスペースの最大数。追加のワークスペースを作成しようとすると、組織にはエラーメッセージが表示されます。これは、実行中および停止中のワークスペースの合計数に適用されます。

CHE_LIMITS_ORGANIZATION_WORKSPACES_RUN_COUNT

-1

単一組織が持てる実行中のワークスペースの最大数。組織がこのしきい値に達し、追加のワークスペースを開始しようとすると、エラーメッセージと共にプロンプトが表示されます。組織は、実行中のワークスペースを停止してから別のワークスペースをアクティべートする必要があります。

CHE_MAIL_FROM__EMAIL__ADDRESS

che@noreply.com

メール通知の送信元のメールに使用されるアドレス

表4.17 組織通知の設定

環境変数名デフォルト値詳細

CHE_ORGANIZATION_EMAIL_MEMBER__ADDED__SUBJECT

You'vebeen added to a Che Organization

組織の通知の件名およびテンプレート

CHE_ORGANIZATION_EMAIL_MEMBER__ADDED__TEMPLATE

st-html-templates/user_added_to_organization

組織の通知の件名およびテンプレート

CHE_ORGANIZATION_EMAIL_MEMBER__REMOVED__SUBJECT

You'vebeen removed from a Che Organization

 

CHE_ORGANIZATION_EMAIL_MEMBER__REMOVED__TEMPLATE

st-html-templates/user_removed_from_organization

 

CHE_ORGANIZATION_EMAIL_ORG__REMOVED__SUBJECT

CheOrganization deleted

 

CHE_ORGANIZATION_EMAIL_ORG__REMOVED__TEMPLATE

st-html-templates/organization_deleted

 

CHE_ORGANIZATION_EMAIL_ORG__RENAMED__SUBJECT

CheOrganization renamed

 

CHE_ORGANIZATION_EMAIL_ORG__RENAMED__TEMPLATE

st-html-templates/organization_renamed

 

表4.18 マルチユーザー固有の OpenShift インフラストラクチャー設定

環境変数名デフォルト値詳細

CHE_INFRA_OPENSHIFT_OAUTH__IDENTITY__PROVIDER

NULL

Keycloak に登録されている Openshift アイデンティティープロバイダーのエイリアス。これは、現行の CodeReady Workspaces ユーザーが所有する Openshift namespace にワークスペース OpenShift リソースを作成するために使用されます。che.infra.openshift.project が空白以外の値に設定する場合は NULL に設定する必要があります。詳細は、https://www.keycloak.org/docs/latest/server_admin/index.html#openshift-4 のドキュメントを参照してください。

表4.19 Keycloak の設定

環境変数名デフォルト値詳細

CHE_KEYCLOAK_AUTH__SERVER__URL

http://${CHE_HOST}:5050/auth

che.keycloak.oidcProvider を使用している場合のみ、keycloak アイデンティティープロバイダーサーバーの URL を NULL に設定できます。

CHE_KEYCLOAK_REALM

che

Keycloak レルムを使用してユーザーを認証するために使用されます。che.keycloak.oidcProvider が使用している場合のみ NULL に設定できます。

CHE_KEYCLOAK_CLIENT__ID

che-public

ユーザーの認証用にダッシュボード、ide、および cli で使用される che.keycloak.realm の Keycloak クライアント ID

表4.20 Redhat Che 固有の設定

環境変数名デフォルト値詳細

CHE_KEYCLOAK_OSO_ENDPOINT

NULL

OSO oauth トークンにアクセスするための URL

CHE_KEYCLOAK_GITHUB_ENDPOINT

NULL

Github oauth トークンにアクセスするための URL

CHE_KEYCLOAK_ALLOWED__CLOCK__SKEW__SEC

3

exp または nbf 要求を検証する際にクロックスキューについて許容される秒数。

CHE_KEYCLOAK_USE__NONCE

true

OIDC オプションの nonce 機能を使用して、セキュリティーを強化します。

CHE_KEYCLOAK_JS__ADAPTER__URL

NULL

使用する Keycloak Javascript アダプターの URL。NULL に設定すると、デフォルト値が ${che.keycloak.auth_server_url}/js/keycloak.js になり、別のoidc_provider を使用する場合には、<che-server>/api/keycloak/OIDCKeycloak.js になります。

CHE_KEYCLOAK_OIDC__PROVIDER

NULL

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig の仕様で詳細に検出エンドポイントを指定する別の OIDC プロバイダーのベース URL。

CHE_KEYCLOAK_USE__FIXED__REDIRECT__URLS

false

固定されたリダイレクト URL のみをサポートする別の OIDC プロバイダーを使用する場合は true に設定します。このプロパティーは、che.keycloak.oidc_provider が NULL の場合は無視されます。

CHE_KEYCLOAK_USERNAME__CLAIM

NULL

定義されていない場合、JWT トークンの解析時にユーザー名の要求がユーザーの表示名として使用されます。フォールバック値は「preferred_username」です。

CHE_OAUTH_SERVICE__MODE

delegated

「embedded」モードまたは「delegated」モードで使用できる OAuth 認証サービスの設定。「embedded」に設定すると、サービスは、(Single User モードの場合のように) CodeReady Workspaces の OAuthAuthenticator のラッパーとして機能します。「delegated」に設定すると、サービスは Keycloak IdentityProvider メカニズムを使用します。このプロパティーが正しく設定されていない場合は、ランタイム例外がスローされます。

CHE_KEYCLOAK_CASCADE__USER__REMOVAL__ENABLED

false

CodeReady Workspaces データベースからユーザーを削除する際の Keycloak サーバーからのユーザーの削除を有効にするための設定。デフォルトで、これは無効にされます。CodeReady Workspaces データベースでユーザーを削除する際に Keycloak からの関連ユーザーの削除が実行される特別なケースでは有効にされある場合があります。適切に機能するには、管理ユーザー名 ${che.keycloak.admin_username} とパスワード ${che.keycloak.admin_password} を設定する必要があります。

CHE_KEYCLOAK_ADMIN__USERNAME

NULL

Keycloak 管理ユーザー名。CodeReady Workspaces データベースからユーザーを削除する際に Keycloak からユーザーを削除するために使用します。${che.keycloak.cascade_user_removal_enabled} が 'true' に設定されている場合にのみ機能します。

CHE_KEYCLOAK_ADMIN__PASSWORD

NULL

Keycloak 管理者パスワード。CodeReady Workspaces データベースからユーザーを削除する際に Keycloak からユーザーを削除するために使用します。${che.keycloak.cascade_user_removal_enabled} が 'true' に設定されている場合にのみ機能します。

4.2. プロジェクトストラテジーの設定

OpenShift プロジェクトストラテジーは、CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT 環境変数を使用して設定されます。

警告

CHE_INFRA_KUBERNETES_NAMESPACE および CHE_INFRA_OPENSHIFT_PROJECT はレガシー変数です。新規インストールでは、これらの変数は未設定のままにします。更新時にこれらの変数を変更すると、データが失われる可能性があります。

警告

デフォルトでは、同じプロジェクト内で同時に実行できるワークスペースは 1 つだけです。「一度に複数のワークスペースの実行」を参照してください。

4.2.1. ワークスペースストラテジーごとに 1 つのプロジェクト

ストラテジーは、新規ワークスペースごとに新規プロジェクトを作成します。

ストラテジーを使用するには、CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT 変数値に <workspaceID> 識別子が含まれている必要があります。これは単独で使用することも、他の ID または任意の文字列と組み合わせることもできます。

例4.2 ワークスペースごとに 1 つのプロジェクト

'codeready-ws' プレフィックスおよびワークスペース ID で構成されるプロジェクト名を割り当てるには、以下を設定します。

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=codeready-ws-<workspaceID>

4.2.2. すべてのワークスペースストラテジーに 1 つのプロジェクト

ストラテジーは、すべてのワークスペースに 1 つの事前に定義されたプロジェクトを使用します。

ストラテジーを使用するには、CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT 変数の値は使用する希望のプロジェクトの名前である必要があります。

例4.3 すべてのワークスペースに 1 つのプロジェクト

すべてのワークスペースを 'codeready-ws' プロジェクトで作成する場合は、以下を設定します。

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=codeready-ws

4.2.3. ユーザーストラテジーごとに 1 つのプロジェクト

ストラテジーは、独自のプロジェクトの各ユーザーを分離します。

ストラテジーを使用するには、CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT 変数の値に 1 つ以上のユーザー識別子が含まれている必要があります。現在サポートされている識別子は <username><userid> です。

例4.4 ユーザーごとに 1 つのプロジェクト

'codeready-ws' プレフィックスおよび個々のユーザー名(codeready-ws-user1codeready-ws-user2) で構成されるプロジェクト名を割り当てるには、以下を設定します。

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=codeready-ws-<username>

4.2.4. ユーザー定義のワークスペースプロジェクトの許可

CodeReady Workspaces サーバーは、ワークスペースの作成時にプロジェクトのユーザー選択を有効にするように設定できます。この機能はデフォルトでは無効にされます。ユーザー定義のワークスペースプロジェクトを許可するには、以下を実行します。

  • Operator デプロイメントの場合、CheCluster カスタムリソースに以下のフィールドを設定します。

    allowUserDefinedWorkspaceNamespaces

4.2.5. 互換性のないユーザー名またはユーザー ID の処理

CodeReady Workspaces サーバーは、テンプレートからプロジェクトを作成する前に、OpenShift オブジェクトの命名規則との互換性についてユーザー名と ID を自動的にチェックします。互換性のないユーザー名または ID は、適切ではないシンボルのグループを - に置き換えることにより減少し、ほぼ有効な名前のみに絞られます。競合を回避するために、ランダムな 6 記号のサフィックスが追加され、結果は再利用できるように設定に保存されます。

4.2.6. ユーザーのプロジェクトの事前作成

ユーザーのプロジェクトを事前に作成するには、プロジェクトのラベルおよびアノテーションを使用します。

metadata:
  labels:
    app.kubernetes.io/component: workspace
    app.kubernetes.io/part-of: che.eclipse.org
  annotations:
    che.eclipse.org/username: <username>  1
1
ターゲットユーザーのユーザー名

ラベルを設定するには、CHE_INFRA_KUBERNETES_NAMESPACE_LABELS を必要なラベルに設定します。アノテーションを設定するには、CHE_INFRA_KUBERNETES_NAMESPACE_ANNOTATIONS を必要なアノテーションに設定します。詳細は、「CodeReady Workspaces サーバーコンポーネントのシステムプロパティー参照」 を参照してください。

重要

OAuth を使用する OpenShift では、ターゲットユーザーにはターゲット namespace で admin ロール権限が必要です。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin
  namespace: <namespace> 1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: <username> 2
1
事前に作成される namespace
2
ターゲットユーザー

Kubernetes では、che ServiceAccount には、クラスター全体での list namespaces パーミッションと、ターゲット namespace の admin ロールが必要です。

4.3. 一度に複数のワークスペースの実行

この手順では、複数のワークスペースを同時に実行する方法を説明します。これにより、ユーザーごとに複数のワークスペースのコンテキストを並行して実行できます。

前提条件

  • '`oc’ ツールが利用できる。
  • OpenShift で実行される CodeReady Workspaces のインスタンス。

    注記

    以下のコマンドは、-n オプションのユーザー例として、デフォルトの OpenShift プロジェクト workspaces を使用します。

手順

  1. ユーザーごとの同時ワークスペースの数を無制限にするには、1 のデフォルト制限を -1 に変更します。
$ oc patch checluster codeready-workspaces -n workspaces --type merge \
  -p '{ "spec": { "server": {"customCheProperties": {"CHE_LIMITS_USER_WORKSPACES_RUN_COUNT": "-1"} } }}'
  1. per-workspace または unique PVC ストラテジーを設定します。永続ボリュームストラテジーを使用した CodeReady Workspaces ワークスペースの設定を参照してください。

    注記

    common PVC ストラテジーを使用する場合、永続ボリュームを ReadWriteMany アクセスモードを使用するように設定します。これにより、ユーザーの同時ワークスペースのいずれかが共通 PVC からの/への読み取り/書き込みを実行できます。

4.4. ワークスペース公開ストラテジーの設定

CodeReady Workspaces サーバーのワークスペース公開ストラテジーを設定し、内部で実行されているアプリケーションが外部からの攻撃を受けないようにする方法を説明します。

ワークスペース公開ストラテジーは、che.infra.kubernetes.server_strategy 設定プロパティーまたは CHE_INFRA_KUBERNETES_SERVER__STRATEGY 環境変数を使用して CodeReady Workspaces サーバーごとに設定されます。

che.infra.kubernetes.server_strategy のサポートされる値は次のとおりです。

  • multi-host

multi-host ストラテジーを有効にするには、以下を実行します。

  1. 以下を設定します。

    • che.infra.kubernetes.ingress.domain 設定プロパティー

      または

    • CHE_INFRA_KUBERNETES_INGRESS_DOMAIN 環境変数

      ワークスペースコンポーネントのサブドメインをホストするドメイン名に一致するには、以下を実行します。

4.4.1. ワークスペース公開ストラテジー

ワークスペースの特定のコンポーネントは、OpenShift クラスター外からアクセスできるようにする必要があります。通常、これはワークスペースの IDE のユーザーインターフェースですが、開発されるアプリケーションの Web UI である可能性もあります。これにより、開発プロセスでの開発者のアプリケーションとの対話が可能になります。

ワークスペースをユーザーが使用できるようにするためのサポートされる方法は、ストラテジー と呼ばれます。このストラテジーは、ワークスペースコンポーネントに新しいサブドメインが作成されるかどうか、およびこれらのコンポーネントを利用可能にするホストを定義します。

CodeReady Workspaces は以下をサポートします。

  • Multi-host ストラテジー
  • single-host ストラテジー

    • gateway サブタイプの使用

4.4.1.1. Multi-host ストラテジー

このストラテジーでは、各ワークスペースコンポーネントには、CodeReady Workspaces サーバーに設定された主なドメインの新規サブドメインが割り当てられます。OpenShift では、これは唯一のストラテジーであり、ワークスペース公開ストラテジーの手動設定は常に無視されます。

このストラテジーは、コンポーネントへの URL に存在するいずれのパスもコンポーネントごとにそのまま受信されるため、コンポーネントのデプロイメントの点で最も理解しやすいストラテジーです。

Transport Layer Security (TLS) プロトコルの使用によってセキュリティーが保護された CodeReady Workspaces サーバーで、各ワークスペースの各コンポーネントに新規のサブドメインを作成するには、CodeReady Workspaces デプロイメントが機能するため、このようなサブドメインすべてについてワイルドカード証明書が利用可能である必要があります。

4.4.1.2. 単一ホストストラテジー

単一ホストストラテジーには、異なる実装方法が設定された 2 つのサブタイプがあります。最初のサブタイプの名前は native です。このストラテジーは Kubernetes でデフォルトで利用できますが、サーバーの公開に ingress を使用するため、OpenShift では利用できません。gateway という名前の 2 つ目のサブタイプは OpenShift の両方で機能し、内部で実行されるリバースプロキシーのある特別な Pod を使用して要求をルーティングします。

これらの単一ホストタイプのいずれかが使用される場合、すべてのワークスペースはメインの CodeReady Workspaces サーバードメインのサブパスにデプロイされます。

これは、すべてのワークスペースコンポーネントのデプロイメントに対応する CodeReady Workspaces サーバーの単一の証明書のみが必要となるため、TLS で保護される CodeReady Workspaces サーバーの場合に便利です。

devfile に指定されたエンドポイントを公開する方法は 2 つあります。これらは、CodeReady Workspaces の CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_DEVFILE__ENDPOINT__EXPOSURE 環境変数を使用して設定できます。この環境変数は、single-host サーバーストラテジーでのみ有効であり、すべてのユーザーのすべてのワークスペースに適用できます。

4.4.1.2.1. devfile エンドポイント:single-host

CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_DEVFILE__ENDPOINT__EXPOSURE: 'single-host'

この単一ホスト設定は、サブパスのエンドポイントを公開します(例:https://<che-host>/serverihzmuqqc/go-cli-server-8080 )。これにより、公開されるコンポーネントおよびユーザーアプリケーションが制限されます。サーバーを参照するサーバー側で生成される絶対 URL は機能しません。これは、サーバーが、コンポーネントまたはユーザーアプリケーションから一意の URL パスのプレフィックスを非表示にするパスが書き換えられるリバースプロキシーの背後にあるためです。

たとえば、ユーザーが仮の [https://codeready-<openshift_deployment_name>.<domain_name>/component-prefix-djh3d/app/index.php] URL にアクセスする場合に、アプリケーションには要求が https://internal-host/app/index.php に送信されるように表示されます。アプリケーションが UI で生成する URL でホストを使用している場合、内部ホストが外部に表示されるホストとは異なるため、これは機能しません。ただし、アプリケーションが URL に絶対パスを使用している場合 (上記の場合は /app/index.php)、この URL は依然として機能しません。これは、外部ではこの URL はコンポーネント固有のプレフィックスがなく、アプリケーションを参照しないためです。

そのため、UI で相対 URL を使用するアプリケーションのみが、single-host ワークスペース公開ストラテジーで機能します。

4.4.1.2.2. devfile エンドポイント: multi-host

CHE_INFRA_KUBERNETES_SINGLEHOST_WORKSPACE_DEVFILE__ENDPOINT__EXPOSURE: 'multi-host'

この単一ホスト設定は、サブドメインのエンドポイントを公開します(例:http://serverihzmuqqc-go-cli-server-8080.<che-host)。これらのエンドポイントは、セキュアでない HTTP ポートで公開されます。gateway 単一ホストの設定でも、専用の Ingress または Route がこのエンドポイントに使用されます。

この設定により、CodeReady Workspaces が TLS で設定されている場合に、エディターページに直接表示されるプレビューの使用が制限されます。https ページはセキュリティーが保護されたエンドポイントとの通信のみを許可するため、ユーザーは別のブラウザータブでアプリケーションのプレビューを開く必要があります。

4.4.2. セキュリティーに関する考慮事項

本セクションでは、さまざまな CodeReady Workspaces ワークスペースの公開ストラテジーを使用するセキュリティー上の影響について説明します。

本セクションのすべてのセキュリティー関連の考慮事項は、マルチユーザーモードの CodeReady Workspaces のみに適用されます。単一ユーザーモードは、セキュリティー制限を課しません。

4.4.2.1. JSON Web トークン (JWT) プロキシー

すべての CodeReady Workspaces プラグイン、エディター、およびコンポーネントには、それらにアクセスするユーザーの認証が必要になる場合があります。この認証は、その設定に基づいて対応するコンポーネントのリバースプロキシーとして機能し、コンポーネントの代わりに認証を実行する JSON Web トークン (JWT) プロキシーを使用して実行されます。

認証では、CodeReady Workspaces サーバーの特別なページへのリダイレクトを使用して、ワークスペースおよびユーザー固有の認証トークン (ワークスペースアクセストークン) を最初に要求されたページに伝播します。

JWT プロキシーは、受信要求の以下の場所からのワークスペースアクセストークンを受け入れます。

  1. トークンクエリーパラメーター
  2. bearer-token 形式の Authorization ヘッダー
  3. access_token クッキー

4.4.2.2. セキュリティーが保護されたプラグインおよびエディター

CodeReady Workspaces ユーザーはワークスペースのプラグインやワークスペースのエディター (Che-Theia など) のセキュリティーを保護する必要はありません。これは、JWT プロキシー認証はユーザーに透過的であり、meta.yaml 記述子のプラグインまたはエディター定義によって制御されるためです。

4.4.2.3. セキュリティー保護されたコンテナーイメージコンポーネント

コンテナーイメージのコンポーネントは、必要に応じて devfile の作成者側が CodeReady Workspaces が提供する認証を要求するカスタムエンドポイントを定義できます。この認証は、エンドポイントの 2 つのオプション属性を使用して設定されます。

  • secure - CodeReady Workspaces サーバーに対し、エンドポイントの前に JWT プロキシーを配置するよう指示するブール値属性。このエンドポイントでは、「JSON Web トークン (JWT) プロキシー」 で説明されているいくつかの方法のいずれかを使用して、ワークスペースのアクセストークンが提供される必要があります。属性のデフォルト値は false です。
  • cookiesAuthEnabled - 「JSON Web トークン (JWT) プロキシー」 で説明されているように、CodeReady Workspaces サーバーに対し、現在のユーザー認証の非認証要求を自動的にリダイレクトするように指示するブール値属性。この属性を true に設定すると、CSRF (クロスサイトリクエストフォージェリー) 攻撃が可能になり、セキュリティー上の影響が発生します。属性のデフォルト値は false です。

4.4.2.4. クロスサイトリクエストフォージェリー攻撃

cookie ベースの認証に、JWT プロキシーによってセキュリティーが保護されたアプリケーションは CSRF (Cross-site Request forgery) 攻撃の対象となりやすくする場合があります。アプリケーションに脆弱性がないことを確認するには、CSRF (Cross-site request forgery) についての Wikipedia ページやその他のリソースを参照してください。

4.4.2.5. フィッシング攻撃

JWT プロキシーの背後にあるサービスとホストを共有するワークスペースを使用してクラスター内に Ingress またはルートを作成できる攻撃者は、サービスの作成やとくに偽造された Ingress オブジェクトの作成が可能になる場合があります。このようなサービスまたは Ingress がワークスペースで以前に認証されている適切なユーザーによってアクセスされる際に、攻撃者は偽の URL への適切なユーザーのブラウザーが送信する cookie からワークスペースアクセストークンを盗むことができる可能性があります。この攻撃ベクトルを排除するには、Ingress のホストの設定を禁止するように OpenShift を設定します。

4.5. ワークスペース nodeSelector の設定

このセクションでは、CodeReady Workspaces ワークスペースの Pod について nodeSelector を設定する方法を説明します。

手順

CodeReady Workspaces は CHE_WORKSPACE_POD_NODE__SELECTOR 環境変数を使用して nodeSelector を設定します。この変数には、nodeSelector ルールを形成するためにコンマ区切りの key=value ペアのセットが含まれるか、またはこれを無効にする NULL が含まれる場合があります。

CHE_WORKSPACE_POD_NODE__SELECTOR=disktype=ssd,cpu=xlarge,[key=value]
重要

nodeSelector は CodeReady Workspaces のインストール時に設定する必要があります。これにより、既存のワークスペース PVC および Pod が異なるゾーンにスケジュールされることによってボリュームのアフィニティーの競合が生じ、既存のワークスペースが実行できなくなることを防ぐことができます。

大規模なマルチゾーンクラスターの異なるゾーンに Pod および PVC がスケジュールされないようにするには、PVC の作成プロセスを調整する追加の StorageClass オブジェクトを作成します(allowedTopologies フィールドに注目してください)。

新規に作成された StorageClass の名前を、CHE_INFRA_KUBERNETES_PVC_STORAGE__CLASS__NAME 環境変数で CodeReady Workspaces に指定します。この変数のデフォルトの空の値の場合、CodeReady Workspaces に対し、クラスターのデフォルト StorageClass を使用するように指示します。

4.6. Red Hat CodeReady Workspaces サーバーのホスト名の設定

この手順では、カスタムホスト名を使用するように Red Hat CodeReady Workspaces を設定する方法を説明します。

前提条件

  • oc ツールが利用できる。
  • 証明書とプライベートキーファイルが生成されます。
重要

プライベートキーと証明書のペアを生成するには、他の Red Hat CodeReady Workspaces ホストの場合と同じ CA を使用する必要があります。

重要

DNS プロバイダーに対し、カスタムホスト名をクラスター Ingress を参照するよう要求します。

手順

  1. CodeReady Workspaces のプロジェクトを事前に作成します。

    $ oc create project workspaces
  2. tls Secret を作成します。

    $ oc create secret tls ${secret} \  1
    --key ${key_file} \                       2
    --cert ${cert_file} \                     3
    -n workspaces
    1
    tls Secret 名
    2
    プライベートキーを含むファイル
    3
    証明書を含むファイル
  3. カスタムリソースに以下の値を設定します。

    spec:
      server:
        cheHost: <hostname>         1
        cheHostTLSSecret: <secret>  2
    1
    カスタム Red Hat CodeReady Workspaces サーバーのホスト名
    2
    tls Secret 名
  4. CodeReady Workspaces がすでにデプロイされており、CodeReady Workspaces を新しい CodeReady Workspaces ホスト名を使用するように再設定する必要がある場合には、RH-SSO を使用してログインし、CodeReady Workspaces レルムで codeready-public クライアントを選択し、CodeReady Workspaces ホスト名の値で Validate Redirect URIs および Web Origins フィールドを更新します。

    keycloak che public client

4.7. OpenShift Ingress のラベルの設定

この手順では、OpenShift Ingress のラベルを、オブジェクトを整理し、分類 (スコープおよび選択)するように設定する方法を説明します。

前提条件

  • oc ツールが利用できる。
  • OpenShift で実行される CodeReady Workspaces のインスタンス。
重要

コンマを使用して、ラベルを区切ります: key1=value1,key2=value2

手順

  1. OpenShift Ingress のラベルを設定するには、以下のコマンドを使用してカスタムリソースを更新します。

    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/cheServerIngress/labels", '\
    '"value": "<labels for a codeready-workspaces server ingress>"}]'
    
    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/auth/identityProviderIngress/labels", '\
    '"value": "<labels for a RH-SSO ingress>"}]'
    
    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/pluginRegistryIngress/labels", '\
    '"value": "<labels for a plugin registry ingress>"}]'
    
    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/devfileRegistryIngress/labels",'\
    '"value": "<labels for a devfile registry ingress>"}]'

4.8. OpenShift Route のラベルの設定

この手順では、OpenShift Route のラベルを、オブジェクトを整理し、分類 (スコープおよび選択)するように設定する方法を説明します。

前提条件

  • oc ツールが利用できる。
  • OpenShift で実行される CodeReady Workspaces のインスタンス。
重要

コンマを使用して、ラベルを区切ります: key1=value1,key2=value2

手順

  1. OpenShift Route のラベルを設定するには、以下のコマンドを使用してカスタムリソースを更新します。

    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/cheServerRoute/labels",'\
    '"value": "<labels for a codeready-workspaces server route>"}]'
    
    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/auth/identityProviderRoute/labels", '\
    '"value": "<labels for a RH-SSO route>"}]'
    
    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/pluginRegistryRoute/labels", '\
    '"value": "<labels for a plugin registry route>"}]'
    
    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/devfileRegistryRoute/labels", '\
    '"value": "<labels for a devfile registry route>"}]'

4.9. 自己署名証明書を使用した Git リポジトリーをサポートする CodeReady Workspaces のデプロイ

この手順では、自己署名証明書を使用するリポジトリーで Git 操作のサポートのあるデプロイメント用に CodeReady Workspaces を設定する方法を説明します。

前提条件

  • Git バージョン 2 以降

手順

自己署名の Git リポジトリーのサポートの設定。

  1. Git サーバーの詳細情報を使用して新規の configMap を作成します。

    $ oc create configmap che-git-self-signed-cert --from-file=ca.crt \
      --from-literal=githost=<host:port> -n {prod-namespace}

    このコマンドで、<host:port> を Git サーバーの HTTPS 接続のホストおよびポートに置き換えます (オプション)。

    注記
    • githost を指定しないと、指定された証明書がすべての HTTPS リポジトリーに使用されます。
    • 証明書ファイルの名前は ca.crt にする必要があります。
    • 証明書ファイルは、通常、以下のような Base64 ASCII ファイルとして保存されます。.pem, .crt, .ca-bundle.また、これらはバイナリーデータとしてエンコードすることもできます (例: .cer)。証明書ファイルを保持するすべての Secrets は、バイナリーデータ証明書ではなく、Base64 ASCII 証明書を使用する必要があります。
  2. ワークスペースの公開ストラテジーを設定します。

    gitSelfSignedCert プロパティーを更新します。これを行うには、以下を実行します。

    $ oc patch checluster codeready-workspaces -n workspaces --type=json \
      -p '[{"op": "replace", "path": "/spec/server/gitSelfSignedCert", "value": true}]'
  3. 新規ワークスペースを作成および開始します。ワークスペースによって使用されるすべてのコンテナーは、自己署名証明書のあるファイルを含む特殊なボリュームをマウントします。リポジトリーの .git/config ファイルには、Git サーバーホスト (その URL) と http セクションの証明書へのパスについての情報が含まれます(git-configに関する Git ドキュメントを参照してください)。以下は例になります。

    [http "https://10.33.177.118:3000"]
            sslCAInfo = /etc/che/git/cert/ca.crt

4.10. ストレージクラスを使用した CodeReady Workspaces のインストール

設定済みのインフラストラクチャーストレージを使用するように CodeReady Workspaces を設定するには、ストレージクラスを使用して CodeReady Workspaces をインストールします。これは、ユーザーがデフォルト以外のプロビジョナーによって提供される永続ボリュームをバインドする必要がある場合にとくに役立ちます。これを実行するには、ユーザーは CodeReady Workspaces のデータを節約するためにこのストレージをバインドし、そのストレージのパラメーターを設定します。これらのパラメーターは、以下を決定します。

  • 特殊なホストパス
  • ストレージ容量
  • ボリューム mod
  • マウントオプション
  • ファイルシステム
  • アクセスモード
  • ストレージタイプ
  • その他多数

CodeReady Workspaces には、データの格納に永続ボリュームが必要な 2 つのコンポーネントがあります。

  • PostgreSQL データベース。
  • CodeReady Workspaces ワークスペース。CodeReady Workspaces ワークスペースは、ボリューム (例: /projects ボリューム) を使用してソースコードを保存します。
注記

CodeReady Workspaces ワークスペースのソースコードは、ワークスペースが一時的ではない場合にのみ永続ボリュームに保存されます。

永続ボリューム要求 (PVC)のファクト:

  • CodeReady Workspaces はインフラストラクチャーに永続ボリュームを作成しません。
  • CodeReady Workspaces は永続ボリューム要求 (PVC)を使用して永続ボリュームをマウントします。
  • CodeReady Workspaces サーバーは永続ボリューム要求を作成します。

    ユーザーは、CodeReady Workspaces PVC でストレージクラス機能を使用するために、CodeReady Workspaces 設定でストレージクラス名を定義します。ストレージクラスを使用すると、ユーザーは追加のストレージパラメーターを使用してインフラストラクチャーストレージを柔軟に設定します。クラス名を使用して、静的にプロビジョニングされた永続ボリュームを CodeReady Workspaces PVC にバインドすることもできます。

手順

CheCluster カスタムリソース定義を使用してストレージクラスを定義します。

  1. ストレージクラス名を定義します。

    これを行うには、以下のいずれかの方法を使用します。

    • server:deploy コマンドの引数の使用

      1. PostgreSQL PVC のストレージクラス名を指定します。

        --postgres-pvc-storage-class-name フラグを指定して crwctl server:deploy コマンドを使用します。

        $ crwctl server:deploy -m -p minikube -a operator --postgres-pvc-storage-class-name=postgress-storage
      2. CodeReady Workspaces ワークスペースのストレージクラス名を指定します。

        --workspace-pvc-storage-class-name フラグを指定して server:deploy コマンドを使用します。

        $ crwctl server:deploy -m -p minikube -a operator --workspace-pvc-storage-class-name=workspace-storage

        CodeReady Workspaces ワークスペースでは、ワークスペースの PVC ストラテジーに応じてストレージクラスの名前の動作が異なります。

        注記

        Postgres-pvc-storage-class-name=postgress-storage および workspace-pvc-storage-class-name は、Operator インストーラーおよび Helm インストーラーで機能します。

    • カスタムリソース YAML ファイルを使用してストレージクラス名を定義します。

      1. CodeReady Workspaces インストールに定義されたカスタムリソースで YAML ファイルを作成します。
      2. フィールド spec#storage#postgresPVCStorageClassName および spec#storage#workspacePVCStorageClassName を定義します。

        apiVersion: org.eclipse.che/v1
        kind: CheCluster
        metadata:
          name: codeready-workspaces
        spec:
          # ...
          storage:
            # ...
            # keep blank unless you need to use a non default storage class for PostgreSQL PVC
            postgresPVCStorageClassName: 'postgres-storage'
            # ...
            # keep blank unless you need to use a non default storage class for workspace PVC(s)
            workspacePVCStorageClassName: 'workspace-storage'
            # ...
      3. カスタムリソースで codeready-workspaces サーバーを起動します。

        $ crwctl server:deploy -m -p minikube -a operator --che-operator-cr-yaml=/path/to/custom/che/resource/org_v1_che_cr.yaml
  2. CodeReady Workspaces を、ワークスペースを 1 つ目の永続ボリュームに、PostreSQL データベースを 2 つ目の永続ボリュームに保存するように設定します。

    1. カスタムリソース YAML ファイルを変更します。

      • pvcStrategycommon に設定します。
      • 単一のプロジェクトでワークスペースを開始するように CodeReady Workspaces を設定します。
      • postgresPVCStorageClassName および workspacePVCStorageClassName のストレージクラス名を定義します。
      • YAML ファイルの例:

        apiVersion: org.eclipse.che/v1
        kind: CheCluster
        metadata:
          name: codeready-workspaces
        spec:
          server:
            # ...
            workspaceNamespaceDefault: 'che'
            # ...
          storage:
            # ...
            # Defaults to common
            pvcStrategy: 'common'
            # ...
            # keep blank unless you need to use a non default storage class for PostgreSQL PVC
            postgresPVCStorageClassName: 'postgres-storage'
            # ...
            # keep blank unless you need to use a non default storage class for workspace PVC(s)
            workspacePVCStorageClassName: 'workspace-storage'
            # ...
    2. カスタムリソースで codeready-workspaces サーバーを起動します。

      $ crwctl server:deploy -m -p minikube -a operator --che-operator-cr-yaml=/path/to/custom/che/resource/org_v1_che_cr.yaml
  3. クラス名を使用して静的にプロビジョニングされたボリュームをバインドします。

    1. PostgreSQL データベースの永続ボリュームを定義します。

      # che-postgres-pv.yaml
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: postgres-pv-volume
        labels:
          type: local
      spec:
        storageClassName: postgres-storage
        capacity:
          storage: 1Gi
        accessModes:
          - ReadWriteOnce
        hostPath:
          path: "/data/che/postgres"
    2. CodeReady Workspaces ワークスペースの永続ボリュームを定義します。

      # che-workspace-pv.yaml
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: workspace-pv-volume
        labels:
          type: local
      spec:
        storageClassName: workspace-storage
        capacity:
          storage: 10Gi
        accessModes:
          - ReadWriteOnce
        hostPath:
          path: "/data/che/workspace"
    3. 2 つの永続ボリュームをバインドします。
$ oc apply -f che-workspace-pv.yaml -f che-postgres-pv.yaml
注記

ボリュームの有効なファイルパーミッションを指定する必要があります。これは、ストレージクラスの設定を使用して実行することも、手動で実行することもできます。パーミッションを手動で定義するには、storageClass#mountOptions uidgid を定義します。PostgreSQL ボリュームには uid=26gid=26 が必要です。

4.11. ストレージタイプの設定

Red Hat CodeReady Workspaces は、さまざまな機能を備えた 3 種類のストレージをサポートします。

  • Persistent (永続)
  • Ephemeral (一時)
  • Asynchronous (非同期)

4.11.1. 永続ストレージ

永続ストレージにより、マウントされた永続ボリュームにユーザーの変更を直接保存できます。とくに小さなファイルが数多くある場合に I/O が低速になりますが、ユーザーの変更は OpenShift インフラストラクチャー (ストレージバックエンド) によって保護されます。たとえば、Node.js プロジェクトには多くの依存関係が含まれることがあり、node_modules/ ディレクトリーには数千の小さなファイルが含まれます。

注記

I/O の速度は、環境内で設定されているストレージクラスによって異なります。

永続ストレージは、新規ワークスペースのデフォルトモードです。この設定をワークスペース設定で表示できるようにするには、以下を devfile に追加します。

attributes:
 persistVolumes: 'true'

4.11.2. 一時ストレージ

一時ストレージでは、ファイルを emptyDir ボリュームに保存します。このボリュームは最初は空の状態です。Pod がノードから削除されると、emptyDir ボリュームのデータは永久に削除されます。つまり、ワークスペースの停止または再起動時にすべての変更が失われます。

重要

変更を保存するには、一時ワークスペースを停止する前に、リモートへのコミットおよびプッシュを実行します。

一時モードは、永続ストレージよりも高速な I/O を提供します。このストレージタイプを有効にするには、以下をワークスペース設定に追加します。

attributes:
 persistVolumes: 'false'

表4.21 AWS EBS での一時モード (emptyDir) と永続モードの I/O の比較

コマンドEphemeral (一時)Persistent (永続)

Red Hat CodeReady Workspaces のクローン作成

0 m 19 s

1 m 26 s

1000 のランダムなファイルの生成

1 m 12 s

44 m 53 s

4.11.3. 非同期ストレージ

注記

非同期ストレージは実験的な機能です。

非同期ストレージは、永続ストレージと一時モードの組み合わせです。初期ワークスペースコンテナーは emptyDir ボリュームをマウントします。次に、ワークスペースの停止時にバックアップが実行され、変更がワークスペースの起動時に復元されます。非同期ストレージは、(一時モードと同様の)高速 I/O を提供し、ワークスペースプロジェクトの変更は永続化されます。

同期は、SSH プロトコルを使用して rsync ツールで実行されます。ワークスペースが非同期ストレージで設定されている場合、workspace-data-sync プラグインはワークスペース設定に自動的に追加されます。プラグインはワークスペースの開始時に rsync コマンドを実行して変更を復元します。ワークスペースが停止したら、変更を永続ストレージに送信します。

比較的小規模なプロジェクトの場合、復元手順は高速で、Che-Theia が初期化されるとプロジェクトのソースファイルはすぐに利用可能になります。rsync にかかる時間が長いと、同期プロセスは Che-Theia のステータスバーの領域に表示されます。(Che-Theia リポジトリーの拡張)。

status bar file sync
注記

非同期モードには、以下の制限があります。

  • common PVC ストラテジーのみをサポートします。
  • ユーザーごとの プロジェクトストラテジーのみをサポートします。
  • 1 度に実行できるワークスペースは 1 つのみです。

ワークスペースの非同期ストレージを設定するには、以下をワークスペース設定に追加します。

attributes:
 asyncPersist: 'true'
 persistVolumes: 'false'

4.11.4. CodeReady Workspaces ダッシュボードのストレージタイプのデフォルトの設定

以下の 2 つの che.properties を使用して、CodeReady Workspaces ダッシュボードでデフォルトのクライアント値を設定します。

che.workspace.storage.available_types

ワークスペースの作成または更新時に、ダッシュボードなどのクライアントがユーザーに提案するストレージタイプに使用できる値を定義します。使用できる値は persistentephemeral および async です。複数の値をコンマで区切ります。以下は例になります。

che.workspace.storage.available_types=persistent,ephemeral,async
che.workspace.storage.preferred_type

ワークスペースの作成時または更新時に、ダッシュボードなどのクライアントがユーザーに提案するストレージタイプのデフォルト値を定義します。async 値は、実験的な取組であるため、デフォルトタイプとしての使用は推奨されません。以下は例になります。

che.workspace.storage.preferred_type=persistent

Storage Type ドロップダウンメニューは、ユーザーダッシュボードの Create Custom Workspace ページで利用できます。

create custom ws storage type 2
create custom ws storage type

4.11.5. 非同期ストレージ Pod のアイドリング

CodeReady Workspaces は、設定された期間に使用されていない場合に、非同期ストレージ Pod をシャットダウンできます。

動作を調整するには、以下の設定プロパティーを使用します。

che.infra.kubernetes.async.storage.shutdown_timeout_min
最後のアクティブなワークスペースの停止後に非同期ストレージ Pod が停止されるアイドル時間を定義します。デフォルト値は 120 分です。
che.infra.kubernetes.async.storage.shutdown_check_period_min
非同期ストレージ Pod でアイドル状態をチェックする頻度を定義します。デフォルト値は 30 分です。

4.12. 信頼できない TLS 証明書の CodeReady Workspaces へのインポート

CodeReady Workspaces コンポーネントの内部通信は、デフォルトでは TLS で暗号化されます。CodeReady Workspaces コンポーネントのプロキシー、ソースコードリポジトリー、アイデンティティープロバイダーなどの外部サービスとの通信では、TLS ツールが必要になる場合があります。これらの通信では、信頼できる認証局が署名する SSL 証明書を使用する必要があります。

CodeReady Workspaces コンポーネントまたは外部サービスで使用される証明書が信頼できない CA によって署名される場合、CodeReady Workspaces インストールで CA 証明書をインポートする必要があるため、すべての CodeReady Workspaces コンポーネントがそれらを信頼できる CA によって署名されているものと見なす必要があります。

この追加が必要になる可能性のある典型的なケースは以下のとおりです。

  • 基礎となる OpenShift クラスターが信頼されていない CA によって署名される TLS 証明書を使用する場合
  • CodeReady Workspaces サーバーまたはワークスペースコンポーネントが、信頼できない CA で署名された TLS 証明書を使用する RH-SSO や Git サーバーなどの外部サービスに接続する場合

これらの証明書を保存するには、CodeReady Workspaces は専用の ConfigMap を使用します。デフォルトの名前は ca-certs ですが、CodeReady Workspaces ではその名前を設定できます。

注記

クラスターに、クラスター全体のプロキシー設定を使用して追加されたクラスター全体の信頼される CA 証明書が含まれる場合、CodeReady Workspaces Operator はそれらを検知し、それらをこの ConfigMap に自動的に挿入します。

  • CodeReady Workspaces は、ConfigMap に自動的に config.openshift.io/inject-trusted-cabundle="true" ラベルを付けます。
  • このアノテーションに基づいて、OpenShift は ConfigMap の ca-bundle.crt キー内にクラスター全体で信頼される CA 証明書を自動的に挿入します。

4.12.1. CodeReady Workspaces のインストール時

前提条件

  • oc ツールが利用できる。
  • CheCluster カスタムリソースを作成する準備が整いました。

手順

  1. インポートする必要のある証明書をローカルファイルシステムに保存します。

    注意
    • 証明書ファイルは、通常、.pem、. crt.ca-bundle などの Base64 ASCII ファイルとして保存されます。ただし、それらにはバイナリーエンコード (例: .cer ファイル) を使用することもできます。証明書ファイルを保持するすべてのシークレットでは、バイナリーでエンコードされる証明書ではなく、Base64 ASCII 証明書を使用する必要があります。
    • CodeReady Workspaces はすでに予約済みのファイル名を使用して証明書を ConfigMap に自動的に挿入するため、以下の予約済みのファイル名を使用して証明書を保存しないようにしてください。

      • ca-bundle.crt
      • ca.crt
  2. 必要な TLS 証明書で新規 ConfigMap を作成します。

    $ oc create configmap ca-certs --from-file=<certificate-file-path> -n=<crw-namespace-name>

    複数の証明書を適用するには、上記のコマンドに別の --from-file=<certificate-file-path> オプションを追加します。

  3. インストールプロセス時に、CheCluster カスタムリソースの作成時に、作成された ConfigMap の適切な名前を設定します。

    CodeReady Workspaces Operator のデプロイメントでは、ConfigMap の名前を持つ spec.server.ServerTrustStoreConfigMapName フィールドを、インストール時に作成する CheCluster カスタムリソースに追加します。

    spec:
      server:
        ...
        spec.server.ServerTrustStoreConfigMapName: ca-certs

4.12.2. すでに実行中の CodeReady Workspaces インストール

前提条件

  • oc ツールが利用できる。
  • 最初に、証明書のインポートに使用される ConfigMap の名前を収集する必要があります。

    CodeReady Workspaces Operator でデプロイされた CodeReady Workspaces のインスタンスで、spec.server.ServerTrustStoreConfigMapName CheCluster Custom Resource プロパティーを読み込んで ConfigMap の名前を取得します。

    $ oc get checluster codeready-workspaces -n <crw-namespace-name> -o jsonpath={.spec.server.serverTrustStoreConfigMapName}
    注記

    既存のインストールで ConfigMap の名前を定義しなかった場合は、ca-certs を使用します。

手順

  1. インポートする必要のある証明書をローカルファイルシステムに保存します。

    注意
    • 証明書ファイルは、通常、.pem、. crt.ca-bundle などの Base64 ASCII ファイルとして保存されます。ただし、それらにはバイナリーエンコード (例: .cer ファイル) を使用することもできます。証明書ファイルを保持するすべてのシークレットでは、バイナリーでエンコードされる証明書ではなく、Base64 ASCII 証明書を使用する必要があります。
    • CodeReady Workspaces はすでに予約済みのファイル名を使用して証明書を ConfigMap に自動的に挿入するため、以下の予約済みのファイル名を使用して証明書を保存しないようにしてください。

      • ca-bundle.crt
      • ca.crt
  2. ConfigMap に必要な TLS 証明書を追加します。

    $ oc create configmap <config-map-name> --from-file=<certificate-file-path> -n=<crw-namespace-name> -o yaml --dry-run | oc apply -f -

    複数の証明書を適用するには、上記のコマンドに別の --from-file=<certificate-file-path> オプションを追加します。

  3. ConfigMap を使用するように CodeReady Workspaces インストールを設定します。

    CodeReady Workspaces Operator デプロイメントの場合:

    1. spec.server.ServerTrustStoreConfigMapName CheCluster カスタムリソースプロパティーを ConfigMap の名前に一致するように編集します。

      $ oc patch checluster codeready-workspaces -n <crw-namespace-name> --type=json -p '[{"op": "replace", "path": "/spec/server/serverTrustStoreConfigMapName", "value": "<config-map-name>"}]'
  4. CodeReady Workspaces Operator、CodeReady Workspaces サーバーおよび RH-SSO を再起動して、新規証明書を読み込みます。

    $ oc rollout restart -n <crw-namespace-name> deployment/codeready-workspaces-operator
    $ oc rollout restart -n <crw-namespace-name> deployment/codeready-workspaces/keycloak
    $ oc rollout restart -n <crw-namespace-name> deployment/codeready-workspaces
    注記

    CodeReady Workspaces コンポーネントの再起動は、CodeReady Workspaces 2.5.0 以降では必要ありません。

4.12.3. CodeReady Workspaces のインストールレベルでの検証

エラーなしで証明書を追加した場合、CodeReady Workspaces サーバーは起動し、https 経由で RH-SSO 設定を取得します。それ以外の場合には、検証すべき項目の一覧を以下に示します。

  • CodeReady Workspaces Operator のデプロイメントでは、CheCluster 属性 serverTrustStoreConfigMapName 値は ConfigMap の名前と一致します。以下のコマンドを使用して値を取得します。

    $ oc get -o json checluster/codeready-workspaces -n <crw-namespace-name> | jq .spec.server.serverTrustStoreConfigMapName
  • CodeReady Workspaces Pod ボリューム一覧には、ConfigMap をデータソースとして使用するボリュームが 1 つ含まれます。CodeReady Workspaces Pod のボリュームの一覧を取得するには、以下を実行します。

    $ oc get pod -o json <codeready-workspaces-pod-name> -n <crw-namespace-name> | jq .spec.volumes
  • CodeReady Workspaces は、証明書を CodeReady Workspaces サーバーコンテナーのフォルダー /public-certs/ にマウントします。このコマンドは、そのフォルダー内のファイルの一覧を返します。

    $ oc exec -t <codeready-workspaces-pod-name> -n <crw-namespace-name> -- ls /public-certs/
  • CodeReady Workspaces サーバーログに、設定された CodeReady Workspaces 証明書を含む、Java トラストストアに追加されたすべての証明書についての行があります。

    $ oc logs <codeready-workspaces-pod-name> -n <crw-namespace-name>
    (...)
    Found a custom cert. Adding it to java trust store based on /usr/lib/jvm/java-1.8.0/jre/lib/security/cacerts
    (...)
  • $CodeReady Workspaces サーバーの Java トラストストアに証明書が含まれる。証明書の SHA1 フィンガープリントは、以下のコマンドで返されるトラストストアに含まれる証明書の SHA1 の一覧にあります。

    $ oc exec -t <codeready-workspaces-pod-name> -n workspaces -- keytool -list -keystore /home/jboss/cacerts
    Your keystore contains 141 entries
    
    (...)

    ローカルファイルシステムの証明書の SHA1 ハッシュを取得するには、以下のコマンドを実行します。

    $ openssl x509 -in <certificate-file-path> -fingerprint -noout
    SHA1 Fingerprint=3F:DA:BF:E7:A7:A7:90:62:CA:CF:C7:55:0E:1D:7D:05:16:7D:45:60

4.12.4. ワークスペースレベルでの検証

  • ワークスペースを起動し、これが作成された OpenShift namespace を取得し、これが起動するのを待機します。
  • 以下のコマンドを使用してワークスペース Pod の名前を取得します。

    $ oc get pods -o=jsonpath='{.items[0].metadata.name}' -n <workspace namespace> | grep '^workspace.*'
  • 以下のコマンドを使用して、ワークスペース Pod の Theia IDE コンテナーの名前を取得します。

    $ oc get -o json pod <workspace pod name>  -n <workspace namespace> | \
        jq -r '.spec.containers[] | select(.name | startswith("theia-ide")).name'
  • ワークスペース namespace 内に作成されている必要がある ca-certs ConfigMap を検索します。

    $ oc get cm ca-certs <workspace namespace>
  • ca-certs 設定マップのエントリは、予約しているca-bundl.crtエントリに加えて、 CodeReady Workspaces のインストールレベルでの証明書のConfigMapに追加されたすべての追加のエントリが含まれていることを確認します。

    $ oc get cm ca-certs -n <workspace namespace> -o json | jq -r '.data | keys[]'
    ca-bundle.crt
    manually-added-certificate.crt
  • ca-certs ConfigMap がワークスペース Pod のボリュームとして追加されていることを確認します。

    $ oc get -o json pod <workspace pod name> -n <workspace namespace> | \
        jq '.spec.volumes[] | select(.configMap.name == "ca-certs")'
    {
      "configMap": {
        "defaultMode": 420,
        "name": "ca-certs"
      },
      "name": "che-self-signed-certs"
    }
  • ボリュームがコンテナー (とくに Theia IDE コンテナー) にマウントされていることを確認します。

    $ oc get -o json pod <workspace pod name> -n <workspace namespace> | \
       jq '.spec.containers[] | select(.name == "<theia ide container name>").volumeMounts[] | select(.name == "che-self-signed-certs")'
    {
      "mountPath": "/public-certs",
      "name": "che-self-signed-certs",
      "readOnly": true
    }
  • Theia IDE コンテナーの /public-certs フォルダーを検査し、その内容が ca-certs ConfigMap のエントリーの一覧と一致することを確認します。

    $ oc exec <workspace pod name> -c <theia ide container name> -n <workspace namespace> -- ls /public-certs
    ca-bundle.crt
    manually-added-certificate.crt

4.13. コンポーネント間の通信での外部方法と内部方法間の切り替え

Red Hat CodeReady Workspaces コンポーネント間の通信は、内部クラスターホスト名を使用します。以下の状況では、代わりに、コンポーネント間の通信で外部の OpenShift Route を使用します。

  • OpenShift インスタンスは複数の CodeReady Workspaces インスタンスを実行しています。
  • 環境は namespace 間の通信を制限します。

前提条件

  • oc ツールが利用できる。
  • {platform-name} で実行している CodeReady Workspaces のインスタンス。

手順

  1. コンポーネント間の通信で外部 OpenShift ルートを使用するには、以下を実行します。

    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/useInternalClusterSVCNames", "value": false}]'
  2. コンポーネント間の通信で内部クラスターホスト名を使用するには、以下を実行します。

    $ oc patch checluster codeready-workspaces -n workspaces --type=json -p \
    '[{"op": "replace", "path": "/spec/server/useInternalClusterSVCNames", "value": true}]'

4.14. Red Hat CodeReady Workspaces ログインページの RH-SSO codeready-workspaces-username-readonly テーマの設定

以下の手順は、OpenShift OAuth サービスが有効にされているすべての CodeReady Workspaces インスタンスに関連します。

事前に作成した namespace のユーザーが Red Hat CodeReady Workspaces ダッシュボードに初めてログインする際に、ユーザーがアカウント情報を更新できるページが表示されます。ユーザー名を変更することはできますが、OpenShift ユーザー名に一致しないユーザー名を選択すると、ユーザーのワークスペースは実行されません。これは、CodeReady Workspaces が存在しない namespace、ユーザーの OpenShift ユーザー名から派生する名前の使用を試行し、ワークスペースの作成を試行することによって生じます。これを防ぐには、以下の手順に従って RH-SSO 設定を変更します。

前提条件

  • OpenShift で実行される CodeReady Workspaces のインスタンス。
  • RH-SSO サービスにログインしている。

手順

ユーザー名を変更したら、Login Theme オプションを readonly に設定します。

  1. 左側のメイン Configure メニューで、Realm Settings を選択します。

    crw keycloak username readonly theme
  2. Themes タブに移動します。
  3. Login Theme フィールドで codeready-workspaces-username-readonly オプションを選択し、Save ボタンをクリックして変更を適用します。

第5章 CodeReady Workspaces のアップグレード

本章では、CodeReady Workspaces インスタンスをバージョン 2.4 から CodeReady Workspaces 2.5 にアップグレードする方法を説明します。

CodeReady Workspaces インスタンスのインストールするために使用する方法により、アップグレードする方法が決まります。

5.1. OperatorHub を使用した CodeReady Workspaces のアップグレード

このセクションでは、OpenShift Web コンソールの OperatorHub から Operator を使用して、以前のマイナーバージョンからアップグレードする方法を説明します。

前提条件

  • OpenShift インスタンスの管理者アカウント。
  • OpenShift の同じインスタンス上で OperatorHub の Operator を使用してインストールされた、以前のマイナーバージョンの CodeReady Workspaces のインスタンス。

手順

  1. OpenShift Web コンソールを開きます。
  2. Operators → Installed Operators セクションに移動します。
  3. インストールされた Operator の一覧で Red Hat CodeReady Workspaces をクリックします。
  4. Subscription タブに移動し、以下のオプションを有効にします。

    • Channel: latest
    • Approval:Automatic

検証手順

  1. CodeReady Workspaces インスタンスに移動します。
  2. 2.5 のバージョン番号がページ下部に表示されます。

5.2. CLI 管理ツールを使用した CodeReady Workspaces のアップグレード

本セクションでは、CLI 管理ツールを使用して以前のマイナーバージョンからアップグレードする方法を説明します。

前提条件

  • OpenShift インスタンスの管理者アカウント
  • 以前のマイナーバージョンの Red Hat CodeReady Workspaces の実行中のインスタンス。これは、OpenShift の同じインスタンスで CLI 管理ツールを使用して <workspaces> プロジェクトにインストールされています。
  • crwctl 2.5 バージョン管理ツールのインストール。「crwctl CLI 管理ツールのインストール」 を参照してください。

手順

  1. CodeReady Workspaces 2.4 インスタンスで実行されているすべてのワークスペースで、変更を保存し、Git リポジトリーに再度プッシュします。
  2. CodeReady Workspaces 2.4 インスタンスのすべてのワークスペースをシャットダウンします。
  3. 以下のコマンドを実行します。

    $ crwctl server:update -n <workspaces>
注記

低速なシステムまたはインターネット接続の場合は、--k8spodwaittimeout=1800000 フラグオプションを crwctl server:update コマンドに追加し、Pod のタイムアウト期間を 1800000 ms 以上に拡張します。

検証手順

  1. CodeReady Workspaces インスタンスに移動します。
  2. 2.5 のバージョン番号がページ下部に表示されます。

5.3. 制限された環境での CLI 管理ツールを使用した CodeReady Workspaces のアップグレード

本セクションでは、制限された環境で CLI 管理ツールを使用して Red Hat CodeReady Workspaces をアップグレードする方法を説明します。アップグレードパスは、CodeReady Workspaces バージョン 2.4 からバージョン 2.5 へのマイナーバージョンの更新をサポートします。

前提条件

5.3.1. 制限された環境でのネットワーク接続について

CodeReady Workspaces では、CodeReady Workspaces 用に作成された各 OpenShift Route が OpenShift クラスター内からアクセスできる必要があります。これらの CodeReady Workspaces コンポーネントには OpenShift Route(codeready-workspaces-server, keycloak, devfile-registry, plugin-registry)があります。

環境のネットワークトポロジーを考慮して、これを実行する最善の方法を判断してください。

例5.1 公開インターネットから切断された、会社または組織が所有するネットワーク

ネットワーク管理者は、クラスターからのトラフィックを OpenShift Route ホスト名にルーティングできるようにする必要があります。

例5.2 クラウドプロバイダーのプライベートサブネットワーク

トラフィックがノードから出て、外部に表示されるロードバランサーに到達できるようにするプロキシー設定を作成します。

5.3.2. プライベートレジストリーの準備

前提条件

  • oc ツールが利用できる。
  • skopeo ツール(バージョン 0.1.40 以降)が利用できる。
  • podman ツールが利用できる。
  • OpenShift クラスターからアクセスできるイメージ、および V2 イメージマニフェスト (スキーマバージョン 2) フォーマットのサポート。インターネットへのアクセスが一時的に可能な場所から、これにプッシュできることを確認します。

表5.1 サンプルで使用されるプレースホルダー

<source-image>

レジストリー、組織、およびダイジェストなどのソースイメージの詳細な組み合わせ (coordinate)。

<target-registry>

ターゲットコンテナーイメージレジストリーのホスト名およびポート。

<target-organization>

ターゲットのコンテナーイメージレジストリー内の組織

<target-image>

ターゲットのコンテナーイメージレジストリーのイメージ名とダイジェスト。

<target-user>

ターゲットのコンテナーイメージレジストリーのユーザー名。

<target-password>

ターゲットのコンテナーイメージレジストリーのユーザーパスワード。

手順

  1. 内部イメージレジストリーにログインします。

    $ podman login --username <user> --password <password> <target-registry>
    警告

    内部レジストリーへのプッシュを試行する際に x509: certificate signed by unknown authority などのエラーが発生した場合には、以下のいずれかの回避策を試してください。

    • OpenShift クラスターの証明書を /etc/containers/certs.d/<target-registry>に追加します。
    • /etc/containers/registries.conf にある Podman 設定ファイルに以下の行を追加して、レジストリーを非セキュアなレジストリーとして追加する。
    [registries.insecure]
    registries = ['<target-registry>']
  2. ダイジェストを変更せずにイメージをコピーします。以下の表のすべてのイメージに対して、この手順を繰り返します。

    $ skopeo copy --all docker://<source-image> docker://<target-registry>/<target-organization>/<target-image>
    注記

    表5.2 名前に含まれるプレフィックスまたはキーワードからの container-images の使用について

    使用プレフィックスまたはキーワード

    Essential

    stacks-, plugin- または -openj9- ではない

    Workspaces

    stacks-, plugin-

    IBM Z および IBM Power Systems

    -openj9-

    表5.3 プライベートレジストリーでコピーするイメージ

    <source-image><target-image>

    registry.redhat.io/codeready-workspaces/configbump-rhel8@sha256:30f61524365f0d36bbe1208df77dd5cbe75b3f9e5c979305566e46ccac139dac

    configbump-rhel8@sha256:30f61524365f0d36bbe1208df77dd5cbe75b3f9e5c979305566e46ccac139dac

    registry.redhat.io/codeready-workspaces/crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    registry.redhat.io/codeready-workspaces/crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    crw-2-rhel8-operator@sha256:df78dac12257c42910cc98e3cf7cafab628012c19b3e4104f85f0567346f45d9

    registry.redhat.io/codeready-workspaces/devfileregistry-rhel8@sha256:58e961fa91492fd13ccb2c39afb201431f187301a2a192ab683ee202c9fe8c55

    devfileregistry-rhel8@sha256:58e961fa91492fd13ccb2c39afb201431f187301a2a192ab683ee202c9fe8c55

    registry.redhat.io/codeready-workspaces/jwtproxy-rhel8@sha256:79783bfaedce74edcb9681baab0a33dd40268f721642c31ca5319b4b47219cb7

    jwtproxy-rhel8@sha256:79783bfaedce74edcb9681baab0a33dd40268f721642c31ca5319b4b47219cb7

    registry.redhat.io/codeready-workspaces/machineexec-rhel8@sha256:a493fcb94465bdbc2c61250a0cacd95b0b5bb46618e9b5fd49e5902341ed0fcd

    machineexec-rhel8@sha256:a493fcb94465bdbc2c61250a0cacd95b0b5bb46618e9b5fd49e5902341ed0fcd

    registry.redhat.io/codeready-workspaces/plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    registry.redhat.io/codeready-workspaces/plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    registry.redhat.io/codeready-workspaces/plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    plugin-java11-openj9-rhel8@sha256:d7facc17f95bcfc23b32487346c82d2e23e6efe4d595a1b782e94f54aa636bbc

    registry.redhat.io/codeready-workspaces/plugin-java11-rhel8@sha256:641e223f5efbc32bab3461aa000e3a50a5dcca063331322158d1c959129ffd99

    plugin-java11-rhel8@sha256:641e223f5efbc32bab3461aa000e3a50a5dcca063331322158d1c959129ffd99

    registry.redhat.io/codeready-workspaces/plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    registry.redhat.io/codeready-workspaces/plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    registry.redhat.io/codeready-workspaces/plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    plugin-java8-openj9-rhel8@sha256:1e84507ef957ed0ad8384cdb2e3d9bbca51db128c7289bcfbc9da505d715bd75

    registry.redhat.io/codeready-workspaces/plugin-java8-rhel8@sha256:5b2df65e7ec4676a43b763b431744790a89acd5c6d197316b694693b58c19770

    plugin-java8-rhel8@sha256:5b2df65e7ec4676a43b763b431744790a89acd5c6d197316b694693b58c19770

    registry.redhat.io/codeready-workspaces/plugin-kubernetes-rhel8@sha256:5821febf70c74ed560a372f990e9fab9baa47f659ef9450b7881072e3cb40399

    plugin-kubernetes-rhel8@sha256:5821febf70c74ed560a372f990e9fab9baa47f659ef9450b7881072e3cb40399

    registry.redhat.io/codeready-workspaces/plugin-openshift-rhel8@sha256:7772bc9073e64713ebbfc1a950cc3cbe21ed7301c65f84bb509fa2b6e71fa81d

    plugin-openshift-rhel8@sha256:7772bc9073e64713ebbfc1a950cc3cbe21ed7301c65f84bb509fa2b6e71fa81d

    registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8@sha256:dc191ef97b01d0afedab6ccdb8c303f32d046f7eccf9f452eb30e615f2a0bf0e

    pluginbroker-artifacts-rhel8@sha256:dc191ef97b01d0afedab6ccdb8c303f32d046f7eccf9f452eb30e615f2a0bf0e

    registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8@sha256:dbd839715c80db641c1505a0fa6f96969cf8cc4aa8c4db95b40626f95854a525

    pluginbroker-metadata-rhel8@sha256:dbd839715c80db641c1505a0fa6f96969cf8cc4aa8c4db95b40626f95854a525

    registry.redhat.io/codeready-workspaces/pluginregistry-rhel8@sha256:c9f48f247cff27280587aeff54cea5d8a27e0eb55c99a73726cd7d575db7fbcc

    pluginregistry-rhel8@sha256:c9f48f247cff27280587aeff54cea5d8a27e0eb55c99a73726cd7d575db7fbcc

    registry.redhat.io/codeready-workspaces/server-rhel8@sha256:feb6c83be2b1e6edc56287d2c9ed66a82522a297f88b495aeddd0778fb9d1f57

    server-rhel8@sha256:feb6c83be2b1e6edc56287d2c9ed66a82522a297f88b495aeddd0778fb9d1f57

    registry.redhat.io/codeready-workspaces/stacks-cpp-rhel8@sha256:4bc877635a0feae47d259a232cca84130dc1f36890f76e39f422024372830bcb

    stacks-cpp-rhel8@sha256:4bc877635a0feae47d259a232cca84130dc1f36890f76e39f422024372830bcb

    registry.redhat.io/codeready-workspaces/stacks-dotnet-rhel8@sha256:a61038e596c0c6104ae86cf4c5af5c60a6126feefa6e6585c540de2c48b723a2

    stacks-dotnet-rhel8@sha256:a61038e596c0c6104ae86cf4c5af5c60a6126feefa6e6585c540de2c48b723a2

    registry.redhat.io/codeready-workspaces/stacks-golang-rhel8@sha256:4ecb4f5fe6917a0e54cdaa8bb8332a06472debc8a12e8c948d7abbb6e90a95f0

    stacks-golang-rhel8@sha256:4ecb4f5fe6917a0e54cdaa8bb8332a06472debc8a12e8c948d7abbb6e90a95f0

    registry.redhat.io/codeready-workspaces/stacks-php-rhel8@sha256:d07364b8556e2f6689fa59fafefbaad3bb8c63b47e3e51be59521d38816a13db

    stacks-php-rhel8@sha256:d07364b8556e2f6689fa59fafefbaad3bb8c63b47e3e51be59521d38816a13db

    registry.redhat.io/codeready-workspaces/theia-endpoint-rhel8@sha256:bbd5b5fce80594d68a266128f607176a2f392829b969deafd848306d90c265e3

    theia-endpoint-rhel8@sha256:bbd5b5fce80594d68a266128f607176a2f392829b969deafd848306d90c265e3

    registry.redhat.io/codeready-workspaces/theia-rhel8@sha256:3713798c7f61c3863afd4f501806df2fe462d8e3be37ab9e572940bf7a6facc0

    theia-rhel8@sha256:3713798c7f61c3863afd4f501806df2fe462d8e3be37ab9e572940bf7a6facc0

    registry.redhat.io/codeready-workspaces/traefik-rhel8@sha256:c7ab18087c660f35386268053f29ebd2dc55163d2fd7956f0fdc227938b136ed

    traefik-rhel8@sha256:c7ab18087c660f35386268053f29ebd2dc55163d2fd7956f0fdc227938b136ed

    registry.redhat.io/jboss-eap-7/eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    registry.redhat.io/jboss-eap-7/eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    registry.redhat.io/jboss-eap-7/eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    eap-xp1-openj9-11-openshift-rhel8@sha256:42d7a7264314b9ef8399bda08ea61362887e4c1a88addb4c4f9f3b5d9d3169ce

    registry.redhat.io/jboss-eap-7/eap-xp1-openjdk11-openshift-rhel8@sha256:94e1cd4eb4196a358e301c1992663258c0016c80247f507fd1c39cf9a73da833

    eap-xp1-openjdk11-openshift-rhel8@sha256:94e1cd4eb4196a358e301c1992663258c0016c80247f507fd1c39cf9a73da833

    registry.redhat.io/jboss-eap-7/eap73-openjdk8-openshift-rhel7@sha256:24dea0cfc154a23c1aeb6b46ade182d0f981362f36b7e6fb9c7d8531ac639fe0

    eap73-openjdk8-openshift-rhel7@sha256:24dea0cfc154a23c1aeb6b46ade182d0f981362f36b7e6fb9c7d8531ac639fe0

    registry.redhat.io/rh-sso-7/sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    registry.redhat.io/rh-sso-7/sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    sso74-openj9-openshift-rhel8@sha256:9297414d1cad8f86871f240c1c0ae324f7d1a3285c22ac7dd878bfcf3c59a75f

    registry.redhat.io/rh-sso-7/sso74-openshift-rhel8@sha256:c0045cd676e06eb17083a44c4b90b29b11ddb40e1fb6a7b651384cf0960f5158

    sso74-openshift-rhel8@sha256:c0045cd676e06eb17083a44c4b90b29b11ddb40e1fb6a7b651384cf0960f5158

    registry.redhat.io/rhel8/postgresql-96@sha256:5b5bf623d89deda89250f422d352b122bce9533b902b5474f9c63a9facc7a6f1

    postgresql-96@sha256:5b5bf623d89deda89250f422d352b122bce9533b902b5474f9c63a9facc7a6f1

    registry.redhat.io/rhscl/mongodb-36-rhel7@sha256:9f799d356d7d2e442bde9d401b720600fd9059a3d8eefea6f3b2ffa721c0dc73

    mongodb-36-rhel7@sha256:9f799d356d7d2e442bde9d401b720600fd9059a3d8eefea6f3b2ffa721c0dc73

    registry.redhat.io/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187aadb32e89fd83fa455ebaa6

    ubi8ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187aadb32e89fd83fa455ebaa6

検証手順

  • イメージに同じダイジェストがあることを確認します。

    $ skopeo inspect docker://<source-image>
    $ skopeo inspect docker://<target-registry>/<target-organization>/<target-image>

関連資料

5.3.3. 制限された環境での CLI 管理ツールを使用した CodeReady Workspaces のアップグレード

本セクションでは、制限された環境で CLI 管理ツールを使用して Red Hat CodeReady Workspaces をアップグレードする方法を説明します。

前提条件

手順

  1. CodeReady Workspaces 2.4 インスタンスで実行されているすべてのワークスペースで、変更を保存し、Git リポジトリーに再度プッシュします。
  2. CodeReady Workspaces 2.4 インスタンスのすべてのワークスペースを停止します。
  3. 以下のコマンドを実行します。

    $ crwctl server:update --che-operator-image=<image-registry>/<organization>/crw-2-rhel8-operator:2.5 -n workspaces
    • <image-registry>: 制限された環境でアクセス可能なコンテナーイメージレジストリーのホスト名およびポート。
    • <organization>: container-image レジストリーの組織。「プライベートレジストリーの準備」 を参照してください。

検証手順

  1. CodeReady Workspaces インスタンスに移動します。
  2. 2.5 のバージョン番号がページ下部に表示されます。
注記

低速なシステムまたはインターネット接続の場合は、--k8spodwaittimeout=1800000 フラグオプションを crwctl server:update コマンドに追加し、Pod のタイムアウト期間を 1800000 ms 以上に拡張します。

第6章 CodeReady Workspaces のアンインストール

本セクションでは、Red Hat CodeReady Workspaces のアンインストール手順を説明します。アンインストールプロセスでは、CodeReady Workspaces 関連のユーザーデータが完全に削除されます。CodeReady Workspaces インスタンスをインストールするために以前に使用された方法により、アンインストール方法が決まります。

6.1. OpenShift Web コンソールを使用した OperatorHub のインストール後の CodeReady Workspaces のアンインストール

本セクションでは、OpenShift Administrator パースペクティブのメインメニューを使用して、クラスターから CodeReady Workspaces をアンインストールする方法を説明します。

前提条件

  • CodeReady Workspaces が OperatorHub を使用して OpenShift クラスターにインストールされている。

手順

  1. OpenShift Web コンソールに移動し、Administrator パースペクティブを選択します。
  2. Home > Projects セクションで、CodeReady Workspaces インスタンスが含まれるプロジェクトに移動します。

    注記

    デフォルトのプロジェクト名は <workspaces> です。

  3. Operators > Installed Operators セクションで、インストールされた Operator の一覧で Red Hat CodeReady Workspaces をクリックします。
  4. Red Hat CodeReady Workspaces Cluster タブで、表示された Red Hat CodeReady Workspaces Cluster をクリックし、右上の Actions ドロップダウンメニューで Delete cluster オプションを選択します。

    注記

    デフォルトの Red Hat CodeReady Workspaces クラスター名は <red-hat-codeready-workspaces> です。

  5. Operators > Installed Operators セクションの、インストールされた Operator 一覧で Red Hat CodeReady Workspaces をクリックし、右上の Actions ドロップダウンメニューで Uninstall Operator オプションを選択します。
  6. Home > Projects セクションで、CodeReady Workspaces インスタンスが含まれるプロジェクトに移動し、右上の Actions ドロップダウンメニューで Delete Project オプションを選択します。

6.2. OpenShift CLI を使用した OperatorHub のインストール後の CodeReady Workspaces のアンインストール

本セクションでは、oc コマンドを使用して、CodeReady Workspaces インスタンスをアンインストールする方法を説明します。

前提条件

  • CodeReady Workspaces が OperatorHub を使用して OpenShift クラスターにインストールされている。
  • oc ツールが利用できる。

手順

以下の手順では、コマンドラインの出力を例として示します。ユーザーの端末の出力は異なる場合があることに注意してください。

クラスターから CodeReady Workspaces インスタンスをアンインストールするには、以下を実行します。

  1. クラスターにサインインします。

    $ oc login -u <username> -p <password> <cluster_URL>
  2. CodeReady Workspaces インスタンスがデプロイされているプロジェクトに切り替えます。

    $ oc project <codeready-workspaces_project>
  3. CodeReady Workspaces クラスター名を取得します。以下は、red-hat-codeready-workspaces という名前のクラスターを示しています。

    $ oc get checluster
    NAME          AGE
    red-hat-codeready-workspaces   27m
  4. CodeReady Workspaces クラスターを削除します。

    $ oc delete checluster red-hat-codeready-workspaces
    checluster.org.eclipse.che "red-hat-codeready-workspaces" deleted
  5. CodeReady Workspaces クラスターサービスバージョン (CSV) モジュールの名前を取得します。以下は、red-hat-codeready-workspaces.v2.5 という名前の CSV モジュールを検出します。

    $ oc get csv
    NAME                 DISPLAY       VERSION   REPLACES             PHASE
    red-hat-codeready-workspaces.v2.5   Red Hat CodeReady Workspaces   2.5     red-hat-codeready-workspaces.v2.4   Succeeded
  6. CodeReady Workspaces CSV を削除します。

    $ oc delete csv red-hat-codeready-workspaces.v2.5
    clusterserviceversion.operators.coreos.com "red-hat-codeready-workspaces.v2.5" deleted

6.3. crwctl インストール後の CodeReady Workspaces のアンインストール

本セクションでは、crwctl ツールを使用してインストールされた Red Hat CodeReady Workspaces のインスタンスをアンインストールする方法を説明します。

前提条件

  • crwctl ツールが利用できる。
  • oc ツールが利用できる。
  • crwctl ツールは OpenShift の CodeReady Workspaces インスタンスにインストールされている。

手順

  1. OpenShift クラスターにサインインします。

    $ oc login -u <username> -p <password> <cluster_URL>
  2. 削除する CodeReady Workspaces namespace の名前をエクスポートします。

    $ export codereadyNamespace=<codeready-namespace-to-remove>
  3. ユーザーのアクセストークンおよび Keycloak URL をエクスポートします。

    $ export KEYCLOAK_BASE_URL="http://${KEYCLOAK_URL}/auth"
    $ export USER_ACCESS_TOKEN=$(curl -X POST $KEYCLOAK_BASE_URL/realms/codeready/protocol/openid-connect/token \
                           -H "Content-Type: application/x-www-form-urlencoded" \
                           -d "username=admin" \
                           -d "password=admin" \
                           -d "grant_type=password" \
                           -d "client_id=codeready-public" | jq -r .access_token)
  4. UAT を使用してサーバーを停止します。

    $ crwctl/bin/crwctl server:stop -n ${codereadyNamespace} --access-token=$USER_ACCESS_TOKEN
  5. プロジェクトおよび CodeReady Workspaces デプロイメントを削除します。

    $ oc project ${codereadyNamespace}
    $ oc delete deployment codeready-operator
    $ oc delete checluster codeready-workspaces
    $ oc delete project ${codereadyNamespace}
  6. プロジェクトについての情報を一覧表示して、削除が正常に実行されていることを確認します。

    $ oc describe project ${codereadyNamespace}
  7. 指定した ClusterRoleBinding を削除します。

    $ oc delete clusterrolebinding codeready-operator