管理指南
管理 Red Hat OpenShift Dev Spaces 3.20
摘要
第 1 章 安全最佳实践
获取 Red Hat OpenShift Dev Spaces 的关键最佳实践概述,可帮助您促进更具弹性的开发环境。
Red Hat OpenShift Dev Spaces 在 OpenShift 上运行,它为其上运行的产品提供平台以及产品的基础。OpenShift 文档是安全强化的入口点。
OpenShift 中的项目隔离
在 OpenShift 中,项目隔离与 Kubernetes 中的命名空间隔离类似,但通过项目的概念来实现。OpenShift 中的项目是顶级的组织单元,可在集群中的不同应用程序、团队或工作负载之间提供隔离和协作。
默认情况下,OpenShift Dev Spaces 为每个用户置备唯一的 & lt;username>-devspaces
项目。另外,集群管理员可以禁用 OpenShift 级别的项目自助置备,并在 CheCluster 自定义资源中关闭自动命名空间置备:
devEnvironments: defaultNamespace: autoProvision: false
devEnvironments:
defaultNamespace:
autoProvision: false
使用这个设置,您可以获得一个策展对 OpenShift Dev Spaces 的访问,集群管理员对每个用户控制置备,并可以明确配置各种设置,包括资源限值和配额。在 第 4.2.2 节 “提前置备项目” 中了解更多有关项目置备的信息。
基于角色的访问控制(RBAC)
默认情况下,OpenShift Dev Spaces operator 会创建以下 ClusterRole:
-
<namespace>-cheworkspaces-clusterrole
-
<namespace>-cheworkspaces-devworkspace-clusterrole
& lt;namespace
> 前缀与 Red Hat OpenShift Dev Spaces CheCluster CR 所在的项目名称对应。
当用户第一次访问 Red Hat OpenShift Dev Spaces 时,对应的 RoleBinding 会在 < username>-devspaces
项目中创建。
下面列出了可授予用户在命名空间中要使用的所有资源和操作。
Resources | Actions |
---|---|
pods | "get", "list", "watch", "create", "delete", "update", "patch" |
pods/exec | "get", "create" |
pods/log | "get", "list", "watch" |
pods/portforward | "get", "list", "create" |
configmaps | "get", "list", "create", "update", "patch", "delete" |
events | "list", "watch" |
secrets | "get", "list", "create", "update", "patch", "delete" |
services | "get", "list", "create", "delete", "update", "patch" |
Routes | "get", "list", "create", "delete" |
persistentvolumeclaims | "get", "list", "watch", "create", "delete", "update", "patch" |
应用程序/部署 | "get", "list", "watch", "create", "patch", "delete" |
apps/replicasets | "get", "list", "patch", "delete" |
命名空间 | "get", "list" |
projects | "get" |
devworkspace | "get", "create", "delete", "list", "update", "patch", "watch" |
devworkspacetemplates | "get", "create", "delete", "list", "update", "patch", "watch" |
每个用户仅被授予其命名空间的权限,无法访问其他用户的资源。集群管理员可以为用户添加额外权限。它们不应该删除默认授予的权限。
如需为 Red Hat OpenShift Dev Spaces 用户配置集群角色,请参阅产品文档。https://eclipse.dev/che/docs/stable/administration-guide/configuring-cluster-roles-for-users/
如需基于角色的访问控制的更多详细信息,请参阅 OpenShift 文档。
开发环境隔离
开发环境的隔离使用 OpenShift 项目实施。每个开发人员都有一个项目,在其中创建和管理以下对象:
- 云环境(CDE) Pod,包括 IDE 服务器。
- 包含开发人员凭据的 secret,如 Git 令牌、SSH 密钥和 Kubernetes 令牌。
- 带有开发人员特定配置的 ConfigMap,如 Git 名称和电子邮件。
- 持久保留数据的卷,如源代码,即使 CDE Pod 停止了。
对命名空间中的资源的访问权限必须限制为拥有它的开发人员。授予另一个开发人员读取访问权限等同于共享开发人员凭据,应该避免。
增强的授权
当前趋势是将基础架构分成几个 "fit for purpose" 集群,而不是具有 gigantic monolith OpenShift 集群。但是,管理员可能仍然希望提供粒度访问权限,并将某些功能的可用性限制为特定用户。
"fit for purpose" OpenShift 集群指的是专门为满足特定用例或工作负载的要求和目标的集群。它基于它将管理的工作负载特性进行定制,以优化性能、资源利用率和其他因素。对于 Red Hat OpenShift Dev Spaces,建议置备这种类型的集群。
因此,可用于为不同组和用户设置粒度访问权限的可选属性包括在 CheCluster 自定义资源中:
-
AllowUsers
-
allowGroups
-
DenyUsers
-
denyGroups
以下是访问配置示例:
networking: auth: advancedAuthorization: allowUsers: - user-a - user-b denyUsers: - user-c allowGroups: - openshift-group-a - openshift-group-b denyGroups: - openshift-group-c
networking:
auth:
advancedAuthorization:
allowUsers:
- user-a
- user-b
denyUsers:
- user-c
allowGroups:
- openshift-group-a
- openshift-group-b
denyGroups:
- openshift-group-c
denyUsers
和 denyGroup
类别中的用户将无法使用 Red Hat OpenShift Dev Spaces,并在尝试访问用户仪表板时看到警告。
身份验证
只有经过身份验证的 OpenShift 用户可以访问 Red Hat OpenShift Dev Spaces。网关 Pod 使用基于角色的访问控制(RBAC)子系统来确定开发人员是否有权访问云开发环境(CDE)。
CDE Gateway 容器检查开发人员的 Kubernetes 角色。如果其角色允许访问 CDE Pod,则允许与开发环境的连接。默认情况下,只有命名空间的所有者有权访问 CDE Pod。
对命名空间中的资源的访问权限必须限制为拥有它的开发人员。授予另一个开发人员 读取访问权限
等同于共享开发人员凭据,应该避免。
安全上下文和安全上下文约束
Red Hat OpenShift Dev Spaces 在 CDE Pod 容器安全上下文的规格中添加 SETGID
和 SETUID
功能:
"spec": { "containers": [ "securityContext": { "allowPrivilegeEscalation": true, "capabilities": { "add": ["SETGID", "SETUID"], "drop": ["ALL","KILL","MKNOD"] }, "readOnlyRootFilesystem": false, "runAsNonRoot": true, "runAsUser": 1001110000 } ] }
"spec": {
"containers": [
"securityContext": {
"allowPrivilegeEscalation": true,
"capabilities": {
"add": ["SETGID", "SETUID"],
"drop": ["ALL","KILL","MKNOD"]
},
"readOnlyRootFilesystem": false,
"runAsNonRoot": true,
"runAsUser": 1001110000
}
]
}
这为用户提供了从 CDE 中构建容器镜像的功能。
默认情况下,Red Hat OpenShift Dev Spaces 将特定的 SecurityContextConstraint
(SCC)分配给允许他们启动具有此类功能的 Pod 的用户。与默认 restricted
SCC 相比,此 SCC 授予用户更多权限,但与 anyuid
SCC 相比。此默认 SCC 在 OpenShift Dev Spaces 命名空间中预先创建,并命名为 container-build
。
在 CheCluster 自定义资源中设置以下属性可防止向用户分配额外的功能和 SCC:
spec: devEnvironments: disableContainerBuildCapabilities: true
spec:
devEnvironments:
disableContainerBuildCapabilities: true
资源配额和限值范围
资源配额和限值范围是 Kubernetes 功能,可用于帮助防止集群中的错误执行者和资源滥用。具体来说,它们允许您为 pod 和容器设置资源消耗限制。通过组合资源配额和限值范围,您可以强制执行特定于项目的策略,以防止不良的执行者消耗过量资源。
这些机制有助于提高 OpenShift 集群中的资源管理、稳定性和公平性。有关 资源配额和限值范围的更多详细信息 , 请参阅 OpenShift 文档。
断开连接的环境
air-gapped OpenShift 断开连接的集群指的是从互联网或任何外部网络隔离的 OpenShift 集群。这种隔离通常是出于安全原因来防止敏感或关键系统免受潜在的网络威胁。在 air-gapped 环境中,集群无法访问外部软件仓库或 registry 来下载容器镜像、更新或依赖项。
Red Hat OpenShift Dev Spaces 支持,并可在受限环境中安装。官方文档 中提供了安装说明。
管理扩展
默认情况下,Red Hat OpenShift Dev Spaces 包括嵌入式 Open VSX registry,其中包含 Microsoft Visual Studio Code - 开源编辑器的一组有限的扩展。另外,集群管理员也可以在自定义资源中指定不同的插件 registry,例如 https://open-vsx.org 包含数千个扩展。它们也可以构建自定义 Open VSX 注册表。有关管理 IDE 扩展的更多详细信息,请参阅 官方文档。
安装额外扩展会增加潜在的风险。要最小化这些风险,请确保只安装来自可靠源的扩展并定期更新它们。
Secrets
将敏感数据保存为用户命名空间机密中的 Kubernetes secret (如个人访问令牌(PAT)和 SSH 密钥)。
Git 存储库
在熟悉和您信任的 Git 存储库中操作至关重要。在将新依赖项合并到存储库中之前,请验证它们是否被维护,并定期发行更新以解决其代码中任何识别的安全漏洞。
第 2 章 准备安装
要准备 OpenShift Dev Spaces 安装,了解 OpenShift Dev Spaces 生态系统和部署限制:
2.1. 支持的平台
OpenShift Dev Spaces 在以下 CPU 架构的 OpenShift 4.14-4.18 上运行:
-
AMD64 和 Intel 64 (
x
86_64) -
IBM Z (
s390x
)
以下 CPU 架构需要 Openshift 4.13-4.18 来运行 OpenShift Dev Spaces:
-
IBM Power (
ppc64le
)
其他资源
2.2. 安装 dsc 管理工具
您可以在 Microsoft Windows、Apple MacOS 和 Linux 上安装 dsc
、Red Hat OpenShift Dev Spaces 命令行管理工具。使用 dsc
,您可以对 OpenShift Dev Spaces 服务器执行操作,如启动、停止、更新和删除服务器。
先决条件
Linux 或 macOS。
注意有关在 Windows 上安装
dsc
,请查看以下页面:
流程
-
从 https://developers.redhat.com/products/openshift-dev-spaces/download 下载存档到目录,如
$HOME
。 -
在存档上运行
tar xvzf
以提取/dsc
目录。 -
将提取的
/dsc/bin
子目录添加到$PATH
。
验证
运行
dsc
查看有关它的信息。dsc
$ dsc
Copy to Clipboard Copied!
其他资源
- "DSC 参考文档"
2.3. 架构
图 2.1. 使用 Dev Workspace operator 的高级别 OpenShift Dev Spaces 架构

OpenShift Dev Spaces 在三个组件组上运行:
- OpenShift Dev Spaces 服务器组件
- 管理用户项目和工作区.主要组件是 User dashboard,用户可从中控制其工作区。
- dev Workspace operator
-
创建和控制运行用户工作区所需的 OpenShift 对象。包括
Pod
、Services
和PersistentVolume
。 - 用户工作区
- 基于容器的开发环境,包括 IDE。
这些 OpenShift 功能的角色是中心:
- dev Workspace 自定义资源
- 代表用户工作区并由 OpenShift Dev Spaces 操作的有效 OpenShift 对象。它是三组组件的通信通道。
- OpenShift 基于角色的访问控制(RBAC)
- 控制对所有资源的访问。
其他资源
2.3.1. 服务器组件
OpenShift Dev Spaces 服务器组件确保多租户和工作区管理。
图 2.2. OpenShift Dev Spaces 服务器组件与 Dev Workspace operator 交互

其他资源
2.3.1.1. dev Spaces operator
OpenShift Dev Spaces operator 确保 OpenShift Dev Spaces 服务器组件的完整生命周期管理。它引进了:
CheCluster
自定义资源定义(CRD)-
定义
CheCluster
OpenShift 对象。 - OpenShift Dev Spaces 控制器
- 创建并控制所需的 OpenShift 对象,以运行 OpenShift Dev Spaces 实例,如 pod、服务和持久性卷。
CheCluster
自定义资源(CR)在使用 OpenShift Dev Spaces operator 的集群中,可以创建
CheCluster
自定义资源(CR)。OpenShift Dev Spaces operator 可确保此 OpenShift Dev Spaces 实例中 OpenShift Dev Spaces 服务器组件的完整生命周期管理:
2.3.1.2. dev Workspace operator
Dev Workspace operator 扩展 OpenShift 以提供 Dev Workspace 支持。它引进了:
- dev Workspace 自定义资源定义
- 从 Devfile v2 规范定义 Dev Workspace OpenShift 对象。
- dev Workspace 控制器
- 创建和控制所需的 OpenShift 对象,以运行 Dev Workspace,如 Pod、服务和持久卷。
- dev Workspace 自定义资源
- 在使用 Dev Workspace operator 的集群中,可以创建 Dev Workspace 自定义资源(CR)。Dev Workspace CR 是 Devfile 的 OpenShift 表示。它在 OpenShift 集群中定义一个用户工作区。
其他资源
2.3.1.3. 网关
OpenShift Dev Spaces 网关有以下角色:
- 路由请求.它使用 Traefik。
- 使用 OpenID Connect (OIDC)验证用户。它使用 OpenShift OAuth2 代理。
- 应用 OpenShift 基于角色的访问控制(RBAC)策略来控制对任何 OpenShift Dev Spaces 资源的访问。它使用 'kube-rbac-proxy'。
OpenShift Dev Spaces operator 将其作为 che-gateway
部署进行管理。
它控制对以下的访问:
图 2.3. OpenShift Dev Spaces 网关与其他组件交互

其他资源
2.3.1.4. 用户仪表板
用户仪表板是 Red Hat OpenShift Dev Spaces 的登录页面。OpenShift Dev Spaces 用户浏览用户仪表板以访问和管理其工作区。这是一个 React 应用程序。OpenShift Dev Spaces 部署在 devspaces-dashboard
Deployment 中启动。
它需要访问:
- 第 2.3.1.5 节 “dev Spaces server”
- 第 2.3.1.6 节 “插件 registry”
- OpenShift API
图 2.4. 用户仪表板与其他组件的交互

当用户请求用户仪表板启动工作区时,用户仪表板会执行这个操作序列:
- 将存储库 URL 发送到 第 2.3.1.5 节 “dev Spaces server”,并在用户从远程 devfile 创建工作区时返回 devfile。
- 读取描述工作区的 devfile。
- 从 第 2.3.1.6 节 “插件 registry” 收集其他元数据。
- 将信息转换为 Dev Workspace 自定义资源。
- 使用 OpenShift API 在用户项目中创建 Dev Workspace 自定义资源。
- 监视 Dev Workspace 自定义资源状态。
- 将用户重定向到正在运行的工作区 IDE。
2.3.1.5. dev Spaces server
其他资源
OpenShift Dev Spaces 服务器主要功能有:
- 创建用户命名空间。
- 使用所需的 secret 和配置映射置备用户命名空间。
- 与 Git 服务供应商集成,以获取和验证 devfile 和身份验证。
OpenShift Dev Spaces 服务器是一个 Java Web 服务,公开 HTTP REST API 并需要访问:
- Git 服务供应商
- OpenShift API
图 2.5. OpenShift Dev Spaces 服务器与其他组件交互

2.3.1.6. 插件 registry
每个 OpenShift Dev Spaces 工作区都以特定的编辑器和一组关联的扩展开始。OpenShift Dev Spaces 插件 registry 提供了可用编辑器和编辑器扩展列表。Devfile v2 描述了每个编辑器或扩展。
第 2.3.1.4 节 “用户仪表板” 读取 registry 的内容。
图 2.6. 插件 registry 与其他组件交互

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

用户工作区是在容器中运行的 Web IDE。
用户工作区是一个 Web 应用程序。它由容器中运行的微服务组成,提供在浏览器中运行的现代 IDE 的所有服务:
- Editor
- 语言自动完成
- 语言服务器
- 调试工具
- 插件
- 应用程序运行时
工作区是一个 OpenShift Deployment,其中包含工作区容器和启用的插件,以及相关的 OpenShift 组件:
- 容器
- ConfigMaps
- 服务
- Endpoints
- ingresses 或 Routes
- Secrets
- 持久性卷(PV)
OpenShift Dev Spaces 工作区包含项目的源代码,保留在 OpenShift 持久性卷(PV)中。微服务对该共享目录具有读/写访问权限。
使用 devfile v2 格式指定 OpenShift Dev Spaces 工作区的工具和运行时应用程序。
下图显示了一个运行 OpenShift Dev Spaces 工作区及其组件。
图 2.8. OpenShift Dev Spaces 工作区组件

