管理ガイド


Red Hat CodeReady Workspaces 2.3

Red Hat CodeReady Workspaces の管理

Robert Kratky

Michal Maléř

fabrice Flore-Thébault

Red Hat Developer Group Documentation Team

概要

Red Hat CodeReady Workspaces を実行している管理者の情報。

第1章 devfile およびプラグインレジストリーのカスタマイズ

CodeReady Workspaces 2.3 には、プラグインレジストリーと devfile レジストリーの 2 つのレジストリーが導入されています。CodeReady Workspaces プラグインおよび CodeReady Workspaces devfiles のメタデータが公開される静的な Web サイトです。

プラグインレジストリーは、CodeReady Workspaces の同じインスタンスの全ユーザーにプラグイン定義を共有できるようにします。レジストリーで公開されるプラグインのみが devfile で使用できます。

devfile レジストリーは、CodeReady Workspaces スタックの定義を保持します。これらは、Create Workspace を 選択する際に CodeReady Workspaces ユーザーダッシュボードで利用できます。これには、サンプルプロジェクトを含む CodeReady Workspaces の技術スタックサンプルの一覧が含まれます。

devfile およびプラグインレジストリーは 2 つの個別の Pod で実行され、CodeReady Workspaces サーバーがデプロイされる際にデプロイされます(CodeReady Workspaces Operator のデフォルト動作です)。プラグインおよび devfile のメタデータは GitHub でバージョン化され、CodeReady Workspaces サーバーのライフサイクルに従います。

本書では、CodeReady Workspaces(プラグインまたは devfile メタデータを変更する)でデプロイされるデフォルトのレジストリーをカスタマイズする以下の 2 つの方法を説明します。

1.1. カスタムレジストリーイメージのビルドおよび実行

本セクションでは、レジストリーのビルドおよび実行中の CodeReady Workspaces サーバーを更新してレジストリーを参照する方法を説明します。

1.1.1. カスタム devfile レジストリーのビルド

本セクションでは、カスタム devfile レジストリーを構築する方法を説明します。以下の操作について説明します。

  • devfile レジストリーを構築するのに必要なソースコードのコピーを取得します。
  • 新しい devfile の追加。
  • devfile レジストリーをビルドします。

手順

  1. devfile レジストリーリポジトリーのクローンを作成します。

    $ git clone git@github.com:redhat-developer/codeready-workspaces.git
    $ cd codeready-workspaces/dependencies/che-devfile-registry
    Copy to Clipboard Toggle word wrap
  2. . /che-devfile-registry/devfiles/ ディレクトリーにサブディレクトリー <devfile-name>/ を作成し、devfile.yaml ファイルおよび meta.yaml ファイルを追加します。

    devfile のファイル組織

    ./che-devfile-registry/devfiles/
    └── <devfile-name>
        ├── devfile.yaml
        └── meta.yaml
    Copy to Clipboard Toggle word wrap

  3. devfile.yaml ファイルに有効なコンテンツを追加します。devfile 形式の詳細な説明は、「 Devfile を使用したワークスペースポータブルの使用」を 参照してください。
  4. meta.yaml ファイルが以下の構造に準拠していることを確認します。

    Expand
    表1.1 devfile meta.yamlのパラメーター
    attributedescription

    description

    ユーザーダッシュボードに表示される説明。

    displayName

    ユーザーダッシュボードに表示される名前。

    globalMemoryLimit

    devfile によって起動されるすべてのコンポーネントが使用する予想されるメモリーの合計。この数は、ユーザーダッシュボードに表示されます。これは通知され、CodeReady Workspaces サーバーによって考慮されません。

    icon

    ユーザーダッシュボードに表示される .svg ファイルへのリンク

    tags

    タグの一覧。タグには、通常スタックに含まれるツールが含まれます。

    devfile meta.yamlの例

    displayName: Rust
    description: Rust Stack with Rust 1.39
    tags: ["Rust"]
    icon: https://www.eclipse.org/che/images/logo-eclipseche.svg
    globalMemoryLimit: 1686Mi
    Copy to Clipboard Toggle word wrap

  5. カスタム devfile レジストリーのコンテナーをビルドします。

    $ docker build -t my-devfile-registry .
    Copy to Clipboard Toggle word wrap

1.1.2. カスタムプラグインレジストリーのビルド

このセクションでは、カスタムプラグインレジストリーを構築する方法を説明します。以下の操作について説明します。

  • カスタムプラグインレジストリーのビルドに必要なソースコードのコピーを取得します。
  • 新しいプラグインの追加。
  • カスタムプラグインレジストリーをビルドします。

手順

  1. プラグインレジストリーリポジトリーのクローンを作成します。

    $ git clone git@github.com:redhat-developer/codeready-workspaces.git
    $ cd codeready-workspaces/dependencies/che-plugin-registry
    Copy to Clipboard Toggle word wrap
  2. . /che-plugin-registry/v3/plugins/ ディレクトリーに新しいディレクトリー <publisher> /<plugin-name> /<plugin-version>/ および meta.yaml ファイルを最後のディレクトリーに作成します。

    プラグインのファイル組織

    ./che-plugin-registry/v3/plugins/
    ├── <publisher>
    │   └── <plugin-name>
    │       ├── <plugin-version>
    │       │   └── meta.yaml
    │       └── latest.txt
    Copy to Clipboard Toggle word wrap

  3. meta.yaml ファイルに有効なコンテンツを追加します。meta.yaml ファイル形式の詳細は、「Using a Visual Studio Code extension in CodeReady Workspaces」セクションまたは eclipse/che-plugin-registry リポジトリーの README. md ファイルを参照してください。
  4. 最新の <plugin-version> ディレクトリーの名前を含む latest.txt という名前のファイルを作成します。

    $ tree che-plugin-registry/v3/plugins/redhat/java/
    che-plugin-registry/v3/plugins/redhat/java/
    ├── 0.38.0
    │   └── meta.yaml
    ├── 0.43.0
    │   └── meta.yaml
    ├── 0.45.0
    │   └── meta.yaml
    ├── 0.46.0
    │   └── meta.yaml
    ├── 0.50.0
    │   └── meta.yaml
    └── latest.txt
    $ cat che-plugin-registry/v3/plugins/redhat/java/latest.txt
    0.50.0
    Copy to Clipboard Toggle word wrap
  5. カスタムプラグインレジストリーのコンテナーをビルドします。

    ./build.sh
    Copy to Clipboard Toggle word wrap

1.1.3. レジストリーのデプロイ

前提条件

このセクションで使用される my-plug-in -registry イメージおよび my-devfile-registry イメージは、docker コマンドを使用してビルドされます。このセクションでは、CodeReady Workspaces がデプロイされている OpenShift クラスターにこれらのイメージが利用可能であることを前提としています。

たとえば、docker ビルドコマンド を実行する前には true の場合、ユーザーは eval $\{minikube docker-env} コマンドを実行します(または、Minishift の場合は eval $\{minishift docker-env} コマンド)。

それ以外の場合は、これらのイメージをコンテナーレジストリー( quay.io、DockerHub、プライベートレジストリーなど)にプッシュできます。

1.1.3.1. OpenShift でのレジストリーのデプロイ

手順

