管理指南


Red Hat OpenShift Dev Spaces 3.20

管理 Red Hat OpenShift Dev Spaces 3.20

Red Hat Developer Group Documentation Team

摘要

管理员运行 Red Hat OpenShift Dev Spaces 的信息。

第 1 章 安全最佳实践

获取 Red Hat OpenShift Dev Spaces 的关键最佳实践概述,可帮助您促进更具弹性的开发环境。

Red Hat OpenShift Dev Spaces 在 OpenShift 上运行,它为其上运行的产品提供平台以及产品的基础。OpenShift 文档是安全强化的入口点。

OpenShift 中的项目隔离

在 OpenShift 中,项目隔离与 Kubernetes 中的命名空间隔离类似,但通过项目的概念来实现。OpenShift 中的项目是顶级的组织单元,可在集群中的不同应用程序、团队或工作负载之间提供隔离和协作。

默认情况下,OpenShift Dev Spaces 为每个用户置备唯一的 & lt;username>-devspaces 项目。另外,集群管理员可以禁用 OpenShift 级别的项目自助置备,并在 CheCluster 自定义资源中关闭自动命名空间置备:

devEnvironments:
  defaultNamespace:
    autoProvision: false
Copy to Clipboard

使用这个设置,您可以获得一个策展对 OpenShift Dev Spaces 的访问,集群管理员对每个用户控制置备,并可以明确配置各种设置,包括资源限值和配额。在 第 4.2.2 节 “提前置备项目” 中了解更多有关项目置备的信息。

基于角色的访问控制(RBAC)

默认情况下,OpenShift Dev Spaces operator 会创建以下 ClusterRole:

  • <namespace>-cheworkspaces-clusterrole
  • <namespace>-cheworkspaces-devworkspace-clusterrole
注意

& lt;namespace > 前缀与 Red Hat OpenShift Dev Spaces CheCluster CR 所在的项目名称对应。

当用户第一次访问 Red Hat OpenShift Dev Spaces 时,对应的 RoleBinding 会在 < username>-devspaces 项目中创建。

下面列出了可授予用户在命名空间中要使用的所有资源和操作。

表 1.1. 用户命名空间中可用的资源和操作概述。
ResourcesActions

pods

"get", "list", "watch", "create", "delete", "update", "patch"

pods/exec

"get", "create"

pods/log

"get", "list", "watch"

pods/portforward

"get", "list", "create"

configmaps

"get", "list", "create", "update", "patch", "delete"

events

"list", "watch"

secrets

"get", "list", "create", "update", "patch", "delete"

services

"get", "list", "create", "delete", "update", "patch"

Routes

"get", "list", "create", "delete"

persistentvolumeclaims

"get", "list", "watch", "create", "delete", "update", "patch"

应用程序/部署

"get", "list", "watch", "create", "patch", "delete"

apps/replicasets

"get", "list", "patch", "delete"

命名空间

"get", "list"

projects

"get"

devworkspace

"get", "create", "delete", "list", "update", "patch", "watch"

devworkspacetemplates

"get", "create", "delete", "list", "update", "patch", "watch"

重要

每个用户仅被授予其命名空间的权限,无法访问其他用户的资源。集群管理员可以为用户添加额外权限。它们不应该删除默认授予的权限。

如需为 Red Hat OpenShift Dev Spaces 用户配置集群角色,请参阅产品文档。https://eclipse.dev/che/docs/stable/administration-guide/configuring-cluster-roles-for-users/

如需基于角色的访问控制的更多详细信息,请参阅 OpenShift 文档

开发环境隔离

开发环境的隔离使用 OpenShift 项目实施。每个开发人员都有一个项目,在其中创建和管理以下对象:

  • 云环境(CDE) Pod,包括 IDE 服务器。
  • 包含开发人员凭据的 secret,如 Git 令牌、SSH 密钥和 Kubernetes 令牌。
  • 带有开发人员特定配置的 ConfigMap,如 Git 名称和电子邮件。
  • 持久保留数据的卷,如源代码,即使 CDE Pod 停止了。
重要

对命名空间中的资源的访问权限必须限制为拥有它的开发人员。授予另一个开发人员读取访问权限等同于共享开发人员凭据,应该避免。

增强的授权

当前趋势是将基础架构分成几个 "fit for purpose" 集群,而不是具有 gigantic monolith OpenShift 集群。但是,管理员可能仍然希望提供粒度访问权限,并将某些功能的可用性限制为特定用户。

注意

"fit for purpose" OpenShift 集群指的是专门为满足特定用例或工作负载的要求和目标的集群。它基于它将管理的工作负载特性进行定制,以优化性能、资源利用率和其他因素。对于 Red Hat OpenShift Dev Spaces,建议置备这种类型的集群。

因此,可用于为不同组和用户设置粒度访问权限的可选属性包括在 CheCluster 自定义资源中:

  • AllowUsers
  • allowGroups
  • DenyUsers
  • denyGroups

以下是访问配置示例:

 networking:
    auth:
      advancedAuthorization:
        allowUsers:
          - user-a
          - user-b
        denyUsers:
          - user-c
        allowGroups:
          - openshift-group-a
          - openshift-group-b
        denyGroups:
          - openshift-group-c
Copy to Clipboard
注意

denyUsersdenyGroup 类别中的用户将无法使用 Red Hat OpenShift Dev Spaces,并在尝试访问用户仪表板时看到警告。

身份验证

只有经过身份验证的 OpenShift 用户可以访问 Red Hat OpenShift Dev Spaces。网关 Pod 使用基于角色的访问控制(RBAC)子系统来确定开发人员是否有权访问云开发环境(CDE)。

CDE Gateway 容器检查开发人员的 Kubernetes 角色。如果其角色允许访问 CDE Pod,则允许与开发环境的连接。默认情况下,只有命名空间的所有者有权访问 CDE Pod。

重要

对命名空间中的资源的访问权限必须限制为拥有它的开发人员。授予另一个开发人员 读取访问权限 等同于共享开发人员凭据,应该避免。

安全上下文和安全上下文约束

Red Hat OpenShift Dev Spaces 在 CDE Pod 容器安全上下文的规格中添加 SETGIDSETUID 功能:

"spec": {
  "containers": [
    "securityContext": {
            "allowPrivilegeEscalation": true,
            "capabilities": {
               "add": ["SETGID", "SETUID"],
               "drop": ["ALL","KILL","MKNOD"]
            },
            "readOnlyRootFilesystem": false,
            "runAsNonRoot": true,
            "runAsUser": 1001110000
   }
  ]
 }
Copy to Clipboard

这为用户提供了从 CDE 中构建容器镜像的功能。

默认情况下,Red Hat OpenShift Dev Spaces 将特定的 SecurityContextConstraint (SCC)分配给允许他们启动具有此类功能的 Pod 的用户。与默认 restricted SCC 相比,此 SCC 授予用户更多权限,但与 anyuid SCC 相比。此默认 SCC 在 OpenShift Dev Spaces 命名空间中预先创建,并命名为 container-build

在 CheCluster 自定义资源中设置以下属性可防止向用户分配额外的功能和 SCC:

spec:
  devEnvironments:
    disableContainerBuildCapabilities: true
Copy to Clipboard

资源配额和限值范围

资源配额和限值范围是 Kubernetes 功能,可用于帮助防止集群中的错误执行者和资源滥用。具体来说,它们允许您为 pod 和容器设置资源消耗限制。通过组合资源配额和限值范围,您可以强制执行特定于项目的策略,以防止不良的执行者消耗过量资源。

这些机制有助于提高 OpenShift 集群中的资源管理、稳定性和公平性。有关 资源配额和限值范围的更多详细信息 请参阅 OpenShift 文档。

断开连接的环境

air-gapped OpenShift 断开连接的集群指的是从互联网或任何外部网络隔离的 OpenShift 集群。这种隔离通常是出于安全原因来防止敏感或关键系统免受潜在的网络威胁。在 air-gapped 环境中,集群无法访问外部软件仓库或 registry 来下载容器镜像、更新或依赖项。

Red Hat OpenShift Dev Spaces 支持,并可在受限环境中安装。官方文档 中提供了安装说明。

管理扩展

默认情况下,Red Hat OpenShift Dev Spaces 包括嵌入式 Open VSX registry,其中包含 Microsoft Visual Studio Code - 开源编辑器的一组有限的扩展。另外,集群管理员也可以在自定义资源中指定不同的插件 registry,例如 https://open-vsx.org 包含数千个扩展。它们也可以构建自定义 Open VSX 注册表。有关管理 IDE 扩展的更多详细信息,请参阅 官方文档

重要

安装额外扩展会增加潜在的风险。要最小化这些风险,请确保只安装来自可靠源的扩展并定期更新它们。

Secrets

将敏感数据保存为用户命名空间机密中的 Kubernetes secret (如个人访问令牌(PAT)和 SSH 密钥)。

Git 存储库

在熟悉和您信任的 Git 存储库中操作至关重要。在将新依赖项合并到存储库中之前,请验证它们是否被维护,并定期发行更新以解决其代码中任何识别的安全漏洞。

第 2 章 准备安装

要准备 OpenShift Dev Spaces 安装,了解 OpenShift Dev Spaces 生态系统和部署限制:

2.1. 支持的平台

OpenShift Dev Spaces 在以下 CPU 架构的 OpenShift 4.14-4.18 上运行:

  • AMD64 和 Intel 64 (x86_64)
  • IBM Z (s390x)

以下 CPU 架构需要 Openshift 4.13-4.18 来运行 OpenShift Dev Spaces:

  • IBM Power (ppc64le)

其他资源

2.2. 安装 dsc 管理工具

您可以在 Microsoft Windows、Apple MacOS 和 Linux 上安装 dsc、Red Hat OpenShift Dev Spaces 命令行管理工具。使用 dsc,您可以对 OpenShift Dev Spaces 服务器执行操作,如启动、停止、更新和删除服务器。

先决条件

流程

  1. https://developers.redhat.com/products/openshift-dev-spaces/download 下载存档到目录,如 $HOME
  2. 在存档上运行 tar xvzf 以提取 /dsc 目录。
  3. 将提取的 /dsc/bin 子目录添加到 $PATH

验证

  • 运行 dsc 查看有关它的信息。

    $ dsc
    Copy to Clipboard

其他资源

2.3. 架构

图 2.1. 使用 Dev Workspace operator 的高级别 OpenShift Dev Spaces 架构

与 devworkspace 交互的 devspace

OpenShift Dev Spaces 在三个组件组上运行:

OpenShift Dev Spaces 服务器组件
管理用户项目和工作区.主要组件是 User dashboard,用户可从中控制其工作区。
dev Workspace operator
创建和控制运行用户工作区所需的 OpenShift 对象。包括 PodServicesPersistentVolume
用户工作区
基于容器的开发环境,包括 IDE。

这些 OpenShift 功能的角色是中心:

dev Workspace 自定义资源
代表用户工作区并由 OpenShift Dev Spaces 操作的有效 OpenShift 对象。它是三组组件的通信通道。
OpenShift 基于角色的访问控制(RBAC)
控制对所有资源的访问。

2.3.1. 服务器组件

OpenShift Dev Spaces 服务器组件确保多租户和工作区管理。

图 2.2. OpenShift Dev Spaces 服务器组件与 Dev Workspace operator 交互

与 devworkspace 交互的 devspaces 部署
2.3.1.1. dev Spaces operator

OpenShift Dev Spaces operator 确保 OpenShift Dev Spaces 服务器组件的完整生命周期管理。它引进了:

CheCluster 自定义资源定义(CRD)
定义 CheCluster OpenShift 对象。
OpenShift Dev Spaces 控制器
创建并控制所需的 OpenShift 对象,以运行 OpenShift Dev Spaces 实例,如 pod、服务和持久性卷。
CheCluster 自定义资源(CR)

在使用 OpenShift Dev Spaces operator 的集群中,可以创建 CheCluster 自定义资源(CR)。OpenShift Dev Spaces operator 可确保此 OpenShift Dev Spaces 实例中 OpenShift Dev Spaces 服务器组件的完整生命周期管理:

2.3.1.2. dev Workspace operator

Dev Workspace operator 扩展 OpenShift 以提供 Dev Workspace 支持。它引进了:

dev Workspace 自定义资源定义
从 Devfile v2 规范定义 Dev Workspace OpenShift 对象。
dev Workspace 控制器
创建和控制所需的 OpenShift 对象,以运行 Dev Workspace,如 Pod、服务和持久卷。
dev Workspace 自定义资源
在使用 Dev Workspace operator 的集群中,可以创建 Dev Workspace 自定义资源(CR)。Dev Workspace CR 是 Devfile 的 OpenShift 表示。它在 OpenShift 集群中定义一个用户工作区。

其他资源

2.3.1.3. 网关

OpenShift Dev Spaces 网关有以下角色:

  • 路由请求.它使用 Traefik
  • 使用 OpenID Connect (OIDC)验证用户。它使用 OpenShift OAuth2 代理
  • 应用 OpenShift 基于角色的访问控制(RBAC)策略来控制对任何 OpenShift Dev Spaces 资源的访问。它使用 'kube-rbac-proxy'

OpenShift Dev Spaces operator 将其作为 che-gateway 部署进行管理。

它控制对以下的访问:

图 2.3. OpenShift Dev Spaces 网关与其他组件交互

OpenShift Dev Spaces 网关与其他组件交互
2.3.1.4. 用户仪表板

用户仪表板是 Red Hat OpenShift Dev Spaces 的登录页面。OpenShift Dev Spaces 用户浏览用户仪表板以访问和管理其工作区。这是一个 React 应用程序。OpenShift Dev Spaces 部署在 devspaces-dashboard Deployment 中启动。

它需要访问:

图 2.4. 用户仪表板与其他组件的交互

用户仪表板与其他组件的交互

当用户请求用户仪表板启动工作区时,用户仪表板会执行这个操作序列:

  1. 将存储库 URL 发送到 第 2.3.1.5 节 “dev Spaces server”,并在用户从远程 devfile 创建工作区时返回 devfile。
  2. 读取描述工作区的 devfile。
  3. 第 2.3.1.6 节 “插件 registry” 收集其他元数据。
  4. 将信息转换为 Dev Workspace 自定义资源。
  5. 使用 OpenShift API 在用户项目中创建 Dev Workspace 自定义资源。
  6. 监视 Dev Workspace 自定义资源状态。
  7. 将用户重定向到正在运行的工作区 IDE。
2.3.1.5. dev Spaces server

其他资源

OpenShift Dev Spaces 服务器主要功能有:

  • 创建用户命名空间。
  • 使用所需的 secret 和配置映射置备用户命名空间。
  • 与 Git 服务供应商集成,以获取和验证 devfile 和身份验证。

OpenShift Dev Spaces 服务器是一个 Java Web 服务,公开 HTTP REST API 并需要访问:

  • Git 服务供应商
  • OpenShift API

图 2.5. OpenShift Dev Spaces 服务器与其他组件交互

OpenShift Dev Spaces 服务器与其他组件交互
2.3.1.6. 插件 registry

每个 OpenShift Dev Spaces 工作区都以特定的编辑器和一组关联的扩展开始。OpenShift Dev Spaces 插件 registry 提供了可用编辑器和编辑器扩展列表。Devfile v2 描述了每个编辑器或扩展。

第 2.3.1.4 节 “用户仪表板” 读取 registry 的内容。

图 2.6. 插件 registry 与其他组件交互

插件 registry 与其他组件交互

2.3.2. 用户工作区

图 2.7. 用户工作区与其他组件交互

用户工作区与其他组件交互

用户工作区是在容器中运行的 Web IDE。

用户工作区是一个 Web 应用程序。它由容器中运行的微服务组成,提供在浏览器中运行的现代 IDE 的所有服务:

  • Editor
  • 语言自动完成
  • 语言服务器
  • 调试工具
  • 插件
  • 应用程序运行时

工作区是一个 OpenShift Deployment,其中包含工作区容器和启用的插件,以及相关的 OpenShift 组件:

  • 容器
  • ConfigMaps
  • 服务
  • Endpoints
  • ingresses 或 Routes
  • Secrets
  • 持久性卷(PV)

OpenShift Dev Spaces 工作区包含项目的源代码,保留在 OpenShift 持久性卷(PV)中。微服务对该共享目录具有读/写访问权限。

使用 devfile v2 格式指定 OpenShift Dev Spaces 工作区的工具和运行时应用程序。

下图显示了一个运行 OpenShift Dev Spaces 工作区及其组件。

图 2.8. OpenShift Dev Spaces 工作区组件

工作区组件

在图中,有一个正在运行的工作区。

2.4. 计算 Dev Spaces 资源要求

OpenShift Dev Spaces Operator、Dev Workspace Controller 和用户工作区由一组 pod 组成。pod 贡献 CPU 和内存限值和请求中的资源消耗。

注意

以下示例 devfile 的链接是从上游社区的指向材料的指针。本材料代表了非常最新的可用内容和最新最佳实践。这些提示尚未由红帽的 QE 部门审查,并且尚未由广泛的用户组验证。请小心使用此信息。它最适合用于教育和"开发"目的,而不是"生产"目的。

流程

  1. 识别依赖于用于定义开发环境的 devfile 的工作区资源要求。这包括识别 devfile 的 components 部分明确指定的工作区组件。

    • 以下是带有 以下组件的 devfile 示例

      例 2.1. 工具

      devfile 的工具 组件定义了以下请求和限制:

          memoryLimit: 6G
          memoryRequest: 512M
          cpuRequest: 1000m
          cpuLimit: 4000m
      Copy to Clipboard
    • 在工作区启动过程中,使用以下请求和限制隐式置备内部 che-gateway 容器:

          memoryLimit: 256M
          memoryRequest: 64M
          cpuRequest: 50m
          cpuLimit: 500m
      Copy to Clipboard
  2. 计算每个工作区所需的资源总和。如果要使用多个 devfile,请对每个预期的 devfile 重复这个计算。

    例 2.2. 上一步中 示例 devfile 的工作区要求

    用途Pod容器名称内存限制内存请求CPU 限制CPU 请求

    开发人员工具

    工作区

    工具

    6 GiB

    512 MiB

    4000 m

    1000 m

    OpenShift Dev Spaces 网关

    工作区

    che-gateway

    256 MiB

    64 MiB

    500 m

    50 M

    总计

    6.3 GiB

    576 MiB

    4500 m

    1050 m

  3. 将每个工作区的资源乘以您希望所有用户同时运行的工作区数。
  4. 计算 OpenShift Dev Spaces Operator、Operands 和 Dev Workspace Controller 的要求总和。

    表 2.1. OpenShift Dev Spaces Operator、Operands 和 Dev Workspace Controller 的默认要求
    用途Pod 名称容器名称内存限制内存请求CPU 限制CPU 请求

    OpenShift Dev Spaces operator

    devspaces-operator

    devspaces-operator

    256 MiB

    64 MiB

    500 m

    100 m

    OpenShift Dev Spaces Server

    devspaces

    devspaces-server

    1 GiB

    512 MiB

    1000 m

    100 m

    OpenShift Dev Spaces Dashboard

    devspaces-dashboard

    devspaces-dashboard

    256 MiB

    32 MiB

    500 m

    100 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    traefik

    4 GiB

    128 MiB

    1000 m

    100 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    configbump

    256 MiB

    64 MiB

    500 m

    50 M

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    oauth-proxy

    512 MiB

    64 MiB

    500 m

    100 m

    OpenShift Dev Spaces Gateway

    devspaces-gateway

    kube-rbac-proxy

    512 MiB

    64 MiB

    500 m

    100 m

    Devfile registry

    devfile-registry

    devfile-registry

    256 MiB

    32 MiB

    500 m

    100 m

    插件 registry

    plugin-registry

    plugin-registry

    256 MiB

    32 MiB

    500 m

    100 m

    dev Workspace Controller Manager

    devworkspace-controller-manager

    devworkspace-controller

    1 GiB

    100 MiB

    1000 m

    250 m

    dev Workspace Controller Manager

    devworkspace-controller-manager

    kube-rbac-proxy

    不适用

    不适用

    不适用

    不适用

    dev Workspace webhook 服务器

    devworkspace-webhook-server

    webhook-server

    300 MiB

    20 MiB

    200 m

    100 m

    dev Workspace Operator Catalog

    devworkspace-operator-catalog

    registry-server

    不适用

    50 MiB

    不适用

    10 m

    dev Workspace Webhook 服务器

    devworkspace-webhook-server

    webhook-server

    300 MiB

    20 MiB

    200 m

    100 m

    dev Workspace Webhook 服务器

    devworkspace-webhook-server

    kube-rbac-proxy

    不适用

    不适用

    不适用

    不适用

    总计

    9 GiB

    1.2 GiB

    6.9

    1.3

第 3 章 安装 Dev Spaces

本节包含安装 Red Hat OpenShift Dev Spaces 的说明。

您只能为每个集群部署一个 OpenShift Dev Spaces 实例。

3.1. 在云中安装 Dev Spaces

在云中部署和运行 Red Hat OpenShift Dev Spaces。

先决条件

3.1.1. 在云中部署 OpenShift Dev Spaces

按照以下说明,使用 dsc 工具启动云中的 OpenShift Dev Spaces 服务器。

3.1.2. 使用 CLI 在 OpenShift 上安装 Dev Spaces

您可以在 OpenShift 上安装 OpenShift Dev Spaces。

先决条件

流程

  1. 可选:如果您之前在此 OpenShift 集群中部署了 OpenShift Dev Spaces,请确保删除了以前的 OpenShift Dev Spaces 实例:

    $ dsc server:delete
    Copy to Clipboard
  2. 创建 OpenShift Dev Spaces 实例:

    $ dsc server:deploy --platform openshift
    Copy to Clipboard

验证步骤

  1. 验证 OpenShift Dev Spaces 实例状态:

    $ dsc server:status
    Copy to Clipboard
  2. 进入到 OpenShift Dev Spaces 集群实例:

    $ dsc dashboard:open
    Copy to Clipboard

3.1.3. 使用 Web 控制台在 OpenShift 上安装 Dev Spaces

如果在 命令行 上安装 OpenShift Dev Spaces 时遇到问题,您可以通过 OpenShift Web 控制台安装它。

先决条件

流程

  1. 在 OpenShift Web 控制台的 Administrator 视图中,进入 OperatorsOperatorHub 并搜索 Red Hat OpenShift Dev Spaces
  2. 安装 Red Hat OpenShift Dev Spaces Operator。

    提示
    小心

    Red Hat OpenShift Dev Spaces Operator 依赖于 Dev Workspace Operator。如果您手动将 Red Hat OpenShift Dev Spaces Operator 安装到非默认命名空间中,请确保同时安装了 Dev Workspace Operator。这是必需的,因为 Operator Lifecycle Manager 将尝试将 Dev Workspace Operator 作为 Red Hat OpenShift Dev Spaces Operator 命名空间中的依赖项安装,如果后者在不同的命名空间中安装,可能会导致 Dev Workspace Operator 的两个冲突安装。

小心

如果要在集群中加入 Web Terminal Operator,请确保使用与 Red Hat OpenShift Dev Spaces Operator 相同的安装命名空间,因为它们都依赖于 Dev Workspace Operator。Web Terminal Operator、Red Hat OpenShift Dev Spaces Operator 和 Dev Workspace Operator 必须安装在同一个命名空间中。

  1. 在 OpenShift 中创建 openshift-devspaces 项目,如下所示:

    oc create namespace openshift-devspaces
    Copy to Clipboard
  2. 进入 OperatorsInstalled OperatorsRed Hat OpenShift Dev Spaces 实例 SpecificationCreate CheClusterYAML view
  3. YAML 视图中,将 namespace: openshift-operators 替换为 namespace: openshift-devspaces
  4. 选择 Create

    提示

验证

  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 部署的资源及其状态。

3.1.4. 在受限环境中安装 Dev Spaces

在受限网络中运行的 OpenShift 集群上,无法使用公共资源。

但是,部署 OpenShift Dev Spaces 并运行工作区需要以下公共资源:

  • Operator 目录
  • 容器镜像
  • 示例项目

要使这些资源可用,您可以将它们替换为 OpenShift 集群可访问的注册表中的副本。

先决条件

流程

  1. 下载并执行镜像脚本,以安装自定义 Operator 目录并镜像相关镜像: prepare-restricted-environment.sh

    $ bash prepare-restricted-environment.sh \
      --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.18\
      --devworkspace_operator_version "v0.33.0" \
      --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.18" \
      --prod_operator_package_name "devspaces" \
      --prod_operator_bundle_name "devspacesoperator" \
      --prod_operator_version "v3.20.0" \
      --my_registry "<my_registry>" 
    1
    Copy to Clipboard
    1
    镜像要镜像的专用 Docker registry
  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
    Copy to Clipboard
  3. 允许来自 OpenShift Dev Spaces 命名空间中的传入流量到用户项目中的所有 Pod。请参阅:第 4.8.1 节 “配置网络策略”
3.1.4.1. 设置 Ansible 示例

按照以下步骤在受限环境中使用 Ansible 示例。

先决条件

  • Microsoft Visual Studio Code - Open Source IDE
  • 64 位 x86 系统。

流程

  1. 镜像以下镜像:

    ghcr.io/ansible/ansible-devspaces@sha256:a28fa23d254ff1b3ae10b95a0812132148f141bda4516661e40d0c49c4ace200
    registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb
    Copy to Clipboard
  2. 配置集群代理以允许访问以下域:

    .ansible.com
    .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com
    Copy to Clipboard