在图中,有一个正在运行的工作区。
2.4. 计算 Dev Spaces 资源要求
OpenShift Dev Spaces Operator、Dev Workspace Controller 和用户工作区由一组 pod 组成。pod 贡献 CPU 和内存限值和请求中的资源消耗。
以下示例 devfile 的链接是从上游社区的指向材料的指针。本材料代表了非常最新的可用内容和最新最佳实践。这些提示尚未由红帽的 QE 部门审查,并且尚未由广泛的用户组验证。请小心使用此信息。它最适合用于教育和"开发"目的,而不是"生产"目的。
流程
识别依赖于用于定义开发环境的 devfile 的工作区资源要求。这包括识别 devfile 的
components
部分明确指定的工作区组件。以下是带有 以下组件的 devfile 示例 :
例 2.1.
工具
devfile
的工具
组件定义了以下请求和限制:memoryLimit: 6G memoryRequest: 512M cpuRequest: 1000m cpuLimit: 4000m
memoryLimit: 6G memoryRequest: 512M cpuRequest: 1000m cpuLimit: 4000m
Copy to Clipboard Copied! 在工作区启动过程中,使用以下请求和限制隐式置备内部
che-gateway
容器:memoryLimit: 256M memoryRequest: 64M cpuRequest: 50m cpuLimit: 500m
memoryLimit: 256M memoryRequest: 64M cpuRequest: 50m cpuLimit: 500m
Copy to Clipboard Copied!
计算每个工作区所需的资源总和。如果要使用多个 devfile,请对每个预期的 devfile 重复这个计算。
例 2.2. 上一步中 示例 devfile 的工作区要求
用途 Pod 容器名称 内存限制 内存请求 CPU 限制 CPU 请求 开发人员工具
工作区
工具
6 GiB
512 MiB
4000 m
1000 m
OpenShift Dev Spaces 网关
工作区
che-gateway
256 MiB
64 MiB
500 m
50 M
总计
6.3 GiB
576 MiB
4500 m
1050 m
- 将每个工作区的资源乘以您希望所有用户同时运行的工作区数。
计算 OpenShift Dev Spaces Operator、Operands 和 Dev Workspace Controller 的要求总和。
表 2.1. OpenShift Dev Spaces Operator、Operands 和 Dev Workspace Controller 的默认要求 用途 Pod 名称 容器名称 内存限制 内存请求 CPU 限制 CPU 请求 OpenShift Dev Spaces operator
devspaces-operator
devspaces-operator
256 MiB
64 MiB
500 m
100 m
OpenShift Dev Spaces Server
devspaces
devspaces-server
1 GiB
512 MiB
1000 m
100 m
OpenShift Dev Spaces Dashboard
devspaces-dashboard
devspaces-dashboard
256 MiB
32 MiB
500 m
100 m
OpenShift Dev Spaces Gateway
devspaces-gateway
traefik
4 GiB
128 MiB
1000 m
100 m
OpenShift Dev Spaces Gateway
devspaces-gateway
configbump
256 MiB
64 MiB
500 m
50 M
OpenShift Dev Spaces Gateway
devspaces-gateway
oauth-proxy
512 MiB
64 MiB
500 m
100 m
OpenShift Dev Spaces Gateway
devspaces-gateway
kube-rbac-proxy
512 MiB
64 MiB
500 m
100 m
Devfile registry
devfile-registry
devfile-registry
256 MiB
32 MiB
500 m
100 m
插件 registry
plugin-registry
plugin-registry
256 MiB
32 MiB
500 m
100 m
dev Workspace Controller Manager
devworkspace-controller-manager
devworkspace-controller
1 GiB
100 MiB
1000 m
250 m
dev Workspace Controller Manager
devworkspace-controller-manager
kube-rbac-proxy
不适用
不适用
不适用
不适用
dev Workspace webhook 服务器
devworkspace-webhook-server
webhook-server
300 MiB
20 MiB
200 m
100 m
dev Workspace Operator Catalog
devworkspace-operator-catalog
registry-server
不适用
50 MiB
不适用
10 m
dev Workspace Webhook 服务器
devworkspace-webhook-server
webhook-server
300 MiB
20 MiB
200 m
100 m
dev Workspace Webhook 服务器
devworkspace-webhook-server
kube-rbac-proxy
不适用
不适用
不适用
不适用
总计
9 GiB
1.2 GiB
6.9
1.3
第 3 章 安装 Dev Spaces
本节包含安装 Red Hat OpenShift Dev Spaces 的说明。
您只能为每个集群部署一个 OpenShift Dev Spaces 实例。
3.1. 在云中安装 Dev Spaces
在云中部署和运行 Red Hat OpenShift Dev Spaces。
先决条件
- 用于部署 OpenShift Dev Spaces 的 OpenShift 集群。
-
DSC
: Red Hat OpenShift Dev Spaces 的命令行工具。请参阅:第 2.2 节 “安装 dsc 管理工具”。
3.1.1. 在云中部署 OpenShift Dev Spaces
按照以下说明,使用 dsc
工具启动云中的 OpenShift Dev Spaces 服务器。
- 第 3.1.2 节 “使用 CLI 在 OpenShift 上安装 Dev Spaces”
- 第 3.1.3 节 “使用 Web 控制台在 OpenShift 上安装 Dev Spaces”
- 第 3.1.4 节 “在受限环境中安装 Dev Spaces”
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#installing-che-on-microsoft-azure
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#installing-che-on-amazon-elastic-kubernetes-service
3.1.2. 使用 CLI 在 OpenShift 上安装 Dev Spaces
您可以在 OpenShift 上安装 OpenShift Dev Spaces。
先决条件
- OpenShift Container Platform
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。 -
DSC
.请参阅:第 2.2 节 “安装 dsc 管理工具”。
流程
可选:如果您之前在此 OpenShift 集群中部署了 OpenShift Dev Spaces,请确保删除了以前的 OpenShift Dev Spaces 实例:
dsc server:delete
$ dsc server:delete
Copy to Clipboard Copied! 创建 OpenShift Dev Spaces 实例:
dsc server:deploy --platform openshift
$ dsc server:deploy --platform openshift
Copy to Clipboard Copied!
验证步骤
验证 OpenShift Dev Spaces 实例状态:
dsc server:status
$ dsc server:status
Copy to Clipboard Copied! 进入到 OpenShift Dev Spaces 集群实例:
dsc dashboard:open
$ dsc dashboard:open
Copy to Clipboard Copied!
3.1.3. 使用 Web 控制台在 OpenShift 上安装 Dev Spaces
如果在 命令行 上安装 OpenShift Dev Spaces 时遇到问题,您可以通过 OpenShift Web 控制台安装它。
先决条件
- 集群管理员的 OpenShift Web 控制台会话。请参阅 访问 Web 控制台。
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。 - 要在同一 OpenShift 集群上重复安装:您可以根据 第 9 章 卸载 Dev Spaces 卸载之前的 OpenShift Dev Spaces 实例。
流程
-
在 OpenShift Web 控制台的 Administrator 视图中,进入 Operators → OperatorHub 并搜索
Red Hat OpenShift Dev Spaces
。 安装 Red Hat OpenShift Dev Spaces Operator。
提示请参阅使用 Web 控制台从 OperatorHub 安装。
小心Red Hat OpenShift Dev Spaces Operator 依赖于 Dev Workspace Operator。如果您手动将 Red Hat OpenShift Dev Spaces Operator 安装到非默认命名空间中,请确保同时安装了 Dev Workspace Operator。这是必需的,因为 Operator Lifecycle Manager 将尝试将 Dev Workspace Operator 作为 Red Hat OpenShift Dev Spaces Operator 命名空间中的依赖项安装,如果后者在不同的命名空间中安装,可能会导致 Dev Workspace Operator 的两个冲突安装。
如果要在集群中加入 Web Terminal Operator,请确保使用与 Red Hat OpenShift Dev Spaces Operator 相同的安装命名空间,因为它们都依赖于 Dev Workspace Operator。Web Terminal Operator、Red Hat OpenShift Dev Spaces Operator 和 Dev Workspace Operator 必须安装在同一个命名空间中。
在 OpenShift 中创建
openshift-devspaces
项目,如下所示:oc create namespace openshift-devspaces
oc create namespace openshift-devspaces
Copy to Clipboard Copied! - 进入 Operators → Installed Operators → Red Hat OpenShift Dev Spaces 实例 Specification → Create CheCluster → YAML view。
-
在 YAML 视图中,将
namespace: openshift-operators
替换为namespace: openshift-devspaces
。 选择 Create。
提示
验证
- 在 Red Hat OpenShift Dev Spaces 实例规格中,进入 devspaces,在 Details 标签页中登录。
- 在 Message 下,检查是否有 None,这表示没有任何错误。
- 在 Red Hat OpenShift Dev Spaces URL 下,等待 OpenShift Dev Spaces 实例的 URL 出现,然后打开 URL 以检查 OpenShift Dev Spaces 仪表板。
- 在 Resources 选项卡中,查看 OpenShift Dev Spaces 部署的资源及其状态。
3.1.4. 在受限环境中安装 Dev Spaces
在受限网络中运行的 OpenShift 集群上,无法使用公共资源。
但是,部署 OpenShift Dev Spaces 并运行工作区需要以下公共资源:
- Operator 目录
- 容器镜像
- 示例项目
要使这些资源可用,您可以将它们替换为 OpenShift 集群可访问的注册表中的副本。
先决条件
- OpenShift 集群至少有 64 GB 磁盘空间。
- OpenShift 集群已准备好在受限网络中运行。请参阅关于断开连接的安装镜像,以及 在受限网络中使用 Operator Lifecycle Manager。
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。 -
到
registry.redhat.io
红帽生态系统目录的一个活跃的oc registry
会话。请参阅: Red Hat Container Registry 身份验证。
-
opm
.请参阅安装opm
CLI。 -
jq
.请参阅 下载jq
。 -
Podman
.请参阅 Podman 安装说明。 -
Skopeo
版本 1.6 或更高版本。请参阅 安装 Skopeo。 -
一个活跃的
skopeo
会话,具有对私有 Docker registry 的管理访问权限。对 registry 进行身份验证 ,并为断开连接的安装 mirror 镜像。 -
用于
OpenShift Dev Spaces 版本 3.20 的 DSC。请参阅 第 2.2 节 “安装 dsc 管理工具”。
流程
下载并执行镜像脚本,以安装自定义 Operator 目录并镜像相关镜像: prepare-restricted-environment.sh。
bash prepare-restricted-environment.sh \ --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.18\ --devworkspace_operator_version "v0.33.0" \ --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.18" \ --prod_operator_package_name "devspaces" \ --prod_operator_bundle_name "devspacesoperator" \ --prod_operator_version "v3.20.0" \ --my_registry "<my_registry>"
$ bash prepare-restricted-environment.sh \ --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.18\ --devworkspace_operator_version "v0.33.0" \ --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.18" \ --prod_operator_package_name "devspaces" \ --prod_operator_bundle_name "devspacesoperator" \ --prod_operator_version "v3.20.0" \ --my_registry "<my_registry>"
1 Copy to Clipboard Copied! - 1
- 镜像要镜像的专用 Docker registry
使用上一步中
che-operator-cr-patch.yaml
中设置的配置安装 OpenShift Dev Spaces:dsc server:deploy \ --platform=openshift \ --olm-channel stable \ --catalog-source-name=devspaces-disconnected-install \ --catalog-source-namespace=openshift-marketplace \ --skip-devworkspace-operator \ --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml
$ dsc server:deploy \ --platform=openshift \ --olm-channel stable \ --catalog-source-name=devspaces-disconnected-install \ --catalog-source-namespace=openshift-marketplace \ --skip-devworkspace-operator \ --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml
Copy to Clipboard Copied! - 允许来自 OpenShift Dev Spaces 命名空间中的传入流量到用户项目中的所有 Pod。请参阅:第 4.8.1 节 “配置网络策略”。
其他资源
3.1.4.1. 设置 Ansible 示例
按照以下步骤在受限环境中使用 Ansible 示例。
先决条件
- Microsoft Visual Studio Code - Open Source IDE
- 64 位 x86 系统。
流程
镜像以下镜像:
ghcr.io/ansible/ansible-devspaces@sha256:a28fa23d254ff1b3ae10b95a0812132148f141bda4516661e40d0c49c4ace200 registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb
ghcr.io/ansible/ansible-devspaces@sha256:a28fa23d254ff1b3ae10b95a0812132148f141bda4516661e40d0c49c4ace200 registry.access.redhat.com/ubi8/python-39@sha256:301fec66443f80c3cc507ccaf72319052db5a1dc56deb55c8f169011d4bbaacb
Copy to Clipboard Copied! 配置集群代理以允许访问以下域:
.ansible.com .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com
.ansible.com .ansible-galaxy-ng.s3.dualstack.us-east-1.amazonaws.com
Copy to Clipboard Copied!
计划在以后的版本中对以下 IDE 和 CPU 架构的支持:
IDE
- JetBrains IntelliJ IDEA 社区版 IDE (技术预览)
CPU 架构
- IBM Power (ppc64le)
- IBM Z (s390x)
3.2. 查找完全限定域名(FQDN)
您可以在命令行中或 OpenShift Web 控制台中获取机构 OpenShift Dev Spaces 实例的完全限定域名(FQDN)。
您可以在 OpenShift Web 控制台的 Administrator 视图中找到机构的 OpenShift Dev Spaces 实例的 FQDN,如下所示。进入 Operators → Installed Operators → Red Hat OpenShift Dev Spaces 实例 Specification → devspaces → Red Hat OpenShift Dev Spaces URL。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。
流程
运行以下命令:
oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'
oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.status.cheURL}'
Copy to Clipboard Copied!
3.3. 安装 Dev Spaces 的权限
了解在不同 Kubernetes 集群上安装 Red Hat OpenShift Dev Spaces 所需的权限。
3.3.1. 使用 CLI 在 OpenShift 上安装 Dev Spaces 的权限
以下是使用 dsc 在 OpenShift 集群上安装 OpenShift Dev Spaces 所需的最小权限集:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: devspaces-install-dsc rules: - apiGroups: ["org.eclipse.che"] resources: ["checlusters"] verbs: ["*"] - apiGroups: ["project.openshift.io"] resources: ["projects"] verbs: ["get", "list"] - apiGroups: [""] resources: ["namespaces"] verbs: ["get", "list", "create"] - apiGroups: [""] resources: ["pods", "configmaps"] verbs: ["get", "list"] - apiGroups: ["route.openshift.io"] resources: ["routes"] verbs: ["get", "list"] # OLM resources permissions - apiGroups: ["operators.coreos.com"] resources: ["catalogsources", "subscriptions"] verbs: ["create", "get", "list", "watch"] - apiGroups: ["operators.coreos.com"] resources: ["operatorgroups", "clusterserviceversions"] verbs: ["get", "list", "watch"] - apiGroups: ["operators.coreos.com"] resources: ["installplans"] verbs: ["patch", "get", "list", "watch"] - apiGroups: ["packages.operators.coreos.com"] resources: ["packagemanifests"] verbs: ["get", "list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devspaces-install-dsc
rules:
- apiGroups: ["org.eclipse.che"]
resources: ["checlusters"]
verbs: ["*"]
- apiGroups: ["project.openshift.io"]
resources: ["projects"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "list", "create"]
- apiGroups: [""]
resources: ["pods", "configmaps"]
verbs: ["get", "list"]
- apiGroups: ["route.openshift.io"]
resources: ["routes"]
verbs: ["get", "list"]
# OLM resources permissions
- apiGroups: ["operators.coreos.com"]
resources: ["catalogsources", "subscriptions"]
verbs: ["create", "get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
resources: ["operatorgroups", "clusterserviceversions"]
verbs: ["get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
resources: ["installplans"]
verbs: ["patch", "get", "list", "watch"]
- apiGroups: ["packages.operators.coreos.com"]
resources: ["packagemanifests"]
verbs: ["get", "list"]
3.3.2. 使用 Web 控制台在 OpenShift 上安装 Dev Spaces 的权限
以下是使用 Web 控制台在 OpenShift 集群上安装 OpenShift Dev Spaces 所需的最小权限集:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: devspaces-install-web-console rules: - apiGroups: ["org.eclipse.che"] resources: ["checlusters"] verbs: ["*"] - apiGroups: [""] resources: ["namespaces"] verbs: ["get", "list", "create"] - apiGroups: ["project.openshift.io"] resources: ["projects"] verbs: ["get", "list", "create"] # OLM resources permissions - apiGroups: ["operators.coreos.com"] resources: ["subscriptions"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: ["operators.coreos.com"] resources: ["operatorgroups"] verbs: ["get", "list", "watch"] - apiGroups: ["operators.coreos.com"] resources: ["clusterserviceversions", "catalogsources", "installplans"] verbs: ["get", "list", "watch", "delete"] - apiGroups: ["packages.operators.coreos.com"] resources: ["packagemanifests", "packagemanifests/icon"] verbs: ["get", "list", "watch"] # Workaround related to viewing operators in OperatorHub - apiGroups: ["operator.openshift.io"] resources: ["cloudcredentials"] verbs: ["get", "list", "watch"] - apiGroups: ["config.openshift.io"] resources: ["infrastructures", "authentications"] verbs: ["get", "list", "watch"]
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devspaces-install-web-console
rules:
- apiGroups: ["org.eclipse.che"]
resources: ["checlusters"]
verbs: ["*"]
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["get", "list", "create"]
- apiGroups: ["project.openshift.io"]
resources: ["projects"]
verbs: ["get", "list", "create"]
# OLM resources permissions
- apiGroups: ["operators.coreos.com"]
resources: ["subscriptions"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["operators.coreos.com"]
resources: ["operatorgroups"]
verbs: ["get", "list", "watch"]
- apiGroups: ["operators.coreos.com"]
resources: ["clusterserviceversions", "catalogsources", "installplans"]
verbs: ["get", "list", "watch", "delete"]
- apiGroups: ["packages.operators.coreos.com"]
resources: ["packagemanifests", "packagemanifests/icon"]
verbs: ["get", "list", "watch"]
# Workaround related to viewing operators in OperatorHub
- apiGroups: ["operator.openshift.io"]
resources: ["cloudcredentials"]
verbs: ["get", "list", "watch"]
- apiGroups: ["config.openshift.io"]
resources: ["infrastructures", "authentications"]
verbs: ["get", "list", "watch"]
第 4 章 配置 Dev Spaces
本节论述了 Red Hat OpenShift Dev Spaces 的配置方法和选项。
4.1. 了解 CheCluster
自定义资源
OpenShift Dev Spaces 的默认部署由 Red Hat OpenShift Dev Spaces Operator 由一个 CheCluster
自定义资源参数组成。
CheCluster
自定义资源是一个 Kubernetes 对象。您可以通过编辑 CheCluster
自定义资源 YAML 文件来配置它。此文件包含配置每个组件的部分: devWorkspace
、cheServer
、pluginRegistry
、devfileRegistry
、仪表板和
imagePuller
。
Red Hat OpenShift Dev Spaces Operator 将 CheCluster
自定义资源转换为 OpenShift Dev Spaces 安装的每个组件可用的配置映射中。
OpenShift 平台将配置应用到每个组件,并创建所需的 Pod。当 OpenShift 检测到一个组件的配置中有更改时,它会相应地重启 Pod。
例 4.1. 配置 OpenShift Dev Spaces 服务器组件的主要属性
-
在
cheServer
组件部分中应用带有适当修改的CheCluster
自定义资源 YAML 文件。 -
Operator 生成
che
ConfigMap
。 -
OpenShift 检测到
ConfigMap
中的更改,并触发 OpenShift Dev Spaces Pod 重启。
其他资源
4.1.1. 在安装过程中使用 dsc 配置 CheCluster
自定义资源
要使用合适的配置部署 OpenShift Dev Spaces,请在安装 OpenShift Dev Spaces 的过程中编辑 CheCluster
自定义资源 YAML 文件。否则,OpenShift Dev Spaces 部署使用 Operator 的默认配置参数。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 CLI 入门。 -
DSC
.请参阅:第 2.2 节 “安装 dsc 管理工具”。
流程
创建一个
che-operator-cr-patch.yaml
YAML 文件,其中包含要配置的CheCluster
自定义资源的子集:spec: <component>: <property_to_configure>: <value>
spec: <component>: <property_to_configure>: <value>
Copy to Clipboard Copied! 部署 OpenShift Dev Spaces 并应用
che-operator-cr-patch.yaml
文件中描述的更改:dsc server:deploy \ --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \ --platform <chosen_platform>
$ dsc server:deploy \ --che-operator-cr-patch-yaml=che-operator-cr-patch.yaml \ --platform <chosen_platform>
Copy to Clipboard Copied!
验证
验证配置的属性的值:
oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
$ oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
Copy to Clipboard Copied!
4.1.2. 使用 CLI 配置 CheCluster 自定义资源
要配置 OpenShift Dev Spaces 的运行实例,请编辑 CheCluster
自定义资源 YAML 文件。
先决条件
- OpenShift 上的 OpenShift Dev Spaces 实例。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
编辑集群中的 CheCluster 自定义资源:
oc edit checluster/devspaces -n openshift-devspaces
$ oc edit checluster/devspaces -n openshift-devspaces
Copy to Clipboard Copied! - 保存并关闭该文件以应用更改。
验证
验证配置的属性的值:
oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
$ oc get configmap che -o jsonpath='{.data.<configured_property>}' \ -n openshift-devspaces
Copy to Clipboard Copied!
4.1.3. CheCluster
自定义资源字段参考
本节介绍可用于自定义 CheCluster
自定义资源的所有字段。
例 4.2. 最小的 CheCluster
自定义资源示例。
apiVersion: org.eclipse.che/v2 kind: CheCluster metadata: name: devspaces namespace: openshift-devspaces spec: components: {} devEnvironments: {} networking: {}
apiVersion: org.eclipse.che/v2
kind: CheCluster
metadata:
name: devspaces
namespace: openshift-devspaces
spec:
components: {}
devEnvironments: {}
networking: {}
属性 | 描述 | default |
---|---|---|
allowedSources | AllowedSources 定义可以在其上启动工作区的允许源。 | |
containerBuildConfiguration | 容器构建配置。 | |
defaultComponents | 应用到 DevWorkspace 的默认组件。这些默认组件旨在在 Devfile (不包含任何组件)时使用。 | |
defaultEditor |
要创建工作区的默认编辑器。它可以是插件 ID 或 URI。插件 ID 必须具有 | |
defaultNamespace | 用户的默认命名空间。 | { "autoProvision": true, "template": "<username>-che"} |
defaultPlugins | 应用到 DevWorkspace 的默认插件。 | |
deploymentStrategy |
DeploymentStrategy 定义部署策略,用于将现有工作区 pod 替换为新 pod。可用的部署模块是 | |
disableContainerBuildCapabilities |
禁用容器构建功能。当设置为 | |
gatewayContainer | GatewayContainer 配置。 | |
ignoredUnrecoverableEvents | IgnoredUnrecoverableEvents 定义在决定失败启动的工作区时应忽略的 Kubernetes 事件名称列表。如果临时集群问题触发假正(例如,如果集群偶尔遇到 FailedScheduling 事件),则应使用此选项。此处列出的事件不会触发工作区失败。 | [ "FailedScheduling"] |
imagePullPolicy | imagePullPolicy 定义用于 DevWorkspace 中容器的 imagePullPolicy。 | |
maxNumberOfRunningWorkspacesPerCluster | 在整个 Kubernetes 集群中同时运行的最大工作区数。这适用于系统中的所有用户。如果值设为 -1,这表示运行工作区的数量没有限制。 | |
maxNumberOfRunningWorkspacesPerUser | 每个用户的最大运行工作区数。值 -1 允许用户运行无限数量的工作区。 | |
maxNumberOfWorkspacesPerUser | 用户可以保留的工作区总数,包括已停止和运行。值 -1 允许用户保留无限数量的工作区。 | -1 |
nodeSelector | 节点选择器限制可运行工作区 pod 的节点。 | |
persistUserHome | PersistUserHome 定义用于在工作区中保留用户主目录的配置选项。 | |
podSchedulerName | 工作区 pod 的 Pod 调度程序。如果没有指定,pod 调度程序被设置为集群中的默认调度程序。 | |
projectCloneContainer | 项目克隆容器配置。 | |
runtimeClassName | runtimeClassName 为工作区 pod 指定 spec.runtimeClassName。 | |
secondsOfInactivityBeforeIdling | 空闲的超时时间(以秒为单位)。此超时是持续时间,之后如果没有活动,则工作区将闲置。要禁用因为不活跃的工作区闲置,请将此值设置为 -1。 | 1800 |
secondsOfRunBeforeIdling | 为工作区运行超时(以秒为单位)。此超时是工作区运行的最长持续时间。要禁用工作区运行超时,请将此值设置为 -1。 | -1 |
安全 | 工作区安全配置。 | |
serviceAccount | 启动工作区时,由 DevWorkspace operator 使用的 ServiceAccount。 | |
serviceAccountTokens | 将作为投射卷挂载到工作区 pod 中的 ServiceAccount 令牌列表。 | |
startTimeoutSeconds | StartTimeoutSeconds 决定工作区在自动失败前可以开始的最长时间(以秒为单位)。如果没有指定,则使用默认值 300 秒(5 分钟)。 | 300 |
storage | 工作区持久性存储。 | { "pvcStrategy": "per-user"} |
容限(tolerations) | 工作区 pod 的 pod 容限限制工作区 pod 可以运行的位置。 | |
trustedCerts | 可信证书设置。 | |
user | 用户配置。 | |
workspacesPodAnnotations | WorkspacesPodAnnotations 为工作区 pod 定义额外的注解。 |
属性 | 描述 | default |
---|---|---|
autoProvision | 指明是否允许自动创建用户命名空间。如果设置为 false,则集群管理员必须预先创建用户命名空间。 | true |
模板 |
如果您没有提前创建用户命名空间,此字段定义启动第一个工作区时创建的 Kubernetes 命名空间。您可以使用 < | "<username>-che" |
属性 | 描述 | default |
---|---|---|
Editor |
用于指定默认插件的编辑器 ID。插件 ID 必须具有 | |
plugins | 指定编辑器的默认插件 URI。 |
属性 | 描述 | default |
---|---|---|
env | 容器中要设置的环境变量列表。 | |
image | 容器镜像。省略它或留空,以使用 Operator 提供的默认容器镜像。 | |
imagePullPolicy |
镜像拉取(pull)策略。对于 | |
name | 容器名称。 | |
resources | 此容器所需的计算资源。 |
属性 | 描述 | default |
---|---|---|
perUserStrategyPvcConfig |
使用 | |
perWorkspaceStrategyPvcConfig |
使用 | |
pvcStrategy |
OpenShift Dev Spaces 服务器的持久性卷声明策略。支持的策略有: | "per-user" |
属性 | 描述 | default |
---|---|---|
claimSize | 持久性卷声明大小。要更新声明大小,置备它的存储类必须支持调整大小。 | |
storageClass | 持久性卷声明的存储类。当省略或留空时,会使用默认存储类。 |
属性 | 描述 | default |
---|---|---|
claimSize | 持久性卷声明大小。要更新声明大小,置备它的存储类必须支持调整大小。 | |
storageClass | 持久性卷声明的存储类。当省略或留空时,会使用默认存储类。 |
属性 | 描述 | default |
---|---|---|
disableWorkspaceCaBundleMount | 默认情况下,Operator 会在两个位置创建并挂载包含用户"工作区中的 CA 证书捆绑包的 'ca-certs-merged' ConfigMap: '/public-certs' 和 '/etc/pki/ca-trust/extracted/pem'。'/etc/pki/ca-trust/extracted/pem' 目录是系统存储红帽可信证书颁发机构提取的 CA 证书(如 CentOS、Fedora)。这个选项禁止将 CA 捆绑包挂载到 '/etc/pki/ca-trust/extracted/pem' 目录,同时仍然将其挂载到 '/public-certs'。 | |
gitTrustedCertsConfigMapName |
ConfigMap 包含要传播到 OpenShift Dev Spaces 组件的证书,并为 Git 提供特定的配置。请参见以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/deploying-che-with-support-for-git-repositories-with-self-signed-certificates/ ConfigMap 必须有一个 |
属性 | 描述 | default |
---|---|---|
openShiftSecurityContextConstraint | 构建容器的 OpenShift 安全性上下文约束。 | "Container-build" |
属性 | 描述 | default |
---|---|---|
cheServer | 与 OpenShift Dev Spaces 服务器相关的常规配置设置。 | { "debug": false, "logLevel": "INFO"} |
dashboard | 与 OpenShift Dev Spaces 安装使用的仪表板相关的配置设置。 | |
devWorkspace | DevWorkspace Operator 配置。 | |
devfileRegistry | 与 OpenShift Dev Spaces 安装使用的 devfile registry 相关的配置设置。 | |
imagePuller | Kubernetes Image Puller 配置。 | |
metrics | OpenShift Dev Spaces 服务器指标配置。 | { "enable": true} |
pluginRegistry | 与 OpenShift Dev Spaces 安装使用的插件 registry 相关的配置设置。 |
属性 | 描述 | default |
---|---|---|
clusterRoles |
分配给 OpenShift Dev Spaces ServiceAccount 的额外 ClusterRole。每个角色都必须有一个 | |
debug | 为 OpenShift Dev Spaces 服务器启用调试模式。 | false |
部署 | 部署覆盖选项。 | |
extraProperties |
在生成的 | |
logLevel |
OpenShift Dev Spaces 服务器的日志级别: | "INFO" |
proxy | Kubernetes 集群的代理服务器设置。OpenShift 集群不需要额外的配置。通过为 OpenShift 集群指定这些设置,您可以覆盖 OpenShift 代理配置。 |
属性 | 描述 | default |
---|---|---|
credentialsSecretName |
包含代理服务器 | |
nonProxyHosts |
可直接到达的主机列表,绕过代理。指定通配符域使用以下形式 | |
port | 代理服务器端口。 | |
url |
代理服务器的 URL (protocol+hostname)。仅在需要代理配置时使用。Operator 遵循 OpenShift 集群范围的代理配置,在自定义资源中定义 |
属性 | 描述 | default |
---|---|---|
部署 | 部署覆盖选项。 | |
disableInternalRegistry | 禁用内部插件 registry。 | |
externalPluginRegistries | 外部插件 registry。 | |
openVSXURL | 打开 VSX 注册表 URL。如果省略了嵌入的实例。 |
属性 | 描述 | default |
---|---|---|
url | 插件 registry 的公共 URL。 |
属性 | 描述 | default |
---|---|---|
部署 | 弃用的部署覆盖选项。 | |
disableInternalRegistry | 禁用内部 devfile registry。 | |
externalDevfileRegistries | 外部 devfile registry 为示例可用的 devfile 提供示例。 |
属性 | 描述 | default |
---|---|---|
url | 提供示例 ready-to-use devfiles 的 devfile registry 的公共 URL。 |
属性 | 描述 | default |
---|---|---|
品牌 | 仪表板品牌资源. | |
部署 | 部署覆盖选项。 | |
headerMessage | 仪表板标题消息。 | |
logLevel | 控制面板的日志级别。 | "ERROR" |
属性 | 描述 | default |
---|---|---|
显示 | 指示仪表板显示消息。 | |
text | 用户仪表板上显示警告消息。 |
属性 | 描述 | default |
---|---|---|
enable |
安装和配置社区支持的 Kubernetes Image Puller Operator。当您在不提供任何 spec 的情况下将值设为 | |
spec | 在 CheCluster 中配置镜像拉取器的 Kubernetes Image Puller spec。 |
属性 | 描述 | default |
---|---|---|
enable |
为 OpenShift Dev Spaces 服务器端点启用 | true |
属性 | 描述 | default |
---|---|---|
azure | 让用户能够处理托管在 Azure DevOps Service (dev.azure.com)上的存储库。 | |
Bitbucket | 允许用户处理托管在 Bitbucket 上的存储库(bitbucket.org 或自托管)。 | |
github | 允许用户使用托管在 GitHub 上的软件仓库(github.com 或 GitHub Enterprise)。 | |
gitlab | 让用户能够处理托管在 GitLab 上的存储库(gitlab.com 或自托管)。 |
属性 | 描述 | default |
---|---|---|
disableSubdomainIsolation |
禁用子域隔离。弃用了 | |
端点 |
GitHub 服务器端点 URL。弃用了 | |
secretName | Kubernetes secret,其中包含 Base64 编码的 GitHub OAuth 客户端 ID 和 GitHub OAuth 客户端 secret。详情请查看以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-github/。 |
属性 | 描述 | default |
---|---|---|
端点 |
GitLab 服务器端点 URL。弃用了 | |
secretName | Kubernetes secret,其中包含 Base64 编码的 GitHub Application id 和 GitLab Application Client secret。请参见以下页面 :https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-gitlab/。 |
属性 | 描述 | default |
---|---|---|
端点 |
Bitbucket 服务器端点 URL。弃用了 | |
secretName | Kubernetes secret,其中包含 Base64 编码的 Bitbucket OAuth 1.0 或 OAuth 2.0 数据。详情请查看以下页面: https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-1-for-a-bitbucket-server/ 和 https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-the-bitbucket-cloud/。 |
属性 | 描述 | default |
---|---|---|
secretName | Kubernetes secret,其中包含 Base64 编码的 Azure DevOps Service Application ID 和 Client Secret。请参见以下页面: https://www.eclipse.org/che/docs/stable/administration-guide/configuring-oauth-2-for-microsoft-azure-devops-services |
属性 | 描述 | default |
---|---|---|
annotations | 定义要为 Ingress 设置的注解(OpenShift 平台的路由)。kubernetes 平台的默认值为:kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/proxy-read-timeout: "3600", nginx.ingress.kubernetes.io/proxy-connect-timeout: "3600", nginx.ingress.kubernetes.io/ssl-redirect: "true" | |
auth | 身份验证设置. | { "gateway": { "configLabels": { "app": "che", "component": "che-gateway-config" } }} |
domain | 对于 OpenShift 集群,Operator 使用域为路由生成主机名。生成的主机名遵循以下模式:che-<devspaces-namespace>.<domain>。<devspaces-namespace> 是创建 CheCluster CRD 的命名空间。与标签结合使用,它会创建一个由非默认 Ingress 控制器提供的路由。对于 Kubernetes 集群,它包含一个全局入口域。没有默认值:您必须指定它们。 | |
hostname | 安装的 OpenShift Dev Spaces 服务器的公共主机名。 | |
ingressClassName |
ingressClassName 是 IngressClass 集群资源的名称。如果在 | |
labels | 定义要为 Ingress 设置的标签(OpenShift 平台的路由)。 | |
tlsSecretName |
用于设置 Ingress TLS 终止的 secret 名称。如果该字段是空字符串,则使用默认集群证书。secret 必须具有 |
属性 | 描述 | default |
---|---|---|
advancedAuthorization |
提前授权设置。决定允许哪些用户和组访问 Che。如果用户被允许访问 OpenShift Dev Spaces,如果他位于 | |
gateway | 网关设置. | { "configLabels": { "app": "che", "component": "che-gateway-config" }} |
identityProviderURL | 身份提供程序服务器的公共 URL。 | |
identityToken |
要传递给上游的身份令牌。支持的令牌有两种: | |
oAuthAccessTokenInactivityTimeoutSeconds |
在 OpenShift | |
oAuthAccessTokenMaxAgeSeconds |
在 OpenShift | |
oAuthClientName |
用于在 OpenShift 端设置身份联邦的 OpenShift | |
oAuthScope | 访问令牌范围.此字段特定于仅用于 Kubernetes 的 OpenShift Dev Spaces 安装,并针对 OpenShift 忽略。 | |
oAuthSecret |
在 OpenShift |
属性 | 描述 | default |
---|---|---|
configLabels | 网关配置标签。 | { "app": "che", "component": "che-gateway-config"} |
部署 |
部署覆盖选项。由于网关部署由多个容器组成,因此必须使用其名称来区分它们: - | |
kubeRbacProxy | 在 OpenShift Dev Spaces 网关 pod 中配置 kube-rbac-proxy。 | |
oAuthProxy | 在 OpenShift Dev Spaces 网关 pod 中配置 oauth-proxy。 | |
Traefik | 配置 OpenShift Dev Spaces 网关 pod 中的 Traefik。 |
属性 | 描述 | default |
---|---|---|
hostname | 从中拉取镜像的替代容器 registry 的可选主机名或 URL。这个值会覆盖 OpenShift Dev Spaces 部署中涉及的所有默认容器镜像中定义的容器 registry 主机名。这在受限环境中安装 OpenShift Dev Spaces 特别有用。 | |
机构 | 从中拉取镜像的替代 registry 的可选存储库名称。这个值会覆盖 OpenShift Dev Spaces 部署中涉及的所有默认容器镜像中定义的容器 registry 组织。这在受限环境中安装 OpenShift Dev Spaces 特别有用。 |
属性 | 描述 | default |
---|---|---|
containers | 属于 pod 的容器列表。 | |
nodeSelector | 节点选择器限制可运行 pod 的节点。 | |
securityContext | Pod 运行的安全选项。 | |
容限(tolerations) | pod 可以运行的组件 pod 限值的 pod 容限。 |
属性 | 描述 | default |
---|---|---|
env | 容器中要设置的环境变量列表。 | |
image | 容器镜像。省略它或留空,以使用 Operator 提供的默认容器镜像。 | |
imagePullPolicy |
镜像拉取(pull)策略。对于 | |
name | 容器名称。 | |
resources | 此容器所需的计算资源。 |
属性 | 描述 | default |
---|---|---|
limits | 描述允许的最大计算资源量。 | |
Request (请求) | 描述所需的最少计算资源。 |
属性 | 描述 | default |
---|---|---|
cpu |
CPU,以内核为单位。(500M = .5 个内核)如果没有指定值,则根据组件设置默认值。如果值为 | |
内存 |
内存,以字节为单位。(500Gi = 500GiB = 500 * 1024 * 1024 * 1024),如果没有指定值,则根据组件设置默认值。如果值为 |
属性 | 描述 | default |
---|---|---|
cpu |
CPU,以内核为单位。(500M = .5 个内核)如果没有指定值,则根据组件设置默认值。如果值为 | |
内存 |
内存,以字节为单位。(500Gi = 500GiB = 500 * 1024 * 1024 * 1024),如果没有指定值,则根据组件设置默认值。如果值为 |
属性 | 描述 | default |
---|---|---|
fsGroup |
适用于 pod 中所有容器的特殊补充组。默认值为 | |
runAsUser |
用于运行容器进程的入口点的 UID。默认值为 |
属性 | 描述 | default |
---|---|---|
chePhase | 指定 OpenShift Dev Spaces 部署的当前阶段。 | |
cheURL | OpenShift Dev Spaces 服务器的公共 URL。 | |
cheVersion | 当前安装的 OpenShift Dev Spaces 版本。 | |
devfileRegistryURL | 弃用了内部 devfile registry 的公共 URL。 | |
gatewayPhase | 指定网关部署的当前阶段。 | |
message | 人类可读的消息,指示 OpenShift Dev Spaces 部署处于当前阶段的详情。 | |
pluginRegistryURL | 内部插件 registry 的公共 URL。 | |
reason | 简短的 CamelCase 消息显示 OpenShift Dev Spaces 部署处于当前阶段的详情。 | |
workspaceBaseDomain | 解析的工作空间基域。这是在 spec 中明确定义相同名称的属性的副本,如果 spec 中未定义,且我们在 OpenShift 上运行,则会自动解析路由的 basedomain。 |
4.2. 配置项目
对于每个用户,OpenShift Dev Spaces 在项目中隔离工作区。OpenShift Dev Spaces 通过存在标签和注解来识别用户项目。启动工作区时,如果所需的项目不存在,OpenShift Dev Spaces 会使用模板名称创建项目。
您可以通过以下方法修改 OpenShift Dev Spaces 行为:
4.2.1. 配置项目名称
您可以在启动一个工作区时配置 OpenShift Dev Spaces 用来创建所需项目的项目名称模板。
有效的项目名称模板遵循以下约定:
-
<
;username>
; 或<userid
> 占位符是必需的。 -
用户名和 ID 不能包含无效字符。如果用户名或 ID 的格式与 OpenShift 对象的命名约定不兼容,OpenShift Dev Spaces 通过将不兼容的字符替换为有效的名称来更改有效名称。
-
OpenShift Dev Spaces 将 &
lt;userid
> 占位符评估为 14 个字符长字符串,并添加随机六个字符的后缀以防止 ID 冲突。结果保存在用户首选项中以供重复使用。 - Kubernetes 将项目名称的长度限制为 63 个字符。
- OpenShift 限制的长度为 49 个字符。
流程
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: devEnvironments: defaultNamespace: template: <workspace_namespace_template_>
spec: components: devEnvironments: defaultNamespace: template: <workspace_namespace_template_>
Copy to Clipboard Copied! 例 4.3. 用户工作区项目名称模板示例
用户工作区项目名称模板 生成的项目示例 <username>-devspaces
(默认)user1-devspaces
<userid>-namespace
cge1egvsb2nhba-namespace-ul1411
<userid>-aka-<username>-namespace
cgezegvsb2nhba-aka-user1-namespace-6m2w2b
4.2.2. 提前置备项目
您可以提前置备工作区项目,而不依赖于自动配置。为每个用户重复上述步骤。
流程
在
CheCluster
级别禁用自动命名空间置备:devEnvironments: defaultNamespace: autoProvision: false
devEnvironments: defaultNamespace: autoProvision: false
Copy to Clipboard Copied! 使用以下标签和注解为 <username> 用户创建 <project_name> 项目:
kind: Namespace apiVersion: v1 metadata: name: <project_name> labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-namespace annotations: che.eclipse.org/username: <username>
kind: Namespace apiVersion: v1 metadata: name: <project_name>
1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-namespace annotations: che.eclipse.org/username: <username>
Copy to Clipboard Copied! - 1
- 使用您选择的项目名称。
4.2.3. 配置用户命名空间
此流程指导您使用 OpenShift Dev Spaces 将 ConfigMap
、Secret、PersistentVolume
VolumeClaim
和其他 Kubernetes 对象从 openshift-devspaces
命名空间复制到多个特定于用户的命名空间。OpenShift Dev Spaces 会自动同步重要配置数据,如共享凭证、配置文件和证书到用户命名空间。
如果您在 openshift-devspaces 命名空间中更改 Kubernetes 资源,OpenShift Dev Spaces 会立即在所有用户命名空间中复制更改。相反,如果在用户命名空间中修改了 Kubernetes 资源,OpenShift Dev Spaces 将立即恢复更改。
流程
创建以下
ConfigMap
以复制到每个用户项目中。为增强配置性,您可以通过添加额外的标签和注解来自定义ConfigMap
。默认情况下,ConfigMap 会自动挂载到用户工作区。如果您不希望 ConfigMap 挂载,请明确添加以下标签来覆盖行为:controller.devfile.io/watch-configmap: "false" controller.devfile.io/mount-to-devworkspace: "false"
controller.devfile.io/watch-configmap: "false" controller.devfile.io/mount-to-devworkspace: "false"
Copy to Clipboard Copied! 有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret。
例 4.4. 将 ConfigMap 复制到每个用户项目中:
kind: ConfigMap apiVersion: v1 metadata: name: devspaces-user-configmap namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/watch-configmap: "false" controller.devfile.io/mount-to-devworkspace: "false" data: ...
kind: ConfigMap apiVersion: v1 metadata: name: devspaces-user-configmap namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/watch-configmap: "false" controller.devfile.io/mount-to-devworkspace: "false" data: ...
Copy to Clipboard Copied! 例 4.5. 将 ConfigMap 复制到每个用户项目中,并通过路径
/home/user/.m2
自动将settings.xml
文件挂载到每个用户容器中:kind: ConfigMap apiVersion: v1 metadata: name: devspaces-user-configmap namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.m2 data: settings.xml: | <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository>/home/user/.m2/repository</localRepository> <interactiveMode>true</interactiveMode> <offline>false</offline> </settings>
kind: ConfigMap apiVersion: v1 metadata: name: devspaces-user-configmap namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.m2 data: settings.xml: | <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository>/home/user/.m2/repository</localRepository> <interactiveMode>true</interactiveMode> <offline>false</offline> </settings>
Copy to Clipboard Copied! 创建以下
Secret
以复制到每个用户项目中。为增强配置性,您可以通过添加额外的标签和注解来自定义Secret
。默认情况下,Secret 会自动挂载到用户工作区。如果您不希望挂载 Secret,请明确添加以下标签来覆盖行为:controller.devfile.io/watch-secret: "false" controller.devfile.io/mount-to-devworkspace: "false"
controller.devfile.io/watch-secret: "false" controller.devfile.io/mount-to-devworkspace: "false"
Copy to Clipboard Copied! 有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret。
例 4.6. 将 Secret 复制到每个用户项目中:
kind: Secret apiVersion: v1 metadata: name: devspaces-user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/watch-secret: "false" controller.devfile.io/mount-to-devworkspace: "false" annotations: controller.devfile.io/mount-as: env stringData: ...
kind: Secret apiVersion: v1 metadata: name: devspaces-user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/watch-secret: "false" controller.devfile.io/mount-to-devworkspace: "false" annotations: controller.devfile.io/mount-as: env stringData: ...
Copy to Clipboard Copied! 例 4.7. 将 Secret 复制到每个用户项目中,并通过路径
/etc/pki/ca-trust/source/anchors
自动将trusted-certificates.crt
文件挂载到每个用户容器中:kind: Secret apiVersion: v1 metadata: name: devspaces-user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /etc/pki/ca-trust/source/anchors stringData: trusted-certificates.crt: | ...
kind: Secret apiVersion: v1 metadata: name: devspaces-user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /etc/pki/ca-trust/source/anchors stringData: trusted-certificates.crt: | ...
Copy to Clipboard Copied! 注意在工作区启动时运行
update-ca-trust
命令来导入证书。它可以手动实现,或者通过将此命令添加到 devfile 中的postStart
事件中。请参阅 在 devfile 中添加事件绑定。例 4.8. 将 Secret 复制到每个用户项目中,并作为环境变量自动挂载到每个用户容器中:
kind: Secret apiVersion: v1 metadata: name: devspaces-user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: env stringData: ENV_VAR_1: value_1 ENV_VAR_2: value_2
kind: Secret apiVersion: v1 metadata: name: devspaces-user-secret namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: env stringData: ENV_VAR_1: value_1 ENV_VAR_2: value_2
Copy to Clipboard Copied! 在下面创建
PersistentVolumeClaim
,将它复制到每个用户项目中。为增强配置,您可以通过添加额外的标签和注解来自定义
PersistentVolumeClaim
。有关其他可能的标签和注解,请参阅 自动挂载卷、configmap 和 secret。要修改
PersistentVolumeClaim
,请将其删除并在 openshift-devspaces 命名空间中创建新名称。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: devspaces-user-pvc namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config spec: ...
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: devspaces-user-pvc namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config spec: ...
Copy to Clipboard Copied! 例 4.9. 将
PersistentVolumeClaim
挂载到用户工作区:apiVersion: v1 kind: PersistentVolumeClaim metadata: name: devspaces-user-pvc namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/mount-to-devworkspace: 'true' annotations: controller.devfile.io/mount-path: /home/user/data controller.devfile.io/read-only: 'true' spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi volumeMode: Filesystem
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: devspaces-user-pvc namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config controller.devfile.io/mount-to-devworkspace: 'true' annotations: controller.devfile.io/mount-path: /home/user/data controller.devfile.io/read-only: 'true' spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi volumeMode: Filesystem
Copy to Clipboard Copied! 要使用 OpenShift Kubernetes Engine,您可以创建一个
Template
对象来复制模板中定义的所有资源。除了前面提到的
ConfigMap
、Secret
和PersistentVolumeClaim
外,Template
对象还可以包括:-
LimitRange
-
NetworkPolicy
-
ResourceQuota
-
角色
RoleBinding
apiVersion: template.openshift.io/v1 kind: Template metadata: name: devspaces-user-namespace-configurator namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config objects: ... parameters: - name: PROJECT_NAME - name: PROJECT_ADMIN_USER
apiVersion: template.openshift.io/v1 kind: Template metadata: name: devspaces-user-namespace-configurator namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config objects: ... parameters: - name: PROJECT_NAME - name: PROJECT_ADMIN_USER
Copy to Clipboard Copied! 参数是可选的
,定义可以使用哪些参数。目前,只支持PROJECT_NAME
和PROJECT_ADMIN_USER
。PROJECT_NAME
是 OpenShift Dev Spaces 命名空间的名称,而PROJECT_ADMIN_USER
是命名空间的 OpenShift Dev Spaces 用户。对象中的 namespace 名称将在同步期间替换为用户的命名空间名称。
例 4.10. 将 Kubernetes 资源复制到用户项目:
apiVersion: template.openshift.io/v1 kind: Template metadata: name: devspaces-user-namespace-configurator namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config objects: - apiVersion: v1 kind: ResourceQuota metadata: name: devspaces-user-resource-quota spec: ... - apiVersion: v1 kind: LimitRange metadata: name: devspaces-user-resource-constraint spec: ... - apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: devspaces-user-roles rules: ... - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: devspaces-user-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: devspaces-user-roles subjects: - kind: User apiGroup: rbac.authorization.k8s.io name: ${PROJECT_ADMIN_USER} parameters: - name: PROJECT_ADMIN_USER
apiVersion: template.openshift.io/v1 kind: Template metadata: name: devspaces-user-namespace-configurator namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config objects: - apiVersion: v1 kind: ResourceQuota metadata: name: devspaces-user-resource-quota spec: ... - apiVersion: v1 kind: LimitRange metadata: name: devspaces-user-resource-constraint spec: ... - apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: devspaces-user-roles rules: ... - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: devspaces-user-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: devspaces-user-roles subjects: - kind: User apiGroup: rbac.authorization.k8s.io name: ${PROJECT_ADMIN_USER} parameters: - name: PROJECT_ADMIN_USER
Copy to Clipboard Copied! 注意只有在 OpenShift 中才支持创建模板 Kubernetes 资源。
-
其他资源
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#end-user-guide:mounting-configmaps
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#end-user-guide:mounting-secrets
- https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#end-user-guide:requesting-persistent-storage-for-workspaces
- 自动挂载卷、configmap 和 secret
-
模板的 OpenShift API 参考
- 配置 OpenShift 项目创建
4.3. 配置服务器组件
4.3.1. 将 Secret 或 ConfigMap 作为文件或环境变量挂载到 Red Hat OpenShift Dev Spaces 容器中
secret 是存储敏感数据的 OpenShift 对象,例如:
- userNames
- 密码
- 身份验证令牌
采用加密的形式。
用户可以挂载包含敏感数据的 OpenShift Secret,或包含 OpenShift Dev Spaces 管理容器中的配置的 ConfigMap:
- 一个文件
- 环境变量
挂载过程使用标准的 OpenShift 挂载机制,但它需要额外的注释和标记。
4.3.1.1. 将 Secret 或 ConfigMap 作为文件挂载到 OpenShift Dev Spaces 容器中
先决条件
- 一个 Red Hat OpenShift Dev Spaces 实例。
流程
在部署 OpenShift Dev Spaces 的 OpenShift 项目中,创建一个新的 OpenShift Secret 或 ConfigMap。要创建的对象标签必须与一组标签匹配:
-
app.kubernetes.io/part-of: che.eclipse.org
-
app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
&
lt;DEPLOYMENT_NAME
> 对应于以下部署:-
devspaces-dashboard
-
devfile-registry
-
plugin-registry
devspaces
和
-
<OBJECT_KIND&
gt; 是:secret
或者
-
configmap
-
例 4.11. Example:
apiVersion: v1 kind: Secret metadata: name: custom-settings labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret ...
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 ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
配置注解值。注解必须表示将给定对象挂载为文件:
-
Che.eclipse.org/mount-as: file
- 表示对象被挂载为一个文件。 -
Che.eclipse.org/mount-path: <TARGET_PATH
>- 要提供所需的挂载路径。
-
例 4.12. Example:
apiVersion: v1 kind: Secret metadata: name: custom-data annotations: che.eclipse.org/mount-as: file che.eclipse.org/mount-path: /data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret ...
apiVersion: v1
kind: Secret
metadata:
name: custom-data
annotations:
che.eclipse.org/mount-as: file
che.eclipse.org/mount-path: /data
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
...
或者
apiVersion: v1 kind: ConfigMap metadata: name: custom-data annotations: che.eclipse.org/mount-as: file che.eclipse.org/mount-path: /data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-data
annotations:
che.eclipse.org/mount-as: file
che.eclipse.org/mount-path: /data
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
OpenShift 对象可以包含几个项目,其名称必须与挂载到容器中的所需文件名匹配。
例 4.13. Example:
apiVersion: v1 kind: Secret metadata: name: custom-data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret annotations: che.eclipse.org/mount-as: file che.eclipse.org/mount-path: /data data: ca.crt: <base64 encoded data content here>
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>
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 容器中的更改可见,请完全重新创建 Secret 或 ConfigMap 对象。
4.3.1.2. 将 Secret 或 ConfigMap 作为子路径挂载到 OpenShift Dev Spaces 容器中
先决条件
- 一个 Red Hat OpenShift Dev Spaces 实例。
流程
在部署 OpenShift Dev Spaces 的 OpenShift 项目中,创建一个新的 OpenShift Secret 或 ConfigMap。要创建的对象标签必须与一组标签匹配:
-
app.kubernetes.io/part-of: che.eclipse.org
-
app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
&
lt;DEPLOYMENT_NAME
> 对应于以下部署:-
devspaces-dashboard
-
devfile-registry
-
plugin-registry
devspaces
和
-
<OBJECT_KIND&
gt; 是:secret
或者
-
configmap
-
例 4.14. Example:
apiVersion: v1 kind: Secret metadata: name: custom-settings labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret ...
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 ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
配置注解值。注解必须表示给定对象挂载为 subPath。
-
Che.eclipse.org/mount-as: 子路径
- 表示对象被挂载为 subPath。 -
Che.eclipse.org/mount-path: <TARGET_PATH
>- 要提供所需的挂载路径。
-
例 4.15. Example:
apiVersion: v1 kind: Secret metadata: name: custom-data annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret ...
apiVersion: v1
kind: Secret
metadata:
name: custom-data
annotations:
che.eclipse.org/mount-as: subpath
che.eclipse.org/mount-path: /data
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
...
或者
apiVersion: v1 kind: ConfigMap metadata: name: custom-data annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-data
annotations:
che.eclipse.org/mount-as: subpath
che.eclipse.org/mount-path: /data
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
OpenShift 对象可以包含几个项目,它们的名称必须与挂载到容器中的文件名匹配。
例 4.16. Example:
apiVersion: v1 kind: Secret metadata: name: custom-data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /data data: ca.crt: <base64 encoded data content here>
apiVersion: v1
kind: Secret
metadata:
name: custom-data
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
annotations:
che.eclipse.org/mount-as: subpath
che.eclipse.org/mount-path: /data
data:
ca.crt: <base64 encoded data content here>
或者
apiVersion: v1 kind: ConfigMap metadata: name: custom-data labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /data data: ca.crt: <data content here>
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-data
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
annotations:
che.eclipse.org/mount-as: subpath
che.eclipse.org/mount-path: /data
data:
ca.crt: <data content here>
这会导致名为 ca.crt
的文件被挂载到 OpenShift Dev Spaces 容器的 /data
路径中。
要在 OpenShift Dev Spaces 容器中进行更改,请完全重新创建 Secret 或 ConfigMap 对象。
4.3.1.3. 将 Secret 或 ConfigMap 作为环境变量挂载到 OpenShift Dev Spaces 容器中
先决条件
- 一个 Red Hat OpenShift Dev Spaces 实例。
流程
在部署 OpenShift Dev Spaces 的 OpenShift 项目中,创建一个新的 OpenShift Secret 或 ConfigMap。要创建的对象标签必须与一组标签匹配:
-
app.kubernetes.io/part-of: che.eclipse.org
-
app.kubernetes.io/component: <DEPLOYMENT_NAME>-<OBJECT_KIND>
&
lt;DEPLOYMENT_NAME
> 对应于以下部署:-
devspaces-dashboard
-
devfile-registry
-
plugin-registry
devspaces
和
-
<OBJECT_KIND&
gt; 是:secret
或者
-
configmap
-
例 4.17. Example:
apiVersion: v1 kind: Secret metadata: name: custom-settings labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret ...
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 ...
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
...
配置注解值。注解必须表示给定对象挂载为环境变量:
-
Che.eclipse.org/mount-as: env
- 表示对象已挂载为环境变量 -
Che.eclipse.org/env-name : <FOO_ENV
>- 提供环境变量名称,这是挂载对象键值所必需的
-
例 4.18. Example:
apiVersion: v1 kind: Secret metadata: name: custom-settings annotations: che.eclipse.org/env-name: FOO_ENV che.eclipse.org/mount-as: env labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret data: mykey: myvalue
apiVersion: v1
kind: Secret
metadata:
name: custom-settings
annotations:
che.eclipse.org/env-name: FOO_ENV
che.eclipse.org/mount-as: env
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
data:
mykey: myvalue
或者
apiVersion: v1 kind: ConfigMap metadata: name: custom-settings annotations: che.eclipse.org/env-name: FOO_ENV che.eclipse.org/mount-as: env labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap data: mykey: myvalue
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
annotations:
che.eclipse.org/env-name: FOO_ENV
che.eclipse.org/mount-as: env
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
data:
mykey: myvalue
这会生成两个环境变量:
-
FOO_ENV
-
myvalue
被置备到 OpenShift Dev Spaces 容器中。
如果对象提供多个数据项,则必须为每个数据键提供环境变量名称,如下所示:
例 4.19. Example:
apiVersion: v1 kind: Secret metadata: name: custom-settings annotations: che.eclipse.org/mount-as: env che.eclipse.org/mykey_env-name: FOO_ENV che.eclipse.org/otherkey_env-name: OTHER_ENV labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-secret stringData: mykey: <data_content_here> otherkey: <data_content_here>
apiVersion: v1
kind: Secret
metadata:
name: custom-settings
annotations:
che.eclipse.org/mount-as: env
che.eclipse.org/mykey_env-name: FOO_ENV
che.eclipse.org/otherkey_env-name: OTHER_ENV
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-secret
stringData:
mykey: <data_content_here>
otherkey: <data_content_here>
或者
apiVersion: v1 kind: ConfigMap metadata: name: custom-settings annotations: che.eclipse.org/mount-as: env che.eclipse.org/mykey_env-name: FOO_ENV che.eclipse.org/otherkey_env-name: OTHER_ENV labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: devspaces-configmap data: mykey: <data content here> otherkey: <data content here>
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-settings
annotations:
che.eclipse.org/mount-as: env
che.eclipse.org/mykey_env-name: FOO_ENV
che.eclipse.org/otherkey_env-name: OTHER_ENV
labels:
app.kubernetes.io/part-of: che.eclipse.org
app.kubernetes.io/component: devspaces-configmap
data:
mykey: <data content here>
otherkey: <data content here>
这会生成两个环境变量:
-
FOO_ENV
-
OTHER_ENV
被置备为 OpenShift Dev Spaces 容器。
OpenShift 对象中注解名称的最大长度为 63 个字符,其中 9 个字符作为前缀被保留,以 /
结尾。这充当可用于对象的密钥的最大长度的限制。
要使 OpenShift Dev Spaces 容器中的更改可见,请完全重新创建 Secret 或 ConfigMap 对象。
4.3.2. Dev Spaces 服务器的高级配置选项
以下部分介绍了 OpenShift Dev Spaces 服务器组件的高级部署和配置方法。
4.3.2.1. 了解 OpenShift Dev Spaces 服务器高级配置
以下部分介绍了 OpenShift Dev Spaces 服务器组件高级配置方法。
高级配置需要:
-
从标准
CheCluster
自定义资源字段添加 Operator 自动生成的环境变量。 -
从标准
CheCluster
自定义资源字段覆盖 Operator 自动生成的属性。
customCheProperties
字段是 CheCluster
自定义资源服务器设置的一部分,包含要应用到 OpenShift Dev Spaces 服务器组件的附加环境变量映射。
例 4.20. 覆盖工作区的默认内存限值
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。apiVersion: org.eclipse.che/v2 kind: CheCluster spec: components: cheServer: extraProperties: CHE_LOGS_APPENDERS_IMPL: json
apiVersion: org.eclipse.che/v2 kind: CheCluster spec: components: cheServer: extraProperties: CHE_LOGS_APPENDERS_IMPL: json
Copy to Clipboard Copied!
以前的 OpenShift Dev Spaces Operator 版本有一个名为 custom
的 ConfigMap 来履行此角色。如果 OpenShift Dev Spaces Operator 找到带有自定义 configMap
的 configMap,它会将它包含的数据添加到
字段中,重新部署 OpenShift Dev Spaces,并删除 custom
CheProperties自定义
configMap
。
4.4. 配置自动扩展
了解 Red Hat OpenShift Dev Spaces 自动扩展的不同方面。
4.4.1. 为 Red Hat OpenShift Dev Spaces 容器配置副本数
要使用 Kubernetes HorizontalPodAutoscaler
(HPA)为 OpenShift Dev Spaces 操作对象配置副本数,您可以为部署定义 HPA
资源。HPA
根据指定指标动态调整副本数量。
流程
为部署创建
HPA
资源,指定目标指标和所需的副本数。apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: scaler namespace: openshift-devspaces spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: <deployment_name> ...
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: scaler namespace: openshift-devspaces spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: <deployment_name>
1 ...
Copy to Clipboard Copied! - 1
- &
lt;deployment_name
> 对应于以下部署:-
devspaces
-
che-gateway
-
devspaces-dashboard
-
plugin-registry
-
devfile-registry
-
例 4.21. 为 devspaces 部署创建一个 HorizontalPodAutoscaler
:
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: devspaces-scaler namespace: openshift-devspaces spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: devspaces minReplicas: 2 maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 75
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: devspaces-scaler
namespace: openshift-devspaces
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: devspaces
minReplicas: 2
maxReplicas: 5
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 75
在本例中,HPA 以名为 devspaces 的 Deployment 为目标,至少为 2 个副本,最多 5 个副本并根据 CPU 使用率进行扩展。
其他资源
4.4.2. 配置机器自动扩展
如果您将集群配置为根据资源需求调整节点数量,则需要额外的配置来维护 OpenShift Dev Spaces 工作区的无缝操作。
当自动扩展添加或删除节点时,工作区需要特殊考虑。
当自动扩展添加新节点时,工作空间启动所需的时间可能比通常要长,直到节点置备完成为止。
相反,当节点被删除时,运行工作区 pod 的节点不应被自动扩展驱除,以避免在使用工作区时造成中断,并可能会丢失任何未保存的数据。
4.4.2.1. 当自动扩展添加新节点时
您需要对 OpenShift Dev Spaces 安装进行额外的配置,以确保在添加新节点时正确工作空间启动。
流程
在 CheCluster 自定义资源中,设置以下字段,以便在自动扩展器置备新节点时允许正确的工作区启动。
spec: devEnvironments: startTimeoutSeconds: 600 ignoredUnrecoverableEvents: - FailedScheduling
spec: devEnvironments: startTimeoutSeconds: 600
1 ignoredUnrecoverableEvents:
2 - FailedScheduling
Copy to Clipboard Copied!
4.4.2.2. 当自动扩展删除节点时
要防止工作区 pod 在自动扩展需要删除节点时被驱除,请将 "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
注解添加到每个工作区 pod。
流程
在 CheCluster 自定义资源中,在
spec.devEnvironments.workspacesPodAnnotations
字段中添加cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
注解。spec: devEnvironments: workspacesPodAnnotations: cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
spec: devEnvironments: workspacesPodAnnotations: cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
Copy to Clipboard Copied!
验证步骤
启动工作区,并验证工作区 pod 是否包含
cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
注解。oc get pod <workspace_pod_name> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/safe-to-evict}'
$ oc get pod <workspace_pod_name> -o jsonpath='{.metadata.annotations.cluster-autoscaler\.kubernetes\.io/safe-to-evict}' false
Copy to Clipboard Copied!
4.5. 在全局配置工作区
本节描述了管理员如何全局配置工作区。
4.5.1. 限制用户可以保留的工作区数
默认情况下,用户可以在仪表板中保留无限数量的工作区,但您可以限制这个数量来减少对集群的需求。
此配置是 CheCluster
自定义资源的一部分:
spec: devEnvironments: maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
spec:
devEnvironments:
maxNumberOfWorkspacesPerUser: <kept_workspaces_limit>
- 1
- 设置每个用户的最大工作区数。默认值为
-1
,允许用户保留无限数量的工作区。使用正整数来设置每个用户的最大工作区数。
流程
获取 OpenShift Dev Spaces 命名空间的名称。默认为
openshift-devspaces
。oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
Copy to Clipboard Copied! 配置
maxNumberOfWorkspacesPerUser
:oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'
$ oc patch checluster/devspaces -n openshift-devspaces \
1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfWorkspacesPerUser": <kept_workspaces_limit>}}}'
2 Copy to Clipboard Copied!
4.5.2. 限制所有用户可以同时运行的工作区数
默认情况下,所有用户都可以运行无限数量的工作区。您可以限制所有用户可以同时运行的工作区数量。此配置是 CheCluster
自定义资源的一部分:
spec: devEnvironments: maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>
spec:
devEnvironments:
maxNumberOfRunningWorkspacesPerCluster: <running_workspaces_limit>
- 1
- 在整个 Kubernetes 集群中同时运行的最大工作区数。这适用于系统中的所有用户。如果值设为 -1,这表示运行工作区的数量没有限制。
流程
配置
maxNumberOfRunningWorkspacesPerCluster
:oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'
oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerCluster": <running_workspaces_limit>}}}'
1 Copy to Clipboard Copied! - 1
- 您选择的 <
running_workspaces_limit>
值。
4.5.3. 允许用户同时运行多个工作区
默认情况下,用户可以一次只运行一个工作区。您可以让用户同时运行多个工作区。
如果使用默认存储方法,如果用户在多节点集群中的节点间分布 pod,则并发运行工作区时可能会遇到问题。从每个用户 通用
存储策略切换到 per-workspace
存储策略,或 使用临时存储
类型可能会避免或解决这些问题。
此配置是 CheCluster
自定义资源的一部分:
spec: devEnvironments: maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
spec:
devEnvironments:
maxNumberOfRunningWorkspacesPerUser: <running_workspaces_limit>
- 1
- 设置每个用户同时运行工作区的最大数量。通过
-1
值,用户可以运行无限数量的工作区。默认值为1
。
流程
获取 OpenShift Dev Spaces 命名空间的名称。默认为
openshift-devspaces
。oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
$ oc get checluster --all-namespaces \ -o=jsonpath="{.items[*].metadata.namespace}"
Copy to Clipboard Copied! 配置
maxNumberOfRunningWorkspacesPerUser
:oc patch checluster/devspaces -n openshift-devspaces \ --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'
$ oc patch checluster/devspaces -n openshift-devspaces \
1 --type='merge' -p \ '{"spec":{"devEnvironments":{"maxNumberOfRunningWorkspacesPerUser": <running_workspaces_limit>}}}'
2 Copy to Clipboard Copied!
4.5.4. 带有自签名证书的 Git
您可以配置 OpenShift Dev Spaces,以支持使用自签名证书的 Git 供应商上的操作。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。 - Git 版本 2 或更高版本
流程
创建一个新的 ConfigMap,其中包含 Git 服务器的详情:
oc create configmap che-git-self-signed-cert \ --from-file=ca.crt=<path_to_certificate> \ --from-literal=githost=<git_server_url> -n openshift-devspaces
$ oc create configmap che-git-self-signed-cert \ --from-file=ca.crt=<path_to_certificate> \
1 --from-literal=githost=<git_server_url> -n openshift-devspaces
2 Copy to Clipboard Copied! - 1
- 自签名证书的路径。
- 2
- 指定 Git 服务器 URL 的可选参数,如
https://git.example.com:8443
。如果省略时,自签名证书用于通过 HTTPS 用于所有存储库。
注意-
证书文件通常存储为 Base64 ASCII 文件,例如:
.pem
,.crt
,.ca-bundle
.保存证书文件的所有ConfigMap
都应使用 Base64 ASCII 证书而不是二进制数据证书。 -
需要信任证书链。如果
ca.crt
由证书颁发机构(CA)签名,则必须将 CA 证书包含在ca.crt
文件中。
在 ConfigMap 中添加所需的标签:
oc label configmap che-git-self-signed-cert \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
$ oc label configmap che-git-self-signed-cert \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
Copy to Clipboard Copied! 配置 OpenShift Dev Spaces 操作对象,将自签名证书用于 Git 存储库。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
spec: devEnvironments: trustedCerts: gitTrustedCertsConfigMapName: che-git-self-signed-cert
Copy to Clipboard Copied!
验证步骤
创建并启动新的工作区。工作区使用的每个容器都会挂载一个特殊卷,其中包含带有自签名证书的文件。容器的
/etc/gitconfig
文件包含有关 Git 服务器主机(its URL)的信息,以及http
部分中证书的路径(请参阅 Git 文档有关 git-config)。例 4.22.
/etc/gitconfig
文件的内容[http "https://10.33.177.118:3000"] sslCAInfo = /etc/config/che-git-tls-creds/certificate
[http "https://10.33.177.118:3000"] sslCAInfo = /etc/config/che-git-tls-creds/certificate
Copy to Clipboard Copied!
4.5.5. 配置工作区 nodeSelector
本节论述了如何为 OpenShift Dev Spaces 工作区的 Pod 配置 nodeSelector
。
流程
使用 NodeSelector
OpenShift Dev Spaces 使用
CheCluster
自定义资源来配置nodeSelector
:spec: devEnvironments: nodeSelector: key: value
spec: devEnvironments: nodeSelector: key: value
Copy to Clipboard Copied! 本节必须包含 每个节点标签 的一组
key=value
对,以组成 nodeSelector 规则。使用 Taints 和 Tolerations
这的工作方式与
nodeSelector
相反。您可以指定 Pod 无法调度到哪些节点上,而不指定将 Pod 调度到哪些节点上。如需更多信息,请参阅 :https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration。OpenShift Dev Spaces 使用
CheCluster
自定义资源来配置容限
:spec: devEnvironments: tolerations: - effect: NoSchedule key: key value: value operator: Equal
spec: devEnvironments: tolerations: - effect: NoSchedule key: key value: value operator: Equal
Copy to Clipboard Copied!
必须在 OpenShift Dev Spaces 安装过程中配置 nodeSelector
。这可防止现有工作区因为现有工作区 PVC 和 Pod 被调度到不同区中造成的卷关联性冲突而运行失败。
为了避免在大型多区集群上的不同区中调度 Pod 和 PVC,请创建一个额外的 StorageClass
对象(请注意 allowedTopologies
字段),它将协调 PVC 创建过程。
通过 CheCluster
自定义资源将这个新创建的 StorageClass
的名称传递给 OpenShift Dev Spaces。如需更多信息,请参阅:第 4.9.1 节 “配置存储类”。
4.5.6. 为云环境配置允许的 URL
允许 URL 在保护云环境(CDE)启动方面扮演重要角色,确保它们只能从授权来源启动。通过使用通配符支持,如 *
,组织可以实施灵活的 URL 模式,允许跨域中的不同路径启动动态和安全 CDE。
配置允许的源:
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p \ '{ "spec": { "devEnvironments": { "allowedSources": { "urls": ["url_1", "url_2"] } } } }'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p \ '{ "spec": { "devEnvironments": { "allowedSources": { "urls": ["url_1", "url_2"]
1 } } } }'
Copy to Clipboard Copied! - 1
- 用于启动云环境(CDE)的批准 URL 数组。CDE 只能从这些 URL 启动。URL 中支持通配符
*
。例如:https://example.com/*
允许从example.com
中的任何路径启动 CDE。
4.6. 缓存镜像以便更快地启动工作区
要提高 OpenShift Dev Spaces 工作区的开始时间性能,请使用 Image Puller,它是一个 OpenShift Dev Spaces 组件,可用于预拉取 OpenShift 集群。
Image Puller 是一个额外的 OpenShift 部署,它会创建一个 DaemonSet,可在每个节点上预拉取相关的 OpenShift Dev Spaces 工作区镜像。这些镜像在 OpenShift Dev Spaces 工作区启动时已经可用,因此改进了工作空间开始时间。
安装 Kubernetes Image Puller
配置 Kubernetes Image Puller
4.6.1. 安装 Kubernetes Image Puller
按照以下说明,为不同的用例安装 Kubernetes Image Puller。
4.6.1.1. 安装 Kubernetes Image Puller
4.6.1.2. 使用 CLI 在 OpenShift 上安装 Image Puller
您可以使用 OpenShift oc
管理工具在 OpenShift 上安装 Kubernetes Image Puller。
如果使用 oc
CLI 安装 ImagePuller,则无法通过 CheCluster
自定义资源进行配置。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。
流程
- 按照 doc 收集要拉取的相关容器镜像列表: 第 4.6.3 节 “检索 Kubernetes Image Puller 的默认镜像列表”
定义内存请求和限值参数,以确保拉取容器,并且平台有足够的内存来运行。
当定义
CACHING_MEMORY_REQUEST
或CACHING_MEMORY_LIMIT
的最小值时,请考虑运行每个容器镜像所需的内存量。在定义
CACHING_MEMORY_REQUEST
或CACHING_MEMORY_LIMIT
的 maximal 值时,请考虑分配给集群中 DaemonSet Pod 的总内存:(memory limit) * (number of images) * (number of nodes in the cluster)
(memory limit) * (number of images) * (number of nodes in the cluster)
Copy to Clipboard Copied! 在 20 个节点中拉取 5 个镜像,容器内存限制为
20Mi
需要2000Mi
内存。克隆 Image Puller 存储库,并在包含 OpenShift 模板的目录中:
git clone https://github.com/che-incubator/kubernetes-image-puller cd kubernetes-image-puller/deploy/openshift
git clone https://github.com/che-incubator/kubernetes-image-puller cd kubernetes-image-puller/deploy/openshift
Copy to Clipboard Copied! 使用以下参数配置
app.yaml
、configmap.yaml
和serviceaccount.yaml
OpenShift 模板:表 4.37. app.yaml中的 Image Puller OpenShift 模板参数 值 使用方法 默认值 DEPLOYMENT_NAME
ConfigMap 中的
DEPLOYMENT_NAME
的值kubernetes-image-puller
IMAGE
用于
kubernetes-image-puller
部署的镜像registry.redhat.io/devspaces/imagepuller-rhel8
IMAGE_TAG
要拉取的镜像标签
latest
SERVICEACCOUNT_NAME
部署创建和使用的 ServiceAccount 的名称
kubernetes-image-puller
表 4.38. configmap.yaml 中的 Image Puller OpenShift 模板参数 值 使用方法 默认值 CACHING_CPU_LIMIT
ConfigMap 中的
CACHING_CPU_LIMIT
的值.2
CACHING_CPU_REQUEST
ConfigMap 中的
CACHING_CPU_REQUEST
的值.05
CACHE_INTERVAL_HOURS
ConfigMap 中的
CACHING_INTERVAL_HOURS
的值"1"
CACHING_MEMORY_LIMIT
ConfigMap 中的
CACHING_MEMORY_LIMIT
的值"20Mi"
CACHE_MEMORY_REQUEST
ConfigMap 中的
CACHING_MEMORY_REQUEST
的值"10Mi"
DAEMONSET_NAME
ConfigMap 中的
DAEMONSET_NAME
的值kubernetes-image-puller
DEPLOYMENT_NAME
ConfigMap 中的
DEPLOYMENT_NAME
的值kubernetes-image-puller
镜像
ConfigMap 中的
IMAGES
值{}
NAMESPACE
ConfigMap 中的
NAMESPACE
值k8s-image-puller
NODE_SELECTOR
ConfigMap 中的
NODE_SELECTOR
的值"{}"
表 4.39. serviceaccount.yaml 中的 Image Puller OpenShift 模板参数 值 使用方法 默认值 SERVICEACCOUNT_NAME
部署创建和使用的 ServiceAccount 的名称
kubernetes-image-puller
KIP_IMAGE
从中复制 sleep 二进制文件的镜像拉取器镜像
registry.redhat.io/devspaces/imagepuller-rhel8:latest
创建一个 OpenShift 项目来托管 Image Puller:
oc new-project <k8s-image-puller>
oc new-project <k8s-image-puller>
Copy to Clipboard Copied! 处理并应用模板来安装 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 -
oc process -f serviceaccount.yaml | oc apply -f - oc process -f configmap.yaml | oc apply -f - oc process -f app.yaml | oc apply -f -
Copy to Clipboard Copied!
验证步骤
验证是否存在 < kubernetes-image-puller> 部署和一个 < kubernetes-image-puller> DaemonSet。DaemonSet 需要为集群中的每个节点都有一个 Pod:
oc get deployment,daemonset,pod --namespace <k8s-image-puller>
oc get deployment,daemonset,pod --namespace <k8s-image-puller>
Copy to Clipboard Copied! 验证 < kubernetes-image-puller >
ConfigMap
的值。oc get configmap <kubernetes-image-puller> --output yaml
oc get configmap <kubernetes-image-puller> --output yaml
Copy to Clipboard Copied!
4.6.1.3. 使用 Web 控制台在 OpenShift 上安装 Image Puller
您可以使用 OpenShift Web 控制台在 OpenShift 上安装社区支持的 Kubernetes Image Puller Operator。
先决条件
- 集群管理员的 OpenShift Web 控制台会话。请参阅 访问 Web 控制台。
流程
- 安装社区支持的 Kubernetes Image Puller Operator。请参阅使用 Web 控制台从 OperatorHub 安装。
-
从社区支持的
Kubernetes Image Puller
Operator 创建一个 kubernetes-image-puller KubernetesImagePuller 操作对象。请参阅 从已安装的 Operator 创建应用程序。
4.6.2. 配置 Kubernetes Image Puller
本节包含为不同用例配置 Kubernetes Image Puller 的说明。
4.6.2.1. 配置 Kubernetes Image Puller
4.6.2.2. 将 Image Puller 配置为预先拉取默认 Dev Spaces 镜像
您可以将 Kubernetes Image Puller 配置为预先拉取默认的 OpenShift Dev Spaces 镜像。Red Hat OpenShift Dev Spaces operator 将控制镜像列表来预拉取,并在 OpenShift Dev Spaces 升级过程中自动更新它们。
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
- Image Puller 安装在 Kubernetes 集群上。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
将 Image Puller 配置为预拉取 OpenShift Dev Spaces 镜像。
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ --patch '{ "spec": { "components": { "imagePuller": { "enable": true } } } }'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ --patch '{ "spec": { "components": { "imagePuller": { "enable": true } } } }'
Copy to Clipboard Copied!
4.6.2.3. 配置 Image Puller 以预拉取自定义镜像
您可以将 Kubernetes Image Puller 配置为预拉取自定义镜像。
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
- Image Puller 安装在 Kubernetes 集群上。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
将 Image Puller 配置为预先拉取自定义镜像。
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ --patch '{ "spec": { "components": { "imagePuller": { "enable": true, "spec": { "images": "NAME-1=IMAGE-1;NAME-2=IMAGE-2" } } } } }'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ --patch '{ "spec": { "components": { "imagePuller": { "enable": true, "spec": { "images": "NAME-1=IMAGE-1;NAME-2=IMAGE-2"
1 } } } } }'
Copy to Clipboard Copied! - 1
- 分号分隔的镜像列表
4.6.2.4. 配置 Image Puller 以预拉取额外镜像
您可以将 Kubernetes Image Puller 配置为预拉取额外的 OpenShift Dev Spaces 镜像。
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
- Image Puller 安装在 Kubernetes 集群上。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
创建
k8s-image-puller
命名空间:oc create namespace k8s-image-puller
oc create namespace k8s-image-puller
Copy to Clipboard Copied! 创建
KubernetesImagePuller
自定义资源:oc apply -f - <<EOF apiVersion: che.eclipse.org/v1alpha1 kind: KubernetesImagePuller metadata: name: k8s-image-puller-images namespace: k8s-image-puller spec: images: "__NAME-1__=__IMAGE-1__;__NAME-2__=__IMAGE-2__" EOF
oc apply -f - <<EOF apiVersion: che.eclipse.org/v1alpha1 kind: KubernetesImagePuller metadata: name: k8s-image-puller-images namespace: k8s-image-puller spec: images: "__NAME-1__=__IMAGE-1__;__NAME-2__=__IMAGE-2__"
1 EOF
Copy to Clipboard Copied! - 1
- 分号分隔的镜像列表
4.6.3. 检索 Kubernetes Image Puller 的默认镜像列表
了解如何检索 Kubernetes Image Puller 使用的默认镜像列表。这对希望检查并配置 Image Puller 的管理员很有用,使其提前只使用这些镜像的子集。
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Kubernetes 集群上运行。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
查找部署 OpenShift Dev Spaces Operator 的命名空间:
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
Copy to Clipboard Copied! 查找 Image Puller 预先拉取的镜像:
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- cat /tmp/external_images.txt
Copy to Clipboard Copied!
4.7. 配置可观察性
要配置 OpenShift Dev Spaces 可观察性功能,请参阅:
4.7.1. Woopra 遥测插件
Woopra Telemetry 插件是 一个插件,用于将遥测从 Red Hat OpenShift Dev Spaces 安装发送到 Segment 和 Woopra。此插件 由红帽托管的 Eclipse Che 使用,但任何 Red Hat OpenShift Dev Spaces 部署都可以利用此插件。有效的 Woopra 域和 Segment Write 键以外的依赖项没有。插件的 devfile v2 ,plugin.yaml,有四个可传递给插件的环境变量:
-
WOOPRA_DOMAIN
- 将事件发送到的 Woopra 域。 -
SEGMENT_WRITE_KEY
- 将事件发送到 Segment 和 Woopra 的写入密钥。 -
WOOPRA_DOMAIN_ENDPOINT
- 如果您不希望直接传递 Woopra 域,则该插件会从返回 Woopra 域的提供的 HTTP 端点中获取它。 -
SEGMENT_WRITE_KEY_ENDPOINT
- 如果您不希望直接传递 Segment 写键,则该插件会从返回分段写入键的提供的 HTTP 端点中获取它。
在 Red Hat OpenShift Dev Spaces 安装中启用 Woopra 插件:
流程
使用正确设置环境变量将
plugin.yaml
devfile v2 文件部署到 HTTP 服务器。配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next plugins: - 'https://your-web-server/plugin.yaml'
spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next
1 plugins:
2 - 'https://your-web-server/plugin.yaml'
Copy to Clipboard Copied!
4.7.2. 创建遥测插件
本节演示了如何创建扩展 AbstractAnalyticsManager
的 AnalyticsManager
类并实现以下方法:
-
isEnabled ()
- 确定遥测后端是否正常工作。这可能意味着始终返回true
,或者具有更复杂的检查,例如,当缺少连接属性时返回false
。 -
destroy ()
- cleanup 方法,在关闭遥测后端前运行。此方法发送WORKSPACE_STOPPED
事件。 -
onActivity ()
- 表示给定用户仍然发生一些活动。这主要用于发送WORKSPACE_INACTIVE
事件。 -
onEvent ()
- 将遥测事件提交到遥测服务器,如WORKSPACE_USED
或WORKSPACE_STARTED
。 -
increaseDuration ()
- 增加了当前事件的持续时间,而不是在少量时间内发送多个事件。
以下部分涵盖了:
- 创建遥测服务器以将事件回显到标准输出。
- 扩展 OpenShift Dev Spaces 遥测客户端并实施用户的自定义后端。
-
创建代表自定义后端的 Dev Workspace 插件的
plugin.yaml
文件。 -
通过从
CheCluster
自定义资源设置workspacesDefaultPlugins
属性来指定自定义插件到 OpenShift Dev Spaces 的位置。
4.7.2.1. 开始使用
本文档描述了扩展 OpenShift Dev Spaces 遥测系统以与自定义后端通信所需的步骤:
- 创建接收事件的服务器进程
- 扩展 OpenShift Dev Spaces 库,以创建向服务器发送事件的后端
- 在容器中打包遥测后端并将其部署到镜像 registry
- 为后端添加插件,并指示 OpenShift Dev Spaces 在 Dev Workspaces 中加载插件
此处 提供了遥测后端的完整示例。
4.7.2.2. 创建接收事件的服务器
出于演示目的,本例演示了如何创建从我们的遥测插件接收事件的服务器并将其写入标准输出。
对于生产用例,请考虑与第三方遥测系统集成(例如,Segment、Woopra),而不是创建自己的遥测服务器。在这种情况下,使用供应商的 API 将事件从自定义后端发送到其系统。
以下 Go 代码在端口 8080
上启动服务器,并将事件写入标准输出:
例 4.23. main.go
package main import ( "io/ioutil" "net/http" "go.uber.org/zap" ) var logger *zap.SugaredLogger func event(w http.ResponseWriter, req *http.Request) { switch req.Method { case "GET": logger.Info("GET /event") case "POST": logger.Info("POST /event") } body, err := req.GetBody() if err != nil { logger.With("err", err).Info("error getting body") return } responseBody, err := ioutil.ReadAll(body) if err != nil { logger.With("error", err).Info("error reading response body") return } logger.With("body", string(responseBody)).Info("got event") } func activity(w http.ResponseWriter, req *http.Request) { switch req.Method { case "GET": logger.Info("GET /activity, doing nothing") case "POST": logger.Info("POST /activity") body, err := req.GetBody() if err != nil { logger.With("error", err).Info("error getting body") return } responseBody, err := ioutil.ReadAll(body) if err != nil { logger.With("error", err).Info("error reading response body") return } logger.With("body", string(responseBody)).Info("got activity") } } func main() { log, _ := zap.NewProduction() logger = log.Sugar() http.HandleFunc("/event", event) http.HandleFunc("/activity", activity) logger.Info("Added Handlers") logger.Info("Starting to serve") http.ListenAndServe(":8080", nil) }
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
$ 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.yaml
和 manifest_with_route
都包含 Deployment 和 Service 的定义。前者还定义了 Kubernetes Ingress,后者则定义了 OpenShift 路由。
在清单文件中,替换 image
和 host
字段,以匹配您推送的镜像和 OpenShift 集群的公共主机名。然后运行:
kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
$ kubectl apply -f manifest_with_[ingress|route].yaml -n openshift-devspaces
4.7.2.3. 创建后端项目
为了在开发时获得快速反馈,建议在 Dev Workspace 内进行开发。这样,您可以在集群中运行应用程序,并从前端 telemetry 插件接收事件。
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
mvn io.quarkus:quarkus-maven-plugin:2.7.1.Final:create \ -DprojectGroupId=mygroup -DprojectArtifactId=devworkspace-telemetry-example-plugin \ -DprojectVersion=1.0.0-SNAPSHOT
Copy to Clipboard Copied! -
删除
src/main/java/mygroup
和src/test/java/mygroup
下的文件。 -
如需最新版本,以及 Maven 协调
后端基础
,请参阅 GitHub 软件包。 将以下依赖项添加到
pom.xml
中:例 4.24.
pom.xml
<!-- Required --> <dependency> <groupId>org.eclipse.che.incubator.workspace-telemetry</groupId> <artifactId>backend-base</artifactId> <version>LATEST VERSION FROM PREVIOUS STEP</version> </dependency> <!-- Used to make http requests to the telemetry server --> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-rest-client</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-rest-client-jackson</artifactId> </dependency>
<!-- Required --> <dependency> <groupId>org.eclipse.che.incubator.workspace-telemetry</groupId> <artifactId>backend-base</artifactId> <version>LATEST VERSION FROM PREVIOUS STEP</version> </dependency> <!-- Used to make http requests to the telemetry server --> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-rest-client</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-rest-client-jackson</artifactId> </dependency>
Copy to Clipboard Copied! -
使用
read:packages
权限创建一个个人访问令牌,从 GitHub 软件包下载org.eclipse.che.incubator.workspace-telemetry:backend-base
依赖项。 在
~/.m2/settings.xml
文件中添加您的 GitHub 用户名、个人访问令牌和che-incubator
存储库详情:例 4.25.
settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>che-incubator</id> <username>YOUR GITHUB USERNAME</username> <password>YOUR GITHUB TOKEN</password> </server> </servers> <profiles> <profile> <id>github</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>central</id> <url>https://repo1.maven.org/maven2</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>false</enabled></snapshots> </repository> <repository> <id>che-incubator</id> <url>https://maven.pkg.github.com/che-incubator/che-workspace-telemetry-client</url> </repository> </repositories> </profile> </profiles> </settings>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>che-incubator</id> <username>YOUR GITHUB USERNAME</username> <password>YOUR GITHUB TOKEN</password> </server> </servers> <profiles> <profile> <id>github</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>central</id> <url>https://repo1.maven.org/maven2</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>false</enabled></snapshots> </repository> <repository> <id>che-incubator</id> <url>https://maven.pkg.github.com/che-incubator/che-workspace-telemetry-client</url> </repository> </repositories> </profile> </profiles> </settings>
Copy to Clipboard Copied!
4.7.2.4. 创建 AnalyticsManager 的具体实施并添加专用逻辑
在 src/main/java/mygroup
下创建两个文件:
-
MainConfiguration.java
- 包含提供给AnalyticsManager
的配置。 -
AnalyticsManager.java
- 包含特定于遥测系统的逻辑。
例 4.26. MainConfiguration.java
package org.my.group; import java.util.Optional; import javax.enterprise.context.Dependent; import javax.enterprise.inject.Alternative; import org.eclipse.che.incubator.workspace.telemetry.base.BaseConfiguration; import org.eclipse.microprofile.config.inject.ConfigProperty; @Dependent @Alternative public class MainConfiguration extends BaseConfiguration { @ConfigProperty(name = "welcome.message") Optional<String> welcomeMessage; }
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")
Optional<String> welcomeMessage;
}
- 1
- MicroProfile 配置注释用于注入
welcome.message
配置。
有关如何设置特定于您的后端的配置属性的更多详细信息,请参阅 Quarkus 配置参考指南。
例 4.27. AnalyticsManager.java
package org.my.group; import java.util.HashMap; import java.util.Map; import javax.enterprise.context.Dependent; import javax.enterprise.inject.Alternative; import javax.inject.Inject; import org.eclipse.che.incubator.workspace.telemetry.base.AbstractAnalyticsManager; import org.eclipse.che.incubator.workspace.telemetry.base.AnalyticsEvent; import org.eclipse.che.incubator.workspace.telemetry.finder.DevWorkspaceFinder; import org.eclipse.che.incubator.workspace.telemetry.finder.UsernameFinder; import org.eclipse.microprofile.rest.client.inject.RestClient; import org.slf4j.Logger; import static org.slf4j.LoggerFactory.getLogger; @Dependent @Alternative public class AnalyticsManager extends AbstractAnalyticsManager { private static final Logger LOG = getLogger(AbstractAnalyticsManager.class); public AnalyticsManager(MainConfiguration mainConfiguration, DevWorkspaceFinder devworkspaceFinder, UsernameFinder usernameFinder) { super(mainConfiguration, devworkspaceFinder, usernameFinder); mainConfiguration.welcomeMessage.ifPresentOrElse( (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); } @Override public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { } @Override public void onActivity() {} }
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(
(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);
}
@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) { }
@Override
public void onActivity() {}
}
由于 org.my.group.AnalyticsManager
和 org.my.group.MainConfiguration
是替代 Bean,因此请使用 src/main/resources/application.properties
中的 quarkus.arc.selected-alternatives
属性来指定它们。
例 4.28. application.properties
quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
quarkus.arc.selected-alternatives=MainConfiguration,AnalyticsManager
4.7.2.5. 在 Dev Workspace 中运行应用程序
在 Dev Workspace 中设置
DEVWORKSPACE_TELEMETRY_BACKEND_PORT
环境变量。在这里,值设为4167
。spec: template: attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167'
spec: template: attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167'
Copy to Clipboard Copied! - 从 Red Hat OpenShift Dev Spaces 仪表板重启 Dev Workspace。
在 Dev Workspace 的终端窗口中运行以下命令以启动应用。使用-
settings
标志指定包含 GitHub 访问令牌的settings.xml
文件的位置的路径。mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
$ mvn --settings=settings.xml quarkus:dev -Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}
Copy to Clipboard Copied! 应用程序现在通过前端插件的端口
4167
接收遥测事件。
验证步骤
验证以下输出是否已记录:
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]
INFO [org.ecl.che.inc.AnalyticsManager] (Quarkus Main Thread) No welcome message provided INFO [io.quarkus] (Quarkus Main Thread) devworkspace-telemetry-example-plugin 1.0.0-SNAPSHOT on JVM (powered by Quarkus 2.7.2.Final) started in 0.323s. Listening on: http://localhost:4167 INFO [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated. INFO [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, kubernetes-client, rest-client, rest-client-jackson, resteasy, resteasy-jsonb, smallrye-context-propagation, smallrye-openapi, swagger-ui, vertx]
Copy to Clipboard Copied! 要验证
AnalyticsManager
的onEvent ()
方法是否从前端插件接收事件,请按 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
INFO [io.qua.dep.dev.RuntimeUpdatesProcessor] (Aesh InputStream Reader) Live reload disabled INFO [org.ecl.che.inc.AnalyticsManager] (executor-thread-2) The received event is: Edit Workspace File in Che
Copy to Clipboard Copied!
4.7.2.6. 实现 isEnabled ()
例如,此方法会在调用时始终返回 true
。
例 4.29. AnalyticsManager.java
@Override public boolean isEnabled() { return true; }
@Override
public boolean isEnabled() {
return true;
}
可以将更复杂的逻辑放在 isEnabled ()
中。例如,托管 OpenShift Dev Spaces Woopra 后端 在确定后端是否已启用前检查配置属性是否存在。
4.7.2.7. 实施 onEvent ()
onEvent ()
将后端收到的事件发送到遥测系统。对于 example 应用,它将 HTTP POST 有效负载发送到来自遥测服务器的 /event
端点。
4.7.2.7.1. 向示例 telemetry 服务器发送 POST 请求
在以下示例中,遥测服务器应用通过以下 URL 部署到 OpenShift: http://little-telemetry-server-che.apps-crc.testing
,其中 apps-crc.testing
是 OpenShift 集群的入口域名。
通过创建
TelemetryService.java
来设置 RESTEasy REST 客户端例 4.30.
TelemetryService.java
package org.my.group; import java.util.Map; import javax.ws.rs.Consumes; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; import org.eclipse.microprofile.rest.client.inject.RegisterRestClient; @RegisterRestClient public interface TelemetryService { @POST @Path("/event") @Consumes(MediaType.APPLICATION_JSON) Response sendEvent(Map<String, Object> payload); }
package org.my.group; import java.util.Map; import javax.ws.rs.Consumes; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.Response; import org.eclipse.microprofile.rest.client.inject.RegisterRestClient; @RegisterRestClient public interface TelemetryService { @POST @Path("/event")
1 @Consumes(MediaType.APPLICATION_JSON) Response sendEvent(Map<String, Object> payload); }
Copy to Clipboard Copied! - 1
- 向其发出
POST
请求的端点。
在
src/main/resources/application.properties
文件中指定TelemetryService
的基本 URL:例 4.31.
application.properties
org.my.group.TelemetryService/mp-rest/url=http://little-telemetry-server-che.apps-crc.testing
org.my.group.TelemetryService/mp-rest/url=http://little-telemetry-server-che.apps-crc.testing
Copy to Clipboard Copied! 将
TelemetryService
注入AnalyticsManager
,并在onEvent ()
中发送POST
请求例 4.32.
AnalyticsManager.java
@Dependent @Alternative public class AnalyticsManager extends AbstractAnalyticsManager { @Inject @RestClient TelemetryService telemetryService; ... @Override public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) { Map<String, Object> payload = new HashMap<String, Object>(properties); payload.put("event", event); telemetryService.sendEvent(payload); }
@Dependent @Alternative public class AnalyticsManager extends AbstractAnalyticsManager { @Inject @RestClient TelemetryService telemetryService; ... @Override public void onEvent(AnalyticsEvent event, String ownerId, String ip, String userAgent, String resolution, Map<String, Object> properties) { Map<String, Object> payload = new HashMap<String, Object>(properties); payload.put("event", event); telemetryService.sendEvent(payload); }
Copy to Clipboard Copied! 这会向遥测服务器发送 HTTP 请求,并在短时间内自动延迟相同的事件。默认持续时间为 1500 毫秒。
4.7.2.8. 实现 increaseDuration ()
许多遥测系统可识别事件持续时间。AbstractAnalyticsManager
将同一时间段内发生的类似事件合并到一个事件中。这个 increaseDuration ()
的实现是一个 no-op。此方法使用用户遥测提供程序的 API 来更改事件或事件属性,以反映事件的增加持续时间。
例 4.33. AnalyticsManager.java
@Override public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
@Override
public void increaseDuration(AnalyticsEvent event, Map<String, Object> properties) {}
4.7.2.9. 实施 onActivity ()
设置不活跃超时限制,并使用 onActivity ()
发送 WORKSPACE_INACTIVE
事件(如果最后一次事件时间超过超时时间)。
例 4.34. AnalyticsManager.java
public class AnalyticsManager extends AbstractAnalyticsManager { ... private long inactiveTimeLimit = 60000 * 3; ... @Override public void onActivity() { if (System.currentTimeMillis() - lastEventTime >= inactiveTimeLimit) { onEvent(WORKSPACE_INACTIVE, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties); } }
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);
}
}
4.7.2.10. 实现 destroy ()
调用 destroy ()
时,发送 WORKSPACE_STOPPED
事件并关闭任何资源,如连接池。
例 4.35. AnalyticsManager.java
@Override public void destroy() { onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties); }
@Override
public void destroy() {
onEvent(WORKSPACE_STOPPED, lastOwnerId, lastIp, lastUserAgent, lastResolution, commonProperties);
}
运行 mvn quarkus:dev
,如 第 4.7.2.5 节 “在 Dev Workspace 中运行应用程序” 所述,使用 Ctrl+C 终止应用程序,使用 Ctrl C 向服务器发送 WORKSPACE_STOPPED
事件。
4.7.2.11. 打包 Quarkus 应用程序
有关在容器中打包应用程序的最佳说明,请参阅 Quarkus 文档。构建容器并将其推送到您选择的容器 registry。
4.7.2.11.1. 用于构建使用 JVM 运行的 Quarkus 镜像的 Dockerfile 示例
例 4.36. Dockerfile.jvm
FROM registry.access.redhat.com/ubi8/openjdk-11:1.11 ENV LANG='en_US.UTF-8' LANGUAGE='en_US:en' COPY --chown=185 target/quarkus-app/lib/ /deployments/lib/ COPY --chown=185 target/quarkus-app/*.jar /deployments/ COPY --chown=185 target/quarkus-app/app/ /deployments/app/ COPY --chown=185 target/quarkus-app/quarkus/ /deployments/quarkus/ EXPOSE 8080 USER 185 ENTRYPOINT ["java", "-Dquarkus.http.host=0.0.0.0", "-Djava.util.logging.manager=org.jboss.logmanager.LogManager", "-Dquarkus.http.port=${DEVWORKSPACE_TELEMETRY_BACKEND_PORT}", "-jar", "/deployments/quarkus-run.jar"]
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 .
mvn package && \
podman build -f src/main/docker/Dockerfile.jvm -t image:tag .
4.7.2.11.2. 用于构建 Quarkus 原生镜像的 Dockerfile 示例
例 4.37. dockerfile.native
FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5 WORKDIR /work/ RUN chown 1001 /work \ && chmod "g+rwX" /work \ && chown 1001:root /work COPY --chown=1001:root target/*-runner /work/application EXPOSE 8080 USER 1001 CMD ["./application", "-Dquarkus.http.host=0.0.0.0", "-Dquarkus.http.port=$DEVWORKSPACE_TELEMETRY_BACKEND_PORT}"]
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 .
mvn package -Pnative -Dquarkus.native.container-build=true && \
podman build -f src/main/docker/Dockerfile.native -t image:tag .
4.7.2.12. 为您的插件创建 plugin.yaml
创建一个 plugin.yaml
devfile v2 文件,代表一个 Dev Workspace 插件,用于在 Dev Workspace Pod 中运行自定义后端。有关 devfile v2 的更多信息,请参阅 Devfile v2 文档
例 4.38. plugin.yaml
schemaVersion: 2.1.0 metadata: name: devworkspace-telemetry-backend-plugin version: 0.0.1 description: A Demo telemetry backend displayName: Devworkspace Telemetry Backend components: - name: devworkspace-telemetry-backend-plugin attributes: workspaceEnv: - name: DEVWORKSPACE_TELEMETRY_BACKEND_PORT value: '4167' container: image: YOUR IMAGE env: - name: WELCOME_MESSAGE value: 'hello world!'
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
env:
- name: WELCOME_MESSAGE
value: 'hello world!'
- 1
- 指定从 第 4.7.2.11 节 “打包 Quarkus 应用程序” 构建的容器镜像。
- 2
- 从 Example 4 设置
welcome.message
可选配置属性的值。
通常,用户将此文件部署到公司 Web 服务器。本指南演示了如何在 OpenShift 上创建 Apache Web 服务器,并在那里托管插件。
创建引用新 plugin.yaml
文件的 ConfigMap
对象。
oc create configmap --from-file=plugin.yaml -n openshift-devspaces telemetry-plugin-yaml
$ oc create configmap --from-file=plugin.yaml -n openshift-devspaces telemetry-plugin-yaml
创建用于公开 Web 服务器的部署、服务和路由。部署引用此 ConfigMap
对象并将其放置在 /var/www/html
目录中。
例 4.39. manifest.yaml
kind: Deployment apiVersion: apps/v1 metadata: name: apache spec: replicas: 1 selector: matchLabels: app: apache template: metadata: labels: app: apache spec: volumes: - name: plugin-yaml configMap: name: telemetry-plugin-yaml defaultMode: 420 containers: - name: apache image: 'registry.redhat.io/rhscl/httpd-24-rhel7:latest' ports: - containerPort: 8080 protocol: TCP resources: {} volumeMounts: - name: plugin-yaml mountPath: /var/www/html strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 25% maxSurge: 25% revisionHistoryLimit: 10 progressDeadlineSeconds: 600 --- kind: Service apiVersion: v1 metadata: name: apache spec: ports: - protocol: TCP port: 8080 targetPort: 8080 selector: app: apache type: ClusterIP --- kind: Route apiVersion: route.openshift.io/v1 metadata: name: apache spec: host: apache-che.apps-crc.testing to: kind: Service name: apache weight: 100 port: targetPort: 8080 wildcardPolicy: None
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
$ oc apply -f manifest.yaml
验证步骤
部署启动后,确认
plugin.yaml
在 web 服务器中可用:curl apache-che.apps-crc.testing/plugin.yaml
$ curl apache-che.apps-crc.testing/plugin.yaml
Copy to Clipboard Copied!
4.7.2.13. 在 Dev Workspace 中指定 telemetry 插件
将以下内容添加到现有 Dev Workspace 的
components
字段中:components: ... - name: telemetry-plugin plugin: uri: http://apache-che.apps-crc.testing/plugin.yaml
components: ... - name: telemetry-plugin plugin: uri: http://apache-che.apps-crc.testing/plugin.yaml
Copy to Clipboard Copied! - 从 OpenShift Dev Spaces 仪表板启动 Dev Workspace。
验证步骤
验证 telemetry 插件容器是否在 Dev Workspace pod 中运行。在这里,通过检查编辑器中的 Workspace 视图来验证这一点。
- 在编辑器中编辑文件,并观察其遥测服务器日志中的事件。
4.7.2.14. 为所有 Dev Workspaces 应用 telemetry 插件
将 telemetry 插件设置为默认插件。默认插件会在 Dev Workspace 启动时为新的和现有的 Dev Workspaces 应用。
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next plugins: - 'http://apache-che.apps-crc.testing/plugin.yaml'
spec: devEnvironments: defaultPlugins: - editor: eclipse/che-theia/next
1 plugins:
2 - 'http://apache-che.apps-crc.testing/plugin.yaml'
Copy to Clipboard Copied!
验证步骤
- 从 Red Hat OpenShift Dev Spaces 仪表板启动新的或现有的 Dev Workspace。
- 按照 第 4.7.2.13 节 “在 Dev Workspace 中指定 telemetry 插件” 验证步骤验证 telemetry 插件是否正常工作。
4.7.2.15. 配置服务器日志记录
可以在 OpenShift Dev Spaces 服务器中微调单个日志记录器的日志级别。
使用 Operator 的 cheLogLevel
配置属性全局配置整个 OpenShift Dev Spaces 服务器的日志级别。请参阅 第 4.1.3 节 “CheCluster
自定义资源字段参考”。要在不是由 Operator 管理的安装中设置全局日志级别,请在 che
ConfigMap 中指定 CHE_LOG_LEVEL
环境变量。
可以使用 CHE_LOGGER_CONFIG
环境变量在 OpenShift Dev Spaces 服务器中配置单个日志记录器的日志级别。
4.7.2.15.1. 配置日志级别
流程
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "<key1=value1,key2=value2>"
spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "<key1=value1,key2=value2>"
1 Copy to Clipboard Copied! - 1
- 以逗号分隔的键值对列表,其中键是 OpenShift Dev Spaces 服务器日志输出和值是所需的日志级别。
例 4.40. 为
WorkspaceManager
配置调试模式spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
Copy to Clipboard Copied!
4.7.2.15.2. 日志记录器命名
日志记录器的名称遵循使用这些日志记录器的内部服务器类的类名称。
4.7.2.15.3. 日志记录 HTTP 流量
流程
要记录 OpenShift Dev Spaces 服务器和 Kubernetes 或 OpenShift 集群的 API 服务器之间的 HTTP 流量,请配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
spec: components: cheServer: extraProperties: CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
Copy to Clipboard Copied!
4.7.2.16. 使用 dsc 收集日志
安装 Red Hat OpenShift Dev Spaces 由 OpenShift 集群中运行多个容器组成。虽然可以从每个正在运行的容器手动收集日志,但 dsc
提供了可自动化进程的命令。
以下命令可使用 dsc
工具从 OpenShift 集群收集 Red Hat OpenShift Dev Spaces 日志:
DSC server:logs
收集现有的 Red Hat OpenShift Dev Spaces 服务器日志,并将其存储在本地机器的目录中。默认情况下,日志下载到计算机的临时目录中。但是,这可以通过指定
-d
参数来覆盖。例如,要将 OpenShift Dev Spaces 日志下载到/home/user/che-logs/
目录,请使用 命令dsc server:logs -d /home/user/che-logs/
dsc server:logs -d /home/user/che-logs/
Copy to Clipboard Copied! 运行时,
dsc server:logs
会在控制台中打印一条消息,指定用于存储日志文件的目录:Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
Red Hat OpenShift Dev Spaces logs will be available in '/tmp/chectl-logs/1648575098344'
Copy to Clipboard Copied! 如果在非默认项目中安装了 Red Hat OpenShift Dev Spaces,
dsc server:logs
需要-n <NAMESPACE>
; paremeter,其中 <NAMESPACE
> 是安装 Red Hat OpenShift Dev Spaces 的 OpenShift 项目。例如,若要从my-namespace
项目中的 OpenShift Dev Spaces 获取日志,请使用 命令dsc server:logs -n my-namespace
dsc server:logs -n my-namespace
Copy to Clipboard Copied! dsc server:deploy
-
当使用
dsc
安装时,日志会在 OpenShift Dev Spaces 安装过程中自动收集。与dsc server:logs
一样,可以使用-d
参数指定目录日志。
其他资源
- "DSC 参考文档"
4.7.3. 监控 Dev Workspace Operator
您可以配置 OpenShift in-cluster 监控堆栈,以提取 Dev Workspace Operator 公开的指标。
4.7.3.1. 收集 Dev Workspace Operator 指标
使用 in-cluster Prometheus 实例收集有关 Dev Workspace Operator 的指标:
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Red Hat OpenShift 中运行。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。 -
devworkspace-controller-metrics
Service 在端口8443
上公开指标。默认情况下已预先配置。
流程
创建用于检测 Dev Workspace Operator 指标服务的 ServiceMonitor。
例 4.41. ServiceMonitor
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: devworkspace-controller namespace: openshift-devspaces spec: endpoints: - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token interval: 10s port: metrics scheme: https tlsConfig: insecureSkipVerify: true namespaceSelector: matchNames: - openshift-operators selector: matchLabels: app.kubernetes.io/name: devworkspace-controller
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: devworkspace-controller namespace: openshift-devspaces
1 spec: endpoints: - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token interval: 10s
2 port: metrics scheme: https tlsConfig: insecureSkipVerify: true namespaceSelector: matchNames: - openshift-operators selector: matchLabels: app.kubernetes.io/name: devworkspace-controller
Copy to Clipboard Copied! 允许 in-cluster Prometheus 实例检测 OpenShift Dev Spaces 命名空间中的 ServiceMonitor。默认的 OpenShift Dev Spaces 命名空间为
openshift-devspaces
。oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
$ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
Copy to Clipboard Copied!
验证
- 对于 OpenShift Dev Spaces 的新安装,请通过从 Dashboard 创建 OpenShift Dev Spaces 工作区来生成指标。
- 在 OpenShift Web 控制台的 Administrator 视图中,进入 Observe → Metrics。
运行 PromQL 查询以确认指标是否可用。例如,输入
devworkspace_started_total
并点 Run queries。如需了解更多指标,请参阅 第 4.7.3.2 节 “dev Workspace 特定指标”。
要排除缺少的指标,请查看 Prometheus 容器日志以了解与 RBAC 相关的错误:
获取 Prometheus pod 的名称:
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
Copy to Clipboard Copied! 显示上一步中的 Prometheus pod 的最后 20 行:
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
Copy to Clipboard Copied!
4.7.3.2. dev Workspace 特定指标
下表描述了 devworkspace-controller-metrics
服务公开的 Dev Workspace 特定指标。
Name | 类型 | 描述 | 标签 |
---|---|---|---|
| 计数 | Dev Workspace 启动事件的数量。 |
|
| 计数 |
Dev Workspaces 的数量成功进入 |
|
| 计数 | 失败的 Dev Workspaces 数量。 |
|
| Histogram | 启动 Dev Workspace 的总时间(以秒为单位)。 |
|
Name | 描述 | 值 |
---|---|---|
|
Dev Workspace 的 |
|
|
Dev Workspace 的 |
|
| 工作区启动失败的原因。 |
|
Name | 描述 |
---|---|
| 由于用于创建 Dev Workspace 的无效 devfile,启动失败。 |
|
由于以下错误启动失败: |
| 未知故障原因. |
4.7.3.3. 从 OpenShift Web 控制台仪表板查看 Dev Workspace Operator 指标
在将 in-cluster Prometheus 实例配置为收集 Dev Workspace Operator 指标后,您可以在 OpenShift web 控制台的 Administrator 视角中查看自定义仪表板上的指标。
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Red Hat OpenShift 中运行。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。 - in-cluster Prometheus 实例收集指标。请参阅 第 4.7.3.1 节 “收集 Dev Workspace Operator 指标”。
流程
在
openshift-config-managed
项目中为仪表板定义创建 ConfigMap,并应用所需的标签。oc create configmap grafana-dashboard-dwo \ --from-literal=dwo-dashboard.json="$(curl https://raw.githubusercontent.com/devfile/devworkspace-operator/main/docs/grafana/openshift-console-dashboard.json)" \ -n openshift-config-managed
$ oc create configmap grafana-dashboard-dwo \ --from-literal=dwo-dashboard.json="$(curl https://raw.githubusercontent.com/devfile/devworkspace-operator/main/docs/grafana/openshift-console-dashboard.json)" \ -n openshift-config-managed
Copy to Clipboard Copied! 注意上一命令包含到来自上游社区的材料的链接。本材料代表了非常最新的可用内容和最新最佳实践。这些提示尚未由红帽的 QE 部门审查,并且尚未由广泛的用户组验证。请小心使用此信息。
oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed
$ oc label configmap grafana-dashboard-dwo console.openshift.io/dashboard=true -n openshift-config-managed
Copy to Clipboard Copied! 注意仪表板定义基于 Grafana 6.x 仪表板。OpenShift Web 控制台不支持所有 Grafana 6.x 仪表板功能。
验证步骤
- 在 OpenShift Web 控制台的 Administrator 视图中,进入 Observe → Dashboards。
- 进入 Dashboard → Che Server JVM,验证仪表板面板是否包含数据。
4.7.3.4. Dev Workspace Operator 的仪表板
OpenShift Web 控制台自定义仪表板基于 Grafana 6.x,显示 Dev Workspace Operator 中的以下指标。
Grafana 6.x 仪表板的所有功能都作为 OpenShift Web 控制台仪表板被支持。
4.7.3.4.1. dev Workspace 指标
Dev Workspace Metrics 面板中会显示 Dev Workspace 特定指标。
图 4.1. Dev Workspace Metrics 面板

- 平均工作区开始时间
- 平均工作区启动持续时间。
- 工作区启动
- 成功和失败的工作区启动数量。
- dev Workspace 成功和失败
- 成功和失败的 Dev Workspace 启动之间的比较。
- dev Workspace 失败率
- 工作区启动失败数量和工作空间启动总数之间的比率。
- dev Workspace 启动失败原因
显示工作空间启动故障的 pie chart:
-
BadRequest
-
InfrastructureFailure
-
Unknown
-
4.7.3.4.2. Operator 指标
Operator Metrics 面板中会显示特定于 Operator 的指标。
图 4.2. Operator Metrics 面板

- flight 中的 Webhook
- 不同 Webhook 请求数量之间的比较。
- 工作队列深度
- 工作队列中的协调请求数。
- memory
- Dev Workspace 控制器和 Dev Workspace Webhook 服务器的内存用量。
- 平均每秒协调计数(DWO)
- Dev Workspace 控制器的平均每秒协调数数。
4.7.4. 监控 Dev Spaces 服务器
您可以将 OpenShift Dev Spaces 配置为公开 JVM 指标,如 JVM 内存和 OpenShift Dev Spaces Server 的类加载。
4.7.4.1. 启用并公开 OpenShift Dev Spaces 服务器指标
OpenShift Dev Spaces 在 che-host
Service 的端口 8087
上公开 JVM 指标。您可以配置此行为。
流程
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: components: metrics: enable: <boolean>
spec: components: metrics: enable: <boolean>
1 Copy to Clipboard Copied! - 1
true
要启用,false
禁用。
4.7.4.2. 使用 Prometheus 收集 OpenShift Dev Spaces 服务器指标
使用 in-cluster Prometheus 实例为 OpenShift Dev Spaces Server 收集、存储和查询 JVM 指标:
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Red Hat OpenShift 中运行。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。 -
OpenShift Dev Spaces 在端口
8087
上公开指标。请参阅启用和公开 OpenShift Dev Spaces 服务器 JVM 指标。
流程
创建 ServiceMonitor 以检测 OpenShift Dev Spaces JVM 指标服务。
例 4.42. ServiceMonitor
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: che-host namespace: openshift-devspaces spec: endpoints: - interval: 10s port: metrics scheme: http namespaceSelector: matchNames: - openshift-devspaces selector: matchLabels: app.kubernetes.io/name: devspaces
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: che-host namespace: openshift-devspaces
1 spec: endpoints: - interval: 10s
2 port: metrics scheme: http namespaceSelector: matchNames: - openshift-devspaces
3 selector: matchLabels: app.kubernetes.io/name: devspaces
Copy to Clipboard Copied! 创建 Role 和 RoleBinding,以允许 Prometheus 查看指标。
例 4.43. 角色
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: prometheus-k8s namespace: openshift-devspaces rules: - verbs: - get - list - watch apiGroups: - '' resources: - services - endpoints - pods
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: prometheus-k8s namespace: openshift-devspaces
1 rules: - verbs: - get - list - watch apiGroups: - '' resources: - services - endpoints - pods
Copy to Clipboard Copied! - 1
- OpenShift Dev Spaces 命名空间。默认为
openshift-devspaces
。
例 4.44. RoleBinding
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: view-devspaces-openshift-monitoring-prometheus-k8s namespace: openshift-devspaces subjects: - kind: ServiceAccount name: prometheus-k8s namespace: openshift-monitoring roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: view-devspaces-openshift-monitoring-prometheus-k8s namespace: openshift-devspaces
1 subjects: - kind: ServiceAccount name: prometheus-k8s namespace: openshift-monitoring roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s
Copy to Clipboard Copied! - 1
- OpenShift Dev Spaces 命名空间。默认为
openshift-devspaces
。
允许 in-cluster Prometheus 实例检测 OpenShift Dev Spaces 命名空间中的 ServiceMonitor。默认的 OpenShift Dev Spaces 命名空间为
openshift-devspaces
。oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
$ oc label namespace openshift-devspaces openshift.io/cluster-monitoring=true
Copy to Clipboard Copied!
验证
- 在 OpenShift Web 控制台的 Administrator 视图中,进入 Observe → Metrics。
-
运行 PromQL 查询以确认指标是否可用。例如,输入
process_uptime_seconds{job="che-host"}
,然后单击 Run queries。
要排除缺少的指标,请查看 Prometheus 容器日志以了解与 RBAC 相关的错误:
获取 Prometheus pod 的名称:
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
$ oc get pods -l app.kubernetes.io/name=prometheus -n openshift-monitoring -o=jsonpath='{.items[*].metadata.name}'
Copy to Clipboard Copied! 显示上一步中的 Prometheus pod 的最后 20 行:
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
$ oc logs --tail=20 <prometheus_pod_name> -c prometheus -n openshift-monitoring
Copy to Clipboard Copied!
4.7.4.3. 从 OpenShift Web 控制台仪表板查看 OpenShift Dev Spaces Server
在将 in-cluster Prometheus 实例配置为收集 OpenShift Dev Spaces Server JVM 指标后,您可以在 OpenShift Web 控制台的 Administrator 视角中查看自定义仪表板上的指标。
先决条件
- 您的机构 OpenShift Dev Spaces 实例已安装并在 Red Hat OpenShift 中运行。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。 - in-cluster Prometheus 实例收集指标。请参阅 第 4.7.4.2 节 “使用 Prometheus 收集 OpenShift Dev Spaces 服务器指标”。
流程
在
openshift-config-managed
项目中为仪表板定义创建 ConfigMap,并应用所需的标签。oc create configmap grafana-dashboard-devspaces-server \ --from-literal=devspaces-server-dashboard.json="$(curl https://raw.githubusercontent.com/eclipse-che/che-server/main/docs/grafana/openshift-console-dashboard.json)" \ -n openshift-config-managed
$ oc create configmap grafana-dashboard-devspaces-server \ --from-literal=devspaces-server-dashboard.json="$(curl https://raw.githubusercontent.com/eclipse-che/che-server/main/docs/grafana/openshift-console-dashboard.json)" \ -n openshift-config-managed
Copy to Clipboard Copied! 注意上一命令包含到来自上游社区的材料的链接。本材料代表了非常最新的可用内容和最新最佳实践。这些提示尚未由红帽的 QE 部门审查,并且尚未由广泛的用户组验证。请小心使用此信息。
oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed
$ oc label configmap grafana-dashboard-devspaces-server console.openshift.io/dashboard=true -n openshift-config-managed
Copy to Clipboard Copied! 注意仪表板定义基于 Grafana 6.x 仪表板。OpenShift Web 控制台不支持所有 Grafana 6.x 仪表板功能。
验证步骤
- 在 OpenShift Web 控制台的 Administrator 视图中,进入 Observe → Dashboards。
进入 Dashboard → Dev Workspace Operator,验证仪表板面板是否包含数据。
图 4.3. 快速事实
图 4.4. JVM 内存
图 4.5. JVM Misc
图 4.6. JVM 内存池(heap)
图 4.7. JVM 内存池(Non-Heap)
图 4.8. 垃圾回收
图 4.9. 类加载
图 4.10. 缓冲池
4.8. 配置网络
4.8.1. 配置网络策略
默认情况下,OpenShift 集群中的所有 Pod 都可以相互通信,即使它们位于不同的命名空间中。在 OpenShift Dev Spaces 中,这可能会导致一个用户项目中的工作区 Pod 将流量发送到其他用户项目中的另一个工作区 Pod。
为安全起见,可以使用 NetworkPolicy 对象配置多租户隔离,以限制用户项目中的所有传入的通信。但是,OpenShift Dev Spaces 项目中的 Pod 必须能够与用户项目中的 Pod 通信。
先决条件
- OpenShift 集群有网络限制,如多租户隔离。
流程
将
allow-from-openshift-devspaces
NetworkPolicy 应用到每个用户项目。allow-from-openshift-devspaces
NetworkPolicy 允许从 OpenShift Dev Spaces 命名空间的传入流量到用户项目中的所有 Pod。例 4.45.
allow-from-openshift-devspaces.yaml
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-devspaces spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-devspaces podSelector: {} policyTypes: - Ingress
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-devspaces spec: ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-devspaces
1 podSelector: {}
2 policyTypes: - Ingress
Copy to Clipboard Copied! OPTIONAL : 在使用网络策略应用配置多租户隔离时,还必须应用
allow-from-openshift-apiserver
和allow-from-workspaces-namespaces
NetworkPolicies 到openshift-devspaces
。allow-from-openshift-apiserver
NetworkPolicy 允许从openshift-apiserver
命名空间中的传入流量到devworkspace-webhook-server
启用 Webhook。allow-from-workspaces-namespaces
NetworkPolicy 允许从每个用户项目的传入流量到che-gateway
pod。例 4.46.
allow-from-openshift-apiserver.yaml
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-apiserver namespace: openshift-devspaces spec: podSelector: matchLabels: app.kubernetes.io/name: devworkspace-webhook-server ingress: - from: - podSelector: {} namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-apiserver policyTypes: - Ingress
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-openshift-apiserver namespace: openshift-devspaces
1 spec: podSelector: matchLabels: app.kubernetes.io/name: devworkspace-webhook-server
2 ingress: - from: - podSelector: {} namespaceSelector: matchLabels: kubernetes.io/metadata.name: openshift-apiserver policyTypes: - Ingress
Copy to Clipboard Copied! 例 4.47.
allow-from-workspaces-namespaces.yaml
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-workspaces-namespaces namespace: openshift-devspaces spec: podSelector: {} ingress: - from: - podSelector: {} namespaceSelector: matchLabels: app.kubernetes.io/component: workspaces-namespace policyTypes: - Ingress
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-from-workspaces-namespaces namespace: openshift-devspaces
1 spec: podSelector: {}
2 ingress: - from: - podSelector: {} namespaceSelector: matchLabels: app.kubernetes.io/component: workspaces-namespace policyTypes: - Ingress
Copy to Clipboard Copied! - 第 4.2 节 “配置项目”
- 网络隔离
- 使用网络策略配置多租户隔离
4.8.2. 配置 Dev Spaces 主机名
此流程描述了如何将 OpenShift Dev Spaces 配置为使用自定义主机名。
先决条件
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。 - 生成证书和私钥文件。
要生成私钥和证书的对,相同的证书颁发机构(CA)必须与其他 OpenShift Dev Spaces 主机一起使用。
请求 DNS 供应商将自定义主机名指向集群入口。
流程
为 OpenShift Dev Spaces 预创建项目:
oc create project openshift-devspaces
$ oc create project openshift-devspaces
Copy to Clipboard Copied! 创建 TLS secret:
oc create secret tls <tls_secret_name> \ --key <key_file> \ --cert <cert_file> \ -n openshift-devspaces
$ oc create secret tls <tls_secret_name> \
1 --key <key_file> \
2 --cert <cert_file> \
3 -n openshift-devspaces
Copy to Clipboard Copied! 在 secret 中添加所需的标签:
oc label secret <tls_secret_name> \ app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
$ oc label secret <tls_secret_name> \
1 app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
Copy to Clipboard Copied! - 1
- TLS secret 名称
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: networking: hostname: <hostname> tlsSecretName: <secret>
spec: networking: hostname: <hostname>
1 tlsSecretName: <secret>
2 Copy to Clipboard Copied! - 如果 OpenShift Dev Spaces 已部署,请等待所有 OpenShift Dev Spaces 组件的推出完成。
4.8.3. 将不可信 TLS 证书导入到 Dev Spaces
OpenShift Dev Spaces 组件与外部服务通信通过 TLS 加密。它们需要由可信证书颁发机构(CA)签名的 TLS 证书。因此,您必须导入到 OpenShift Dev Spaces 中由外部服务使用的所有不受信任的 CA 链,例如:
- 代理
- 身份供应商(OIDC)
- 源代码存储库供应商(Git)
OpenShift Dev Spaces 使用 OpenShift Dev Spaces 项目中的标记 ConfigMap 作为 TLS 证书的源。ConfigMap 可以有任意数量的键,每个键都有随机数量的证书。所有证书都挂载到:
-
OpenShift Dev Spaces 服务器和仪表板 pod 的
/public-certs
位置 -
工作区 pod 的
/etc/pki/ca-trust/extracted/pem
位置
配置 CheCluster
自定义资源,以禁用在 /etc/pki/ca-trust/extracted/pem
处的 CA 捆绑包挂载。证书将被挂载到 /public-certs
,以保持之前版本中的行为。
配置 CheCluster
自定义资源,以禁用在路径 /etc/pki/ca-trust/extracted/pem
下挂载 CA 捆绑包。在这种情况下,证书将被挂载到路径 /public-certs
下。
spec: devEnvironments: trustedCerts: disableWorkspaceCaBundleMount: true
spec:
devEnvironments:
trustedCerts:
disableWorkspaceCaBundleMount: true
在 OpenShift 集群中,OpenShift Dev Spaces Operator 会自动将 Red Hat Enterprise Linux CoreOS (RHCOS)信任捆绑包添加到挂载的证书中。
先决条件
流程
将所有 CA 链 PEM 文件链到
custom-ca-certificates.pem
文件中,并删除与 Java 信任存储不兼容的返回字符。cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
$ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
Copy to Clipboard Copied! 使用所需的 TLS 证书创建
custom-ca-certificates
ConfigMap:oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces
$ oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces
Copy to Clipboard Copied! 标记
custom-ca-certificates
ConfigMap:oc label configmap custom-ca-certificates \ app.kubernetes.io/component=ca-bundle \ app.kubernetes.io/part-of=che.eclipse.org \ --namespace=openshift-devspaces
$ oc label configmap custom-ca-certificates \ app.kubernetes.io/component=ca-bundle \ app.kubernetes.io/part-of=che.eclipse.org \ --namespace=openshift-devspaces
Copy to Clipboard Copied! - 如果之前尚未部署,部署 OpenShift Dev Spaces。否则,请等待 OpenShift Dev Spaces 组件的推出完成。
- 重启正在运行的工作区以使更改生效。
验证步骤
验证 ConfigMap 是否包含您的自定义 CA 证书。此命令返回 PEM 格式的 CA 捆绑包证书:
oc get configmap \ --namespace=openshift-devspaces \ --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \ --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org
oc get configmap \ --namespace=openshift-devspaces \ --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \ --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org
Copy to Clipboard Copied! 在 OpenShift Dev Spaces 服务器日志中验证导入的证书计数是否不是 null :
oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem
oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem
Copy to Clipboard Copied! - 启动一个工作区,获取创建它的项目名称:< workspace_namespace > 并等待工作区启动。
验证
ca-certs-merged
ConfigMap 是否包含您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:oc get configmap che-trusted-ca-certs \ --namespace=<workspace_namespace> \ --output='jsonpath={.data.tls-ca-bundle\.pem}'
oc get configmap che-trusted-ca-certs \ --namespace=<workspace_namespace> \ --output='jsonpath={.data.tls-ca-bundle\.pem}'
Copy to Clipboard Copied! 验证工作区 pod 是否挂载
ca-certs-merged
ConfigMap:oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \ | grep ca-certs-merged
oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \ | grep ca-certs-merged
Copy to Clipboard Copied! 获取工作区 pod 名称 < workspace_pod_name>:
oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}' \
oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}' \
Copy to Clipboard Copied! 验证工作区容器是否具有您的自定义 CA 证书。此命令以 PEM 格式返回 OpenShift Dev Spaces CA 捆绑包证书:
oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
Copy to Clipboard Copied!
其他资源
4.8.4. 添加标签和注解
4.8.4.1. 配置 OpenShift 路由以使用路由器划分
您可以为 OpenShift Route 配置标签、注解和域,以用于 路由器分片。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。 -
DSC
.请参阅:第 2.2 节 “安装 dsc 管理工具”。
流程
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: networking: labels: <labels> domain: <domain> annotations: <annotations>
spec: networking: labels: <labels>
1 domain: <domain>
2 annotations: <annotations>
3 Copy to Clipboard Copied!
4.8.5. 配置工作区端点基域
了解如何为工作区端点配置基域。默认情况下,OpenShift Dev Spaces Operator 会自动检测到基域。要更改它,您需要在 CheCluster
自定义资源中配置 CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX
属性。
spec: components: cheServer: extraProperties: CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<...>"
spec:
components:
cheServer:
extraProperties:
CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<...>"
- 1
- 工作区端点基域,如
my-devspaces.example.com
。
流程
配置工作区端点基域:
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' -p \ '{"spec": {"components": {"cheServer": {"extraProperties": {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' -p \ '{"spec": {"components": {"cheServer": {"extraProperties": {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'
Copy to Clipboard Copied!
4.8.6. 配置代理
了解如何为 Red Hat OpenShift Dev Spaces 配置代理。步骤包括为代理凭证创建 Kubernetes Secret,并在 CheCluster 自定义资源中配置必要的代理设置。代理设置通过环境变量传播到操作对象和工作区。
在 OpenShift 集群中,您不需要配置代理设置。OpenShift Dev Spaces Operator 会自动使用 OpenShift 集群范围的代理配置。但是,您可以通过在 CheCluster 自定义资源中指定代理设置来覆盖代理设置。
流程
(可选)在 openshift-devspaces 命名空间中创建 Secret,其中包含代理服务器的用户和密码。secret 必须具有
app.kubernetes.io/part-of=che.eclipse.org
标签。如果代理服务器不需要身份验证,请跳过这一步。oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: devspaces-proxy-credentials namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org type: Opaque stringData: user: <user> password: <password> EOF
oc apply -f - <<EOF kind: Secret apiVersion: v1 metadata: name: devspaces-proxy-credentials namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org type: Opaque stringData: user: <user>
1 password: <password>
2 EOF
Copy to Clipboard Copied! 通过在 CheCluster 自定义资源中设置以下属性,为 OpenShift 集群配置代理或覆盖集群范围的代理配置:
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' -p \ '{"spec": {"components": {"cheServer": {"proxy": {"credentialsSecretName" : "<secretName>", "nonProxyHosts" : ["<host_1>"], "port" : "<port>", "url" : "<protocol>://<domain>"}}}}}'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' -p \ '{"spec": {"components": {"cheServer": {"proxy": {"credentialsSecretName" : "<secretName>",
1 "nonProxyHosts" : ["<host_1>"],
2 "port" : "<port>",
3 "url" : "<protocol>://<domain>"}}}}}'
4 Copy to Clipboard Copied! 重要在一些代理配置中,
localhost
可能不会转换为127.0.0.1
。在这种情况下,应该同时指定localhost
和127.0.0.1
。- 代理服务器的端口。
- 代理服务器的协议和域。
验证步骤
- 启动工作区
-
验证工作区 pod 是否包含
HTTP_PROXY
、HTTPS_PROXY
、http_proxy
和https_proxy
环境变量,每个变量都设置为 <protocol> ://<user& gt;:<password@<domain>:<port>
。 -
验证工作区 pod 是否包含
NO_PROXY
和no_proxy
环境变量,每个变量都设置为用逗号分开的非代理主机列表。
4.9. 配置存储
OpenShift Dev Spaces 不支持网络文件系统(NFS)协议。
4.9.1. 配置存储类
要将 OpenShift Dev Spaces 配置为使用配置的基础架构存储,请使用存储类安装 OpenShift Dev Spaces。当您要绑定由非默认置备程序提供的持久性卷时,这特别有用。
OpenShift Dev Spaces 有一个组件,需要持久性卷来存储数据:
-
OpenShift Dev Spaces 工作区。OpenShift Dev Spaces 工作区使用卷存储源代码,如
/projects
卷。
只有工作区不是临时的时,OpenShift Dev Spaces 工作区源代码才会存储在持久性卷中。
持久性卷声明事实:
- OpenShift Dev Spaces 不会在基础架构中创建持久性卷。
- OpenShift Dev Spaces 使用持久性卷声明(PVC)来挂载持久性卷。
第 2.3.1.2 节 “dev Workspace operator” 创建持久性卷声明。
在 OpenShift Dev Spaces 配置中定义存储类名称,以使用 OpenShift Dev Spaces PVC 中的存储类功能。
流程
使用 CheCluster 自定义资源定义来定义存储类:
定义存储类名称 :配置
CheCluster
自定义资源,并安装 OpenShift Dev Spaces。请参阅 第 4.1.1 节 “在安装过程中使用 dsc 配置CheCluster
自定义资源”。spec: devEnvironments: storage: perUserStrategyPvcConfig: claimSize: <claim_size> storageClass: <storage_class_name> perWorkspaceStrategyPvcConfig: claimSize: <claim_size> storageClass: <storage_class_name> pvcStrategy: <pvc_strategy>
spec: devEnvironments: storage: perUserStrategyPvcConfig: claimSize: <claim_size>
1 storageClass: <storage_class_name>
2 perWorkspaceStrategyPvcConfig: claimSize: <claim_size>
3 storageClass: <storage_class_name>
4 pvcStrategy: <pvc_strategy>
5 Copy to Clipboard Copied!
4.9.2. 配置存储策略
通过选择存储策略,可以将 OpenShift Dev Spaces 配置为向工作区提供持久性或非持久性存储。默认情况下,所选存储策略将应用到所有新创建的工作区。用户可以为 devfile 中的工作区选择非默认存储策略,或者通过 URL 参数 选择。
可用的存储策略:
-
每个用户
:对用户创建的所有工作区使用单个 PVC。 -
per-workspace
: 每个工作区都会被赋予自己的 PVC。 -
Ephemeral
: Non-persistent storage; 当工作区停止后,任何本地更改都会丢失。
OpenShift Dev Spaces 中使用的默认存储策略是 每个用户
。
流程
-
将 Che Cluster Custom Resource 中的
pvcStrategy
字段设置为per-user
、per-workspace
或ephemeral
。
-
您可以在安装时设置此字段。请参阅 第 4.1.1 节 “在安装过程中使用 dsc 配置
CheCluster
自定义资源”。 - 您可以在命令行中更新此字段。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。
spec: devEnvironments: storage: pvc: pvcStrategy: 'per-user'
spec:
devEnvironments:
storage:
pvc:
pvcStrategy: 'per-user'
- 1
- 可用的存储策略是
按用户、每个
工作区临时的
。
4.9.3. 配置存储大小
您可以使用 per-user
或 per-workspace
存储策略配置持久性卷声明(PVC)大小。您必须使用 CheCluster
自定义资源的 PVC 大小,格式为 Kubernetes 资源数量。有关可用存储策略的详情,请查看 此页面。
默认持久性卷声明大小:
per-user: 10Gi
per-user: 10Gi
Copy to Clipboard Copied! per-workspace: 5Gi
per-workspace: 5Gi
Copy to Clipboard Copied!
流程
-
在 Che Cluster Custom Resource 中为所需的存储策略设置适当的
claimSize
字段。
-
您可以在安装时设置此字段。请参阅 第 4.1.1 节 “在安装过程中使用 dsc 配置
CheCluster
自定义资源”。 - 您可以在命令行中更新此字段。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。
spec: devEnvironments: storage: pvc: pvcStrategy: '<strategy_name>' perUserStrategyPvcConfig: claimSize: <resource_quantity> perWorkspaceStrategyPvcConfig: claimSize: <resource_quantity>
spec:
devEnvironments:
storage:
pvc:
pvcStrategy: '<strategy_name>'
perUserStrategyPvcConfig:
claimSize: <resource_quantity>
perWorkspaceStrategyPvcConfig:
claimSize: <resource_quantity>
4.9.4. 持久用户主页
Red Hat OpenShift Dev Spaces 提供了一个永久的主目录功能,允许每个非临时工作区在工作空间重启后保留其 /home/user
目录。您可以通过将 spec.devEnvironments.persistUserHome.enabled
设置为 true
,在 CheCluster 中启用此功能。
对于新启动的工作区,此功能会创建一个挂载到工具容器的 /home/user
路径的 PVC。在本文档中,将使用"tools 容器"来指代 devfile 中的第一个容器。此容器是默认包含项目源代码的容器。
当首次挂载 PVC 时,持久性卷的内容为空,因此必须使用 /home/user
目录内容填充。
默认情况下,persistent UserHome
功能为每个名为 init-persistent-home
的新工作区 pod 创建一个 init 容器。此 init 容器使用工具容器镜像创建,并负责运行 stow
命令在持久性卷中创建符号链接以填充 /home/user
目录。
对于不能符号链接到 /home/user
目录的文件,如 .viminfo
和 .bashrc
文件,则会使用 cp
而不是 stow
。
stow
命令的主要功能是运行:
stow -t /home/user/ -d /home/tooling/ --no-folding
stow -t /home/user/ -d /home/tooling/ --no-folding
以上命令在 /home/user
中为位于 /home/tooling
的文件和目录创建符号链接。这会使用指向 /home/tool
中内容的符号链接填充持久卷。因此,persistent UserHome
功能预期工具镜像在 /home/tooling
中包含其 /home/user/
内容。
例如,如果工具容器镜像包含 home/tooling
目录中的文件,如 .config
和 .config-folder/another-file
,则 stow 将以以下方式在持久性卷中创建符号链接:
图 4.11. 启用 persistUserHome
的工具容器

init 容器将 stow
命令的输出写入 /home/user/.stow.log
,并且仅在持久性卷第一次挂载到工作区时运行 stow
。
使用 stow
命令在持久性卷中填充 /home/user
内容有两个主要优点:
-
与在持久性卷中创建
/home/user
目录内容的副本相比,创建符号链接速度更快且消耗较少的存储。为了以不同方式放置它,本例中的持久卷包含符号链接,而不是实际文件本身。 -
如果使用现有二进制文件、配置和文件的较新版本更新工具镜像,则 init 容器不需要
研究
新版本,因为现有符号链接将链接到/home/tooling
中的较新版本。
如果工具镜像使用额外的二进制文件或文件更新,则不会以符号形式链接到 /home/user
目录,因为 stow
命令不会被再次运行。在这种情况下,用户必须删除 /home/user/.stow_completed
文件,然后重新启动工作区来重新运行 stow
。
persistUserHome
工具镜像要求
persistUserHome
依赖于用于工作区的工具镜像。默认情况下,OpenShift Dev Spaces 使用通用基础镜像(UDI)作为示例工作区,它支持 persistentUserHome
开箱即用。
如果您使用自定义镜像,应该满足三个要求来支持 persistUserHome
功能。
-
工具镜像应包含
stow
版本 >= 2.4.0。 -
$HOME
环境变量设置为/home/user
。 -
在工具镜像中,要包含
/home/user
内容的目录是/home/tooling
。
由于要求三个,例如,默认的 UDI 镜像将 /home/user
内容添加到 /home/tooling
中,并运行:
RUN stow -t /home/user/ -d /home/tooling/ --no-folding
RUN stow -t /home/user/ -d /home/tooling/ --no-folding
在 Dockerfile 中,使 /home/tooling
中的文件可以从 /home/user
访问,即使没有使用 persistUserHome
功能。
4.10. 配置仪表板
4.10.1. 配置入门示例
此流程描述了如何配置 OpenShift Dev Spaces 仪表板来显示自定义示例。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 CLI 入门。
流程
使用示例配置创建 JSON 文件。该文件必须包含一个对象数组,每个对象代表一个示例。
cat > my-samples.json <<EOF [ { "displayName": "<display_name>", "description": "<description>", "tags": <tags>, "url": "<url>", "icon": { "base64data": "<base64data>", "mediatype": "<mediatype>" } } ] EOF
cat > my-samples.json <<EOF [ { "displayName": "<display_name>",
1 "description": "<description>",
2 "tags": <tags>,
3 "url": "<url>",
4 "icon": { "base64data": "<base64data>",
5 "mediatype": "<mediatype>"
6 } } ] EOF
Copy to Clipboard Copied! 使用示例配置创建 ConfigMap:
oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces
oc create configmap getting-started-samples --from-file=my-samples.json -n openshift-devspaces
Copy to Clipboard Copied! 在 ConfigMap 中添加所需的标签:
oc label configmap getting-started-samples app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=getting-started-samples -n openshift-devspaces
oc label configmap getting-started-samples app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=getting-started-samples -n openshift-devspaces
Copy to Clipboard Copied! - 刷新 OpenShift Dev Spaces Dashboard 页面,以查看新的示例。
4.10.2. 配置编辑器定义
了解如何配置 OpenShift Dev Spaces 编辑器定义。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 CLI 入门。
流程
使用编辑器定义配置创建
my-editor-definition-devfile.yaml
YAML 文件。重要确保您在
metadata.attributes
下为publisher
和version
提供实际值。它们用于构建编辑器 id 以及编辑器名称,格式为publisher/name/version
。您可以在下面找到支持的值,包括可选的值:
# Version of the devile schema schemaVersion: 2.2.2 # Meta information of the editor metadata: # (MANDATORY) The editor name # Must consist of lower case alphanumeric characters, '-' or '.' name: editor-name displayName: Display Name description: Run Editor Foo on top of Eclipse Che # (OPTIONAL) Array of tags of the current editor. The Tech-Preview tag means the option is considered experimental and is not recommended for production environments. While it can include new features and improvements, it may still contain bugs or undergo significant changes before reaching a stable version. tags: - Tech-Preview # Additional attributes attributes: title: This is my editor # (MANDATORY) The publisher name publisher: publisher # (MANDATORY) The editor version version: version repository: https://github.com/editor/repository/ firstPublicationDate: '2024-01-01' iconMediatype: image/svg+xml iconData: | <icon-content> # List of editor components components: # Name of the component - name: che-code-injector # Configuration of devworkspace-related container container: # Image of the container image: 'quay.io/che-incubator/che-code:insiders' # The command to run in the dockerimage component instead of the default one provided in the image command: - /entrypoint-init-container.sh # (OPTIONAL) List of volumes mounts that should be mounted in this container volumeMounts: # The name of the mount - name: checode # The path of the mount path: /checode # (OPTIONAL) The memory limit of the container memoryLimit: 256Mi # (OPTIONAL) The memory request of the container memoryRequest: 32Mi # (OPTIONAL) The CPU limit of the container cpuLimit: 500m # (OPTIONAL) The CPU request of the container cpuRequest: 30m # Name of the component - name: che-code-runtime-description # (OPTIONAL) Map of implementation-dependant free-form YAML attributes attributes: # The component within the architecture app.kubernetes.io/component: che-code-runtime # The name of a higher level application this one is part of app.kubernetes.io/part-of: che-code.eclipse.org # Defines a container component as a "container contribution". If a flattened DevWorkspace has a container component with the merge-contribution attribute, then any container contributions are merged into that container component controller.devfile.io/container-contribution: true container: # Can be a dummy image because the component is expected to be injected into workspace dev component image: quay.io/devfile/universal-developer-image:latest # (OPTIONAL) List of volume mounts that should be mounted in this container volumeMounts: # The name of the mount - name: checode # (OPTIONAL) The path in the component container where the volume should be mounted. If no path is defined, the default path is the is /<name> path: /checode # (OPTIONAL) The memory limit of the container memoryLimit: 1024Mi # (OPTIONAL) The memory request of the container memoryRequest: 256Mi # (OPTIONAL) The CPU limit of the container cpuLimit: 500m # (OPTIONAL) The CPU request of the container cpuRequest: 30m # (OPTIONAL) Environment variables used in this container env: - name: ENV_NAME value: value # Component endpoints endpoints: # Name of the editor - name: che-code # (OPTIONAL) Map of implementation-dependant string-based free-form attributes attributes: # Type of the endpoint. You can only set its value to main, indicating that the endpoint should be used as the mainUrl in the workspace status (i.e. it should be the URL used to access the editor in this context) type: main # An attribute that instructs the service to automatically redirect the unauthenticated requests for current user authentication. Setting this attribute to true has security consequences because it makes Cross-site request forgery (CSRF) attacks possible. The default value of the attribute is false. cookiesAuthEnabled: true # Defines an endpoint as "discoverable", meaning that a service should be created using the endpoint name (i.e. instead of generating a service name for all endpoints, this endpoint should be statically accessible) discoverable: false # Used to secure the endpoint with authorization on OpenShift, so that not anyone on the cluster can access the endpoint, the attribute enables authentication. urlRewriteSupported: true # Port number to be used within the container component targetPort: 3100 # (OPTIONAL) Describes how the endpoint should be exposed on the network (public, internal, none) exposure: public # (OPTIONAL) Describes whether the endpoint should be secured and protected by some authentication process secure: true # (OPTIONAL) Describes the application and transport protocols of the traffic that will go through this endpoint protocol: https # Mandatory name that allows referencing the component from other elements - name: checode # (OPTIONAL) Allows specifying the definition of a volume shared by several other components. Ephemeral volumes are not stored persistently across restarts. Defaults to false volume: {ephemeral: true} # (OPTIONAL) Bindings of commands to events. Each command is referred-to by its name events: # IDs of commands that should be executed before the devworkspace start. These commands would typically be executed in an init container preStart: - init-container-command # IDs of commands that should be executed after the devworkspace has completely started. In the case of Che-Code, these commands should be executed after all plugins and extensions have started, including project cloning. This means that those commands are not triggered until the user opens the IDE within the browser postStart: - init-che-code-command # (OPTIONAL) Predefined, ready-to-use, devworkspace-related commands commands: # Mandatory identifier that allows referencing this command - id: init-container-command apply: # Describes the component for the apply command component: che-code-injector # Mandatory identifier that allows referencing this command - id: init-che-code-command # CLI Command executed in an existing component container exec: # Describes component for the exec command component: che-code-runtime-description # The actual command-line string commandLine: 'nohup /checode/entrypoint-volume.sh > /checode/entrypoint-logs.txt 2>&1 &'
# Version of the devile schema schemaVersion: 2.2.2 # Meta information of the editor metadata: # (MANDATORY) The editor name # Must consist of lower case alphanumeric characters, '-' or '.' name: editor-name displayName: Display Name description: Run Editor Foo on top of Eclipse Che # (OPTIONAL) Array of tags of the current editor. The Tech-Preview tag means the option is considered experimental and is not recommended for production environments. While it can include new features and improvements, it may still contain bugs or undergo significant changes before reaching a stable version. tags: - Tech-Preview # Additional attributes attributes: title: This is my editor # (MANDATORY) The publisher name publisher: publisher # (MANDATORY) The editor version version: version repository: https://github.com/editor/repository/ firstPublicationDate: '2024-01-01' iconMediatype: image/svg+xml iconData: | <icon-content> # List of editor components components: # Name of the component - name: che-code-injector # Configuration of devworkspace-related container container: # Image of the container image: 'quay.io/che-incubator/che-code:insiders' # The command to run in the dockerimage component instead of the default one provided in the image command: - /entrypoint-init-container.sh # (OPTIONAL) List of volumes mounts that should be mounted in this container volumeMounts: # The name of the mount - name: checode # The path of the mount path: /checode # (OPTIONAL) The memory limit of the container memoryLimit: 256Mi # (OPTIONAL) The memory request of the container memoryRequest: 32Mi # (OPTIONAL) The CPU limit of the container cpuLimit: 500m # (OPTIONAL) The CPU request of the container cpuRequest: 30m # Name of the component - name: che-code-runtime-description # (OPTIONAL) Map of implementation-dependant free-form YAML attributes attributes: # The component within the architecture app.kubernetes.io/component: che-code-runtime # The name of a higher level application this one is part of app.kubernetes.io/part-of: che-code.eclipse.org # Defines a container component as a "container contribution". If a flattened DevWorkspace has a container component with the merge-contribution attribute, then any container contributions are merged into that container component controller.devfile.io/container-contribution: true container: # Can be a dummy image because the component is expected to be injected into workspace dev component image: quay.io/devfile/universal-developer-image:latest # (OPTIONAL) List of volume mounts that should be mounted in this container volumeMounts: # The name of the mount - name: checode # (OPTIONAL) The path in the component container where the volume should be mounted. If no path is defined, the default path is the is /<name> path: /checode # (OPTIONAL) The memory limit of the container memoryLimit: 1024Mi # (OPTIONAL) The memory request of the container memoryRequest: 256Mi # (OPTIONAL) The CPU limit of the container cpuLimit: 500m # (OPTIONAL) The CPU request of the container cpuRequest: 30m # (OPTIONAL) Environment variables used in this container env: - name: ENV_NAME value: value # Component endpoints endpoints: # Name of the editor - name: che-code # (OPTIONAL) Map of implementation-dependant string-based free-form attributes attributes: # Type of the endpoint. You can only set its value to main, indicating that the endpoint should be used as the mainUrl in the workspace status (i.e. it should be the URL used to access the editor in this context) type: main # An attribute that instructs the service to automatically redirect the unauthenticated requests for current user authentication. Setting this attribute to true has security consequences because it makes Cross-site request forgery (CSRF) attacks possible. The default value of the attribute is false. cookiesAuthEnabled: true # Defines an endpoint as "discoverable", meaning that a service should be created using the endpoint name (i.e. instead of generating a service name for all endpoints, this endpoint should be statically accessible) discoverable: false # Used to secure the endpoint with authorization on OpenShift, so that not anyone on the cluster can access the endpoint, the attribute enables authentication. urlRewriteSupported: true # Port number to be used within the container component targetPort: 3100 # (OPTIONAL) Describes how the endpoint should be exposed on the network (public, internal, none) exposure: public # (OPTIONAL) Describes whether the endpoint should be secured and protected by some authentication process secure: true # (OPTIONAL) Describes the application and transport protocols of the traffic that will go through this endpoint protocol: https # Mandatory name that allows referencing the component from other elements - name: checode # (OPTIONAL) Allows specifying the definition of a volume shared by several other components. Ephemeral volumes are not stored persistently across restarts. Defaults to false volume: {ephemeral: true} # (OPTIONAL) Bindings of commands to events. Each command is referred-to by its name events: # IDs of commands that should be executed before the devworkspace start. These commands would typically be executed in an init container preStart: - init-container-command # IDs of commands that should be executed after the devworkspace has completely started. In the case of Che-Code, these commands should be executed after all plugins and extensions have started, including project cloning. This means that those commands are not triggered until the user opens the IDE within the browser postStart: - init-che-code-command # (OPTIONAL) Predefined, ready-to-use, devworkspace-related commands commands: # Mandatory identifier that allows referencing this command - id: init-container-command apply: # Describes the component for the apply command component: che-code-injector # Mandatory identifier that allows referencing this command - id: init-che-code-command # CLI Command executed in an existing component container exec: # Describes component for the exec command component: che-code-runtime-description # The actual command-line string commandLine: 'nohup /checode/entrypoint-volume.sh > /checode/entrypoint-logs.txt 2>&1 &'
Copy to Clipboard Copied! 使用编辑器定义内容创建 ConfigMap:
oc create configmap my-editor-definition --from-file=my-editor-definition-devfile.yaml -n openshift-devspaces
oc create configmap my-editor-definition --from-file=my-editor-definition-devfile.yaml -n openshift-devspaces
Copy to Clipboard Copied! 在 ConfigMap 中添加所需的标签:
oc label configmap my-editor-definition app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=editor-definition -n openshift-devspaces
oc label configmap my-editor-definition app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=editor-definition -n openshift-devspaces
Copy to Clipboard Copied! - 刷新 OpenShift Dev Spaces Dashboard 页面,以查看新的可用编辑器。
4.10.2.1. 检索编辑器定义
OpenShift Dev Spaces 仪表板 API 也从以下 URL 提供编辑器定义:
https://<openshift_dev_spaces_fqdn>/dashboard/api/editors
对于 第 4.10.2 节 “配置编辑器定义” 中的示例,可以通过访问以下 URL 来检索编辑器定义:
https://<openshift_dev_spaces_fqdn> /dashboard/api/editors/devfile?che-editor=publisher/editor-name/version
从 OpenShift 集群中检索编辑器定义时,可以通过仪表板服务访问 OpenShift Dev Spaces 仪表板 API: http://devspaces-dashboard.openshift-devspaces.svc.cluster.local:8080/dashboard/api/editors
其他资源
- devfile 文档
- {editor-definition-samples-link}
4.10.3. 配置默认编辑器定义
了解如何配置 OpenShift Dev Spaces 默认编辑器定义。
流程
查找可用编辑器的 ID:
oc exec deploy/devspaces-dashboard -n openshift-devspaces \ -- curl -s http://localhost:8080/dashboard/api/editors | jq -r '.[] | "\(.metadata.attributes.publisher)/\(.metadata.name)/\(.metadata.attributes.version)"'
oc exec deploy/devspaces-dashboard -n openshift-devspaces \ -- curl -s http://localhost:8080/dashboard/api/editors | jq -r '.[] | "\(.metadata.attributes.publisher)/\(.metadata.name)/\(.metadata.attributes.version)"'
Copy to Clipboard Copied! 配置
defaultEditor
:oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p '{"spec":{"devEnvironments":{"defaultEditor": "<default_editor>"}}}'
oc patch checluster/devspaces \ --namespace openshift-devspaces \ --type='merge' \ -p '{"spec":{"devEnvironments":{"defaultEditor": "<default_editor>"}}}'
1 Copy to Clipboard Copied! - 1
- 可以使用插件 ID 或 URI 指定创建工作区的默认编辑器。插件 ID 的格式应为:
发布者/名称/版本
。请参阅第一步中的可用的编辑器 ID。
其他资源
- 第 4.10.2 节 “配置编辑器定义”
- 第 4.10.4 节 “Concealing 编辑器定义”
- {editor-definition-samples-link}
4.10.4. Concealing 编辑器定义
了解如何编写 OpenShift Dev Spaces 编辑器定义。当您想从 Dashboard UI 隐藏所选编辑器时,这非常有用,例如隐藏 IntelliJ IDEA Ultimate,且只有 Visual Studio Code - 开源可见。
流程
查找部署 OpenShift Dev Spaces Operator 的命名空间:
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
Copy to Clipboard Copied! 查找可用的编辑器定义文件:
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- ls /tmp/editors-definitions
oc exec -n $OPERATOR_NAMESPACE deploy/devspaces-operator -- ls /tmp/editors-definitions
Copy to Clipboard Copied! 输出应类似以下示例:
che-code-insiders.yaml che-code-latest.yaml che-idea-latest.yaml che-idea-next.yaml
che-code-insiders.yaml che-code-latest.yaml che-idea-latest.yaml che-idea-next.yaml
Copy to Clipboard Copied! 选择要 conceal 的编辑器定义。例如,要整合
che-idea-next.yaml
编辑器定义,请设置编辑器定义文件名称:CHE_EDITOR_CONCEAL_FILE_NAME=che-idea-next.yaml
CHE_EDITOR_CONCEAL_FILE_NAME=che-idea-next.yaml
Copy to Clipboard Copied! 为拥塞的编辑器定义定义 ConfigMap 名称:
CHE_EDITOR_CONCEAL_CONFIGMAP_NAME=che-conceal-$CHE_EDITOR_CONCEAL_FILE_NAME
CHE_EDITOR_CONCEAL_CONFIGMAP_NAME=che-conceal-$CHE_EDITOR_CONCEAL_FILE_NAME
Copy to Clipboard Copied! 创建 ConfigMap:
oc create configmap $CHE_EDITOR_CONCEAL_CONFIGMAP_NAME \ --namespace $OPERATOR_NAMESPACE \ --from-literal=$CHE_EDITOR_CONCEAL_FILE_NAME=""
oc create configmap $CHE_EDITOR_CONCEAL_CONFIGMAP_NAME \ --namespace $OPERATOR_NAMESPACE \ --from-literal=$CHE_EDITOR_CONCEAL_FILE_NAME=""
Copy to Clipboard Copied! 查找 Operator 订阅名称和命名空间(如果存在):
SUBSCRIPTION=$(oc get subscriptions \ --all-namespaces \ --output json \ | jq -r '.items[] | select(.spec.name=="devspaces")') SUBSCRIPTION_NAMESPACE=$(echo $SUBSCRIPTION | jq -r '.metadata.namespace') SUBSCRIPTION_NAME=$(echo $SUBSCRIPTION | jq -r '.metadata.name')
SUBSCRIPTION=$(oc get subscriptions \ --all-namespaces \ --output json \ | jq -r '.items[] | select(.spec.name=="devspaces")') SUBSCRIPTION_NAMESPACE=$(echo $SUBSCRIPTION | jq -r '.metadata.namespace') SUBSCRIPTION_NAME=$(echo $SUBSCRIPTION | jq -r '.metadata.name')
Copy to Clipboard Copied! 修补 Kubernetes 资源以使用空编辑器定义挂载 ConfigMap。要修补的资源取决于 Operator 订阅是否存在。如果订阅存在,则应该修补订阅。如果没有,请修补 Operator 部署:
if [[ -n $SUBSCRIPTION_NAMESPACE ]]; then if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config}') == "" ]]; then oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config", "value": {} }]' fi if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumes}') == "" ]]; then oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config/volumes", "value": [] }]' fi if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumeMounts}') == "" ]]; then oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config/volumeMounts", "value": [] }]' fi oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config/volumes/-", "value": { "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "configMap": { "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'" } } }, { "op":"add", "path":"/spec/config/volumeMounts/-", "value":{ "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'", "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'" } }]' else oc patch deployment devspaces-operator \ --namespace $OPERATOR_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/template/spec/volumes/-", "value": { "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "configMap": { "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'" } } }, { "op":"add", "path":"/spec/template/spec/containers/0/volumeMounts/-", "value":{ "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'", "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'" } } ]' fi
if [[ -n $SUBSCRIPTION_NAMESPACE ]]; then if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config}') == "" ]]; then oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config", "value": {} }]' fi if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumes}') == "" ]]; then oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config/volumes", "value": [] }]' fi if [[ $(oc get subscription $SUBSCRIPTION_NAME --namespace $SUBSCRIPTION_NAMESPACE --output jsonpath='{.spec.config.volumeMounts}') == "" ]]; then oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config/volumeMounts", "value": [] }]' fi oc patch subscription $SUBSCRIPTION_NAME \ --namespace $SUBSCRIPTION_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/config/volumes/-", "value": { "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "configMap": { "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'" } } }, { "op":"add", "path":"/spec/config/volumeMounts/-", "value":{ "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'", "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'" } }]' else oc patch deployment devspaces-operator \ --namespace $OPERATOR_NAMESPACE \ --type json \ --patch '[{ "op":"add", "path":"/spec/template/spec/volumes/-", "value": { "name":"'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "configMap": { "name": "'$CHE_EDITOR_CONCEAL_CONFIGMAP_NAME'" } } }, { "op":"add", "path":"/spec/template/spec/containers/0/volumeMounts/-", "value":{ "name": "'$(echo ${CHE_EDITOR_CONCEAL_FILE_NAME%.*})'", "subPath":"'$CHE_EDITOR_CONCEAL_FILE_NAME'", "mountPath": "/tmp/editors-definitions/'$CHE_EDITOR_CONCEAL_FILE_NAME'" } } ]' fi
Copy to Clipboard Copied!
其他资源
- 第 4.10.2 节 “配置编辑器定义”
- 第 4.10.3 节 “配置默认编辑器定义”
- {editor-definition-samples-link}
4.10.5. 自定义 OpenShift Eclipse Che ConsoleLink 图标
此流程描述了如何自定义 Red Hat OpenShift Dev Spaces ConsoleLink 图标。
先决条件
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 CLI 入门。
流程
创建 Secret:
oc apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: devspaces-dashboard-customization namespace: openshift-devspaces annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /public/dashboard/assets/branding labels: app.kubernetes.io/component: devspaces-dashboard-secret app.kubernetes.io/part-of: che.eclipse.org data: loader.svg: <Base64_encoded_content_of_the_image> type: Opaque EOF
oc apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: devspaces-dashboard-customization namespace: openshift-devspaces annotations: che.eclipse.org/mount-as: subpath che.eclipse.org/mount-path: /public/dashboard/assets/branding labels: app.kubernetes.io/component: devspaces-dashboard-secret app.kubernetes.io/part-of: che.eclipse.org data: loader.svg: <Base64_encoded_content_of_the_image>
1 type: Opaque EOF
Copy to Clipboard Copied! - 1
- 带有禁用行嵌套的 Base64 编码。
- 等待 devspaces-dashboard 的推出完成。
其他资源
4.11. 管理身份和授权
本节论述了管理 Red Hat OpenShift Dev Spaces 的身份和授权的不同方面。
4.11.1. 为 Git 供应商配置 OAuth
要启用实验性功能,在 Red Hat OpenShift Dev Spaces 中在启动时强制刷新个人访问令牌,请修改自定义资源配置,如下所示:
spec: components: cheServer: extraProperties: CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"
spec:
components:
cheServer:
extraProperties:
CHE_FORCE_REFRESH_PERSONAL_ACCESS_TOKEN: "true"
您可以在 OpenShift Dev Spaces 和 Git 供应商之间配置 OAuth,让用户能够处理远程 Git 存储库:
4.11.1.1. 为 GitHub 配置 OAuth 2.0
要让用户处理托管在 GitHub 上的远程 Git 存储库:
- 设置 GitHub OAuth 应用程序(OAuth 2.0)。
- 应用 GitHub OAuth App Secret。
4.11.1.1.1. 设置 GitHub OAuth 应用程序
使用 OAuth 2.0 设置 GitHub OAuth 应用程序。
先决条件
- 已登陆到 GitHub。
流程
- 进入 https://github.com/settings/applications/new。
输入以下值:
-
应用程序名称 : <
;application name>
-
Homepage URL:
https://<openshift_dev_spaces_fqdn>/
-
授权回调 URL:
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
-
应用程序名称 : <
- 点击 Register application。
- 点 Generate new client secret。
- 复制并保存应用 GitHub OAuth App Secret 时要使用的 GitHub OAuth 客户端 ID。
- 复制并保存 GitHub OAuth Client Secret,以便在应用 GitHub OAuth App Secret 时使用。
4.11.1.1.2. 应用 GitHub OAuth 应用程序 Secret
准备并应用 GitHub OAuth 应用程序 Secret。
先决条件
- 设置 GitHub OAuth 应用程序已完成。
在设置 GitHub OAuth App 时会生成以下值:
- GitHub OAuth 客户端 ID
- GitHub OAuth 客户端 Secret
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
准备 Secret:
kind: Secret apiVersion: v1 metadata: name: github-oauth-config namespace: openshift-devspaces 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> che.eclipse.org/scm-github-disable-subdomain-isolation: 'false' type: Opaque stringData: id: <GitHub_OAuth_Client_ID> secret: <GitHub_OAuth_Client_Secret>
kind: Secret apiVersion: v1 metadata: name: github-oauth-config namespace: openshift-devspaces
1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: github che.eclipse.org/scm-server-endpoint: <github_server_url>
2 che.eclipse.org/scm-github-disable-subdomain-isolation: 'false'
3 type: Opaque stringData: id: <GitHub_OAuth_Client_ID>
4 secret: <GitHub_OAuth_Client_Secret>
5 Copy to Clipboard Copied! 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 在输出中验证是否已创建 Secret。
要为另一个 GitHub 提供程序配置 OAuth 2.0,您必须重复上述步骤,并使用其他名称创建第二个 GitHub OAuth Secret。
4.11.1.2. 为 GitLab 配置 OAuth 2.0
允许用户处理使用 GitLab 实例托管的远程 Git 存储库:
- 设置 GitLab 授权应用程序(OAuth 2.0)。
- 应用 GitLab 授权应用程序 Secret。
4.11.1.2.1. 设置 GitLab 授权应用程序
使用 OAuth 2.0 设置 GitLab 授权应用程序。
先决条件
- 您已登录到 GitLab。
流程
- 点您的 avatar,再转到 → 。
- 输入 OpenShift Dev Spaces 作为 Name。
-
输入
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
作为 Redirect URI。 - 选中 机密和 过期访问令牌 复选框。
-
在 Scopes 下,选中
api
、write_repository
和openid
复选框。 - 单击 Save application。
- 复制并保存 GitLab 应用 ID,以便在应用 GitLab-authorized 应用程序 Secret 时使用。
- 复制并保存 GitLab 客户端 Secret,以便在应用 GitLab-authorized 应用程序 Secret 时使用。
其他资源
4.11.1.2.2. 应用 GitLab-authorized 应用程序 Secret
准备并应用 GitLab-authorized 应用程序 Secret。
先决条件
- 设置 GitLab 授权应用程序已完成。
在设置 GitLab 授权应用程序时生成的以下值是准备的:
- GitLab 应用程序 ID
- GitLab Client Secret
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
准备 Secret:
kind: Secret apiVersion: v1 metadata: name: gitlab-oauth-config namespace: openshift-devspaces 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> type: Opaque stringData: id: <GitLab_Application_ID> secret: <GitLab_Client_Secret>
kind: Secret apiVersion: v1 metadata: name: gitlab-oauth-config namespace: openshift-devspaces
1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: gitlab che.eclipse.org/scm-server-endpoint: <gitlab_server_url>
2 type: Opaque stringData: id: <GitLab_Application_ID>
3 secret: <GitLab_Client_Secret>
4 Copy to Clipboard Copied! 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 在输出中验证是否已创建 Secret。
要为另一个 Gitlab 提供程序配置 OAuth 2.0,您必须重复上面的步骤,并使用其他名称创建第二个 Gitlab OAuth Secret。
4.11.1.3. 为 Bitbucket 服务器配置 OAuth 2.0
您可以使用 OAuth 2.0 允许用户处理托管在 Bitbucket 服务器上的远程 Git 存储库:
- 在 Bitbucket 服务器上设置 OAuth 2.0 应用程序链接。
- 为 Bitbucket 服务器应用应用程序链接 Secret。
4.11.1.3.1. 在 Bitbucket 服务器上设置 OAuth 2.0 应用程序链接
在 Bitbucket 服务器上设置 OAuth 2.0 应用程序链接。
先决条件
- 您已登录到 Bitbucket 服务器。
流程
- 前往 Administration > Applications > Application links。
- 选择 Create link。
- 选择 External application and Incoming。
-
输入
https://<openshift_dev_spaces_fqdn> /api/oauth/callback
到 Redirect URL 字段。 - 在应用程序 权限 中选择 Admin - Write 复选框。
- 点击 Save。
- 复制并保存应用 Bitbucket 应用程序链接 Secret 时要使用的 客户端 ID。
- 复制并保存应用 Bitbucket 应用程序链接 Secret 时要使用的 Client secret。
其他资源
4.11.1.3.2. 为 Bitbucket 服务器应用 OAuth 2.0 应用程序链接 Secret
为 Bitbucket 服务器准备并应用 OAuth 2.0 应用程序链接 Secret。
先决条件
- 应用程序链接已在 Bitbucket 服务器上设置。
在设置 Bitbucket 应用程序链接时会生成以下值:
- Bitbucket 客户端 ID
- Bitbucket 客户端 secret
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
准备 Secret:
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url> type: Opaque stringData: id: <Bitbucket_Client_ID> secret: <Bitbucket_Client_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 che.eclipse.org/scm-server-endpoint: <bitbucket_server_url>
2 type: Opaque stringData: id: <Bitbucket_Client_ID>
3 secret: <Bitbucket_Client_Secret>
4 Copy to Clipboard Copied! 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 在输出中验证是否已创建 Secret。
4.11.1.4. 为 Bitbucket 云配置 OAuth 2.0
您可以允许用户处理在 Bitbucket 云托管的远程 Git 存储库:
- 在 Bitbucket 云中设置 OAuth 使用者(OAuth 2.0)。
- 为 Bitbucket 云应用 OAuth 使用者 Secret。
4.11.1.4.1. 在 Bitbucket 云中设置 OAuth 使用者
在 Bitbucket 云中为 OAuth 2.0 设置 OAuth 使用者。
先决条件
- 您已登录到 Bitbucket 云。
流程
- 点您的 avatar,再进入 All workspaces 页面。
- 选择一个工作区并点它。
- 前往 → → 。
- 输入 OpenShift Dev Spaces 作为 Name。
-
输入
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
作为 Callback URL。 - 在 权限 下,选中所有 帐户 和存储库复选框,然后单击保存。
- 扩展添加的消费者,然后复制并保存应用 Bitbucket OAuth 消费者 Secret 时使用的 Key 值:
- 复制并保存应用 Bitbucket OAuth 消费者 Secret 时使用的 Secret 值。
4.11.1.4.2. 为 Bitbucket 云应用 OAuth 消费者 Secret
为 Bitbucket 云准备并应用 OAuth 使用者 Secret。
先决条件
- OAuth 使用者在 Bitbucket 云中设置。
在设置 Bitbucket OAuth 使用者时会生成以下值:
- Bitbucket OAuth 消费者密钥
- Bitbucket OAuth 消费者 Secret
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
准备 Secret:
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket type: Opaque stringData: id: <Bitbucket_Oauth_Consumer_Key> secret: <Bitbucket_Oauth_Consumer_Secret>
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces
1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: bitbucket type: Opaque stringData: id: <Bitbucket_Oauth_Consumer_Key>
2 secret: <Bitbucket_Oauth_Consumer_Secret>
3 Copy to Clipboard Copied! 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 在输出中验证是否已创建 Secret。
4.11.1.5. 为 Bitbucket 服务器配置 OAuth 1.0
要让用户处理托管在 Bitbucket 服务器上的远程 Git 存储库:
- 在 Bitbucket 服务器上设置应用程序链接(OAuth 1.0)。
- 为 Bitbucket 服务器应用应用程序链接 Secret。
4.11.1.5.1. 在 Bitbucket 服务器上设置应用程序链接
在 Bitbucket 服务器上为 OAuth 1.0 设置应用程序链接。
先决条件
- 您已登录到 Bitbucket 服务器。
-
OpenSSL
安装在您正在使用的操作系统中。
流程
在命令行中,运行命令来为后续步骤创建必要的文件,并在应用应用程序链接 Secret 时使用:
openssl genrsa -out private.pem 2048 && \ openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in private.pem -out privatepkcs8.pem && \ cat privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n' > privatepkcs8-stripped.pem && \ openssl rsa -in private.pem -pubout > public.pub && \ cat public.pub | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > public-stripped.pub && \ openssl rand -base64 24 > bitbucket-consumer-key && \ openssl rand -base64 24 > bitbucket-shared-secret
$ openssl genrsa -out private.pem 2048 && \ openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in private.pem -out privatepkcs8.pem && \ cat privatepkcs8.pem | sed 's/-----BEGIN PRIVATE KEY-----//g' | sed 's/-----END PRIVATE KEY-----//g' | tr -d '\n' > privatepkcs8-stripped.pem && \ openssl rsa -in private.pem -pubout > public.pub && \ cat public.pub | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > public-stripped.pub && \ openssl rand -base64 24 > bitbucket-consumer-key && \ openssl rand -base64 24 > bitbucket-shared-secret
Copy to Clipboard Copied! - 前往 → 。
-
在 URL 字段中输入
https:// <openshift_dev_spaces_fqdn> /
,然后点击 Create new link。 - 在 所提供的 应用程序 URL 下已重定向一次,选中 Use this URL 复选框,然后单击 Continue。
- 输入 OpenShift Dev Spaces 作为 Application Name。
- 选择 Generic Application 作为 Application Type。
- 输入 OpenShift Dev Spaces 作为 Service Provider Name。
-
将
bitbucket-consumer-key
文件的内容粘贴为 Consumer 键。 -
将
bitbucket-shared-secret
文件的内容粘贴为 Shared secret。 -
输入
<bitbucket_server_url> /plugins/servlet/oauth/request-token
作为 Request Token URL。 -
输入
<bitbucket_server_url>/plugins/servlet/oauth/access-token
作为 Access token URL。 -
输入
<bitbucket_server_url> /plugins/servlet/oauth/authorize
作为 Authorize URL。 - 选中 Create incoming link 复选框,再单击 Continue。
-
将
bitbucket-consumer-key
文件的内容粘贴为 Consumer Key。 - 输入 OpenShift Dev Spaces 作为 Consumer 名称。
-
将
public-striped.pub 文件的内容
粘贴为 公钥,然后单击 Continue。
4.11.1.5.2. 为 Bitbucket 服务器应用应用程序链接 Secret
为 Bitbucket 服务器准备并应用应用程序链接 Secret。
先决条件
- 应用程序链接已在 Bitbucket 服务器上设置。
在设置应用程序链接时创建的以下文件已准备好:
-
privatepkcs8-stripped.pem
-
bitbucket-consumer-key
-
bitbucket-shared-secret
-
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
准备 Secret:
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url> type: Opaque stringData: private.key: <Content_of_privatepkcs8-stripped.pem> consumer.key: <Content_of_bitbucket-consumer-key> shared_secret: <Content_of_bitbucket-shared-secret>
kind: Secret apiVersion: v1 metadata: name: bitbucket-oauth-config namespace: openshift-devspaces
1 labels: app.kubernetes.io/component: oauth-scm-configuration app.kubernetes.io/part-of: che.eclipse.org annotations: che.eclipse.org/oauth-scm-server: bitbucket che.eclipse.org/scm-server-endpoint: <bitbucket_server_url>
2 type: Opaque stringData: private.key: <Content_of_privatepkcs8-stripped.pem>
3 consumer.key: <Content_of_bitbucket-consumer-key>
4 shared_secret: <Content_of_bitbucket-shared-secret>
5 Copy to Clipboard Copied! 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 在输出中验证是否已创建 Secret。
4.11.1.6. 为 Microsoft Azure DevOps 服务配置 OAuth 2.0
要让用户处理托管在 Microsoft Azure Repos 上的远程 Git 存储库:
- 设置 Microsoft Azure DevOps Services OAuth App (OAuth 2.0)。
- 应用 Microsoft Azure DevOps Services OAuth App Secret。
Azure DevOps Server 不支持 OAuth 2.0,请参阅文档页面。
4.11.1.6.1. 设置 Microsoft Azure DevOps Services OAuth 应用程序
使用 OAuth 2.0 设置 Microsoft Azure DevOps Services OAuth 应用程序。
先决条件
您已登录到 Microsoft Azure DevOps 服务。
重要为您的机构启用了
通过 OAuth 的第三方应用程序访问
。请参阅 更改您的机构应用程序连接和安全策略。流程
- Visit https://app.vsaex.visualstudio.com/app/register/.
输入以下值:
-
公司名称 :
OpenShift Dev Spaces
-
应用程序名称 :
OpenShift Dev Spaces
-
应用程序网站:
https:// <openshift_dev_spaces_fqdn>/
-
授权回调 URL:
https:// <openshift_dev_spaces_fqdn> /api/oauth/callback
-
公司名称 :
- 在 Select Authorized scopes 中,选择 Code (read and write)。
- 点 Create application。
- 复制并保存应用 Microsoft Azure DevOps Services OAuth App Secret 时要使用的 App ID。
- 单击 Show 以显示 Client Secret。
- 复制并保存应用 Microsoft Azure DevOps Services OAuth App Secret 时要使用的 客户端 Secret。
4.11.1.6.2. 应用 Microsoft Azure DevOps Services OAuth 应用程序 Secret
准备并应用 Microsoft Azure DevOps Services Secret。
先决条件
- 设置 Microsoft Azure DevOps Services OAuth 应用程序已完成。
在设置 Microsoft Azure DevOps Services OAuth App 时会生成以下值:
- 应用程序 ID
- Client Secret
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
准备 Secret:
kind: Secret apiVersion: v1 metadata: name: azure-devops-oauth-config namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: azure-devops type: Opaque stringData: id: <Microsoft_Azure_DevOps_Services_OAuth_App_ID> secret: <Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>
kind: Secret apiVersion: v1 metadata: name: azure-devops-oauth-config namespace: openshift-devspaces
1 labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: oauth-scm-configuration annotations: che.eclipse.org/oauth-scm-server: azure-devops type: Opaque stringData: id: <Microsoft_Azure_DevOps_Services_OAuth_App_ID>
2 secret: <Microsoft_Azure_DevOps_Services_OAuth_Client_Secret>
3 Copy to Clipboard Copied! 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
Copy to Clipboard Copied! - 在输出中验证是否已创建 Secret。
- 等待 OpenShift Dev Spaces 服务器组件的推出完成。
4.11.2. 为 Dev Spaces 用户配置集群角色
您可以通过在这些用户中添加集群角色来授予 OpenShift Dev Spaces 用户。
先决条件
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
定义用户角色名称:
USER_ROLES=<name>
$ USER_ROLES=<name>
1 Copy to Clipboard Copied! - 1
- 唯一的资源名称。
查找部署 OpenShift Dev Spaces Operator 的命名空间:
OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
$ OPERATOR_NAMESPACE=$(oc get pods -l app.kubernetes.io/component=devspaces-operator -o jsonpath={".items[0].metadata.namespace"} --all-namespaces)
Copy to Clipboard Copied! 创建所需的角色:
kubectl apply -f - <<EOF kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ${USER_ROLES} labels: app.kubernetes.io/part-of: che.eclipse.org rules: - verbs: - <verbs> apiGroups: - <apiGroups> resources: - <resources> EOF
$ kubectl apply -f - <<EOF kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ${USER_ROLES} labels: app.kubernetes.io/part-of: che.eclipse.org rules: - verbs: - <verbs>
1 apiGroups: - <apiGroups>
2 resources: - <resources>
3 EOF
Copy to Clipboard Copied! 将角色委托给 OpenShift Dev Spaces Operator:
kubectl apply -f - <<EOF kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ${USER_ROLES} labels: app.kubernetes.io/part-of: che.eclipse.org subjects: - kind: ServiceAccount name: devspaces-operator namespace: ${OPERATOR_NAMESPACE} roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ${USER_ROLES} EOF
$ kubectl apply -f - <<EOF kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: ${USER_ROLES} labels: app.kubernetes.io/part-of: che.eclipse.org subjects: - kind: ServiceAccount name: devspaces-operator namespace: ${OPERATOR_NAMESPACE} roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: ${USER_ROLES} EOF
Copy to Clipboard Copied! 配置 OpenShift Dev Spaces Operator,将角色委托给
che
服务帐户:kubectl patch checluster devspaces \ --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
$ kubectl patch checluster devspaces \ --patch '{"spec": {"components": {"cheServer": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
Copy to Clipboard Copied! 配置 OpenShift Dev Spaces 服务器,将角色委派给用户:
kubectl patch checluster devspaces \ --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
$ kubectl patch checluster devspaces \ --patch '{"spec": {"devEnvironments": {"user": {"clusterRoles": ["'${USER_ROLES}'"]}}}}' \ --type=merge -n openshift-devspaces
Copy to Clipboard Copied! - 等待 OpenShift Dev Spaces 服务器组件的推出完成。
- 询问用户退出并登录以应用新角色。
4.11.3. 配置高级授权
您可以确定允许哪些用户和组访问 OpenShift Dev Spaces。
先决条件
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
配置
CheCluster
自定义资源。请参阅 第 4.1.2 节 “使用 CLI 配置 CheCluster 自定义资源”。spec: networking: auth: advancedAuthorization: allowUsers: - <allow_users> allowGroups: - <allow_groups> denyUsers: - <deny_users> denyGroups: - <deny_groups>
spec: networking: auth: advancedAuthorization: allowUsers: - <allow_users>
1 allowGroups: - <allow_groups>
2 denyUsers: - <deny_users>
3 denyGroups: - <deny_groups>
4 Copy to Clipboard Copied! - 等待 OpenShift Dev Spaces 服务器组件的推出完成。
要允许用户访问 OpenShift Dev Spaces,请将它们添加到 allowUsers
列表中。或者,选择用户所属的组,并将组添加到 allowGroups
列表中。要拒绝用户访问 OpenShift Dev Spaces,请将它们添加到 denyUsers
列表中。或者,选择用户所属的组,并将组添加到 denyGroups
列表中。如果用户处于 allow
和 deny
列表,则他们会拒绝对 OpenShift Dev Spaces 的访问。
如果 allowUsers
和 allowGroups
为空,则所有用户都可以访问 OpenShift Dev Spaces,但拒绝
列表中的用户除外。如果 denyUsers
和 denyGroups
为空,则只允许来自 允许列表
中的用户访问 OpenShift Dev Spaces。
如果 allow
和 deny
列表都为空,则所有用户都可以访问 OpenShift Dev Spaces。
4.11.4. 删除用户数据以遵守 GDPR
您可以删除 OpenShift Container Platform 上的用户数据,以遵守强制实施其个人数据的 General Data Protection Regulation (GDPR)。其他 Kubernetes 基础架构的过程可能有所不同。按照您要用于 Red Hat OpenShift Dev Spaces 安装的供应商的用户管理最佳实践。
按如下所示删除用户数据是不可逆的!所有删除的数据都将被删除且无法恢复!
先决条件
-
具有 OpenShift Container Platform 集群的管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。
流程
使用以下命令列出 OpenShift 集群中的所有用户:
oc get users
$ oc get users
Copy to Clipboard Copied! - 删除用户条目:
如果用户有任何关联的资源(如项目、角色或服务帐户),则需要在删除用户前先删除这些资源。
oc delete user <username>
$ oc delete user <username>
4.12. 配置 fuse-overlayfs
默认情况下,通用基础镜像(UDI)包含 Podman 和 Buildah,您可以在工作区中构建和推送容器镜像。但是,UDI 中的 Podman 和 Buildah 被配置为使用 vfs
存储驱动程序,该驱动程序不提供写时复制支持。要更有效地镜像管理,请使用 fuse-overlayfs 存储驱动程序,该驱动程序在无根环境中支持 copy-on-write。
要为早于 4.15 的 OpenShift 版本启用 fuse-overlayfs,管理员必须首先通过 第 4.12.1 节 “为早于 4.15 的 OpenShift 版本启用访问” 在集群中启用 /dev/fuse
访问。
OpenShift 版本 4.15 及更高版本不需要这样做,因为 /dev/fuse
设备默认可用。请参阅 发行注记。
启用 /dev/fuse
访问后,可通过两种方式启用 fuse-overlayfs:
4.12.1. 为早于 4.15 的 OpenShift 版本启用访问
要使用 fuse-overlayfs,您必须首先使 /dev/fuse
可以被工作区容器访问。
OpenShift 版本 4.15 及更新的版本不需要这个过程,因为 /dev/fuse
设备默认可用。请参阅 发行注记。
在 OpenShift 集群中创建 MachineConfig
资源是一个潜在的危险任务,因为您要对集群进行高级系统级更改。
查看 MachineConfig 文档 以了解更多详情和可能的风险。
流程
根据 OpenShift 集群的类型设置环境变量:单一节点集群,或使用单独的 control plane 和 worker 节点的多节点集群。
对于单一节点集群,请设置:
NODE_ROLE=master
$ NODE_ROLE=master
Copy to Clipboard Copied! 对于多节点集群,请设置:
NODE_ROLE=worker
$ NODE_ROLE=worker
Copy to Clipboard Copied!
为 OpenShift Butane 配置版本设置环境变量。此变量是 OpenShift 集群的主版本和次要版本。例如:
4.12.0
、4.13.0
或4.14.0
。VERSION=4.12.0
$ VERSION=4.12.0
Copy to Clipboard Copied! 创建一个
MachineConfig
资源,在NODE_ROLE
节点上创建一个名为99-podman-fuse
的 drop-in CRI-O 配置文件。此配置文件可让您访问某些 pod 的/dev/fuse
设备。cat << EOF | butane | oc apply -f - variant: openshift version: ${VERSION} metadata: labels: machineconfiguration.openshift.io/role: ${NODE_ROLE} name: 99-podman-dev-fuse-${NODE_ROLE} storage: files: - path: /etc/crio/crio.conf.d/99-podman-fuse mode: 0644 overwrite: true contents: inline: | [crio.runtime.workloads.podman-fuse] activation_annotation = "io.openshift.podman-fuse" allowed_annotations = [ "io.kubernetes.cri-o.Devices" ] [crio.runtime] allowed_devices = ["/dev/fuse"] EOF
cat << EOF | butane | oc apply -f - variant: openshift version: ${VERSION} metadata: labels: machineconfiguration.openshift.io/role: ${NODE_ROLE} name: 99-podman-dev-fuse-${NODE_ROLE} storage: files: - path: /etc/crio/crio.conf.d/99-podman-fuse
1 mode: 0644 overwrite: true contents:
2 inline: | [crio.runtime.workloads.podman-fuse]
3 activation_annotation = "io.openshift.podman-fuse"
4 allowed_annotations = [ "io.kubernetes.cri-o.Devices"
5 ] [crio.runtime] allowed_devices = ["/dev/fuse"]
6 EOF
Copy to Clipboard Copied! 应用
MachineConfig
资源后,在应用更改时,会临时禁用具有worker
角色的每个节点调度。查看节点的状态。oc get nodes
$ oc get nodes
Copy to Clipboard Copied! 输出示例:
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.27.9 ip-10-0-136-243.ec2.internal Ready master 34m v1.27.9 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.27.9 ip-10-0-142-249.ec2.internal Ready master 34m v1.27.9 ip-10-0-153-11.ec2.internal Ready worker 28m v1.27.9 ip-10-0-153-150.ec2.internal Ready master 34m v1.27.9
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.27.9 ip-10-0-136-243.ec2.internal Ready master 34m v1.27.9 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.27.9 ip-10-0-142-249.ec2.internal Ready master 34m v1.27.9 ip-10-0-153-11.ec2.internal Ready worker 28m v1.27.9 ip-10-0-153-150.ec2.internal Ready master 34m v1.27.9
Copy to Clipboard Copied! 当所有具有
worker
角色的节点都处于Ready
状态后,/dev/fuse
可供带有以下注解的任何 pod 使用:io.openshift.podman-fuse: '' io.kubernetes.cri-o.Devices: /dev/fuse
io.openshift.podman-fuse: '' io.kubernetes.cri-o.Devices: /dev/fuse
Copy to Clipboard Copied!
验证步骤
获取具有
worker
角色的节点名称:oc get nodes
$ oc get nodes
Copy to Clipboard Copied! 打开到 worker 节点的
oc debug
会话。oc debug node/<nodename>
$ oc debug node/<nodename>
Copy to Clipboard Copied! 验证存在名为
99-podman-fuse
的新 CRI-O 配置文件。stat /host/etc/crio/crio.conf.d/99-podman-fuse
sh-4.4# stat /host/etc/crio/crio.conf.d/99-podman-fuse
Copy to Clipboard Copied!
4.12.1.1. 在工作区中为 Podman 和 Buildah 使用 fuse-overlayfs
用户可遵循 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.20/html-single/user_guide/index#end-user-guide:using-the-fuse-overlay-storage-driver 来更新现有工作区,为 Podman 和 Buildah 使用 fuse-overlayfs 存储驱动程序。
4.12.2. 为所有工作区启用 fuse-overlayfs
先决条件
- 第 4.12.1 节 “为早于 4.15 的 OpenShift 版本启用访问” 部分已完成。OpenShift 版本 4.15 及更新的版本不需要这样做。
-
对目标 OpenShift 集群具有管理权限的活动
oc
会话。请参阅 CLI 入门。
流程
创建一个 ConfigMap,为所有用户工作区挂载
storage.conf
文件。kind: ConfigMap apiVersion: v1 metadata: name: fuse-overlay namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.config/containers/ data: storage.conf: | [storage] driver = "overlay" [storage.options.overlay] mount_program="/usr/bin/fuse-overlayfs"
kind: ConfigMap apiVersion: v1 metadata: name: fuse-overlay namespace: openshift-devspaces labels: app.kubernetes.io/part-of: che.eclipse.org app.kubernetes.io/component: workspaces-config annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.config/containers/ data: storage.conf: | [storage] driver = "overlay" [storage.options.overlay] mount_program="/usr/bin/fuse-overlayfs"
Copy to Clipboard Copied! 警告创建此 ConfigMap 将导致所有正在运行的工作区重启。
在 CheCluster 自定义资源的
spec.devEnvironments.workspacesPodAnnotations
字段中设置所需的注解。kind: CheCluster apiVersion: org.eclipse.che/v2 spec: devEnvironments: workspacesPodAnnotations: io.kubernetes.cri-o.Devices: /dev/fuse
kind: CheCluster apiVersion: org.eclipse.che/v2 spec: devEnvironments: workspacesPodAnnotations: io.kubernetes.cri-o.Devices: /dev/fuse
Copy to Clipboard Copied! 注意对于 4.15 之前的 OpenShift 版本,还需要
io.openshift.podman-fuse: ""
注解。
验证步骤
启动工作区并验证存储驱动程序是否
覆盖
。podman info | grep overlay
$ podman info | grep overlay
Copy to Clipboard Copied! 输出示例:
graphDriverName: overlay overlay.mount_program: Executable: /usr/bin/fuse-overlayfs Package: fuse-overlayfs-1.12-1.module+el8.9.0+20326+387084d0.x86_64 fuse-overlayfs: version 1.12 Backing Filesystem: overlayfs
graphDriverName: overlay overlay.mount_program: Executable: /usr/bin/fuse-overlayfs Package: fuse-overlayfs-1.12-1.module+el8.9.0+20326+387084d0.x86_64 fuse-overlayfs: version 1.12 Backing Filesystem: overlayfs
Copy to Clipboard Copied! 注意现有工作区可能会出现以下错误:
ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "vfs" from database - delete libpod local files ("/home/user/.local/share/containers/storage") to resolve. May prevent use of images created by other tools
ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "vfs" from database - delete libpod local files ("/home/user/.local/share/containers/storage") to resolve. May prevent use of images created by other tools
Copy to Clipboard Copied! 在这种情况下,删除错误信息中所述的 libpod 本地文件。
第 5 章 管理 IDE 扩展
IDE 使用扩展或插件来扩展其功能,并且在 IDE 之间管理扩展的机制会有所不同。
5.1. Microsoft Visual Studio Code 的扩展 - 开源
要管理扩展,此 IDE 使用其中一个 Open VSX registry 实例:
-
在 OpenShift Dev Spaces 的
plugin-registry
pod 中运行 Open VSX registry 的嵌入式实例,以支持 air-gapped、offline 和 proxy-restricted 环境。嵌入的 Open VSX 注册表仅包含 open-vsx.org 上发布的扩展的子集。此子集 可自定义。 - 通过互联网访问的公共 open-vsx.org 注册表。
- 部署到可从 OpenShift Dev Spaces 工作区 Pod 访问的网络上的独立 Open VSX registry 实例。
默认为 Open VSX 注册表的嵌入式实例。
5.1.1. 选择 Open VSX 注册表实例
默认为 Open VSX 注册表的嵌入式实例。
如果默认的 Open VSX registry 实例不是您需要的,您可以选择以下实例之一:
-
https://open-vsx.org
中的 Open VSX registry 实例需要访问互联网。 - 部署到可从 OpenShift Dev Spaces 工作区 Pod 访问的网络上的独立 Open VSX registry 实例。
流程
编辑
CheCluster
自定义资源中的openVSXURL
值:spec: components: pluginRegistry: openVSXURL: "<url_of_an_open_vsx_registry_instance>"
spec: components: pluginRegistry: openVSXURL: "<url_of_an_open_vsx_registry_instance>"
1 Copy to Clipboard Copied! - 1
- 例如:
openVSXURL: "https://open-vsx.org"
。
重要- 在 air-gapped 环境中不建议使用 https://open-vsx.org,这会与互联网隔离。为了降低恶意软件入侵和未授权访问代码的风险,请使用带有策展的扩展集嵌入或自托管的 Open VSX registry。
-
要在
plugin-registry
pod 中选择嵌入的 Open VSX registry 实例,请使用openVSXURL: ''
。您可以自定义包含的扩展的列表。 -
如果从机构的集群内部访问 URL,您也可以将
openVSXURL
指向独立 Open VSX registry 实例的 URL,且不会被代理阻止。
5.1.2. 在嵌入式 Open VSX registry 实例中添加或删除扩展
您可以在嵌入式 Open VSX registry 实例中添加或删除扩展。这会生成 Open VSX 注册表的自定义构建,可在您组织的工作区中使用。
要在 OpenShift Dev Spaces 更新后获取最新的安全修复,请基于 latest 标签或 SHA 重建容器。
流程
获取每个所选扩展的发布程序和扩展名称:
- 在 Open VSX 注册表网站 中找到扩展,并复制扩展列表页面和扩展名版本的 URL。
从复制的 URL 中提取 & lt;publisher > 和 <extension> name:
https://open-vsx.org/extension/<publisher>/<name>
https://open-vsx.org/extension/<publisher>/<name>
Copy to Clipboard Copied! 提示如果扩展只能从 Microsoft Visual Studio Marketplace 提供,但没有 Open VSX,您可以要求扩展发布程序,根据 这些说明 在 open-vsx.org 上发布,可能会使用此 GitHub 操作。
如果扩展发布者不可用或不希望将扩展发布到 open-vsx.org,且没有与扩展相对应的 Open VSX,考虑使用向 Open VSX 团队报告问题。
构建自定义插件 registry 镜像并更新 CheCluster 自定义资源:
提示- 在构建过程中,将验证每个扩展是否与 OpenShift Dev Spaces 中使用的 Visual Studio Code 版本兼容。
使用 OpenShift Dev Spaces 实例:
重要对于 IBM Power (
ppc64le
)和 IBM Z (s390x
),自定义插件 registry 应该在对应的架构本地构建。- 以管理员身份登录到 OpenShift Dev Spaces 实例。
创建新的 Red Hat Registry Service Account 并复制用户名和令牌。
- 使用插件 registry 存储库 启动工作区。
打开一个终端,再签出与 OpenShift Dev Spaces 版本对应的 Git 标签(例如,
devspaces-3.15-rhel-8
):git checkout devspaces-$PRODUCT_VERSION-rhel-8
git checkout devspaces-$PRODUCT_VERSION-rhel-8
Copy to Clipboard Copied! -
打开
openvsx-sync.json
文件并添加或删除扩展。 -
执行
1。登录到工作区中的 registry.redhat.io
任务(Terminal → Run Task… → devfile → 1。登录 registry.redhat.io,并登录到 registry.redhat.io。 -
执行
2。build 和 Publish a Custom Plugin Registry
任务在工作区(Terminal → Run Task… → devfile → 2 中。构建和发布自定义插件 registry。 执行
3。将 Che 配置为使用 Custom Plugin Registry
任务(Terminal → Run Task… → devfile → 3。配置 Che 以使用自定义插件 Registry。使用 Linux 操作系统:
提示- Podman 和 NodeJS 版本 18.20.3 或更高版本应该安装到系统中。
- 下载或分叉并克隆 Dev Spaces 存储库。
git clone https://github.com/redhat-developer/devspaces.git
git clone https://github.com/redhat-developer/devspaces.git
+
- 进入插件 registry 子模块:
cd devspaces/dependencies/che-plugin-registry/
cd devspaces/dependencies/che-plugin-registry/
+
签出与 OpenShift Dev Spaces 版本对应的标签(如
devspaces-3.15-rhel-8
):git checkout devspaces-$PRODUCT_VERSION-rhel-8
git checkout devspaces-$PRODUCT_VERSION-rhel-8
Copy to Clipboard Copied! - 创建新的 Red Hat Registry Service Account 并复制用户名和令牌。
登录到 registry.redhat.io :
podman login registry.redhat.io
podman login registry.redhat.io
Copy to Clipboard Copied! 对于需要添加或删除的每个扩展,编辑
openvsx-sync.json
文件 :-
要添加扩展,请将发布程序、名称和扩展版本添加到
openvsx-sync.json
文件中。 -
要删除扩展,请从
openvsx-sync.json
文件中删除发布者、名称和扩展版本。 使用以下 JSON 语法:
{ "id": "<publisher>.<name>", "version": "<extension_version>" }
{ "id": "<publisher>.<name>", "version": "<extension_version>" }
Copy to Clipboard Copied! 提示如果您有一个闭源扩展,或者只为机构内部使用创建的扩展,您可以使用自定义插件 registry 容器可访问的 URL 从
.vsix
文件添加扩展:{ "id": "<publisher>.<name>", "download": "<url_to_download_vsix_file>", "version": "<extension_version>" }
{ "id": "<publisher>.<name>", "download": "<url_to_download_vsix_file>", "version": "<extension_version>" }
Copy to Clipboard Copied! - 在使用资源之前,请阅读 Microsoft Visual Studio Marketplace 使用条款。
-
要添加扩展,请将发布程序、名称和扩展版本添加到
构建插件 registry 容器镜像,并将其发布到容器 registry 中,如 quay.io :
./build.sh -o <username> -r quay.io -t custom
$ ./build.sh -o <username> -r quay.io -t custom
Copy to Clipboard Copied! podman push quay.io/<username/plugin_registry:custom>
$ podman push quay.io/<username/plugin_registry:custom>
Copy to Clipboard Copied!
编辑您机构的集群中的
CheCluster
自定义资源以指向镜像(例如在 quay.io上)并保存更改:spec: components: pluginRegistry: deployment: containers: - image: quay.io/<username/plugin_registry:custom> openVSXURL: ''
spec: components: pluginRegistry: deployment: containers: - image: quay.io/<username/plugin_registry:custom> openVSXURL: ''
Copy to Clipboard Copied!
验证
-
检查
plugin-registry
pod 是否已重启并在运行。 - 重启工作区,并检查工作区 IDE 的 Extensions 视图中的可用扩展。
5.2. 打开 VSX 注册表 URL
为搜索和安装扩展,Microsoft Visual Studio Code - 开源编辑器使用嵌入的 Open VSX 注册表实例。您还可以将 OpenShift Dev Spaces 配置为使用另一个 Open VSX registry 实例,而不是嵌入的实例。
流程
在 CheCluster Custom Resource
spec.components.pluginRegistry.openVSXURL
字段中设置 Open VSX registry 实例的 URL。spec: components: # [...] pluginRegistry: openVSXURL: <your_open_vsx_registy> # [...]
spec: components: # [...] pluginRegistry: openVSXURL: <your_open_vsx_registy> # [...]
Copy to Clipboard Copied! 警告由于使用 的专用 Microsoft 术语,Red Hat OpenShift Dev Spaces 不支持Visual Studio Code Marketplace。
第 6 章 配置 Visual Studio Code - 开源("Code - OSS")
了解如何配置 Visual Studio Code - 开源("代码 - OSS")。
6.1. 配置单个和多根工作区
使用多根工作区功能,您可以处理同一工作区中的多个项目文件夹。当您一次性处理多个相关项目时,这很有用,如产品文档和产品代码存储库。
请参阅什么是 VS Code 工作区,以更好地理解和编写工作空间文件。
默认情况下,工作区设置为在多 root 模式中打开。
启动工作区后,将生成 /projects/.code-workspace
工作区文件。工作区文件将包含 devfile 中描述的所有项目。
{ "folders": [ { "name": "project-1", "path": "/projects/project-1" }, { "name": "project-2", "path": "/projects/project-2" } ] }
{
"folders": [
{
"name": "project-1",
"path": "/projects/project-1"
},
{
"name": "project-2",
"path": "/projects/project-2"
}
]
}
如果工作区文件已存在,则会更新它,所有缺少的项目都会从 devfile 中获取。如果您从 devfile 中删除项目,它将保留在工作区文件中。
您可以更改默认行为,并提供自己的工作区文件,或切换到单根工作区。
流程
提供您自己的工作区文件。
将名为
.code-workspace
的工作区文件放在存储库的根目录中。创建工作空间后,Visual Studio Code - 开源("Code - OSS")将像其一样使用工作区文件。{ "folders": [ { "name": "project-name", "path": "." } ] }
{ "folders": [ { "name": "project-name", "path": "." } ] }
Copy to Clipboard Copied! 重要创建工作区文件时请小心。如果出现错误,则会打开一个空的 Visual Studio Code - Open Source ("Code - OSS")。
重要如果您有多个项目,则工作区文件将从第一个项目获取。如果第一个项目中没有工作区文件,则会创建一个新文件,并放入
/projects
目录中。
指定替代的工作区文件。
在 devfile 中定义 VSCODE_DEFAULT_WORKSPACE 环境变量,并将正确的位置指定到工作区文件。
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/projects/project-name/workspace-file"
Copy to Clipboard Copied!
在单根模式下打开工作区。
定义 VSCODE_DEFAULT_WORKSPACE 环境变量,并将它设为 root。
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"
env: - name: VSCODE_DEFAULT_WORKSPACE value: "/"
Copy to Clipboard Copied!
6.2. 为 Microsoft Visual Studio Code 配置可信扩展
您可以使用 Microsoft Visual Studio Code 的 product.json
文件中的 trustedExtensionAuthAccess
字段指定哪些扩展是可信的,以访问身份验证令牌。
"trustedExtensionAuthAccess": [ "<publisher1>.<extension1>", "<publisher2>.<extension2>" ]
"trustedExtensionAuthAccess": [
"<publisher1>.<extension1>",
"<publisher2>.<extension2>"
]
当您拥有需要访问 GitHub、Microsoft 或任何需要 OAuth 的其他服务的扩展时,这特别有用。通过在此字段中添加扩展 ID,授予他们访问这些令牌的权限。
您可以在 devfile 或 ConfigMap 中定义变量。选择最适合您需求的选项。使用 ConfigMap 时,变量将在所有工作区上传播,您不需要将变量添加到您使用的每个 devfile 中。
使用 trustedExtensionAuthAccess
字段请小心,因为它可能会导致安全风险。仅授予对可信扩展的访问权限。
由于 Microsoft Visual Studio Code 编辑器在 che-code
镜像中捆绑在一起,因此您只能在工作区启动时更改 product.json
文件。
定义 VSCODE_TRUSTED_EXTENSIONS 环境变量。在 devfile.yaml 中定义变量,或使用变量挂载 ConfigMap。
在 devfile.yaml 中定义 VSCODE_TRUSTED_EXTENSIONS 环境变量:
env: - name: VSCODE_TRUSTED_EXTENSIONS value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
env: - name: VSCODE_TRUSTED_EXTENSIONS value: "<publisher1>.<extension1>,<publisher2>.<extension2>"
Copy to Clipboard Copied! 使用 VSCODE_TRUSTED_EXTENSIONS 环境变量挂载 ConfigMap:
kind: ConfigMap apiVersion: v1 metadata: name: trusted-extensions labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: env data: VSCODE_TRUSTED_EXTENSIONS: '<publisher1>.<extension1>,<publisher2>.<extension2>'
kind: ConfigMap apiVersion: v1 metadata: name: trusted-extensions labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: env data: VSCODE_TRUSTED_EXTENSIONS: '<publisher1>.<extension1>,<publisher2>.<extension2>'
Copy to Clipboard Copied!
验证
-
变量的值将在工作区启动时解析,对应的
trustedExtensionAuthAccess
部分将添加到product.json
中。
6.3. 配置默认扩展
默认扩展是一组预安装的扩展,通过将扩展二进制 .vsix
文件路径放在 DEFAULT_EXTENSIONS 环境变量来指定。
启动后,编辑器会检查此环境变量,如果指定了,则提取到扩展的路径,并将其安装到后台,而不会干扰用户。
配置默认扩展对于从编辑器级别安装 .vsix 扩展非常有用。
如果要指定多个扩展,以分号分隔它们。
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
DEFAULT_EXTENSIONS='/projects/extension-1.vsix;/projects/extension-2.vsix'
阅读内容,了解如何定义 DEFAULT_EXTENSIONS 环境变量,包括将 .vsix
文件添加到工作区的多个示例。
将默认 .vsix
扩展嵌入到工作区中有三种不同的方法:
- 将扩展二进制文件放在源存储库中。
-
使用 devfile
postStart
事件从网络获取扩展二进制文件。 -
在
che-code
镜像中包括扩展的.vsix
二进制文件。
将扩展二进制文件放在源存储库中
将扩展二进制文件放入 Git 存储库并在 devfile 中定义环境变量是向工作区添加默认扩展的最简单方法。如果存储库 root 中存在 extension.vsix
文件,您可以为工具容器设置 DEFAULT_EXTENSIONS。
流程
在
.devfile.yaml
中指定 DEFAULT_EXTENSIONS,如下例所示:schemaVersion: 2.3.0 metadata: generateName: example-project components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest env: - name: 'DEFAULT_EXTENSIONS' value: '/projects/example-project/extension.vsix'
schemaVersion: 2.3.0 metadata: generateName: example-project components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest env: - name: 'DEFAULT_EXTENSIONS' value: '/projects/example-project/extension.vsix'
Copy to Clipboard Copied!
使用 devfile postStart 事件从网络获取扩展二进制文件
您可以使用 cURL 或 GNU Wget 将扩展下载到您的工作区。为此,您需要:
- 指定 devfile 命令,将扩展下载到您的工作中
-
添加
postStart
事件,以在工作空间启动时运行命令 - 在 devfile 中定义 DEFAULT_EXTENSIONS 环境变量
流程
将以下示例中显示的值添加到 devfile 中:
schemaVersion: 2.3.0 metadata: generateName: example-project components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest env: - name: DEFAULT_EXTENSIONS value: '/tmp/extension-1.vsix;/tmp/extension-2.vsix' commands: - id: add-default-extensions exec: # name of the tooling container component: tools # download several extensions using curl commandLine: | curl https://.../extension-1.vsix --location -o /tmp/extension-1.vsix curl https://.../extension-2.vsix --location -o /tmp/extension-2.vsix events: postStart: - add-default-extensions
schemaVersion: 2.3.0 metadata: generateName: example-project components: - name: tools container: image: quay.io/devfile/universal-developer-image:ubi8-latest env: - name: DEFAULT_EXTENSIONS value: '/tmp/extension-1.vsix;/tmp/extension-2.vsix' commands: - id: add-default-extensions exec: # name of the tooling container component: tools # download several extensions using curl commandLine: | curl https://.../extension-1.vsix --location -o /tmp/extension-1.vsix curl https://.../extension-2.vsix --location -o /tmp/extension-2.vsix events: postStart: - add-default-extensions
Copy to Clipboard Copied! 警告在某些情况下,curl 可能会下载
.gzip
压缩文件。这可能会使安装扩展不可能。要修复尝试将文件保存为 .vsix.gz 文件,然后使用 gunzip 解压缩该文件。这会将 .vsix.gz 文件替换为解压缩的 .vsix 文件。curl https://some-extension-url --location -o /tmp/extension.vsix.gz gunzip /tmp/extension.vsix.gz
curl https://some-extension-url --location -o /tmp/extension.vsix.gz gunzip /tmp/extension.vsix.gz
Copy to Clipboard Copied!
在 che-code
镜像中包括扩展 .vsix
二进制文件。
使用编辑器镜像中捆绑的默认扩展,以及 ConfigMap 中定义的 DEFAULT_EXTENSIONS 环境变量,您可以在不更改 devfile 的情况下应用默认扩展。
按照以下步骤为编辑器镜像添加所需的扩展。
流程
-
创建一个目录,并将您选择的
.vsix
扩展放在这个目录中。 使用以下内容创建 Dockerfile:
inherit che-incubator/che-code:latest copy all .vsix files to /default-extensions directory add instruction to the script to copy default extensions to the working container
# inherit che-incubator/che-code:latest FROM quay.io/che-incubator/che-code:latest USER 0 # copy all .vsix files to /default-extensions directory RUN mkdir --mode=775 /default-extensions COPY --chmod=755 *.vsix /default-extensions/ # add instruction to the script to copy default extensions to the working container RUN echo "cp -r /default-extensions /checode/" >> /entrypoint-init-container.sh
Copy to Clipboard Copied! 构建镜像并将其推送到 registry:
docker build -t yourname/che-code:next . docker push yourname/che-code:next
$ docker build -t yourname/che-code:next . $ docker push yourname/che-code:next
Copy to Clipboard Copied! 将新 ConfigMap 添加到用户的项目中,定义 DEFAULT_EXTENSIONS 环境变量,并指定扩展的绝对路径。此 ConfigMap 将环境变量设置为用户项目中的所有工作区。
kind: ConfigMap apiVersion: v1 metadata: name: vscode-default-extensions labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: env data: DEFAULT_EXTENSIONS: '/checode/default-extensions/extension1.vsix;/checode/default-extensions/extension2.vsix'
kind: ConfigMap apiVersion: v1 metadata: name: vscode-default-extensions labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: env data: DEFAULT_EXTENSIONS: '/checode/default-extensions/extension1.vsix;/checode/default-extensions/extension2.vsix'
Copy to Clipboard Copied! 使用
yourname/che-code:next
镜像创建工作区。首先,打开仪表板并导航到左侧的 Create Workspace 选项卡。- 在 Editor Selector 部分中,展开 使用 Editor Definition 下拉菜单,并将编辑器 URI 设置为 Editor Image。
- 点任何示例或使用 Git 存储库 URL 创建工作区。
6.4. 应用编辑器配置
您可以通过在 ConfigMap 中添加配置来配置 Visual Studio Code - 开源编辑器。这些配置应用于您打开的任何工作区。启动工作区后,编辑器会检查此 ConfigMap 并将配置存储到对应的配置文件中。
目前支持以下部分:
- settings.json
- extensions.json
- product.json
- configurations.json
settings.json 部分包含各种设置,您可以在其中自定义代码 - OSS 编辑器的不同部分。
extensions.json 部分包含启动工作区时安装的推荐扩展。
product.json 部分包含您需要添加到编辑器的 product.json 文件中的属性。如果属性已存在,则其值将更新。
configuration .json 部分包含与 Code - OSS 编辑器配置相关的属性。例如,您可以使用 extensions.install-from-vsix-enabled
属性来禁用 来自 VSIX 命令的 Install
。
流程
在用户的项目中添加一个新的 ConfigMap,定义支持的部分,并指定您要添加的属性。
apiVersion: v1 kind: ConfigMap metadata: name: vscode-editor-configurations labels: app.kubernetes.io/part-of: che.eclipse.org data: extensions.json: | { "recommendations": [ "dbaeumer.vscode-eslint", "github.vscode-pull-request-github" ] } settings.json: | { "window.header": "A HEADER MESSAGE", "window.commandCenter": false, "workbench.colorCustomizations": { "titleBar.activeBackground": "#CCA700", "titleBar.activeForeground": "#ffffff" } } product.json: | { "extensionEnabledApiProposals": { "ms-python.python": [ "contribEditorContentMenu", "quickPickSortByLabel", ] }, "trustedExtensionAuthAccess": [ "<publisher1>.<extension1>", "<publisher2>.<extension2>" ] } configurations.json: | { "extensions.install-from-vsix-enabled": false }
apiVersion: v1 kind: ConfigMap metadata: name: vscode-editor-configurations labels: app.kubernetes.io/part-of: che.eclipse.org data: extensions.json: | { "recommendations": [ "dbaeumer.vscode-eslint", "github.vscode-pull-request-github" ] } settings.json: | { "window.header": "A HEADER MESSAGE", "window.commandCenter": false, "workbench.colorCustomizations": { "titleBar.activeBackground": "#CCA700", "titleBar.activeForeground": "#ffffff" } } product.json: | { "extensionEnabledApiProposals": { "ms-python.python": [ "contribEditorContentMenu", "quickPickSortByLabel", ] }, "trustedExtensionAuthAccess": [ "<publisher1>.<extension1>", "<publisher2>.<extension2>" ] } configurations.json: | { "extensions.install-from-vsix-enabled": false }
Copy to Clipboard Copied! - 启动或重启工作区
确保 Configmap 包含有效 JSON 格式的数据。
考虑将 ConfigMap 添加到 openshift-devspaces 命名空间中。它允许在所有用户命名空间中复制 ConfigMap,同时防止在用户命名空间内进行修改。请参阅 第 4.2.3 节 “配置用户命名空间”。
验证
使用以下方法之一验证 ConfigMap 中定义的设置是否已应用:
-
使用
F1 → Preferences: Open Remote Settings
检查是否应用了定义的设置。 -
使用
F1 → File: Open File: Open File: Open File…
命令,确保/checode/remote/data/Machine/settings.json
文件中存在 ConfigMap 中的设置。
-
使用
验证是否应用了 ConfigMap 中定义的扩展:
-
进入
Extensions
视图(F1 → View: Show Extensions
),检查是否已安装了扩展 -
使用
F1 → File: Open File: Open File: Open File…
命令,确保.code-workspace
文件中存在 ConfigMap 中的扩展。默认情况下,工作区文件放置在/projects/.code-workspace
中。
-
进入
验证 ConfigMap 中定义的产品属性是否已添加到 Visual Studio Code product.json 中:
-
打开一个终端,运行命令
cat /checode/entrypoint-logs.txt | grep "Node.js dir"
,并复制 Visual Studio Code 路径。 -
按
Ctrl + O
,粘贴复制的路径并打开 product.json 文件。 - 确保 product.json 文件包含 ConfigMap 中定义的所有属性。
-
打开一个终端,运行命令
验证 ConfigMap 中定义的
extensions.install-from-vsix-enabled
属性是否已应用到代码 - OSS 编辑器:-
打开 Command appears (use
F1
),以检查命令列表中是否不存在Install from VSIX
命令。 -
使用
F1 → Open View → Extensions
打开Extensions
面板,然后点…
on the view (Views and More Actions
tooltip),检查操作列表中是否缺少Install from VSIX
操作。 -
进入 Explorer,找到带有
vsix
扩展名的文件(redhat.vscode-yaml-1.17.0.vsix),打开该文件的菜单。在菜单中应不存在 VSIX
操作中的安装。
-
打开 Command appears (use
第 7 章 使用 Dev Spaces 服务器 API
要管理 OpenShift Dev Spaces 服务器工作负载,请使用 Swagger Web 用户界面来浏览 OpenShift Dev Spaces 服务器 API。
流程
-
导航到 Swagger API web 用户界面:
https:// <openshift_dev_spaces_fqdn> /swagger
。
其他资源
第 8 章 升级 Dev Spaces
本章论述了如何从 CodeReady Workspaces 3.1 升级到 OpenShift Dev Spaces 3.20。
8.1. 升级 chectl 管理工具
这部分论述了如何升级 dsc
管理工具。
8.2. 指定更新批准策略
Red Hat OpenShift Dev Spaces Operator 支持两个升级策略:
自动
- Operator 会在有新更新可用时安装新的更新。
Manual(手动)
- 在开始安装前,需要手动批准新的更新。
您可以使用 OpenShift Web 控制台为 Red Hat OpenShift Dev Spaces Operator 指定更新批准策略。
先决条件
- 集群管理员的 OpenShift Web 控制台会话。请参阅 访问 Web 控制台。
- 使用红帽生态系统目录安装的 OpenShift Dev Spaces 实例。
流程
- 在 OpenShift Web 控制台中,导航到 → 。
- 在安装的 Operator 列表中点 Red Hat OpenShift Dev Spaces。
- 进入到 Subscription 选项卡。
-
将 Update 批准策略 配置为
Automatic
或Manual
。
其他资源
8.3. 使用 OpenShift Web 控制台升级 Dev Spaces
您可以使用 OpenShift Web 控制台中的 Red Hat OpenShift Dev Spaces Operator 从早期的次版本手动批准升级。
先决条件
- 集群管理员的 OpenShift Web 控制台会话。请参阅 访问 Web 控制台。
- 使用红帽生态系统目录安装的 OpenShift Dev Spaces 实例。
-
订阅的批准策略是
Manual
。请参阅 第 8.2 节 “指定更新批准策略”。
流程
- 手动批准待处理的 Red Hat OpenShift Dev Spaces Operator 升级。请参阅 手动批准待处理的 Operator 升级。
验证步骤
- 进入到 OpenShift Dev Spaces 实例。
- 3.20 版本号在页面的底部可见。
其他资源
8.4. 使用 CLI 管理工具升级 Dev Spaces
本节论述了如何使用 CLI 管理工具从以前的次版本进行升级。
先决条件
- OpenShift 上的管理帐户。
-
在
openshift-devspaces
OpenShift 项目中,使用同一 OpenShift 实例里的 CLI 管理工具安装先前次要版本的 CodeReady Workspaces 实例。 -
用于
OpenShift Dev Spaces 版本 3.20 的 DSC。请参阅:第 2.2 节 “安装 dsc 管理工具”。
流程
- 保存并将更改推送回所有正在运行的 CodeReady Workspaces 3.1 工作区的 Git 存储库。
- 关闭 CodeReady Workspaces 3.1 实例中的所有工作区。
升级 OpenShift Dev Spaces:
dsc server:update -n openshift-devspaces
$ dsc server:update -n openshift-devspaces
Copy to Clipboard Copied! 注意对于缓慢的系统或互联网连接,请添加--
k8spodwaittimeout=1800000
标志选项,将 Pod 超时周期延长为 1800000 毫秒或更长时间。
验证步骤
- 进入到 OpenShift Dev Spaces 实例。
- 3.20 版本号在页面的底部可见。
8.5. 在受限环境中升级 Dev Spaces
本节论述了如何使用受限环境中的 CLI 管理工具升级 Red Hat OpenShift Dev Spaces 并执行次版本更新。
先决条件
-
OpenShift Dev Spaces 实例使用
openshift-devspaces
项目中的dsc --installer operator
方法在 OpenShift 上安装。请参阅 第 3.1.4 节 “在受限环境中安装 Dev Spaces”。
- OpenShift 集群至少有 64 GB 磁盘空间。
- OpenShift 集群已准备好在受限网络中运行。请参阅关于断开连接的安装镜像,以及 在受限网络中使用 Operator Lifecycle Manager。
-
具有 OpenShift 集群管理权限的活跃的
oc
会话。请参阅 OpenShift CLI 入门。 -
到
registry.redhat.io
红帽生态系统目录的一个活跃的oc registry
会话。请参阅: Red Hat Container Registry 身份验证。
-
opm
.请参阅安装opm
CLI。 -
jq
.请参阅 下载jq
。 -
Podman
.请参阅 Podman 安装说明。 -
Skopeo
版本 1.6 或更高版本。请参阅 安装 Skopeo。 -
一个活跃的
skopeo
会话,具有对私有 Docker registry 的管理访问权限。对 registry 进行身份验证 ,并为断开连接的安装 mirror 镜像。 -
用于
OpenShift Dev Spaces 版本 3.20 的 DSC。请参阅 第 2.2 节 “安装 dsc 管理工具”。
流程
下载并执行镜像脚本,以安装自定义 Operator 目录并镜像相关镜像: prepare-restricted-environment.sh。
bash prepare-restricted-environment.sh \ --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.18\ --devworkspace_operator_version "v0.33.0" \ --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.18" \ --prod_operator_package_name "devspaces" \ --prod_operator_bundle_name "devspacesoperator" \ --prod_operator_version "v3.20.0" \ --my_registry "<my_registry>"
$ bash prepare-restricted-environment.sh \ --devworkspace_operator_index registry.redhat.io/redhat/redhat-operator-index:v4.18\ --devworkspace_operator_version "v0.33.0" \ --prod_operator_index "registry.redhat.io/redhat/redhat-operator-index:v4.18" \ --prod_operator_package_name "devspaces" \ --prod_operator_bundle_name "devspacesoperator" \ --prod_operator_version "v3.20.0" \ --my_registry "<my_registry>"
1 Copy to Clipboard Copied! - 1
- 镜像要镜像的专用 Docker registry
- 在 CodeReady Workspaces 3.1 实例中的所有工作区中,保存并将更改推送回 Git 存储库。
- 停止 CodeReady Workspaces 3.1 实例中的所有工作区。
运行以下命令:
dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
$ dsc server:update --che-operator-image="$TAG" -n openshift-devspaces --k8spodwaittimeout=1800000
Copy to Clipboard Copied!
验证步骤
- 进入到 OpenShift Dev Spaces 实例。
- 3.20 版本号在页面的底部可见。
其他资源
8.6. 在 OpenShift 上修复 Dev Workspace Operator
在某些情况下,如 OLM 重启或集群升级,OpenShift Dev Spaces 的 Dev Spaces Operator 可能会自动安装 Dev Workspace Operator,即使在集群中已存在。在这种情况下,您可以修复 OpenShift 上的 Dev Workspace Operator,如下所示:
先决条件
-
一个活跃的
oc
会话,作为目标 OpenShift 集群的集群管理员。请参阅 CLI 入门。 - 在 OpenShift Web 控制台的 Installed Operators 页面中,您会看到 Dev Workspace Operator 的多个条目,或看到一个处于 Replacing 和 Pending 循环中的一个条目。
流程
-
删除包含故障 pod 的
devworkspace-controller
命名空间。 通过将转换策略设置为
None
并删除整个webhook
部分,更新DevWorkspace
和DevWorkspaceTemplate
自定义资源定义(CRD):spec: ... conversion: strategy: None status: ...
spec: ... conversion: strategy: None status: ...
Copy to Clipboard Copied! 提示您可以通过在
→ 中搜索DevWorkspace
DevWorkspaceTemplate
CRD。注意DevWorkspaceOperatorConfig
和DevWorkspaceRouting
CRD 默认将转换策略设置为None
。删除 Dev Workspace Operator 订阅:
oc delete sub devworkspace-operator \ -n openshift-operators
$ oc delete sub devworkspace-operator \ -n openshift-operators
1 Copy to Clipboard Copied! - 1
openshift-operators
或安装了 Dev Workspace Operator 的 OpenShift 项目。
以 < devworkspace_operator.vX.Y.Z > 格式获取 Dev Workspace Operator CSV:
oc get csv | grep devworkspace
$ oc get csv | grep devworkspace
Copy to Clipboard Copied! 删除每个 Dev Workspace Operator CSV:
oc delete csv <devworkspace_operator.vX.Y.Z> \ -n openshift-operators
$ oc delete csv <devworkspace_operator.vX.Y.Z> \ -n openshift-operators
1 Copy to Clipboard Copied! - 1
openshift-operators
或安装了 Dev Workspace Operator 的 OpenShift 项目。
重新创建 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 startingCSV: devworkspace-operator.v0.33.0 EOF
$ cat <<EOF | oc apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: devworkspace-operator namespace: openshift-operators spec: channel: fast name: devworkspace-operator source: redhat-operators sourceNamespace: openshift-marketplace installPlanApproval: Automatic
1 startingCSV: devworkspace-operator.v0.33.0 EOF
Copy to Clipboard Copied! - 1
Automatic
或Manual
。
重要对于
installPlanApproval: Manual
,在 OpenShift Web 控制台的 Administrator 视角中,进入 → ,为 Dev Workspace Operator 选择以下内容: → → 。- 在 OpenShift Web 控制台的 Administrator 视角中,进入 → ,并验证 Dev Workspace Operator 的 Succeeded 状态。
第 9 章 卸载 Dev Spaces
卸载 OpenShift Dev Spaces 删除所有与 OpenShift Dev Spaces 相关的用户数据!
使用 dsc
卸载 OpenShift Dev Spaces 实例。
先决条件
-
DSC
.请参阅:第 2.2 节 “安装 dsc 管理工具”。
流程
删除 OpenShift Dev Spaces 实例:
dsc server:delete
$ dsc server:delete
Copy to Clipboard Copied!
--delete-namespace
选项删除 OpenShift Dev Spaces 命名空间。
--delete-all
选项会删除 Dev Workspace Operator 和相关资源。
OpenShift Container Platform 官方文档 中提供了用于手动删除 Dev Workspace Operator 的标准操作步骤(SOP)。