管理ガイド

手順

1. オプション: この OpenShift クラスターに OpenShift Dev Spaces をデプロイした場合は、以前の OpenShift Dev Spaces インスタンスが削除されていることを確認してください。

   $ dsc server:delete

2. OpenShift Dev Spaces インスタンスを作成します。

   $ dsc server:deploy --platform openshift

検証手順

1. OpenShift Dev Spaces インスタンスのステータスを確認します。

   $ dsc server:status

2. OpenShift Dev Spaces クラスターインスタンスに移動します。

   $ dsc dashboard:open

手順

1. OpenShift Web コンソールの 管理者 ビューで、Operators → OperatorHub に移動し、Red Hat OpenShift Dev Spaces を検索します。

2. Red Hat OpenShift Dev Spaces Operator をインストールします。

   ヒント

   Web コンソールを使用して OperatorHub からインストールするを 参照してください。

   注意

   Red Hat OpenShift Dev Spaces Operator は、Dev Workspace Operator に依存します。Red Hat OpenShift Dev Spaces Operator を手動でデフォルト以外の namespace にインストールする場合は、Dev Workspace Operator も同じ namespace にインストールされていることを確認してください。これは、Operator Lifecycle Manager が、Red Hat OpenShift Dev Spaces Operator namespace 内の依存関係として Dev Workspace Operator をインストールしようとすることから、Red Hat OpenShift Dev Spaces Operator が別の namespace にインストールされている場合は、Dev Workspace Operator は 2 つの競合するインストールとなる可能性があるため、確認が必要となります。

1. 次のように、OpenShift で openshift-devspaces プロジェクトを作成します。

   oc create namespace openshift-devspaces

2. Operators → Installed Operators → Red Hat OpenShift Dev Spaces インスタンスの仕様 → Create CheCluster → YAML view に移動します。
3. YAML view で、namespace: openshift-operators を namespace: openshift-devspaces に置き換えます。

4. Create を選択します。

   ヒント

   インストールされた Operators からアプリケーションを作成するを 参照してください。

1. Red Hat OpenShift Dev Spaces インスタンスの仕様 で、devspaces に移動し、Details タブに移動します。

1. Message の下に None があることを確認します。これはエラーがないことを意味します。
2. Red Hat OpenShift Dev Spaces URL で、OpenShift Dev Spaces インスタンスの URL が表示されるまで待ち、URL を開いて OpenShift Dev Spaces ダッシュボードを確認します。
3. Resources タブで、OpenShift Dev Spaces デプロイメントのリソースとそのステータスを表示します。

手順

1. ミラーリングスクリプトをダウンロードして実行し、カスタム Operator カタログをインストールし、関連するイメージをミラーリングします (prepare-restricted-environment.sh)。

   $ bash prepare-restricted-environment.sh \
     --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.15\
     --devworkspace_operator_version "v0.26.0" \
     --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.15" \
     --prod_operator_package_name "devspaces" \
     --prod_operator_bundle_name "devspacesoperator" \
     --prod_operator_version "v3.12.0" \
     --my_registry "<my_registry>" 1

   1

   イメージがミラーリングされるプライベート Docker レジストリー

2. 前の手順で で che-operator-cr-patch.yaml に指定した設定で OpenShift Dev Spaces をインストールします。

   $ dsc server:deploy \
     --platform=openshift \
     --olm-channel stable \
     --catalog-source-name=devspaces-disconnected-install \
     --catalog-source-namespace=openshift-marketplace \
     --skip-devworkspace-operator \
     --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml

3. OpenShift Dev Spaces namespace からユーザープロジェクト内のすべての Pod への受信トラフィックを許可します。「ネットワークポリシーの設定」 を参照してください。

検証

1. 設定されたプロパティーの値を確認します。

   $ oc get configmap che -o jsonpath='{.data.<configured_property>}' \
   -n openshift-devspaces

手順

1. クラスター上の CheCluster カスタムリソースを編集します。

   $ oc edit checluster/devspaces -n openshift-devspaces

2. ファイルを保存して閉じ、変更を適用します。

検証

1. 設定されたプロパティーの値を確認します。

   $ oc get configmap che -o jsonpath='{.data.<configured_property>}' \
   -n openshift-devspaces

手順