注意

计划在以后的版本中对以下 IDE 和 CPU 架构的支持:

  • IDE

  • CPU 架构

    • IBM Power (ppc64le)
    • IBM Z (s390x)

3.2. 查找完全限定域名(FQDN)

您可以在命令行中或 OpenShift Web 控制台中获取机构 OpenShift Dev Spaces 实例的完全限定域名(FQDN)。

提示

您可以在 OpenShift Web 控制台的 Administrator 视图中找到机构的 OpenShift Dev Spaces 实例的 FQDN,如下所示。进入 OperatorsInstalled OperatorsRed Hat OpenShift Dev Spaces 实例 SpecificationdevspacesRed Hat OpenShift Dev Spaces URL

先决条件

流程

  1. 运行以下命令:

    oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'
    Copy to Clipboard

3.3. 安装 Dev Spaces 的权限

了解在不同 Kubernetes 集群上安装 Red Hat OpenShift Dev Spaces 所需的权限。

3.3.1. 使用 CLI 在 OpenShift 上安装 Dev Spaces 的权限

以下是使用 dsc 在 OpenShift 集群上安装 OpenShift Dev Spaces 所需的最小权限集:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devspaces-install-dsc
rules:
- apiGroups: ["org.eclipse.che"]
  resources: ["checlusters"]
  verbs: ["*"]
- apiGroups: ["project.openshift.io"]
  resources: ["projects"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "create"]
- apiGroups: [""]
  resources: ["pods", "configmaps"]
  verbs: ["get", "list"]
- apiGroups: ["route.openshift.io"]
  resources: ["routes"]
  verbs: ["get", "list"]
  # OLM resources permissions
