管理指南


Red Hat OpenShift Dev Spaces 3.5

Administering Red Hat OpenShift Dev Spaces 3.5

Robert Kratky

Fabrice Flore-Thébault

Red Hat Developer Group Documentation Team

摘要

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

第 1 章 准备安装

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

1.1. 支持的平台

OpenShift Dev Spaces 在以下 CPU 架构的 OpenShift 4.10-4.12 上运行:

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

其他资源

1.2. 架构

图 1.1. 使用 Dev Workspace operator 的 OpenShift Dev Spaces 架构

与 devworkspace 交互的 devspaces

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

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

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

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

1.2.1. 服务器组件

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

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

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

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

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

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

1.2.1.2. dev Workspace operator

Dev Workspace 操作器将 OpenShift 扩展为提供 Dev Workspace 支持。它引进了:

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

其他资源

1.2.1.3. gateway

OpenShift Dev Spaces 网关具有以下角色:

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

OpenShift Dev Spaces 操作器将其作为 che-gateway Deployment 进行管理。

它控制对以下的访问:

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

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

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

它需要访问:

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

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

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

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

其他资源

OpenShift Dev Spaces devfile registry 是提供示例 devfile 列表的服务,用于创建随时可用的工作区。第 1.2.1.4 节 “用户仪表板”DashboardCreate Workspace 页面中显示示例列表。每个示例都包含一个 Devfile v2。OpenShift Dev Spaces 部署在 devfile-registry 部署中启动一个 devfile registry 实例。

图 1.5. devfile registry 与其他组件交互

devspaces devfile registry 交互
1.2.1.6. dev Spaces 服务器

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

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

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

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

OpenShift Dev Spaces 服务器与其他组件交互
1.2.1.7. PostgreSQL

OpenShift Dev Spaces 服务器使用 PostgreSQL 数据库来持久保留用户配置,如工作区元数据。

OpenShift Dev Spaces 部署在 postgres 部署中启动一个专用的 PostgreSQL 实例。您可以使用外部数据库。

图 1.7. PostgreSQL 与其他组件交互

PostgreSQL 与其他组件交互
1.2.1.8. 插件 registry

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

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

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

插件 registry 与其他组件交互

1.2.2. 用户工作区

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

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

用户工作区是在容器中运行的 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 工作区及其组件。

图 1.10. OpenShift Dev Spaces 工作区组件

带有 dw 的工作区组件

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

1.3. 计算 Dev Spaces 资源要求

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

注意

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

流程

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

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

      例 1.1. 工具

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

          memoryLimit: 6G
          memoryRequest: 512M
          cpuRequest: 1000m
          cpuLimit: 4000m

      例 1.2. postgresql

      postgresql 组件没有定义任何请求和限值,因此会在专用容器的默认值上返回:

          memoryLimit: 128M
          memoryRequest: 64M
          cpuRequest: 10m
          cpuLimit: 1000m
    • 在工作区启动过程中,内部 che-gateway 容器使用以下请求和限制隐式置备:

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

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

    Expand
    目的Pod容器名称内存限制内存请求CPU 限制CPU 请求

    开发人员工具

    workspace

    工具

    6 GiB

    512 MiB

    4000 M

    1000 M

    数据库

    workspace

    postgresql

    128 MiB

    64 MiB

    1000 M

    10 M

    OpenShift Dev Spaces 网关

    workspace

    chee-gateway

    256 MiB

    64 MiB

    500 M

    50 M

    总计

    6.4 GiB

    640 MiB

    5500 M

    1060 M

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

    Expand
    表 1.1. OpenShift Dev Spaces Operator、Operperpers 和 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

    PostgreSQL 数据库

    postgres

    postgres

    1 Gi

    512 Mi

    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

第 2 章 安装 Dev Spaces

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

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

2.1. 安装 dsc 管理工具

您可以在 Microsoft Windows、Mrca 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

其他资源

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

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

先决条件

流程

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

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

    $ dsc server:deploy --platform openshift

验证步骤

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

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

    $ dsc dashboard:open

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

本节论述了如何使用 OpenShift Web 控制台安装 OpenShift Dev Spaces。请考虑使用 第 2.2 节 “使用 CLI 在 OpenShift 上安装 Dev Spaces” 替代。

先决条件

流程

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

    $ dsc server:delete
  2. 安装 Red Hat OpenShift Dev Spaces Operator。请参阅使用 Web 控制台从 OperatorHub 安装
  3. 在 OpenShift 中创建 openshift-devspaces 项目,如下所示:

    oc create namespace openshift-devspaces
  4. 在 OpenShift Web 控制台的 Administrator 视图中,进入 OperatorsInstalled OperatorsRed Hat OpenShift Dev Spaces instance SpecificationCreate CheClusterYAML view
  5. YAML 视图中,将 namespace: openshift-operators 替换为 namespace: openshift-devspaces
  6. 选择 Create。请参阅 从已安装的 Operator 创建应用程序

验证

  1. 要验证 OpenShift Dev Spaces 实例是否已正确安装,请导航到 Operator 详情页面的 Dev Spaces Cluster 选项卡。Red Hat OpenShift Dev Spaces 实例 Specification 页面显示 Red Hat OpenShift Dev Spaces 实例及其状态。
  2. devspaces CheCluster 并进入到 Details 选项卡。
  3. 查看以下字段的内容:

    • Message 字段包含错误消息。预期的内容为 None
    • Red Hat OpenShift Dev Spaces URL 字段包含 Red Hat OpenShift Dev Spaces 实例的 URL。部署成功完成时会出现 URL。
  4. 进入到 Resources 选项卡。查看分配给 OpenShift Dev Spaces 部署的资源列表及其状态。

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

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

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

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

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

先决条件

流程

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

    $ bash prepare-restricted-environment.sh \
      --ocp_ver "4.12" \
      --devworkspace_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.12" \
      --devworkspace_operator_version "v0.19.0" \
      --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.12" \
      --prod_operator_package_name "devspaces-operator" \
      --prod_operator_version "v3.5.0" \
      --my_registry "<my_registry>" \
      --my_catalog "<my_catalog>"
  2. 使用上一步中 che-operator-cr-patch.yaml 中设置的配置安装 OpenShift Dev Spaces:

    $ dsc server:deploy --platform=openshift \
      --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml
  3. 允许从 OpenShift Dev Spaces 命名空间中的传入流量到用户项目中的所有 Pod。请参阅: 第 3.7.1 节 “配置网络策略”

第 3 章 配置 Dev Spaces

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

3.1. 了解 CheCluster 自定义资源

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

CheCluster 自定义资源是一个 Kubernetes 对象。您可以通过编辑 CheCluster 自定义资源 YAML 文件来配置它。此文件包含用于配置每个组件的部分: devWorkspace,cheServer,pluginRegistry,devfileRegistry,database,dashboardimagePuller

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

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

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

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

要使用适当的配置部署 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>
  • 部署 OpenShift Dev Spaces 并应用 che-operator-cr-patch.yaml 文件中描述的更改:

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

验证

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

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

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

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

先决条件

  • OpenShift 上的 OpenShift Dev Spaces 实例。
  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI

流程

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

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

验证

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

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

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

本节论述了可用于自定义 CheCluster 自定义资源的所有字段。

例 3.2. 一个最小的 CheCluster 自定义资源示例。

apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
  name: devspaces
spec:
  devEnvironments:
    defaultNamespace:
      template: '<username>-che'
    storage:
      pvcStrategy: 'common'
  components:
    database:
      externalDb: false
    metrics:
      enable: true
Expand
表 3.1. 开发环境配置选项。
属性描述

containerBuildConfiguration

容器构建配置。

defaultComponents

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

defaultEditor

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

defaultNamespace

用户的默认命名空间。

defaultPlugins

应用到 DevWorkspace 的默认插件。

disableContainerBuildCapabilities

禁用容器构建功能。

maxNumberOfRunningWorkspacesPerUser

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

maxNumberOfWorkspacesPerUser

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

nodeSelector

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

podSchedulerName

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

secondsOfInactivityBeforeIdling

以秒为单位的工作区闲置超时。这个超时是工作区在没有活动时会被闲置的持续时间。要禁用因为不活跃而闲置工作区,请将此值设置为 -1。

secondsOfRunBeforeIdling

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

serviceAccount

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

startTimeoutSeconds

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

storage

工作区持久性存储。

容限(tolerations)

工作区 pod 的 pod 容限限制了工作区 pod 可以运行的情况。

trustedCerts

可信证书设置。

Expand
表 3.2. 开发环境 defaultNamespace 选项。
属性描述