1. ターゲットメトリクスと必要なレプリカ数を指定して、デプロイメント用の HPA リソースを作成します。

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: scaler
     namespace: openshift-devspaces
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: <deployment_name> 1
     ...

   1

   <deployment_name> は、次のデプロイメントのいずれかに対応します。

   • devspaces
   • che-gateway
   • devspaces-dashboard
   • plugin-registry
   • devfile-registry

手順

1. OpenShift Dev Spaces namespace の名前を取得します。デフォルトは openshift-devspaces です。

   $ oc get checluster --all-namespaces \
     -o=jsonpath="{.items[*].metadata.namespace}"

2. maxNumberOfWorkspacesPerUser を設定します。

   $ oc patch checluster/devspaces -n openshift-devspaces \1
   --type='merge' -p \
   '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'2

   1

   ステップ 1 で取得した OpenShift Dev Spaces namespace 。

   2

   <kept_workspaces_limit> の値を選択します。

手順

1. OpenShift Dev Spaces namespace の名前を取得します。デフォルトは openshift-devspaces です。

   $ oc get checluster --all-namespaces \
     -o=jsonpath="{.items[*].metadata.namespace}"

2. maxNumberOfRunningWorkspacesPerUser を設定します。

   $ oc patch checluster/devspaces -n openshift-devspaces \1
   --type='merge' -p \
   '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'2

   1

   ステップ 1 で取得した OpenShift Dev Spaces namespace 。

   2

   <running_workspaces_limit> の値を選択します。