- apiGroups: ["operators.coreos.com"]
  resources: ["catalogsources", "subscriptions"]
  verbs: ["create", "get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
  resources: ["operatorgroups", "clusterserviceversions"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
  resources: ["installplans"]
  verbs: ["patch", "get", "list", "watch"]
- apiGroups: ["packages.operators.coreos.com"]
  resources: ["packagemanifests"]
  verbs: ["get", "list"]
Copy to Clipboard

3.3.2. 使用 Web 控制台在 OpenShift 上安装 Dev Spaces 的权限

以下是使用 Web 控制台在 OpenShift 集群上安装 OpenShift Dev Spaces 所需的最小权限集:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: devspaces-install-web-console
rules:
- apiGroups: ["org.eclipse.che"]
  resources: ["checlusters"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "create"]
- apiGroups: ["project.openshift.io"]
  resources: ["projects"]
  verbs: ["get", "list", "create"]
  # OLM resources permissions
- apiGroups: ["operators.coreos.com"]
  resources: ["subscriptions"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["operators.coreos.com"]
  resources: ["operatorgroups"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
  resources: ["clusterserviceversions", "catalogsources", "installplans"]
  verbs: ["get", "list", "watch", "delete"]
- apiGroups: ["packages.operators.coreos.com"]
  resources: ["packagemanifests", "packagemanifests/icon"]
  verbs: ["get", "list", "watch"]
  # Workaround related to viewing operators in OperatorHub
- apiGroups: ["operator.openshift.io"]
  resources: ["cloudcredentials"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["config.openshift.io"]
  resources: ["infrastructures", "authentications"]
  verbs: ["get", "list", "watch"]
Copy to Clipboard

第 4 章 配置 Dev Spaces

本节论述了 Red Hat OpenShift Dev Spaces 的配置方法和选项。

4.1. 了解 CheCluster 自定义资源

OpenShift Dev Spaces 的默认部署由 Red Hat OpenShift Dev Spaces Operator 由一个 CheCluster 自定义资源参数组成。

CheCluster 自定义资源是一个 Kubernetes 对象。您可以通过编辑 CheCluster 自定义资源 YAML 文件来配置它。此文件包含配置每个组件的部分: devWorkspacecheServerpluginRegistrydevfileRegistry仪表板和 imagePuller

Red Hat OpenShift Dev Spaces Operator 将 CheCluster 自定义资源转换为 OpenShift Dev Spaces 安装的每个组件可用的配置映射中。

OpenShift 平台将配置应用到每个组件,并创建所需的 Pod。当 OpenShift 检测到一个组件的配置中有更改时,它会相应地重启 Pod。

例 4.1. 配置 OpenShift Dev Spaces 服务器组件的主要属性

  1. cheServer 组件部分中应用带有适当修改的 CheCluster 自定义资源 YAML 文件。
  2. Operator 生成 che ConfigMap
  3. OpenShift 检测到 ConfigMap 中的更改,并触发 OpenShift Dev Spaces Pod 重启。

4.1.1. 在安装过程中使用 dsc 配置 CheCluster 自定义资源

要使用合适的配置部署 OpenShift Dev Spaces,请在安装 OpenShift Dev Spaces 的过程中编辑 CheCluster 自定义资源 YAML 文件。否则,OpenShift Dev Spaces 部署使用 Operator 的默认配置参数。

先决条件

流程

  • 创建一个 che-operator-cr-patch.yaml YAML 文件,其中包含要配置的 CheCluster 自定义资源的子集:

    spec:
      <component>:
          <property_to_configure>: <value>
    Copy to Clipboard
  • 部署 OpenShift Dev Spaces 并应用 che-operator-cr-patch.yaml 文件中描述的更改:

    $ dsc server:deploy \
    --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \
    --platform <chosen_platform>
    Copy to Clipboard

验证

  1. 验证配置的属性的值:

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

4.1.2. 使用 CLI 配置 CheCluster 自定义资源

要配置 OpenShift Dev Spaces 的运行实例,请编辑 CheCluster 自定义资源 YAML 文件。

先决条件

  • OpenShift 上的 OpenShift Dev Spaces 实例。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 编辑集群中的 CheCluster 自定义资源:

    $ oc edit checluster/devspaces -n openshift-devspaces
    Copy to Clipboard
  2. 保存并关闭该文件以应用更改。

验证

  1. 验证配置的属性的值:

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

4.1.3. CheCluster 自定义资源字段参考

本节介绍可用于自定义 CheCluster 自定义资源的所有字段。

例 4.2. 最小的 CheCluster 自定义资源示例。

apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
  name: devspaces
  namespace: openshift-devspaces
spec:
  components: {}
  devEnvironments: {}
  networking: {}
Copy to Clipboard
表 4.1. 开发环境配置选项。
属性描述default

allowedSources

AllowedSources 定义可以在其上启动工作区的允许源。

 

containerBuildConfiguration

容器构建配置。

 

defaultComponents

应用到 DevWorkspace 的默认组件。这些默认组件旨在在 Devfile (不包含任何组件)时使用。

 

defaultEditor

要创建工作区的默认编辑器。它可以是插件 ID 或 URI。插件 ID 必须具有 publisher/name/version 格式。URI 必须从 http://https:// 开始。

 

defaultNamespace

用户的默认命名空间。

{ "autoProvision": true, "template": "<username>-che"}

defaultPlugins

应用到 DevWorkspace 的默认插件。

 

deploymentStrategy

DeploymentStrategy 定义部署策略,用于将现有工作区 pod 替换为新 pod。可用的部署模块是 RecreateRollingUpdate。使用 Recreate 部署策略时,现有工作区 pod 会在创建新工作区 pod 前被终止。使用 RollingUpdate 部署策略时,会创建一个新的工作区 pod,只有在新的工作区 pod 处于 ready 状态时,才会删除现有工作区 pod。如果没有指定,则使用默认的 Recreate 部署策略。

 

disableContainerBuildCapabilities

禁用容器构建功能。当设置为 false (默认值)时,devEnvironments.security.containerSecurityContext 字段会被忽略,并应用了以下容器 SecurityContext: containerSecurityContext: allowPrivilegeEscalation: true capabilities: add: - SETGID - SETUID

 

gatewayContainer

GatewayContainer 配置。

 

ignoredUnrecoverableEvents

IgnoredUnrecoverableEvents 定义在决定失败启动的工作区时应忽略的 Kubernetes 事件名称列表。如果临时集群问题触发假正(例如,如果集群偶尔遇到 FailedScheduling 事件),则应使用此选项。此处列出的事件不会触发工作区失败。

[ "FailedScheduling"]

imagePullPolicy

imagePullPolicy 定义用于 DevWorkspace 中容器的 imagePullPolicy。

 

maxNumberOfRunningWorkspacesPerCluster

在整个 Kubernetes 集群中同时运行的最大工作区数。这适用于系统中的所有用户。如果值设为 -1,这表示运行工作区的数量没有限制。

 

maxNumberOfRunningWorkspacesPerUser

每个用户的最大运行工作区数。值 -1 允许用户运行无限数量的工作区。

 

maxNumberOfWorkspacesPerUser

用户可以保留的工作区总数,包括已停止和运行。值 -1 允许用户保留无限数量的工作区。

-1

nodeSelector

节点选择器限制可运行工作区 pod 的节点。

 

persistUserHome

PersistUserHome 定义用于在工作区中保留用户主目录的配置选项。

 

podSchedulerName

工作区 pod 的 Pod 调度程序。如果没有指定,pod 调度程序被设置为集群中的默认调度程序。

 

projectCloneContainer

项目克隆容器配置。

 

runtimeClassName

runtimeClassName 为工作区 pod 指定 spec.runtimeClassName。

 

secondsOfInactivityBeforeIdling

空闲的超时时间(以秒为单位)。此超时是持续时间,之后如果没有活动,则工作区将闲置。要禁用因为不活跃的工作区闲置,请将此值设置为 -1。

1800

secondsOfRunBeforeIdling

为工作区运行超时(以秒为单位)。此超时是工作区运行的最长持续时间。要禁用工作区运行超时,请将此值设置为 -1。

-1

安全

工作区安全配置。

 

serviceAccount

启动工作区时,由 DevWorkspace operator 使用的 ServiceAccount。

 

serviceAccountTokens

将作为投射卷挂载到工作区 pod 中的 ServiceAccount 令牌列表。

 

startTimeoutSeconds

StartTimeoutSeconds 决定工作区在自动失败前可以开始的最长时间(以秒为单位)。如果没有指定,则使用默认值 300 秒(5 分钟)。

300

storage

工作区持久性存储。

{ "pvcStrategy": "per-user"}

容限(tolerations)

工作区 pod 的 pod 容限限制工作区 pod 可以运行的位置。

 

trustedCerts

可信证书设置。

 

user

用户配置。

 

workspacesPodAnnotations

WorkspacesPodAnnotations 为工作区 pod 定义额外的注解。

 
表 4.2. defaultNamespace 选项。
属性描述default

autoProvision

指明是否允许自动创建用户命名空间。如果设置为 false,则集群管理员必须预先创建用户命名空间。

true

模板

如果您没有提前创建用户命名空间,此字段定义启动第一个工作区时创建的 Kubernetes 命名空间。您可以使用 < username> 和 & lt;userid& gt; 占位符,如 che-workspace-<username>。

"<username>-che"

表 4.3. defaultPlugins 选项。
属性描述default

Editor

用于指定默认插件的编辑器 ID。插件 ID 必须具有 publisher/name/version 格式。

 

plugins

指定编辑器的默认插件 URI。

 
表 4.4. gatewayContainer 选项。
属性描述default

env

容器中要设置的环境变量列表。

 

image

容器镜像。省略它或留空,以使用 Operator 提供的默认容器镜像。

 

imagePullPolicy

镜像拉取(pull)策略。对于 每天下一个最新的镜像,默认值为 Always,其他情况下为 IfNotPresent

 

name

容器名称。

 

resources

此容器所需的计算资源。

 
表 4.5. 存储选项。
属性描述default

perUserStrategyPvcConfig

使用 per-user PVC 策略时的 PVC 设置。

 

perWorkspaceStrategyPvcConfig

使用 per-workspace PVC 策略时的 PVC 设置。

 

pvcStrategy

OpenShift Dev Spaces 服务器的持久性卷声明策略。支持的策略有:per-user(一个卷中的所有工作区 PVC)、per-workspace(每个工作区都有自己的独立 PVC)和 ephemeral(非持久性存储,当工作区停止时本地的变化会丢失。)

"per-user"

表 4.6. 每个用户 PVC 策略选项。
属性描述default

claimSize

持久性卷声明大小。要更新声明大小,置备它的存储类必须支持调整大小。

 

storageClass

持久性卷声明的存储类。当省略或留空时,会使用默认存储类。

 
表 4.7. 每个工作区 PVC 策略选项。
属性描述default

claimSize

持久性卷声明大小。要更新声明大小,置备它的存储类必须支持调整大小。

 

storageClass

持久性卷声明的存储类。当省略或留空时,会使用默认存储类。

 
表 4.8. trustedCerts 选项。
属性描述default

disableWorkspaceCaBundleMount

默认情况下,Operator 会在两个位置创建并挂载包含用户"工作区中的 CA 证书捆绑包的 'ca-certs-merged' ConfigMap: '/public-certs' 和 '/etc/pki/ca-trust/extracted/pem'。'/etc/pki/ca-trust/extracted/pem' 目录是系统存储红帽可信证书颁发机构提取的 CA 证书(如 CentOS、Fedora)。这个选项禁止将 CA 捆绑包挂载到 '/etc/pki/ca-trust/extracted/pem' 目录,同时仍然将其挂载到 '/public-certs'。

 

gitTrustedCertsConfigMapName

ConfigMap 包含要传播到 OpenShift Dev Spaces 组件的证书,并为 Git 提供特定的配置。请参见以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/deploying-che-with-support-for-git-repositories-with-self-signed-certificates/ ConfigMap 必须有一个 app.kubernetes.io/part-of=che.eclipse.org 标签。

 
表 4.9. containerBuildConfiguration 选项。
属性描述default

openShiftSecurityContextConstraint

构建容器的 OpenShift 安全性上下文约束。

"Container-build"

表 4.10. OpenShift Dev Spaces 组件配置。
属性描述default

cheServer

与 OpenShift Dev Spaces 服务器相关的常规配置设置。

{ "debug": false, "logLevel": "INFO"}

dashboard

与 OpenShift Dev Spaces 安装使用的仪表板相关的配置设置。

 

devWorkspace

DevWorkspace Operator 配置。

 

devfileRegistry

与 OpenShift Dev Spaces 安装使用的 devfile registry 相关的配置设置。

 

imagePuller

Kubernetes Image Puller 配置。

 

metrics

OpenShift Dev Spaces 服务器指标配置。

{ "enable": true}

pluginRegistry

与 OpenShift Dev Spaces 安装使用的插件 registry 相关的配置设置。

 
表 4.11. 与 OpenShift Dev Spaces 服务器组件相关的常规配置设置。
属性描述default

clusterRoles

分配给 OpenShift Dev Spaces ServiceAccount 的额外 ClusterRole。每个角色都必须有一个 app.kubernetes.io/part-of=che.eclipse.org 标签。默认角色为: - < devspaces-namespace>-cheworkspaces-clusterrole - <devspaces-namespace>-cheworkspaces-namespaces-clusterrole - <devspaces-namespace>-cheworkspaces-devworkspace-clusterrole,其中 <devspaces-namespace> 是创建 CheCluster CR 的命名空间。OpenShift Dev Spaces Operator 必须具有这些 ClusterRole 的所有权限才能授予它们。

 

debug

为 OpenShift Dev Spaces 服务器启用调试模式。

false

部署

部署覆盖选项。

 

extraProperties

在生成的 che ConfigMap 中应用的附加环境变量映射,供 OpenShift Dev Spaces 服务器使用,除了已经从 CheCluster 自定义资源(CR)的其他字段生成的值之外。如果 extraProperties 字段包含通常由其他 CR 字段在 che ConfigMap 中生成的属性,则改为使用 extraProperties 中定义的值。

 

logLevel

OpenShift Dev Spaces 服务器的日志级别: INFODEBUG

"INFO"

proxy

Kubernetes 集群的代理服务器设置。OpenShift 集群不需要额外的配置。通过为 OpenShift 集群指定这些设置,您可以覆盖 OpenShift 代理配置。

 
表 4.12. 代理 选项。
属性描述default

credentialsSecretName

包含代理服务器 的用户名和密码 的 secret 名称。secret 必须具有 app.kubernetes.io/part-of=che.eclipse.org 标签。

 

nonProxyHosts

可直接到达的主机列表,绕过代理。指定通配符域使用以下形式 .<DOMAIN& gt;,例如: - localhost - 127.0.0.1 - my.host.com - 123.42.12.32 仅在需要代理配置时使用。Operator 遵循 OpenShift 集群范围的代理配置,在自定义资源中定义 非ProxyHosts 会导致从集群代理配置中定义非代理主机列表,以及自定义资源中定义的列表。请参见以下页面 :https://docs.openshift.com/container-platform/latest/networking/enable-cluster-wide-proxy.html。在一些代理配置中,localhost 可能不会转换为 127.0.0.1。在这种情况下,应该同时指定 localhost 和 127.0.0.1。

 

port

代理服务器端口。

 

url

代理服务器的 URL (protocol+hostname)。仅在需要代理配置时使用。Operator 遵循 OpenShift 集群范围的代理配置,在自定义资源中定义 url 会导致覆盖集群代理配置。请参见以下页面 :https://docs.openshift.com/container-platform/latest/networking/enable-cluster-wide-proxy.html。

 
表 4.13. 与 OpenShift Dev Spaces 安装使用的插件 registry 组件相关的配置设置。
属性描述default

部署

部署覆盖选项。

 

disableInternalRegistry

禁用内部插件 registry。

 

externalPluginRegistries

外部插件 registry。

 

openVSXURL

打开 VSX 注册表 URL。如果省略了嵌入的实例。

 
表 4.14. externalPluginRegistries 选项。
属性描述default

url

插件 registry 的公共 URL。

 
表 4.15. 与 OpenShift Dev Spaces 安装使用的 Devfile registry 组件相关的配置设置。
属性描述default

部署

弃用的部署覆盖选项。

 

disableInternalRegistry

禁用内部 devfile registry。

 

externalDevfileRegistries

外部 devfile registry 为示例可用的 devfile 提供示例。

 
表 4.16. externalDevfileRegistries 选项。
属性描述default

url

提供示例 ready-to-use devfiles 的 devfile registry 的公共 URL。

 
表 4.17. 与 OpenShift Dev Spaces 安装使用的 Dashboard 组件相关的配置设置。
属性描述default

品牌

仪表板品牌资源.

 

部署

部署覆盖选项。

 

headerMessage

仪表板标题消息。

 

logLevel

控制面板的日志级别。

"ERROR"

表 4.18. headerMessage 选项。
属性描述default

显示

指示仪表板显示消息。

 

text

用户仪表板上显示警告消息。

 
表 4.19. Kubernetes Image Puller 组件配置。
属性描述default

enable

安装和配置社区支持的 Kubernetes Image Puller Operator。当您在不提供任何 spec 的情况下将值设为 true 时,它会创建一个由 Operator 管理的默认 Kubernetes Image Puller 对象。当您将值设为 false 时,Kubernetes Image Puller 对象会被删除,并且 Operator 卸载,无论是否提供了 spec。如果将 spec.images 字段留空,则会自动检测到一组推荐的与工作区相关的镜像,并在安装后预先拉取。请注意,虽然此 Operator 及其行为由社区支持,但其有效负载可能被商业支持用于拉取商业支持的镜像。

 

spec

在 CheCluster 中配置镜像拉取器的 Kubernetes Image Puller spec。

 
表 4.20. OpenShift Dev Spaces 服务器指标组件配置。
属性描述default

enable

为 OpenShift Dev Spaces 服务器端点启用 指标

true

表 4.21. 允许用户处理远程 Git 存储库的配置设置。
属性描述default

azure

让用户能够处理托管在 Azure DevOps Service (dev.azure.com)上的存储库。

 

Bitbucket

允许用户处理托管在 Bitbucket 上的存储库(bitbucket.org 或自托管)。

 

github

允许用户使用托管在 GitHub 上的软件仓库(github.com 或 GitHub Enterprise)。

 

gitlab

让用户能够处理托管在 GitLab 上的存储库(gitlab.com 或自托管)。

 
表 4.22. GitHub 选项。
属性描述default

disableSubdomainIsolation

禁用子域隔离。弃用了 che.eclipse.org/scm-github-disable-subdomain-isolation 注解。详情请查看以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/。

 

端点

GitHub 服务器端点 URL。弃用了 che.eclipse.org/scm-server-endpoint 注解。详情请查看以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/。

 

secretName

Kubernetes secret,其中包含 Base64 编码的 GitHub OAuth 客户端 ID 和 GitHub OAuth 客户端 secret。详情请查看以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/。

 
表 4.23. GitLab 选项。
属性描述default

端点

GitLab 服务器端点 URL。弃用了 che.eclipse.org/scm-server-endpoint 注解。请参见以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/。

 

secretName

Kubernetes secret,其中包含 Base64 编码的 GitHub Application id 和 GitLab Application Client secret。请参见以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/。

 
表 4.24. Bitbucket 选项。
属性描述default

端点

Bitbucket 服务器端点 URL。弃用了 che.eclipse.org/scm-server-endpoint 注解。请参见以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-1-for-a-bitbucket-server/。

 

secretName

Kubernetes secret,其中包含 Base64 编码的 Bitbucket OAuth 1.0 或 OAuth 2.0 数据。详情请查看以下页面: https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-1-for-a-bitbucket-server/https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-the-bitbucket-cloud/。

 
表 4.25. Azure 选项。
属性描述default

secretName

Kubernetes secret,其中包含 Base64 编码的 Azure DevOps Service Application ID 和 Client Secret。请参见以下页面: https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-microsoft-azure-devops-services

 
表 4.26. 网络、OpenShift Dev Spaces 身份验证和 TLS 配置。
属性描述default

annotations

定义要为 Ingress 设置的注解(OpenShift 平台的路由)。kubernetes 平台的默认值为:kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-read-timeout: "3600", nginx.ingress.kubernetes.io/proxy-connect-timeout: "3600", nginx.ingress.kubernetes.io/ssl-redirect: "true"

 

auth

身份验证设置.

{ "gateway": { "configLabels": { "app": "che", "component": "che-gateway-config" } }}

domain

对于 OpenShift 集群,Operator 使用域为路由生成主机名。生成的主机名遵循以下模式:che-<devspaces-namespace>.<domain>。<devspaces-namespace> 是创建 CheCluster CRD 的命名空间。与标签结合使用,它会创建一个由非默认 Ingress 控制器提供的路由。对于 Kubernetes 集群,它包含一个全局入口域。没有默认值:您必须指定它们。

 

hostname

安装的 OpenShift Dev Spaces 服务器的公共主机名。

 

ingressClassName

ingressClassName 是 IngressClass 集群资源的名称。如果在 IngressClassName 字段和 kubernetes.io/ingress.class 注解中都定义了类名称,IngressClassName 字段具有优先权。

 

labels

定义要为 Ingress 设置的标签(OpenShift 平台的路由)。

 

tlsSecretName

用于设置 Ingress TLS 终止的 secret 名称。如果该字段是空字符串,则使用默认集群证书。secret 必须具有 app.kubernetes.io/part-of=che.eclipse.org 标签。

 
表 4.27. 身份验证选项。
属性描述default

advancedAuthorization

提前授权设置。决定允许哪些用户和组访问 Che。如果用户被允许访问 OpenShift Dev Spaces,如果他位于 allowUsers 列表中,或者属于来自 allowGroups 列表中的组的成员,并且不允许 denyUsers 列表,也不是来自 denyGroups 列表中组的成员。如果 allowUsersallowGroups 为空,则允许所有用户访问 Che。如果 denyUsersdenyGroups 为空,则不会拒绝访问 Che 的用户。

 

gateway

网关设置.

{ "configLabels": { "app": "che", "component": "che-gateway-config" }}

identityProviderURL

身份提供程序服务器的公共 URL。

 

identityToken

要传递给上游的身份令牌。支持的令牌有两种: id_tokenaccess_token。默认值为 id_token。此字段特定于仅用于 Kubernetes 的 OpenShift Dev Spaces 安装,并针对 OpenShift 忽略。

 

oAuthAccessTokenInactivityTimeoutSeconds

在 OpenShift OAuthClient 资源中为令牌设置的不活跃超时,用于在 OpenShift 端设置身份联邦。0 表示此客户端的令牌永远不会超时。

 

oAuthAccessTokenMaxAgeSeconds

在 OpenShift OAuthClient 资源中为令牌设置的访问令牌最大期限,用于在 OpenShift 端设置身份联邦。0 表示没有过期。

 

oAuthClientName

用于在 OpenShift 端设置身份联邦的 OpenShift OAuthClient 资源的名称。

 

oAuthScope

访问令牌范围.此字段特定于仅用于 Kubernetes 的 OpenShift Dev Spaces 安装,并针对 OpenShift 忽略。

 

oAuthSecret

在 OpenShift OAuthClient 资源中设置的机密名称,用于在 OpenShift 端设置身份联邦。对于 Kubernetes,这可以是纯文本 oAuthSecret 值,也可以是包含键 oAuthSecret 且值为 secret 的 kubernetes secret 的名称。注意:此 secret 必须与 CheCluster 资源位于同一个命名空间中,并包含标签 app.kubernetes.io/part-of=che.eclipse.org

 
表 4.28. 网关 选项。
属性描述default

configLabels

网关配置标签。

{ "app": "che", "component": "che-gateway-config"}

部署

部署覆盖选项。由于网关部署由多个容器组成,因此必须使用其名称来区分它们: - gateway - configbump - oauth-proxy - kube-rbac-proxy

 

kubeRbacProxy

在 OpenShift Dev Spaces 网关 pod 中配置 kube-rbac-proxy。

 

oAuthProxy

在 OpenShift Dev Spaces 网关 pod 中配置 oauth-proxy。

 

Traefik

配置 OpenShift Dev Spaces 网关 pod 中的 Traefik。

 
表 4.29. 存储 OpenShift Dev Spaces 镜像的替代 registry 的配置。
属性描述default

hostname

从中拉取镜像的替代容器 registry 的可选主机名或 URL。这个值会覆盖 OpenShift Dev Spaces 部署中涉及的所有默认容器镜像中定义的容器 registry 主机名。这在受限环境中安装 OpenShift Dev Spaces 特别有用。

 

机构

从中拉取镜像的替代 registry 的可选存储库名称。这个值会覆盖 OpenShift Dev Spaces 部署中涉及的所有默认容器镜像中定义的容器 registry 组织。这在受限环境中安装 OpenShift Dev Spaces 特别有用。

 
表 4.30. 部署选项。
属性描述default

containers

属于 pod 的容器列表。

 

nodeSelector

节点选择器限制可运行 pod 的节点。

 

securityContext

Pod 运行的安全选项。

 

容限(tolerations)

pod 可以运行的组件 pod 限值的 pod 容限。

 
表 4.31. 容器 选项。
属性描述default

env

容器中要设置的环境变量列表。

 

image

容器镜像。省略它或留空,以使用 Operator 提供的默认容器镜像。

 

imagePullPolicy

镜像拉取(pull)策略。对于 每天下一个最新的镜像,默认值为 Always,其他情况下为 IfNotPresent

 

name

容器名称。

 

resources

此容器所需的计算资源。

 
表 4.32. 容器 选项。
属性描述default

limits

描述允许的最大计算资源量。

 

Request (请求)

描述所需的最少计算资源。

 
表 4.33. 请求 选项。
属性描述default

cpu

CPU,以内核为单位。(500M = .5 个内核)如果没有指定值,则根据组件设置默认值。如果值为 0, 则不会为组件设置值。

 

内存

内存,以字节为单位。(500Gi = 500GiB = 500 * 1024 * 1024 * 1024),如果没有指定值,则根据组件设置默认值。如果值为 0, 则不会为组件设置值。

 
表 4.34. 限制 选项.
属性描述default

cpu

CPU,以内核为单位。(500M = .5 个内核)如果没有指定值,则根据组件设置默认值。如果值为 0, 则不会为组件设置值。

 

内存

内存,以字节为单位。(500Gi = 500GiB = 500 * 1024 * 1024 * 1024),如果没有指定值,则根据组件设置默认值。如果值为 0, 则不会为组件设置值。

 
表 4.35. securityContext 选项。
属性描述default

fsGroup

适用于 pod 中所有容器的特殊补充组。默认值为 1724

 

runAsUser

用于运行容器进程的入口点的 UID。默认值为 1724

 
表 4.36. CheCluster 自定义资源状态定义 OpenShift Dev Spaces 安装的观察状态
属性描述default

chePhase

指定 OpenShift Dev Spaces 部署的当前阶段。

 

cheURL

OpenShift Dev Spaces 服务器的公共 URL。

 

cheVersion

当前安装的 OpenShift Dev Spaces 版本。

 

devfileRegistryURL

弃用了内部 devfile registry 的公共 URL。

 

gatewayPhase

指定网关部署的当前阶段。

 

message

人类可读的消息,指示 OpenShift Dev Spaces 部署处于当前阶段的详情。

 

pluginRegistryURL

内部插件 registry 的公共 URL。

 

reason

简短的 CamelCase 消息显示 OpenShift Dev Spaces 部署处于当前阶段的详情。

 

workspaceBaseDomain

解析的工作空间基域。这是在 spec 中明确定义相同名称的属性的副本,如果 spec 中未定义,且我们在 OpenShift 上运行,则会自动解析路由的 basedomain。

 

4.2. 配置项目

对于每个用户,OpenShift Dev Spaces 在项目中隔离工作区。OpenShift Dev Spaces 通过存在标签和注解来识别用户项目。启动工作区时,如果所需的项目不存在,OpenShift Dev Spaces 会使用模板名称创建项目。

您可以通过以下方法修改 OpenShift Dev Spaces 行为:

4.2.1. 配置项目名称

您可以在启动一个工作区时配置 OpenShift Dev Spaces 用来创建所需项目的项目名称模板。

有效的项目名称模板遵循以下约定:

  • &lt ;username&gt; 或 <userid > 占位符是必需的。
  • 用户名和 ID 不能包含无效字符。如果用户名或 ID 的格式与 OpenShift 对象的命名约定不兼容,OpenShift Dev Spaces 通过将不兼容的字符替换为有效的名称来更改有效名称。
  • OpenShift Dev Spaces 将 & lt;userid > 占位符评估为 14 个字符长字符串,并添加随机六个字符的后缀以防止 ID 冲突。结果保存在用户首选项中以供重复使用。
  • Kubernetes 将项目名称的长度限制为 63 个字符。
  • OpenShift 限制的长度为 49 个字符。

流程

  • 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      components:
        devEnvironments:
          defaultNamespace:
            template: <workspace_namespace_template_>
    Copy to Clipboard

    例 4.3. 用户工作区项目名称模板示例

    用户工作区项目名称模板生成的项目示例

    <username>-devspaces (默认)

    user1-devspaces

    <userid>-namespace

    cge1egvsb2nhba-namespace-ul1411

    <userid>-aka-<username>-namespace

    cgezegvsb2nhba-aka-user1-namespace-6m2w2b

4.2.2. 提前置备项目

您可以提前置备工作区项目,而不依赖于自动配置。为每个用户重复上述步骤。

流程

  1. CheCluster 级别禁用自动命名空间置备:

    devEnvironments:
      defaultNamespace:
        autoProvision: false
    Copy to Clipboard
  2. 使用以下标签和注解为 <username> 用户创建 <project_name> 项目:

    kind: Namespace
    apiVersion: v1
    metadata:
      name: <project_name> 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-namespace
      annotations:
        che.eclipse.org/username: <username>
    Copy to Clipboard
    1
    使用您选择的项目名称。

4.2.3. 配置用户命名空间

此流程指导您使用 OpenShift Dev Spaces 将 ConfigMap、Secret、PersistentVolume VolumeClaim 和其他 Kubernetes 对象从 openshift-devspaces 命名空间复制到多个特定于用户的命名空间。OpenShift Dev Spaces 会自动同步重要配置数据,如共享凭证、配置文件和证书到用户命名空间。

如果您在 openshift-devspaces 命名空间中更改 Kubernetes 资源,OpenShift Dev Spaces 会立即在所有用户命名空间中复制更改。相反,如果在用户命名空间中修改了 Kubernetes 资源,OpenShift Dev Spaces 将立即恢复更改。

流程

  1. 创建以下 ConfigMap 以复制到每个用户项目中。为增强配置性,您可以通过添加额外的标签和注解来自定义 ConfigMap。默认情况下,ConfigMap 会自动挂载到用户工作区。如果您不希望 ConfigMap 挂载,请明确添加以下标签来覆盖行为:

    controller.devfile.io/watch-configmap: "false"
    controller.devfile.io/mount-to-devworkspace: "false"
    Copy to Clipboard

    有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret

    例 4.4. 将 ConfigMap 复制到每个用户项目中:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: devspaces-user-configmap
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
        controller.devfile.io/watch-configmap: "false"
        controller.devfile.io/mount-to-devworkspace: "false"
    data:
      ...
    Copy to Clipboard

    例 4.5. 将 ConfigMap 复制到每个用户项目中,并通过路径 /home/user/.m2 自动将 settings.xml 文件挂载到每个用户容器中:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: devspaces-user-configmap
      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>
    Copy to Clipboard
  2. 创建以下 Secret 以复制到每个用户项目中。为增强配置性,您可以通过添加额外的标签和注解来自定义 Secret。默认情况下,Secret 会自动挂载到用户工作区。如果您不希望挂载 Secret,请明确添加以下标签来覆盖行为:

    controller.devfile.io/watch-secret: "false"
    controller.devfile.io/mount-to-devworkspace: "false"
    Copy to Clipboard

    有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret

    例 4.6. 将 Secret 复制到每个用户项目中:

    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-user-secret
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: workspaces-config
        controller.devfile.io/watch-secret: "false"
        controller.devfile.io/mount-to-devworkspace: "false"
      annotations:
        controller.devfile.io/mount-as: env
    stringData:
      ...
    Copy to Clipboard

    例 4.7. 将 Secret 复制到每个用户项目中,并通过路径 /etc/pki/ca-trust/source/anchors 自动将 trusted-certificates.crt 文件挂载到每个用户容器中:

    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-user-secret
      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: |
        ...
    Copy to Clipboard
    注意

    在工作区启动时运行 update-ca-trust 命令来导入证书。它可以手动实现,或者通过将此命令添加到 devfile 中的 postStart 事件中。请参阅 在 devfile 中添加事件绑定

    例 4.8. 将 Secret 复制到每个用户项目中,并作为环境变量自动挂载到每个用户容器中:

    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-user-secret
      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
    Copy to Clipboard
  3. 在下面创建 PersistentVolumeClaim,将它复制到每个用户项目中。

    为增强配置,您可以通过添加额外的标签和注解来自定义 PersistentVolumeClaim。有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret

    要修改 PersistentVolumeClaim,请将其删除并在 openshift-devspaces 命名空间中创建新名称。

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

    例 4.9. 将 PersistentVolumeClaim 挂载到用户工作区:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: devspaces-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
    Copy to Clipboard
  4. 要使用 OpenShift Kubernetes Engine,您可以创建一个 Template 对象来复制模板中定义的所有资源。

    除了前面提到的 ConfigMapSecretPersistentVolumeClaim 外,Template 对象还可以包括:

    • LimitRange
    • NetworkPolicy
    • ResourceQuota
    • 角色
    • RoleBinding

      apiVersion: template.openshift.io/v1
      kind: Template
      metadata:
        name: devspaces-user-namespace-configurator
        namespace: openshift-devspaces
        labels:
          app.kubernetes.io/part-of: che.eclipse.org
          app.kubernetes.io/component: workspaces-config
      objects:
        ...
      parameters:
      - name: PROJECT_NAME
      - name: PROJECT_ADMIN_USER
      Copy to Clipboard

      参数是可选的,定义可以使用哪些参数。目前,只支持 PROJECT_NAMEPROJECT_ADMIN_USERPROJECT_NAME 是 OpenShift Dev Spaces 命名空间的名称,而 PROJECT_ADMIN_USER 是命名空间的 OpenShift Dev Spaces 用户。

      对象中的 namespace 名称将在同步期间替换为用户的命名空间名称。

      例 4.10. 将 Kubernetes 资源复制到用户项目:

      apiVersion: template.openshift.io/v1
      kind: Template
      metadata:
        name: devspaces-user-namespace-configurator
        namespace: openshift-devspaces
        labels:
          app.kubernetes.io/part-of: che.eclipse.org
          app.kubernetes.io/component: workspaces-config
      objects:
      - apiVersion: v1
        kind: ResourceQuota
        metadata:
          name: devspaces-user-resource-quota
        spec:
          ...
      - apiVersion: v1
        kind: LimitRange
        metadata:
          name: devspaces-user-resource-constraint
        spec:
          ...
      - apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: devspaces-user-roles
        rules:
          ...
      - apiVersion: rbac.authorization.k8s.io/v1
        kind: RoleBinding
        metadata:
          name: devspaces-user-rolebinding
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: Role
          name: devspaces-user-roles
        subjects:
        - kind: User
          apiGroup: rbac.authorization.k8s.io
          name: ${PROJECT_ADMIN_USER}
      parameters:
      - name: PROJECT_ADMIN_USER
      Copy to Clipboard
      注意

      只有在 OpenShift 中才支持创建模板 Kubernetes 资源。

4.3. 配置服务器组件

4.3.1. 将 Secret 或 ConfigMap 作为文件或环境变量挂载到 Red Hat OpenShift Dev Spaces 容器中

secret 是存储敏感数据的 OpenShift 对象,例如:

  • userNames
  • 密码
  • 身份验证令牌

采用加密的形式。

用户可以挂载包含敏感数据的 OpenShift Secret,或包含 OpenShift Dev Spaces 管理容器中的配置的 ConfigMap:

  • 一个文件
  • 环境变量

挂载过程使用标准的 OpenShift 挂载机制,但它需要额外的注释和标记。

4.3.1.1. 将 Secret 或 ConfigMap 作为文件挂载到 OpenShift Dev Spaces 容器中

先决条件

  • 一个 Red Hat OpenShift Dev Spaces 实例。

流程

  1. 在部署 OpenShift Dev Spaces 的 OpenShift 项目中,创建一个新的 OpenShift Secret 或 ConfigMap。要创建的对象标签必须与一组标签匹配:

    • app.kubernetes.io/part-of: che.eclipse.org
    • app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
    • & lt;DEPLOYMENT_NAME > 对应于以下部署:

      • devspaces-dashboard
      • devfile-registry
      • plugin-registry
      • devspaces

    • <OBJECT_KIND& gt; 是:

      • secret

        或者

      • configmap

例 4.11. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard
  1. 配置注解值。注解必须表示将给定对象挂载为文件:

    • Che.eclipse.org/mount-as: file - 表示对象被挂载为一个文件。
    • Che.eclipse.org/mount-path: <TARGET_PATH >- 要提供所需的挂载路径。

例 4.12. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard

OpenShift 对象可以包含几个项目,其名称必须与挂载到容器中的所需文件名匹配。

例 4.13. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <base64 encoded data content here>
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <data content here>
Copy to Clipboard

这会导致名为 ca.crt 的文件被挂载到 OpenShift Dev Spaces 容器的 /data 路径中。

重要

要使 OpenShift Dev Spaces 容器中的更改可见,请完全重新创建 Secret 或 ConfigMap 对象。

4.3.1.2. 将 Secret 或 ConfigMap 作为子路径挂载到 OpenShift Dev Spaces 容器中

先决条件

  • 一个 Red Hat OpenShift Dev Spaces 实例。

流程

  1. 在部署 OpenShift Dev Spaces 的 OpenShift 项目中,创建一个新的 OpenShift Secret 或 ConfigMap。要创建的对象标签必须与一组标签匹配:

    • app.kubernetes.io/part-of: che.eclipse.org
    • app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
    • & lt;DEPLOYMENT_NAME > 对应于以下部署:

      • devspaces-dashboard
      • devfile-registry
      • plugin-registry
      • devspaces

    • <OBJECT_KIND& gt; 是:

      • secret

        或者

      • configmap

例 4.14. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard
  1. 配置注解值。注解必须表示给定对象挂载为 subPath。

    • Che.eclipse.org/mount-as: 子路径 - 表示对象被挂载为 subPath。
    • Che.eclipse.org/mount-path: <TARGET_PATH >- 要提供所需的挂载路径。

例 4.15. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard

OpenShift 对象可以包含几个项目,它们的名称必须与挂载到容器中的文件名匹配。

例 4.16. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <base64 encoded data content here>
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
  annotations:
    che.eclipse.org/mount-as: subpath
    che.eclipse.org/mount-path: /data
data:
  ca.crt: <data content here>
Copy to Clipboard

这会导致名为 ca.crt 的文件被挂载到 OpenShift Dev Spaces 容器的 /data 路径中。

重要

要在 OpenShift Dev Spaces 容器中进行更改,请完全重新创建 Secret 或 ConfigMap 对象。

4.3.1.3. 将 Secret 或 ConfigMap 作为环境变量挂载到 OpenShift Dev Spaces 容器中

先决条件

  • 一个 Red Hat OpenShift Dev Spaces 实例。

流程

  1. 在部署 OpenShift Dev Spaces 的 OpenShift 项目中,创建一个新的 OpenShift Secret 或 ConfigMap。要创建的对象标签必须与一组标签匹配:

    • app.kubernetes.io/part-of: che.eclipse.org
    • app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
    • & lt;DEPLOYMENT_NAME > 对应于以下部署:

      • devspaces-dashboard
      • devfile-registry
      • plugin-registry
      • devspaces

    • <OBJECT_KIND& gt; 是:

      • secret

        或者

      • configmap

例 4.17. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
...
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...
Copy to Clipboard
  1. 配置注解值。注解必须表示给定对象挂载为环境变量:

    • Che.eclipse.org/mount-as: env - 表示对象已挂载为环境变量
    • Che.eclipse.org/env-name : <FOO_ENV >- 提供环境变量名称,这是挂载对象键值所必需的

例 4.18. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
data:
  mykey: myvalue
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
data:
  mykey: myvalue
Copy to Clipboard

这会生成两个环境变量:

  • FOO_ENV
  • myvalue

被置备到 OpenShift Dev Spaces 容器中。

如果对象提供多个数据项,则必须为每个数据键提供环境变量名称,如下所示:

例 4.19. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/mykey_env-name: FOO_ENV
    che.eclipse.org/otherkey_env-name: OTHER_ENV
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-secret
stringData:
  mykey: <data_content_here>
  otherkey: <data_content_here>
Copy to Clipboard

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/mount-as: env
    che.eclipse.org/mykey_env-name: FOO_ENV
    che.eclipse.org/otherkey_env-name: OTHER_ENV
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
data:
  mykey: <data content here>
  otherkey: <data content here>
Copy to Clipboard

这会生成两个环境变量:

  • FOO_ENV
  • OTHER_ENV

被置备为 OpenShift Dev Spaces 容器。

注意

OpenShift 对象中注解名称的最大长度为 63 个字符,其中 9 个字符作为前缀被保留,以 / 结尾。这充当可用于对象的密钥的最大长度的限制。

重要

要使 OpenShift Dev Spaces 容器中的更改可见,请完全重新创建 Secret 或 ConfigMap 对象。

4.3.2. Dev Spaces 服务器的高级配置选项

以下部分介绍了 OpenShift Dev Spaces 服务器组件的高级部署和配置方法。

4.3.2.1. 了解 OpenShift Dev Spaces 服务器高级配置

以下部分介绍了 OpenShift Dev Spaces 服务器组件高级配置方法。

高级配置需要:

  • 从标准 CheCluster 自定义资源字段添加 Operator 自动生成的环境变量。
  • 从标准 CheCluster 自定义资源字段覆盖 Operator 自动生成的属性。

customCheProperties 字段是 CheCluster 自定义资源服务器设置的一部分,包含要应用到 OpenShift Dev Spaces 服务器组件的附加环境变量映射。

例 4.20. 覆盖工作区的默认内存限值

  • 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    apiVersion: org.eclipse.che/v2
    kind: CheCluster
    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGS_APPENDERS_IMPL: json
    Copy to Clipboard
注意

以前的 OpenShift Dev Spaces Operator 版本有一个名为 custom 的 ConfigMap 来履行此角色。如果 OpenShift Dev Spaces Operator 找到带有自定义 configMap 的 configMap,它会将它包含的数据添加到 custom CheProperties 字段中,重新部署 OpenShift Dev Spaces,并删除 自定义 configMap

4.4. 配置自动扩展

了解 Red Hat OpenShift Dev Spaces 自动扩展的不同方面。

4.4.1. 为 Red Hat OpenShift Dev Spaces 容器配置副本数

要使用 Kubernetes HorizontalPodAutoscaler (HPA)为 OpenShift Dev Spaces 操作对象配置副本数,您可以为部署定义 HPA 资源。HPA 根据指定指标动态调整副本数量。

流程

  1. 为部署创建 HPA 资源,指定目标指标和所需的副本数。

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: scaler
      namespace: openshift-devspaces
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <deployment_name> 
    1
    
      ...
    Copy to Clipboard
    1
    & lt;deployment_name > 对应于以下部署:
    • devspaces
    • che-gateway
    • devspaces-dashboard
    • plugin-registry
    • devfile-registry

例 4.21. 为 devspaces 部署创建一个 HorizontalPodAutoscaler

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: devspaces-scaler
  namespace: openshift-devspaces
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: devspaces
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
Copy to Clipboard

在本例中,HPA 以名为 devspaces 的 Deployment 为目标,至少为 2 个副本,最多 5 个副本并根据 CPU 使用率进行扩展。

4.4.2. 配置机器自动扩展

如果您将集群配置为根据资源需求调整节点数量,则需要额外的配置来维护 OpenShift Dev Spaces 工作区的无缝操作。

当自动扩展添加或删除节点时,工作区需要特殊考虑。

当自动扩展添加新节点时,工作空间启动所需的时间可能比通常要长,直到节点置备完成为止。

相反,当节点被删除时,运行工作区 pod 的节点不应被自动扩展驱除,以避免在使用工作区时造成中断,并可能会丢失任何未保存的数据。

4.4.2.1. 当自动扩展添加新节点时

您需要对 OpenShift Dev Spaces 安装进行额外的配置,以确保在添加新节点时正确工作空间启动。

流程

  1. 在 CheCluster 自定义资源中,设置以下字段,以便在自动扩展器置备新节点时允许正确的工作区启动。

    spec:
      devEnvironments:
        startTimeoutSeconds: 600 
    1
    
        ignoredUnrecoverableEvents: 
    2
    
          - FailedScheduling
    Copy to Clipboard
    1
    至少设置为 600 秒,以允许在工作空间启动期间置备新节点的时间。
    2
    忽略 FailedScheduling 事件,以允许在置备新节点时继续工作空间。默认启用此设置。
4.4.2.2. 当自动扩展删除节点时

要防止工作区 pod 在自动扩展需要删除节点时被驱除,请将 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" 注解添加到每个工作区 pod。

流程

  1. 在 CheCluster 自定义资源中,在 spec.devEnvironments.workspacesPodAnnotations 字段中添加 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 注解。

    spec:
      devEnvironments:
        workspacesPodAnnotations:
          cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
    Copy to Clipboard

验证步骤

  1. 启动工作区,并验证工作区 pod 是否包含 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 注解。

    $ oc get pod <workspace_pod_name> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/safe-to-evict}'
    false
    Copy to Clipboard

4.5. 在全局配置工作区

本节描述了管理员如何全局配置工作区。

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

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

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

spec:
  devEnvironments:
    maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
1
Copy to Clipboard
1
设置每个用户的最大工作区数。默认值为 -1,允许用户保留无限数量的工作区。使用正整数来设置每个用户的最大工作区数。

流程

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

    $ oc get checluster --all-namespaces \
      -o=jsonpath="{.items[*].metadata.namespace}"
    Copy to Clipboard
  2. 配置 maxNumberOfWorkspacesPerUser:

    $ oc patch checluster/devspaces -n openshift-devspaces \
    1
    
    --type='merge' -p \
    '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'
    2
    Copy to Clipboard
    1
    您在第 1 步中获取的 OpenShift Dev Spaces 命名空间。
    2
    您选择 < kept_workspaces_limit> 值。

4.5.2. 限制所有用户可以同时运行的工作区数

默认情况下,所有用户都可以运行无限数量的工作区。您可以限制所有用户可以同时运行的工作区数量。此配置是 CheCluster 自定义资源的一部分:

spec:
  devEnvironments:
    maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>
1
Copy to Clipboard
1
在整个 Kubernetes 集群中同时运行的最大工作区数。这适用于系统中的所有用户。如果值设为 -1,这表示运行工作区的数量没有限制。

流程

  1. 配置 maxNumberOfRunningWorkspacesPerCluster:

    oc patch checluster/devspaces -n openshift-devspaces \
    --type='merge' -p \
    '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'
    1
    Copy to Clipboard
    1
    您选择的 < running_workspaces_limit> 值。

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

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

注意

如果使用默认存储方法,如果用户在多节点集群中的节点间分布 pod,则并发运行工作区时可能会遇到问题。从每个用户 通用 存储策略切换到 per-workspace 存储策略,或 使用临时存储 类型可能会避免或解决这些问题。

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

spec:
  devEnvironments:
    maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
1
Copy to Clipboard
1
设置每个用户同时运行工作区的最大数量。通过 -1 值,用户可以运行无限数量的工作区。默认值为 1

流程

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

    $ oc get checluster --all-namespaces \
      -o=jsonpath="{.items[*].metadata.namespace}"
    Copy to Clipboard
  2. 配置 maxNumberOfRunningWorkspacesPerUser:

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

4.5.4. 带有自签名证书的 Git

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

先决条件

  • 具有 OpenShift 集群管理权限的活跃的 oc 会话。请参阅 OpenShift CLI 入门
  • Git 版本 2 或更高版本

流程

  1. 创建一个新的 ConfigMap,其中包含 Git 服务器的详情:

    $ 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
    Copy to Clipboard
    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
    Copy to Clipboard
  3. 配置 OpenShift Dev Spaces 操作对象,将自签名证书用于 Git 存储库。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      devEnvironments:
        trustedCerts:
          gitTrustedCertsConfigMapName: che-git-self-signed-cert
    Copy to Clipboard

验证步骤

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

    例 4.22. /etc/gitconfig 文件的内容

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

4.5.5. 配置工作区 nodeSelector

本节论述了如何为 OpenShift Dev Spaces 工作区的 Pod 配置 nodeSelector

流程

  1. 使用 NodeSelector

    OpenShift Dev Spaces 使用 CheCluster 自定义资源来配置 nodeSelector

    spec:
      devEnvironments:
        nodeSelector:
          key: value
    Copy to Clipboard

    本节必须包含 每个节点标签 的一组 key=value 对,以组成 nodeSelector 规则。

  2. 使用 Taints 和 Tolerations

    这的工作方式与 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
    Copy to Clipboard
重要

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

为了避免在大型多区集群上的不同区中调度 Pod 和 PVC,请创建一个额外的 StorageClass 对象(请注意 allowedTopologies 字段),它将协调 PVC 创建过程。

通过 CheCluster 自定义资源将这个新创建的 StorageClass 的名称传递给 OpenShift Dev Spaces。如需更多信息,请参阅:第 4.9.1 节 “配置存储类”

4.5.6. 为云环境配置允许的 URL

允许 URL 在保护云环境(CDE)启动方面扮演重要角色,确保它们只能从授权来源启动。通过使用通配符支持,如 *,组织可以实施灵活的 URL 模式,允许跨域中的不同路径启动动态和安全 CDE。

  1. 配置允许的源:

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        -p \
    '{
       "spec": {
         "devEnvironments": {
           "allowedSources": {
             "urls": ["url_1", "url_2"] 
    1
    
           }
         }
       }
     }'
    Copy to Clipboard
    1
    用于启动云环境(CDE)的批准 URL 数组。CDE 只能从这些 URL 启动。URL 中支持通配符 *。例如: https://example.com/* 允许从 example.com 中的任何路径启动 CDE。

4.6. 缓存镜像以便更快地启动工作区

要提高 OpenShift Dev Spaces 工作区的开始时间性能,请使用 Image Puller,它是一个 OpenShift Dev Spaces 组件,可用于预拉取 OpenShift 集群。

Image Puller 是一个额外的 OpenShift 部署,它会创建一个 DaemonSet,可在每个节点上预拉取相关的 OpenShift Dev Spaces 工作区镜像。这些镜像在 OpenShift Dev Spaces 工作区启动时已经可用,因此改进了工作空间开始时间。

4.6.1. 安装 Kubernetes Image Puller

按照以下说明,为不同的用例安装 Kubernetes Image Puller。

4.6.1.1. 安装 Kubernetes Image Puller
4.6.1.2. 使用 CLI 在 OpenShift 上安装 Image Puller

您可以使用 OpenShift oc 管理工具在 OpenShift 上安装 Kubernetes Image Puller。

重要

如果使用 oc CLI 安装 ImagePuller,则无法通过 CheCluster 自定义资源进行配置。

先决条件

流程

  1. 按照 doc 收集要拉取的相关容器镜像列表: 第 4.6.3 节 “检索 Kubernetes Image Puller 的默认镜像列表”
  2. 定义内存请求和限值参数,以确保拉取容器,并且平台有足够的内存来运行。

    当定义 CACHING_MEMORY_REQUESTCACHING_MEMORY_LIMIT 的最小值时,请考虑运行每个容器镜像所需的内存量。

    在定义 CACHING_MEMORY_REQUESTCACHING_MEMORY_LIMIT 的 maximal 值时,请考虑分配给集群中 DaemonSet Pod 的总内存:

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

    在 20 个节点中拉取 5 个镜像,容器内存限制为 20Mi 需要 2000Mi 内存。

  3. 克隆 Image Puller 存储库,并在包含 OpenShift 模板的目录中:

    git clone https://github.com/che-incubator/kubernetes-image-puller
    cd kubernetes-image-puller/deploy/openshift
    Copy to Clipboard
  4. 使用以下参数配置 app.yamlconfigmap.yamlserviceaccount.yaml OpenShift 模板:

    表 4.37. 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

    表 4.38. configmap.yaml 中的 Image Puller OpenShift 模板参数
    使用方法默认值

    CACHING_CPU_LIMIT

    ConfigMap 中的 CACHING_CPU_LIMIT 的值

    .2

    CACHING_CPU_REQUEST

    ConfigMap 中的 CACHING_CPU_REQUEST 的值

    .05

    CACHE_INTERVAL_HOURS

    ConfigMap 中的 CACHING_INTERVAL_HOURS 的值

    "1"

    CACHING_MEMORY_LIMIT

    ConfigMap 中的 CACHING_MEMORY_LIMIT 的值

    "20Mi"

    CACHE_MEMORY_REQUEST

    ConfigMap 中的 CACHING_MEMORY_REQUEST 的值

    "10Mi"

    DAEMONSET_NAME

    ConfigMap 中的 DAEMONSET_NAME 的值

    kubernetes-image-puller

    DEPLOYMENT_NAME

    ConfigMap 中的 DEPLOYMENT_NAME 的值

    kubernetes-image-puller

    镜像

    ConfigMap 中的 IMAGES

    {}

    NAMESPACE

    ConfigMap 中的 NAMESPACE

    k8s-image-puller

    NODE_SELECTOR

    ConfigMap 中的 NODE_SELECTOR 的值

    "{}"

    表 4.39. serviceaccount.yaml 中的 Image Puller OpenShift 模板参数
    使用方法默认值

    SERVICEACCOUNT_NAME

    部署创建和使用的 ServiceAccount 的名称

    kubernetes-image-puller

    KIP_IMAGE

    从中复制 sleep 二进制文件的镜像拉取器镜像

    registry.redhat.io/devspaces/imagepuller-rhel8:latest

  5. 创建一个 OpenShift 项目来托管 Image Puller:

    oc new-project <k8s-image-puller>
    Copy to Clipboard
  6. 处理并应用模板来安装 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 -
    Copy to Clipboard

验证步骤

  1. 验证是否存在 < kubernetes-image-puller> 部署和一个 < kubernetes-image-puller> DaemonSet。DaemonSet 需要为集群中的每个节点都有一个 Pod:

    oc get deployment,daemonset,pod --namespace <k8s-image-puller>
    Copy to Clipboard
  2. 验证 < kubernetes-image-puller > ConfigMap 的值。

    oc get configmap <kubernetes-image-puller> --output yaml
    Copy to Clipboard
4.6.1.3. 使用 Web 控制台在 OpenShift 上安装 Image Puller

您可以使用 OpenShift Web 控制台在 OpenShift 上安装社区支持的 Kubernetes Image Puller Operator。

先决条件

流程

  1. 安装社区支持的 Kubernetes Image Puller Operator。请参阅使用 Web 控制台从 OperatorHub 安装
  2. 从社区支持的 Kubernetes Image Puller Operator 创建一个 kubernetes-image-puller KubernetesImagePuller 操作对象。请参阅 从已安装的 Operator 创建应用程序

4.6.2. 配置 Kubernetes Image Puller

本节包含为不同用例配置 Kubernetes Image Puller 的说明。

4.6.2.1. 配置 Kubernetes Image Puller
4.6.2.2. 将 Image Puller 配置为预先拉取默认 Dev Spaces 镜像

您可以将 Kubernetes Image Puller 配置为预先拉取默认的 OpenShift Dev Spaces 镜像。Red Hat OpenShift Dev Spaces operator 将控制镜像列表来预拉取,并在 OpenShift Dev Spaces 升级过程中自动更新它们。

先决条件

  • 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
  • Image Puller 安装在 Kubernetes 集群上。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 将 Image Puller 配置为预拉取 OpenShift Dev Spaces 镜像。

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        --patch '{
                  "spec": {
                    "components": {
                      "imagePuller": {
                        "enable": true
                      }
                    }
                  }
                }'
    Copy to Clipboard
4.6.2.3. 配置 Image Puller 以预拉取自定义镜像

您可以将 Kubernetes Image Puller 配置为预拉取自定义镜像。

先决条件

  • 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
  • Image Puller 安装在 Kubernetes 集群上。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 将 Image Puller 配置为预先拉取自定义镜像。

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        --patch '{
                  "spec": {
                    "components": {
                      "imagePuller": {
                        "enable": true,
                        "spec": {
                          "images": "NAME-1=IMAGE-1;NAME-2=IMAGE-2" 
    1
    
                        }
                      }
                    }
                  }
                }'
    Copy to Clipboard
    1
    分号分隔的镜像列表
4.6.2.4. 配置 Image Puller 以预拉取额外镜像

您可以将 Kubernetes Image Puller 配置为预拉取额外的 OpenShift Dev Spaces 镜像。

先决条件

  • 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
  • Image Puller 安装在 Kubernetes 集群上。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 创建 k8s-image-puller 命名空间:

    oc create namespace k8s-image-puller
    Copy to Clipboard
  2. 创建 KubernetesImagePuller 自定义资源:

    oc apply -f - <<EOF
    apiVersion: che.eclipse.org/v1alpha1
    kind: KubernetesImagePuller
    metadata:
      name: k8s-image-puller-images
      namespace: k8s-image-puller
    spec:
      images: "__NAME-1__=__IMAGE-1__;__NAME-2__=__IMAGE-2__" 
    1
    
    EOF
    Copy to Clipboard
    1
    分号分隔的镜像列表

4.6.3. 检索 Kubernetes Image Puller 的默认镜像列表

了解如何检索 Kubernetes Image Puller 使用的默认镜像列表。这对希望检查并配置 Image Puller 的管理员很有用,使其提前只使用这些镜像的子集。

先决条件

  • 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 查找部署 OpenShift Dev Spaces Operator 的命名空间:

    OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
    Copy to Clipboard
  2. 查找 Image Puller 预先拉取的镜像:

    oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt
    Copy to Clipboard

4.7. 配置可观察性

要配置 OpenShift Dev Spaces 可观察性功能,请参阅:

4.7.1. Woopra 遥测插件

Woopra Telemetry 插件是 一个插件,用于将遥测从 Red Hat OpenShift Dev Spaces 安装发送到 Segment 和 Woopra。此插件 由红帽托管的 Eclipse Che 使用,但任何 Red Hat OpenShift Dev Spaces 部署都可以利用此插件。有效的 Woopra 域和 Segment Write 键以外的依赖项没有。插件的 devfile v2 ,plugin.yaml,有四个可传递给插件的环境变量:

  • WOOPRA_DOMAIN - 将事件发送到的 Woopra 域。
  • SEGMENT_WRITE_KEY - 将事件发送到 Segment 和 Woopra 的写入密钥。
  • WOOPRA_DOMAIN_ENDPOINT - 如果您不希望直接传递 Woopra 域,则该插件会从返回 Woopra 域的提供的 HTTP 端点中获取它。
  • SEGMENT_WRITE_KEY_ENDPOINT - 如果您不希望直接传递 Segment 写键,则该插件会从返回分段写入键的提供的 HTTP 端点中获取它。

在 Red Hat OpenShift Dev Spaces 安装中启用 Woopra 插件:

流程

  • 使用正确设置环境变量将 plugin.yaml devfile v2 文件部署到 HTTP 服务器。

    1. 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

      spec:
        devEnvironments:
          defaultPlugins:
          - editor: eclipse/che-theia/next     
      1
      
            plugins:                           
      2
      
            - 'https://your-web-server/plugin.yaml'
      Copy to Clipboard
      1
      用于为其设置 telemetry 插件的 editorId
      2
      遥测插件的 devfile v2 定义的 URL。

4.7.2. 创建遥测插件

本节演示了如何创建扩展 AbstractAnalyticsManagerAnalyticsManager 类并实现以下方法:

  • isEnabled () - 确定遥测后端是否正常工作。这可能意味着始终返回 true,或者具有更复杂的检查,例如,当缺少连接属性时返回 false
  • destroy () - cleanup 方法,在关闭遥测后端前运行。此方法发送 WORKSPACE_STOPPED 事件。
  • onActivity () - 表示给定用户仍然发生一些活动。这主要用于发送 WORKSPACE_INACTIVE 事件。
  • onEvent () - 将遥测事件提交到遥测服务器,如 WORKSPACE_USEDWORKSPACE_STARTED
  • increaseDuration () - 增加了当前事件的持续时间,而不是在少量时间内发送多个事件。

以下部分涵盖了:

  • 创建遥测服务器以将事件回显到标准输出。
  • 扩展 OpenShift Dev Spaces 遥测客户端并实施用户的自定义后端。
  • 创建代表自定义后端的 Dev Workspace 插件的 plugin.yaml 文件。
  • 通过从 CheCluster 自定义资源设置 workspacesDefaultPlugins 属性来指定自定义插件到 OpenShift Dev Spaces 的位置。
4.7.2.1. 开始使用

本文档描述了扩展 OpenShift Dev Spaces 遥测系统以与自定义后端通信所需的步骤:

  1. 创建接收事件的服务器进程
  2. 扩展 OpenShift Dev Spaces 库,以创建向服务器发送事件的后端
  3. 在容器中打包遥测后端并将其部署到镜像 registry
  4. 为后端添加插件,并指示 OpenShift Dev Spaces 在 Dev Workspaces 中加载插件

此处 提供了遥测后端的完整示例。

4.7.2.2. 创建接收事件的服务器

出于演示目的,本例演示了如何创建从我们的遥测插件接收事件的服务器并将其写入标准输出。

对于生产用例,请考虑与第三方遥测系统集成(例如,Segment、Woopra),而不是创建自己的遥测服务器。在这种情况下,使用供应商的 API 将事件从自定义后端发送到其系统。

以下 Go 代码在端口 8080 上启动服务器,并将事件写入标准输出:

例 4.23. main.go

package main

import (
	"io/ioutil"
	"net/http"

	"go.uber.org/zap"
)

var logger *zap.SugaredLogger

func event(w http.ResponseWriter, req *http.Request) {
	switch req.Method {
	case "GET":
		logger.Info("GET /event")
	case "POST":
		logger.Info("POST /event")
	}
	body, err := req.GetBody()
	if err != nil {
		logger.With("err", err).Info("error getting body")
		return
	}
	responseBody, err := ioutil.ReadAll(body)
	if err != nil {
		logger.With("error", err).Info("error reading response body")
		return
	}
	logger.With("body", string(responseBody)).Info("got event")
}

func activity(w http.ResponseWriter, req *http.Request) {
	switch req.Method {
	case "GET":
		logger.Info("GET /activity, doing nothing")
	case "POST":
		logger.Info("POST /activity")
		body, err := req.GetBody()
		if err != nil {
			logger.With("error", err).Info("error getting body")
			return
		}
		responseBody, err := ioutil.ReadAll(body)
		if err != nil {
			logger.With("error", err).Info("error reading response body")
			return
		}
		logger.With("body", string(responseBody)).Info("got activity")
	}
}

func main() {

	log, _ := zap.NewProduction()
	logger = log.Sugar()

	http.HandleFunc("/event", event)
	http.HandleFunc("/activity", activity)
	logger.Info("Added Handlers")

	logger.Info("Starting to serve")
	http.ListenAndServe(":8080", nil)
}
Copy to Clipboard

基于此代码创建容器镜像,并将它公开为 openshift-devspaces 项目中的 OpenShift 中的部署。示例遥测服务器的代码位于 telemetry-server-example 上。要部署遥测服务器,请克隆存储库并构建容器:

$ git clone https://github.com/che-incubator/telemetry-server-example
$ cd telemetry-server-example
$ podman build -t registry/organization/telemetry-server-example:latest .
$ podman push registry/organization/telemetry-server-example:latest
Copy to Clipboard

manifest_with_ingress.yamlmanifest_with_route 都包含 Deployment 和 Service 的定义。前者还定义了 Kubernetes Ingress,后者则定义了 OpenShift 路由。

在清单文件中,替换 imagehost 字段,以匹配您推送的镜像和 OpenShift 集群的公共主机名。然后运行:

$ kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
Copy to Clipboard
4.7.2.3. 创建后端项目
注意

为了在开发时获得快速反馈,建议在 Dev Workspace 内进行开发。这样,您可以在集群中运行应用程序,并从前端 telemetry 插件接收事件。

  1. Maven Quarkus 项目构建:

    mvn io.quarkus:quarkus-maven-plugin:2.7.1.Final:create \
        -DprojectGroupId=mygroup -DprojectArtifactId=devworkspace-telemetry-example-plugin \
    -DprojectVersion=1.0.0-SNAPSHOT
    Copy to Clipboard
  2. 删除 src/main/java/mygroupsrc/test/java/mygroup 下的文件。
  3. 如需最新版本,以及 Maven 协调 后端基础,请参阅 GitHub 软件包
  4. 将以下依赖项添加到 pom.xml 中:

    例 4.24. pom.xml

    <!-- Required -->
    <dependency>
        <groupId>org.eclipse.che.incubator.workspace-telemetry</groupId>
        <artifactId>backend-base</artifactId>
        <version>LATEST VERSION FROM PREVIOUS STEP</version>
    </dependency>
    
    
    <!-- Used to make http requests to the telemetry server -->
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-client</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-rest-client-jackson</artifactId>
    </dependency>
    Copy to Clipboard
  5. 使用 read:packages 权限创建一个个人访问令牌,从 GitHub 软件包下载 org.eclipse.che.incubator.workspace-telemetry:backend-base 依赖项。
  6. ~/.m2/settings.xml 文件中添加您的 GitHub 用户名、个人访问令牌和 che-incubator 存储库详情:

    例 4.25. 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
    http://maven.apache.org/xsd/settings-1.0.0.xsd">
       <servers>
          <server>
             <id>che-incubator</id>
             <username>YOUR GITHUB USERNAME</username>
             <password>YOUR GITHUB TOKEN</password>
          </server>
       </servers>
    
       <profiles>
          <profile>
             <id>github</id>
             <activation>
                <activeByDefault>true</activeByDefault>
             </activation>
             <repositories>
                <repository>
                   <id>central</id>
                   <url>https://repo1.maven.org/maven2</url>
                   <releases><enabled>true</enabled></releases>
                   <snapshots><enabled>false</enabled></snapshots>
                   </repository>
                   <repository>
                   <id>che-incubator</id>
                   <url>https://maven.pkg.github.com/che-incubator/che-workspace-telemetry-client</url>
                </repository>
             </repositories>
          </profile>
       </profiles>
    </settings>
    Copy to Clipboard
4.7.2.4. 创建 AnalyticsManager 的具体实施并添加专用逻辑

src/main/java/mygroup 下创建两个文件:

  • MainConfiguration.java - 包含提供给 AnalyticsManager 的配置。
  • AnalyticsManager.java - 包含特定于遥测系统的逻辑。

例 4.26. MainConfiguration.java

package org.my.group;

import java.util.Optional;

import javax.enterprise.context.Dependent;
import javax.enterprise.inject.Alternative;

import org.eclipse.che.incubator.workspace.telemetry.base.BaseConfiguration;
import org.eclipse.microprofile.config.inject.ConfigProperty;

@Dependent
@Alternative
public class MainConfiguration extends BaseConfiguration {
    @ConfigProperty(name = "welcome.message")      
1

    Optional<String> welcomeMessage;               
2

}
Copy to Clipboard
1
MicroProfile 配置注释用于注入 welcome.message 配置。

有关如何设置特定于您的后端的配置属性的更多详细信息,请参阅 Quarkus 配置参考指南

例 4.27. AnalyticsManager.java

package org.my.group;

import java.util.HashMap;
import java.util.Map;

import javax.enterprise.context.Dependent;
import javax.enterprise.inject.Alternative;
import javax.inject.Inject;

import org.eclipse.che.incubator.workspace.telemetry.base.AbstractAnalyticsManager;
import org.eclipse.che.incubator.workspace.telemetry.base.AnalyticsEvent;
import org.eclipse.che.incubator.workspace.telemetry.finder.DevWorkspaceFinder;
import org.eclipse.che.incubator.workspace.telemetry.finder.UsernameFinder;
import org.eclipse.microprofile.rest.client.inject.RestClient;
import org.slf4j.Logger;

import static org.slf4j.LoggerFactory.getLogger;

@Dependent
@Alternative
public class AnalyticsManager extends AbstractAnalyticsManager {

    private static final Logger LOG = getLogger(AbstractAnalyticsManager.class);

    public AnalyticsManager(MainConfiguration mainConfiguration, DevWorkspaceFinder devworkspaceFinder, UsernameFinder usernameFinder) {
        super(mainConfiguration, devworkspaceFinder, usernameFinder);

        mainConfiguration.welcomeMessage.ifPresentOrElse(     
1

            (str) -> LOG.info("The welcome message is: {}", str),
            () -> LOG.info("No welcome message provided")
        );
    }

    @Override
    public boolean isEnabled() {
        return true;
    }

    @Override
    public void destroy() {}

    @Override
    public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) {
        LOG.info("The received event is: {}", event);         
2

    }

    @Override
    public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { }

    @Override
    public void onActivity() {}
}
Copy to Clipboard
1
如果提供,请记录欢迎消息。
2
记录从前端插件接收的事件。

