3.4. 全局配置工作区

这部分论述了如何全局配置工作区。

3.4.1. 限制用户可以保留的工作区数量

默认情况下，用户可以在仪表板中保留无限个工作区，但您可以限制这个数量来减少对集群的需求。

此配置是 CheCluster 自定义资源的一部分： 

spec:
  components:
    cheServer:
      extraProperties:
        CHE_LIMITS_USER_WORKSPACES_COUNT: "<kept_workspaces_limit>" 1
1
设置每个用户的最大工作区数。默认值 -1 允许用户保留无限数量的工作区。使用正整数来设置每个用户的最大工作区数。

流程

  1. 获取 OpenShift Dev Spaces 命名空间的名称。默认为 openshift-devspaces。 

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

  2. 配置 CHE_LIMITS_USER_WORKSPACES_COUNT ： 

    $ oc patch checluster/devspaces -n openshift-devspaces \1
--type='merge' -p \
'{"spec":{"components":{"cheServer":{"extraProperties":{"CHE_LIMITS_USER_WORKSPACES_COUNT": "<kept_workspaces_limit>"}}}}}' 2
    1
    您在第 1 步中获得的 OpenShift Dev Spaces 命名空间。
    2
    您可以选择 < kept_workspaces_limit> 值。

其他资源

3.4.2. 允许用户同时运行多个工作区

默认情况下，用户一次只能运行一个工作区。您可以让用户同时运行多个工作区。

注意

如果使用默认存储方法，如果用户在多节点集群中分布 pod 时，当同时运行工作区时，用户可能会出现问题。从每位用户的 通用存储策略 切换到 每个工作区存储策略，或 使用临时存储 类型可以避免或解决这些问题。

此配置是 CheCluster 自定义资源的一部分： 

spec:
  components:
    devWorkspace:
      runningLimit: "<running_workspaces_limit>" 1
1
设置每个用户同时运行工作区的最大数量。默认值为：1。

流程

  1. 获取 OpenShift Dev Spaces 命名空间的名称。默认为 openshift-devspaces。 

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

  2. 配置 runningLimit ： 

    $ oc patch checluster/devspaces -n openshift-devspaces \1
--type='merge' -p \
'{"spec":{"components":{"devWorkspace":{"runningLimit": "<running_workspaces_limit>"}}}}' 2
    1
    您在第 1 步中获得的 OpenShift Dev Spaces 命名空间。
    2
    选择 < running_workspaces_limit> 值。

其他资源

3.4.3. 带有自签名证书的 Git

您可以配置 OpenShift Dev Spaces，以支持使用自签名证书的 Git 供应商上的操作。

先决条件

  • 具有 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=<host:port> -n openshift-devspaces  2
    1
    自签名证书的路径
    2
    Git 服务器上 HTTPS 连接的主机和端口（可选）。
    注意
    • 如果没有指定 githost，则给定证书适用于所有 HTTPS 存储库。
    • 证书文件通常存储为 Base64 ASCII 文件，例如：.pem、.crt、.ca-bundle.另外，它们可以编码为二进制数据，如 .cer。所有包含证书文件的 Secret 都应该使用 Base64 ASCII 证书而不是二进制数据证书。

  2. 在 ConfigMap 中添加所需的标签： 

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

  3. 配置 OpenShift Dev Spaces 操作对象，以便为 Git 存储库使用自签名证书。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。 

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

验证步骤

  • 创建并启动新工作区。工作区使用的每个容器都挂载一个带有自签名证书的文件的特殊卷。容器的 /etc/gitconfig 文件包含有关 Git 服务器主机( URL)和 http 部分中的证书路径的信息（请参阅关于 git-config的 Git 文档）。

    例 3.11. /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。此变量可以包含一组以逗号分隔的 key=value 对来组成 nodeSelector 规则，或 NULL 禁用它。 

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

nodeSelector 必须在 OpenShift Dev Spaces 安装过程中配置。这可防止现有工作区因为卷关联性冲突而运行失败，导致现有工作区 PVC 和 Pod 被调度到不同的区。

为了避免在大型多区集群上的不同区中调度 Pod 和 PVC，请创建一个额外的 StorageClass 对象（注意 允许的Topologies 字段），这将协调 PVC 创建过程。

通过 CHE_INFRA_KUBERNETES_PVC_STORAGE_CLASS_NAME 环境变量将这个新创建的 StorageClass 名称传递给 OpenShift Dev Spaces。这个变量的默认空值指示 OpenShift Dev Spaces 使用集群的默认 StorageClass。

其他资源

3.4.5. 打开 VSX registry URL

为了搜索并安装扩展，Visis Studio Code 编辑器使用嵌入的 Open VSX 注册表实例。您还可以将 OpenShift Dev Spaces 配置为使用另一个 Open VSX registry 实例，而不是嵌入的实例。

流程

  • 在 CheCluster Custom Resource spec.components.pluginRegistry.openVSXURL 字段中设置 Open VSX registry 实例的 URL。 

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

其他资源