3.5. ワークスペースのグローバル設定


このセクションでは、管理者がワークスペースをグローバルに設定する方法を説明します。

3.5.1. ユーザーが保持できるワークスペースの数を制限する

デフォルトでは、ユーザーはダッシュボードに無制限の数のワークスペースを保持できますが、この数を制限してクラスターの需要を減らすことができます。

この設定は、CheCluster カスタムリソースの一部です。

spec:
  devEnvironments:
    maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>1
1
ユーザーごとのワークスペースの最大数を設定します。デフォルト値 -1 では、ユーザーは無制限の数のワークスペースを保持できます。ユーザーごとのワークスペースの最大数を設定するには、正の整数を使用します。

手順

  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> の値を選択します。

3.5.2. ユーザーが複数のワークスペースを同時に実行できるようにする

デフォルトでは、ユーザーは一度に 1 つのワークスペースしか実行できません。ユーザーが複数のワークスペースを同時に実行できるようにすることができます。

注記

デフォルトのストレージ方法を使用している際、マルチノードクラスター内のノード全体に Pod が分散されている場合は、ワークスペースを同時に実行すると問題が発生する可能性があります。ユーザーごとの common ストレージストラテジーから per-workspace ストレージストラテジーに切り替えるか、ephemeral ストレージタイプを使用すると、これらの問題を回避または解決できます。

この設定は、CheCluster カスタムリソースの一部です。

spec:
  devEnvironments:
    maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>1
1
ユーザーごとに同時に実行されるワークスペースの最大数を設定します。値 -1 を指定すると、ユーザーはワークスペースを無制限に実行できます。デフォルト値は 1 です。

手順

  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> の値を選択します。

3.5.3. 自己署名証明書を使用した Git

自己署名証明書を使用する Git プロバイダーでの操作をサポートするように OpenShift Dev Spaces を設定できます。

前提条件

  • OpenShift クラスターへの管理権限を持つアクティブな oc セッション。OpenShift CLI のスタートガイド を参照してください。
  • Git バージョン 2 以降

手順

  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

検証手順

  • 新規ワークスペースを作成および開始します。ワークスペースによって使用されるすべてのコンテナーは、自己署名証明書のあるファイルを含む特殊なボリュームをマウントします。コンテナーの /etc/gitconfig ファイルには、Git サーバーホスト (その URL) と http セクションの証明書へのパスの情報が含まれます (git-config に関する Git ドキュメントを参照してください)。

    例3.15 /etc/gitconfig ファイルの内容

    [http "https://10.33.177.118:3000"]
    sslCAInfo = /etc/config/che-git-tls-creds/certificate

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

このセクションでは、OpenShift Dev Spaces ワークスペースの Pod に nodeSelector を設定する方法を説明します。

手順

  1. NodeSelector の使用

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

    spec:
      devEnvironments:
        nodeSelector:
          key: value

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

  2. テイントおよび容認の使用

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

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

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

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

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

CheCluster カスタムリソースを通じて、新しく作成された StorageClass の名前を OpenShift Dev Spaces に渡します。詳細は、「ストレージクラスの設定」 を参照してください。

3.5.5. VSX レジストリー URL を開く

エクステンションを検索してインストールするために、Microsoft Visual Studio Code - オープンソースエディターは、組み込みの Open VSX レジストリーインスタンスを使用します。組み込みのレジストリーインスタンスではなく、別の Open VSX レジストリーインスタンスを使用するように OpenShift Dev Spaces を設定することもできます。

手順

  • CheCluster カスタムリソースの spec.components.pluginRegistry.openVSXURL フィールドに Open VSX レジストリーインスタンスの URL を設定します。

    spec:
       components:
    # [...]
         pluginRegistry:
           openVSXURL: <your_open_vsx_registy>
    # [...]

3.5.6. ユーザー namespace の設定

この手順では、OpenShift Dev Spaces を使用して、ConfigMapsSecrets、および PersistentVolumeClaimopenshift-devspaces namespace から多数のユーザー固有の namespace に複製するプロセスを説明します。OpenShift Dev Spaces は、共有認証情報、設定ファイル、証明書などの重要な設定データのユーザー namespace への同期を自動化します。

openshift-devspaces namespace の Kubernetes リソースに変更を加えると、OpenShift Dev Spaces はすべてのユーザー namespace にわたって変更を直ちに複製します。逆に、Kubernetes リソースがユーザー namespace で変更されると、OpenShift Dev Spaces は変更を直ちに元に戻します。

手順

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

    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 を作成して、それをすべてのユーザー namespace に複製します。

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

    'PersistentVolumeClaim' を変更するには、一度削除し、openshift-devspaces namespace に新しいものを作成します。

    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
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.