手順

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

   $ oc create configmap che-git-self-signed-cert \
     --from-file=ca.crt=<path_to_certificate> \  1
     --from-literal=githost=<git_server_url> -n openshift-devspaces  2

   1

   自己署名証明書へのパス。

   2

   Git サーバーの URL を指定するオプションのパラメーター (例: https://git.example.com:8443)。省略すると、自己署名証明書が HTTPS 経由のすべてのリポジトリーに使用されます。

   注記
   • 証明書ファイルは、通常、以下のような Base64 ASCII ファイルとして保存されます。.pem, .crt, .ca-bundle.証明書ファイルを保持するすべての ConfigMap はバイナリーデータ証明書ではなく Base64 ASCII 証明書を使用する必要があります。
   • 証明書の信頼チェーンが必要です。ca.crt が認証局 (CA) によって署名されている場合は、CA 証明書が ca.crt ファイルに含まれている必要があります。

2. 必要なラベルを ConfigMap に追加します。

   $ oc label configmap che-git-self-signed-cert \
     app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces

3. Git リポジトリーに自己署名証明書を使用するように OpenShift Dev Spaces オペランドを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。

   spec:
     devEnvironments:
       trustedCerts:
         gitTrustedCertsConfigMapName: che-git-self-signed-cert

手順

1. NodeSelector の使用

   OpenShift Dev Spaces は、CheCluster カスタムリソースを使用して nodeSelector を設定します。

   spec:
     devEnvironments:
       nodeSelector:
         key: value

   このセクションには、nodeSelector ルールを形成するために、各 ノードラベル の キー = 値の ペアのセットが含まれている必要があります。

2. 汚染と許容の使用

   これは nodeSelector とは逆の働きをします。Pod がスケジュールされるノードを指定する代わりに、Pod がスケジュールされないノードを指定します。詳細は、https ://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration を参照してください。

   OpenShift Dev Spaces は、CheCluster カスタムリソースを使用して 許容範囲 を設定します。

   spec:
     devEnvironments:
       tolerations:
         - effect: NoSchedule
           key: key
           value: value
           operator: Equal

手順

1. 以下の ConfigMap を作成して、すべてのユーザー名前空間に複製します。設定可能性を高めるために、追加のラベルとアノテーションを追加して ConfigMap を カスタマイズできます。その他の可能なラベルとアノテーションについては 、ボリューム、設定マップ、シークレットの自動マウント を参照してください。

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: user-configmap
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
   data:
     ...

   例3.16 ユーザーワークスペースに settings.xml ファイルをマウントします。

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: user-settings-xml
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /home/user/.m2
   data:
     settings.xml: |
       <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
         <localRepository>/home/user/.m2/repository</localRepository>
         <interactiveMode>true</interactiveMode>
         <offline>false</offline>
       </settings>

2. 以下の Secret を作成して、それをすべてのユーザー名前空間に複製します。設定可能性を高めるために、追加のラベルとアノテーションを追加して Secret を カスタマイズできます。その他の可能なラベルとアノテーションについては 、ボリューム、設定マップ、シークレットの自動マウント を参照してください。

   kind: Secret
   apiVersion: v1
   metadata:
     name: user-secret
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
   data:
     ...

   例3.17 ユーザーワークスペースに証明書をマウントする:

   kind: Secret
   apiVersion: v1
   metadata:
     name: user-certificates
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
     annotations:
       controller.devfile.io/mount-as: subpath
       controller.devfile.io/mount-path: /etc/pki/ca-trust/source/anchors
   stringData:
     trusted-certificates.crt: |
       ...

   注記

   ワークスペースの起動時に update-ca-trust コマンドを実行して証明書をインポートします。これは手動で実行することも、devfile の postStart イベントにこのコマンドを追加することで実行することもできます。devfile でのイベントバインディングの追加を 参照してください。

   例3.18 環境変数をユーザーワークスペースにマウントする:

   kind: Secret
   apiVersion: v1
   metadata:
     name: user-env
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
     annotations:
       controller.devfile.io/mount-as: env
   stringData:
     ENV_VAR_1: value_1
     ENV_VAR_2: value_2

3. 以下の PersistentVolumeClaim を作成して、それをすべてのユーザー名前空間に複製します。

   設定可能性を高めるために、追加のラベルとアノテーションを追加して PersistentVolumeClaim をカスタマイズできます。その他の可能なラベルとアノテーションについては 、ボリューム、設定マップ、シークレットの自動マウント を参照してください。

   PersistentVolumeClaim を変更するには、これを削除し、openshift-devspaces 名前空間に新しいものを作成します。

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: user-pvc
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
   spec:
     ...

   例3.19 PersistentVolumeClaim をユーザーワークスペースにマウントする:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: user-pvc
     namespace: openshift-devspaces
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspaces-config
       controller.devfile.io/mount-to-devworkspace: 'true'
     annotations:
       controller.devfile.io/mount-path: /home/user/data
       controller.devfile.io/read-only: 'true'
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 5Gi
     volumeMode: Filesystem

手順

1. https://<openshift_dev_spaces_fqdn>/plugin-registry/v3/external_images.txt URL に移動して、プルする関連コンテナーイメージのリストを収集します。
2. プル前のリストからイメージを判別します。ワークスペースの起動時間を短縮するには、universal-developer-image、che-code、che-gateway などのワークスペース関連のイメージをプルすることを検討してください。

手順

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. コミュニティーでサポートされている Kubernetes Image Puller Operator をインストールします。Web コンソールを使用して OperatorHub からインストールするを 参照してください。
2. コミュニティーでサポートされている Kubernetes Image Puller Operator から KubernetesImagePuller オペランドを作成します。インストールされた Operators からアプリケーションを作成するを 参照してください。

手順

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 テンプレートを設定します。

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

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

   表3.39 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 の値	"undefined"
   NAMESPACE	ConfigMap の NAMESPACE の値	k8s-image-puller
   NODE_SELECTOR	ConfigMap の NODE_SELECTOR の値	"{}"

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

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

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

   $ oc new-project <k8s-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 <k8s-image-puller>

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

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

手順

1. OpenShift Dev Spaces のプロジェクトを作成します。

   $ oc create project openshift-devspaces

2. TLS Secret を作成します。

   $ oc create secret TLS <tls_secret_name> \ 1
   --key <key_file> \ 2
   --cert <cert_file> \ 3
   -n openshift-devspaces

   1

   TLS Secret 名

   2

   プライベートキーを含むファイル

   3

   証明書を含むファイル

3. シークレットに必要なラベルを追加します。

   $ oc label secret <tls_secret_name> \ 1
   app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces

   1

   TLS Secret 名

4. CheCluster カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。

   spec:
     networking:
       hostname: <hostname>     1
       tlsSecretName: <secret>  2

   1

   カスタム Red Hat OpenShift Dev Spaces サーバーのホスト名

   2

   TLS Secret 名

5. OpenShift Dev Spaces がすでにデプロイされている場合は、すべての OpenShift Dev Spaces コンポーネントのロールアウトが完了するまで待ちます。

手順

1. インポートするすべての CA チェーン PEM ファイルを custom-ca-certificates.pem ファイルに連結し、Java トラストストアと互換性のない戻り文字を削除します。

   $ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem

2. 必要な TLS 証明書を使用して custom-ca-certificates Config Map を作成します。

   $ oc create configmap custom-ca-certificates \
       --from-file=custom-ca-certificates.pem \
       --namespace=openshift-devspaces

3. custom-ca-certificates Config Map にラベルを付けます。

   $ oc label configmap custom-ca-certificates \
       app.kubernetes.io/component=ca-bundle \
       app.kubernetes.io/part-of=che.eclipse.org \
       --namespace=openshift-devspaces

4. 以前にデプロイされていない場合は、OpenShift Dev Spaces をデプロイします。それ以外の場合は、OpenShift Dev Spaces コンポーネントのロールアウトが完了するまで待ちます。
5. 変更を有効にするには、実行中のワークスペースを再起動します。

検証手順

1. Config Map にカスタム CA 証明書が含まれていることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

   $ oc get configmap \
       --namespace=openshift-devspaces \
       --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \
       --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org

2. OpenShift Dev Spaces Pod に、ca-certs-merged Config Mapをマウントするボリュームが含まれていることを確認します。

   $ oc get pod \
       --selector=app.kubernetes.io/component=devspaces \
       --output='jsonpath={.items[0].spec.volumes[0:].configMap.name}' \
       --namespace=openshift-devspaces \
       | grep ca-certs-merged

3. OpenShift Dev Spaces サーバーコンテナーにカスタム CA 証明書があることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

   $ oc exec -t deploy/devspaces \
       --namespace=openshift-devspaces \
       -- cat /public-certs/custom-ca-certificates.pem

4. OpenShift Dev Spaces サーバーログで、インポートされた証明書の数が null でないことを確認します。

   $ oc logs deploy/devspaces --namespace=openshift-devspaces \
       | grep custom-ca-certificates.pem

5. 証明書の SHA256 フィンガープリントを一覧表示します。

   $ for certificate in ca-cert*.pem ;
     do openssl x509 -in $certificate -digest -sha256 -fingerprint -noout | cut -d= -f2;
     done

6. OpenShift Dev Spaces サーバーの Java トラストストアに同じフィンガープリントを持つ証明書が含まれていることを確認します。

   $ oc exec -t deploy/devspaces --namespace=openshift-devspaces -- \
       keytool -list -keystore /home/user/cacerts \
       | grep --after-context=1 custom-ca-certificates.pem

7. ワークスペースを開始し、これが作成されたプロジェクト名 <workspace_namespace> を取得して、ワークスペースが開始されるのを待ちます。

8. che-trusted-ca-certs Config Mapにカスタム CA 証明書が含まれていることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

   $ oc get configmap che-trusted-ca-certs \
       --namespace=<workspace_namespace> \
       --output='jsonpath={.data.custom-ca-certificates\.custom-ca-certificates\.pem}'

9. ワークスペース Pod が che-trusted-ca-certs Config Mapをマウントすることを確認します。

   $ oc get pod \
       --namespace=<workspace_namespace> \
       --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
       --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
       | grep che-trusted-ca-certs

10. Universal-developer-image コンテナー (またはワークスペース devfile で定義されたコンテナー) が che-trusted-ca-certs ボリュームをマウントしていることを確認します。

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.containers[0:]}' \
        | jq 'select (.volumeMounts[].name == "che-trusted-ca-certs") | .name'

