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


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

3.4.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.4.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.4.3. 自己署名証明書を使用した Git

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

前提条件

  • OpenShift クラスターへの管理権限を持つアクティブな oc セッション。Getting started with the 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.14 /etc/gitconfig ファイルの内容

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

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

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

手順

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

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

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

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

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

3.4.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>
    # [...]
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.