プラグインレジストリーをデプロイする OpenShift テンプレートは、GitHub リポジトリーの openshift/ ディレクトリーにあります。

  1. OpenShift テンプレートを使用してプラグインレジストリーをデプロイするには、以下のコマンドを実行します。

    NAMESPACE=<namespace-name>  
    1
    
    IMAGE_NAME="my-plug-in-registry"
    IMAGE_TAG="latest"
    oc new-app -f openshift/che-plugin-registry.yml \
     -n "$\{NAMESPACE}" \
     -p IMAGE="$\{IMAGE_NAME}" \
     -p IMAGE_TAG="$\{IMAGE_TAG}" \
     -p PULL_POLICY="IfNotPresent"
    Copy to Clipboard Toggle word wrap
    1
    crwctl を使用してインストールした場合、デフォルトの CodeReady Workspaces プロジェクトは ワークスペース になります。OperatorHub のインストール方法では、CodeReady Workspaces をユーザー現在のプロジェクトにデプロイします。
  2. devfile レジストリーには、GitHub リポジトリーの deploy/openshift/ ディレクトリーに OpenShift テンプレートがあります。デプロイするには、以下のコマンドを実行します。

    NAMESPACE=<namespace-name>  
    1
    
    IMAGE_NAME="my-devfile-registry"
    IMAGE_TAG="latest"
    oc new-app -f openshift/che-devfile-registry.yml \
     -n "$\{NAMESPACE}" \
     -p IMAGE="$\{IMAGE_NAME}" \
     -p IMAGE_TAG="$\{IMAGE_TAG}" \
     -p PULL_POLICY="IfNotPresent"
    Copy to Clipboard Toggle word wrap
    1
    crwctl を使用してインストールした場合、デフォルトの CodeReady Workspaces プロジェクトは ワークスペース になります。OperatorHub のインストール方法では、CodeReady Workspaces をユーザー現在のプロジェクトにデプロイします。
  3. レジストリーが OpenShift に正常にデプロイされているかどうかを確認します。

    1. 新規プラグインがプラグインレジストリーに正しく公開されていることを確認するには、レジストリーパス /v3/plugins/index.json に対して要求を行います(または devfile レジストリーの /devfiles/index.json )。

      $ URL=$(oc get -o 'custom-columns=URL:.spec.rules[0].host' \
        -l app=che-plugin-registry route --no-headers)
      $ INDEX_JSON=$(curl -sSL http://${URL}/v3/plugins/index.json)
      $ echo ${INDEX_JSON} | grep -A 4 -B 5 "\"name\":\"my-plug-in\""
      ,\{
       "id": "my-org/my-plug-in/1.0.0",
       "displayName":"This is my first plug-in for CodeReady Workspaces",
       "version":"1.0.0",
       "type":"VS Code extension",
       "name":"my-plug-in",
       "description":"This plugin shows that we are able to add plugins to the registry",
       "publisher":"my-org",
       "links": \{"self":"/v3/plugins/my-org/my-plug-in/1.0.0" }
      }
      --
      --
      ,\{
       "id": "my-org/my-plug-in/latest",
       "displayName":"This is my first plug-in for CodeReady Workspaces",
       "version":"latest",
       "type":"VS Code extension",
       "name":"my-plug-in",
       "description":"This plugin shows that we are able to add plugins to the registry",
       "publisher":"my-org",
       "links": \{"self":"/v3/plugins/my-org/my-plug-in/latest" }
      }
      Copy to Clipboard Toggle word wrap
    2. CodeReady Workspaces サーバーがレジストリーの URL を参照することを確認します。これには、コード対応 ConfigMap (または devfile レジストリーの CHE _WORKSPACE__REGISTRY__URL)で CHE _WORKSPACE_PLUGIN __REGISTRY__URL パラメーターを比較します。

      $ oc get \
        -o "custom-columns=URL:.data['CHE_WORKSPACE_PLUGINREGISTRYURL']" \
        --no-headers cm/che
      URL
      http://che-plugin-registry-che.192.168.99.100.mycluster.mycompany.com/v3
      Copy to Clipboard Toggle word wrap

      ルートの URL で以下を行います。

      $ oc get -o 'custom-columns=URL:.spec.rules[0].host' \
        -l app=che-plugin-registry route --no-headers
      che-plugin-registry-che.192.168.99.100.mycluster.mycompany.com
      Copy to Clipboard Toggle word wrap
    3. 一致しない場合は、ConfigMap を更新し、CodeReady Workspaces サーバーを再起動します。

      $ oc edit cm/che
      (...)
      $ oc scale --replicas=0 deployment/che
      $ oc scale --replicas=1 deployment/che
      Copy to Clipboard Toggle word wrap

新しいレジストリーをデプロイし、CodeReady Workspaces サーバーがそれらのレジストリーを使用するように設定すると、新しいプラグインがワークスペース プラグインビューで利用でき、新しいスタックはユーザーダッシュボードの New Workspace タブに表示されます。

1.2. レジストリーイメージへのプラグインバイナリーの追加

CodeReady Workspaces のプラグインレジストリーは Eclipse Che バージョンとは異なります。Eclipse Che はプラグインメタデータのみをホストしますが、CodeReady Workspaces プラグインレジストリーも対応するバイナリーをホストし、デフォルトではオフラインモードで構築されます。これは、バイナリーがプラグインレジストリーイメージですでにホストされていることを意味します。

本セクションでは、新規プラグインを追加するか、または別のバージョンのプラグインを参照する方法を説明します。これは、プラグインの meta.yaml ファイルを変更して、新規プラグインを参照するように修正し、オフラインモードで新しいレジストリーを構築します。これには、変更されたプラグインメタ .yaml ファイルとプラグインバイナリーファイルが含まれます。

前提条件

  • CodeReady Workspaces のインスタンスが利用できます。
  • oc ツールが利用可能である。

手順

  1. codeready-workspaces リポジトリーのクローン

    $ git clone https://github.com/redhat-developer/codeready-workspaces
    $ cd codeready-workspaces/dependencies/che-plugin-registry
    Copy to Clipboard Toggle word wrap
  2. プラグインレジストリーで変更するバイナリーの特定

    meta.yaml ファイルには、プラグインに必要な拡張の URL を定義する extension セクションが含まれます。たとえば、redhat/java11/0.63.0 プラグインは以下の 2 つの拡張機能を一覧表示します。

    meta.yaml

    extensions:
      - https://download.jboss.org/jbosstools/vscode/3rdparty/vscode-java-debug/vscode-java-debug-0.26.0.vsix
      - https://download.jboss.org/jbosstools/static/jdt.ls/stable/java-0.63.0-2222.vsix
    Copy to Clipboard Toggle word wrap

    最初のエクステンションを変更して、GitHub でホストされるバージョンを参照し、プラグインレジストリーを再構築します。redhat/java11/0.63.0 プラグ インを使用する場合、バイナリーはカスタムプラグインサーバーから取得されます。後続のコマンドに役立つには、以下の環境変数を設定します。

    ORG=redhat
    NAME=java11
    CHE_PLUGIN_VERSION=0.63.0
    VSCODE_JAVA_DEBUG_VERSION=0.26.0
    VSCODE_JAVA_DEBUG_URL="https://github.com/microsoft/vscode-java-debug/releases/download/0.26.0/vscjava.vscode-java-debug-0.26.0.vsix"
    OLD_JAVA_DEBUG_META_YAML_URL="https://download.jboss.org/jbosstools/vscode/3rdparty/vscode-java-debug/vscode-java-debug-0.26.0.vsix"
    Copy to Clipboard Toggle word wrap
  3. プラグインレジストリーの URL を取得します。

    $ oc get route plugin-registry -o jsonpath='{.spec.host}' -n ${CHE_NAMESPACE}
    Copy to Clipboard Toggle word wrap

    この値を PLUGIN_REGISTRY_URL という変数に保存します。

  4. meta.yaml ファイルの URL を更新して、レジストリーコンテナーに保存される VS コード拡張バイナリーを参照します。

    $ sed -i -e "s#${OLD_JAVA_DEBUG_META_YAML_URL}#${VSCODE_JAVA_DEBUG_URL}#g" \
      ./v3/plugins/${ORG}/${NAME}/${CHE_PLUGIN_VERSION}/meta.yaml
      ./v3/plugins/${ORG}/${NAME}/${CHE_PLUGIN_VERSION}/meta.yaml
    Copy to Clipboard Toggle word wrap
    重要

    デフォルトでは、CodeReady Workspaces は TLS を有効にしてデプロイされます。TLS を使用しないインストールの場合は、NEW_JAVA_ DEBUG_URL 変数および NEW_JAVA_LS_URL 変数で http:// を使用します。

  5. meta.yaml に正しく置換された URL があることを確認します。

    $ cat ./v3/plugins/${ORG}/${NAME}/${CHE_PLUGIN_VERSION}/meta.yaml
    Copy to Clipboard Toggle word wrap

    meta.yaml

    extensions:
      - https://plugin-registry-che.apps-crc.testing/v3/plugins/redhat/java11/0.63.0/vscode-java-debug-0.26.0.vsix
      - https://plugin-registry-che.apps-crc.testing/v3/plugins/redhat/java11/0.63.0/java-0.63.0-2222.vsix
    Copy to Clipboard Toggle word wrap

  6. カスタムレジストリーイメージ」セクションの手順を使用して、プラグインレジストリーをビルドおよびデプロイし ます。

1.3. ランタイム時の devfile およびプラグインの編集

カスタムレジストリーイメージのビルドの代替方法は、以下のとおりです。

  1. レジストリーの起動
  2. ランタイム時のコンテンツの変更

このアプローチは簡単かつ高速です。ただし、コンテナーが削除されるとすぐに変更が失われます。

1.3.1. ランタイム時のプラグインの追加

手順

プラグインを追加するには、以下を行います。

  1. プラグインレジストリーソースをチェックアウトします。

    $ git clone https://github.com/redhat-developer/codeready-workspaces; \
      cd codeready-workspaces/dependencies/che-plugin-registry
    Copy to Clipboard Toggle word wrap
  2. 一部のローカルフォルダーに meta.yaml を作成します。これは、ゼロまたは既存のプラグインの meta.yaml ファイルからコピーして実行できます。

    $ PLUGIN="v3/plugins/new-org/new-plugin/0.0.1"; \
      mkdir -p ${PLUGIN}; cp v3/plugins/che-incubator/cpptools/0.1/* ${PLUGIN}/
      echo "${PLUGIN##*/}" > ${PLUGIN}/../latest.txt
    Copy to Clipboard Toggle word wrap
  3. 既存のプラグインからコピーした場合には、必要に応じて meta.yaml ファイルに変更を加えます。新しいプラグインに固有の タイトル、表示名、および 説明 があることを確認します。firstPublicationDate を 現在 の日付に更新します。
  4. meta.yaml のこれらのフィールドは、上記の PLUGIN で定義されたパスと一致する必要があります。

    publisher: new-org
    name: new-plugin
    version: 0.0.1
    Copy to Clipboard Toggle word wrap
  5. プラグインレジストリーコンテナーをホストする Pod の名前を取得します。これを実行するには、component=plugin-registry ラベルをフィルターします。

    $ PLUGIN_REG_POD=$(oc get -o custom-columns=NAME:.metadata.name \
      --no-headers pod -l component=plugin-registry)
    Copy to Clipboard Toggle word wrap
  6. レジストリーの index.json ファイルを再生成し、新しいプラグインを追加します。

    $ cd codeready-workspaces/dependencies/che-plugin-registry; \
        "$(pwd)/build/scripts/generate_latest_metas.sh" v3 && \
        "$(pwd)/build/scripts/check_plugins_location.sh" v3 && \
        "$(pwd)/build/scripts/set_plugin_dates.sh" v3 && \
        "$(pwd)/build/scripts/check_plugins_viewer_mandatory_fields.sh" v3 && \
        "$(pwd)/build/scripts/index.sh" v3 > v3/plugins/index.json
    Copy to Clipboard Toggle word wrap
  7. 新しい index.json および meta.yaml ファイルを新しいローカルプラグインフォルダーからコンテナーにコピーします。

    $ cd codeready-workspaces/dependencies/che-plugin-registry; \
      LOCAL_FILES="$(pwd)/${PLUGIN}/meta.yaml $(pwd)/v3/plugins/index.json"; \
      oc exec ${PLUGIN_REG_POD} -i -t -- mkdir -p /var/www/html/${PLUGIN}; \
      for f in $LOCAL_FILES; do e=${f/$(pwd)\//}; echo "Upload ${f} -> /var/www/html/${e}"; \
        oc cp "${f}" ${PLUGIN_REG_POD}:/var/www/html/${e}; done
    Copy to Clipboard Toggle word wrap
  8. プラグインレジストリーの既存の CodeReady Workspaces インスタンスから新しいプラグインを使用できるようになりました。これを検出するには、CodeReady Workspaces ダッシュボードに移動し、Workspaces リンクをクリックします。ここから、歯車アイコンをクリックしてワークスペースの 1 つを設定します。Plugins タブを選択し、利用可能なプラグインの更新一覧を表示します。

1.3.2. ランタイム時の devfile の追加

手順

devfile を追加するには、以下を実行します。

  1. devfile レジストリーソースをチェックアウトします。

    $ git clone https://github.com/redhat-developer/codeready-workspaces; \
      cd codeready-workspaces/dependencies/che-devfile-registry
    Copy to Clipboard Toggle word wrap
  2. 一部のローカルフォルダーに devfile.yaml および meta.yaml を作成します。これは、ゼロまたは既存の devfile からコピーして実行できます。

    $ STACK="new-stack"; \
      mkdir -p devfiles/${STACK}; cp devfiles/03_web-nodejs-simple/* devfiles/${STACK}/
    Copy to Clipboard Toggle word wrap
  3. 既存の devfile からコピーする場合は、必要に応じて devfile に変更を加えます。新しい devfile に固有の displayNamedescription があることを確認します。
  4. devfile レジストリーコンテナーをホストする Pod の名前を取得します。これを実行するには、component=devfile-registry ラベルをフィルターします。

    $ DEVFILE_REG_POD=$(oc get -o custom-columns=NAME:.metadata.name \
      --no-headers pod -l component=devfile-registry)
    Copy to Clipboard Toggle word wrap
  5. レジストリーの index.json ファイルを再生成し、新しい devfile を追加します。

    $ cd codeready-workspaces/dependencies/che-devfile-registry; \
      "$(pwd)/build/scripts/check_mandatory_fields.sh" devfiles; \
      "$(pwd)/build/scripts/index.sh" > index.json
    Copy to Clipboard Toggle word wrap
  6. 新しい index.json、devfile. yaml、および meta.yaml ファイルを新しいローカル devfile フォルダーからコンテナーにコピーします。

    $ cd codeready-workspaces/dependencies/che-devfile-registry; \
      LOCAL_FILES="$(pwd)/${STACK}/meta.yaml $(pwd)/${STACK}/devfile.yaml $(pwd)/index.json"; \
      oc exec ${DEVFILE_REG_POD} -i -t -- mkdir -p /var/www/html/devfiles/${STACK}; \
      for f in $LOCAL_FILES; do e=${f/$(pwd)\//}; echo "Upload ${f} -> /var/www/html/devfiles/${e}"
        oc cp "${f}" ${DEVFILE_REG_POD}:/var/www/html/devfiles/${e}; done
    Copy to Clipboard Toggle word wrap
  7. devfile レジストリーの既存の CodeReady Workspaces インスタンスから、新しい devfile を使用できるようになりました。これを検出するには、CodeReady Workspaces ダッシュボードに移動し、Workspaces リンクをクリックします。そこから Add Workspace をクリックし、利用可能な devfile の更新一覧を表示します。

1.4. CodeReady Workspaces での Visual Studio コードエクステンションの使用

Red Hat CodeReady Workspaces 2.3 以降、Visual Studio Code(VS Code)拡張をインストールし、CodeReady Workspaces ワークスペースの機能を拡張することができます。vs Code 拡張機能は Che-Theia エディターコンテナーで実行することも、前提条件で独自の分離済みで事前設定されたコンテナーでパッケージ化することもできます。

本ガイドでは以下について説明します。

  • CodeReady Workspaces with workspaces で VS コードエクステンションを使用します。
  • CodeReady Workspaces プラグインパネル
  • CodeReady Workspaces プラグインレジストリーで VS コードエクステンションを公開する方法(他の CodeReady Workspaces ユーザーとエクステンションを共有する場合)。

    • extension-hosting サイドカーコンテナーおよび devfile でエクステンションの使用は任意です。
    • 特定の API がサポートされているか、実装されていないかを示すために VS Code 拡張機能との互換性を確認する方法

1.4.1. VS コードエクステンションの CodeReady Workspaces プラグインレジストリーへの公開

CodeReady Workspaces のユーザーはワークスペースの devfile を使用して、任意のプラグイン(Visual Studio Code(VS Code)拡張としても知られる)を使用できます。このプラグインはプラグインレジストリーに追加でき、ワークスペースのインストールにアクセスできる同じ組織のユーザーが簡単に再利用できます。

一部のプラグインには、コードコンパイルにランタイム専用コンテナーが必要です。そのため、これらのプラグインはランタイムサイドカーコンテナーと VS コード拡張の組み合わせになります。

以下のセクションでは、プラグイン設定の移植性を説明し、プラグインが必要なランタイムコンテナーにエクステンションを関連付けます。

1.4.1.1. meta.yaml ファイルの作成およびプラグインレジストリーへの追加

Red Hat CodeReady Workspaces プラグインレジストリーで VS Code 拡張を公開するには、プラグインのメタデータが必要です。このメタ情報は meta.yaml ファイルとして提供されます。本セクションでは、エクステンションの meta.yaml ファイルを作成する方法を説明します。

手順

  1. 以下のプラグインレジストリーディレクトリーに meta.yaml ファイルを作成します。<apiVersion> /plugins/ <publisher>/<plug-inName>/<plug-inVersion>/
  2. meta.yaml ファイルを編集し、必要な情報を提供します。設定ファイルは、以下の構造に従う必要があります。

    apiVersion: v2                                                   
    1
    
    publisher: myorg                                                 
    2
    
    name: my-vscode-ext                                              
    3
    
    version: 1.7.2                                                   
    4
    
    type: value                                                      
    5
    
    displayName:                                                     
    6
    
    title:                                                           
    7
    
    description:                                                     
    8
    
    icon: https://www.eclipse.org/che/images/logo-eclipseche.svg     
    9
    
    repository:                                                     
    10
    
    category:                                                       
    11
    
    spec:
      containers:                                                   
    12
    
        - image:                                                    
    13
    
          memoryLimit:                                              
    14
    
          memoryRequest:                                            
    15
    
          cpuLimit:                                                 
    16
    
          cpuRequest:                                               
    17
    
      extensions:                                                   
    18
    
              - https://github.com/redhat-developer/vscode-yaml/releases/download/0.4.0/redhat.vscode-yaml-0.4.0.vsix
              - https://github.com/SonarSource/sonarlint-vscode/releases/download/1.16.0/sonarlint-vscode-1.16.0.vsix
    Copy to Clipboard Toggle word wrap
    1
    ファイル構造のバージョン。
    2
    プラグインパブリッシャーの名前。パスのパブリッシャーと同じである必要があります。
    3
    プラグインの名前。path と同じである必要があります。
    4
    プラグインのバージョン。path と同じである必要があります。
    5
    プラグインのタイプ。使用できる値は Che PluginChe Editor、Theia プラグイン、 VS Code 拡張 です。
    6
    プラグインの短縮名。
    7
    プラグインのタイトル。
    8
    プラグインの簡単な説明と、そのプラグインの動作。
    9
    プラグインロゴへのリンク。
    10
    オプション。プラグインのソースコードリポジトリーへのリンク。
    11
    このプラグインが属するカテゴリーを定義します。EditorDebuggerFormatterLanguage、Linter、Snippet、Theme、または Other のいずれ にする必要があります。
    12
    このセクションを省略すると、VS Code 拡張が Che-Theia IDE コンテナーに追加されます。
    13
    サイドカーコンテナーを起動する Docker イメージ。例: eclipse/che-theia-endpoint-runtime:next
    14
    サイドカーコンテナーで利用可能な最大 RAM。例: "512Mi"この値は、コンポーネント設定のユーザーが上書きされる可能性があります。
    15
    デフォルトでサイドカーコンテナー用に提供される RAM。たとえば、「256Mi」です。この値は、コンポーネント設定のユーザーが上書きされる可能性があります。
    16
    サイドカーコンテナーで利用可能なコアまたはミリコアの最大 CPU 容量(「m」で拡張)。例: "500m", "2"この値は、コンポーネント設定のユーザーが上書きされる可能性があります。
    17
    コアまたはミリコアの CPU 容量(「m」で拡張)。これは、デフォルトでサイドカーコンテナー用に提供されます。たとえば、「125m」です。この値は、コンポーネント設定のユーザーが上書きされる可能性があります。
    18
    このサイドカーコンテナーで実行される VS コードエクステンションの一覧。

1.4.2. プラグインレジストリー VS コードエクステンションのワークスペースへの追加

必要な VS Code 拡張が CodeReady Workspaces プラグインレジストリーに追加されると、ユーザーは CodeReady Workspaces プラグインパネルまたは ワークスペース設定を使用してワークスペースに追加できます。

1.4.2.1. CodeReady Workspaces Plugins パネルを使用した VS コードエクステンションの追加

前提条件

手順

CodeReady Workspaces Plugins パネルを使用して VS コードエクステンションを追加するには、以下を実行します。

  1. CTRL+SHIFT+J を押すか、View/ Plugins に移動し、CodeReady Workspaces Plugins パネルを開きます。
  2. 現在のレジストリーを、VS Code 拡張が追加されたレジストリーに変更します。
  3. 検索バーで、Menu ボタンをクリックしてから Change Registry をクリックし、一覧からレジストリーを選択します。必要なレジストリーが一覧にない場合は、Add Registry menu オプションを使用して追加します。レジストリーリンクは、レジストリー プラグインセグメントを参照します( :
  4. 新しいレジストリーリンクを追加した後にプラグインの一覧を更新するには、検索バーメニューから Refresh コマンドを使用します。
  5. フィルターを使用して必要なプラグインを検索し、Install ボタンをクリックします。
  6. 変更を有効にするためにワークスペースを再起動します。
1.4.2.2. ワークスペース設定を使用した VS コードエクステンションの追加

前提条件

手順

ワークスペース設定を使用して VS コードエクステンションを追加するには、以下を行います。

  1. DashboardWorkspaces タブをクリックし、プラグインを追加するワークスペースを選択します。Workspace <workspace-name> ウィンドウが開き、ワークスペースの詳細が表示されます。
  2. devfile タブをクリックします。
  3. components セクションを見つけ、以下の構造で新しいエントリーを追加します。

     - type: chePlugin
       id:              
    1
    Copy to Clipboard Toggle word wrap
    1
    ID 形式: <publisher> /<plug-inName> /<plug-inVersion>

    CodeReady Workspaces は、他のフィールドを新しいコンポーネントに自動的に追加します。

    専用参照フィールドを使用して、GitHub でホストされる meta.yaml ファイルにリンクできます。

     - type: chePlugin
       reference:              
    1
    Copy to Clipboard Toggle word wrap
    1
    https://raw.githubusercontent.com/<username>/<registryRepository>/v3/plugins/<publisher>/<plug-inName>/<plug-inVersion>/meta.yaml
  4. 変更を有効にするためにワークスペースを再起動します。

1.4.3. VS コードエクステンション API の互換性レベルの確認

Che-Theia は、VS Code extensions API を完全にサポートしません。vscode -theia-comparator は、Che-Theia プラグイン API と VS Code extension API 間の互換性の分析に使用され ます。このツールは夜間サイクルで実行され、結果は vscode-theia -comparator GitHub のページで公開されます。

前提条件

手順

vscode -theia comparator を手動で実行するには、以下を 実行します。

  1. vscode-theia -comparator リポジトリーのクローンを 作成し、yarn コマンド を使用してビルドします。
  2. GITHUB _TOKEN 環境変数をトークンに設定します。
  3. yarn run generate コマンドを実行してレポートを生成します。
  4. out/status.html ファイルを開いてレポートを表示します。

第2章 CodeReady Workspaces ログの取得

CodeReady Workspaces でさまざまなタイプのログを取得する方法は、以下のセクションを参照してください。

2.1. OpenShift での OpenShift イベントへのアクセス

OpenShift プロジェクトの高レベルのモニタリングについては、プロジェクトが実行する OpenShift イベントを表示します。

このセクションでは、OpenShift Web コンソールでこれらのイベントにアクセスする方法を説明します。

前提条件

  • 実行中の OpenShift Web コンソール。

手順

  1. OpenShift Web コンソールの左側のパネルで、Home → Events をクリックします。
  2. 特定のプロジェクトの全イベントの一覧を表示するには、一覧からプロジェクトを選択します。
  3. 現在のプロジェクトのイベントの詳細が表示されます。

その他のリソース

2.2. OpenShift 4 CLI ツールを使用した CodeReady Workspaces クラスターデプロイメントの状態の表示

このセクションでは、OpenShift 4 CLI ツールを使用して CodeReady Workspaces クラスターのデプロイメントの状態を表示する方法を説明します。

前提条件

  • OpenShift で実行している Red Hat CodeReady Workspaces のインスタンス。
  • OpenShift コマンドラインツール oc のインストール。

手順

  1. 以下のコマンドを実行して crw プロジェクトを選択します。

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行して、選択したプロジェクトで実行されている Pod の名前およびステータスを取得します。

    $ oc get pods
    Copy to Clipboard Toggle word wrap
  3. すべての Pod のステータスが Running であることを確認します。

    例2.1 Runningステータスの Pod

    NAME                            READY     STATUS    RESTARTS   AGE
    codeready-8495f4946b-jrzdc            0/1       Running   0          86s
    codeready-operator-578765d954-99szc   1/1       Running   0          42m
    keycloak-74fbfb9654-g9vp5       1/1       Running   0          4m32s
    postgres-5d579c6847-w6wx5       1/1       Running   0          5m14s
    Copy to Clipboard Toggle word wrap
  4. CodeReady Workspaces クラスターデプロイメントの状態を表示するには、以下を実行します。

    $ oc logs --tail=10 -f `(oc get pods -o name | grep operator)`
    Copy to Clipboard Toggle word wrap

    例2.2 Operator のログ:

    Copy to Clipboard Toggle word wrap

2.3. CodeReady Workspaces サーバーログの表示

本セクションでは、コマンドラインを使用して CodeReady Workspaces サーバーログを表示する方法を説明します。

2.3.1. OpenShift CLI を使用した CodeReady Workspaces サーバーログの表示

このセクションでは、OpenShift CLI(コマンドラインインターフェース)を使用して CodeReady Workspaces サーバーログを表示する方法を説明します。

手順

  1. ターミナルで以下のコマンドを実行し、Pod を取得します。

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    $ oc get pods
    NAME            READY  STATUS   RESTARTS  AGE
    codeready-11-j4w2b    1/1    Running  0         3m
    Copy to Clipboard Toggle word wrap

  2. デプロイメントのログを取得するには、以下のコマンドを実行します。

    $ oc logs <name-of-pod>
    Copy to Clipboard Toggle word wrap

    $ oc logs codeready-11-j4w2b
    Copy to Clipboard Toggle word wrap

2.4. 外部サービスログの表示

このセクションでは、CodeReady Workspaces サーバーに関連する外部サービスのログを表示する方法を説明します。

2.4.1. RH-SSO ログの表示

RH-SSO OpenID プロバイダーは、サーバーと IDE の 2 つの部分で構成されます。診断またはエラー情報を複数のログに書き込みます。

2.4.1.1. RH-SSO サーバーログの表示

本セクションでは、RH-SSO OpenID プロバイダーサーバーのログを表示する方法を説明します。

手順

  1. OpenShift Web コンソールで Deployments をクリックします。
  2. Filter by label search フィールドに keycloak と入力し、RH-SSO ログを表示します。
  3. Deployment Configs セクションで、keycloak リンクをクリックして開きます。
  4. history タブ 、アクティブな RH-SSO デプロイメントの ログの表示 リンクをクリックします。
  5. RH-SSO ログが表示されます。
2.4.1.2. Firefox での RH-SSO クライアントログの表示

本セクションでは、Firefox WebConsole で RH-SSO IDE クライアントの診断またはエラー情報を表示する方法を説明します。

手順

  • Menu > WebDeveloper > WebConsole をクリックします。
2.4.1.3. Google Chrome での RH-SSO クライアントログの表示

本セクションでは、Google Chrome Console タブで RH-SSO IDE クライアント診断またはエラー情報を表示する方法を説明します。

手順

  1. Menu > More Tools > Developer Tools の順 にクリックします。
  2. Console タブをクリックします。

    Google chrome で keycloak ide ログを表示する CRW

2.4.2. CodeReady Workspaces データベースログの表示

本セクションでは、PostgreSQL サーバーログなどの CodeReady Workspaces でデータベースログを表示する方法を説明します。

手順

  1. OpenShift Web コンソールで Deployments をクリックします。
  2. Find by label 検索フィールドに、以下を入力します。

    • app=che を押して Enter
    • component=postgres および Enter

      OpenShift Web コンソールは、これら 2 つのキーに基づいて検索し、PostgreSQL ログを表示するようになりました。

  3. postgres デプロイメントをクリックして開きます。
  4. アクティブな PostgreSQL デプロイメントの ログを表示 リンクをクリックします。

    OpenShift Web コンソールは、データベースログを表示します。

その他のリソース

  • PostgreSQL サーバーに関連する一部の診断またはエラーメッセージは、アクティブな CodeReady Workspaces デプロイメントログにあります。アクティブな CodeReady Workspaces デプロイメントログにアクセスする方法は、「 CodeReady Workspaces サーバーログの 表示」を参照してください。

2.5. CodeReady Workspaces ワークスペースログの表示

このセクションでは、CodeReady Workspaces ワークスペースログを表示する方法を説明します。

2.5.1. Che-Theia IDE ログの表示

このセクションでは、Che-Theia IDE ログを表示する方法を説明します。

2.5.1.1. OpenShift CLI を使用した Che-Theia エディターログの表示

Che-Theia エディターのログを確認すると、エディターがロードしたプラグインについての理解と洞察を向上させることができます。このセクションでは、OpenShift CLI(コマンドラインインターフェース)を使用して Che-Theia エディターログにアクセスする方法を説明します。

前提条件

  • CodeReady Workspaces は OpenShift クラスターにデプロイされます。
  • ワークスペースが作成されます。
  • ユーザーは CodeReady Workspaces インストールプロジェクトにあります。

手順

  1. 利用可能な Pod の一覧を取得します。

    $ oc get pods
    Copy to Clipboard Toggle word wrap

    $ oc get pods
    NAME                                              READY  STATUS   RESTARTS  AGE
    codeready-9-xz6g8                                 1/1    Running  1         15h
    workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2  4/4    Running  0         1h
    Copy to Clipboard Toggle word wrap

  2. 特定の Pod で利用可能なコンテナーの一覧を取得します。

    $ oc get pods <name-of-pod> --output jsonpath='\{.spec.containers[*].name}'
    Copy to Clipboard Toggle word wrap

    たとえば、以下のようになります。

    $ oc get pods workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 -o
    jsonpath='\{.spec.containers[*].name}'
    > go-cli che-machine-exechr7 theia-idexzb vscode-gox3r
    Copy to Clipboard Toggle word wrap

  3. ia /ide コンテナーからログ を取得します。

    $ oc logs --follow <name-of-pod> --container <name-of-container>
    Copy to Clipboard Toggle word wrap

    たとえば、以下のようになります。

    $ oc logs --follow workspace0zqb2ew3py4srthh.go-cli-549cdcf69-9n4w2 -container
    theia-idexzb
    >root INFO unzipping the plug-in 'task_plugin.theia' to directory: /tmp/theia-unpacked/task_plugin.theia
    root INFO unzipping the plug-in 'theia_yeoman_plugin.theia' to directory: /tmp/theia-unpacked/theia_yeoman_plugin.theia
    root WARN A handler with prefix term  is already registered.
    root INFO [nsfw-watcher: 75] Started watching: /home/theia/.theia
    root WARN e.onStart is slow, took: 367.4600000013015 ms
    root INFO [nsfw-watcher: 75] Started watching: /projects
    root INFO [nsfw-watcher: 75] Started watching: /projects/.theia/tasks.json
    root INFO [4f9590c5-e1c5-40d1-b9f8-ec31ec3bdac5] Sync of 9 plugins took: 62.26000000242493 ms
    root INFO [nsfw-watcher: 75] Started watching: /projects
    root INFO [hosted-plugin: 88] PLUGIN_HOST(88) starting instance
    Copy to Clipboard Toggle word wrap

2.5.2. 言語サーバーからのログの表示およびデバッグアダプター

2.5.2.1. 重要なログの確認

このセクションでは、重要なログを確認する方法を説明します。

手順

  1. OpenShift Web コンソールで、ApplicationsPods をクリックし、アクティブなワークスペースの一覧を表示します。
  2. ワークスペースが実行されている Pod の名前をクリックします。Pod 画面には、追加の情報が含まれるすべてのコンテナーの一覧が含まれます。
  3. コンテナーを選択し、コンテナー名をクリックします。

    ヒント

    最も重要なログ は、ia-ide コンテナーとプラグインコンテナーログです。

  4. コンテナー画面で Logs セクションに移動します。

    以下は、Java プラグインを実行するサイドカーコンテナーの出力ログです。

    重要なログの確認
2.5.2.2. メモリー問題の検出

このセクションでは、メモリー不足のプラグインに関連するメモリーの問題を検出する方法を説明します。以下は、メモリー不足のプラグインに関連する最も一般的な問題です。

プラグインコンテナーがメモリー不足の状態になる
これは、コンテナーのイメージエントリーポイントを実行するのに十分な RAM がない場合にプラグインの初期化中に発生する可能性があります。ユーザーは、プラグインコンテナーのログでこれを検出できます。この場合、ログには OOMKilled が含まれます。これは、コンテナーのプロセスがコンテナーで利用可能な以上のメモリーを要求することを意味します。
コンテナー内のプロセスが、これを通知せずにメモリーが不足します。

たとえば、Java 言語サーバー(vscode-java エクステンションによって開始された Eclipse JDT Language Server)は OutOfMemoryException をスローし ます。これは、コンテナーが初期化された後、プラグインが言語サーバーを起動するときや、処理する必要があるプロジェクトのサイズが原因でプロセスがメモリー不足になる場合などにいつでも発生する可能性があります。

この問題を回避するには、コンテナーで実行しているプライマリープロセスのログを確認します。たとえば、Eclipse JDT Language Server のログファイルを確認するには、関連するプラグイン固有のセクションを参照してください。

2.5.2.3. デバッグアダプターのクライアントサーバートラフィックのロギング

このセクションでは、Che-Theia とデバッグアダプター間の交換を Output ビューに記録する方法を説明します。

前提条件

  • Debug アダプター オプションがリストに表示されるため、デバッグセッションを開始する必要があります。

手順

  1. FileSettings の順にクリックし、Preferences を開き ます。
  2. Preferences ビューの Debug セクションを展開します。
  3. trace 設定値を true に設定します(デフォルトは falseです)。
  4. これで、すべての通信イベントがログに記録されます。
  5. これらのイベントを確認するには、View → Output をクリックし、Output ビューの右上にあるドロップダウンリスト から Debug Adapter を選択します。
2.5.2.4. Python のログの表示

本セクションでは、Python 言語サーバーのログを表示する方法を説明します。

手順

  • Output ビューに移動し、ドロップダウンリストで Python を選択します。

    python のログの表示
2.5.2.5. Go のログの表示

本セクションでは、Go 言語サーバーのログを表示する方法を説明します。

2.5.2.5.1. ゴパスの検索

このセクションでは、GOPATH 変数が参照する場所を見つける方法を説明します。

手順

  • Go: 現在の GOPATH コマンドを実行します。

    ゴパスの検索
    Gopath の表示
2.5.2.5.2. Go のデバッグコンソールログの表示

本セクションでは、Go デバッガーからのログ出力を表示する方法を説明します。

手順

  1. デバッグ設定 showLog 属性を true に設定します。

    {
      "version": "0.2.0",
      "configurations": [
         {
            "type": "go",
            "showLog": true
           ....
         }
      ]
    }
    Copy to Clipboard Toggle word wrap
  2. コンポーネントのデバッグ出力を有効にするには、パッケージを logOutput 属性 のコンマ区切りリスト値に追加します。

    {
      "version": "0.2.0",
      "configurations": [
         {
            "type": "go",
            "showLog": true,
            "logOutput": "debugger,rpc,gdbwire,lldbout,debuglineerr"
           ....
         }
      ]
    }
    Copy to Clipboard Toggle word wrap
  3. デバッグコンソールは、デバッグコンソールで追加情報を出力します。

    go のデバッグコンソールログの表示
2.5.2.5.3. Output パネルでの Go ログ出力の表示

このセクションでは、出力 パネル で Go ログの出力を表示する方法を説明します。

手順

  1. Output ビューに移動します。
  2. ドロップダウンリストで Go を選択します。

    出力パネルで go logs 出力の表示
2.5.2.6. NodeDebug NodeDebug2 アダプターのログの表示
注記

一般的な診断以外の特定の診断はありません。

2.5.2.7. Typescript のログの表示
2.5.2.7.1. ラベル切り替えプロトコル(LSP)トレースの有効化

手順

  1. Typescript(TS)サーバーに送信されたメッセージの追跡を有効にするには、Preferences ビューで typescript.tsserver .trace 属性を詳細に設定し ます。このパラメーターを使用して、TS サーバーの問題を診断します。
  2. TS サーバーのファイルのロギングを有効にするには、typescript.tsserver .log 属性を verbose に設定します。このログを使用して、TS サーバーの問題を診断します。ログにはファイルパスが含まれます。
2.5.2.7.2. Typescript 言語サーバーログの表示

本セクションでは、Typescript 言語サーバーログを表示する方法を説明します。

手順

  1. ログファイルへのパスを取得するには、「 Typescript Output console」を参照してください。

    typescript 言語サーバーログの検索
  2. ログファイルを開くには、Open TS Server log コマンドを使用します。

    typescript 言語サーバーログの表示
2.5.2.7.3. Output パネルでの Typescript ログ出力の表示

このセクションでは、Output パネルで Typescript ログ出力を表示する方法を説明します。

手順

  1. 出力ビューに移動します
  2. ドロップダウンリストで TypeScript を選択します。

    出力パネルで typescript ログ出力の表示
2.5.2.8. Java のログの表示

一般的な診断以外に、ユーザーが実行できる Language Support for Java(Eclipse JDT Language Server) プラグインアクションがあります。

2.5.2.8.1. Eclipse JDT Language Server の状態の検証

手順

Eclipse JDT Language Server プラグインを実行しているコンテナーが Eclipse JDT Language Server メインプロセスを実行しているかどうかを確認します。

  1. Eclipse JDT Language Server プラグインを実行しているコンテナーでターミナルを開きます(例: container: vscode-javaxxx)。
  2. ターミナル内で ps aux | grep jdt コマンドを実行して、Eclipse JDT Language Server プロセスがコンテナーで実行しているかどうかを確認します。プロセスが実行されている場合、出力は以下のようになります。

    usr/lib/jvm/default-jvm/bin/java --add-modules=ALL-SYSTEM --add-opens java.base/java.util
    Copy to Clipboard Toggle word wrap

    このメッセージには、使用された VSCode Java エクステンションも表示されます。実行していない場合、言語サーバーはコンテナー内で起動されていません。

  3. 重要なログの確認」で説明されているすべてのログの確認
2.5.2.8.2. Eclipse JDT Language Server 機能の検証

手順

Eclipse JDT Language Server プロセスが実行している場合は、言語サーバー機能が機能しているかどうかを確認します。

  1. Java ファイルを開き、ホバーまたは自動補完機能を使用します。ファイルが正しくない場合、ユーザーは Outline ビューまたは Problems ビューで Java を確認します。
2.5.2.8.3. Java 言語サーバーログの表示

手順

Eclipse JDT Language Server には、エラー、実行されたコマンド、およびイベントに関する情報をログに記録する独自のワークスペースがあります。

  1. このログファイルを開くには、Eclipse JDT Language Server プラグインを実行しているコンテナーでターミナルを開きます。また、Java: Open Java Language Server log file コマンドを実行してログファイル を表示することもできます。
  2. cat <PATH_TO_LOG_FILE> を実行します。ここで、PATH_TO_LOG_FILE/home/theia/.theia/workspace-storage/<workspace_name>/redhat.java/jdt_ws/.metadata/.log です。
2.5.2.8.4. Java 言語サーバープロトコル(LSP)メッセージのロギング

手順

VS コード 出力 ビューに LSP メッセージをログに記録するには、java.trace.server 属性を verbose に設定してトレースを有効にします。

その他のリソース

トラブルシューティングの手順は、VS Code Java Github リポジトリー を参照してください。

2.5.2.9. Intelephense のログの表示
2.5.2.9.1. Intelephense クライアントサーバー通信のロギング

手順

出力 ビューでクライアント/サーバーの相互交換をログに記録するように PHP Intelephense 言語サポートを設定するには、以下を行います。

  1. File → Settings をクリックします。
  2. Preferences ビューを開きます。
  3. Intelephense セクションを 展開 し、trace.server.verbose 優先度の値を verbose に設定し、すべての通信イベントを 表示 します(デフォルト値は offです)。
2.5.2.9.2. Output パネルでの Intelephense イベントの表示

この手順では、Output パネルで Intelephense イベントを表示する方法を説明します。

手順

  1. View → Output をクリックします
  2. 出力 ビュー のドロップダウンリストで Intelephense を選択します。
2.5.2.10. PHP-Debug のログの表示

この手順では、PHP Debug プラグインを設定して PHP Debug プラグイン診断メッセージを Debug Console ビューに記録する方法を説明します。デバッグセッションの開始前にこれを設定します。

手順

  1. launch.json ファイルに、選択した起動設定に "log": true 属性を追加します。
  2. デバッグセッションを開始します。
  3. 診断メッセージは、アプリケーションの出力と共に Debug Console ビューに出力されます。
2.5.2.11. XML のログの表示

一般的な診断以外には、ユーザーが実行できる XML プラグイン固有のアクションがあります。

2.5.2.11.1. XML 言語サーバーの状態の確認

手順

  1. vscode -xml- <xxx> という名前のコンテナーでターミナルを開きます
  2. ps aux | grep java を実行して、XML 言語サーバーが起動していることを確認します。プロセスが実行されている場合、出力は以下のようになります。

    java ***/org.eclipse.ls4xml-uber.jar`
    Copy to Clipboard Toggle word wrap

    そうでない場合は、「 重要なログの確認 」の章を参照してください。

2.5.2.11.2. XML 言語サーバーの機能フラグの確認

手順

  1. 機能が有効になっているかどうかを確認します。XML プラグインは、機能を有効または無効にできる複数の設定を提供します。

    • xml.format.enabled: フォーマッターを有効にします。
    • XML.validation.enabled: 検証を有効にします。
    • XML.documentSymbols.enabled: ドキュメントシンボルの有効化
  2. XML 言語サーバーが機能しているかどうかを確認するには、<hello></hello> などの単純な XML 要素を作成し 右側の Outline パネルに表示されることを確認します。
  3. ドキュメントシンボルが表示されない場合は、xml.documentSymbols.enabled 属性が true に設定されていることを確認します。true で、シンボルがない場合、言語サーバーはエディターにフックされないことがあります。ドキュメント記号がある場合、言語サーバーはエディターに接続されます。
  4. ユーザーの必要な機能が設定内で true に設定されていることを確認します(デフォルトでは true に設定されます)。機能のいずれかが機能していない、または予想通りに機能しない場合は、Language Server に対して問題を報告します。
2.5.2.11.3. XML Language Server Protocol(LSP)トレースの有効化

手順

VS コード 出力 ビューに LSP メッセージをログに記録するには、xml.trace.server 属性を verbose に設定してトレースを有効にします。

2.5.2.11.4. XML 言語サーバーログの表示

手順

言語サーバーからのログは、/home/theia/.theia/workspace-storage/<workspace_name>/redhat.vscode-xml/lsp4xml.log のプラグインサイドカーコンテナーにあります。

2.5.2.12. YAML のログの表示

このセクションでは、一般的な診断に加えて、ユーザーが実行できる YAML プラグイン固有のアクションについて説明します。

2.5.2.12.1. YAML 言語サーバーの状態の確認

本セクションでは、YAML 言語サーバーの状態を検証する方法を説明します。

手順

YAML プラグインを実行しているコンテナーが YAML 言語サーバーを実行しているかどうかを確認します。

  1. エディターで、YAML プラグインを実行しているコンテナーでターミナルを開きます(コンテナーの例: vscode -yaml-<xxx>)。
  2. ターミナルで、ps aux | grep node コマンドを実行します。このコマンドは、現在のコンテナーで実行しているすべてのノードプロセスを検索します。
  3. コマンド ノード **/server.js が実行されていることを確認します。

    yaml 言語サーバーの状態の確認

コンテナーで実行している ノード **/server.js は、言語サーバーが実行されていることを示しています。実行していない場合、言語サーバーはコンテナー内で起動しません。この場合、「 重要なログの確認」を 参照してください。

2.5.2.12.2. YAML 言語サーバー機能フラグの確認

手順

機能フラグを確認するには、次のコマンドを実行します。

  1. 機能が有効になっているかどうかを確認します。YAML プラグインは、以下のような機能を有効または無効にすることができる複数の設定を提供します。

    • yaml.format.enable: フォーマッターを有効にします。
    • yaml.validate: 検証 を有効にします。
    • yaml.hover: マウス 機能を有効にします。
    • yaml.completion: 補完 機能を有効にします。
  2. プラグインが機能していることを確認するには、hello: world などの最も単純な YAML を入力し、エディターの右側で Outline パネルを開きます。
  3. ドキュメントシンボルがあるかどうかを確認します。yes の場合、言語サーバーはエディターに接続されます。
  4. 機能が機能しない場合は、上記の設定が true に設定されていることを確認します(デフォルトでは true に設定されます)。機能が機能しない場合は、Language Server に対して問題を報告します。
2.5.2.12.3. YAML Language Server Protocol(LSP)トレースの有効化

手順

VS コード 出力 ビューに LSP メッセージをログに記録するには、yaml.trace.server 属性を verbose に設定してトレースを有効にします。

2.5.2.13. Omnisharp-Theia プラグインを使用した Dotnet のログの表示
2.5.2.13.1. Omnisharp-Theia プラグイン

CodeReady Workspaces は Omnisharp-Theia プラグインをリモートプラグインとして使用します。これは github.com/redhat-developer/omnisharp-theia-plugin に あります。問題が発生した場合は、これを報告するか、リポジトリーで修正を貢献します。

このプラグインは omnisharp- roslyn を言語サーバー として登録し、C# アプリケーションにプロジェクトの依存関係と言語構文を提供します。

言語サーバーは .NET SDK 2.2.105 で実行されます。

2.5.2.13.2. Omnisharp-Theia プラグイン言語サーバーの状態の確認

手順

Omnisharp-Theia プラグインを実行しているコンテナーが OmniSharp を実行しているかどうかを確認するには、ps aux | grep OmniSharp.exe コマンドを実行します。プロセスが実行されている場合、以下が出力例になります。

/tmp/theia-unpacked/redhat-developer.che-omnisharp-plugin.0.0.1.zcpaqpczwb.omnisharp_theia_plugin.theia/server/bin/mono
/tmp/theia-unpacked/redhat-developer.che-omnisharp-plugin.0.0.1.zcpaqpczwb.omnisharp_theia_plugin.theia/server/omnisharp/OmniSharp.exe
Copy to Clipboard Toggle word wrap

出力が異なると、言語サーバーはコンテナー内で起動しません。「 重要なログの確認」で説明されているログを確認 してください。

2.5.2.13.3. Omnisharp Che-Theia プラグイン言語サーバー機能の確認

手順

  • OmniSharp.exe プロセスが実行している場合は、.cs ファイルを開いて、言語サーバーの機能が機能しているかどうかを確認します。または、Problems ビューまたは Outline ビューを開きます。
2.5.2.13.4. Output パネルでの Omnisharp-Theia プラグインログの表示

手順

Omnisharp .exe が実行されている場合、これは Output パネルのすべての情報をログに記録します。ログを表示するには、Output ビューを開き、ドロップダウンリストから C# を選択します。

2.5.2.14. NetcoredebugOutput プラグインを使用した Dotnet のログの表示
2.5.2.14.1. NetcoredebugOutput プラグイン

NetcoredebugOutput プラグインは、netcoredbg ツールを提供 ます。このツールは、VS Code Debug Adapter プロトコルを実装し、ユーザーが .NET Core ランタイムで .NET アプリケーションをデバッグできるようにします。

NetcoredebugOutput プラグインを実行しているコンテナーには Dotnet SDK v.2.2.105 が含まれます。

2.5.2.14.2. NetcoredebugOutput プラグインの状態の確認

手順

プラグインの初期化をテストするには、以下を実行します。

  1. launch.json ファイルに netcoredbg デバッグ設定があるかどうかを確認します。デバッグ設定の例を以下に示します。

    {
     "type": "netcoredbg",
     "request": "launch",
     "program": "$\{workspaceFolder}/bin/Debug/<target-framework>/<project-name.dll>",
     "args": [],
     "name": ".NET Core Launch (console)",
     "stopAtEntry": false,
     "console": "internalConsole"
    }
    Copy to Clipboard Toggle word wrap
  2. 存在する場合をテストするには、launch.json ファイルの configuration セクションのかっこ内の自動補完機能をテストします。netcoredbg を見つけると Che-Theia プラグインは正しく初期化されます。そうでない場合は、「 重要なログの確認」を 参照してください。
2.5.2.14.3. Output パネルでの NetcoredebugOutput プラグインログの表示

本セクションでは、Output パネルで NetcoredebugOutput プラグインのログを表示する方法を説明します。

手順

  • Debug コンソールを開きます。

    出力パネルのログでの netcoredebugoutput プラグインの表示
2.5.2.15. Camel のログの表示
2.5.2.15.1. Camel 言語サーバーの状態の確認

手順

vscode -apache-camel <xxx> Camel コンテナーに保存されている Camel 言語ツールを使用して、サイドカーコンテナー のログ出力を検査できます。

言語サーバーの状態を確認するには、次のコマンドを実行します。

  1. vscode -apache-camel <xxx>コンテナー でターミナルを開きます。
  2. ps aux | grep java コマンドを実行します。以下は、言語サーバープロセスの例になります。

    java -jar /tmp/vscode-unpacked/camel-tooling.vscode-apache-camel.latest.euqhbmepxd.camel-tooling.vscode-apache-camel-0.0.14.vsix/extension/jars/language-server.jar
    Copy to Clipboard Toggle word wrap
  3. 見つからない場合は、「 重要なログの確認 」を参照してください。
2.5.2.15.2. Output パネルでの Camel ログの表示

Camel 言語サーバーは、ログを $\{java.io.tmpdir}/log-camel-lsp.out ファイルに書き込む SpringBoot アプリケーションです。通常、$\{java.io.tmpdir}/tmp ディレクトリーを参照するため、ファイル名は /tmp/log-camel-lsp.out に なります。

手順

Camel 言語サーバーログは、Language Support for Apache Camel という名前の Output チャンネルに出力されます。

注記

出力チャネルは、クライアント側で最初に作成されたログエントリー時にのみ作成されます。すべてが正常に機能しなくなると、存在しない可能性があります。

出力パネルでの Camel ログの表示

2.6. プラグインブローカーログの表示

このセクションでは、プラグインブローカーログを表示する方法を説明します。

che-plugin-broker Pod 自体は、作業の完了時に削除されます。したがって、そのイベントログはワークスペースの起動時にのみ利用できます。

手順

一時 Pod からログに記録されたイベントを表示するには、以下を実行します。

  1. CodeReady Workspaces ワークスペースを起動します。
  2. 主な OpenShift Container Platform 画面で、Workload → Pods に移動します。
  3. Pod の Terminal タブにある OpenShift ターミナル コンソールを使用します。

検証手順

  • OpenShift ターミナルコンソールは、ワークスペースの開始時にプラグインブローカーログを表示します。

2.7. crwctl を使用したログの収集

crwctl ツール を使用して、OpenShift クラスターからすべての Red Hat CodeReady Workspaces ログを取得できます。

  • crwctl server:start は、Red Hat CodeReady Workspaces のインストール時に Red Hat CodeReady Workspaces サーバーのログの収集を自動的に開始します。
  • crwctl server:logs が既存の Red Hat CodeReady Workspaces サーバーログを収集します。
  • crwctl workspace:logs がワークスペースログを収集します。

第3章 CodeReady Workspaces の監視

本章では、CodeReady Workspaces を設定してメトリクスを公開し、CodeReady Workspaces でメトリクスとして公開されるデータを処理する外部ツールを使用してモニタリングスタックのサンプルを構築する方法を説明します。

3.1. CodeReady Workspaces メトリクスの有効化および公開

このセクションでは、CodeReady Workspaces メトリクスを有効にして公開する方法を説明します。

手順

  1. CHE _METRICS_ENABLED=true 環境変数を設定します。これは、che-master ホストで 8087 ポートをサービスとして公開します。

Red Hat CodeReady Workspaces が OperatorHub からインストールされると、デフォルトの CheCluster CR が使用されると、環境変数は自動的 設定されます。

che che cluster cr の監視
spec:
  metrics:
    enable: true
Copy to Clipboard Toggle word wrap

3.2. Prometheus を使用した CodeReady Workspaces メトリクスの収集

本セクションでは、Prometheus モニタリングシステムを使用して CodeReady Workspaces についてのメトリクスを収集し、保存し、クエリーする方法を説明します。

前提条件

手順

  • 8087 ポートからメトリクスをスクレープするように Prometheus を設定します。

    Prometheus の設定例

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: prometheus-config
    data:
      prometheus.yml: |-
          global:
            scrape_interval:     5s             
    1
    
            evaluation_interval: 5s             
    2
    
          scrape_configs:                       
    3
    
            - job_name: 'che'
              static_configs:
                - targets: ['[che-host]:8087']  
    4
    Copy to Clipboard Toggle word wrap

    1
    ターゲットがスクレープされるレート。
    2
    記録ルールおよびアラートルールを再チェックする速度(現時点ではシステムでは使用されません)。
    3
    リソース Prometheus モニター。デフォルト設定では、codeready という単一のジョブがあり、CodeReady Workspaces サーバーによって公開される時系列データをスクレープします。
    4
    8087 ポートからメトリクスを収集します。

検証手順

  • Prometheus コンソールを使用してメトリクスをクエリーし、表示します。

    メトリックは http://<che-server-url>:9090/metrics で利用できます。

    詳細は、Prometheus ドキュメントの「 Using the expression browser 」を参照してください。

3.3. CodeReady Workspaces モニタリングメトリクスの拡張

本セクションでは、CodeReady Workspaces が公開しているモニタリングメトリクスを拡張するために、メトリクスまたはメトリクスのグループを作成する方法を説明します。

CodeReady Workspaces には、2 つの主要なモジュールメトリクスがあります。

  • che-core-metrics-core - コアメトリクスモジュールが含まれます。
  • che-core-api-metrics - ワークスペースやユーザーマネージャーなどのコア CodeReady Workspaces コンポーネントに依存するメトリクスが含まれます。

手順

  • MeterBinder クラスを拡張するクラスを作成し ます。これにより、作成されたメトリクスをオーバーライドされた bindTo(MeterRegistry registry) メソッドに登録できます。

    以下は、値を提供する関数を持つメトリクスの例です。

    メトリクスの例

    public class UserMeterBinder implements MeterBinder {
    
      private final UserManager userManager;
    
      @Inject
      public UserMeterBinder(UserManager userManager) {
        this.userManager = userManager;
      }
    
      @Override
      public void bindTo(MeterRegistry registry) {
        Gauge.builder("che.user.total", this::count)
            .description("Total amount of users")
            .register(registry);
      }
    
      private double count() {
        try {
          return userManager.getTotalCount();
        } catch (ServerException e) {
          return Double.NaN;
        }
      }
    Copy to Clipboard Toggle word wrap

    メトリックは参照を使って保存でき、手動でコード内の他の場所に更新できます。

第4章 CodeReady Workspaces のトレース

トレースは、マイクロサービスアーキテクチャーのレイテンシーの問題のトラブルシューティングを行うタイミングデータを収集し、分散システムを介して伝搬する際の完全なトランザクションまたはワークフローを理解するのに役立ちます。すべてのトランザクションは、独立したチームによって新しいサービスが導入されると、初期段階においてパフォーマンスの懸念を反映する可能性があります。

CodeReady Workspaces アプリケーションを追跡すると、ワークスペース作成、ワークスペースの起動、サブ操作の実行期間の破棄、ボトルネックの特定やプラットフォーム全体の状態の向上など、さまざまな操作の実行の分析に役立ちます。

トレーサーはアプリケーションで稼働します。実施される操作に関するタイミングとメタデータを記録します。これは多くの場合、ライブラリーをインストルメント化するため、その使用がユーザーに透過的になります。たとえば、インストルメント化された Web サーバーレコードはリクエストの受信時や応答の送信時に記録されます。収集されるトレースデータは スパン と呼ばれます。スパンには、トレース、スパン識別子、および行の下に伝播できるその他の種類のデータを含むコンテキストがあります。

4.1. トレース API

CodeReady Workspaces はインストルメンテーションにベンダーに依存しない OpenTracing API を使用します。つまり、開発者が異なるトレースバックエンドを試行し、その後に新たな分散トレースシステム用のインストルメンテーションプロセス全体を繰り返す代わりに、開発者はトレーサーバックエンドの設定を簡単に変更できることを意味します。

4.2. バックエンドのトレース

デフォルトでは、CodeReady Workspaces はトレースバックエンドとして Jaeger を使用します。Jaeger は Dapper と OpenZipkin によって影響を受け、Uber Technologies によってオープンソースとしてリリースされた分散トレースシステムです。Jaeger は、リクエストおよびパフォーマンスを大規模にするためにより複雑なアーキテクチャーを拡張します。

4.3. Jaeger トレースツールのインストール

以下のセクションでは、Jaeger トレースツールのインストール方法を説明します。その後、CodeReady Workspaces でメトリクスの収集に Jaeger を使用できます。

利用可能なインストール方法:

Jaeger を使用して CodeReady Workspaces インスタンスをトレースするには、バージョン 1.12.0 以降のバージョンが必要です。Jaeger の詳細は、Jaeger の Web サイトを参照して ください

4.3.1. OpenShift 4 での CodeReady Workspaces の Jaeger トレースツールのインストール

本セクションでは、評価の目的で Jaeger トレースツールを使用する方法を説明します。

OpenShift Container Platform の CodeReady Workspaces プロジェクトから Jaeger トレースツールをインストールするには、本セクションの手順に従います。

前提条件

  • ユーザーが OpenShift Container Platform Web コンソールにログインしている。
  • OpenShift Container Platform クラスターの CodeReady Workspaces のインスタンス。

手順

  1. OpenShift Container Platform クラスターの CodeReady Workspaces インストールプロジェクトで、oc クライアントを使用して Jaeger デプロイメント用の新規アプリケーションを作成します。

    $ oc new-app -f / ${CHE_LOCAL_GIT_REPO}/deploy/openshift/templates/jaeger-all-in-one-template.yml:
    
    --> Deploying template "<project_name>/jaeger-template-all-in-one" for "/home/user/crw-projects/crw/deploy/openshift/templates/jaeger-all-in-one-template.yml" to project <project_name>
    
         Jaeger (all-in-one)
         ---------
         Jaeger Distributed Tracing Server (all-in-one)
    
         * With parameters:
            * Jaeger Service Name=jaeger
            * Image version=latest
            * Jaeger Zipkin Service Name=zipkin
    
    --> Creating resources ...
        deployment.apps "jaeger" created
        service "jaeger-query" created
        service "jaeger-collector" created
        service "jaeger-agent" created
        service "zipkin" created
        route.route.openshift.io "jaeger-query" created
    --> Success
        Access your application using the route: 'jaeger-query-<project_name>.apps.ci-ln-whx0352-d5d6b.origin-ci-int-aws.dev.rhcloud.com'
        Run 'oc status' to view your app.
    Copy to Clipboard Toggle word wrap
  2. メインの OpenShift Container Platform 画面の左側のメニューから Workloads → Deployments を使用して、正常に終了するまで Jaeger デプロイメントを監視します。
  3. メインの OpenShift Container Platform 画面の左側のメニューから Networking → Routes を選択し、URL リンクをクリックして Jaeger ダッシュボードにアクセスします。
  4. CodeReady Workspaces トレースコレクションの有効化 」の手順にしたがって、手順を完了します。

4.3.2. OpenShift 4 での OperatorHub を使用した Jaeger のインストール

本セクションでは、実稼働環境で評価の目的で Jaeger トレースツールを使用する方法を説明します。

OpenShift Container Platform の OperatorHub インターフェースから Jaeger トレースツールをインストールするには、以下の手順を行います。

前提条件

  • ユーザーが OpenShift Container Platform Web コンソールにログインしている。
  • CodeReady Workspaces インスタンスはプロジェクトで利用できます。

手順

  1. OpenShift Container Platform コンソールを開きます。
  2. メインの OpenShift Container Platform 画面の左側のメニューから、Operators → OperatorHub に移動します。
  3. Search by keyword search bar に Jaeger Operator を入力します。
  4. Jaeger Operator タイルをクリックします。
  5. Jaeger Operator ポップアップウィンドウで Install ボタンを クリックします。
  6. インストール方法: CodeReady Workspaces がデプロイされている クラスター上の特定のプロジェクト で、残りのプロジェクトはデフォルト値のままにします。
  7. Subscribe ボタンをクリックします。
  8. OpenShift Container Platform メイン画面の左側のメニューから、Operators → Installed Operators セクションに移動します。
  9. Red Hat CodeReady Workspaces は Installed Operator として表示され、InstallSucceeded ステータスで示されます。
  10. インストールされた Operator の一覧で Jaeger Operator 名をクリックします。
  11. Overview タブに移動します。
  12. ページ下部の Conditions セクションで、この message: install strategy completed with error を待ちます
  13. Jaeger Operator および追加の Elasticsearch Operator がインストールされている。
  14. Operators → Installed Operators セクションに移動します。
  15. インストールされた Operator の一覧で Jaeger Operator をクリックします。
  16. Jaeger Cluster ページが表示されます。
  17. ウィンドウの左下隅にある Create Instanceをクリックします。
  18. 保存 をクリックします。
  19. OpenShift は Jaeger クラスター jaeger-all-in-one-inmemory を作成します。
  20. CodeReady Workspaces メトリクスコレクションの有効化」の手順にしたがって、手順を完了します。

4.4. CodeReady Workspaces トレースコレクションの有効化

前提条件

手順

Jaeger トレースが機能するには、CodeReady Workspaces デプロイメントで以下の環境変数を有効にします。

# Activating CodeReady Workspaces tracing modules
CHE_TRACING_ENABLED=true

# Following variables are the basic Jaeger client library configuration.
JAEGER_ENDPOINT="http://jaeger-collector:14268/api/traces"

# Service name
JAEGER_SERVICE_NAME="che-server"

# URL to remote sampler
JAEGER_SAMPLER_MANAGER_HOST_PORT="jaeger:5778"

# Type and param of sampler (constant sampler for all traces)
JAEGER_SAMPLER_TYPE="const"
JAEGER_SAMPLER_PARAM="1"

# Maximum queue size of reporter
JAEGER_REPORTER_MAX_QUEUE_SIZE="10000"
Copy to Clipboard Toggle word wrap

以下の環境変数を有効にするには、以下を実行します。

  1. CodeReady Workspaces デプロイメントの yaml ソースコードで、spec.server.customCheProperties の下に以下の設定変数を追加します

    customCheProperties:
          CHE_TRACING_ENABLED: 'true'
          JAEGER_SAMPLER_TYPE: const
          DEFAULT_JAEGER_REPORTER_MAX_QUEUE_SIZE: '10000'
          JAEGER_SERVICE_NAME: che-server
          JAEGER_ENDPOINT: 'http://jaeger-collector:14268/api/traces'
          JAEGER_SAMPLER_MANAGER_HOST_PORT: 'jaeger:5778'
          JAEGER_SAMPLER_PARAM: '1'
    Copy to Clipboard Toggle word wrap
  2. デプロイメントの Jaeger コレクターサービスの名前に一致するように JAEGER_ENDPOINT の値を編集します。

    OpenShift Container Platform メイン画面の左側のメニューから、Networking → Services へのナビゲーションで JAEGER_ENDPOINT の値を取得します。ここでは、以下の oc コマンドを実行します。

    $ oc get services
    Copy to Clipboard Toggle word wrap

    要求された値は、コレクター 文字列が含まれるサービス名に含まれます。

その他のリソース

4.5. Jaeger UI での CodeReady Workspaces トレースの表示

ここでは、Jaeger UI を使用して CodeReady Workspaces 操作の概要を説明します。

手順

この例では、CodeReady Workspaces インスタンスがしばらく実行しており、1 つのワークスペースの起動が行われています。

ワークスペースの起動のトレースを確認するには、次のコマンドを実行します。

  1. 左側の Search パネルで、操作名(span name)、タグ、または時間と期間で絞り込みを行います。

    図4.1 Jaeger UI を使用した CodeReady Workspaces のトレース

    トレース検索
  2. 拡張するトレースを選択し、ネストされたスパンのツリーと、タグや期間などの強調表示されたスパンに関する追加情報を表示します。

    図4.2 拡張トレースツリー

    展開したトレースツリー

4.6. CodeReady Workspaces のコードベースの概要およびエクステンションガイド

CodeReady Workspaces のトレース実装のコアは、che-core-tracing-core および che-core -tracing-web モジュールにあります。

トレーシング API へのすべての HTTP リクエストには独自のトレースがあります。これは、サーバーアプリケーション全体にバインドされる OpenTracing ライブラリー から TracingFilter によって実行されます。@ Traced アノテーション をメソッドに追加すると、TracingInterceptor がトレーススパンを追加します。

4.6.1. タグ付け

スパンには、操作名、スパンオリジン、エラーなどの標準タグが含まれる場合があります。ワークスペース関連の操作(ワークスペースの開始や停止など)には、userId、workspaceID、stackId などの追加 タグがあり ます。TracingFilter によって作成さ れる スパンには HTTP ステータスコードタグもあります。

トレースされたメソッドでタグの宣言は、TracingTags クラス からフィールドを設定して静的に行われます。

TracingTags.WORKSPACE_ID.set(workspace.getId());
Copy to Clipboard Toggle word wrap

TracingTags は、各 AnnotationAware タグ 実装 として、一般的に使用されるすべてのタグが宣言されるクラスです。

その他のリソース

Jaeger UI の使用方法に関する詳細は、Jaeger ドキュメント「 Jaeger Getting Started Guide」 を参照してください。

第5章 ユーザーの管理

本セクションでは、Red Hat CodeReady Workspaces で承認および認証を設定する方法と、ユーザーグループおよびユーザーを管理する方法を説明します。

5.1. 承認の設定

5.1.1. 認可およびユーザー管理

Red Hat CodeReady Workspaces は RH-SSO を使用してユーザーの作成、インポート、管理、削除、および認証を行います。RH-SSO は、組み込みの認証メカニズムとユーザーストレージを使用します。サードパーティーの ID 管理システムを使用して、ユーザーを作成および認証することができます。CodeReady Workspaces リソースへのアクセスを要求する場合は、Red Hat CodeReady Workspaces に RH-SSO トークンが必要です。

ローカルユーザーとインポートされたフェデレーションユーザーがプロファイルにメールアドレスを持っている必要があります。

デフォルトの RH-SSO 認証情報は admin:admin です。Red Hat CodeReady Workspaces に初めてログインするときに admin:admin 認証情報を使用できます。システム権限があります。

手順

RH-SSO の URL を確認するには、以下を実行します。

  • OpenShift Web コンソールに移動し、RH-SSO プロジェクトに移動します。

5.1.2. RH-SSO を使用するための CodeReady Workspaces の設定

デプロイメントスクリプトは RH-SSO を設定します。以下のフィールドで che-public クライアントを作成します。

  • 有効なリダイレクト URI: この URL を使用して CodeReady Workspaces にアクセスします。
  • Web Origins

以下は、CodeReady Workspaces が RH-SSO と連携するように設定する場合の一般的なエラーです。

無効 redirectURI エラー: myhost で CodeReady Workspaces(エイリアス)にアクセスし、元の CODEREADY _HOST1.1.1.1 になると発生します。このエラーが発生した場合は、RH-SSO 管理コンソールに移動し、有効なリダイレクト URI が設定されていることを確認します。

CORS エラー: 無効な Web オリジンがある場合に発生します。

5.1.3. RH-SSO トークンの設定

ユーザートークンはデフォルトで 30 分後に有効期限が切れます。

以下の RH-SSO トークン設定を変更することができます。

Keycloak レルム

5.1.4. ユーザーフェデレーションの設定

RH-SSO は外部ユーザーデータベースをフェデレーションし、LDAP および Active Directory をサポートします。ストレージプロバイダーを選択する前に、接続をテストし、ユーザーを認証できます。

プロバイダーの追加方法について は、RH-SSO ドキュメントの User Storage フェデレーションページを参照してください。

RH-SSO ドキュメントの LDAP および Active Directory ページを参照して、複数の LDAP サーバーを指定します。

5.1.5. アカウントおよびブローカーによる認証の有効化

RH-SSO は、GitHub、OpenShift、および Twitter などの最も一般的なコミュニティーネットワークの組み込みサポートを提供します。

GitHub でのログインを有効にする 手順」を参照してください。

SSH キーを有効にし、CodeReady Workspaces ユーザーの GitHub アカウントにアップロードすることもできます。

GitHub アイデンティティープロバイダーの登録時にこの機能を有効にするには、以下を実行します。

  1. scope を repo,user,write:public_key に設定します。
  2. トークンおよび ON で読み取り可能な保存されたトークンを設定します。

    KC プロバイダー
  3. デフォルトの read-token ロールを追加します。

    KC ロール

これは、マルチユーザー CodeReady Workspaces のデフォルトの委譲 れた OAuth サービスモードです。OAuth サービスモードは、che.oauth.service_mode プロパティーで設定できます。

5.1.6. プロトコルベースのプロバイダーの使用

RH-SSO は SAML v2.0 プロトコルおよび OpenID Connect v1.0 プロトコルをサポートします。アイデンティティープロバイダーシステムがこれらのプロトコルに対応している場合は接続できます。

5.1.7. RH-SSO を使用したユーザーの管理

ユーザーインターフェースでユーザーを追加、削除、および編集できます。詳細は、「 RH-SSO User Management 」を参照してください。

5.1.8. SMTP およびメール通知の設定

Red Hat CodeReady Workspaces は、事前設定された MTP サーバーを提供しません。

RH-SSO で SMTP サーバーを有効にするには、以下を行います。

  1. che realm settings > Email の順に移動します。
  2. ホスト、ポート、ユーザー名、およびパスワードを指定します。

Red Hat CodeReady Workspaces は、登録、メールの確認、パスワードのリカバリー、および失敗したログインに、メールテンプレートにデフォルトのテーマを使用します。

5.2. ユーザーデータの削除

5.2.1. GDPR

ユーザーデータを削除する必要がある場合は、以下の API を ユーザー または 管理者 承認トークンと共に使用する必要があります。

curl -X DELETE `http(s)://{che-host}/api/user/{id}`
Copy to Clipboard Toggle word wrap
注記

ユーザーのワークスペースはすべて事前に停止する必要があります。そうでない場合は、API リクエストは 500 Error で失敗します。

すべてのユーザーのデータを削除するには、「 Red Hat CodeReady Workspaces のアンインストール 」の手順に従います。

第6章 CodeReady Workspaces のセキュリティー保護

本セクションでは、CodeReady Workspaces サーバーおよびそのワークスペースのユーザー認証、認証のタイプ、およびパーミッションモデルのあらゆる側面について説明します。

6.1. ユーザーの認証

本書では、CodeReady Workspaces サーバーとワークスペースの両方で、Red Hat CodeReady Workspaces でのユーザー認証のあらゆる側面について説明します。これには、すべての REST API エンドポイント、WebSocket または JSON RPC 接続、および一部の Web リソースのセキュリティー保護が含まれます。

すべての認証タイプは、ユーザー ID 情報を転送するためのコンテナーとして JWT オープン標準 を使用します。さらに、CodeReady Workspaces サーバー認証は、Keycloak によってデフォルトで提供される OpenID Connect プロトコル実装に基づいています。

ワークスペースでの認証は、ワークスペースごとに自己署名型の JWT トークンと、JWTProxy をベースとした専用のサービスで検証されることを意味し ます

6.1.1. CodeReady Workspaces サーバーへの認証

6.1.1.1. OpenID を使用した CodeReady Workspaces サーバーへの認証

CodeReady Workspaces サーバーの OpenID 認証は、外部 OpenID Connect プロバイダーが存在し、以下の主なステップを持つことを意味します。

  • HTTP リクエストから取得された JWT トークンを使用するか、トークンが見つからないか、無効な場合は、ユーザーを RH-SSO ログインページにリダイレクトします。
  • Authorization ヘッダーで認証トークンを送信します。一部のケースでは、Authorization ヘッダーを使用できない場合は、トークンをトークンクエリーパラメーターに送信できます。例: OAuth 認証の初期化
  • CodeReady Workspaces サーバーコード内の現在のユーザーを表す内部 サブジェクト オブジェクトを作成します。
注記

対応している OpenID プロバイダーのみが RH-SSO です。

手順

OpenID 認証を使用して CodeReady Workspaces サーバーへの認証を行うには、以下を実行します。

  1. OpenID 設定サービスをリクエストします。ここで 、クライアントが、JSON 形式で返される jwks.endpoint、token .endpointlogout.endpoint 、または client_id などの OpenId プロバイダーの必要な URL およびプロパティーをすべて検索できます。
  2. サービス URL は https://codeready-<openshift_deployment_name>.<domain_name>/api/keycloak/settings で、CodeReady Workspaces マルチユーザーモードでのみ利用できます。URL にサービスが存在すると、現在のデプロイメントで認証が有効になっていることを確認します。

    出力例:

    {
        "che.keycloak.token.endpoint": "http://172.19.20.9:5050/auth/realms/che/protocol/openid-connect/token",
        "che.keycloak.profile.endpoint": "http://172.19.20.9:5050/auth/realms/che/account",
        "che.keycloak.client_id": "che-public",
        "che.keycloak.auth_server_url": "http://172.19.20.9:5050/auth",
        "che.keycloak.password.endpoint": "http://172.19.20.9:5050/auth/realms/che/account/password",
        "che.keycloak.logout.endpoint": "http://172.19.20.9:5050/auth/realms/che/protocol/openid-connect/logout",
        "che.keycloak.realm": "che"
    }
    Copy to Clipboard Toggle word wrap

    このサービスは、JavaScript クライアントライブラリーをダウンロードし、https://codeready-<openshift_deployment_name>.<domain_name>/api/keycloak/OIDCKeycloak.js URL を使用してプロバイダーと対話 でき ます。

  3. client_id および return redirection パスを含む必要なパラメーターをすべて使用して、ユーザーを適切なプロバイダーのログインページにリダイレクトします。これは、すべてのクライアントライブラリー(JS または Java)で実行できます。
  4. ユーザーがプロバイダーにログインすると、クライアント側のサイドコードを取得し、JWT トークンがトークンを検証すると、サブジェクト の作成が開始されます。

トークン署名の検証は、以下の 2 つの手順で行われます。

  1. Authentication: トークンは Authorization ヘッダーまたはトークンクエリーパラメーターから抽出され、プロバイダーから取得さ た公開鍵を使用して解析されます。期限切れ、無効なトークン、または不適切な場合、403 エラーがユーザーに送信されます。今後のバージョンでのサポート制限や完全削除により、クエリーパラメーターの最小使用が推奨されます。

    検証に成功すると、トークンの解析形式は環境初期化ステップに渡されます。

  2. 環境の初期化 - フィルターは JWT トークンクレームからデータを抽出し、ローカルデータベースにユーザーを作成します(まだ利用できない場合は)、サブジェクト オブジェクトを構築し、これを各リクエストの EnvironmentContext オブジェクトに設定します。この オブジェクト は、どこにでもアクセスできます。

    リクエストが JWT トークンのみを使用して作成された場合、以下の単一の認証フィルターが使用されます。

    org.eclipse.che.multiuser.machine.machine.server.MachineLoginFilter: フィルターは userId トークン が属するユーザーを見つけ、ユーザーインスタンスを取得し、プリンシパルをセッションに設定します。CodeReady Workspaces のサーバー間の要求は、EnvironmentContext オブジェクト から取得した現在のサブジェクトトークンですべてのリクエストに署名する専用のリクエストファクトリーを使用して実行されます。

注記

ユーザー固有のデータの提供

RH-SSO は、ユーザー固有の情報(ファーストおよび姓、電話番号、ジョブタイトル)を保存する可能性があるため、このデータをコンシューマーに提供 できる ProfileDao には特別な実装があります。実装は読み取り専用であるため、ユーザーは作成および更新の操作を実行できません。

6.1.1.1.1. RH-SSO による認証情報からのトークンの取得

JavaScript やその他のクライアント(コマンドラインクライアントや Selenium テストなど)を実行できないクライアントは、RH-SSO から直接承認トークンを要求する必要があります。

トークンを取得するには、ユーザー名とパスワード認証情報でリクエストをトークンエンドポイントに送信します。このリクエストは、スキーマ的に以下の cURL リクエストとして記述できます。

$ curl --data "grant_type=password&client_id=<client_name>&username=<username>&password=<password>" \
  http://<keyckloak_host>:5050/auth/realms/<realm_name>/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

CodeReady Workspaces ダッシュボードは、カスタマイズされた RH-SSO ログインページと、grant_type=authorization_code に基づく認証メカニズムを使用します。これは 2 段階の認証プロセスです。

  1. ログインし、承認コードを取得します。
  2. この認可コードを使用したトークンの取得。
6.1.1.1.2. OpenShift トークンから RH-SSO を介したトークンの取得

CodeReady Workspaces が Operator を使用して OpenShift にインストールされ、OpenShift OAuth 統合がデフォルトで有効になると、ユーザーの CodeReady Workspaces 認証トークンをユーザーの OpenShift トークンから取得できます。

OpenShift トークンから認証トークンを取得するには、スキーマで記述された cURL リクエストを OpenShift トークンエンドポイントに送信します。

$ curl -X POST -d "client_id=<client_name>" \
--data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
-d "subject_token=<user_openshift_token>" \
 -d "subject_issuer=<openshift_identity_provider_name>" \
 --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
 http://<keyckloak_host>:5050/auth/realms/<realm_name>/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

<openshift_identity_provider_name> のデフォルト値は以下のとおりです。

  • On OpenShift 3.11: openshift-v3
  • OpenShift 4.x の場合: openshift-v4

<user_openshift_token> は、以下のコマンドで end-user によって取得されるトークンです。

$ oc whoami --show-token
Copy to Clipboard Toggle word wrap
警告

このトークン交換機能を使用する前に、エンドユーザーが OpenShift ログインページを使用して CodeReady Workspaces Dashboard に 1 回以上対話形式でログインする必要があります。このステップは、OpenShift および RH-SSO ユーザーアカウントを適切にリンクし、必要なユーザープロファイル情報を設定するために必要です。

6.1.1.2. 他の認証実装を使用した CodeReady Workspaces サーバーへの認証

この手順では、RH-SSO 以外の OpenID Connect(OIDC)認証実装を使用する方法を説明します。

手順

  1. multiuser.properties ファイル(クライアント ID、認証 URL、レルム名など)に保存されている認証設定パラメーターを更新します。
  2. 単一フィルターまたはフィルターチェーンを作成してトークンの検証、CodeReady Workspaces ダッシュボードでユーザーの作成、サブジェクト オブジェクトの作成。
  3. 新しい承認プロバイダーが OpenID プロトコルをサポートする場合は、特定の実装から切り離されたため、設定エンドポイントで利用可能な OIDC JS クライアントライブラリーを使用します。
  4. 選択したプロバイダーがユーザーに関する追加のデータ(最初の名およびジョブタイトル)を保存する場合は、この情報を提供するプロバイダー固有の ProfileDao 実装 を作成することが推奨されます。
6.1.1.3. OAuth を使用した CodeReady Workspaces サーバーへの認証

サードパーティーサービスとのユーザーによる対話を容易にするため、CodeReady Workspaces サーバーは OAuth 認証をサポートします。OAuth トークンは GitHub 関連のプラグインにも使用されます。

OAuth 認証には、RH-SSO ブローカーメカニズムに基づく 2 つの主要なフローがあります。以下は、2 つの主な OAuth API 実装です。

internal
org.eclipse.che.security.oauth.EmbeddedOAuthAPI
External
org.eclipse.che.multiuser.keycloak.server.oauth2.DelegatedOAuthAPI

2 つの実装を切り替えるには、che.oauth.service_mode=<embedded|delegated> 設定プロパティーを使用します。

OAuth API の主な REST エンドポイントは、以下を含む org.eclipse.che.security.oauth. OAuthAuthenticationService です。

  • OAuth 認証フローが起動する認証方法。
  • プロバイダーからのコールバックを処理するコールバックメソッド。
  • 現在のユーザーの OAuth トークンを取得するトークン。

これらのメソッドは、現在アクティベートされ、埋め込みまたは委譲された OAuthAPI に適用されます。その後、OAuthAPI は以下の基礎となる操作を提供します。

  • 適切なオーセンティケーターを見つけます。
  • ログインプロセスを初期化します。
  • ユーザーの転送
6.1.1.4. Swagger または REST クライアントを使用したクエリーの実行

ユーザーの RH-SSO トークンは、REST クライアントを介してユーザーのセキュアな API に対してクエリーを実行するために使用されます。有効なトークンは Request ヘッダーまたは ?token=$token クエリーパラメーターとして割り当てる必要があります。

https://codeready-<openshift_deployment_name>.<domain_name>/swagger で CodeReady Workspaces Swagger インターフェースにアクセスし ます。アクセストークンが Request ヘッダーに含まれるように、ユーザーは RH-SSO を介して署名する必要があります。

6.1.2. CodeReady Workspaces ワークスペースでの認証

ワークスペースコンテナーには、認証で保護する必要のあるサービスが含まれる場合があります。このような保護されているサービスは、セキュア と呼ばれます。これらのサービスのセキュリティーを保護するには、マシン認証メカニズムを使用します。

JWT トークンは、RH-SSO トークンをワークスペースコンテナーに渡す必要がありません(安全でない可能性があります)。また、RH-SSO トークンの有効期間は比較的短く、定期的な更新や更新が必要になる場合があります。これは、クライアントの同じユーザーセッショントークンの管理および同期が困難です。

図6.1 ワークスペース内の認証

ワークスペース内の CRW 認証
6.1.2.1. セキュアなサーバーの作成

CodeReady Workspaces ワークスペースでセキュアなサーバーを作成するには、devfile の dockerimage タイプ のコンポーネントでエンドポイントの secure 属性を true に設定します。

セキュアなサーバー用の devfile スニペット

components:
  - type: dockerimage
    endpoints:
      - attributes:
          secure: 'true'
Copy to Clipboard Toggle word wrap

6.1.2.2. workspace JWT token

ワークスペーストークンは、要求に以下の情報が含まれる JSON Web トークン(JWT)です。

  • UID: このトークンを所有するユーザーの ID
  • Uname: このトークンを所有するユーザーの名前
  • wsid: このトークンでクエリーできるワークスペースの ID

各ユーザーは、各ワークスペースに一意の個人トークンが提供されます。トークンと署名の構造は、RH-SSO とは異なります。トークンビューの例を以下に示します。

# Header
{
  "alg": "RS512",
  "kind": "machine_token"
}
# Payload
{
  "wsid": "workspacekrh99xjenek3h571",
  "uid": "b07e3a58-ed50-4a6e-be17-fcf49ff8b242",
  "uname": "john",
  "jti": "06c73349-2242-45f8-a94c-722e081bb6fd"
}
# Signature
{
  "value": "RSASHA256(base64UrlEncode(header) + . +  base64UrlEncode(payload))"
}
Copy to Clipboard Toggle word wrap

RSA アルゴリズムを使用した SHA-256 暗号は、JWT トークンの署名に使用されます。設定することはできません。また、トークンが署名されるキーペアの公開部分を配布するパブリックサービスはありません。

6.1.2.3. マシントークンの検証

マシントークン(JWT トークン)の検証は、別の Pod の JWTProxy で実行される専用のワークスペースサービスを使用して 実行 されます。ワークスペースが起動すると、このサービスは CodeReady Workspaces サーバーから SHA キーの公開部分を受け取ります。セキュアなサーバーごとに個別の検証エンドポイントが作成されます。トラフィックがエンドポイントに到達すると、JWTProxy はクッキーまたはヘッダーからトークンを 抽出 し、公開鍵の部分を使用して検証します。

CodeReady Workspaces サーバーにクエリーを行うには、ワークスペースサーバーは CHE _MACHINE_TOKEN 環境変数で提供されるマシントークンを使用できます。このトークンは、ワークスペースを起動したユーザーのものです。このような要求の範囲は、現在のワークスペースのみに制限されます。許可される操作のリストは厳密に制限されます。

6.2. ユーザーの承認

CodeReady Workspaces のユーザー認可は、パーミッションモデルに基づいています。パーミッションは、ユーザーの許可されたアクションを制御し、セキュリティーモデルを確立するために使用されます。すべての要求は、認証後に現在のユーザーサブジェクトに必要なパーミッションが存在するかどうかを検証します。CodeReady Workspaces が管理するリソースを制御し、ユーザーにパーミッションを割り当てることで特定のアクションを許可します。

パーミッションは以下のエンティティーに適用できます。

  • workspace
  • system

すべてのパーミッションは、提供される REST API を使用して管理できます。API は https://codeready-<openshift_deployment_name>.<domain_name>/swagger/#!/permissions の Swagger を使用して文書化されて ます。

6.2.1. CodeReady Workspaces ワークスペースパーミッション

ワークスペースを作成するユーザーはワークスペースの所有者です。デフォルトでは、ワークスペースの所有者には、読み取り使用実行、設定、パーミッションの 設定 および 削除 の権限があります。ワークスペースの所有者は、ユーザーをワークスペースに招待し、他のユーザーに対するワークスペースパーミッションを制御できます。

以下のパーミッションはワークスペースに関連付けられます。

Expand
表6.1 CodeReady Workspaces ワークスペースパーミッション
permissiondescription

read

ワークスペース設定の読み取りを許可します。

使用方法

ワークスペースを使用し、これと対話することを許可します。

run

ワークスペースを開始および停止できます。

設定

ワークスペース設定の定義と変更を可能にします。

setPermissions

他のユーザーに対してワークスペースのアクセス権を更新できます。

DELETE

ワークスペースの削除を許可します。

6.2.2. CodeReady Workspaces のシステムのパーミッション

CodeReady Workspaces システムパーミッションは、CodeReady Workspaces インストール全体の機能を制御します。システムには、以下の権限が適用されます。

Expand
表6.2 CodeReady Workspaces システムパーミッション
permissiondescription

manageSystem

システムおよびワークスペースを制御できます。

setPermissions

システムのユーザー権限を更新できます。

manageUsers

ユーザーの作成および管理を許可します。

monitorSystem

サーバーの状態の監視に使用されるエンドポイントへのアクセスを許可します。

すべてのシステム権限は、CHE _SYSTEM_ADMIN__NAME プロパティー(デフォルトは admin)で設定されている管理ユーザーに付与されます。CodeReady Workspaces サーバーの起動時にシステムのパーミッションが付与されます。CodeReady Workspaces ユーザーデータベースにユーザーがない場合は、最初のユーザーがログインした後に発生します。

6.2.3. manageSystem permission

manageSystem 権限 を持つユーザーは、以下のサービスにアクセスできます。

Expand
パスHTTP メソッドdescription

/resource/free/

GET

空きのリソース制限を取得します。

/resource/free/{accountId}

GET

指定のアカウントの空きリソース制限を取得します。

/resource/free/{accountId}

POST

指定のアカウントの空きリソース制限を編集します。

/resource/free/{accountId}

DELETE

指定のアカウントの空きリソース制限を削除します。

/installer/

POST

インストーラーをレジストリーに追加します。

/installer/{key}

PUT

レジストリーでインストーラーを更新します。

/installer/{key}

DELETE

レジストリーからインストーラーを削除します。

/logger/

GET

CodeReady Workspaces サーバーでロギング設定を取得します。

/logger/{name}

GET

CodeReady Workspaces サーバーでロガーの設定を取得します。

/logger/{name}

PUT

CodeReady Workspaces サーバーでロガーを作成します。

/logger/{name}

POST

CodeReady Workspaces サーバーのロガーを編集します。

/resource/{accountId}/details

GET

指定のアカウントのリソースの詳細情報を取得します。

/system/stop

POST

すべてのシステムサービスをシャットダウンし、停止する CodeReady Workspaces を準備します。

6.2.4. monitorSystem permission

monitorSystem 権限 を持つユーザーは、以下のサービスにアクセスできます。

Expand
パスHTTP メソッドdescription

/activity

GET

一定期間、特定の状態でワークスペースを取得します。

6.2.5. CodeReady Workspaces パーミッションの一覧表示

特定の リソース に適用する CodeReady Workspaces パーミッションを一覧表示するには、GET /permissions 要求を実行します。

ユーザー に適用されるパーミッションを一覧表示するには、GET /permissions/{domain} 要求を実行します。

すべてのユーザー に適用されるパーミッションを一覧表示するには、GET /permissions/{domain}/all 要求を実行します。この情報を表示するには、ユーザーが manageSystem パーミッションを持っている必要があります。

適切なドメイン値は以下のとおりです。

  • system
  • organization
  • workspace
注記

ドメインは任意です。ドメインが指定されていない場合、API はすべてのドメインに対して可能なすべてのパーミッションを返します。

6.2.6. CodeReady Workspaces パーミッションの割り当て

リソースにパーミッションを割り当てるには、POST /permissions リクエストを実行します。適切なドメイン値は以下のとおりです。

  • system
  • organization
  • workspace

以下は、userId を使用するユーザーのパーミッションを workspaceID を持つ ワークス ペースに要求するメッセージボディー です

CodeReady Workspaces ユーザーパーミッションの要求

{
  "actions": [
    "read",
    "use",
    "run",
    "configure",
    "setPermissions"
  ],
  "userId": "userID",          
1

  "domainId": "workspace",
  "instanceId": "workspaceID"  
2

}
Copy to Clipboard Toggle word wrap

1
userId パラメーター は、特定のパーミッションが付与されたユーザーの ID です。
2
instanceId パラメーター は、すべてのユーザーのパーミッションを取得するリソースの ID です。

6.2.7. CodeReady Workspaces パーミッションの共有

setPermissions 権限を持つ ユーザー は、ワークスペースを共有でき、他のユーザーに対して 読み取り使用実行設定、またはパーミッションの 特権 を付与できます。

手順

ワークスペースのパーミッションを共有するには、以下を実行します。

  1. ユーザーダッシュボードでワークスペースを選択します。
  2. Share タブに移動し、ユーザーのメール ID を入力します。複数のメールの区切り文字としてコンマまたはスペースを使用します。

第7章 バックアップおよび障害復旧

このセクションでは、CodeReady Workspaces のバックアップおよび障害復旧を説明します。

7.1. 外部データベースの設定

PostgreSQL データベースは、CodeReady Workspaces の状態に関するデータを永続化するために CodeReady Workspaces サーバーによって使用されます。これには、ユーザーアカウント、ワークスペース、設定などの情報が含まれます。

デフォルトでは、CodeReady Workspaces Operator はデータベースデプロイメントを作成し、管理します。

ただし、CodeReady Workspaces Operator はバックアップやリカバリーなどの完全なライフサイクル機能をサポートしません。

ビジネスクリティカルなセットアップでは、以下の推奨される障害復旧オプションを使用して外部データベースを設定します。

  • 高可用性(HA)
  • point In Time Recovery(PITR)

オンプレミスの外部 PostgreSQL インスタンスを設定するか、Amazon relationshipal Database Service(Amazon RDS)などのクラウドサービスを使用します。Amazon RDS では、毎日およびオンデマンドのスナップショットを使用して、回復性のある障害復旧ストラテジーのマルチアベイラビリティーゾーン設定に実稼働データベースをデプロイすることができます。

データベース例の推奨設定は以下のとおりです。

Expand
パラメーター

インスタンスクラス

db.t2.small

vCPU

1

RAM

2 GB

multi-az

True、2 つのレプリカ

エンジンバージョン

9.6.11

TLS

enabled

自動バックアップ

有効(30 日)

7.1.1. 外部 PostgreSQL の設定

手順

  1. 以下の SQL スクリプトを使用して、CodeReady Workspaces サーバーのユーザーとデータベースを作成してワークスペースメタデータを永続化します。

    CREATE USER <database-user> WITH PASSWORD '<database-password>' 
    1
     
    2
    
    CREATE DATABASE <database>                                      
    3
    
    GRANT ALL PRIVILEGES ON DATABASE <database> TO <database-user>
    ALTER USER <database-user> WITH SUPERUSER
    Copy to Clipboard Toggle word wrap
    1
    CodeReady Workspaces サーバーデータベースのユーザー名
    2
    CodeReady Workspaces サーバーのデータベースのパスワード
    3
    CodeReady Workspaces サーバーデータベース名
  2. 以下の SQL スクリプトを使用して、RH-SSO バックエンドのデータベースを作成し、ユーザー情報を永続化します。

    CREATE USER <identity-database-user> WITH PASSWORD '<identity-database-password>' 
    1
     
    2
    
    CREATE DATABASE <identity-database>                                               
    3
    
    GRANT ALL PRIVILEGES ON DATABASE <identity-database> TO <identity-database-user>
    Copy to Clipboard Toggle word wrap
    1
    RH-SSO データベースのユーザー名
    2
    RH-SSO データベースのパスワード
    3
    RH-SSO データベース名

7.1.2. 外部 PostgreSQL と連携するように CodeReady Workspaces の設定

前提条件

  • oc ツールが利用可能である。

手順

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

    $ oc create project workspaces
    Copy to Clipboard Toggle word wrap
  2. CodeReady Workspaces サーバーデータベースの認証情報を保存するシークレットを作成します。

    $ oc create secret generic <server-database-credentials> \ 
    1
    
    --from-literal=user=<database-user> \                            
    2
    
    --from-literal=password=<database-password> \                    
    3
    
    -n workspaces
    Copy to Clipboard Toggle word wrap
    1
    CodeReady Workspaces サーバーデータベースのクレデンシャルを保存するシークレット名
    2
    CodeReady Workspaces サーバーデータベースのユーザー名
    3
    CodeReady Workspaces サーバーのデータベースのパスワード
  3. RH-SSO データベースの認証情報を保存するシークレットを作成します。

    $ oc create secret generic <identity-database-credentials> \ 
    1
    
    --from-literal=user=<identity-database-user> \                     
    2
    
    --from-literal=password=<identity-database-password> \             
    3
    
    -n workspaces
    Copy to Clipboard Toggle word wrap
    1
    RH-SSO データベースの認証情報を保存するシークレット名
    2
    RH-SSO データベースのユーザー名
    3
    RH-SSO データベースのパスワード
  4. Operator にデータベースのデプロイを省略し、既存のデータベースの接続詳細を CodeReady Workspaces サーバーに渡させるには、カスタムリソースに以下の値を設定します。

    spec:
      database:
        externalDb: true
        chePostgresHostName: <hostname>                     
    1
    
        chePostgresPort: <port>                             
    2
    
        chePostgresSecret: <server-database-credentials>    
    3
    
        chePostgresDb: <database>                           
    4
    
    spec:
      auth:
        identityProviderPostgresSecret: <identity-database-credentials> 
    5
    Copy to Clipboard Toggle word wrap
    1
    外部データベースのホスト名
    2
    外部データベースポート
    3
    CodeReady Workspaces サーバーデータベースのクレデンシャルのあるシークレット名
    4
    CodeReady Workspaces サーバーデータベースのユーザー名
    5
    RH-SSO データベースのクレデンシャルのあるシークレット名

その他のリソース

7.2. 永続ボリュームのバックアップ

永続ボリューム(PV)は、CodeReady Workspaces ワークスペースデータをローカルのハードドライブのデスクトップ IDE に保存する方法と同様に CodeReady Workspaces ワークスペースデータを格納します。

データの損失を防ぐには、PV を定期的にバックアップします。PV を含む OpenShift リソースのバックアップおよび復元には、ストレージに依存しないツールを使用することが推奨されます。

第8章 CodeReady Workspaces リソース要件の計算

このセクションでは、Red Hat CodeReady Workspaces の実行に必要なリソース(メモリーおよび CPU)を計算する方法を説明します。

8.1. CodeReady Workspaces アーキテクチャーコンポーネント

ハイレベル CodeReady Workspaces アーキテクチャー の記事で説明されているように、Red Hat CodeReady Workspaces コンポーネントは次のとおりです。

  • 中央ワークスペースコントローラー: ユーザーワークスペースを管理する常に実行中のサービス
  • ユーザーワークスペース: ユーザーがコーディングを停止すると、コントローラーが停止するコンテナーベースの IDE。
CRW 高レベル

CodeReady Workspaces 中央コントローラーとユーザーワークスペースはいずれもコンテナーセットで構成されます。これらのコンテナーは、CPU、RAM の制限および要求に関するリソース消費に貢献します。OpenShift による container-resource 要求および制限の管理方法に関する詳細は、OpenShift ドキュメントを参照してください

8.2. コントローラーの要件

Workspace Controller は、5 つの異なるコンテナーで実行される 5 つのサービスで構成されます。以下の表は、これらの各サービスのデフォルトリソース要件を示しています。

Expand
表8.1 ControllerServices
Podコンテナー名デフォルトのメモリー制限デフォルトのメモリー要求

CodeReady Workspaces サーバーおよびダッシュボード

che

1 GiB

512 MiB

PostgreSQL

postgres

1 GiB

512 MiB

Red Hat Single Sign-On

keycloak

2 GiB

512 MiB

devfile レジストリー

che-devfile-registry

256 MiB

16 MiB

プラグインレジストリー

che-plugin-registry

256 MiB

16 MiB

CodeReady Workspaces Workspace Controller が小規模な CodeReady Workspaces ワークスペースを管理する場合は、これらのデフォルト値で十分です。大規模なデプロイメントの場合は、メモリー制限を増やします。デフォルトのリクエストおよび制限を上書きする方法は、高度な設定オプション のアーティクルを参照してください。たとえば、che.openshift.io で実行されるホスト型 CodeReady Workspaces バージョンは 1 GB のメモリーを使用します。

8.3. ワークスペースの要件

本セクションでは、ワークスペースに必要なリソースを計算する方法を説明します。これは、このワークスペースの各コンポーネントに必要なリソースの合計です。

以下の例は、適切な計算の必要性を示しています。

  • 10 個のアクティブなプラグインを持つワークスペースでは、より多くのリソースが必要となり、プラグインが少ない同じワークスペースが必要になります。
  • ビルド、テスト、およびアプリケーションのデバッグを実行するには、標準の Java ワークスペースよりも多くのリソースが必要です。

手順

  1. devfilecomponents セクションで明示的に指定するワークスペースコンポーネントを特定します。
  2. 暗黙的なワークスペースコンポーネントを特定します。

    1. CodeReady Workspaces は、デフォルトの cheEditor : che-theia、 およびコマンドの実行を可能に する chePlugin を暗黙的にロードします( che-machine-exec-plugin )。デフォルトエディターを変更するには、devfile に cheEditor コンポーネントセクションを追加します。
    2. CodeReady Workspaces がマルチユーザーモードで稼働している場合、JWT プロキシーコンポーネントをロードし ます。JWT プロキシー は、ワークスペースコンポーネントの外部通信の認証および承認を行います。
  3. 各コンポーネントの要件を計算します。

    1. デフォルト値:

      以下の表は、すべてのワークスペースコンポーネントのデフォルト要件を示しています。また、クラスター全体でデフォルトを変更するために、対応する CodeReady Workspaces サーバープロパティーも表示します。

      Expand
      表8.2 タイプ別のワークスペースコンポーネントのデフォルト要件
      コンポーネントのタイプCodeReady Workspaces サーバープロパティーデフォルトのメモリー制限デフォルトのメモリー要求

      chePlugin

      che.workspace.sidecar.default_memory_limit_mb

      128 MiB

      128 MiB

      cheEditor

      che.workspace.sidecar.default_memory_limit_mb

      128 MiB

      128 MiB

      Kubernetesopenshiftdockerimage

      che.workspace.default_memory_limit_mb, che.workspace.default_memory_request_mb

      1 Gi

      512 MiB

      JWT Proxy

      che.server.secure_exposer.jwtproxy.memory_limit

      128 MiB

      128 MiB

    2. chePlugins および cheEditors コンポーネント のカスタム要件:

      1. カスタムのメモリー制限および要求:

        存在する場合、meta .yaml ファイルの containers セクションの memoryLimit および memoryRequest 属性 は、chePlugins または cheEditors コンポーネントのメモリー制限を定義 ます。CodeReady Workspaces は、明示的に指定されていない場合にメモリー制限と一致するようにメモリー要求を自動的に設定します。

        例8.1 The chePlugin che-incubator/typescript/latest

        meta.yaml 仕様セクション:

        spec:
         containers:
           - image: docker.io/eclipse/che-remote-plugin-node:next
             name: vscode-typescript
             memoryLimit: 512Mi
             memoryRequest: 256Mi
        Copy to Clipboard Toggle word wrap

        これにより、コンテナーに以下のメモリー制限および要求が生じます。

        Expand

        メモリー制限

        512 MiB

        メモリー要求

        256 MiB

        ヒント

        chePlugin の meta.yaml ファイルを見つける方法

        コミュニティープラグインは、v3/plugins/${organization}/${name}/${version}/ フォルダーの che-plugin-registry GitHub リポジトリー で利用できます。

        非コミュニティーまたはカスタマイズされたプラグインの場合、meta.yaml ファイルは${pluginRegistryEndpoint }/v3/plugins/${Orgization}/${name}/${version}/meta.yaml のローカル OpenShift クラスターで利用できます。

        たとえば、ローカルの Minikube クラスターでは、che-incubator/typescript/latest meta.yaml の URL は http://plugin-registry-che.192.168.64.78.mycluster.mycompany.com/v3/plugins/che-incubator/typescript/latest/meta.yaml です

      2. カスタム CPU の制限および要求:

        CodeReady Workspaces はデフォルトで CPU の制限および要求を設定しません。ただし、meta.yaml ファイルの chePlugin および cheEditor タイプ の CPU 制限を設定することもできます。また、メモリー制限の場合と同じように、devfile で CPU 制限を設定することができます。

        例8.2 The chePlugin che-incubator/typescript/latest

        meta.yaml 仕様セクション:

        spec:
         containers:
           - image: docker.io/eclipse/che-remote-plugin-node:next
             name: vscode-typescript
             cpuLimit: 2000m
             cpuRequest: 500m
        Copy to Clipboard Toggle word wrap

        これにより、コンテナーに以下の CPU 制限および要求が生じます。

        Expand

        CPU の制限

        2 コア

        CPU 要求

        0.5 コア

CPU の制限および要求をグローバルに設定するには、以下の専用の環境変数を使用します。

Expand

CPU の制限

CHE_WORKSPACE_SIDECAR_DEFAULT__CPU__LIMIT__CORES

CPU 要求

CHE_WORKSPACE_SIDECAR_DEFAULT__CPU__REQUEST__CORES

CodeReady Workspaces サーバーコンポーネントの高度な設定オプション」も参照し てください。

OpenShift プロジェクトの LimitRange オブジェクトは、クラスター管理者によって設定される CPU 制限および要求のデフォルト値を指定する可能性があることに注意してください。リソースのオーバーランにより開始エラーが発生しないようにするには、アプリケーションレベルまたはワークスペースレベルの制限がこれらの設定に準拠する必要があります。

  1. dockerimage コンポーネントの カスタム 要件

    存在する場合、devfile の memoryLimit 属性 および memoryRequest 属性は dockerimage コンテナーのメモリー制限を定義 ます。CodeReady Workspaces は、明示的に指定されていない場合にメモリー制限と一致するようにメモリー要求を自動的に設定します。

      - alias: maven
        type: dockerimage
        image: eclipse/maven-jdk8:latest
        memoryLimit: 1536M
    Copy to Clipboard Toggle word wrap
  2. kubernetes または openshift コンポーネントのカスタム要件:

    参照されるマニフェストは、メモリーの要件および制限を定義する可能性があります。

    1. 以前に計算された要件をすべて追加します。

8.4. ワークスペースの例

このセクションでは、CodeReady Workspaces ワークスペースの例を説明します。

以下の devfile は CodeReady Workspaces ワークスペースを定義します。

apiVersion: 1.0.0
metadata:
 generateName: guestbook-nodejs-sample-
projects:
 - name: guestbook-nodejs-sample
   source:
     type: git
     location: "https://github.com/l0rd/nodejs-sample"
components:
 - type: chePlugin
   id: che-incubator/typescript/latest
 - type: kubernetes
   alias: guestbook-frontend
   reference: https://raw.githubusercontent.com/l0rd/nodejs-sample/master/kubernetes-manifests/guestbook-frontend.deployment.yaml
   mountSources: true
   entrypoints:
     - command: ['sleep']
       args: ['infinity']
Copy to Clipboard Toggle word wrap

この表には、各ワークスペースコンポーネントのメモリー要件が記載されています。

Expand
表8.3 ワークスペースのメモリー要件および制限の合計
Podコンテナー名デフォルトのメモリー制限デフォルトのメモリー要求

workspace

Theia-ide(デフォルト cheEditor

512 MiB

512 MiB

workspace

machine-exec (default chePlugin)

128 MiB

128 MiB

workspace

vscode-typescript (chePlugin)

512 MiB

512 MiB

workspace

frontend(kubernetes)

1 GiB

512 MiB

JWT Proxy

Verifier

128 MiB

128 MiB

Total

2.25 GiB

1.75 GiB

  • devfile に含まれていない場合でも、theia -ide および machine-exec コンポーネントはワークスペースに暗黙的に追加されます。
  • machine-exec で必要なリソースが chePlugin のデフォルト です
  • theia -ide の リソースは、cheEditormeta.yamlmemoryLimit として 512 MiB に設定され ます
  • Typescript VS Code 拡張機能もデフォルトのメモリー制限を上書きしています。meta.yaml ファイルで制限は 512 MiB に明示的に指定されます。
  • CodeReady Workspaces は、kubernetes コンポーネントタイプのデフォルト( 1 GiB のメモリー制限、512 MiB のメモリー要求)を適用しています。これは、kubernetes コンポーネントはリソースの制限や要求のないコンテナー仕様を持つ Deployment マニフェストを参照するためです。
  • JWT コンテナーには 128 MiB のメモリーが必要です。

これらを一緒に追加すると、1.75 GiB のメモリー要求は 2.25 GiB の制限となります。

8.5. その他のリソース

第9章 イメージをキャッシュしてワークスペースを迅速に開始

このセクションでは、CodeReady Workspaces クラスターに Image Puller をインストールして、クラスターノードのイメージをキャッシュする方法を説明します。

9.1. Image Puller の概要

Red Hat CodeReady Workspaces ワークスペースの開始が遅いのは、基礎となるクラスターがリモートレジストリーからワークスペースで使用されるイメージをプルするのを待機することで生じる可能性があります。したがって、プルーニング前のイメージは、開始時間を大幅に向上させることができます。Image Puller は、イメージを事前にプルし、ワークスペースの起動時間を短縮するために使用できます。

Image Puller は、Red Hat CodeReady Workspaces とともに実行される追加のデプロイメントです。事前にプルするイメージの一覧が指定される場合、アプリケーションはクラスター内で実行され、各ノードのイメージをプルする DaemonSet を作成します。

注記

事前にローテーションされる イメージの最低要件は、sleep コマンドの可用性です。つまり、FROM スクラッチイメージ(例: 'che-machine-exec')はサポートされていません。また、Dockerfile にボリュームをマウントするイメージは、OpenShift の事前に解析の対象外となります。

アプリケーションはデプロイできます。

イメージプルーナーは、以下の利用可能なパラメーターで ConfigMap から設定をロードします。

Expand
表9.1 Image Puller のデフォルトパラメーター
パラメーター使用方法デフォルト

CACHING_INTERVAL_HOURS

DaemonSet の正常性を確認する間隔(時間単位)

"1"

CACHING_MEMORY_REQUEST

プルーラーの実行時のキャッシュされた各イメージのメモリー要求

10Mi

CACHING_MEMORY_LIMIT

プルーラーの実行時のキャッシュされた各イメージのメモリー制限

20mi

CACHING_CPU_REQUEST

プルーラーの実行時のキャッシュされた各イメージの CPU 要求

.05

CACHING_CPU_LIMIT

プルーラーの実行時のキャッシュされた各イメージの CPU 制限

.2

DAEMONSET_NAME

作成する DaemonSet の名前

kubernetes-image-puller

NAMESPACE

DaemonSet を作成する namespace

k8s-image-puller

イメージ

キャッシュされるイメージの一覧(形式: <name>=<image>;…​

イメージのデフォルト一覧が含まれます。デプロイする前に、現在の要件に合致するイメージでこれを記入してください。

NODE_SELECTOR

DaemonSet によって作成される Pod に適用されるノードセレクター

'{}'

デフォルトのメモリー要求および制限により、コンテナーに十分なメモリーがあることを確認します。CACHING _MEMORY_REQUEST または CACHING_MEMORY _LIMIT を変更する場合、クラスター内の DaemonSet Pod に割り当てられるメモリーの合計を考慮する必要があります。

(メモリー制限)*(イメージの数)*(クラスター内のノード数)

たとえば、コンテナーメモリーの制限が 20Mi の場合に 5 つのイメージをキャッシュするイメージプルーナーを実行するには、2000 Mi のメモリーが必要です。

9.2. Operator を使用したイメージプルのデプロイ

Image Puller をデプロイする方法として Operator を使用することが推奨されます。

9.2.1. OperatorHub を使用した OpenShift へのイメージプルのインストール

前提条件

  • イメージプルーラーをホストするためのクラスター内のプロジェクト。本書では、例としてプロジェクト image-puller を使用します。

手順

  1. OpenShift クラスターコンソールに移動し、OperatorsOperatorHub に移動します。
  2. Filter by keyword ボックスを使用して OpenShift Image Puller Operator を検索します。OpenShift Image Puller Operator をクリックします。
  3. Operator の説明を確認します。Continue → Install を クリックし ます。
  4. Installation Mode について A specific project on the cluster を選択します。ドロップダウンで、イメージプルーナーをインストールするために作成したプロジェクトを見つけます。Subscribe をクリックします。
  5. Image Puller Operator のインストールを待ちます。OpenShiftImagePuller → Create instance をクリックします。
  6. YAML エディターでリダイレクトされたウィンドウで、OpenShiftImagePuller カスタム リソースに変更し、Create をクリックします。
  7. プロジェクトの Workloads および Pods メニューに移動し、イメージプルーダーがインストールされていることを確認します。

9.3. OpenShift テンプレートを使用したイメージプルのデプロイ

Image Puller リポジトリーには、OpenShift にデプロイする OpenShift テンプレートが含まれます。

前提条件

  • 稼働中の OpenShift クラスター。
  • oc ツールが利用可能である。

OpenShift テンプレートをさらに設定するには、以下のパラメーターを使用できます。

Expand
表9.2 OpenShift テンプレートでインストールするためのパラメーター
使用方法デフォルト

DAEMONSET_NAME

ConfigMap に設定する DAEMONSET_NAME の値

kubernetes-image-puller

IMAGE

kubernetes-image-puller デプロイメントに使用されるイメージ

registry.redhat.io/codeready-workspaces/imagepuller-rhel8:2.3

IMAGE_TAG

プルするイメージタグ

2.3

SERVICEACCOUNT_NAME

デプロイメントで使用する ServiceAccount の名前(インストールの一部として作成される)

k8s-image-puller

CACHING_INTERVAL_HOURS

ConfigMap に設定する CACHING _INTERVAL_HOURS の値

"1"

CACHING_INTERVAL_REQUEST

ConfigMap に設定する CACHING _MEMORY_REQUEST の値

"10mi"

CACHING_INTERVAL_LIMIT

ConfigMap に設定される CACHING _MEMORY_LIMIT の値

"20Mi"`

NODE_SELECTOR

ConfigMap に設定する NODE_ SELECTOR の値

"{}"

DAEMONSET _NAME、CACHING_ INTERVAL_HOURS、および CACHING_ MEMORY_REQUEST などの設定値の 表9.1「Image Puller のデフォルトパラメーター」 詳細は、を参照してください。

Expand
表9.3 pre-pull に推奨されるイメージの一覧
imageURLtag

theia-rhel8

codeready-workspaces/theia-rhel8

2.3

theia-endpoint-rhel8

theia-endpoint-image

2.3

machineexec-rhel8

registry.redhat.io/codeready-workspaces/machineexec-rhel8:2.3

2.3

pluginbroker-metadata-rhel8

registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:2.3

2.3

pluginbroker-artifacts-rhel8

registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:2.3

2.3

plugin-java8-rhel8

registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:2.3

2.3

plugin-java11-rhel8

registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:2.3

2.3

plugin-kubernetes-rhel8

registry.redhat.io/codeready-workspaces/plugin-kubernetes-rhel8:2.3

2.3

plugin-openshift-rhel8

registry.redhat.io/codeready-workspaces/plugin-openshift-rhel8:2.3

2.3

stacks-cpp-rhel8

registry.redhat.io/codeready-workspaces/stacks-cpp-rhel8:2.3

2.3

stacks-dotnet-rhel8

registry.redhat.io/codeready-workspaces/stacks-dotnet-rhel8:2.3

2.3

stacks-golang-rhel8

registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:2.3

2.3

stacks-php-rhel8

registry.redhat.io/codeready-workspaces/stacks-php-rhel8:2.3

2.3

DAEMONSET _NAME、CACHING_ INTERVAL_HOURS、および CACHING_ MEMORY_REQUEST などの設定値の 表9.1「Image Puller のデフォルトパラメーター」 詳細は、を参照してください。

手順

インストール

  1. kubernetes-image-puller リポジトリーのクローンを作成します。

    $ git clone https://github.com/che-incubator/kubernetes-image-puller
    $ cd kubernetes-image-puller
    Copy to Clipboard Toggle word wrap
  2. プルーナーをデプロイするために新規の OpenShift プロジェクトを作成します。

    $ oc new-project k8s-image-puller
    Copy to Clipboard Toggle word wrap
  3. テンプレートをプロセスし、プルーナーをデプロイします。

    CodeReady Workspaces では、カスタム値を使用してイメージプルーラーをデプロイする必要があります。カスタム値を設定するには、-p <parameterName> =<value> オプションの oc プロセス に追加します。

    $ oc process -f deploy/serviceaccount.yaml \
        | oc apply -f -
    $ oc process -f deploy/configmap.yaml \
        -p IMAGES='plugin-java8-rhel8=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:2.3;\
        theia-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:2.3;\
        stacks-golang-rhel8=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:2.3;\
        plugin-java11-rhel8=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:2.3;\
        theia-endpoint-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:2.3;\
        pluginbroker-metadata-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:2.3;\
        pluginbroker-artifacts-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:2.3;' \
        | oc apply -f -
    $ oc process -f deploy/app.yaml \
        -p IMAGE=registry.redhat.io/codeready-workspaces/imagepuller-rhel8 \
        -p IMAGE_TAG='2.3' \
        | oc apply -f -
    Copy to Clipboard Toggle word wrap

インストールの確認

  1. 新規デプロイメント kubernetes-image-puller および DaemonSet(DAEMONSET _NAME パラメーターの値に基づいて名前が指定)が存在する ことを確認します。DeamonSet には、クラスター内の各ノードに Pod が必要です。

    $ oc get deployment,daemonset,pod --namespace k8s-image-puller
    deployment.extensions/kubernetes-image-puller   1/1       1            1           2m19s
    
    NAME                                           DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.extensions/kubernetes-image-puller   1         1         1         1            1           <none>          2m10s
    
    NAME                                           READY     STATUS    RESTARTS   AGE
    pod/kubernetes-image-puller-5495f46497-mkd4p   1/1       Running   0          2m18s
    pod/kubernetes-image-puller-n8bmf              3/3       Running   0          2m10s
    Copy to Clipboard Toggle word wrap
  2. k8s-image-puller という名前の ConfigMap に、パラメーターの置換で指定した値、またはデフォルト値が含まれることを確認します。

    $ oc get configmap k8s-image-puller --output yaml
    apiVersion: v1
    data:
      CACHING_INTERVAL_HOURS: "1"
      CACHING_MEMORY_LIMIT: 20Mi
      CACHING_MEMORY_REQUEST: 10Mi
      DAEMONSET_NAME: kubernetes-image-puller
      IMAGES: |
        theia-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver};
        theia-endpoint-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver};
        pluginbroker-metadata-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:{prod-ver};
        pluginbroker-artifacts-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:{prod-ver};
        plugin-java8-rhel8=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:{prod-ver};
        plugin-java11-rhel8=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:{prod-ver};
        stacks-golang-rhel8=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:{prod-ver};
      NAMESPACE: k8s-image-puller
      NODE_SELECTOR: '{}'
    kind: ConfigMap
    metadata:
      annotations:
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"v1","data":{"CACHING_INTERVAL_HOURS":"1","CACHING_MEMORY_LIMIT":"20Mi","CACHING_MEMORY_REQUEST":"10Mi","DAEMONSET_NAME":"kubernetes-image-puller","IMAGES":"theia-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver}; theia-endpoint-rhel8=registry.redhat.io/codeready-workspaces/theia-rhel8:{prod-ver}; pluginbroker-metadata-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8:{prod-ver}; pluginbroker-artifacts-rhel8=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8:{prod-ver}; plugin-java8-rhel8=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:{prod-ver}; plugin-java11-rhel8=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8:{prod-ver}; stacks-golang-rhel8=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:{prod-ver};\n","NAMESPACE":"k8s-image-puller","NODE_SELECTOR":"{}"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"k8s-image-puller","namespace":"k8s-image-puller"},"type":"Opaque"}
      creationTimestamp: 2020-02-17T22:40:13Z
      name: k8s-image-puller
      namespace: k8s-image-puller
      resourceVersion: "72250"
      selfLink: /api/v1/namespaces/k8s-image-puller/configmaps/k8s-image-puller
      uid: 76430ed6-51d6-11ea-9c19-52fdfc072182
    Copy to Clipboard Toggle word wrap

第10章 CodeReady Workspaces アーキテクチャー要素

このセクションでは、CodeReady Workspaces アーキテクチャーについて説明します。セクションは、高レベルの CodeReady Workspaces アーキテクチャーの概要から始まり、CodeReady Workspaces ワークスペースコントローラーおよび CodeReady Workspaces ワークスペースアーキテクチャーに関する情報の提供を継続します。

10.1. 高度な CodeReady Workspaces アーキテクチャー

図10.1 高度な CodeReady Workspaces アーキテクチャー

CRW 高レベル

CodeReady Workspaces は、OpenShift API を介して CodeReady Workspaces ワークスペースを管理する 1 つの中央ワークスペースコントローラーで構成されています。

CodeReady Workspaces が OpenShift クラスターにインストールされている場合、ワークスペースコントローラーはデプロイされる唯一のコンポーネントになります。CodeReady Workspaces ワークスペースは、ユーザー要求直後に作成されます。

このセクションでは、ワークスペースコントローラーおよび CodeReady Workspaces ワークスペースを作成するさまざまなサービスについて説明します。

10.2. CodeReady Workspaces ワークスペースコントローラー

ワークスペースコントローラーは、コンテナーベースの開発環境 CodeReady Workspaces ワークスペースを管理します。これは、以下の異なる設定でデプロイできます。

  • Single-user: 認証サービスが設定されていません。開発環境はセキュリティー保護されていません。この設定では、リソースが少なくなります。これは、Minikube を使用する場合など、ローカルインストールにより適応されます。
  • マルチユーザー: これはマルチテナント設定です。開発環境のセキュリティーが保護され、この設定にはより多くのリソースが必要です。クラウドインストールに適しています。

CodeReady Workspaces ワークスペースコントローラーの一部である異なるサービスを以下の図に示します。RH-SSO および PostgreSQL は、マルチユーザー設定でのみ必要となることに注意してください。

図10.2 CodeReady Workspaces ワークスペースコントローラー

CRW ワークスペースコントローラー

10.2.1. CodeReady Workspaces サーバー

CodeReady Workspaces サーバー(wsmaster とも 呼ば れる)はワークスペースコントローラーの中央サービスです。これは、CodeReady Workspaces ワークスペースおよび CodeReady Workspaces ユーザーのマルチユーザーモードで HTTP REST API を公開する Java Web サービスです。

Expand

ソースコード

Red Hat CodeReady Workspaces GitHub

コンテナーイメージ

eclipse/che-server

環境変数

Che server コンポーネントの高度な設定オプション

10.2.2. CodeReady Workspaces ユーザーダッシュボード

ユーザーダッシュボードは、Red Hat CodeReady Workspaces の送信ページです。これは Angular フロントエンドアプリケーションです。CodeReady Workspaces のユーザーは、ユーザーダッシュボードを介してブラウザーから CodeReady Workspaces ワークスペースを作成し、起動し、管理します。

Expand

ソースコード

CodeReady Workspaces Dashboard

コンテナーイメージ

eclipse/che-server

10.2.3. devfile レジストリー

CodeReady Workspaces devfile レジストリーは、使用できるワークスペースを作成するための CodeReady Workspaces スタックの一覧を提供するサービスです。このスタックの一覧は、DashboardCreate Workspace ウィンドウで使用されます。devfile レジストリーはコンテナーで実行され、ユーザーダッシュボードが接続可能な場所であればデプロイできます。

devfile レジストリーのカスタマイズに関する詳細は、「 Customizing devfile registry」セクションを参照してください。

Expand

ソースコード

CodeReady Workspaces Devfile レジストリー

コンテナーイメージ

quay.io/crw/che-devfile-registry

10.2.4. CodeReady Workspaces プラグインレジストリー

CodeReady Workspaces プラグインレジストリーは、CodeReady Workspaces ワークスペースのプラグインおよびエディターのリストを提供するサービスです。devfile は、CodeReady Workspaces プラグインレジストリーで公開されるプラグインのみを参照します。これはコンテナーで実行され、wsmaster 接続時にデプロイできます。

プラグインレジストリーのカスタマイズに関する詳細は、1章devfile およびプラグインレジストリーのカスタマイズ セクションを参照してください。

Expand

ソースコード

CodeReady Workspaces プラグインレジストリー

コンテナーイメージ

quay.io/crw/che-plugin-registry

10.2.5. CodeReady Workspaces および PostgreSQL

PostgreSQL データベースは、マルチユーザーモードで CodeReady Workspaces を設定するのが前提条件です。CodeReady Workspaces 管理者は、CodeReady Workspaces を既存の PostgreSQL インスタンスに接続するか、または CodeReady Workspaces デプロイメントが新しい専用の PostgreSQL インスタンスを開始するように設定できます。

CodeReady Workspaces サーバーはデータベースを使用してユーザー設定(ワークフローメタデータ、Git 認証情報)を永続化します。RH-SSO は、データベースをバックエンドとして使用し、ユーザー情報を永続化します。

Expand

ソースコード

CodeReady Workspaces Postgres

コンテナーイメージ

registry.redhat.io/rhel8/postgresql-96:1

10.2.6. CodeReady Workspaces および RH-SSO

RH-SSO は、マルチユーザーモードで CodeReady Workspaces を設定するのが前提条件です。CodeReady Workspaces 管理者は、CodeReady Workspaces を既存の RH-SSO インスタンスに接続するか、または CodeReady Workspaces デプロイメントに新しい専用の RH-SSO インスタンスを起動させることもできます。

CodeReady Workspaces サーバーは、RH-SSO を OpenID Connect(OIDC)プロバイダーとして使用し、CodeReady Workspaces ユーザーを認証し、CodeReady Workspaces リソースへのセキュアなアクセスを提供します。

Expand

ソースコード

CodeReady Workspaces Red Hat Single Sign-On

コンテナーイメージ

registry.redhat.io/rh-sso-7/sso74-openshift-rhel8:7.4

10.3. CodeReady Workspaces ワークスペースアーキテクチャー

クラスター上の CodeReady Workspaces デプロイメントは、CodeReady Workspaces サーバーコンポーネント、ユーザープロファイルおよび設定を保存するデータベース、およびワークスペースをホストする追加のデプロイメントで構成されます。CodeReady Workspaces サーバーはワークスペースの作成をオーケストレーションします。ワークスペースの作成は、ワークスペースコンテナーと有効なプラグインを含むデプロイメントと、以下のような関連するコンポーネントで構成されます。

  • ConfigMaps
  • services
  • endpoints
  • ingresses/routes
  • secrets
  • pvs

CodeReady Workspaces ワークスペースは Web アプリケーションです。これは、コンテナーで実行されるマイクロサービスで構成されており、最新の IDE(エディター、言語の自動補完、デバッグツール)のすべてのサービスを提供します。IDE サービスは、OpenShift リソースとして定義される、コンテナーおよびユーザーランタイムアプリケーションにパッケージ化された開発ツールを使用してデプロイされます。

CodeReady Workspaces ワークスペースのプロジェクトのソースコードは OpenShift PersistentVolume に保持されます。マイクロサービスは、ソースコード(IDE サービス、開発ツール)への読み取り/書き込みアクセスを持つコンテナーで、この共有ディレクトリーへの読み取り/書き込みアクセスを持ちます。

以下の図は、CodeReady Workspaces ワークスペースの詳細なコンポーネントを示しています。

図10.3 CodeReady Workspaces ワークスペースコンポーネント

CRW ワークスペース

図には、実行中のワークスペースが 3 つあります。この 2 つは ユーザー A に属し、もう 1 つは User C です。4 番目のワークスペースがプロビジョニングされ、プラグインブローカーがワークスペース設定を確認し、完了します。

devfile 形式を使用して、CodeReady Workspaces ワークスペースのツールおよびランタイムアプリケーションを指定します。

10.3.1. CodeReady Workspaces ワークスペースコンポーネント

このセクションでは、CodeReady Workspaces ワークスペースのコンポーネントについて説明します。

10.3.1.1. Che Editor プラグイン

Che Editor プラグインは、CodeReady Workspaces ワークスペースプラグインです。ワークスペースでエディターとして使用される web アプリケーションを定義します。デフォルトの CodeReady Workspaces ワークスペースエディターは Che-Theia です。

Che-Theia ソースコードリポジトリーは Che-Theia Github にあります。Eclipse Theia open-source プロジェクト をベースにしています。

Che-Theia は TypeScript で記述され、Microsoft Monaco エディター で構築されています。これは、Visual Studio Code(VS Code )に似た Web ベースのソースコードエディターです。VS Code 拡張機能をサポートするプラグインシステムがあります。

Expand

ソースコード

che-Theia

コンテナーイメージ

eclipse/che-theia

エンドポイント

Theia, webviews, theia-dev, theia-redirect-1, theia-redirect-2, theia-redirect-3

10.3.1.2. CodeReady Workspaces ユーザーランタイム

ユーザーランタイムとして非終了ユーザーコンテナーを使用します。コンテナーイメージとして定義したり、OpenShift リソースのセットとして定義できるアプリケーションは、CodeReady Workspaces ワークスペースに追加できます。これにより、CodeReady Workspaces ワークスペースでアプリケーションを簡単にテストできます。

CodeReady Workspaces ワークスペースでアプリケーションをテストするには、ワークスペース仕様のステージまたは実稼働環境で使用されるアプリケーションの YAML 定義を追加します。これは 12 要素のアプリ dev/prod パリティーです。

ユーザーランタイムの例は Node.js、SpringBoot または MongoDB、および MySQL です。

10.3.1.3. CodeReady Workspaces ワークスペース JWT プロキシー

JWT プロキシーは、CodeReady Workspaces ワークスペースサービスの通信のセキュリティーを保護する役割を果たします。CodeReady Workspaces ワークスペースの JWT プロキシーは、CodeReady Workspaces サーバーがマルチユーザーモードで設定されている場合のみ CodeReady Workspaces ワークスペースに含まれます。

HTTP プロキシーは、ワークスペースサービスから CodeReady Workspaces サーバーへの送信リクエストに署名し、ブラウザーで実行している IDE クライアントからの受信要求を認証するために使用されます。

Expand

ソースコード

JWT プロキシー

コンテナーイメージ

eclipse/che-jwtproxy

10.3.1.4. CodeReady Workspaces プラグインブローカー

プラグインブローカーは、プラグイン meta.yaml ファイルで指定される特殊なサービスです。

  • CodeReady Workspaces サーバーが認識するプラグイン定義を提供するために、すべての情報を収集します。
  • ワークスペースプロジェクト(ダウンロード、アンパックファイル、プロセス設定)で準備操作を実行します。

プラグインブローカーの主な目的は、CodeReady Workspaces がサポートできる実際のプラグインから CodeReady Workspaces プラグインの定義を切り離すことです。ブローカーを使用すると、CodeReady Workspaces サーバーを更新せずに CodeReady Workspaces がさまざまなプラグインをサポートできます。

CodeReady Workspaces サーバーはプラグインブローカーを起動します。プラグインブローカーはワークスペースと同じ OpenShift プロジェクトで実行されます。プラグインおよびプロジェクトの永続ボリュームにアクセスできる。

プラグインブローカーはコンテナーイメージ(例: eclipse/che-plugin-broker)として定義されます。プラグインタイプは、起動するブローカーのタイプを決定します。Che Plugin および Che Editor の 2 種類のプラグインがサポートされています。

Expand

ソースコード

CodeReady Workspaces プラグインブローカー

コンテナーイメージ

quay.io/crw/che-plugin-artifacts-broker
eclipse/che-plugin-metadata-broker

10.3.2. CodeReady Workspaces ワークスペースの設定

このセクションでは、CodeReady Workspaces ワークスペースのプロビジョニングに影響する CodeReady Workspaces サーバーのプロパティーについて説明します。

10.3.2.1. codeready-workspaces ワークスペースのストレージストラテジー

ワークスペース Pod は Persistent Volume Claim(永続ボリューム要求、PVC)を使用します。これは、ReadWriteOnce アクセスモード で物理ボリューム(PV)にバインドされます。CodeReady Workspaces サーバーがワークスペースに PVC を使用する方法を設定できます。この設定の個別の方法は PVC ストラテジーと呼ばれます。

Expand
ストラテジーDetailsProscons

unique

ワークスペースボリュームまたはユーザー定義 PVC ごとの 1 つの PVC

ストレージの分離

未定義の PV 数が必要です。

ワークスペース別(デフォルト)

1 つのワークスペースの 1 つの PVC

一意のストラテジーと比較して、ストレージの管理と制御が容易になります。

PV 数は依然として認識されず、ワークスペース番号により異なります。

common

1 つの OpenShift namespace のすべてのワークスペース用の 1 つの PVC

ストレージの管理と制御が容易になります。

PV が ReadWriteMany(RWX)アクセスモードをサポートしない場合、ワークスペースは別の OpenShift namespace になければなりません。

または、namespace ごとにワークスペースを 1 つ以上実行することはできません。

namespace ストラテジーの設定方法

Red Hat CodeReady Workspaces は、すべての CodeReady Workspaces ワークスペースがユーザーのプロジェクトで動作し、1 つの PVC を共有する際に、「ユーザーごとに 1 つのプロジェクト」プロジェクトストラテジーと組み合わせて 一般的な PVC ストラテジーを使用します。

10.3.2.1.1. 一般的な PVC ストラテジー

OpenShift ネイティブプロジェクト内のすべてのワークスペースは、宣言されたボリュームに以下のようなデータを保存する際にデフォルトのデータストレージと同じ Persistent Volume Claim(永続ボリューム要求、PVC)を使用します。

  • projects
  • ワークスペースログ
  • 使用で定義される追加のボリューム

一般的な PVC ストラテジーが使用されている場合、ユーザー定義 PVC は無視され、これらのユーザー定義 PVC を参照するボリュームは一般的な PVC を参照するボリュームに置き換えられます。このストラテジーでは、すべての CodeReady Workspaces ワークスペースが同じ PVC を使用します。ユーザーが 1 つのワークスペースを実行する場合、一度にクラスター内の 1 つのノードにのみバインドします。

対応するコンテナーボリュームは共通のボリュームへのリンクをマウントし、サブパスには <workspace-ID> または <original-PVC-name> がプレフィックスとして付けられます。詳細はを参照してください 「subpaths が PVC で使用される方法」

CodeReady Workspaces ボリューム名は、ユーザー定義の PVC の名前と同じです。つまり、マシンがユーザー定義 PVC と同じ名前の CodeReady Workspaces ボリュームを使用するように設定されている場合、それらは共通の PVC 内で同じ共有フォルダーを使用します。

ワークスペースが削除されると、対応するサブディレクトリー(${ws-id})が PV ディレクトリーで削除されます。

一般的な PVC ストラテジーの使用に関する制限

一般的な ストラテジーが使用され、ワークスペース PVC アクセスモードが ReadWriteOnce(RWO)の場合、単一ノードのみが PVC を同時に使用できます。

複数のノードがある場合、一般的な ストラテジーを使用できますが、以下のようになります。

  • ワークスペース PVC アクセスモードは ReadWriteMany (RWM)に再設定する必要があるため、この PVC を同時に使用できます。
  • 同じプロジェクトのワークスペースのみを 1 つだけ実行している可能性があります。「プロジェクトストラテジー の設定」を参照して ください。

一般的 な PVC ストラテジーは、大規模な複数ノードクラスターには適していません。したがって、シングルノードクラスターでの使用が最も適しています。ただし、ワーク空間 ごとのプロジェクトストラテジーと組み合わせて、約 75 ノードを持つクラスターには、一般的 な PVC ストラテジーを使用できます。このストラテジーで使用される PVC は、イベントのリスクがあるため、すべてのプロジェクトに対応するのに十分な大きさである必要があります。

10.3.2.1.2. ワークスペースごとの PVC ストラテジー

ワークスペースごとの ストラテジーは 一般的な PVC ストラテジーに似ています。唯一の違いは、すべてのワークスペースボリュームが、すべてのワークスペースではなく、以下のデフォルトデータストレージと同じ PVC を使用することです。

  • projects
  • ワークスペースログ
  • ユーザーが定義する追加のボリューム

CodeReady Workspaces がワークスペースデータを単一の PVC によって割り当てられる割り当てられた PV に保持するストラテジーです。

ワークスペースごと の PVC ストラテジーは、利用可能な PVC ストラテジーで最も汎用的なストラテジーであり、ユーザーが多い大規模なマルチノードクラスターの適切なオプションとして機能します。ワークス ペースごと の PVC ストラテジーを使用すると、ユーザーは複数のワークスペースを同時に実行でき、より多くの PVC が作成されます。

10.3.2.1.3. 一意 の PVC ストラテジー

一意の 'PVC ストラテジーを使用する場合、ワークスペースのすべての CodeReady Workspaces ボリュームに独自の PVC があります。そのため、ワークスペース PVC は以下のようになります。

ワークスペースの初回起動時に作成されます。対応するワークスペースが削除されると削除されます。

ユーザー定義 PVC は以下の仕様で作成されます。

  • これらは生成された名前でプロビジョニングされ、プロジェクトの他の PVC と命名の競合を防ぎます。
  • ユーザー定義の PVC を参照するマウントされた Physical 永続ボリュームのサブパスは、<workspace-ID> または <PVC-name> がプレフィックスとして付加されます。これにより、同じ PV データ構造が異なる PVC ストラテジーで設定されます。詳細はを参照してください 「subpaths が PVC で使用される方法」

一意 の PVC ストラテジーは、ユーザーの数が少ない大規模なマルチノードクラスターに適しています。このストラテジーはワークスペース内の各ボリュームの個別の PVC と操作するため、PVC が大幅に増えます。

10.3.2.1.4. subpaths が PVC で使用される方法

サブパスは、永続ボリューム(PV)のフォルダー階層を示しています。

/pv0001
  /workspaceID1
  /workspaceID2
  /workspaceIDn
    /che-logs
    /projects
    /<volume1>
    /<volume2>
    /<User-defined PVC name 1 | volume 3>
    ...
Copy to Clipboard Toggle word wrap

ユーザーが devfile 内のコンポーネントのボリュームを定義すると、同じ名前のボリュームを定義するすべてのコンポーネントは、<PV-name>、<workspace-ID> 、または '<original-PVC-name> と同じディレクトリーでサポートされます。各コンポーネントは、コンテナーの異なるパスにこの場所をマウントできます。

一般的な PVC ストラテジーを使用すると、ユーザー定義の PVC は共通の PVC のサブパスに置き換えられます。ユーザーがボリュームを my-volume として参照する場合、/workspace- id/my-volume サブパスを使用して、そのボリュームが common- pvc にマウントされます。

10.3.2.2. 永続ボリュームストラテジーを使用した CodeReady Workspaces ワークスペースの設定

永続ボリューム(PV)は、ボリュームをクラスターに追加する仮想ストレージインスタンスとして機能します。

Persistent Volume Claim(永続ボリューム要求、PVC)は、特定のタイプおよび設定の永続ストレージをプロビジョニングする要求です。以下の CodeReady Workspaces ストレージ設定ストラテジーで使用できます。

  • common
  • ワーク領域別
  • unique

マウントされた PVC は、コンテナーファイルシステムのフォルダーとして表示されます。

10.3.2.2.1. Operator を使用した PVC ストラテジーの設定

以下のセクションでは、Operator を使用して CodeReady Workspaces サーバーの workspace Persistent Volume Claim(永続ボリューム要求、PVC)ストラテジーを設定する方法を説明します。

警告

既存のワークスペースを持つ既存の CodeReady Workspaces クラスターで PVC ストラテジーを再設定することは推奨されません。これを行うと、データが失われます。

Operator は、カスタムリソースを使用してアプリケーションとそのコンポーネント 管理する OpenShift のソフトウェアエクステンションです。

Operator を使用して CodeReady Workspaces をデプロイする場合、CheCluster カスタムリソースオブジェクトの YAML ファイルの spec.storage.pvcStrategy プロパティー を変更して、目的のストラテジーを設定します。

前提条件

  • oc ツールが利用可能である。

手順

以下の手順は、以下を行うことができます。

  • OpenShift コマンドラインツール、oc

CheCluster YAML ファイルを変更するには、以下のいずれかを選択します。

  • oc apply コマンドを実行して新規クラスターを作成します。以下に例を示します。

    $ oc apply -f <my-cluster.yaml>
    Copy to Clipboard Toggle word wrap
  • oc patch コマンドを実行して、実行中のクラスターの YAML ファイルプロパティーを更新します。以下に例を示します。

    $ oc patch checluster codeready-workspaces --type=json \
      -p '[{"op": "replace", "path": "/spec/storage/pvcStrategy", "value": "<per-workspace>"}]'
    Copy to Clipboard Toggle word wrap

使用されるストラテジーに応じて、上記の例の <per-workspace> オプションを 一意 または 一般的な オプションに置き換えます。

10.3.2.3. ワークスペースプロジェクトの設定

新しいワークスペース Pod がデプロイされる OpenShift プロジェクトは、CodeReady Workspaces サーバー設定によって異なります。デフォルトでは、すべてのワークスペースは個別のプロジェクトにデプロイされますが、ユーザーは CodeReady Workspaces サーバーを設定して、1 つの特定のプロジェクトにすべてのワークスペースをデプロイすることができます。プロジェクトの名前は CodeReady Workspaces サーバー設定プロパティーとして提供され、ランタイム時に変更できません。

10.3.3. CodeReady Workspaces ワークスペース作成フロー

CHECH ワークスペース作成フロー

CodeReady Workspaces ワークスペース作成フローを以下に示します。

  1. ユーザーは、以下で定義されている CodeReady Workspaces ワークスペースを起動します。

    • エディター(デフォルトは Che-Theia)
    • プラグインの一覧(Java および OpenShift ツールなど)
    • ランタイムアプリケーションの一覧
  2. wsmaster は、プラグインレジストリーからエディターおよびプラグインメタデータを取得します。
  3. 各プラグインタイプについて、wsmaster は特定のプラグインブローカーを 起動 します。
  4. CodeReady Workspaces プラグインブローカーは、プラグインメタデータを Che Plugin 定義に変換します。これは、以下の手順を実行します。

    1. プラグインをダウンロードし、そのコンテンツを抽出します。
    2. プラグインの meta.yaml ファイルを処理し、Che プラグ イン の形式で wsmaster に戻します。
  5. wsmaster はエディターとプラグインサイドカーを起動します。
  6. エディターはプラグイン永続ボリュームからプラグインをロードします。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る