11. ワークスペース Pod 名 <workspace_pod_name> を取得します。

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \

12. ワークスペースコンテナーにカスタム CA 証明書があることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

    $ oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /public-certs/custom-ca-certificates.custom-ca-certificates.pem

1. ストレージクラス名を定義します。CheCluster カスタムリソースを設定し、OpenShift Dev Spaces をインストールします。「dsc を使用したインストール時に CheCluster カスタムリソースの設定」 を参照してください。

   spec:
     devEnvironments:
       storage:
         perUserStrategyPvcConfig:
           claimSize: <claim_size> 1
           storageClass: <storage_class_name> 2
         perWorkspaceStrategyPvcConfig:
           claimSize: <claim_size> 3
           storageClass: <storage_class_name> 4
         pvcStrategy: <pvc_strategy> 5

   1 3

   Persistent Volume Claim のサイズ。

   2 4

   Persistent Volume Claim のストレージクラス。省略されるか、空のままの場合は、デフォルトのストレージクラスが使用されます。

   5

   永続ボリューム要求ストラテジー。サポートされているストラテジーは、per-user (1 つのボリュームにすべてのワークスペースの永続ボリューム要求)、per-workspace (各ワークスペースに個別の永続ボリューム要求が与えられる)、ephemeral (ワークスペースが停止すると、ローカルの変更が失われる非永続ストレージ) です。

