手順

1. https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.7/html-single/end-user_guide/index#making-a-workspace-portable-using-a-devfile_crw の components セクションに明示的に指定されるワークスペースコンポーネントを特定します。

2. 暗黙的なワークスペースコンポーネントを特定します。

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

3. 各コンポーネントの要件を計算します。

   1. デフォルト値:

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

      表2.2 タイプ別のワークスペースコンポーネントのデフォルト要件

      コンポーネントのタイプ	CodeReady Workspaces サーバープロパティー	デフォルトのメモリー制限	デフォルトのメモリー要求
      chePlugin	che.workspace.sidecar.default_memory_limit_mb	128 MiB	64 MiB
      cheEditor	che.workspace.sidecar.default_memory_limit_mb	128 MiB	64 MiB
      kubernetes、 openshift、 dockerimage	che.workspace.default_memory_limit_mb、 che.workspace.default_memory_request_mb	1 Gi	200 MiB
      JWT Proxy	che.server.secure_exposer.jwtproxy.memory_limit、 che.server.secure_exposer.jwtproxy.memory_request	128 MiB	15 MiB

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

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

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

         例2.1 chePlugin che-incubator/typescript/latest

         meta.yaml 仕様セクション:

         spec:
          containers:
            - image: docker.io/eclipse/che-remote-plugin-node:next
              name: vscode-typescript
              memoryLimit: 512Mi
              memoryRequest: 256Mi

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

         メモリー制限	512 MiB
         メモリー要求	256 MiB

         注記

         IBM Power Systems (ppc64le) の場合は、一部のプラグインのメモリー制限が最大 1.5G まで増え、Pod が十分な RAM を実行できるようになりました。たとえば、IBM Power Systems (ppc64le) では、Theia エディター Pod には 2G が必要で、OpenShift コネクター Pod には 2.5G が必要です。AMD64 および Intel 64(x86_64)、 および IBM Z(s390x)の場合、メモリー要件は 512M と 1500M とそれぞれ低くなっています。ただし、一部の devfile は、AMD64 および Intel 64 (x86_64)、ならびに IBM Z (s390x) に有効である低い制限を設定するように設定されます。これを回避するため、デフォルトの memoryLimit を 1 - 1.5 GB 以上を増やすために、devfile を編集します。

         注記

         chePlugin の meta.yaml ファイルの検索方法です。

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

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

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

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

         例2.2 chePlugin che-incubator/typescript/latest

         meta.yaml 仕様セクション:

         spec:
          containers:
            - image: docker.io/eclipse/che-remote-plugin-node:next
              name: vscode-typescript
              cpuLimit: 2000m
              cpuRequest: 500m

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

         CPU 制限	2 コア
         CPU 要求	0.5 コア

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

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

     - alias: maven
       type: dockerimage
       image: eclipse/maven-jdk8:latest
       memoryLimit: 1536M

2. kubernetes または openshift コンポーネントのカスタム要件:

   参照されるマニフェストは、メモリー要件および制限を定義できます。

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

手順

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

手順

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

   $ oc project <project_name>

2. 以下のコマンドを実行して、選択したプロジェクトで実行されている Pod の名前およびステータスを取得します。

   $ oc get pods

3. すべての Pod のステータスが Running であることを確認します。

   例4.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

4. CodeReady Workspaces クラスターデプロイメントの状態を表示するには、以下を実行します。

   $ oc logs --tail=10 -f `(oc get pods -o name | grep operator)`

   例4.2 Operator のログ:

   time="2019-07-12T09:48:29Z" level=info msg="Exec successfully completed"
   time="2019-07-12T09:48:29Z" level=info msg="Updating eclipse-che CR with status: provisioned with OpenShift identity provider: true"
   time="2019-07-12T09:48:29Z" level=info msg="Custom resource eclipse-che updated"
   time="2019-07-12T09:48:29Z" level=info msg="Creating a new object: ConfigMap, name: che"
   time="2019-07-12T09:48:29Z" level=info msg="Creating a new object: ConfigMap, name: custom"
   time="2019-07-12T09:48:29Z" level=info msg="Creating a new object: Deployment, name: che"
   time="2019-07-12T09:48:30Z" level=info msg="Updating eclipse-che CR with status: CodeReady Workspaces API: Unavailable"
   time="2019-07-12T09:48:30Z" level=info msg="Custom resource eclipse-che updated"
   time="2019-07-12T09:48:30Z" level=info msg="Waiting for deployment che. Default timeout: 420 seconds"

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