由于 org.my.group.AnalyticsManagerorg.my.group.MainConfiguration 是替代 Bean,因此请使用 src/main/resources/application.properties 中的 quarkus.arc.selected-alternatives 属性来指定它们。

例 4.28. application.properties

quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
Copy to Clipboard
4.7.2.5. 在 Dev Workspace 中运行应用程序
  1. 在 Dev Workspace 中设置 DEVWORKSPACE_TELEMETRY_BACKEND_PORT 环境变量。在这里,值设为 4167

    spec:
      template:
        attributes:
          workspaceEnv:
            - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT
              value: '4167'
    Copy to Clipboard
  2. 从 Red Hat OpenShift Dev Spaces 仪表板重启 Dev Workspace。
  3. 在 Dev Workspace 的终端窗口中运行以下命令以启动应用。使用- settings 标志指定包含 GitHub 访问令牌的 settings.xml 文件的位置的路径。

    $ mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
    Copy to Clipboard

    应用程序现在通过前端插件的端口 4167 接收遥测事件。

验证步骤

  1. 验证以下输出是否已记录:

    INFO  [org.ecl.che.inc.AnalyticsManager] (Quarkus Main Thread) No welcome message provided
    INFO  [io.quarkus] (Quarkus Main Thread) devworkspace-telemetry-example-plugin 1.0.0-SNAPSHOT on JVM (powered by Quarkus 2.7.2.Final) started in 0.323s. Listening on: http://localhost:4167
    INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
    INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, kubernetes-client, rest-client, rest-client-jackson, resteasy, resteasy-jsonb, smallrye-context-propagation, smallrye-openapi, swagger-ui, vertx]
    Copy to Clipboard
  2. 要验证 AnalyticsManageronEvent () 方法是否从前端插件接收事件,请按 l 键禁用 Quarkus 实时编码并在 IDE 中编辑任何文件。应该会记录以下输出:

    INFO  [io.qua.dep.dev.RuntimeUpdatesProcessor] (Aesh InputStream Reader) Live reload disabled
    INFO  [org.ecl.che.inc.AnalyticsManager] (executor-thread-2) The received event is: Edit Workspace File in Che
    Copy to Clipboard
4.7.2.6. 实现 isEnabled ()

例如,此方法会在调用时始终返回 true

例 4.29. AnalyticsManager.java

@Override
public boolean isEnabled() {
    return true;
}
Copy to Clipboard

可以将更复杂的逻辑放在 isEnabled () 中。例如,托管 OpenShift Dev Spaces Woopra 后端 在确定后端是否已启用前检查配置属性是否存在。

4.7.2.7. 实施 onEvent ()

onEvent () 将后端收到的事件发送到遥测系统。对于 example 应用,它将 HTTP POST 有效负载发送到来自遥测服务器的 /event 端点。

4.7.2.7.1. 向示例 telemetry 服务器发送 POST 请求

在以下示例中,遥测服务器应用通过以下 URL 部署到 OpenShift: http://little-telemetry-server-che.apps-crc.testing,其中 apps-crc.testing 是 OpenShift 集群的入口域名。

  1. 通过创建 TelemetryService.java来设置 RESTEasy REST 客户端

    例 4.30. TelemetryService.java

    package org.my.group;
    
    import java.util.Map;
    
    import javax.ws.rs.Consumes;
    import javax.ws.rs.POST;
    import javax.ws.rs.Path;
    import javax.ws.rs.core.MediaType;
    import javax.ws.rs.core.Response;
    
    import org.eclipse.microprofile.rest.client.inject.RegisterRestClient;
    
    @RegisterRestClient
    public interface TelemetryService {
        @POST
        @Path("/event") 
    1
    
        @Consumes(MediaType.APPLICATION_JSON)
        Response sendEvent(Map<String, Object> payload);
    }
    Copy to Clipboard
    1
    向其发出 POST 请求的端点。
  2. src/main/resources/application.properties 文件中指定 TelemetryService 的基本 URL:

    例 4.31. application.properties

    org.my.group.TelemetryService/mp-rest/url=http://little-telemetry-server-che.apps-crc.testing
    Copy to Clipboard
  3. TelemetryService 注入 AnalyticsManager,并在 onEvent ()中发送 POST 请求

    例 4.32. AnalyticsManager.java

    @Dependent
    @Alternative
    public class AnalyticsManager extends AbstractAnalyticsManager {
        @Inject
        @RestClient
        TelemetryService telemetryService;
    
    ...
    
    @Override
    public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) {
        Map<String, Object> payload = new HashMap<String, Object>(properties);
        payload.put("event", event);
        telemetryService.sendEvent(payload);
    }
    Copy to Clipboard

    这会向遥测服务器发送 HTTP 请求,并在短时间内自动延迟相同的事件。默认持续时间为 1500 毫秒。