手順

1. Che Cluster カスタムリソースの pvcStrategy フィールドを、per-user、per-workspace または ephemeral に設定します。

手順

1. Che Cluster カスタムリソースで、必要なストレージストラテジーの適切な claimSize フィールドを設定します。

手順

1. サンプル設定で JSON ファイルを作成します。ファイルにはオブジェクトの配列が含まれている必要があります。各オブジェクトはサンプルを表します。

   cat > my-samples.json <<EOF
   [
     {
       "displayName": "<display_name>", 1
       "description": "<description>", 2
       "tags": <tags>, 3
       "url": "<url>", 4
       "icon": {
         "base64data": "<base64data>", 5
         "mediatype": "<mediatype>" 6
       }
     }
   ]
   EOF

   1

   サンプルの表示名。

   2

   サンプルの説明。

   3

   タグの JSON 配列 (例: ["java", "spring"])。

   4

   devfile を含むリポジトリーへの URL。

   5

   アイコンの base64 でエンコードされたデータ。

   6

   アイコンのメディアタイプ。たとえば image/png。

2. サンプル設定で ConfigMap を作成します。

   oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces

3. 必要なラベルを ConfigMap に追加します。

   oc label configmap getting-started-samples app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=getting-started-samples -n openshift-devspaces

4. OpenShift Dev Spaces Dashboard ページを更新して、新しいサンプルを表示します。

手順

1. シークレットを作成します。

   oc apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: devspaces-dashboard-customization
     namespace: openshift-devspaces
     annotations:
       che.eclipse.org/mount-as: subpath
       che.eclipse.org/mount-path: /public/dashboard/assets/branding
     labels:
       app.kubernetes.io/component: devspaces-dashboard-secret
       app.kubernetes.io/part-of: che.eclipse.org
   data:
     loader.svg: <Base64_encoded_content_of_the_image> 1
   type: Opaque
   EOF

   1

   行の折り返しが無効になっている Base64 エンコーディング。

2. devspaces-dashboard のロールアウトが完了するまで待ちます。

手順

1. ユーザーロール名を定義します。

   $ USER_ROLES=<name> 1

   1

   一意のリソース名。

2. OpenShift Dev Spaces Operator がデプロイされている namespace を見つけます。

   $ OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)

3. 必要なロールを作成します。

   $ kubectl apply -f - <<EOF
   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: ${USER_ROLES}
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
   rules:
     - verbs:
         - <verbs> 1
       apiGroups:
         - <apiGroups> 2
       resources:
         - <resources> 3
   EOF

   1

   <verbs> として、このルールに含まれるすべての ResourceKind および AttributeRestrictions に適用されるすべての動詞をリストします。* を使用してすべての動詞を表すことができます。

   2

   <apiGroups> として、リソースを含む APIGroups に名前を付けます。

   3

   <resources> として、このルールが適用されるすべてのリソースをリストします。* を使用してすべての動詞を表すことができます。

4. ロールを OpenShift Dev Spaces Operator に委譲します。

   $ kubectl apply -f - <<EOF
   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: ${USER_ROLES}
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
   subjects:
     - kind: ServiceAccount
       name: devspaces-operator
       namespace: ${OPERATOR_NAMESPACE}
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ${USER_ROLES}
   EOF

5. ロールを che サービスアカウントに委譲するように OpenShift Dev Spaces Operator を設定します。

   $ kubectl patch checluster devspaces \
     --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
     --type=merge -n openshift-devspaces