autoProvision

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

模板

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

Expand
表 3.3. 开发环境 存储选项。
属性描述

perUserStrategyPvcConfig

使用每个用户 PVC 策略时 PVC 设置。

perWorkspaceStrategyPvcConfig

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

pvcStrategy

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

Expand
表 3.4. OpenShift Dev Spaces 组件配置。
属性描述

cheServer

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

dashboard

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

数据库

与 OpenShift Dev Spaces 安装使用的数据库相关的配置设置。

devWorkspace

DevWorkspace Operator 配置。

devfileRegistry

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

imagePuller

Kubernetes Image Puller 配置。

metrics

OpenShift Dev Spaces 服务器指标配置。

pluginRegistry

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

Expand
表 3.5. DevWorkspace operator 组件配置。
属性描述

runningLimit

弃用,而是使用 MaxNumberOfRunningWorkspacesPerUser 是每个用户运行工作区的最大数量。

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

clusterRoles

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

debug

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

部署

部署覆盖选项。

extraProperties

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

logLevel

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

proxy

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

Expand
表 3.7. 与 OpenShift Dev Spaces 安装使用的插件 registry 组件相关的配置设置。
属性Description

部署

部署覆盖选项。

disableInternalRegistry

禁用内部插件 registry。

externalPluginRegistries

外部插件 registry。

openVSXURL

打开 VSX registry URL。如果省略了嵌入式实例。

Expand
表 3.8. 与 OpenShift Dev Spaces 安装使用的 Devfile registry 组件相关的配置设置。
属性Description

部署

部署覆盖选项。

disableInternalRegistry

禁用内部 devfile registry。

externalDevfileRegistries

外部 devfile registry 服务示例可直接使用 devfile。

Expand
表 3.9. 与 OpenShift Dev Spaces 安装使用的 Database 组件相关的配置设置。
属性描述

credentialsSecretName

secret 包括 PostgreSQL userpassword,OpenShift Dev Spaces 服务器使用它来连接到数据库。secret 必须具有 app.kubernetes.io/part-of=che.eclipse.org 标签。

部署

部署覆盖选项。

externalDb

指示 Operator 部署专用数据库。默认情况下,将专用 PostgreSQL 数据库部署为 OpenShift Dev Spaces 安装的一部分。当 externalDb 设为 true 时,Operator 不会部署专用数据库,您需要提供有关您要使用的外部数据库的连接详情。

postgresDb

OpenShift Dev Spaces 服务器用于连接数据库的 PostgreSQL 数据库名称。

postgresHostName

OpenShift Dev Spaces 服务器连接的 PostgreSQL 数据库主机名。仅在使用外部数据库时覆盖这个值。参阅字段 externalDb

postgresPort

OpenShift Dev Spaces 服务器连接的 PostgreSQL 数据库端口。仅在使用外部数据库时覆盖这个值。参阅字段 externalDb

pvc

PostgreSQL 数据库的 PVC 设置。

Expand
表 3.10. 与 OpenShift Dev Spaces 安装使用的 Dashboard 组件相关的配置设置。
属性Description

部署

部署覆盖选项。

headerMessage

仪表板标头消息。

Expand
表 3.11. Kubernetes Image Puller 组件配置。
属性描述

enable

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

spec

Kubernetes Image Puller spec,用于在 CheCluster 中配置镜像拉取程序。

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

enable

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

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

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

身份验证设置。

domain

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

hostname

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

labels

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

tlsSecretName

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

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

hostname

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

机构

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

Expand
表 3.15. CheCluster 自定义资源状态 定义 OpenShift Dev Spaces 安装的状态
属性描述

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。

postgresVersion

使用的镜像的 PostgreSQL 版本。

reason

简短的 CamelCase 消息,指示 OpenShift Dev Spaces 部署处于当前阶段的原因。

workspaceBaseDomain

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

3.2. 配置项目

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

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

3.2.1. 配置项目名称

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

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

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

流程

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

    spec:
      components:
        devEnvironments:
          defaultNamespace:
            template: <workspace_namespace_template_>

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

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

    <username>-devspaces (默认)

    user1-devspaces

    <userid>-namespace

    cge1egvsb2nhba-namespace-ul1411

    <userid>-aka-<username>-namespace

    cgezegvsb2nhba-aka-user1-namespace-6m2w2b

3.2.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>
    1
    使用您选择的项目名称。

3.3. 配置服务器组件

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

  • 用户名
  • 密码
  • 身份验证令牌

以加密的形式。

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

  • 一个文件
  • 环境变量

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

先决条件

  • 正在运行的 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 > 对应于以下部署:

      • postgres
      • keycloak
      • devfile-registry
      • plugin-registry
      • devspaces

    • <OBJECT_KIND& gt; 是:

      • secret

        或者

      • configmap

例 3.4. Example:

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

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...

注解必须表示,给定的对象挂载为一个文件。

  1. 配置注解值:

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

例 3.5. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
...

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-data
  annotations:
    che.eclipse.org/mount-as: file
    che.eclipse.org/mount-path: /data
  labels:
...

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

例 3.6. 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>

或者

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>

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

重要

要在 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 > 对应于以下部署:

      • postgres
      • keycloak
      • devfile-registry
      • plugin-registry
      • devspaces

    • <OBJECT_KIND& gt; 是:

      • secret

        或者

      • configmap

例 3.7. Example:

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

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: devspaces-configmap
...

注解必须表示给定对象作为环境变量挂载。

  1. 配置注解值:

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

例 3.8. Example:

apiVersion: v1
kind: Secret
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
   ...
data:
  mykey: myvalue

或者

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-settings
  annotations:
    che.eclipse.org/env-name: FOO_ENV
    che.eclipse.org/mount-as: env
  labels:
   ...
data:
  mykey: myvalue

这会导致两个环境变量:

  • FOO_ENV
  • myvalue

被置备到 OpenShift Dev Spaces 容器中。

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

例 3.9. 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:
   ...
data:
  mykey: __<base64 encoded data content here>__
  otherkey: __<base64 encoded data content here>__

或者

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:
   ...
data:
  mykey: __<data content here>__
  otherkey: __<data content here>__

这会导致两个环境变量:

  • FOO_ENV
  • OTHER_ENV

被置备到 OpenShift Dev Spaces 容器中。

注意

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

重要

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

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

以下小节描述了 OpenShift Dev Spaces 服务器组件的高级部署和配置方法。

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

以下小节描述了 OpenShift Dev Spaces 服务器组件高级配置方法。

高级配置需要:

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

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

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

注意

OpenShift Dev Spaces Operator 的早期版本有一个名为 custom 的 ConfigMap 来满足此角色。如果 OpenShift Dev Spaces Operator 找到名为 customconfigMap,它会将其包含的数据添加到 customCheProperties 字段中,重新部署 OpenShift Dev Spaces,并删除 自定义 configMap

3.4. 全局配置工作区

本节论述了如何全局配置工作区。

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

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

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

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

流程

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

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

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

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

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

注意

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

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

spec:
  devEnvironments:
    maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
1
1
设置每个用户同时运行的最大工作区数。-1 值允许用户运行无限数量的工作区。默认值为 1

流程

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

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

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

3.4.3. 带有自签名证书的 Git

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

先决条件

流程

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

    $ oc create configmap che-git-self-signed-cert \
      --from-file=ca.crt=<path_to_certificate> \  
    1
    
      --from-literal=githost=<host:port> -n openshift-devspaces  
    2
    1
    自签名证书的路径
    2
    Git 服务器上 HTTPS 连接的主机和端口(可选)。
    注意
    • 如果没有指定 githost,则给定证书将用于所有 HTTPS 存储库。
    • 证书文件通常存储为 Base64 ASCII 文件,例如:.pem, .crt, .ca-bundle.此外,它们也可以编码为二进制数据,例如 .cer。保存证书文件的所有 Secret 都应该使用 Base64 ASCII 证书,而不是二进制数据证书。
  2. 在 ConfigMap 中添加所需的标签:

    $ oc label configmap che-git-self-signed-cert \
      app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
  3. 配置 OpenShift Dev Spaces 操作对象,以将自签名证书用于 Git 存储库。请参阅 第 3.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”

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

验证步骤

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

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

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

3.4.4. 配置工作区 nodeSelector

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

流程

OpenShift Dev Spaces 使用 CHE_WORKSPACE_POD_NODE__SELECTOR 环境变量来配置 nodeSelector。此变量可以包含一组以逗号分隔的 key=value 对来组成 nodeSelector 规则,或 NULL 禁用它。

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

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

为了避免 Pod 和 PVC 调度到大型多区的不同区中,请创建额外的 StorageClass 对象(注意 allowedTopologies 字段),这会协调 PVC 创建过程。

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

3.4.5. 打开 VSX registry URL

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

流程

  • 在 CheCluster 自定义资源 spec.components.pluginRegistry.openVSXURL 字段中设置 Open VSX registry 实例的 URL。

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

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

要改进 OpenShift Dev Spaces 工作区的开始时间性能,请使用 Image Puller,它是一个 OpenShift Dev Spaces 无关的组件,可用于为 OpenShift 集群预拉取镜像。Image Puller 是一个额外的 OpenShift 部署,它会创建一个 DaemonSet,它可以在每个节点上预拉取相关的 OpenShift Dev Spaces 工作区镜像。当 OpenShift Dev Spaces 工作区启动时,这些镜像已经可用,从而改进了工作区启动时间。

Image Puller 为配置提供以下参数。

Expand
表 3.16. Image Puller 参数
参数使用方法默认值

CACHING_INTERVAL_HOURS

daemonset 以小时为单位的健康检查间隔

"1"

CACHING_MEMORY_REQUEST

运行 puller 时每个缓存的镜像的内存请求。请参阅 第 3.5.2 节 “定义内存设置”

10Mi

CACHING_MEMORY_LIMIT

在 puller 运行时每个缓存的镜像的内存限值。请参阅 第 3.5.2 节 “定义内存设置”

20Mi

CACHING_CPU_REQUEST

拉取程序运行时每个缓存的镜像的处理器请求

.05 或 50 millicores

CACHING_CPU_LIMIT

拉取程序运行时每个缓存的镜像的处理器限制

.2 或 200 毫秒

DAEMONSET_NAME

要创建的 DaemonSet 的名称

kubernetes-image-puller

DEPLOYMENT_NAME

要创建的部署的名称

kubernetes-image-puller

NAMESPACE

包含要创建的 DaemonSet 的 OpenShift 项目

k8s-image-puller

镜像

以分号隔离的要拉取镜像的列表,格式为 <name1>=<image1>;<name2>=<image2>。请参阅 第 3.5.1 节 “定义镜像列表”

 

NODE_SELECTOR

应用到 DaemonSet 创建的 pod 的节点选择器

'{}'

关联性

应用到 DaemonSet 创建的 pod 的关联性

'{}'

IMAGE_PULL_SECRETS

镜像 pull secret 列表,格式为 pullsecret1;…​ 以添加到 DaemonSet 创建的 pod。这些 secret 需要位于镜像拉取程序的命名空间中,集群管理员必须创建它们。

""

3.5.1. 定义镜像列表

Image Puller 可以预拉取大多数镜像,包括 che-machine-exec 等涂销空间。但是,在 OpenShift 3.11 中预拉取不支持在 Dockerfile 中挂载卷的镜像,如 traefik

流程

  1. 通过导航到 https://devspaces- <openshift_deployment_name> . <domain_name&gt; /plugin-registry/v3/external_images.txt URL 来收集要拉取的相关容器镜像列表。
  2. 从预拉取(pull)的列表中确定镜像。为了加快工作空间启动时间,请考虑拉取与工作区相关的镜像,如 Universal-developer-image、che-code' 和 che-gateway

3.5.2. 定义内存设置

定义内存请求和限值参数,以确保拉取的容器和平台有足够的内存才能运行。

流程

  1. 要定义 CACHING_MEMORY_REQUESTCACHING_MEMORY_LIMIT 的最小值,请考虑运行每个容器镜像所需的内存量。
  2. 要为 CACHING_MEMORY_REQUESTCACHING_MEMORY_LIMIT 定义最大值,请考虑分配给集群中 DaemonSet Pod 的总内存:

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

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

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

先决条件

流程

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

3.5.4. 使用 CLI 在 OpenShift 上安装 Image Puller

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

先决条件

流程

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

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

    Expand
    表 3.17. app.yaml中的 Image Puller OpenShift 模板参数
    使用方法默认值

    DEPLOYMENT_NAME

    ConfigMap 中的 DEPLOYMENT_NAME 的值

    kubernetes-image-puller

    镜像

    用于 kubernetes-image-puller 部署的镜像

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

    IMAGE_TAG

    要拉取的镜像标签

    最新

    SERVICEACCOUNT_NAME

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

    kubernetes-image-puller

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

    CACHING_CPU_LIMIT

    ConfigMap 中的 CACHING_CPU_LIMIT 的值

    .2

    CACHING_CPU_REQUEST

    ConfigMap 中的 CACHING_CPU_REQUEST 的值

    .05

    CACHING_INTERVAL_HOURS

    ConfigMap 中的 CACHING_INTERVAL_HOURS 的值

    "1"

    CACHING_MEMORY_LIMIT

    ConfigMap 中的 CACHING_MEMORY_LIMIT 的值

    "20Mi"

    CACHING_MEMORY_REQUEST

    ConfigMap 中的 CACHING_MEMORY_REQUEST 的值

    "10Mi"

    DAEMONSET_NAME

    ConfigMap 中的 DAEMONSET_NAME 的值

    kubernetes-image-puller

    DEPLOYMENT_NAME

    ConfigMap 中的 DEPLOYMENT_NAME 的值

    kubernetes-image-puller

    镜像

    ConfigMap 中的 IMAGES 的值

    "undefined"

    NAMESPACE

    ConfigMap 中的 NAMESPACE

    k8s-image-puller

    NODE_SELECTOR

    ConfigMap 中的 NODE_SELECTOR 的值

    "{}"

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

    SERVICEACCOUNT_NAME

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

    kubernetes-image-puller

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

    $ oc new-project <k8s-image-puller>
  4. 处理并应用模板来安装 puller:

    $ oc process -f serviceaccount.yaml | oc apply -f -
    $ oc process -f configmap.yaml | oc apply -f -
    $ oc process -f app.yaml | oc apply -f -

验证步骤

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

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

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

3.6. 配置可观察性

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

3.6.1. Che-Theia 工作区

3.6.1.1. Telemetry 概述

Telemetry 是操作数据的明确和集合。默认情况下,Red Hat OpenShift Dev Spaces 不提供遥测,但在 Che- Theia 编辑器中,有一个抽象 API,允许使用插件机制和 chectl 命令行工具使用数据启用遥测。此方法在由红帽托管的"E Eclipse Che"中使用,"为每个 Che-Theia 工作区启用了遥测功能的服务。

本文档包括描述如何为 Red Hat OpenShift Dev Spaces 自行遥测客户端的信息,后跟 Red Hat OpenShift Dev Spaces Woopra Telemetry 插件 的概述。

3.6.1.2. 使用案例

Red Hat OpenShift Dev Spaces Telemetry API 允许跟踪:

  • 工作区使用率的持续时间
  • 用户驱动的操作,如文件编辑、提交和推送到远程存储库。
  • 工作区中使用的编程语言和 devfile。
3.6.1.3. 它如何工作

当 Dev Workspace 启动时,che-theia 容器会启动遥测插件,该插件负责将遥测事件发送到后端。如果在 Dev Workspace Pod 中设置了 $DEVWORKSPACE_TELEMETRY_BACKEND_PORT 环境变量,遥测插件会将事件发送到侦听该端口的后端。后端将收到的事件转换为特定于事件的后端表示,并将它们发送到配置的分析后端(如 Segment 或 Woopra)。

Telemetry 图
3.6.1.4. Che-Theia 遥测插件发送到后端的事件
Expand
事件描述

WORKSPACE_OPENED

Che- Theia 开始运行时发送

COMMIT_LOCALLY

使用 git.commit Theia 命令在本地进行提交时发送

PUSH_TO_REMOTE

使用 git.push Theia 命令进行 Git 推送时发送

EDITOR_USED

在编辑器中更改文件时发送

可以在后端插件中检测到 WORKSPACE_INACTIVEWORKSPACE_STOPPED 等其他事件。

3.6.1.5. 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 写密钥,则插件将从返回 Segment 写密钥的 HTTP 端点中获取它。

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

流程

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

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

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

本节介绍如何创建扩展 AbstractAnalyticsManager 并实现以下方法的 AnalyticsManager 类:

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

以下部分涵盖了:

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

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

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

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

创建接收事件的服务器

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

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

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

例 3.12. 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)
}

基于此代码创建容器镜像,并将其公开为 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

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

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

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

为了在开发时快速反馈,建议在 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
  2. 删除 src/main/java/mygroupsrc/test/java/mygroup 下的文件。
  3. 有关 backend-base 的最新版本,请参阅 GitHub 软件包
  4. pom.xml 中添加以下依赖项:

    例 3.13. 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>
  5. 创建一个具有 read:packages 权限的个人访问令牌,以便从 GitHub 软件包下载 org.eclipse.che.incubator.workspace-telemetry:backend-base 依赖项。
  6. ~/.m2/settings.xml 文件中添加 GitHub 用户名、个人访问令牌和 che-incubator 存储库详情:

    例 3.14. 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>

src/main/java/mygroup 下,在项目中创建两个文件:

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

例 3.15. 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

}
1
MicroProfile 配置注解用于注入 welcome.message 配置。

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

例 3.16. 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() {}
}
1
如果提供,请记录欢迎消息。
2
记录从前端插件接收的事件。

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

例 3.17. application.properties

quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
3.6.1.6.4. 在 Dev Workspace 中运行应用程序
  1. 在 Dev Workspace 中设置 DEVWORKSPACE_TELEMETRY_BACKEND_PORT 环境变量。此处,值设为 4167

    spec:
      template:
        attributes:
          workspaceEnv:
            - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT
              value: '4167'
  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}

    应用程序现在通过前端插件的端口 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]
  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
3.6.1.6.5. 实现 isEnabled ()

在本示例中,每当调用时,此方法始终返回 true

例 3.18. AnalyticsManager.java

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

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

3.6.1.6.6. 在Event ()的实现

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

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

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

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

    例 3.19. 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);
    }
    1
    发出请求 的端点
  2. src/main/resources/application.properties 文件中指定 TelemetryService 的基本 URL:

    例 3.20. application.properties

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

    例 3.21. 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);
    }

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

3.6.1.6.7. 实现 增加Duration ()

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

例 3.22. AnalyticsManager.java

@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
3.6.1.6.8. 实现 onActivity ()

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

例 3.23. 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);
        }
    }
3.6.1.6.9. 实现 destroy ()

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

例 3.24. AnalyticsManager.java

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

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

3.6.1.6.10. 打包 Quarkus 应用程序

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

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

例 3.25. 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"]

要构建镜像,请运行:

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

例 3.26. 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}"]

要构建镜像,请运行:

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

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

例 3.27. 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!'
1
指定从 第 3.6.1.6.10 节 “打包 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

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

例 3.28. 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
$ oc apply -f manifest.yaml

验证步骤

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

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

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

验证步骤

  1. 验证遥测插件容器是否在 Dev Workspace pod 中运行。在这里,这可以通过检查编辑器中的 Workspace 视图进行验证。

    dev Workspace 遥测插件
  2. 编辑编辑器中的文件,并在示例遥测服务器日志中观察其事件。

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

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

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

验证步骤

  1. 从 Red Hat OpenShift Dev Spaces 仪表板中启动一个新的或现有的 Dev Workspace。
  2. 按照 第 3.6.1.6.12 节 “在 Dev Workspace 中指定 telemetry 插件” 的验证步骤,验证遥测插件是否正常工作。

3.6.2. 配置服务器日志记录

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

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

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

3.6.2.1. 配置日志级别

流程

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

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

    例 3.29. 为 WorkspaceManager配置调试模式

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

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

3.6.2.3. 日志记录 HTTP 流量

流程

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

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"

3.6.3. 使用 dsc 收集日志

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

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

DS 服务器:logs

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

dsc server:logs -d /home/user/che-logs/

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

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

如果在非默认项目中安装了 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
dsc server:deploy
使用 dsc 安装时,OpenShift Dev Spaces 安装过程中会自动收集日志。与 dsc server:logs 一样,可以使用 -d 参数指定目录日志。

其他资源

3.6.4. 使用 Prometheus 和 Grafana 进行监控

您可以使用集群中运行的 Prometheus 和 Grafana 实例来收集并查看 OpenShift Dev Spaces 指标。

3.6.4.1. 安装 Prometheus 和 Grafana

您可以通过应用 template.yaml 来安装 Prometheus 和 Grafana。本例中的 template.yaml 文件提供了基本配置、Deployment 和 Services 的监控堆栈来使用 Prometheus 和 Grafana。

另外,您可以使用 Prometheus OperatorGrafana Operator

先决条件

  • oc

流程

使用 template.yaml 安装 Prometheus 和 Grafana:

  1. 为 Prometheus 和 Grafana 创建一个新项目 监控

    $ oc new-project monitoring
  2. 监控 项目中应用 template.yaml

    $ oc apply -f template.yaml -n monitoring

例 3.30. template.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  labels:
    app: grafana
spec:
  ports:
  - name: 3000-tcp
    port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app: grafana
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  labels:
    app: prometheus
spec:
  ports:
  - name: 9090-tcp
    port: 9090
    protocol: TCP
    targetPort: 9090
  selector:
    app: prometheus
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
spec:
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - image: registry.redhat.io/rhel8/grafana:7
        name: grafana
        ports:
        - containerPort: 3000
          protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: prometheus
  name: prometheus
spec:
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus
      containers:
      - image: quay.io/prometheus/prometheus:v2.36.0
        name: prometheus
        ports:
        - containerPort: 9090
          protocol: TCP
        volumeMounts:
        - mountPath: /prometheus
          name: volume-data
        - mountPath: /etc/prometheus/prometheus.yml
          name: volume-config
          subPath: prometheus.yml
      volumes:
      - emptyDir: {}
        name: volume-data
      - configMap:
          defaultMode: 420
          name: prometheus-config
        name: volume-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: ""
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
---
3.6.4.2. 监控 Dev Workspace Operator

您可以配置示例监控堆栈来处理 Dev Workspace Operator 公开的指标。

使用 Prometheus 收集、存储和查询 Dev Workspace Operator 的指标:

先决条件

  • devworkspace-controller-metrics 服务在端口 8443 上公开指标。默认情况下,这是预先配置的。
  • devworkspace-webhookserver 服务在端口 9443 上公开指标。默认情况下,这是预先配置的。
  • Prometheus 2.26.0 或更高版本正在运行。Prometheus 控制台使用对应服务在 9090 端口上运行。请参阅 Prometheus 的第一步

流程

  1. 创建一个 ClusterRoleBinding,将与 Prometheus 关联的 ServiceAccount 绑定到 devworkspace-controller-metrics-reader ClusterRole。对于 监控堆栈示例,要使用的 ServiceAccount 的名称是 prometheus

    注意

    如果没有 ClusterRoleBinding,您无法访问 Dev Workspace 指标,因为访问使用基于角色的访问控制(RBAC)进行保护。

    例 3.31. ClusterRoleBinding

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: devworkspace-controller-metrics-binding
    subjects:
      - kind: ServiceAccount
        name: prometheus
        namespace: monitoring
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: devworkspace-controller-metrics-reader
  2. 将 Prometheus 配置为从 devworkspace-controller-metrics Service 公开的端口 8443 中提取指标,并从 devworkspace-webhookserver 服务公开的端口 9443 中提取指标。

    注意

    监控堆栈示例 已创建了带有空配置的 prometheus-config ConfigMap。要提供 Prometheus 配置详情,请编辑 ConfigMap 的 data 字段。

    例 3.32. Prometheus 配置

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: prometheus-config
      namespace: monitoring
    data:
      prometheus.yml: |-
          global:
            scrape_interval: 5s 
    1
    
            evaluation_interval: 5s 
    2
    
          scrape_configs: 
    3
    
            - job_name: 'DevWorkspace'
              scheme: https
              authorization:
                type: Bearer
                credentials_file: '/var/run/secrets/kubernetes.io/serviceaccount/token'
              tls_config:
                insecure_skip_verify: true
              static_configs:
                - targets: ['devworkspace-controller-metrics.<DWO_project>:8443'] 
    4
    
            - job_name: 'DevWorkspace webhooks'
              scheme: https
              authorization:
                type: Bearer
                credentials_file: '/var/run/secrets/kubernetes.io/serviceaccount/token'
              tls_config:
                insecure_skip_verify: true
              static_configs:
                - targets: ['devworkspace-webhookserver.<DWO_project>:9443'] 
    5
    1
    提取目标的速度。
    2
    重新检查记录和警报规则的速度。
    3
    Prometheus 监控的资源。在默认配置中,两个作业是 DevWorkspaceDevWorkspace Webhook,提取 devworkspace-controller-metricsdevworkspace-webhookserver 服务公开的时间序列数据。
    4
    从端口 8443 获取指标的目标。将 <DWO_project> 替换为 devworkspace-controller-metrics Service 所在的项目。
    5
    从端口 9443 获取指标的目标。将 <DWO_project> 替换为 devworkspace-webhookserver Service 所在的项目。
  3. 缩减 Prometheus Deployment,再读取上一步中的更新 ConfigMap。

    $ oc scale --replicas=0 deployment/prometheus -n monitoring && oc scale --replicas=1 deployment/prometheus -n monitoring

验证

  1. 使用端口转发在本地访问 Prometheus Service:

    $ oc port-forward svc/prometheus 9090:9090 -n monitoring
  2. 通过查看 localhost:9090/targets 上的目标端点来验证所有目标是否已启动。
  3. 使用 Prometheus 控制台查看和查询指标:

3.6.4.2.2. 特定于 dev Workspace 的指标

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

Expand
表 3.20. 指标
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

Expand
表 3.21. 标签
Name描述

source

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

字符串

routingclass

Dev Workspace 的 spec.routingclass

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

reason

工作区启动失败的原因。

"BadRequest|InfrastructureFailure|Unknown"

Expand
表 3.22. 启动失败原因
Name描述

BadRequest

启动失败,因为 devfile 用于创建 Dev Workspace。

InfrastructureFailure

因为以下错误,启动失败: CreateContainerError,RunContainerError,FailedScheduling,FailedMount.

Unknown

未知故障原因。

使用示例仪表板查看 Grafana 上的 Dev Workspace Operator 指标:

先决条件

流程

  1. 为 Prometheus 实例添加数据源。请参阅创建 Prometheus 数据源
  2. 导入 grafana-dashboard.json 仪表板示例。

验证步骤

3.6.4.2.4. Dev Workspace Operator 的 Grafana 仪表板

基于 grafana-dashboard.json 的 Grafana 仪表板示例显示了 Dev Workspace Operator 中的以下指标。

Dev Workspace 特定指标 面板

图 3.1. Dev Workspace 特定指标 面板

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

显示工作空间启动失败的重复图表:

  • BadRequest
  • InfrastructureFailure
  • Unknown
Operator 指标 面板(第 1 部分)

图 3.2. Operator 指标 面板(第 1 部分)

包含 Operator 指标部分 1 的 Grafana 仪表板面板
flight 中的 Webhook
不同 Webhook 请求数量之间的比较。
工作队列持续时间
显示协调请求在处理前保留在工作队列中保留的热图。
Webhook 延迟(/mutate)
显示 /mutate Webhook 延迟的热图。
协调时间
显示协调持续时间的热图。
Operator 指标 面板(第 2 部分)

图 3.3. Operator 指标 面板(第 2 部分)

包含 Operator 指标第 2 部分的 Grafana 仪表板面板
Webhook 延迟(/convert)
显示 /convert Webhook 延迟的热图。
工作队列深度
工作队列中的协调请求数。
memory
Dev Workspace 控制器和 Dev Workspace Webhook 服务器的内存用量。
协调计数(DWO)
Dev Workspace 控制器的平均每秒协调计数数。
3.6.4.3. 监控 Dev Spaces 服务器

您可以配置 OpenShift Dev Spaces 以公开 OpenShift Dev Spaces 服务器的 JVM 内存和类加载。

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

流程

使用 Prometheus 为 OpenShift Dev Spaces 服务器收集、存储和查询 JVM 指标:

先决条件

流程

  1. 配置 Prometheus,以从端口 8087 中提取指标。

    注意

    监控堆栈示例 已创建了带有空配置的 prometheus-config ConfigMap。要提供 Prometheus 配置详情,请编辑 ConfigMap 的 data 字段。

    例 3.33. Prometheus 配置

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: prometheus-config
    data:
      prometheus.yml: |-
          global:
            scrape_interval:     5s             
    1
    
            evaluation_interval: 5s             
    2
    
          scrape_configs:                       
    3
    
            - job_name: 'OpenShift Dev Spaces Server'
              static_configs:
                - targets: ['che-host.<OpenShift Dev Spaces_project>:8087']  
    4
    1
    提取目标的速度。
    2
    重新检查记录和警报规则的速度。
    3
    Prometheus 监控的资源。在默认配置中,单个作业 OpenShift Dev Spaces 服务器 提取 OpenShift Dev Spaces 服务器公开的时间序列数据。
    4
    从端口 8087 获取指标的目标。将 <OpenShift Dev Spaces_project& gt; 替换为 OpenShift Dev Spaces 项目。默认 OpenShift Dev Spaces 项目为 openshift-devspaces
  2. 缩减 Prometheus Deployment,再读取上一步中的更新 ConfigMap。

    $ oc scale --replicas=0 deployment/prometheus -n monitoring && oc scale --replicas=1 deployment/prometheus -n monitoring

验证

  1. 使用端口转发在本地访问 Prometheus Service:

    $ oc port-forward svc/prometheus 9090:9090 -n monitoring
  2. 通过查看 targets 端点(位于localhost:9090/targets)来验证所有目标已在线。
  3. 使用 Prometheus 控制台查看和查询指标:

查看 Grafana 上的 OpenShift Dev Spaces 服务器指标:

先决条件

流程

  1. 为 Prometheus 实例添加数据源。请参阅创建 Prometheus 数据源
  2. 导入示例 仪表板。请参阅导入仪表板
  3. 在 Grafana 控制台中查看 OpenShift Dev Spaces JVM 指标:

    图 3.4. OpenShift Dev Spaces 服务器 JVM 仪表板

    evinceOpenShift Dev Spaces 服务器 JVM the dashboard

    图 3.5. 快速事实

    Tailoring JVM 快速事实面板

    图 3.6. JVM 内存

    一部式 JVM 内存站面板

    图 3.7. JVM Misc

    TailoringJVM Misc 面板

    图 3.8. JVM 内存池(堆)

    sVirt JVM 内存池(heap) EUM 面板

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

    Tailoring JVM Memory Pools (非堆)Eise 面板

    图 3.10. 垃圾回收

    Tailoring JVM 垃圾回收 面板

    图 3.11. 类加载

    Tailoring JVM 类加载 一 个面板

    图 3.12. 缓冲池

    Tailoring JVM 缓冲池 一 个面板

3.7. 配置网络

3.7.1. 配置网络策略

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

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

先决条件

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

流程

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

    例 3.34. 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
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    podSelector 选择项目中的所有 Pod。

3.7.2. 配置 Dev Spaces 主机名

这个步骤描述了如何将 OpenShift Dev Spaces 配置为使用自定义主机名。

先决条件

  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • 生成证书和私钥文件。
重要

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

重要

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

流程

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

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

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

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

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

3.7.3. 将不受信任的 TLS 证书导入到 Dev Spaces

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

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

OpenShift Dev Spaces 在 OpenShift Dev Spaces 项目中使用标记的配置映射作为 TLS 证书的源。配置映射可以具有任意数量的密钥,每个密钥都有随机数量的证书。

注意

当 OpenShift 集群包含通过 cluster- wide-proxy 配置 添加的集群范围可信 CA 证书时,OpenShift Dev Spaces Operator 会检测到它们,并使用 config.openshift.io/inject-trusted-cabundle="true" 标签自动将它们注入配置映射中。根据此注解,OpenShift 会自动注入配置映射的 ca-bundle.crt 键中的集群范围可信 CA 证书。

先决条件

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

流程

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

    $ cat ca-cert-for-{prod-id-short}-*.pem | tr -d '\r' > custom-ca-certificates.pem
  2. 使用所需的 TLS 证书创建 custom-ca-certificates 配置映射:

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
  3. 标记 custom-ca-certificates 配置映射:

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

验证步骤

  1. 验证配置映射是否包含您的自定义 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
  2. 验证 OpenShift Dev Spaces pod 包含挂载 ca-certs-merged 配置映射的卷:

    $ oc get pod \
        --selector=app.kubernetes.io/component=devspaces \
        --output='jsonpath={.items[0].spec.volumes[0:].configMap.name}' \
        --namespace=openshift-devspaces \
        | grep ca-certs-merged
  3. 验证 OpenShift Dev Spaces 服务器容器是否具有您的自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

    $ oc exec -t deploy/devspaces \
        --namespace=openshift-devspaces \
        -- cat /public-certs/custom-ca-certificates.pem
  4. 在 OpenShift Dev Spaces 服务器日志中验证导入的证书计数是否不是 null :

    $ oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep custom-ca-certificates.pem
  5. 列出证书的 SHA256 指纹:

    $ for certificate in ca-cert*.pem ;
      do openssl x509 -in $certificate -digest -sha256 -fingerprint -noout | cut -d= -f2;
      done
  6. 验证 OpenShift Dev Spaces 服务器 Java 信任存储是否包含具有相同指纹的证书:

    $ oc exec -t deploy/devspaces --namespace=openshift-devspaces -- \
        keytool -list -keystore /home/user/cacerts \
        | grep --after-context=1 custom-ca-certificates.pem
  7. 启动工作区,获取在其中创建它的项目名称: < workspace_namespace& gt;,并等待工作区启动。
  8. 验证 che-trusted-ca-certs 配置映射是否包含您的自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

    $ oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.custom-ca-certificates\.custom-ca-certificates\.pem}'
  9. 验证工作区 pod 是否挂载 che-trusted-ca-certs 配置映射:

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep che-trusted-ca-certs
  10. 验证 generic -developer-image 容器(或工作区 devfile 中定义的容器)是否挂载 che-trusted-ca-certs 卷:

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

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \
  12. 验证工作区容器是否具有自定义 CA 证书。这个命令以 PEM 格式返回您的自定义 CA 证书:

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

3.7.4. 配置 OpenShift 路由

如果您的机构需要,您可以配置 OpenShift Route 标签和注解。

先决条件

  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • 在 OpenShift 中运行的一个 OpenShift Dev Spaces 实例。

流程

3.7.5. 配置 OpenShift 路由

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

先决条件

流程

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

    spec:
      networking:
        labels: <labels> 
    1
    
        domain: <domain> 
    2
    
        annotations: <annotations> 
    3
    1
    目标入口控制器用来过滤服务集合的无结构键值映射。
    2
    目标入口控制器服务的 DNS 名称。
    3
    与资源存储的一个无结构键值映射。

3.8. 配置存储

警告

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

3.8.1. 使用存储类安装 Dev Spaces

要将 OpenShift Dev Spaces 配置为使用配置的基础架构存储,请使用存储类安装 OpenShift Dev Spaces。当用户想要绑定非默认置备程序提供的持久性卷时,这特别有用。为此,用户可以为 OpenShift Dev Spaces 数据保存并设置该存储的参数。这些参数可决定以下内容:

  • 特殊的主机路径
  • 存储容量
  • 卷 mod
  • 挂载选项
  • 文件系统
  • 访问模式
  • 存储类型
  • 以及许多其他

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

  • PostgreSQL 数据库。
  • OpenShift Dev Spaces 工作区。OpenShift Dev Spaces 工作区使用卷(如 /projects 卷)存储源代码。
注意

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

持久性卷声明事实:

  • OpenShift Dev Spaces 不会在基础架构中创建持久性卷。
  • OpenShift Dev Spaces 使用持久性卷声明(PVC)来挂载持久性卷。
  • OpenShift Dev Spaces 服务器创建持久性卷声明。

    用户在 OpenShift Dev Spaces 配置中定义存储类名称,以使用 OpenShift Dev Spaces PVC 中的存储类功能。使用存储类时,用户使用额外的存储参数以灵活的方式配置基础架构存储。您还可以使用类名称将静态置备的持久性卷绑定到 OpenShift Dev Spaces PVC。

流程

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

  1. 定义存储类名称:配置 CheCluster 自定义资源,并安装 OpenShift Dev Spaces。请参阅 第 3.1.1 节 “在安装过程中使用 dsc 配置 CheCluster 自定义资源”

    spec:
      components:
        database:
          pvc:
            # keep blank unless you need to use a non default storage class for PostgreSQL PVC
            storageClass: 'postgres-storage'
      devEnvironments:
        storage:
          pvc:
            # keep blank unless you need to use a non default storage class for workspace PVC(s)
            storageClass: 'workspace-storage'
  2. che-postgres-pv.yaml 文件中定义 PostgreSQL 数据库的持久性卷:

    che-postgres-pv.yaml file

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: postgres-pv-volume
      labels:
        type: local
    spec:
      storageClassName: postgres-storage
      capacity:
        storage: 1Gi
      accessModes:
        - ReadWriteOnce
      hostPath:
        path: "/data/che/postgres"

  3. che-postgres-pv.yaml 文件中为 OpenShift Dev Spaces 工作区定义持久性卷:

    che-workspace-pv.yaml file

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: workspace-pv-volume
      labels:
        type: local
    spec:
      storageClassName: workspace-storage
      capacity:
        storage: 10Gi
      accessModes:
        - ReadWriteOnce
      hostPath:
        path: "/data/che/workspace"

  4. 绑定两个持久性卷:

    $ kubectl apply -f che-workspace-pv.yaml -f che-postgres-pv.yaml
注意

您必须为卷提供有效的文件权限。您可以使用存储类配置或手动进行此操作。要手动定义权限,请定义 storageClass#mountOptions uidgid。PostgreSQL 卷需要 uid=26gid=26

3.9. 管理身份和授权

本节论述了管理 Red Hat OpenShift Dev Spaces 的身份和授权的不同方面。

3.9.1. 为 Git 供应商配置 OAuth

您可以在 OpenShift Dev Spaces 和 Git 供应商之间配置 OAuth,允许用户使用远程 Git 存储库:

3.9.1.1. 为 GitHub 配置 OAuth 2.0

允许用户使用 GitHub 上托管的远程 Git 存储库:

  1. 设置 GitHub OAuth 应用程序(OAuth 2.0)。
  2. 应用 GitHub OAuth App Secret。
3.9.1.1.1. 设置 GitHub OAuth 应用程序

使用 OAuth 2.0 设置 GitHub OAuth 应用程序。

先决条件

  • 已登陆到 GitHub。
  • base64 安装在您正在使用的操作系统中。

流程

  1. 进入 https://github.com/settings/applications/new
  2. 输入以下值:

    1. 应用程序名称OpenShift Dev Spaces
    2. 主页 URL:https://devspaces- &lt;openshift_deployment_name>. &lt;domain_name>/
    3. 授权回调 URL:https://devspaces- &lt;openshift_deployment_name>.<domain_name&gt; /api/oauth/callback
  3. 点击 Register application
  4. Generate new client secret
  5. 复制 GitHub OAuth 客户端 ID,并将其编码到 Base64 中,以便在应用 GitHub OAuth App Secret 时要使用的:

    $ echo -n '<github_oauth_client_id>' | base64
  6. 复制 GitHub OAuth 客户端 Secret,并将其编码到 Base64 中,以便在应用 GitHub OAuth App Secret 时要使用的:

    $ echo -n '<github_oauth_client_secret>' | base64
3.9.1.1.2. 应用 GitHub OAuth 应用程序 Secret

准备并应用 GitHub OAuth App Secret。

先决条件

  • 设置 GitHub OAuth 应用程序已完成。
  • 准备好设置 GitHub OAuth App 时生成的 Base64 编码值:

    • GitHub OAuth 客户端 ID
    • GitHub OAuth 客户端 Secret
  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 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
    
    type: Opaque
    data:
      id: <Base64_GitHub_OAuth_Client_ID> 
    3
    
      secret: <Base64_GitHub_OAuth_Client_Secret> 
    4
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    GitHub Enterprise Server URL。默认情况下 ,https://github.com 用于 SAAS 版本。
    3
    Base64 编码的 GitHub OAuth 客户端 ID
    4
    Base64 编码的 GitHub OAuth 客户端机密
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 验证在 Secret 是否已创建的输出中。
3.9.1.2. 为 GitLab 配置 OAuth 2.0

允许用户使用 GitLab 实例托管的远程 Git 存储库:

  1. 设置 GitLab 授权应用(OAuth 2.0)。
  2. 应用 GitLab 授权应用程序 Secret。
3.9.1.2.1. 设置 GitLab 授权应用程序

使用 OAuth 2.0 设置 GitLab 授权应用程序。

先决条件

  • 已登陆到 GitLab。
  • base64 安装在您正在使用的操作系统中。

流程

  1. 点您的 avatar,再进入 Edit profileApplications
  2. 输入 OpenShift Dev Spaces 作为 Name
  3. 输入 https://devspaces- &lt;openshift_deployment_name&gt; .<domain_name> /api/oauth/callback 作为 Redirect URI
  4. 选中 ConfidentialExpire 访问令牌 复选框。
  5. Scopes 下,选中 apiwrite_repositoryopenid 复选框。
  6. Save application
  7. 复制 GitLab 应用程序 ID,并将其编码到 Base64 中,以便在应用 GitLab-authorized 应用程序 Secret 时要使用的:

    $ echo -n '<gitlab_application_id>' | base64
  8. 复制 GitLab 客户端 Secret,并将其编码到 Base64 中,以便在应用 GitLab-authorized 应用程序 Secret 时要使用的:

    $ echo -n '<gitlab_client_secret>' | base64
3.9.1.2.2. 应用 GitLab-authorized 应用程序 Secret

准备并应用 GitLab-authorized 应用程序 Secret。

先决条件

  • 设置 GitLab 授权应用程序已完成。
  • 准备好在设置 GitLab 授权应用程序时生成的 Base64 编码值:

    • GitLab 应用程序 ID
    • GitLab Client Secret
  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 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
    data:
      id: <Base64_GitLab_Application_ID> 
    3
    
      secret: <Base64_GitLab_Client_Secret> 
    4
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    GitLab 服务器 URL。使用 https://gitlab.com 作为 SAAS 版本。
    3
    Base64 编码的 GitLab 应用程序 ID
    4
    Base64 编码的 GitLab 客户端 Secret
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 验证在 Secret 是否已创建的输出中。
3.9.1.3. 为 Bitbucket 服务器配置 OAuth 1.0

允许用户使用在 Bitbucket 服务器上托管的远程 Git 存储库:

  1. 在 Bitbucket 服务器上设置应用链接(OAuth 1.0)。
  2. 为 Bitbucket 服务器应用应用链接 Secret。
3.9.1.4. 为 Bitbucket 云配置 OAuth 2.0

您可以允许用户使用托管在 Bitbucket 云中的远程 Git 存储库:

  1. 在 Bitbucket 云中设置 OAuth 使用者(OAuth 2.0)。
  2. 为 Bitbucket 云应用 OAuth 使用者 Secret。
3.9.1.4.1. 在 Bitbucket 云中设置 OAuth 使用者

在 Bitbucket 云中为 OAuth 2.0 设置 OAuth 使用者。

先决条件

  • 您已登录到 Bitbucket 云。
  • base64 安装在您正在使用的操作系统中。

流程

  1. 点您的 avatar,再进入 All workspaces 页面。
  2. 选择一个工作区并点它。
  3. 前往 SettingsOAuth consumersAdd consumer
  4. 输入 OpenShift Dev Spaces 作为 Name
  5. 输入 https://devspaces- &lt;openshift_deployment_name&gt; .<domain_name> /api/oauth/callback 作为 回调 URL
  6. Permissions 下,选中所有 帐户 和存储库 复选框,然后单击 Save
  7. 展开添加的消费者,然后复制 Key 值并将其编码为 Base64,以便在应用 Bitbucket OAuth 消费者 Secret 时使用:

    $ echo -n '<bitbucket_oauth_consumer_key>' | base64
  8. 复制 Secret 值并将其以 Base64 进行编码,以便在应用 Bitbucket OAuth 消费者 Secret 时使用:

    $ echo -n '<bitbucket_oauth_consumer_secret>' | base64
3.9.1.4.2. 为 Bitbucket 云应用 OAuth 使用者 Secret

为 Bitbucket 云准备并应用 OAuth 使用者机密。

先决条件

  • OAuth 使用者在 Bitbucket 云中设置。
  • 准备好在设置 Bitbucket OAuth 使用者时生成的 Base64 编码值:

    • Bitbucket OAuth 使用者密钥
    • Bitbucket OAuth 使用者 Secret
  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 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
    data:
      id: <Base64_Bitbucket_Oauth_Consumer_Key> 
    2
    
      secret: <Base64_Bitbucket_Oauth_Consumer_Secret> 
    3
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    Base64 编码的 Bitbucket OAuth 使用者密钥
    3
    Base64 编码的 Bitbucket OAuth 使用者机密
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 验证在 Secret 是否已创建的输出中。
3.9.1.5. 为 Microsoft Azure DevOps 服务配置 OAuth 2.0

用户可以使用托管在 Microsoft Azure Repo 上的远程 Git 存储库:

  1. 设置 Microsoft Azure DevOps 服务 OAuth 应用程序(OAuth 2.0)。
  2. 应用 Microsoft Azure DevOps Services OAuth App Secret。

使用 OAuth 2.0 设置 Microsoft Azure DevOps 服务 OAuth 应用程序。

先决条件

流程

  1. Visit https://app.vsaex.visualstudio.com/app/register/.
  2. 输入以下值:

    1. 公司名称OpenShift Dev Spaces
    2. 应用程序名称OpenShift Dev Spaces
    3. 应用程序网站:https://devspaces- &lt;openshift_deployment_name>. &lt;domain_name>/
    4. 授权回调 URL:https://devspaces- &lt;openshift_deployment_name>.<domain_name&gt; /api/oauth/callback
  3. Select Authorized ranges 中,选择 Code (读取和写入)。
  4. Create application
  5. 复制 App ID,并将其编码到 Base64 中,以便在应用 Microsoft Azure DevOps Services OAuth App Secret 时使用:

    $ echo -n '<microsoft_azure_devops_services_oauth_app_id>' | base64
  6. 单击 Show 以显示 客户端 Secret
  7. 复制 客户端 Secret,并将其编码到 Base64 中,以便在应用 Microsoft Azure DevOps Services OAuth App Secret 时使用:

    $ echo -n '<microsoft_azure_devops_services_oauth_client_secret>' | base64

准备并应用 Microsoft Azure DevOps Services Secret。

先决条件

  • 设置 Microsoft Azure DevOps 服务 OAuth 应用程序已完成。
  • 准备好在设置 Microsoft Azure DevOps Services OAuth App 时生成以 Base64 编码的值:

    • 应用程序 ID
    • Client Secret
  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 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
    data:
      id: <Base64_Microsoft_Azure_DevOps_Services_OAuth_App_ID>
    2
    
      secret: <Base64_Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>
    3
    1
    OpenShift Dev Spaces 命名空间。默认值为 openshift-devspaces
    2
    Base64 编码的 Microsoft Azure DevOps Services OAuth App ID
    3
    Base64 编码的 Microsoft Azure DevOps Services OAuth Client Secret
  2. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
  3. 验证在 Secret 是否已创建的输出中。

3.9.2. 配置管理用户

要执行需要在 OpenShift Dev Spaces 服务器上需要管理特权的操作,如删除用户数据,激活具有管理特权的用户。默认安装为 admin 用户启用管理特权,无论 OpenShift 中存在它。

流程

3.9.3. 删除用户数据以遵守 GDPR

您可以删除用户数据符合 General Data Protection Regulation (GDPR),以强制个人的个人数据被清除。

警告

按如下所示删除用户数据是不可逆的!所有删除的数据都会被删除并无法恢复!

先决条件

流程

  1. 如果 OpenShift Dev Spaces 实例已升级,因为以前的版本中用户数据存储在 PostgreSQL 数据库中,则首先使用已弃用的端点:

    1. 进入 https://devspaces- &lt;openshift_deployment_name>.<domain_name> /swagger/rhcs/user/find_1
    2. 选择 Try it outname:<username > → Execute 来获取用户 ID
    3. Response body 中查找 id 值。

      如果响应是 404,这表示用户不在数据库中,请跳至第 2 步。

    4. 进入 https://devspaces- &lt;openshift_deployment_name>.<domain_name&gt; /swagger/rhcs/user/remove
    5. 选择 Try it outid : & lt;id> → Execute 以删除由 OpenShift Dev Spaces 服务器管理的用户数据。
    6. 验证您是否得到 204 响应。
  2. 删除用户项目,以删除绑定到用户的所有 OpenShift 资源,如工作区、Secret 和 ConfigMap。

    $ oc delete namespace <username>-devspaces

第 4 章 管理 IDE 扩展

IDE 使用扩展或插件来扩展其功能,管理扩展的机制因 IDE 而异。

4.1. Microsoft Visual Studio Code 的扩展 - 开源

要管理扩展,这个 IDE 使用以下 Open VSX registry 实例之一:

  • 公共、主 open-vsx.org registry。
  • 在 OpenShift Dev Spaces 的 plugin-registry pod 中运行 Open VSX registry 的嵌入式实例,以支持 air-gapped、off 和 proxy-restricted 环境。嵌入式 Open VSX registry 仅包含 open-vsx.org 上发布的扩展子集。此子集可以自定义。
  • 独立 Open VSX registry 实例,部署到 OpenShift Dev Spaces 工作区 pod 访问的网络上。

4.1.1. 选择 Open VSX registry 实例

如果从您的机构的集群解析,则 https://open-vsx.org 的 Open VSX registry 是默认设置。如果没有,则 OpenShift Dev Spaces plugin-registry pod 中的嵌入式 Open VSX registry 是默认设置。

如果默认的 Open VSX registry 实例不需要,您可以选择另一个 Open VSX registry 实例,如下所示:

流程

  • 编辑 CheCluster 自定义资源中的 openVSXURL 值:

    spec:
      components:
        pluginRegistry:
          openVSXURL: "<url_of_an_open_vsx_registry_instance>"
    提示
    • 默认的 openVSXURL 值为 https://open-vsx.org
    • 要在 plugin-registry pod 中选择嵌入的 Open VSX registry 实例,请使用 openVSXURL: ''。有关如何自定义包含的扩展列表,请参见下一小节。
    • 如果可从您的机构集群中的 URL 访问其 URL,则您还可以将 openVSXURL 指向独立 Open VSX registry 实例的 URL,而不是被代理阻止。

您可以在 OpenShift Dev Spaces 部署的嵌入式 Open VSX registry 实例中添加或删除扩展,以支持离线和代理环境。

这将创建 Open VSX registry 的自定义构建,可在您的组织的工作区中使用。

提示

要在 OpenShift Dev Spaces 更新后获取最新的安全修复,请根据最新的标签或 SHA 重建容器。

流程

  1. 获取每个所选扩展名的发布者和扩展名称:

    1. Open VSX registry 网站 中找到扩展,并复制扩展列表页面的 URL。
    2. 从复制的 URL 中提取 <publisher > 和名称 <extension>

      https://www.open-vsx.org/extension/<publisher>/<extension>
      提示

      如果扩展仅可用于 Microsoft Visual Studio Marketplace,但不适用于 Open VSX,您可以要求扩展发布发布者根据以下 说明在 open-vsx.org 上发布它,并可能使用此 GitHub 操作

      如果扩展发布者不可用或不希望将扩展发布到 open-vsx.org,且没有与扩展相对应的 Open VSX,考虑使用向 Open VSX 团队报告问题

  2. 下载或分叉并克隆 插件 registry 存储库
  3. 对于需要添加或删除的每个扩展,请编辑 openvsx-sync.json 文件

    • 要添加扩展,请在 openvsx-sync.json 文件中添加发布程序和扩展名称。
    • 要删除扩展,请从 openvsx-sync.json 文件中删除发布程序和扩展名称。
    • 使用以下 JSON 语法:

          {
              "id": "<publisher>.<extension>"
          }
      提示
      • open-vsx.org 上的最新扩展版本是默认值。或者,您可以在新 行中添加 "<extension_version> version": " " 以指定版本。
      • 如果您有一个 down-source 扩展或只为机构中内部使用开发的扩展,您可以使用自定义插件 registry 容器可访问的 URL 直接从 .vsix 文件添加扩展:

            {
                "id": "<publisher>.<extension>",
                "download": "<url_to_download_vsix_file>",
                "version": "<extension_version>"
            }
      • 在使用其资源前,请阅读 Microsoft Visual Studio Marketplace使用条款
  4. 构建插件 registry 容器镜像并将其发布到类似 quay.io 的容器 registry:

    1. $ ./build.sh -o <username> -r quay.io -t custom
    2. $ podman push quay.io/<username/plugin_registry:custom>
  5. 编辑您机构集群中的 CheCluster 自定义资源以指向镜像(例如在 quay.io上),并保存更改:

    spec:
      components:
        pluginRegistry:
          deployment:
            containers:
              - image: quay.io/<username/plugin_registry:custom>
          openVSXURL: ''

验证

  1. 检查 plugin-registry pod 是否已重启并正在运行。
  2. 重启工作区,并在工作区 IDE 的 Extensions 视图中检查可用的扩展。

第 5 章 使用 Dev Spaces 服务器 API

要管理 OpenShift Dev Spaces 服务器工作负载,请使用 Swagger Web 用户界面浏览 OpenShift Dev Spaces 服务器 API。

流程

  • 进入 Swagger API web 用户界面: https://devspaces- <openshift_deployment_name> . &lt;domain_name>/swagger

其他资源

第 6 章 升级 Dev Spaces

本章论述了如何从 CodeReady Workspaces 3.1 升级到 OpenShift Dev Spaces 3.5。

6.1. 升级 chectl 管理工具

这部分论述了如何升级 dsc 管理工具。

6.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. 更新批准策略配置为 AutomaticManual

6.3. 使用 OpenShift Web 控制台升级 Dev Spaces

您可以使用 OpenShift Web 控制台中的红帽生态系统目录中的 Red Hat OpenShift Dev Spaces Operator 从较早的次版本手动批准升级。

先决条件

流程

验证步骤

  1. 进入 OpenShift Dev Spaces 实例。
  2. 3.5 版本号在页面的底部可见。

6.4. 使用 CLI 管理工具升级 Dev Spaces

本节描述了如何使用 CLI 管理工具从以前的次版本升级。

先决条件

  • OpenShift 上的管理帐户。
  • 一个以前的 CodeReady Workspaces 次要版本的实例,使用 openshift-devspaces OpenShift 项目的同一 OpenShift 实例上的 CLI 管理工具安装。
  • 用于 OpenShift Dev Spaces 版本 3.5 的DS。请参阅: 第 2.1 节 “安装 dsc 管理工具”

流程

  1. 保存更改并将其推送到所有正在运行的 CodeReady Workspaces 3.1 工作区的 Git 存储库。
  2. 关闭 CodeReady Workspaces 3.1 实例中的所有工作区。
  3. 升级 OpenShift Dev Spaces:

    $ dsc server:update -n openshift-devspaces
    注意

    对于较慢的系统或互联网连接,请添加 --k8spodwaittimeout=1800000 标志选项,将 Pod 超时周期扩展到 1800000 ms 或更长时间。

验证步骤

  1. 进入 OpenShift Dev Spaces 实例。
  2. 3.5 版本号在页面的底部可见。

6.5. 在受限环境中升级 Dev Spaces

本节论述了如何在受限环境中使用 CLI 管理工具升级 Red Hat OpenShift Dev Spaces 并执行次版本更新。

先决条件

流程

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

    $ bash prepare-restricted-environment.sh \
      --ocp_ver "4.12" \
      --devworkspace_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.12" \
      --devworkspace_operator_version "v0.19.0" \
      --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.12" \
      --prod_operator_package_name "devspaces-operator" \
      --prod_operator_version "v3.5.0" \
      --my_registry "<my_registry>" \
      --my_catalog "<my_catalog>"
  2. 在 CodeReady Workspaces 3.1 实例中的所有运行工作区中,保存更改并推送回 Git 存储库。
  3. 停止 CodeReady Workspaces 3.1 实例中的所有工作区。
  4. 运行以下命令:

    $ dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000

验证步骤

  1. 进入 OpenShift Dev Spaces 实例。
  2. 3.5 版本号在页面的底部可见。

6.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:
    ...
    提示

    您可以通过在 AdministrationCustomResourceDefinitions 中搜索 DevWorkspace,在 OpenShift Web 控制台的 Administrator 视角中查找并编辑 DevWorkspaceDevWorkspaceTemplate CRD。

    注意

    DevWorkspaceOperatorConfigDevWorkspaceRouting CRD 默认将转换策略设置为 None

  3. 删除 Dev Workspace Operator 订阅:

    $ oc delete sub devworkspace-operator \
    -n openshift-operators 
    1
    1
    安装了 Dev Workspace Operator 的 OpenShift -operators 或 OpenShift 项目。
  4. 获取 < devworkspace_operator.vX.Y.Z > 格式的 Dev Workspace Operator CSV:

    $ oc get csv | grep devworkspace
  5. 删除每个 Dev Workspace Operator CSV:

    $ oc delete csv <devworkspace_operator.vX.Y.Z> \
    -n openshift-operators 
    1
    1
    安装了 Dev Workspace Operator 的 OpenShift -operators 或 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.19.0
    EOF
    1
    AutomaticManual
    重要

    对于 installPlanApproval: Manual,在 OpenShift Web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators,为 Dev Workspace Operator 选择以下内容:Upgrade availablePreview InstallPlanApprove

  7. 在 OpenShift Web 控制台的 Administrator 视角中,进入 OperatorsInstalled Operators,并验证 Dev Workspace OperatorSucceeded 状态。

第 7 章 卸载 Dev Spaces

警告

卸载 OpenShift Dev Spaces 会删除所有与 OpenShift Dev Spaces 相关的用户数据!

使用 oc 卸载 OpenShift Dev Spaces 实例。

先决条件

流程

  • 删除 OpenShift Dev Spaces 实例:

    $ dsc server:delete
提示

--delete-namespace 选项删除 OpenShift Dev Spaces 命名空间。

--delete-all 选项删除 Dev Workspace Operator 和相关资源。

法律通告

Copyright © 2023 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 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部