4.7.2.8. 实现 increaseDuration ()

许多遥测系统可识别事件持续时间。AbstractAnalyticsManager 将同一时间段内发生的类似事件合并到一个事件中。这个 increaseDuration () 的实现是一个 no-op。此方法使用用户遥测提供程序的 API 来更改事件或事件属性,以反映事件的增加持续时间。

例 4.33. AnalyticsManager.java

@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
Copy to Clipboard
4.7.2.9. 实施 onActivity ()

设置不活跃超时限制,并使用 onActivity () 发送 WORKSPACE_INACTIVE 事件(如果最后一次事件时间超过超时时间)。

例 4.34. AnalyticsManager.java

public class AnalyticsManager extends AbstractAnalyticsManager {

    ...

    private long inactiveTimeLimit = 60000 * 3;

    ...

    @Override
    public void onActivity() {
        if (System.currentTimeMillis() - lastEventTime >= inactiveTimeLimit) {
            onEvent(WORKSPACE_INACTIVE, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties);
        }
    }
Copy to Clipboard
4.7.2.10. 实现 destroy ()

调用 destroy () 时,发送 WORKSPACE_STOPPED 事件并关闭任何资源,如连接池。

例 4.35. AnalyticsManager.java

@Override
public void destroy() {
    onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties);
}
Copy to Clipboard

运行 mvn quarkus:dev,如 第 4.7.2.5 节 “在 Dev Workspace 中运行应用程序” 所述,使用 Ctrl+C 终止应用程序,使用 Ctrl C 向服务器发送 WORKSPACE_STOPPED 事件。

4.7.2.11. 打包 Quarkus 应用程序

有关在容器中打包应用程序的最佳说明,请参阅 Quarkus 文档。构建容器并将其推送到您选择的容器 registry。

4.7.2.11.1. 用于构建使用 JVM 运行的 Quarkus 镜像的 Dockerfile 示例

例 4.36. Dockerfile.jvm

FROM registry.access.redhat.com/ubi8/openjdk-11:1.11

ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en'