6. ロールをユーザーに委譲するように OpenShift Dev Spaces サーバーを設定します。

   $ kubectl patch checluster devspaces \
     --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
     --type=merge -n openshift-devspaces

7. OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。
8. ログアウトして、新しいロールを適用するようにユーザーに依頼します。

手順

1. CheCluster カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。

   spec:
     networking:
       auth:
         advancedAuthorization:
           allowUsers:
             - <allow_users> 1
           allowGroups:
             - <allow_groups> 2
           denyUsers:
             - <deny_users> 3
           denyGroups:
             - <deny_groups> 4

   1

   Red Hat OpenShift Dev Spaces へのアクセスが許可されているユーザーのリスト。

   2

   Red Hat OpenShift Dev Spaces へのアクセスが許可されているユーザーのグループのリスト (OpenShift Container Platform のみ)。

   3

   Red Hat OpenShift Dev Spaces へのアクセスを拒否されたユーザーのリスト。

   4

   Red Hat OpenShift Dev Spaces へのアクセスを拒否されたユーザーのグループのリスト (OpenShift Container Platform のみ)。

2. OpenShift Dev Spaces サーバーコンポーネントのロールアウトが完了するまで待ちます。

手順

1. 次のコマンドを使用して、OpenShift クラスター内のすべてのユーザーをリスト表示します。

   $ oc get users

2. ユーザーエントリーを削除します。

手順

1. OpenShift クラスターのタイプ (シングルノードクラスター、または個別のコントロールプレーンとワーカーノードを持つマルチノードクラスター) に基づいて環境変数を設定します。

   • シングルノードクラスターの場合は、次のように設定します。

     $ NODE_ROLE=master

   • マルチノードクラスターの場合は、次のように設定します。

     $ NODE_ROLE=worker

2. OpenShift Butane 設定バージョンの環境変数を設定します。この変数は、OpenShift クラスターのメジャーバージョンとマイナーバージョンです。たとえば、4.12.0、4.13.0、または 4.14.0 です。

   $ VERSION=4.12.0

3. NODE_ROLE ノードに 99-podman-Fuse という名前のドロップイン CRI-O 設定ファイルを作成する MachineConfig リソースを作成します。この設定ファイルにより、特定の Pod が /dev/Fuse デバイスにアクセスできるようになります。

   cat << EOF | butane | oc apply -f -
   variant: openshift
   version: ${VERSION}
   metadata:
     labels:
       machineconfiguration.openshift.io/role: ${NODE_ROLE}
     name: 99-podman-dev-fuse-${NODE_ROLE}
   storage:
     files:
     - path: /etc/crio/crio.conf.d/99-podman-fuse 1
       mode: 0644
       overwrite: true
       contents: 2
         inline: |
           [crio.runtime.workloads.podman-fuse] 3
           activation_annotation = "io.openshift.podman-fuse" 4
           allowed_annotations = [
             "io.kubernetes.cri-o.Devices" 5
           ]
           [crio.runtime]
           allowed_devices = ["/dev/fuse"] 6
   EOF

   1

   CRI-O の新しいドロップイン設定ファイルへの絶対ファイルパス。

   2

   新しいドロップイン設定ファイルの内容。

   3

   podman-Fuse ワークロードを定義します。

   4

   podman-Fuse ワークロード設定をアクティブにする Pod アノテーション。

   5

   podman-Fuse ワークロードが処理できるアノテーションのリスト。

   6

   ユーザーが io.kubernetes.cri-o.Devices アノテーションを使用して指定できるホスト上のデバイスのリスト。

4. MachineConfig リソースを適用した後、変更が適用されると、ワーカー ロールを持つ各ノードのスケジュール設定が一時的に無効になります。ノードのステータスを表示します。

   $ oc get nodes

   出力例:

   NAME                           STATUS                     ROLES    AGE   VERSION
   ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.27.9
   ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.27.9
   ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.27.9
   ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.27.9
   ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.27.9
   ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.27.9

5. ワーカー ロールを持つすべてのノードのステータスが Ready に なると、次のアノテーションを持つすべての Pod で /dev/Fuse が利用できるようになります。

   io.openshift.podman-fuse: ''
   io.kubernetes.cri-o.Devices: /dev/fuse