手順

1. che-master ホストで 8087 ポートをサービスとして公開する CHE_METRICS_ENABLED=true 環境変数を設定します。

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'

2. JAEGER_ENDPOINT の値を編集して、デプロイメントの Jaeger コレクターサービスの名前に一致するようにします。

   メインの OpenShift Container Platform 画面の左側のメニューから、Networking → Services に移動して JAEGER_ENDPOINT の値を取得します。または、以下の oc コマンドを実行します。

   $ oc get services

   要求された値は collector 文字列が含まれるサービス名に含まれます。

1. 左側の Search パネルで、操作名（スパン名)、タグ、または期間でスパンをフィルターします。

   図6.1 Jaeger UI を使用した CodeReady Workspaces の追跡

   

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

   図6.2 拡張されたトレースツリー

   

手順

1. 関連するコンテナーイメージの一覧を取得します。

   例8.1 CodeReady Workspaces に関連するすべてのイメージの一覧の取得

   $ curl -sSLo- https://raw.githubusercontent.com/redhat-developer/codeready-workspaces-operator/crw-2.7-rhel-8/manifests/codeready-workspaces.csv.yaml | \
     yq -r '.spec.relatedImages[]'

2. sleep コマンドを含まないコンテナーイメージの一覧から除外します。

   例8.2 イメージは {image-puller-short} と互換性がありません。sleep コマンドがありません

   • FROM scratch イメージ。
   • che-machine-exec
3. Dockerfile でボリュームをマウントするコンテナーイメージの一覧から除外します。

手順

1. CACHING_MEMORY_REQUEST または CACHING_MEMORY_LIMIT の最小値を定義するには、プルする各コンテナーイメージの実行に必要なメモリー容量を考慮してください。

2. CACHING_MEMORY_REQUEST または CACHING_MEMORY_LIMIT の最大値を定義するには、クラスターのデーモンセット Pod に割り当てられるメモリーの合計を考慮します。

   (memory limit) * (number of images) * (number of nodes in the cluster)

   コンテナーのメモリー制限が 20Mi の 20 ノードで 5 つのイメージをプルする場合、2000Mi のメモリーが必要です。

手順

1. CheCluster カスタムリソースを編集して .spec.imagePuller.enable を true に設定します。

   例8.3 CheCluster カスタムリソースでの Image Puller の有効化

   apiVersion: org.eclipse.che/v1
   kind: CheCluster
   metadata:
     name: codeready-workspaces
   spec:
     # ...
     imagePuller:
       enable: true

   CodeReady Workspaces Operator を使用した Image Puller のアンインストール

   • CheCluster カスタムリソースを編集し、.spec.imagePuller.enable を false に設定します。

2. CheCluster カスタムリソースを編集し、.spec.imagePuller.spec を、 CodeReady Workspaces Operator のオプションの Image Puller パラメーターを設定できるように設定します。

   例8.4 CheCluster カスタムリソースでの Image Puller の設定

   apiVersion: org.eclipse.che/v1
   kind: CheCluster
   metadata:
     name: codeready-workspaces
   spec:
     ...
     imagePuller:
       enable: true
       spec:
           configMapName: <kubernetes-image-puller>
           daemonsetName: <kubernetes-image-puller>
           deploymentName: <kubernetes-image-puller>
           images: <{image-puller-images}>

検証手順

1. OpenShift は {image-puller-operator-id} サブスクリプションを作成します。

2. eclipse-che namespace には community supported Kubernetes Image Puller Operator ClusterServiceVersion が含まれます。

   $ oc get clusterserviceversions

3. eclipse-che namespace には、kubernetes-image-puller および {image-puller-deployment-id} のデプロイメントが含まれます。

   $ oc get deployments

4. コミュニティーがサポートする Kubernetes Image Puller Operator は KubernetesImagePuller カスタムリソースを作成します。

   $ oc get kubernetesimagepullers

手順

1. Image Puller をホストする OpenShift プロジェクト <kubernetes-image-puller> を作成するには、OpenShift Web コンソールを開き、Home → Projects セクションに移動し、Create Project をクリックします。

2. プロジェクトの詳細を指定します。

   • Name: <kubernetes-image-puller>
   • Display Name: <Image Puller>
   • Description: <Kubernetes Image Puller>
3. Operators → OperatorHub に移動します。
4. Filter by keyword ボックスを使用して community supported Kubernetes Image Puller Operator を検索します。community supported Kubernetes Image Puller Operator をクリックします。
5. Operator の説明を確認します。Continue → Install をクリックします。
6. Installation Mode について A specific project on the cluster を選択します。ドロップダウンで、OpenShift プロジェクト <kubernetes-image-puller> を見つけます。Subscribe をクリックします。
7. コミュニティーがサポートする Kubernetes Image Puller Operator のインストールを待機します。KubernetesImagePuller → Create instance をクリックします。
8. YAML エディターのあるリダイレクトされるウィンドウで、KubernetesImagePuller カスタムリソースに変更を加え、Create をクリックします。
9. <kubernetes-image-puller> OpenShift プロジェクトの Workloads および Pods メニューに移動します。Image Puller が利用可能であることを確認します。

手順

1. Image Puller リポジトリーのクローンを作成し、OpenShift テンプレートが含まれるディレクトリーを取得します。

   $ git clone https://github.com/che-incubator/kubernetes-image-puller
   $ cd kubernetes-image-puller/deploy/openshift

2. 以下のパラメーターを使用して、app.yaml、configmap.yaml、および serviceaccount.yaml OpenShift テンプレートを設定します。

   表8.2 app.yaml の Image Puller OpenShift テンプレートパラメーター

   値	使用	デフォルト
   DEPLOYMENT_NAME	ConfigMap の DEPLOYMENT_NAME の値	kubernetes-image-puller
   IMAGE	kubernetes-image-puller デプロイメントに使用されるイメージ	registry.redhat.io/codeready-workspaces/imagepuller-rhel8:2.7
   IMAGE_TAG	プルするイメージタグ	latest
   SERVICEACCOUNT_NAME	デプロイメントで作成され、使用される ServiceAccount の名前	{image-puller-serviceaccount-name}

   表8.3 configmap.yaml の Image Puller OpenShift テンプレートパラメーター

   値	使用	デフォルト
   CACHING_CPU_LIMIT	ConfigMap の CACHING_CPU_LIMIT の値	.2
   CACHING_CPU_REQUEST	ConfigMap の CACHING_CPU_REQUEST の値	.05
   CACHING_INTERVAL_HOURS	ConfigMap の CACHING_INTERVAL_HOURS の値	"1"
   CACHING_MEMORY_LIMIT	ConfigMap の CACHING_MEMORY_LIMIT の値	"20Mi"`
   CACHING_MEMORY_REQUEST	ConfigMap の CACHING_MEMORY_REQUEST の値	"10Mi"
   DAEMONSET_NAME	ConfigMap の DAEMONSET_NAME の値	kubernetes-image-puller
   DEPLOYMENT_NAME	ConfigMap の DEPLOYMENT_NAME の値	kubernetes-image-puller
   IMAGES	ConfigMap の IMAGES の値	{image-puller-images}
   NODE_SELECTOR	ConfigMap の NODE_SELECTOR の値	"{}"

   表8.4 serviceaccount.yaml の Image Puller OpenShift テンプレートパラメーター

   値	使用	デフォルト
   SERVICEACCOUNT_NAME	デプロイメントで作成され、使用される ServiceAccount の名前	{image-puller-serviceaccount-name}

3. Image Puller をホストする OpenShift プロジェクトを作成します。

   $ oc new-project <kubernetes-image-puller>

4. テンプレートを処理してから適用し、Puller をインストールします。

   $ oc process -f serviceaccount.yaml | oc apply -f -
   $ oc process -f configmap.yaml | oc apply -f -
   $ oc process -f app.yaml | oc apply -f -

検証手順

1. <kubernetes-image-puller> デプロイメントおよび <kubernetes-image-puller> デーモンセットがあることを確認します。デーモンセットでは、クラスター内の各ノードに Pod が必要です。

   $ oc get deployment,daemonset,pod --namespace <kubernetes-image-puller>

2. <kubernetes-image-puller> ConfigMap の値を確認します。

   $ oc get configmap <kubernetes-image-puller> --output yaml