COPY --chown=185 target/quarkus-app/lib/ /deployments/lib/
COPY --chown=185 target/quarkus-app/*.jar /deployments/
COPY --chown=185 target/quarkus-app/app/ /deployments/app/
COPY --chown=185 target/quarkus-app/quarkus/ /deployments/quarkus/

EXPOSE 8080
USER 185

ENTRYPOINT ["java", "-Dquarkus.http.host=0.0.0.0", "-Djava.util.logging.manager=org.jboss.logmanager.LogManager", "-Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}", "-jar", "/deployments/quarkus-run.jar"]
Copy to Clipboard

要构建镜像,请运行:

mvn package && \
podman build -f src/main/docker/Dockerfile.jvm -t image:tag .
Copy to Clipboard
4.7.2.11.2. 用于构建 Quarkus 原生镜像的 Dockerfile 示例

例 4.37. dockerfile.native

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
WORKDIR /work/
RUN chown 1001 /work \
    && chmod "g+rwX" /work \
    && chown 1001:root /work
COPY --chown=1001:root target/*-runner /work/application

EXPOSE 8080
USER 1001

CMD ["./application", "-Dquarkus.http.host=0.0.0.0", "-Dquarkus.http.port=$DEVWORKSPACE_TELEMETRY_BACKEND_PORT}"]
Copy to Clipboard

要构建镜像,请运行:

mvn package -Pnative -Dquarkus.native.container-build=true && \
podman build -f src/main/docker/Dockerfile.native -t image:tag .
Copy to Clipboard
4.7.2.12. 为您的插件创建 plugin.yaml

创建一个 plugin.yaml devfile v2 文件,代表一个 Dev Workspace 插件,用于在 Dev Workspace Pod 中运行自定义后端。有关 devfile v2 的更多信息,请参阅 Devfile v2 文档

例 4.38. plugin.yaml

schemaVersion: 2.1.0
metadata:
  name: devworkspace-telemetry-backend-plugin
  version: 0.0.1
  description: A Demo telemetry backend
  displayName: Devworkspace Telemetry Backend
components:
  - name: devworkspace-telemetry-backend-plugin
    attributes:
      workspaceEnv:
        - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT
          value: '4167'
    container:
      image: YOUR IMAGE            
1

      env:
        - name: WELCOME_MESSAGE    
2

          value: 'hello world!'
Copy to Clipboard
1
指定从 第 4.7.2.11 节 “打包 Quarkus 应用程序” 构建的容器镜像。
2
从 Example 4 设置 welcome.message 可选配置属性的值。

通常,用户将此文件部署到公司 Web 服务器。本指南演示了如何在 OpenShift 上创建 Apache Web 服务器,并在那里托管插件。

创建引用新 plugin.yaml 文件的 ConfigMap 对象。

$ oc create configmap --from-file=plugin.yaml -n openshift-devspaces telemetry-plugin-yaml
Copy to Clipboard

创建用于公开 Web 服务器的部署、服务和路由。部署引用此 ConfigMap 对象并将其放置在 /var/www/html 目录中。

例 4.39. manifest.yaml

kind: Deployment
apiVersion: apps/v1
metadata:
  name: apache
spec:
  replicas: 1
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      volumes:
        - name: plugin-yaml
          configMap:
            name: telemetry-plugin-yaml
            defaultMode: 420
      containers:
        - name: apache
          image: 'registry.redhat.io/rhscl/httpd-24-rhel7:latest'
          ports:
            - containerPort: 8080
              protocol: TCP
          resources: {}
          volumeMounts:
            - name: plugin-yaml
              mountPath: /var/www/html
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
kind: Service
apiVersion: v1
metadata:
  name: apache
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  selector:
    app: apache
  type: ClusterIP
---
kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: apache
spec:
  host: apache-che.apps-crc.testing
  to:
    kind: Service
    name: apache
    weight: 100
  port:
    targetPort: 8080
  wildcardPolicy: None
Copy to Clipboard
$ oc apply -f manifest.yaml
Copy to Clipboard

验证步骤

  • 部署启动后,确认 plugin.yaml 在 web 服务器中可用:

    $ curl apache-che.apps-crc.testing/plugin.yaml
    Copy to Clipboard
4.7.2.13. 在 Dev Workspace 中指定 telemetry 插件
  1. 将以下内容添加到现有 Dev Workspace 的 components 字段中:

    components:
      ...
      - name: telemetry-plugin
        plugin:
          uri: http://apache-che.apps-crc.testing/plugin.yaml
    Copy to Clipboard
  2. 从 OpenShift Dev Spaces 仪表板启动 Dev Workspace。

验证步骤

  1. 验证 telemetry 插件容器是否在 Dev Workspace pod 中运行。在这里,通过检查编辑器中的 Workspace 视图来验证这一点。

    dev Workspace 遥测插件
  2. 在编辑器中编辑文件,并观察其遥测服务器日志中的事件。
4.7.2.14. 为所有 Dev Workspaces 应用 telemetry 插件

将 telemetry 插件设置为默认插件。默认插件会在 Dev Workspace 启动时为新的和现有的 Dev Workspaces 应用。

  • 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      devEnvironments:
        defaultPlugins:
        - editor: eclipse/che-theia/next     
    1
    
          plugins:                           
    2
    
          - 'http://apache-che.apps-crc.testing/plugin.yaml'
    Copy to Clipboard
    1
    用于为其设置默认插件的编辑器识别。
    2
    devfile v2 插件的 URL 列表。

验证步骤

  1. 从 Red Hat OpenShift Dev Spaces 仪表板启动新的或现有的 Dev Workspace。
  2. 按照 第 4.7.2.13 节 “在 Dev Workspace 中指定 telemetry 插件” 验证步骤验证 telemetry 插件是否正常工作。
4.7.2.15. 配置服务器日志记录

可以在 OpenShift Dev Spaces 服务器中微调单个日志记录器的日志级别。

使用 Operator 的 cheLogLevel 配置属性全局配置整个 OpenShift Dev Spaces 服务器的日志级别。请参阅 第 4.1.3 节 “CheCluster 自定义资源字段参考”。要在不是由 Operator 管理的安装中设置全局日志级别,请在 che ConfigMap 中指定 CHE_LOG_LEVEL 环境变量。

可以使用 CHE_LOGGER_CONFIG 环境变量在 OpenShift Dev Spaces 服务器中配置单个日志记录器的日志级别。

4.7.2.15.1. 配置日志级别

流程

  • 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "<key1=value1,key2=value2>" 
    1
    Copy to Clipboard
    1
    以逗号分隔的键值对列表,其中键是 OpenShift Dev Spaces 服务器日志输出和值是所需的日志级别。

    例 4.40. 为 WorkspaceManager配置调试模式

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
    Copy to Clipboard
4.7.2.15.2. 日志记录器命名

日志记录器的名称遵循使用这些日志记录器的内部服务器类的类名称。

4.7.2.15.3. 日志记录 HTTP 流量

流程

  • 要记录 OpenShift Dev Spaces 服务器和 Kubernetes 或 OpenShift 集群的 API 服务器之间的 HTTP 流量,请配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
    Copy to Clipboard
4.7.2.16. 使用 dsc 收集日志

安装 Red Hat OpenShift Dev Spaces 由 OpenShift 集群中运行多个容器组成。虽然可以从每个正在运行的容器手动收集日志,但 dsc 提供了可自动化进程的命令。

以下命令可使用 dsc 工具从 OpenShift 集群收集 Red Hat OpenShift Dev Spaces 日志:

DSC server:logs

收集现有的 Red Hat OpenShift Dev Spaces 服务器日志,并将其存储在本地机器的目录中。默认情况下,日志下载到计算机的临时目录中。但是,这可以通过指定 -d 参数来覆盖。例如,要将 OpenShift Dev Spaces 日志下载到 /home/user/che-logs/ 目录,请使用 命令

dsc server:logs -d /home/user/che-logs/
Copy to Clipboard

运行时,dsc server:logs 会在控制台中打印一条消息,指定用于存储日志文件的目录:

Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
Copy to Clipboard

如果在非默认项目中安装了 Red Hat OpenShift Dev Spaces,dsc server:logs 需要 -n <NAMESPACE&gt; paremeter,其中 & lt;NAMESPACE > 是安装 Red Hat OpenShift Dev Spaces 的 OpenShift 项目。例如,若要从 my-namespace 项目中的 OpenShift Dev Spaces 获取日志,请使用 命令

dsc server:logs -n my-namespace
Copy to Clipboard
dsc server:deploy
当使用 dsc 安装时,日志会在 OpenShift Dev Spaces 安装过程中自动收集。与 dsc server:logs 一样,可以使用 -d 参数指定目录日志。

其他资源

4.7.3. 监控 Dev Workspace Operator

您可以配置 OpenShift in-cluster 监控堆栈,以提取 Dev Workspace Operator 公开的指标。

4.7.3.1. 收集 Dev Workspace Operator 指标

使用 in-cluster Prometheus 实例收集有关 Dev Workspace Operator 的指标:

先决条件

  • 您的机构 OpenShift Dev Spaces 实例已安装并在 Red Hat OpenShift 中运行。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门
  • devworkspace-controller-metrics Service 在端口 8443 上公开指标。默认情况下已预先配置。

流程

  1. 创建用于检测 Dev Workspace Operator 指标服务的 ServiceMonitor。

    例 4.41. ServiceMonitor

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: devworkspace-controller
      namespace: openshift-devspaces 
    1
    
    spec:
      endpoints:
        - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
          interval: 10s 
    2
    
          port: metrics
          scheme: https
          tlsConfig:
            insecureSkipVerify: true
      namespaceSelector:
        matchNames:
          - openshift-operators
      selector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-controller
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    提取目标的速度。
  2. 允许 in-cluster Prometheus 实例检测 OpenShift Dev Spaces 命名空间中的 ServiceMonitor。默认的 OpenShift Dev Spaces 命名空间为 openshift-devspaces

    $ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
    Copy to Clipboard

验证

  1. 对于 OpenShift Dev Spaces 的新安装,请通过从 Dashboard 创建 OpenShift Dev Spaces 工作区来生成指标。
  2. 在 OpenShift Web 控制台的 Administrator 视图中,进入 ObserveMetrics
  3. 运行 PromQL 查询以确认指标是否可用。例如,输入 devworkspace_started_total 并点 Run queries

    如需了解更多指标,请参阅 第 4.7.3.2 节 “dev Workspace 特定指标”

提示

要排除缺少的指标,请查看 Prometheus 容器日志以了解与 RBAC 相关的错误:

  1. 获取 Prometheus pod 的名称:

    $ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
    Copy to Clipboard
  2. 显示上一步中的 Prometheus pod 的最后 20 行:

    $ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
    Copy to Clipboard
4.7.3.2. dev Workspace 特定指标

下表描述了 devworkspace-controller-metrics 服务公开的 Dev Workspace 特定指标。

表 4.40. 指标
Name类型描述标签

devworkspace_started_total

计数

Dev Workspace 启动事件的数量。

,routingclass

devworkspace_started_success_total

计数

Dev Workspaces 的数量成功进入 Running 阶段。

,routingclass

devworkspace_fail_total

计数

失败的 Dev Workspaces 数量。

原因

devworkspace_startup_time

Histogram

启动 Dev Workspace 的总时间(以秒为单位)。

,routingclass

表 4.41. 标签
Name描述

source

Dev Workspace 的 controller.devfile.io/devworkspace-source 标签。

字符串

routingclass

Dev Workspace 的 spec.routingclass

"basic|cluster|cluster-tls|web-terminal"

reason

工作区启动失败的原因。

"BadRequest|InfrastructureFailure|Unknown"

表 4.42. 启动失败原因
Name描述

BadRequest

由于用于创建 Dev Workspace 的无效 devfile,启动失败。

InfrastructureFailure

由于以下错误启动失败: CreateContainerError,RunContainerError,FailedScheduling,FailedMount.

Unknown

未知故障原因.

4.7.3.3. 从 OpenShift Web 控制台仪表板查看 Dev Workspace Operator 指标

在将 in-cluster Prometheus 实例配置为收集 Dev Workspace Operator 指标后,您可以在 OpenShift web 控制台的 Administrator 视角中查看自定义仪表板上的指标。

先决条件

流程

  • openshift-config-managed 项目中为仪表板定义创建 ConfigMap,并应用所需的标签。

    1. $ oc create configmap grafana-dashboard-dwo \
        --from-literal=dwo-dashboard.json="$(curl https://raw.githubusercontent.com/devfile/devworkspace-operator/main/docs/grafana/openshift-console-dashboard.json)" \
        -n openshift-config-managed
      Copy to Clipboard
      注意

      上一命令包含到来自上游社区的材料的链接。本材料代表了非常最新的可用内容和最新最佳实践。这些提示尚未由红帽的 QE 部门审查,并且尚未由广泛的用户组验证。请小心使用此信息。

    2. $ oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed
      Copy to Clipboard
      注意

      仪表板定义基于 Grafana 6.x 仪表板。OpenShift Web 控制台不支持所有 Grafana 6.x 仪表板功能。

验证步骤

  1. 在 OpenShift Web 控制台的 Administrator 视图中,进入 ObserveDashboards
  2. 进入 DashboardChe Server JVM,验证仪表板面板是否包含数据。
4.7.3.4. Dev Workspace Operator 的仪表板

OpenShift Web 控制台自定义仪表板基于 Grafana 6.x,显示 Dev Workspace Operator 中的以下指标。

注意

Grafana 6.x 仪表板的所有功能都作为 OpenShift Web 控制台仪表板被支持。

4.7.3.4.1. dev Workspace 指标

Dev Workspace Metrics 面板中会显示 Dev Workspace 特定指标。

图 4.1. Dev Workspace Metrics 面板

Grafana 仪表板面板,其中包含与 'DevWorkspace 启动相关的指标
平均工作区开始时间
平均工作区启动持续时间。
工作区启动
成功和失败的工作区启动数量。
dev Workspace 成功和失败
成功和失败的 Dev Workspace 启动之间的比较。
dev Workspace 失败率
工作区启动失败数量和工作空间启动总数之间的比率。
dev Workspace 启动失败原因

显示工作空间启动故障的 pie chart:

  • BadRequest
  • InfrastructureFailure
  • Unknown
4.7.3.4.2. Operator 指标

Operator Metrics 面板中会显示特定于 Operator 的指标。

图 4.2. Operator Metrics 面板

包含 Operator 指标的 Grafana 仪表板面板
flight 中的 Webhook
不同 Webhook 请求数量之间的比较。
工作队列深度
工作队列中的协调请求数。
memory
Dev Workspace 控制器和 Dev Workspace Webhook 服务器的内存用量。
平均每秒协调计数(DWO)
Dev Workspace 控制器的平均每秒协调数数。

4.7.4. 监控 Dev Spaces 服务器

您可以将 OpenShift Dev Spaces 配置为公开 JVM 指标,如 JVM 内存和 OpenShift Dev Spaces Server 的类加载。

4.7.4.1. 启用并公开 OpenShift Dev Spaces 服务器指标

OpenShift Dev Spaces 在 che-host Service 的端口 8087 上公开 JVM 指标。您可以配置此行为。

流程

4.7.4.2. 使用 Prometheus 收集 OpenShift Dev Spaces 服务器指标

使用 in-cluster Prometheus 实例为 OpenShift Dev Spaces Server 收集、存储和查询 JVM 指标:

先决条件

流程

  1. 创建 ServiceMonitor 以检测 OpenShift Dev Spaces JVM 指标服务。

    例 4.42. ServiceMonitor

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: che-host
      namespace: openshift-devspaces 
    1
    
    spec:
      endpoints:
        - interval: 10s 
    2
    
          port: metrics
          scheme: http
      namespaceSelector:
        matchNames:
          - openshift-devspaces 
    3
    
      selector:
        matchLabels:
          app.kubernetes.io/name: devspaces
    Copy to Clipboard
    1 3
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    提取目标的速度。
  2. 创建 Role 和 RoleBinding,以允许 Prometheus 查看指标。

    例 4.43. 角色

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: prometheus-k8s
      namespace: openshift-devspaces 
    1
    
    rules:
      - verbs:
          - get
          - list
          - watch
        apiGroups:
          - ''
        resources:
          - services
          - endpoints
          - pods
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces

    例 4.44. RoleBinding

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: view-devspaces-openshift-monitoring-prometheus-k8s
      namespace: openshift-devspaces 
    1
    
    subjects:
      - kind: ServiceAccount
        name: prometheus-k8s
        namespace: openshift-monitoring
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: prometheus-k8s
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
  3. 允许 in-cluster Prometheus 实例检测 OpenShift Dev Spaces 命名空间中的 ServiceMonitor。默认的 OpenShift Dev Spaces 命名空间为 openshift-devspaces

    $ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
    Copy to Clipboard

验证

  1. 在 OpenShift Web 控制台的 Administrator 视图中,进入 ObserveMetrics
  2. 运行 PromQL 查询以确认指标是否可用。例如,输入 process_uptime_seconds{job="che-host"},然后单击 Run queries
提示

要排除缺少的指标,请查看 Prometheus 容器日志以了解与 RBAC 相关的错误:

  1. 获取 Prometheus pod 的名称:

    $ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
    Copy to Clipboard
  2. 显示上一步中的 Prometheus pod 的最后 20 行:

    $ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
    Copy to Clipboard
4.7.4.3. 从 OpenShift Web 控制台仪表板查看 OpenShift Dev Spaces Server

在将 in-cluster Prometheus 实例配置为收集 OpenShift Dev Spaces Server JVM 指标后,您可以在 OpenShift Web 控制台的 Administrator 视角中查看自定义仪表板上的指标。

先决条件

流程

  • openshift-config-managed 项目中为仪表板定义创建 ConfigMap,并应用所需的标签。

    1. $ oc create configmap grafana-dashboard-devspaces-server \
        --from-literal=devspaces-server-dashboard.json="$(curl https://raw.githubusercontent.com/eclipse-che/che-server/main/docs/grafana/openshift-console-dashboard.json)" \
        -n openshift-config-managed
      Copy to Clipboard
      注意

      上一命令包含到来自上游社区的材料的链接。本材料代表了非常最新的可用内容和最新最佳实践。这些提示尚未由红帽的 QE 部门审查,并且尚未由广泛的用户组验证。请小心使用此信息。

    2. $ oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed
      Copy to Clipboard
      注意

      仪表板定义基于 Grafana 6.x 仪表板。OpenShift Web 控制台不支持所有 Grafana 6.x 仪表板功能。

验证步骤

  1. 在 OpenShift Web 控制台的 Administrator 视图中,进入 ObserveDashboards
  2. 进入 DashboardDev Workspace Operator,验证仪表板面板是否包含数据。

    图 4.3. 快速事实

    *JVM 快速事实* 面板

    图 4.4. JVM 内存

    *JVM Memory* 面板

    图 4.5. JVM Misc

    *JVM Misc* 面板

    图 4.6. JVM 内存池(heap)

    *JVM Memory Pools (heap)* 面板

    图 4.7. JVM 内存池(Non-Heap)

    *JVM Memory Pools (non-heap)* 面板

    图 4.8. 垃圾回收

    *JVM 垃圾回收* 面板

    图 4.9. 类加载

    *JVM 类加载* 面板

    图 4.10. 缓冲池

    *JVM 缓冲池* 面板

4.8. 配置网络

4.8.1. 配置网络策略

默认情况下,OpenShift 集群中的所有 Pod 都可以相互通信,即使它们位于不同的命名空间中。在 OpenShift Dev Spaces 中,这可能会导致一个用户项目中的工作区 Pod 将流量发送到其他用户项目中的另一个工作区 Pod。

为安全起见,可以使用 NetworkPolicy 对象配置多租户隔离,以限制用户项目中的所有传入的通信。但是,OpenShift Dev Spaces 项目中的 Pod 必须能够与用户项目中的 Pod 通信。

先决条件

  • OpenShift 集群有网络限制,如多租户隔离。

流程

  • allow-from-openshift-devspaces NetworkPolicy 应用到每个用户项目。allow-from-openshift-devspaces NetworkPolicy 允许从 OpenShift Dev Spaces 命名空间的传入流量到用户项目中的所有 Pod。

    例 4.45. allow-from-openshift-devspaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: allow-from-openshift-devspaces
    spec:
        ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    kubernetes.io/metadata.name: openshift-devspaces   
    1
    
        podSelector: {}   
    2
    
        policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 选择项目中的所有 Pod。
  • OPTIONAL : 在使用网络策略应用配置多租户隔离时,还必须应用 allow-from-openshift-apiserverallow-from-workspaces-namespaces NetworkPolicies 到 openshift-devspacesallow-from-openshift-apiserver NetworkPolicy 允许从 openshift-apiserver 命名空间中的传入流量到 devworkspace-webhook-server 启用 Webhook。allow-from-workspaces-namespaces NetworkPolicy 允许从每个用户项目的传入流量到 che-gateway pod。

    例 4.46. allow-from-openshift-apiserver.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-apiserver
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-webhook-server   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: openshift-apiserver
      policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 只选择 devworkspace-webhook-server pod

    例 4.47. allow-from-workspaces-namespaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-workspaces-namespaces
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector: {}   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  app.kubernetes.io/component: workspaces-namespace
      policyTypes:
        - Ingress
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    podSelector 选择 OpenShift Dev Spaces 命名空间中的所有 pod。
  • 第 4.2 节 “配置项目”
  • 网络隔离
  • 使用网络策略配置多租户隔离

4.8.2. 配置 Dev Spaces 主机名

此流程描述了如何将 OpenShift Dev Spaces 配置为使用自定义主机名。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门
  • 生成证书和私钥文件。
重要

要生成私钥和证书的对,相同的证书颁发机构(CA)必须与其他 OpenShift Dev Spaces 主机一起使用。

重要

请求 DNS 供应商将自定义主机名指向集群入口。

流程

  1. 为 OpenShift Dev Spaces 预创建项目:

    $ oc create project openshift-devspaces
    Copy to Clipboard
  2. 创建 TLS secret:

    $ oc create secret tls <tls_secret_name> \ 
    1
    
    --key <key_file> \ 
    2
    
    --cert <cert_file> \ 
    3
    
    -n openshift-devspaces
    Copy to Clipboard
    1
    TLS secret 名称
    2
    具有私钥的文件
    3
    具有证书的文件
  3. 在 secret 中添加所需的标签:

    $ oc label secret <tls_secret_name> \ 
    1
    
    app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    Copy to Clipboard
    1
    TLS secret 名称
  4. 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      networking:
        hostname: <hostname>     
    1
    
        tlsSecretName: <secret>  
    2
    Copy to Clipboard
    1
    自定义 Red Hat OpenShift Dev Spaces 服务器主机名
    2
    TLS secret 名称
  5. 如果 OpenShift Dev Spaces 已部署,请等待所有 OpenShift Dev Spaces 组件的推出完成。

4.8.3. 将不可信 TLS 证书导入到 Dev Spaces

OpenShift Dev Spaces 组件与外部服务通信通过 TLS 加密。它们需要由可信证书颁发机构(CA)签名的 TLS 证书。因此,您必须导入到 OpenShift Dev Spaces 中由外部服务使用的所有不受信任的 CA 链,例如:

  • 代理
  • 身份供应商(OIDC)
  • 源代码存储库供应商(Git)

OpenShift Dev Spaces 使用 OpenShift Dev Spaces 项目中的标记 ConfigMap 作为 TLS 证书的源。ConfigMap 可以有任意数量的键,每个键都有随机数量的证书。所有证书都挂载到:

  • OpenShift Dev Spaces 服务器和仪表板 pod 的 /public-certs 位置
  • 工作区 pod 的 /etc/pki/ca-trust/extracted/pem 位置

配置 CheCluster 自定义资源,以禁用在 /etc/pki/ca-trust/extracted/pem 处的 CA 捆绑包挂载。证书将被挂载到 /public-certs,以保持之前版本中的行为。

注意

配置 CheCluster 自定义资源,以禁用在路径 /etc/pki/ca-trust/extracted/pem 下挂载 CA 捆绑包。在这种情况下,证书将被挂载到路径 /public-certs 下。

spec:
  devEnvironments:
    trustedCerts:
      disableWorkspaceCaBundleMount: true
Copy to Clipboard
重要

在 OpenShift 集群中,OpenShift Dev Spaces Operator 会自动将 Red Hat Enterprise Linux CoreOS (RHCOS)信任捆绑包添加到挂载的证书中。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门
  • openshift-devspaces 项目存在。
  • 对于每个要导入的 CA 链:使用 PEM 格式的 root CA 和中间证书,采用 ca-cert-for-devspaces- <count>.pem 文件。

流程

  1. 将所有 CA 链 PEM 文件链到 custom-ca-certificates.pem 文件中,并删除与 Java 信任存储不兼容的返回字符。

    $ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
    Copy to Clipboard
  2. 使用所需的 TLS 证书创建 custom-ca-certificates ConfigMap:

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
    Copy to Clipboard
  3. 标记 custom-ca-certificates ConfigMap:

    $ oc label configmap custom-ca-certificates \
        app.kubernetes.io/component=ca-bundle \
        app.kubernetes.io/part-of=che.eclipse.org \
        --namespace=openshift-devspaces
    Copy to Clipboard
  4. 如果之前尚未部署,部署 OpenShift Dev Spaces。否则,请等待 OpenShift Dev Spaces 组件的推出完成。
  5. 重启正在运行的工作区以使更改生效。

验证步骤

  1. 验证 ConfigMap 是否包含您的自定义 CA 证书。此命令返回 PEM 格式的 CA 捆绑包证书:

    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
    Copy to Clipboard
  2. 在 OpenShift Dev Spaces 服务器日志中验证导入的证书计数是否不是 null :

    oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep tls-ca-bundle.pem
    Copy to Clipboard
  3. 启动一个工作区,获取创建它的项目名称:< workspace_namespace > 并等待工作区启动。
  4. 验证 ca-certs-merged ConfigMap 是否包含您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:

    oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.tls-ca-bundle\.pem}'
    Copy to Clipboard
  5. 验证工作区 pod 是否挂载 ca-certs-merged ConfigMap:

    oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep ca-certs-merged
    Copy to Clipboard
  6. 获取工作区 pod 名称 < workspace_pod_name>:

    oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \
    Copy to Clipboard
  7. 验证工作区容器是否具有您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:

    oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    Copy to Clipboard

4.8.4. 添加标签和注解

4.8.4.1. 配置 OpenShift 路由以使用路由器划分

您可以为 OpenShift Route 配置标签、注解和域,以用于 路由器分片

先决条件

流程

  • 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      networking:
        labels: <labels> 
    1
    
        domain: <domain> 
    2
    
        annotations: <annotations> 
    3
    Copy to Clipboard
    1
    一个无结构的键值映射,目标入口控制器用来过滤一组 Routes to service。
    2
    目标入口控制器服务的 DNS 名称。
    3
    一个无结构的键值映射,它存储了一个资源。

4.8.5. 配置工作区端点基域

了解如何为工作区端点配置基域。默认情况下,OpenShift Dev Spaces Operator 会自动检测到基域。要更改它,您需要在 CheCluster 自定义资源中配置 CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX 属性。

spec:
  components:
    cheServer:
      extraProperties:
        CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<...>" 
1
Copy to Clipboard
1
工作区端点基域,如 my-devspaces.example.com

流程

  1. 配置工作区端点基域:

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' -p \
    '{"spec":
        {"components":
            {"cheServer":
                {"extraProperties":
                    {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'
    Copy to Clipboard

4.8.6. 配置代理

了解如何为 Red Hat OpenShift Dev Spaces 配置代理。步骤包括为代理凭证创建 Kubernetes Secret,并在 CheCluster 自定义资源中配置必要的代理设置。代理设置通过环境变量传播到操作对象和工作区。

在 OpenShift 集群中,您不需要配置代理设置。OpenShift Dev Spaces Operator 会自动使用 OpenShift 集群范围的代理配置。但是,您可以通过在 CheCluster 自定义资源中指定代理设置来覆盖代理设置。

流程

  1. (可选)在 openshift-devspaces 命名空间中创建 Secret,其中包含代理服务器的用户和密码。secret 必须具有 app.kubernetes.io/part-of=che.eclipse.org 标签。如果代理服务器不需要身份验证,请跳过这一步。

    oc apply -f - <<EOF
    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-proxy-credentials
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
    type: Opaque
    stringData:
      user: <user>          
    1
    
      password: <password>  
    2
    
    EOF
    Copy to Clipboard
    1
    代理服务器的用户名。
    2
    代理服务器的密码。
  2. 通过在 CheCluster 自定义资源中设置以下属性,为 OpenShift 集群配置代理或覆盖集群范围的代理配置:

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' -p \
    '{"spec":
        {"components":
            {"cheServer":
                {"proxy":
                    {"credentialsSecretName" : "<secretName>",                      
    1
    
                     "nonProxyHosts"         : ["<host_1>"],                        
    2
    
                     "port"                  : "<port>",                            
    3
    
                     "url"                   : "<protocol>://<domain>"}}}}}'    
    4
    Copy to Clipboard
    1
    上一步中创建的凭据 secret 名称。
    2
    可以直接访问的主机列表,无需使用代理。使用以下格式,.<DOMAIN > 指定一个通配符域。OpenShift Dev Spaces Operator 会自动将 .svc 和 Kubernetes 服务主机添加到非代理主机列表中。在 OpenShift 中,OpenShift Dev Spaces Operator 将集群范围的代理配置中的非代理主机列表与自定义资源合并。
    重要

    在一些代理配置中,localhost 可能不会转换为 127.0.0.1。在这种情况下,应该同时指定 localhost127.0.0.1

    代理服务器的端口。
    代理服务器的协议和域。

验证步骤

  1. 启动工作区
  2. 验证工作区 pod 是否包含 HTTP_PROXYHTTPS_PROXYhttp_proxyhttps_proxy 环境变量,每个变量都设置为 < protocol> ://<user& gt;:<password@<domain>:<port>
  3. 验证工作区 pod 是否包含 NO_PROXYno_proxy 环境变量,每个变量都设置为用逗号分开的非代理主机列表。

4.9. 配置存储

警告

OpenShift Dev Spaces 不支持网络文件系统(NFS)协议。

4.9.1. 配置存储类

要将 OpenShift Dev Spaces 配置为使用配置的基础架构存储,请使用存储类安装 OpenShift Dev Spaces。当您要绑定由非默认置备程序提供的持久性卷时,这特别有用。

OpenShift Dev Spaces 有一个组件,需要持久性卷来存储数据:

  • OpenShift Dev Spaces 工作区。OpenShift Dev Spaces 工作区使用卷存储源代码,如 /projects 卷。
注意

只有工作区不是临时的时,OpenShift Dev Spaces 工作区源代码才会存储在持久性卷中。

持久性卷声明事实:

  • OpenShift Dev Spaces 不会在基础架构中创建持久性卷。
  • OpenShift Dev Spaces 使用持久性卷声明(PVC)来挂载持久性卷。
  • 第 2.3.1.2 节 “dev Workspace operator” 创建持久性卷声明。

    在 OpenShift Dev Spaces 配置中定义存储类名称,以使用 OpenShift Dev Spaces PVC 中的存储类功能。

流程

使用 CheCluster 自定义资源定义来定义存储类:

  1. 定义存储类名称 :配置 CheCluster 自定义资源,并安装 OpenShift Dev Spaces。请参阅 第 4.1.1 节 “在安装过程中使用 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
    Copy to Clipboard
    1 3
    持久性卷声明大小。
    2 4
    持久性卷声明的存储类。当省略或留空时,会使用默认存储类。
    5
    持久性卷声明策略。支持的策略有:per-user (一个卷中的所有工作区持久性卷声明)、per-workspace (每个工作区都有自己的独立持久性卷声明)和 ephemeral (非持久性存储,当工作区停止时本地更改将会丢失。)

4.9.2. 配置存储策略

通过选择存储策略,可以将 OpenShift Dev Spaces 配置为向工作区提供持久性或非持久性存储。默认情况下,所选存储策略将应用到所有新创建的工作区。用户可以为 devfile 中的工作区选择非默认存储策略,或者通过 URL 参数 选择。

可用的存储策略:

  • 每个用户 :对用户创建的所有工作区使用单个 PVC。
  • per-workspace: 每个工作区都会被赋予自己的 PVC。
  • Ephemeral: Non-persistent storage; 当工作区停止后,任何本地更改都会丢失。

OpenShift Dev Spaces 中使用的默认存储策略是 每个用户

流程

  1. 将 Che Cluster Custom Resource 中的 pvcStrategy 字段设置为 per-userper-workspaceephemeral
注意
spec:
  devEnvironments:
    storage:
      pvc:
        pvcStrategy: 'per-user' 
1
Copy to Clipboard
1
可用的存储策略是 按用户、每个 工作区临时的

4.9.3. 配置存储大小

您可以使用 per-userper-workspace 存储策略配置持久性卷声明(PVC)大小。您必须使用 CheCluster 自定义资源的 PVC 大小,格式为 Kubernetes 资源数量。有关可用存储策略的详情,请查看 此页面

默认持久性卷声明大小:

  • per-user: 10Gi
    Copy to Clipboard
  • per-workspace: 5Gi
    Copy to Clipboard

流程

  1. 在 Che Cluster Custom Resource 中为所需的存储策略设置适当的 claimSize 字段。
注意
spec:
  devEnvironments:
    storage:
      pvc:
        pvcStrategy: '<strategy_name>'  
1

        perUserStrategyPvcConfig: 
2

          claimSize: <resource_quantity> 
3

        perWorkspaceStrategyPvcConfig:  
4

          claimSize: <resource_quantity> 
5
Copy to Clipboard
1
选择存储策略: per-userper-workspaceephemeral。注: 临时存储 策略不使用持久性存储,因此您无法配置其存储大小或其他与 PVC 相关的属性。
2 4
在下一行中指定声明大小,或者省略下一行来设置默认的声明大小值。只有在您选择此存储策略时,才会使用指定的声明大小。
3 5
声明大小必须指定为 Kubernetes 资源数量。可用数量单位包括: EiPiTiGiMiKi

4.9.4. 持久用户主页

Red Hat OpenShift Dev Spaces 提供了一个永久的主目录功能,允许每个非临时工作区在工作空间重启后保留其 /home/user 目录。您可以通过将 spec.devEnvironments.persistUserHome.enabled 设置为 true,在 CheCluster 中启用此功能。

对于新启动的工作区,此功能会创建一个挂载到工具容器的 /home/user 路径的 PVC。在本文档中,将使用"tools 容器"来指代 devfile 中的第一个容器。此容器是默认包含项目源代码的容器。

当首次挂载 PVC 时,持久性卷的内容为空,因此必须使用 /home/user 目录内容填充。

默认情况下,persistent UserHome 功能为每个名为 init-persistent-home 的新工作区 pod 创建一个 init 容器。此 init 容器使用工具容器镜像创建,并负责运行 stow 命令在持久性卷中创建符号链接以填充 /home/user 目录。

注意

对于不能符号链接到 /home/user 目录的文件,如 .viminfo.bashrc 文件,则会使用 cp 而不是 stow

stow 命令的主要功能是运行:

stow -t /home/user/ -d /home/tooling/ --no-folding
Copy to Clipboard

以上命令在 /home/user 中为位于 /home/tooling 的文件和目录创建符号链接。这会使用指向 /home/tool 中内容的符号链接填充持久卷。因此,persistent UserHome 功能预期工具镜像在 /home/tooling 中包含其 /home/user/ 内容。

例如,如果工具容器镜像包含 home/tooling 目录中的文件,如 .config.config-folder/another-file,则 stow 将以以下方式在持久性卷中创建符号链接:

图 4.11. 启用 persistUserHome 的工具容器

持久的用户主页示例场景

init 容器将 stow 命令的输出写入 /home/user/.stow.log,并且仅在持久性卷第一次挂载到工作区时运行 stow

使用 stow 命令在持久性卷中填充 /home/user 内容有两个主要优点:

  1. 与在持久性卷中创建 /home/user 目录内容的副本相比,创建符号链接速度更快且消耗较少的存储。为了以不同方式放置它,本例中的持久卷包含符号链接,而不是实际文件本身。
  2. 如果使用现有二进制文件、配置和文件的较新版本更新工具镜像,则 init 容器不需要 研究 新版本,因为现有符号链接将链接到 /home/tooling 中的较新版本。
注意

如果工具镜像使用额外的二进制文件或文件更新,则不会以符号形式链接到 /home/user 目录,因为 stow 命令不会被再次运行。在这种情况下,用户必须删除 /home/user/.stow_completed 文件,然后重新启动工作区来重新运行 stow

persistUserHome 工具镜像要求

persistUserHome 依赖于用于工作区的工具镜像。默认情况下,OpenShift Dev Spaces 使用通用基础镜像(UDI)作为示例工作区,它支持 persistentUserHome 开箱即用。

如果您使用自定义镜像,应该满足三个要求来支持 persistUserHome 功能。

  1. 工具镜像应包含 stow 版本 >= 2.4.0。
  2. $HOME 环境变量设置为 /home/user
  3. 在工具镜像中,要包含 /home/user 内容的目录是 /home/tooling

由于要求三个,例如,默认的 UDI 镜像将 /home/user 内容添加到 /home/tooling 中,并运行:

RUN stow -t /home/user/ -d /home/tooling/ --no-folding
Copy to Clipboard

在 Dockerfile 中,使 /home/tooling 中的文件可以从 /home/user 访问,即使没有使用 persistUserHome 功能。

4.10. 配置仪表板

4.10.1. 配置入门示例

此流程描述了如何配置 OpenShift Dev Spaces 仪表板来显示自定义示例。

先决条件

  • 具有 OpenShift 集群管理权限的活跃的 oc 会话。请参阅 CLI 入门

流程

  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
    Copy to Clipboard
    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
    Copy to Clipboard
  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
    Copy to Clipboard
  4. 刷新 OpenShift Dev Spaces Dashboard 页面,以查看新的示例。

4.10.2. 配置编辑器定义

了解如何配置 OpenShift Dev Spaces 编辑器定义。

先决条件

  • 具有 OpenShift 集群管理权限的活跃的 oc 会话。请参阅 CLI 入门

流程

  1. 使用编辑器定义配置创建 my-editor-definition-devfile.yaml YAML 文件。

    重要

    确保您在 metadata.attributes 下为 publisherversion 提供实际值。它们用于构建编辑器 id 以及编辑器名称,格式为 publisher/name/version

    您可以在下面找到支持的值,包括可选的值:

    # Version of the devile schema
    schemaVersion: 2.2.2
    # Meta information of the editor
    metadata:
      # (MANDATORY) The editor name
      # Must consist of lower case alphanumeric characters, '-' or '.'
      name: editor-name
      displayName: Display Name
      description: Run Editor Foo on top of Eclipse Che
      # (OPTIONAL) Array of tags of the current editor. The Tech-Preview tag means the option is considered experimental and is not recommended for production environments. While it can include new features and improvements, it may still contain bugs or undergo significant changes before reaching a stable version.
      tags:
        - Tech-Preview
      # Additional attributes
      attributes:
        title: This is my editor
        # (MANDATORY) The publisher name
        publisher: publisher
        # (MANDATORY) The editor version
        version: version
        repository: https://github.com/editor/repository/
        firstPublicationDate: '2024-01-01'
        iconMediatype: image/svg+xml
        iconData: |
          <icon-content>
    # List of editor components
    components:
      # Name of the component
      - name: che-code-injector
        # Configuration of devworkspace-related container
        container:
          # Image of the container
          image: 'quay.io/che-incubator/che-code:insiders'
          # The command to run in the dockerimage component instead of the default one provided in the image
          command:
            - /entrypoint-init-container.sh
          # (OPTIONAL) List of volumes mounts that should be mounted in this container
          volumeMounts:
              # The name of the mount
            - name: checode
              # The path of the mount
              path: /checode
          # (OPTIONAL) The memory limit of the container
          memoryLimit: 256Mi
          # (OPTIONAL) The memory request of the container
          memoryRequest: 32Mi
          # (OPTIONAL) The CPU limit of the container
          cpuLimit: 500m
          # (OPTIONAL) The CPU request of the container
          cpuRequest: 30m
      # Name of the component
      - name: che-code-runtime-description
        # (OPTIONAL) Map of implementation-dependant free-form YAML attributes
        attributes:
          # The component within the architecture
          app.kubernetes.io/component: che-code-runtime
          # The name of a higher level application this one is part of
          app.kubernetes.io/part-of: che-code.eclipse.org
          # Defines a container component as a "container contribution". If a flattened DevWorkspace has a container component with the merge-contribution attribute, then any container contributions are merged into that container component
          controller.devfile.io/container-contribution: true
        container:
          # Can be a dummy image because the component is expected to be injected into workspace dev component
          image: quay.io/devfile/universal-developer-image:latest
          # (OPTIONAL) List of volume mounts that should be mounted in this container
          volumeMounts:
              # The name of the mount
            - name: checode
              # (OPTIONAL) The path in the component container where the volume should be mounted. If no path is defined, the default path is the is /<name>
              path: /checode
          # (OPTIONAL) The memory limit of the container
          memoryLimit: 1024Mi
          # (OPTIONAL) The memory request of the container
          memoryRequest: 256Mi
          # (OPTIONAL) The CPU limit of the container
          cpuLimit: 500m
          # (OPTIONAL) The CPU request of the container
          cpuRequest: 30m
          # (OPTIONAL) Environment variables used in this container
          env:
            - name: ENV_NAME
              value: value
          # Component endpoints
          endpoints:
            # Name of the editor
            - name: che-code
              # (OPTIONAL) Map of implementation-dependant string-based free-form attributes
              attributes:
                # Type of the endpoint. You can only set its value to main, indicating that the endpoint should be used as the mainUrl in the workspace status (i.e. it should be the URL used to access the editor in this context)
                type: main
                # An attribute that instructs the service to automatically redirect the unauthenticated requests for current user authentication. Setting this attribute to true has security consequences because it makes Cross-site request forgery (CSRF) attacks possible. The default value of the attribute is false.
                cookiesAuthEnabled: true
                # Defines an endpoint as "discoverable", meaning that a service should be created using the endpoint name (i.e. instead of generating a service name for all endpoints, this endpoint should be statically accessible)
                discoverable: false
                # Used to secure the endpoint with authorization on OpenShift, so that not anyone on the cluster can access the endpoint, the attribute enables authentication.
                urlRewriteSupported: true
              # Port number to be used within the container component
              targetPort: 3100
              # (OPTIONAL) Describes how the endpoint should be exposed on the network (public, internal, none)
              exposure: public
              # (OPTIONAL) Describes whether the endpoint should be secured and protected by some authentication process
              secure: true
              # (OPTIONAL) Describes the application and transport protocols of the traffic that will go through this endpoint
              protocol: https
        # Mandatory name that allows referencing the component from other elements
      - name: checode
        # (OPTIONAL) Allows specifying the definition of a volume shared by several other components. Ephemeral volumes are not stored persistently across restarts. Defaults to false
        volume: {ephemeral: true}
    # (OPTIONAL) Bindings of commands to events. Each command is referred-to by its name
    events:
      # IDs of commands that should be executed before the devworkspace start. These commands would typically be executed in an init container
      preStart:
        - init-container-command
      # IDs of commands that should be executed after the devworkspace has completely started. In the case of Che-Code, these commands should be executed after all plugins and extensions have started, including project cloning. This means that those commands are not triggered until the user opens the IDE within the browser
      postStart:
        - init-che-code-command
    # (OPTIONAL) Predefined, ready-to-use, devworkspace-related commands
    commands:
        # Mandatory identifier that allows referencing this command
      - id: init-container-command
        apply:
          # Describes the component for the apply command
          component: che-code-injector
        # Mandatory identifier that allows referencing this command
      - id: init-che-code-command
        # CLI Command executed in an existing component container
        exec:
          # Describes component for the exec command
          component: che-code-runtime-description
          # The actual command-line string
          commandLine: 'nohup /checode/entrypoint-volume.sh > /checode/entrypoint-logs.txt
            2>&1 &'
    Copy to Clipboard
  2. 使用编辑器定义内容创建 ConfigMap:

    oc create configmap my-editor-definition --from-file=my-editor-definition-devfile.yaml -n openshift-devspaces
    Copy to Clipboard
  3. 在 ConfigMap 中添加所需的标签:

    oc label configmap my-editor-definition app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=editor-definition -n openshift-devspaces
    Copy to Clipboard
  4. 刷新 OpenShift Dev Spaces Dashboard 页面,以查看新的可用编辑器。
4.10.2.1. 检索编辑器定义

OpenShift Dev Spaces 仪表板 API 也从以下 URL 提供编辑器定义:

https://<openshift_dev_spaces_fqdn>/dashboard/api/editors

对于 第 4.10.2 节 “配置编辑器定义” 中的示例,可以通过访问以下 URL 来检索编辑器定义:

https://<openshift_dev_spaces_fqdn> /dashboard/api/editors/devfile?che-editor=publisher/editor-name/version

提示

从 OpenShift 集群中检索编辑器定义时,可以通过仪表板服务访问 OpenShift Dev Spaces 仪表板 API: http://devspaces-dashboard.openshift-devspaces.svc.cluster.local:8080/dashboard/api/editors

其他资源

4.10.3. 配置默认编辑器定义

了解如何配置 OpenShift Dev Spaces 默认编辑器定义。

先决条件

  • 具有 OpenShift 集群管理权限的活跃的 oc 会话。请参阅 CLI 入门
  • jq.请参阅 下载 jq

流程

  1. 查找可用编辑器的 ID:

    oc exec deploy/devspaces-dashboard -n openshift-devspaces  \
        -- curl -s http://localhost:8080/dashboard/api/editors | jq -r '.[] | "\(.metadata.attributes.publisher)/\(.metadata.name)/\(.metadata.attributes.version)"'
    Copy to Clipboard
  2. 配置 defaultEditor

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' \
        -p '{"spec":{"devEnvironments":{"defaultEditor": "<default_editor>"}}}'
    1
    Copy to Clipboard
    1
    可以使用插件 ID 或 URI 指定创建工作区的默认编辑器。插件 ID 的格式应为: 发布者/名称/版本。请参阅第一步中的可用的编辑器 ID。

4.10.4. Concealing 编辑器定义

了解如何编写 OpenShift Dev Spaces 编辑器定义。当您想从 Dashboard UI 隐藏所选编辑器时,这非常有用,例如隐藏 IntelliJ IDEA Ultimate,且只有 Visual Studio Code - 开源可见。

先决条件

  • 具有 OpenShift 集群管理权限的活跃的 oc 会话。请参阅 CLI 入门
  • jq.请参阅 下载 jq

流程

  1. 查找部署 OpenShift Dev Spaces Operator 的命名空间:

    OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
    Copy to Clipboard
  2. 查找可用的编辑器定义文件:

    oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- ls /tmp/editors-definitions
    Copy to Clipboard

    输出应类似以下示例:

    che-code-insiders.yaml
    che-code-latest.yaml
    che-idea-latest.yaml
    che-idea-next.yaml
    Copy to Clipboard
  3. 选择要 conceal 的编辑器定义。例如,要整合 che-idea-next.yaml 编辑器定义,请设置编辑器定义文件名称:

    CHE_EDITOR_CONCEAL_FILE_NAME=che-idea-next.yaml
    Copy to Clipboard
  4. 为拥塞的编辑器定义定义 ConfigMap 名称:

    CHE_EDITOR_CONCEAL_CONFIGMAP_NAME=che-conceal-$CHE_EDITOR_CONCEAL_FILE_NAME
    Copy to Clipboard
  5. 创建 ConfigMap:

    oc create configmap $CHE_EDITOR_CONCEAL_CONFIGMAP_NAME \
        --namespace $OPERATOR_NAMESPACE \
        --from-literal=$CHE_EDITOR_CONCEAL_FILE_NAME=""
    Copy to Clipboard
  6. 查找 Operator 订阅名称和命名空间(如果存在):

    SUBSCRIPTION=$(oc get subscriptions \
        --all-namespaces \
        --output json \
            | jq -r '.items[] | select(.spec.name=="devspaces")')
    SUBSCRIPTION_NAMESPACE=$(echo $SUBSCRIPTION | jq -r '.metadata.namespace')
    SUBSCRIPTION_NAME=$(echo $SUBSCRIPTION | jq -r '.metadata.name')
    Copy to Clipboard
  7. 修补 Kubernetes 资源以使用空编辑器定义挂载 ConfigMap。要修补的资源取决于 Operator 订阅是否存在。如果订阅存在,则应该修补订阅。如果没有,请修补 Operator 部署:

    if [[ -n $SUBSCRIPTION_NAMESPACE ]]; then
        if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config}') == "" ]]; then
            oc patch subscription $SUBSCRIPTION_NAME \
              --namespace $SUBSCRIPTION_NAMESPACE \
              --type json \
              --patch '[{
                    "op":"add",
                    "path":"/spec/config",
                    "value": {}
                }]'
        fi
    
        if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumes}') == "" ]]; then
            oc patch subscription $SUBSCRIPTION_NAME \
              --namespace $SUBSCRIPTION_NAMESPACE \
              --type json \
              --patch '[{
                    "op":"add",
                    "path":"/spec/config/volumes",
                    "value": []
                }]'
        fi
    
        if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumeMounts}') == "" ]]; then
            oc patch subscription $SUBSCRIPTION_NAME \
              --namespace $SUBSCRIPTION_NAMESPACE \
              --type json \
              --patch '[{
                    "op":"add",
                    "path":"/spec/config/volumeMounts",
                    "value": []
                }]'
        fi
    
        oc patch subscription $SUBSCRIPTION_NAME \
          --namespace $SUBSCRIPTION_NAMESPACE \
          --type json \
          --patch '[{
            "op":"add",
            "path":"/spec/config/volumes/-",
            "value": {
                "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "configMap": {
                    "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'"
                }
            }
          },
          {
            "op":"add",
            "path":"/spec/config/volumeMounts/-",
            "value":{
                "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'",
                "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'"
            }
          }]'
    else
        oc patch deployment devspaces-operator \
          --namespace $OPERATOR_NAMESPACE \
          --type json \
          --patch '[{
            "op":"add",
            "path":"/spec/template/spec/volumes/-",
            "value": {
                "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "configMap": {
                    "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'"
                }
            }
        },
        {
            "op":"add",
            "path":"/spec/template/spec/containers/0/volumeMounts/-",
            "value":{
                "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'",
                "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'",
                "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'"
            }
        }
    ]'
    fi
    Copy to Clipboard

4.11. 管理身份和授权

本节论述了管理 Red Hat OpenShift Dev Spaces 的身份和授权的不同方面。

4.11.1. 为 Git 供应商配置 OAuth

注意

要启用实验性功能,在 Red Hat OpenShift Dev Spaces 中在启动时强制刷新个人访问令牌,请修改自定义资源配置,如下所示:

spec:
  components:
    cheServer:
      extraProperties:
        CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"
Copy to Clipboard

您可以在 OpenShift Dev Spaces 和 Git 供应商之间配置 OAuth,让用户能够处理远程 Git 存储库:

4.11.1.1. 为 GitHub 配置 OAuth 2.0

要让用户处理托管在 GitHub 上的远程 Git 存储库:

  1. 设置 GitHub OAuth 应用程序(OAuth 2.0)。
  2. 应用 GitHub OAuth App Secret。
4.11.1.1.1. 设置 GitHub OAuth 应用程序

使用 OAuth 2.0 设置 GitHub OAuth 应用程序。

先决条件

  • 已登陆到 GitHub。

流程

  1. 进入 https://github.com/settings/applications/new
  2. 输入以下值:

    1. 应用程序名称 : &lt;application name>
    2. Homepage URL: https://<openshift_dev_spaces_fqdn>/
    3. 授权回调 URL:https:// &lt;openshift_dev_spaces_fqdn&gt; /api/oauth/callback
  3. 点击 Register application
  4. Generate new client secret
  5. 复制并保存应用 GitHub OAuth App Secret 时要使用的 GitHub OAuth 客户端 ID
  6. 复制并保存 GitHub OAuth Client Secret,以便在应用 GitHub OAuth App Secret 时使用。
4.11.1.1.2. 应用 GitHub OAuth 应用程序 Secret

准备并应用 GitHub OAuth 应用程序 Secret。

先决条件

  • 设置 GitHub OAuth 应用程序已完成。
  • 在设置 GitHub OAuth App 时会生成以下值:

    • GitHub OAuth 客户端 ID
    • GitHub OAuth 客户端 Secret
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 准备 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: github-oauth-config
      namespace: openshift-devspaces 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: github
        che.eclipse.org/scm-server-endpoint: <github_server_url> 
    2
    
        che.eclipse.org/scm-github-disable-subdomain-isolation: 'false' 
    3
    
    type: Opaque
    stringData:
      id: <GitHub_OAuth_Client_ID> 
    4
    
      secret: <GitHub_OAuth_Client_Secret> 
    5
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    这取决于您的机构正在使用的 GitHub 产品:在 GitHub.com 或 GitHub Enterprise Cloud 上托管存储库时,忽略这一行或输入默认的 https://github.com。在 GitHub Enterprise Server 上托管存储库时,输入 GitHub Enterprise Server URL。
    3
    如果您使用带有禁用 子域隔离 选项的 GitHub Enterprise 服务器,您必须将注解设置为 true,否则您可以省略该注解,或者将其设置为 false
    4
    GitHub OAuth 客户端 ID
    5
    GitHub OAuth 客户端机密
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 在输出中验证是否已创建 Secret。

要为另一个 GitHub 提供程序配置 OAuth 2.0,您必须重复上述步骤,并使用其他名称创建第二个 GitHub OAuth Secret。

4.11.1.2. 为 GitLab 配置 OAuth 2.0

允许用户处理使用 GitLab 实例托管的远程 Git 存储库:

  1. 设置 GitLab 授权应用程序(OAuth 2.0)。
  2. 应用 GitLab 授权应用程序 Secret。
4.11.1.2.1. 设置 GitLab 授权应用程序

使用 OAuth 2.0 设置 GitLab 授权应用程序。

先决条件

  • 您已登录到 GitLab。

流程

  1. 点您的 avatar,再转到 Edit profileApplications
  2. 输入 OpenShift Dev Spaces 作为 Name
  3. 输入 https:// &lt;openshift_dev_spaces_fqdn&gt; /api/oauth/callback 作为 Redirect URI
  4. 选中 机密和 过期访问令牌 复选框。
  5. Scopes 下,选中 apiwrite_repositoryopenid 复选框。
  6. 单击 Save application
  7. 复制并保存 GitLab 应用 ID,以便在应用 GitLab-authorized 应用程序 Secret 时使用。
  8. 复制并保存 GitLab 客户端 Secret,以便在应用 GitLab-authorized 应用程序 Secret 时使用。
4.11.1.2.2. 应用 GitLab-authorized 应用程序 Secret

准备并应用 GitLab-authorized 应用程序 Secret。

先决条件

  • 设置 GitLab 授权应用程序已完成。
  • 在设置 GitLab 授权应用程序时生成的以下值是准备的:

    • GitLab 应用程序 ID
    • GitLab Client Secret
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 准备 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: gitlab-oauth-config
      namespace: openshift-devspaces 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: gitlab
        che.eclipse.org/scm-server-endpoint: <gitlab_server_url> 
    2
    
    type: Opaque
    stringData:
      id: <GitLab_Application_ID> 
    3
    
      secret: <GitLab_Client_Secret> 
    4
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    GitLab 服务器 URL.将 https://gitlab.com 用于 SAAS 版本。
    3
    GitLab 应用 ID
    4
    GitLab 客户端机密.
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 在输出中验证是否已创建 Secret。

要为另一个 Gitlab 提供程序配置 OAuth 2.0,您必须重复上面的步骤,并使用其他名称创建第二个 Gitlab OAuth Secret。

4.11.1.3. 为 Bitbucket 服务器配置 OAuth 2.0

您可以使用 OAuth 2.0 允许用户处理托管在 Bitbucket 服务器上的远程 Git 存储库:

  1. 在 Bitbucket 服务器上设置 OAuth 2.0 应用程序链接。
  2. 为 Bitbucket 服务器应用应用程序链接 Secret。
4.11.1.4. 为 Bitbucket 云配置 OAuth 2.0

您可以允许用户处理在 Bitbucket 云托管的远程 Git 存储库:

  1. 在 Bitbucket 云中设置 OAuth 使用者(OAuth 2.0)。
  2. 为 Bitbucket 云应用 OAuth 使用者 Secret。
4.11.1.4.1. 在 Bitbucket 云中设置 OAuth 使用者

在 Bitbucket 云中为 OAuth 2.0 设置 OAuth 使用者。

先决条件

  • 您已登录到 Bitbucket 云。

流程

  1. 点您的 avatar,再进入 All workspaces 页面。
  2. 选择一个工作区并点它。
  3. 前往 SettingsOAuth consumersAdd consumer
  4. 输入 OpenShift Dev Spaces 作为 Name
  5. 输入 https:// &lt;openshift_dev_spaces_fqdn&gt; /api/oauth/callback 作为 Callback URL
  6. 权限 下,选中所有 帐户 和存储库复选框,然后单击保存
  7. 扩展添加的消费者,然后复制并保存应用 Bitbucket OAuth 消费者 Secret 时使用的 Key 值:
  8. 复制并保存应用 Bitbucket OAuth 消费者 Secret 时使用的 Secret 值。
4.11.1.4.2. 为 Bitbucket 云应用 OAuth 消费者 Secret

为 Bitbucket 云准备并应用 OAuth 使用者 Secret。

先决条件

  • OAuth 使用者在 Bitbucket 云中设置。
  • 在设置 Bitbucket OAuth 使用者时会生成以下值:

    • Bitbucket OAuth 消费者密钥
    • Bitbucket OAuth 消费者 Secret
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 准备 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: bitbucket-oauth-config
      namespace: openshift-devspaces 
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: bitbucket
    type: Opaque
    stringData:
      id: <Bitbucket_Oauth_Consumer_Key> 
    2
    
      secret: <Bitbucket_Oauth_Consumer_Secret> 
    3
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    Bitbucket OAuth 使用者密钥.
    3
    Bitbucket OAuth 使用者机密
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 在输出中验证是否已创建 Secret。
4.11.1.5. 为 Bitbucket 服务器配置 OAuth 1.0

要让用户处理托管在 Bitbucket 服务器上的远程 Git 存储库:

  1. 在 Bitbucket 服务器上设置应用程序链接(OAuth 1.0)。
  2. 为 Bitbucket 服务器应用应用程序链接 Secret。
4.11.1.6. 为 Microsoft Azure DevOps 服务配置 OAuth 2.0

要让用户处理托管在 Microsoft Azure Repos 上的远程 Git 存储库:

  1. 设置 Microsoft Azure DevOps Services OAuth App (OAuth 2.0)。
  2. 应用 Microsoft Azure DevOps Services OAuth App Secret。
重要

Azure DevOps Server 不支持 OAuth 2.0,请参阅文档页面

4.11.1.6.1. 设置 Microsoft Azure DevOps Services OAuth 应用程序

使用 OAuth 2.0 设置 Microsoft Azure DevOps Services OAuth 应用程序。

先决条件

  • 您已登录到 Microsoft Azure DevOps 服务

    重要

    为您的机构启用了 通过 OAuth 的第三方应用程序访问。请参阅 更改您的机构应用程序连接和安全策略

    流程

    1. Visit https://app.vsaex.visualstudio.com/app/register/.
    2. 输入以下值:

      1. 公司名称OpenShift Dev Spaces
      2. 应用程序名称OpenShift Dev Spaces
      3. 应用程序网站:https:// &lt;openshift_dev_spaces_fqdn>/
      4. 授权回调 URL:https:// &lt;openshift_dev_spaces_fqdn&gt; /api/oauth/callback
    3. Select Authorized scopes 中,选择 Code (read and write)
    4. Create application
    5. 复制并保存应用 Microsoft Azure DevOps Services OAuth App Secret 时要使用的 App ID
    6. 单击 Show 以显示 Client Secret
    7. 复制并保存应用 Microsoft Azure DevOps Services OAuth App Secret 时要使用的 客户端 Secret。

4.11.1.6.2. 应用 Microsoft Azure DevOps Services OAuth 应用程序 Secret

准备并应用 Microsoft Azure DevOps Services Secret。

先决条件

  • 设置 Microsoft Azure DevOps Services OAuth 应用程序已完成。
  • 在设置 Microsoft Azure DevOps Services OAuth App 时会生成以下值:

    • 应用程序 ID
    • Client Secret
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 准备 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: azure-devops-oauth-config
      namespace: openshift-devspaces
    1
    
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
        app.kubernetes.io/component: oauth-scm-configuration
      annotations:
        che.eclipse.org/oauth-scm-server: azure-devops
    type: Opaque
    stringData:
      id: <Microsoft_Azure_DevOps_Services_OAuth_App_ID>
    2
    
      secret: <Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>
    3
    Copy to Clipboard
    1
    OpenShift Dev Spaces 命名空间。默认为 openshift-devspaces
    2
    Microsoft Azure DevOps Services OAuth 应用 ID
    3
    Microsoft Azure DevOps Services OAuth Client Secret
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard
  3. 在输出中验证是否已创建 Secret。
  4. 等待 OpenShift Dev Spaces 服务器组件的推出完成。

4.11.2. 为 Dev Spaces 用户配置集群角色

您可以通过在这些用户中添加集群角色来授予 OpenShift Dev Spaces 用户。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 定义用户角色名称:

    $ USER_ROLES=<name> 
    1
    Copy to Clipboard
    1
    唯一的资源名称。
  2. 查找部署 OpenShift Dev Spaces Operator 的命名空间:

    $ OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
    Copy to Clipboard
  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
    Copy to Clipboard
    1
    作为 <verbs >,列出适用于此规则中包含的所有 ResourceKinds 和 AttributeRestrictions 的所有 Verbs。您可以使用 * 代表所有操作。
    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
    Copy to Clipboard
  5. 配置 OpenShift Dev Spaces Operator,将角色委托给 che 服务帐户:

    $ kubectl patch checluster devspaces \
      --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
      --type=merge -n openshift-devspaces
    Copy to Clipboard
  6. 配置 OpenShift Dev Spaces 服务器,将角色委派给用户:

    $ kubectl patch checluster devspaces \
      --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \
      --type=merge -n openshift-devspaces
    Copy to Clipboard
  7. 等待 OpenShift Dev Spaces 服务器组件的推出完成。
  8. 询问用户退出并登录以应用新角色。

4.11.3. 配置高级授权

您可以确定允许哪些用户和组访问 OpenShift Dev Spaces。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 配置 CheCluster 自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

    spec:
      networking:
        auth:
          advancedAuthorization:
            allowUsers:
              - <allow_users> 
    1
    
            allowGroups:
              - <allow_groups> 
    2
    
            denyUsers:
              - <deny_users> 
    3
    
            denyGroups:
              - <deny_groups> 
    4
    Copy to Clipboard
    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 服务器组件的推出完成。
注意

要允许用户访问 OpenShift Dev Spaces,请将它们添加到 allowUsers 列表中。或者,选择用户所属的组,并将组添加到 allowGroups 列表中。要拒绝用户访问 OpenShift Dev Spaces,请将它们添加到 denyUsers 列表中。或者,选择用户所属的组,并将组添加到 denyGroups 列表中。如果用户处于 allowdeny 列表,则他们会拒绝对 OpenShift Dev Spaces 的访问。

如果 allowUsersallowGroups 为空,则所有用户都可以访问 OpenShift Dev Spaces,但拒绝 列表中的用户除外。如果 denyUsersdenyGroups 为空,则只允许来自 允许列表 中的用户访问 OpenShift Dev Spaces。

如果 allowdeny 列表都为空,则所有用户都可以访问 OpenShift Dev Spaces。

4.11.4. 删除用户数据以遵守 GDPR

您可以删除 OpenShift Container Platform 上的用户数据,以遵守强制实施其个人数据的 General Data Protection Regulation (GDPR)。其他 Kubernetes 基础架构的过程可能有所不同。按照您要用于 Red Hat OpenShift Dev Spaces 安装的供应商的用户管理最佳实践。

警告

按如下所示删除用户数据是不可逆的!所有删除的数据都将被删除且无法恢复!

先决条件

  • 具有 OpenShift Container Platform 集群的管理权限的活跃的 oc 会话。请参阅 OpenShift CLI 入门

流程

  1. 使用以下命令列出 OpenShift 集群中的所有用户:

    $ oc get users
    Copy to Clipboard
  2. 删除用户条目:
重要

如果用户有任何关联的资源(如项目、角色或服务帐户),则需要在删除用户前先删除这些资源。

$ oc delete user <username>
Copy to Clipboard

4.12. 配置 fuse-overlayfs

默认情况下,通用基础镜像(UDI)包含 Podman 和 Buildah,您可以在工作区中构建和推送容器镜像。但是,UDI 中的 Podman 和 Buildah 被配置为使用 vfs 存储驱动程序,该驱动程序不提供写时复制支持。要更有效地镜像管理,请使用 fuse-overlayfs 存储驱动程序,该驱动程序在无根环境中支持 copy-on-write。

要为早于 4.15 的 OpenShift 版本启用 fuse-overlayfs,管理员必须首先通过 第 4.12.1 节 “为早于 4.15 的 OpenShift 版本启用访问” 在集群中启用 /dev/fuse 访问。

OpenShift 版本 4.15 及更高版本不需要这样做,因为 /dev/fuse 设备默认可用。请参阅 发行注记

启用 /dev/fuse 访问后,可通过两种方式启用 fuse-overlayfs:

4.12.1. 为早于 4.15 的 OpenShift 版本启用访问

要使用 fuse-overlayfs,您必须首先使 /dev/fuse 可以被工作区容器访问。

注意

OpenShift 版本 4.15 及更新的版本不需要这个过程,因为 /dev/fuse 设备默认可用。请参阅 发行注记

警告

在 OpenShift 集群中创建 MachineConfig 资源是一个潜在的危险任务,因为您要对集群进行高级系统级更改。

查看 MachineConfig 文档 以了解更多详情和可能的风险。

先决条件

  • Butane 工具(但ane)安装在您使用的操作系统中。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 CLI 入门

流程

  1. 根据 OpenShift 集群的类型设置环境变量:单一节点集群,或使用单独的 control plane 和 worker 节点的多节点集群。

    • 对于单一节点集群,请设置:

      $ NODE_ROLE=master
      Copy to Clipboard
    • 对于多节点集群,请设置:

      $ NODE_ROLE=worker
      Copy to Clipboard
  2. 为 OpenShift Butane 配置版本设置环境变量。此变量是 OpenShift 集群的主版本和次要版本。例如: 4.12.04.13.04.14.0

    $ VERSION=4.12.0
    Copy to Clipboard
  3. 创建一个 MachineConfig 资源,在 NODE_ROLE 节点上创建一个名为 99-podman-fuse 的 drop-in CRI-O 配置文件。此配置文件可让您访问某些 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
    Copy to Clipboard
    1
    CRI-O 的新置入配置文件的绝对路径。
    2
    新置入配置文件的内容。
    3
    定义 podman-fuse 工作负载。
    4
    激活 podman-fuse 工作负载设置的 pod 注解。
    5
    允许 podman-fuse 工作负载处理的注释列表。
    6
    用户可以使用 io.kubernetes.cri-o.Devices 注解指定的主机上的设备列表。
  4. 应用 MachineConfig 资源后,在应用更改时,会临时禁用具有 worker 角色的每个节点调度。查看节点的状态。

    $ oc get nodes
    Copy to Clipboard

    输出示例:

    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
    Copy to Clipboard
  5. 当所有具有 worker 角色的节点都处于 Ready 状态后,/dev/fuse 可供带有以下注解的任何 pod 使用:

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

验证步骤

  1. 获取具有 worker 角色的节点名称:

    $ oc get nodes
    Copy to Clipboard
  2. 打开到 worker 节点的 oc debug 会话。

    $ oc debug node/<nodename>
    Copy to Clipboard
  3. 验证存在名为 99-podman-fuse 的新 CRI-O 配置文件。

    sh-4.4# stat /host/etc/crio/crio.conf.d/99-podman-fuse
    Copy to Clipboard
4.12.1.1. 在工作区中为 Podman 和 Buildah 使用 fuse-overlayfs

用户可遵循 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#end-user-guide:using-the-fuse-overlay-storage-driver 来更新现有工作区,为 Podman 和 Buildah 使用 fuse-overlayfs 存储驱动程序。

4.12.2. 为所有工作区启用 fuse-overlayfs

先决条件

流程

  1. 创建一个 ConfigMap,为所有用户工作区挂载 storage.conf 文件。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: fuse-overlay
      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/.config/containers/
    data:
      storage.conf: |
        [storage]
        driver = "overlay"
    
        [storage.options.overlay]
        mount_program="/usr/bin/fuse-overlayfs"
    Copy to Clipboard
    警告

    创建此 ConfigMap 将导致所有正在运行的工作区重启。

  2. 在 CheCluster 自定义资源的 spec.devEnvironments.workspacesPodAnnotations 字段中设置所需的注解。

    kind: CheCluster
    apiVersion: org.eclipse.che/v2
    spec:
      devEnvironments:
        workspacesPodAnnotations:
          io.kubernetes.cri-o.Devices: /dev/fuse
    Copy to Clipboard
    注意

    对于 4.15 之前的 OpenShift 版本,还需要 io.openshift.podman-fuse: "" 注解。

验证步骤

  1. 启动工作区并验证存储驱动程序是否 覆盖

    $ podman info | grep overlay
    Copy to Clipboard

    输出示例:

    graphDriverName: overlay
      overlay.mount_program:
        Executable: /usr/bin/fuse-overlayfs
        Package: fuse-overlayfs-1.12-1.module+el8.9.0+20326+387084d0.x86_64
          fuse-overlayfs: version 1.12
      Backing Filesystem: overlayfs
    Copy to Clipboard
    注意

    现有工作区可能会出现以下错误:

    ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "vfs" from database - delete libpod local files ("/home/user/.local/share/containers/storage") to resolve.  May prevent use of images created by other tools
    Copy to Clipboard

    在这种情况下,删除错误信息中所述的 libpod 本地文件。

第 5 章 管理 IDE 扩展

IDE 使用扩展或插件来扩展其功能,并且在 IDE 之间管理扩展的机制会有所不同。

5.1. Microsoft Visual Studio Code 的扩展 - 开源

要管理扩展,此 IDE 使用其中一个 Open VSX registry 实例:

  • 在 OpenShift Dev Spaces 的 plugin-registry pod 中运行 Open VSX registry 的嵌入式实例,以支持 air-gapped、offline 和 proxy-restricted 环境。嵌入的 Open VSX 注册表仅包含 open-vsx.org 上发布的扩展的子集。此子集 可自定义
  • 通过互联网访问的公共 open-vsx.org 注册表。
  • 部署到可从 OpenShift Dev Spaces 工作区 Pod 访问的网络上的独立 Open VSX registry 实例。

默认为 Open VSX 注册表的嵌入式实例。

5.1.1. 选择 Open VSX 注册表实例

默认为 Open VSX 注册表的嵌入式实例。

如果默认的 Open VSX registry 实例不是您需要的,您可以选择以下实例之一:

  • https://open-vsx.org 中的 Open VSX registry 实例需要访问互联网。
  • 部署到可从 OpenShift Dev Spaces 工作区 Pod 访问的网络上的独立 Open VSX registry 实例。

流程

  • 编辑 CheCluster 自定义资源中的 openVSXURL 值:

    spec:
      components:
        pluginRegistry:
          openVSXURL: "<url_of_an_open_vsx_registry_instance>" 
    1
    Copy to Clipboard
    1
    例如: openVSXURL: "https://open-vsx.org"
    重要
    • 在 air-gapped 环境中不建议使用 https://open-vsx.org,这会与互联网隔离。为了降低恶意软件入侵和未授权访问代码的风险,请使用带有策展的扩展集嵌入或自托管的 Open VSX registry。
    • 要在 plugin-registry pod 中选择嵌入的 Open VSX registry 实例,请使用 openVSXURL: ''您可以自定义包含的扩展的列表
    • 如果从机构的集群内部访问 URL,您也可以将 openVSXURL 指向独立 Open VSX registry 实例的 URL,且不会被代理阻止。

5.1.2. 在嵌入式 Open VSX registry 实例中添加或删除扩展

您可以在嵌入式 Open VSX registry 实例中添加或删除扩展。这会生成 Open VSX 注册表的自定义构建,可在您组织的工作区中使用。

提示

要在 OpenShift Dev Spaces 更新后获取最新的安全修复,请基于 latest 标签或 SHA 重建容器。

流程

  1. 获取每个所选扩展的发布程序和扩展名称:

    1. Open VSX 注册表网站 中找到扩展,并复制扩展列表页面和扩展名版本的 URL。
    2. 从复制的 URL 中提取 & lt;publisher > 和 <extension> name:

      https://open-vsx.org/extension/<publisher>/<name>
      Copy to Clipboard
      提示

      如果扩展只能从 Microsoft Visual Studio Marketplace 提供,但没有 Open VSX,您可以要求扩展发布程序,根据 这些说明open-vsx.org 上发布,可能会使用此 GitHub 操作

      如果扩展发布者不可用或不希望将扩展发布到 open-vsx.org,且没有与扩展相对应的 Open VSX,考虑使用向 Open VSX 团队报告问题

  2. 构建自定义插件 registry 镜像并更新 CheCluster 自定义资源:

    提示
    • 在构建过程中,将验证每个扩展是否与 OpenShift Dev Spaces 中使用的 Visual Studio Code 版本兼容。
    1. 使用 OpenShift Dev Spaces 实例:

      重要

      对于 IBM Power (ppc64le)和 IBM Z (s390x),自定义插件 registry 应该在对应的架构本地构建。

      1. 以管理员身份登录到 OpenShift Dev Spaces 实例。

创建新的 Red Hat Registry Service Account 并复制用户名和令牌。

  1. 使用插件 registry 存储库 启动工作区。
  2. 打开一个终端,再签出与 OpenShift Dev Spaces 版本对应的 Git 标签(例如,devspaces-3.15-rhel-8):

    git checkout devspaces-$PRODUCT_VERSION-rhel-8
    Copy to Clipboard
  3. 打开 openvsx-sync.json 文件并添加或删除扩展。
  4. 执行 1。登录到工作区中的 registry.redhat.io 任务(Terminal → Run Task…​ → devfile → 1。登录 registry.redhat.io,并登录到 registry.redhat.io
  5. 执行 2。build 和 Publish a Custom Plugin Registry 任务在工作区(Terminal → Run Task…​ → devfile → 2 中。构建和发布自定义插件 registry。
  6. 执行 3。将 Che 配置为使用 Custom Plugin Registry 任务(Terminal → Run Task…​ → devfile → 3。配置 Che 以使用自定义插件 Registry。

    1. 使用 Linux 操作系统:

      提示
      • Podman 和 NodeJS 版本 18.20.3 或更高版本应该安装到系统中。
  7. 下载或分叉并克隆 Dev Spaces 存储库
git clone https://github.com/redhat-developer/devspaces.git
Copy to Clipboard

+

  1. 进入插件 registry 子模块:
cd devspaces/dependencies/che-plugin-registry/
Copy to Clipboard

+

  1. 签出与 OpenShift Dev Spaces 版本对应的标签(如 devspaces-3.15-rhel-8):

    git checkout devspaces-$PRODUCT_VERSION-rhel-8
    Copy to Clipboard
  2. 创建新的 Red Hat Registry Service Account 并复制用户名和令牌。
  3. 登录到 registry.redhat.io

    podman login registry.redhat.io
    Copy to Clipboard
  4. 对于需要添加或删除的每个扩展,编辑 openvsx-sync.json 文件

    • 要添加扩展,请将发布程序、名称和扩展版本添加到 openvsx-sync.json 文件中。
    • 要删除扩展,请从 openvsx-sync.json 文件中删除发布者、名称和扩展版本。
    • 使用以下 JSON 语法:

          {
              "id": "<publisher>.<name>",
              "version": "<extension_version>"
          }
      Copy to Clipboard
      提示
      • 如果您有一个闭源扩展,或者只为机构内部使用创建的扩展,您可以使用自定义插件 registry 容器可访问的 URL 从 .vsix 文件添加扩展:

            {
                "id": "<publisher>.<name>",
                "download": "<url_to_download_vsix_file>",
                "version": "<extension_version>"
            }
        Copy to Clipboard
      • 在使用资源之前,请阅读 Microsoft Visual Studio Marketplace 使用条款
  5. 构建插件 registry 容器镜像,并将其发布到容器 registry 中,如 quay.io

    1. $ ./build.sh -o <username> -r quay.io -t custom
      Copy to Clipboard
    2. $ podman push quay.io/<username/plugin_registry:custom>
      Copy to Clipboard
  6. 编辑您机构的集群中的 CheCluster 自定义资源以指向镜像(例如在 quay.io上)并保存更改:

    spec:
      components:
        pluginRegistry:
          deployment:
            containers:
              - image: quay.io/<username/plugin_registry:custom>
          openVSXURL: ''
    Copy to Clipboard

验证

  1. 检查 plugin-registry pod 是否已重启并在运行。
  2. 重启工作区,并检查工作区 IDE 的 Extensions 视图中的可用扩展。

5.2. 打开 VSX 注册表 URL

为搜索和安装扩展,Microsoft Visual Studio Code - 开源编辑器使用嵌入的 Open VSX 注册表实例。您还可以将 OpenShift Dev Spaces 配置为使用另一个 Open VSX registry 实例,而不是嵌入的实例。

流程

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

    spec:
       components:
    # [...]
         pluginRegistry:
           openVSXURL: <your_open_vsx_registy>
    # [...]
    Copy to Clipboard
    警告

    由于使用 的专用 Microsoft 术语,Red Hat OpenShift Dev Spaces 不支持Visual Studio Code Marketplace

第 6 章 配置 Visual Studio Code - 开源("Code - OSS")

了解如何配置 Visual Studio Code - 开源("代码 - OSS")。

6.1. 配置单个和多根工作区

使用多根工作区功能,您可以处理同一工作区中的多个项目文件夹。当您一次性处理多个相关项目时,这很有用,如产品文档和产品代码存储库。

提示

请参阅什么是 VS Code 工作区,以更好地理解和编写工作空间文件。

注意

默认情况下,工作区设置为在多 root 模式中打开。

启动工作区后,将生成 /projects/.code-workspace 工作区文件。工作区文件将包含 devfile 中描述的所有项目。

{
	"folders": [
		{
			"name": "project-1",
			"path": "/projects/project-1"
		},
		{
			"name": "project-2",
			"path": "/projects/project-2"
		}
	]
}
Copy to Clipboard

如果工作区文件已存在,则会更新它,所有缺少的项目都会从 devfile 中获取。如果您从 devfile 中删除项目,它将保留在工作区文件中。

您可以更改默认行为,并提供自己的工作区文件,或切换到单根工作区。

流程

  • 提供您自己的工作区文件。

    • 将名为 .code-workspace 的工作区文件放在存储库的根目录中。创建工作空间后,Visual Studio Code - 开源("Code - OSS")将像其一样使用工作区文件。

      {
      	"folders": [
      		{
      			"name": "project-name",
      			"path": "."
      		}
      	]
      }
      Copy to Clipboard
      重要

      创建工作区文件时请小心。如果出现错误,则会打开一个空的 Visual Studio Code - Open Source ("Code - OSS")。

      重要

      如果您有多个项目,则工作区文件将从第一个项目获取。如果第一个项目中没有工作区文件,则会创建一个新文件,并放入 /projects 目录中。

  • 指定替代的工作区文件。

    • 在 devfile 中定义 VSCODE_DEFAULT_WORKSPACE 环境变量,并将正确的位置指定到工作区文件。

         env:
           - name: VSCODE_DEFAULT_WORKSPACE
             value: "/projects/project-name/workspace-file"
      Copy to Clipboard
  • 在单根模式下打开工作区。

    • 定义 VSCODE_DEFAULT_WORKSPACE 环境变量,并将它设为 root。

         env:
           - name: VSCODE_DEFAULT_WORKSPACE
             value: "/"
      Copy to Clipboard

6.2. 为 Microsoft Visual Studio Code 配置可信扩展

您可以使用 Microsoft Visual Studio Code 的 product.json 文件中的 trustedExtensionAuthAccess 字段指定哪些扩展是可信的,以访问身份验证令牌。

	"trustedExtensionAuthAccess": [
		"<publisher1>.<extension1>",
		"<publisher2>.<extension2>"
	]
Copy to Clipboard

当您拥有需要访问 GitHub、Microsoft 或任何需要 OAuth 的其他服务的扩展时,这特别有用。通过在此字段中添加扩展 ID,授予他们访问这些令牌的权限。

您可以在 devfile 或 ConfigMap 中定义变量。选择最适合您需求的选项。使用 ConfigMap 时,变量将在所有工作区上传播,您不需要将变量添加到您使用的每个 devfile 中。

警告

使用 trustedExtensionAuthAccess 字段请小心,因为它可能会导致安全风险。仅授予对可信扩展的访问权限。

流程

由于 Microsoft Visual Studio Code 编辑器在 che-code 镜像中捆绑在一起,因此您只能在工作区启动时更改 product.json 文件。

  1. 定义 VSCODE_TRUSTED_EXTENSIONS 环境变量。在 devfile.yaml 中定义变量,或使用变量挂载 ConfigMap。

    1. 在 devfile.yaml 中定义 VSCODE_TRUSTED_EXTENSIONS 环境变量:

         env:
           - name: VSCODE_TRUSTED_EXTENSIONS
             value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
      Copy to Clipboard
    2. 使用 VSCODE_TRUSTED_EXTENSIONS 环境变量挂载 ConfigMap:

         kind: ConfigMap
         apiVersion: v1
         metadata:
           name: trusted-extensions
           labels:
             controller.devfile.io/mount-to-devworkspace: 'true'
             controller.devfile.io/watch-configmap: 'true'
           annotations:
             controller.devfile.io/mount-as: env
         data:
           VSCODE_TRUSTED_EXTENSIONS: '<publisher1>.<extension1>,<publisher2>.<extension2>'
      Copy to Clipboard

验证

  • 变量的值将在工作区启动时解析,对应的 trustedExtensionAuthAccess 部分将添加到 product.json 中。

6.3. 配置默认扩展

默认扩展是一组预安装的扩展,通过将扩展二进制 .vsix 文件路径放在 DEFAULT_EXTENSIONS 环境变量来指定。

启动后,编辑器会检查此环境变量,如果指定了,则提取到扩展的路径,并将其安装到后台,而不会干扰用户。

配置默认扩展对于从编辑器级别安装 .vsix 扩展非常有用。

注意

如果要指定多个扩展,以分号分隔它们。

  DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
Copy to Clipboard

阅读内容,了解如何定义 DEFAULT_EXTENSIONS 环境变量,包括将 .vsix 文件添加到工作区的多个示例。

将默认 .vsix 扩展嵌入到工作区中有三种不同的方法:

  • 将扩展二进制文件放在源存储库中。
  • 使用 devfile postStart 事件从网络获取扩展二进制文件。
  • che-code 镜像中包括扩展的 .vsix 二进制文件。

将扩展二进制文件放在源存储库中

将扩展二进制文件放入 Git 存储库并在 devfile 中定义环境变量是向工作区添加默认扩展的最简单方法。如果存储库 root 中存在 extension.vsix 文件,您可以为工具容器设置 DEFAULT_EXTENSIONS

流程

  • .devfile.yaml 中指定 DEFAULT_EXTENSIONS,如下例所示:

    schemaVersion: 2.3.0
    metadata:
      generateName: example-project
    components:
      - name: tools
        container:
          image: quay.io/devfile/universal-developer-image:ubi8-latest
          env:
            - name: 'DEFAULT_EXTENSIONS'
              value: '/projects/example-project/extension.vsix'
    Copy to Clipboard

使用 devfile postStart 事件从网络获取扩展二进制文件

您可以使用 cURL 或 GNU Wget 将扩展下载到您的工作区。为此,您需要:

  • 指定 devfile 命令,将扩展下载到您的工作中
  • 添加 postStart 事件,以在工作空间启动时运行命令
  • 在 devfile 中定义 DEFAULT_EXTENSIONS 环境变量

流程

  • 将以下示例中显示的值添加到 devfile 中:

    schemaVersion: 2.3.0
    metadata:
      generateName: example-project
    components:
      - name: tools
        container:
          image: quay.io/devfile/universal-developer-image:ubi8-latest
          env:
            - name: DEFAULT_EXTENSIONS
              value: '/tmp/extension-1.vsix;/tmp/extension-2.vsix'
    
    commands:
      - id: add-default-extensions
        exec:
          # name of the tooling container
          component: tools
          # download several extensions using curl
          commandLine: |
            curl https://.../extension-1.vsix --location -o /tmp/extension-1.vsix
            curl https://.../extension-2.vsix --location -o /tmp/extension-2.vsix
    
    events:
      postStart:
        - add-default-extensions
    Copy to Clipboard
    警告

    在某些情况下,curl 可能会下载 .gzip 压缩文件。这可能会使安装扩展不可能。要修复尝试将文件保存为 .vsix.gz 文件,然后使用 gunzip 解压缩该文件。这会将 .vsix.gz 文件替换为解压缩的 .vsix 文件。

    curl https://some-extension-url --location -o /tmp/extension.vsix.gz
    gunzip /tmp/extension.vsix.gz
    Copy to Clipboard

che-code 镜像中包括扩展 .vsix 二进制文件。

使用编辑器镜像中捆绑的默认扩展,以及 ConfigMap 中定义的 DEFAULT_EXTENSIONS 环境变量,您可以在不更改 devfile 的情况下应用默认扩展。

按照以下步骤为编辑器镜像添加所需的扩展。

流程

  • 创建一个目录,并将您选择的 .vsix 扩展放在这个目录中。
  • 使用以下内容创建 Dockerfile:

    # inherit che-incubator/che-code:latest
    FROM quay.io/che-incubator/che-code:latest
    USER 0
    
    # copy all .vsix files to /default-extensions directory
    RUN mkdir --mode=775 /default-extensions
    COPY --chmod=755 *.vsix /default-extensions/
    
    # add instruction to the script to copy default extensions to the working container
    RUN echo "cp -r /default-extensions /checode/" >> /entrypoint-init-container.sh
    Copy to Clipboard
  • 构建镜像并将其推送到 registry:

    $ docker build -t yourname/che-code:next .
    $ docker push yourname/che-code:next
    Copy to Clipboard
  • 将新 ConfigMap 添加到用户的项目中,定义 DEFAULT_EXTENSIONS 环境变量,并指定扩展的绝对路径。此 ConfigMap 将环境变量设置为用户项目中的所有工作区。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: vscode-default-extensions
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
      annotations:
        controller.devfile.io/mount-as: env
    data:
      DEFAULT_EXTENSIONS: '/checode/default-extensions/extension1.vsix;/checode/default-extensions/extension2.vsix'
    Copy to Clipboard
  • 使用 yourname/che-code:next 镜像创建工作区。首先,打开仪表板并导航到左侧的 Create Workspace 选项卡。

    1. Editor Selector 部分中,展开 使用 Editor Definition 下拉菜单,并将编辑器 URI 设置为 Editor Image
    2. 点任何示例或使用 Git 存储库 URL 创建工作区。

6.4. 应用编辑器配置

您可以通过在 ConfigMap 中添加配置来配置 Visual Studio Code - 开源编辑器。这些配置应用于您打开的任何工作区。启动工作区后,编辑器会检查此 ConfigMap 并将配置存储到对应的配置文件中。

目前支持以下部分:

  • settings.json
  • extensions.json
  • product.json
  • configurations.json

settings.json 部分包含各种设置,您可以在其中自定义代码 - OSS 编辑器的不同部分。
extensions.json 部分包含启动工作区时安装的推荐扩展。
product.json 部分包含您需要添加到编辑器的 product.json 文件中的属性。如果属性已存在,则其值将更新。
configuration .json 部分包含与 Code - OSS 编辑器配置相关的属性。例如,您可以使用 extensions.install-from-vsix-enabled 属性来禁用 来自 VSIX 命令的 Install

流程

  • 在用户的项目中添加一个新的 ConfigMap,定义支持的部分,并指定您要添加的属性。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: vscode-editor-configurations
      labels:
         app.kubernetes.io/part-of: che.eclipse.org
    data:
      extensions.json: |
        {
          "recommendations": [
              "dbaeumer.vscode-eslint",
              "github.vscode-pull-request-github"
          ]
        }
      settings.json: |
        {
          "window.header": "A HEADER MESSAGE",
          "window.commandCenter": false,
          "workbench.colorCustomizations": {
            "titleBar.activeBackground": "#CCA700",
            "titleBar.activeForeground": "#ffffff"
          }
        }
      product.json: |
        {
          "extensionEnabledApiProposals": {
            "ms-python.python": [
              "contribEditorContentMenu",
              "quickPickSortByLabel",
            ]
          },
          "trustedExtensionAuthAccess": [
            "<publisher1>.<extension1>",
            "<publisher2>.<extension2>"
          ]
        }
      configurations.json: |
        {
          "extensions.install-from-vsix-enabled": false
        }
    Copy to Clipboard
  • 启动或重启工作区
注意

确保 Configmap 包含有效 JSON 格式的数据。

提示

考虑将 ConfigMap 添加到 openshift-devspaces 命名空间中。它允许在所有用户命名空间中复制 ConfigMap,同时防止在用户命名空间内进行修改。请参阅 第 4.2.3 节 “配置用户命名空间”

验证

  1. 使用以下方法之一验证 ConfigMap 中定义的设置是否已应用:

    • 使用 F1 → Preferences: Open Remote Settings 检查是否应用了定义的设置。
    • 使用 F1 → File: Open File: Open File: Open File…​ 命令,确保 /checode/remote/data/Machine/settings.json 文件中存在 ConfigMap 中的设置。
  2. 验证是否应用了 ConfigMap 中定义的扩展:

    • 进入 Extensions 视图(F1 → View: Show Extensions),检查是否已安装了扩展
    • 使用 F1 → File: Open File: Open File: Open File…​ 命令,确保 .code-workspace 文件中存在 ConfigMap 中的扩展。默认情况下,工作区文件放置在 /projects/.code-workspace 中。
  3. 验证 ConfigMap 中定义的产品属性是否已添加到 Visual Studio Code product.json 中:

    • 打开一个终端,运行命令 cat /checode/entrypoint-logs.txt | grep "Node.js dir",并复制 Visual Studio Code 路径。
    • Ctrl + O,粘贴复制的路径并打开 product.json 文件。
    • 确保 product.json 文件包含 ConfigMap 中定义的所有属性。
  4. 验证 ConfigMap 中定义的 extensions.install-from-vsix-enabled 属性是否已应用到代码 - OSS 编辑器:

    • 打开 Command appears (use F1),以检查命令列表中是否不存在 Install from VSIX 命令。
    • 使用 F1 → Open View → Extensions 打开 Extensions 面板,然后点 …​ on the view (Views and More Actions tooltip),检查操作列表中是否缺少 Install from VSIX 操作。
    • 进入 Explorer,找到带有 vsix 扩展名的文件(redhat.vscode-yaml-1.17.0.vsix),打开该文件的菜单。在菜单中应 不存在 VSIX 操作中的安装。

第 7 章 使用 Dev Spaces 服务器 API

要管理 OpenShift Dev Spaces 服务器工作负载,请使用 Swagger Web 用户界面来浏览 OpenShift Dev Spaces 服务器 API。

流程

  • 导航到 Swagger API web 用户界面: https:// <openshift_dev_spaces_fqdn> /swagger

其他资源

第 8 章 升级 Dev Spaces

本章论述了如何从 CodeReady Workspaces 3.1 升级到 OpenShift Dev Spaces 3.20。

8.1. 升级 chectl 管理工具

这部分论述了如何升级 dsc 管理工具。

8.2. 指定更新批准策略

Red Hat OpenShift Dev Spaces Operator 支持两个升级策略:

自动
Operator 会在有新更新可用时安装新的更新。
Manual(手动)
在开始安装前,需要手动批准新的更新。

您可以使用 OpenShift Web 控制台为 Red Hat OpenShift Dev Spaces Operator 指定更新批准策略。

先决条件

  • 集群管理员的 OpenShift Web 控制台会话。请参阅 访问 Web 控制台
  • 使用红帽生态系统目录安装的 OpenShift Dev Spaces 实例。

流程

  1. 在 OpenShift Web 控制台中,导航到 OperatorsInstalled Operators
  2. 在安装的 Operator 列表中点 Red Hat OpenShift Dev Spaces
  3. 进入到 Subscription 选项卡。
  4. Update 批准策略 配置为 AutomaticManual

8.3. 使用 OpenShift Web 控制台升级 Dev Spaces

您可以使用 OpenShift Web 控制台中的 Red Hat OpenShift Dev Spaces Operator 从早期的次版本手动批准升级。

先决条件

流程

验证步骤

  1. 进入到 OpenShift Dev Spaces 实例。
  2. 3.20 版本号在页面的底部可见。

8.4. 使用 CLI 管理工具升级 Dev Spaces

本节论述了如何使用 CLI 管理工具从以前的次版本进行升级。

先决条件

  • OpenShift 上的管理帐户。
  • openshift-devspaces OpenShift 项目中,使用同一 OpenShift 实例里的 CLI 管理工具安装先前次要版本的 CodeReady Workspaces 实例。
  • 用于 OpenShift Dev Spaces 版本 3.20 的 DSC。请参阅:第 2.2 节 “安装 dsc 管理工具”

流程

  1. 保存并将更改推送回所有正在运行的 CodeReady Workspaces 3.1 工作区的 Git 存储库。
  2. 关闭 CodeReady Workspaces 3.1 实例中的所有工作区。
  3. 升级 OpenShift Dev Spaces:

    $ dsc server:update -n openshift-devspaces
    Copy to Clipboard
    注意

    对于缓慢的系统或互联网连接,请添加-- k8spodwaittimeout=1800000 标志选项,将 Pod 超时周期延长为 1800000 毫秒或更长时间。

验证步骤

  1. 进入到 OpenShift Dev Spaces 实例。
  2. 3.20 版本号在页面的底部可见。

8.5. 在受限环境中升级 Dev Spaces

本节论述了如何使用受限环境中的 CLI 管理工具升级 Red Hat 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.18\
      --devworkspace_operator_version "v0.33.0" \
      --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.18" \
      --prod_operator_package_name "devspaces" \
      --prod_operator_bundle_name "devspacesoperator" \
      --prod_operator_version "v3.20.0" \
      --my_registry "<my_registry>" 
    1
    Copy to Clipboard
    1
    镜像要镜像的专用 Docker registry
  2. 在 CodeReady Workspaces 3.1 实例中的所有工作区中,保存并将更改推送回 Git 存储库。
  3. 停止 CodeReady Workspaces 3.1 实例中的所有工作区。
  4. 运行以下命令:

    $ dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
    Copy to Clipboard

验证步骤

  1. 进入到 OpenShift Dev Spaces 实例。
  2. 3.20 版本号在页面的底部可见。

8.6. 在 OpenShift 上修复 Dev Workspace Operator

在某些情况下,如 OLM 重启或集群升级,OpenShift Dev Spaces 的 Dev Spaces Operator 可能会自动安装 Dev Workspace Operator,即使在集群中已存在。在这种情况下,您可以修复 OpenShift 上的 Dev Workspace Operator,如下所示:

先决条件

  • 一个活跃的 oc 会话,作为目标 OpenShift 集群的集群管理员。请参阅 CLI 入门
  • 在 OpenShift Web 控制台的 Installed Operators 页面中,您会看到 Dev Workspace Operator 的多个条目,或看到一个处于 ReplacingPending 循环中的一个条目。

流程

  1. 删除包含故障 pod 的 devworkspace-controller 命名空间。
  2. 通过将转换策略设置为 None 并删除整个 webhook 部分,更新 DevWorkspaceDevWorkspaceTemplate 自定义资源定义(CRD):

    spec:
      ...
      conversion:
        strategy: None
    status:
    ...
    Copy to Clipboard
    提示

    您可以通过在 AdministrationCustomResourceDefinitions 中搜索 DevWorkspace ,在 OpenShift Web 控制台的 Administrator 视角中找到并编辑 DevWorkspaceTemplate CRD。

    注意

    DevWorkspaceOperatorConfigDevWorkspaceRouting CRD 默认将转换策略设置为 None

  3. 删除 Dev Workspace Operator 订阅:

    $ oc delete sub devworkspace-operator \
    -n openshift-operators 
    1
    Copy to Clipboard
    1
    openshift-operators 或安装了 Dev Workspace Operator 的 OpenShift 项目。
  4. 以 < devworkspace_operator.vX.Y.Z > 格式获取 Dev Workspace Operator CSV:

    $ oc get csv | grep devworkspace
    Copy to Clipboard
  5. 删除每个 Dev Workspace Operator CSV:

    $ oc delete csv <devworkspace_operator.vX.Y.Z> \
    -n openshift-operators 
    1
    Copy to Clipboard
    1
    openshift-operators 或安装了 Dev Workspace Operator 的 OpenShift 项目。
  6. 重新创建 Dev Workspace Operator 订阅:

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: devworkspace-operator
      namespace: openshift-operators
    spec:
      channel: fast
      name: devworkspace-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      installPlanApproval: Automatic 
    1
    
      startingCSV: devworkspace-operator.v0.33.0
    EOF
    Copy to Clipboard
    1
    AutomaticManual
    重要

    对于 installPlanApproval: Manual,在 OpenShift Web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators,为 Dev Workspace Operator 选择以下内容:Upgrade availablePreview InstallPlanApprove

  7. 在 OpenShift Web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators,并验证 Dev Workspace OperatorSucceeded 状态。

第 9 章 卸载 Dev Spaces

警告

卸载 OpenShift Dev Spaces 删除所有与 OpenShift Dev Spaces 相关的用户数据!

使用 dsc 卸载 OpenShift Dev Spaces 实例。

先决条件

流程

  • 删除 OpenShift Dev Spaces 实例:

    $ dsc server:delete
    Copy to Clipboard
提示

--delete-namespace 选项删除 OpenShift Dev Spaces 命名空间。

--delete-all 选项会删除 Dev Workspace Operator 和相关资源。

重要

OpenShift Container Platform 官方文档 中提供了用于手动删除 Dev Workspace Operator 的标准操作步骤(SOP)。

法律通告

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat