用户指南


Red Hat OpenShift Dev Spaces 3.6

使用 Red Hat OpenShift Dev Spaces 3.6

Robert Kratky

Fabrice Flore-Thébault

Red Hat Developer Group Documentation Team

摘要

使用 Red Hat OpenShift Dev Spaces 的用户的信息。

第 1 章 使用 Dev Spaces

要开始为您的机构使用 OpenShift Dev Spaces,您可以阅读以下内容:

1.1. 开发人员工作区

Red Hat OpenShift Dev Spaces 为开发人员提供代码、构建、测试、运行和调试应用程序所需的所有空间:

  • 项目源代码
  • 基于 Web 的集成开发环境(IDE)
  • 开发人员对项目工作所需的工具依赖项
  • 应用程序运行时:应用程序在生产环境中运行的环境的副本

Pod 管理 OpenShift Dev Spaces 工作区的每个组件。因此,OpenShift Dev Spaces 工作区中运行的一切都在容器内运行。这使得 OpenShift Dev Spaces 工作区高度可移植。

嵌入式基于浏览器的 IDE 是 OpenShift Dev Spaces 工作区中运行的所有内容的访问点。

1.1.1. Microsoft Visual Studio Code - Open Source

Microsoft Visual Studio Code - 基于浏览器的默认 IDE。

OpenShift Dev Spaces 添加以下功能:

打开 VSX registry
IDE 使用 Open VSX registry 列出和下载扩展。OpenShift Dev Spaces 管理员可以配置 Open VSX registry URL
推荐的扩展
IDE 自动安装 推荐的扩展

OpenShift Dev Spaces 增加了以下扩展:

命令

将 Devfile 命令转换为 Microsoft Visual Studio Code - 开源任务。

流程

  • 要查看可用任务的下拉列表,请输入: F1 Tasks: Run Task Enter che
活动跟踪器
跟踪 Microsoft Visual Studio Code 提供的事件 - 开源来确定和停止不活跃工作区。此扩展不会保存、收集或存储数据。
API
提供与 Dev Workspace 和 OpenShift Dev Spaces 交互的帮助信息。
GitHub 身份验证
提供向 GitHub 进行身份验证的支持。它注册可以被其他扩展利用的 github Authentication Provider。这也提供了 Settings Sync 使用的 GitHub 身份验证。
端口

检测打开端口并提供重定向 URI。当进程开始侦听端口时,OpenShift Dev Spaces 会显示带有打开生成的资源的链接的通知。

流程

  • 要显示端点列表,请输入: F1 Explorer: Focus on endpoint View Enter
远程
为远程授权提供命令。
资源监控器
监控 CPU 和 RAM 等资源。
Telemetry

检测并发送以下事件到侦听 http://localhost:${DEVWORKSPACE_TELEMETRY_BACKEND_PORT} 的后端遥测插件:

WORKSPACE_OPENED
当遥测扩展激活时发送
EDITOR_USED
vscode.workspace.onDidChangeTextDocument 事件上发送
Terminal
打开终端到 Dev Workspace 容器。

1.2. 堆栈示例

为了演示 Red Hat OpenShift Dev Spaces 作为远程开发环境的功能,Red Hat OpenShift Dev Spaces 包含使用各种编程语言的堆栈示例。每个示例都包括一个 devfile,您可以使用它们作为 bootstrap 新项目的引用。如果您是 OpenShift Dev Spaces 管理员,您可以自定义示例。

Expand
表 1.1. 支持的语言
语言构建器、运行时和数据库成熟度

Apache Camel K

  • Red Hat Fuse

GA

Java

  • OpenJDK 11
  • Maven 3.6
  • gradle 6.1
  • Quarkus 工具
  • Lombok 1.18
  • JBoss EAP 7.4
  • JBoss EAP XP 3.0

GA

Node.js

  • Node.js 16
  • NPM 8
  • Express
  • MongoDB 3.6

GA

Python

  • Python 3.8
  • Pip 22.2

GA

C/C++

  • GCC
  • cmake
  • make

技术预览

C#

  • AMD64 和 Intel 64 (x86_64)上的 dotnet 3.1
  • AMD64 和 Intel 64 (x86_64)和 IBM Z (s390x)上的 dotnet 6.0

技术预览

Go

  • Golang

技术预览

PHP

  • CakePHP
  • Composer

技术预览

1.3. 首次参与的徽标

要启用第一次人员启动带有项目的工作区,请添加一个带有到 OpenShift Dev Spaces 实例的链接的徽标。

图 1.1. 工厂徽标

流程

  1. 替换 OpenShift Dev Spaces URL ("https://devspaces- &lt;openshift_deployment_name&gt; . <domain_name> ")和存储库 URL (<your_repository_url>),并在项目 README.md 文件中添加链接。

    [![Contribute](https://www.eclipse.org/che/contribute.svg)]("https://devspaces-<openshift_deployment_name>.<domain_name>"/#https://<your_repository_url>)
    Copy to Clipboard Toggle word wrap
  2. Git 供应商 Web 界面中的 README.md 文件显示 工厂徽标。点徽标在 OpenShift Dev Spaces 实例中使用您的项目打开工作区。

1.4. 查看拉取和合并请求

Red Hat OpenShift Dev Spaces 工作区包含查看从头到完成的拉取和合并请求所需的所有工具。点 OpenShift Dev Spaces 链接,您可以使用可随时使用的工作区访问 Red Hat OpenShift Dev Spaces 支持的 Web IDE,您可以运行 linter、单元测试、构建等。

先决条件

  • 您可以访问由 Git 提供程序托管的存储库。
  • 您可以访问 OpenShift Dev Spaces 实例。

流程

  1. 打开要在 OpenShift Dev Spaces 中查看的功能分支。分支克隆在一个工作区中打开,其中包含用于调试和测试的工具。
  2. 检查拉取或合并请求更改。
  3. 运行所需的调试和测试工具:

    • 运行 linter。
    • 运行单元测试。
    • 运行构建。
    • 运行应用程序以检查问题。
  4. 导航到 Git 供应商的 UI,以保留注释并拉取或合并您分配的请求。

验证

  • (可选)使用存储库的主分支打开第二个工作区,以重现问题。

第 2 章 用户加入

如果您的机构已在运行 OpenShift Dev Spaces 实例,您可以学习如何启动新的工作区、管理您的工作区并从工作区验证到 Git 服务器,以新用户身份开始:

2.1. 使用 Git 存储库克隆启动新的工作区

在浏览器中使用 OpenShift Dev Spaces 涉及多个 URL:

  • 机构的 OpenShift Dev Spaces 实例的 URL,用作以下所有 URL 的一部分
  • 带有工作区控制面板的 OpenShift Dev Spaces 仪表板的 Workspaces 页面的 URL
  • 启动新的工作区的 URL
  • 正在使用的工作区的 URL

使用 OpenShift Dev Spaces,您可以访问浏览器中的 URL,以启动包含 Git 存储库克隆的新工作区。这样,您可以克隆托管在 GitHub、GitLab 实例或 Bitbucket 服务器上的 Git 存储库。

提示

您还可以使用 OpenShift Dev Spaces 仪表板的 Create Workspace 页面中的 Git Repo URL \114 字段来进入 Git 存储库的 URL 来启动新的工作区。

先决条件

  • 您的机构有一个正在运行的 OpenShift Dev Spaces 实例。
  • 您知道机构的 OpenShift Dev Spaces 实例的 FQDN URL: "https://devspaces- <openshift_deployment_name> . < domain_name> "
  • 可选:您已 对配置了 Git 服务器进行身份验证
  • 您的 Git 存储库维护器将 devfile.yaml.devfile.yaml 文件保留在 Git 存储库的根目录中。(有关其他文件名和文件路径,请参阅 第 2.3 节 “启动新的工作区的 URL 的可选参数”。)

    提示

    您还可以通过提供不包含 devfile 的 Git 存储库的 URL 来启动新的工作区。这样做会导致带有通用基础镜像和 Microsoft Visual Studio Code 的工作区 - Open Source 作为工作区 IDE。

流程

使用 Git 存储库克隆启动新的工作区:

  1. 可选:修改 OpenShift Dev Spaces 仪表板页面,以向您的组织的 OpenShift Dev Spaces 实例进行身份验证。
  2. 访问 URL 以使用基本语法启动新的工作区:

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>
    Copy to Clipboard Toggle word wrap
    提示

    您可以使用可选参数扩展此 URL:

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?<optional_parameters> 
    1
    Copy to Clipboard Toggle word wrap

    例 2.1. 启动新的工作区的 URL

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#https://github.com/che-samples/cpp-hello-world

    例 2.2. 使用 GitHub 托管存储库克隆启动新的工作区的 URL 语法

    使用 GitHub 和 GitLab 时,您甚至可以使用要克隆的存储库的特定分支的 URL:

    • "https://devspaces-<openshift_deployment_name& gt; . <domain_name> "Evolutionhttps://github.com/ <user_or_org&gt; / <repository > 启动一个新的工作区,克隆默认分支。
    • "https://devspaces-<openshift_deployment_name>.<domain_name>"#https://github.com/<user_or_org>/<repository>/tree/<branch_name> 启动带有指定分支克隆的新工作区。
    • "https://devspaces-<openshift_deployment_name>.<domain_name>"#https://github.com/<user_or_org>/<repository>/pull/<pull_request_id> 启动一个新的工作区,其中包含拉取请求分支的克隆。

    例 2.3. 使用 BitBucket 服务器存储库克隆启动新的工作区的 URL 语法

    • "https://devspaces-<openshift_deployment_name& gt; . <domain_name> "114https://<bb-host>/scm/<project-key>/<repository_name>.git 启动一个新的工作区,并带有默认分支的克隆。
    • "https://devspaces-<openshift_deployment_name > . <domain_name> "114https://<bb-host>/users/<user-slug>/repos/<repo-name >/ 在用户配置文件下创建了存储库,则使用默认分支克隆启动新的工作区。
    • "https://devspaces-<openshift_deployment_name& gt; . <domain_name> "VirtualMachinehttps://<bb-host>/users/<user-slug>/repos/<repo-name>/browse?at=refs%2Fheads%2F<branch-name > 启动带有指定分支克隆的新工作区。

    输入 URL 在浏览器选项卡中启动新的工作区后,它会呈现工作区启动页面。当新工作区就绪时,浏览器中的工作区 IDE 会加载。新工作区的文件系统中已存在 Git 存储库的克隆。工作区具有唯一的 URL:"https://devspaces-<openshift_deployment_name>.<domain_name>"#workspace<unique_url>.

提示

虽然地址栏中无法做到这一点,但您可以使用浏览器书签管理器添加一个 URL 以作为书签来启动新工作区:

  • 在 Mozilla Firefox 中,转至 Evolution > Bookmarks > Manage bookmarks > Bookmarks Toolbar > Organize > Addbookmarks
  • 在 Google Chrome 中,进入 \":\" > Bookmarks > Bookmark manager > Bookmarks bar > \":\" > Add newbookmarks

2.2. 从 devfile URL 启动新的工作区

在浏览器中使用 OpenShift Dev Spaces 涉及多个 URL:

  • 机构的 OpenShift Dev Spaces 实例的 URL,用作以下所有 URL 的一部分
  • devfile 的 URL
  • 启动新的工作区的 URL
  • 正在使用的工作区的 URL

使用 OpenShift Dev Spaces,您可以在浏览器中打开 devfile URL 来启动新的工作区。

提示

您还可以在 OpenShift Dev Spaces 仪表板的 Create Workspace 页面中的 Git Repo URL * 字段中输入 devfile 的 URL 来启动新的工作区。

先决条件

  • 您的机构有一个正在运行的 OpenShift Dev Spaces 实例。
  • 您知道机构的 OpenShift Dev Spaces 实例的 FQDN URL: "https://devspaces- <openshift_deployment_name> . < domain_name> "

流程

从 devfile URL 启动新的工作区:

  1. 可选:修改 OpenShift Dev Spaces 仪表板页面,以向您的组织的 OpenShift Dev Spaces 实例进行身份验证。
  2. 访问 URL 以使用基本语法启动新的工作区:

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#<devfile_url>
    Copy to Clipboard Toggle word wrap
    提示

    您可以使用可选参数扩展此 URL:

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#<devfile_url>?<optional_parameters> 
    1
    Copy to Clipboard Toggle word wrap

    例 2.4. 启动新的工作区的 URL

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml

    提示

    您可以将个人访问令牌传递给 URL,以访问私有存储库:

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#https://<token>@<host>/<path> 
    1
    Copy to Clipboard Toggle word wrap
    1
    您在 Git 提供程序网站上生成的个人访问令牌。

    这适用于 GitHub、GitLab、Bitbucket、Microsoft Azure 和其他支持个人访问令牌的供应商。

    验证

    输入 URL 在浏览器选项卡中启动新的工作区后,它会呈现工作区启动页面。当新的工作区就绪时,工作区 IDE 会在浏览器选项卡中加载。

工作区具有唯一的 URL:"https://devspaces-<openshift_deployment_name>.<domain_name>"#workspace<unique_url>.

提示

您不能将 URL 用于在地址栏中启动新工作区,但您可以使用浏览器书签管理器创建书签:

  • 在 Mozilla Firefox 中,进入 > Bookmarks > Manage bookmarks Ctrl+Shift+O > Bookmarks Toolbar > Organize > Add bookmark
  • 在 Google Chrome 中,进入 > Bookmarks > Bookmark manager > Bookmarks bar > > Add new bookmark
重要

要在新工作区的文件系统中启动 Git 存储库的克隆,devfile 必须包含项目信息。

请参阅 https://devfile.io/docs/2.2.0/adding-projects

2.3. 启动新的工作区的 URL 的可选参数

当您启动新的工作区时,OpenShift Dev Spaces 根据 devfile 中的说明配置工作区。当使用 URL 启动新工作区时,您可以将可选参数附加到进一步配置工作区的 URL 中。您可以使用这些参数来指定工作区 IDE,启动重复工作区,并指定 devfile 文件名或路径。

2.3.1. URL 参数串联

启动新的工作区的 URL 支持通过使用以下 URL 语法的 & amp; 来串联多个可选 URL 参数:

"https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?<url_parameter_1>&<url_parameter_2>&<url_parameter_3>

例 2.5. 使用 Git 存储库和可选 URL 参数的 URL 来启动新工作区的 URL

浏览器的完整 URL:

"https://devspaces-<openshift_deployment_name>.<domain_name>"#https://github.com/che-samples/cpp-hello-world?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml

URL 部分的说明:

"https://devspaces-<openshift_deployment_name>.<domain_name>" 
1

#https://github.com/che-samples/cpp-hello-world 
2

?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml 
3
Copy to Clipboard Toggle word wrap
1
OpenShift Dev Spaces URL。
2
要克隆到新工作区中的 Git 存储库的 URL。
3
串联的可选 URL 参数。

2.3.2. IDE 的 URL 参数

您可以在启动工作区时使用 che-editor= URL 参数指定受支持的 IDE。

提示

当您无法在 source-code Git 仓库中添加或编辑 /.che/che-editor.yaml 文件时,请使用 che-editor= 参数来为工作区克隆。

注意

che-editor= 参数覆盖 /.che/che-editor.yaml 文件。

此参数接受两种类型的值:

  • che-editor=<editor_key>

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?che-editor=<editor_key>
    Copy to Clipboard Toggle word wrap
    Expand
    表 2.1. 支持的 IDE 的 URL 参数 <editor_key > 值
    IDE<editor_key> value备注

    Microsoft Visual Studio Code - Open Source

    che-incubator/che-code/latest

    这是在没有使用 URL 参数或 che-editor.yaml 时在新工作区中载入的默认 IDE。

    JetBrains IntelliJ IDEA Community Edition

    che-incubator/che-idea/latest

    技术预览

  • che-editor=<url_to_a_file>

    "https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?che-editor=<url_to_a_file>
    1
    Copy to Clipboard Toggle word wrap
    1
    带有 devfile 内容的 文件的 URL。
    提示
    • URL 必须指向原始文件内容。
    • 要将此参数与 che-editor.yaml 文件一起使用,请使用其他名称或路径复制文件,并从文件中删除 内联 行。

2.3.3. 用于启动重复工作区的 URL 参数

访问启动新工作区的 URL 会根据 devfile 和链接的 Git 存储库的克隆生成新的工作区。

在某些情况下,您可能需要在 devfile 和链接的 Git 存储库时复制多个工作区。您可以使用 URL 参数访问启动新工作区的同一 URL。

用于启动重复工作区的 URL 参数是 新的

"https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?new
Copy to Clipboard Toggle word wrap
注意

如果您目前有一个使用 URL 启动的工作区,则在没有 URL 参数的情况下再次访问 URL 会导致错误消息。

2.3.4. devfile 文件名的 URL 参数

当您访问启动新工作区的 URL 时,OpenShift Dev Spaces 会使用文件名 .devfile.yamldevfile.yaml 为 devfile 搜索链接的 Git 存储库。链接的 Git 存储库中的 devfile 必须遵循这个文件。

在某些情况下,您可能需要为 devfile 指定不同的非关系文件名。

用于指定 devfile 的未协调文件名的 URL 参数为 df= <filename>.yaml

"https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?df=<filename>.yaml 
1
Copy to Clipboard Toggle word wrap
1
<filename > .yaml 是链接 Git 存储库中 devfile 的不协调文件名。
提示

df= &lt;filename& gt; .yaml 参数也有一个长版本: devfilePath= <filename&gt; .yaml

2.3.5. devfile 文件路径的 URL 参数

当您访问启动新工作区的 URL 时,OpenShift Dev Spaces 会在链接 Git 存储库的根目录中搜索名为 .devfile.yamldevfile.yaml 的 devfile。链接 Git 存储库中的 devfile 的文件路径必须遵循这个路径惯例。

在某些情况下,您可能需要在链接的 Git 存储库中为 devfile 指定不同的非协调文件路径。

用于指定 devfile 的非协调文件路径的 URL 参数是 devfilePath= <relative_file_path>

"https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?devfilePath=<relative_file_path> 
1
Copy to Clipboard Toggle word wrap
1
<relative_file_path > 是链接 Git 存储库中 devfile 的非协调文件路径。

2.3.6. 工作区存储的 URL 参数

如果启动新工作区的 URL 不包含指定存储类型的 URL 参数,则新工作区会在临时存储或持久性存储中创建新的工作区,每当被定义为 CheCluster 自定义资源中的默认存储类型。

为工作区指定存储类型的 URL 参数是 storage Type= <storage_type>

"https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?storageType=<storage_type> 
1
Copy to Clipboard Toggle word wrap
1
可能的 &lt ;storage_type&gt; 值:
  • ephemeral
  • per-user (persistent)
  • 每个工作区 (持久性)
提示

使用 临时或 每个工作区 存储类型,您可以同时运行多个工作区,这无法使用默认的 按用户 存储类型。

2.3.7. 其他远程的 URL 参数

当您访问一个 URL 来启动新的工作区时,OpenShift Dev Spaces 会将 origin 远程配置为 Git 存储库,您在您的机构 OpenShift Dev Spaces 实例的 FQDN URL 后指定 #

用于克隆和配置工作区额外远程的 URL 参数是 remotes=

"https://devspaces-<openshift_deployment_name>.<domain_name>"#<git_repository_url>?remotes={{<name_1>,<url_1>},{<name_2>,<url_2>},{<name_3>,<url_3>},...}
Copy to Clipboard Toggle word wrap
重要
  • 如果您没有为任何其他远程输入名称 origin,则来自 <git_repository_url> 的远程会被克隆,并默认命名为 origin,并会作为自动签出的预期分支。
  • 如果您为一个额外的远程输入了名称 origin,它的默认分支将被自动签出,当来自 <git_repository_url> 的远程将不会为工作区进行克隆。

2.4. 您可以在工作区上执行的基本操作

您可以在 OpenShift Dev Spaces 仪表板的 Workspaces ("https://devspaces-<openshift_deployment_name>.<domain_name>"/dashboard/#/workspaces) 页中管理您的工作区并验证它们的当前状态。

启动新的工作区后,您可以在 Workspaces 页面中执行以下操作:

Expand
表 2.2. 您可以在工作区上执行的基本操作
操作Workspaces 页面中的 GUI 步骤

重新打开正在运行的工作区

Open

重启正在运行的工作区

进入 > Restart Workspace

停止正在运行的工作区

前往 novncproxy & gt; Stop Workspace

启动已停止的工作空间

Open

删除工作区

前往 novncproxy & gt; Delete Workspace

2.5. 从工作区对 Git 服务器进行身份验证

在工作区中,您可以运行需要用户身份验证的 Git 命令,如克隆远程私有 Git 存储库或推送到远程公共或私有 Git 存储库。

从工作区对 Git 服务器的用户身份验证由管理员配置,或者在某些情况下由单个用户配置:

第 3 章 自定义工作区组件

自定义工作区组件:

第 4 章 Dev Spaces 中的 devfile 简介

devfile 是用于开发环境自定义的 yaml 文本文件。使用它们配置 devfile 以满足您的特定需求,并在多个工作区间共享自定义的 devfile,以确保在您的团队中实现相同的用户体验和构建、运行和部署。

devfile 和通用基础镜像

您不需要 devfile 来启动工作区。如果您没有在项目存储库中包括 devfile,Red Hat OpenShift Dev Spaces 会自动加载带有通用基础镜像(UDI)的默认 devfile。

OpenShift Dev Spaces devfile registry

OpenShift Dev Spaces devfile registry 包含可用于不同语言和技术的 devfile。

注意

registry 中包含的 devfile 特定于 Red Hat OpenShift Dev Spaces,应被视为示例而不是模板。它们可能需要更新才能与示例中功能的其他组件版本一起工作。

第 5 章 工作区中的 IDE

5.1. 支持的 IDE

新工作区中的默认 IDE 是 Microsoft Visual Studio Code - Open Source。或者,您可以选择另一个支持的 IDE:

Expand
表 5.1. 支持的 IDE
IDEid备注

Microsoft Visual Studio Code - Open Source

che-incubator/che-code/latest

这是在没有使用 URL 参数或 che-editor.yaml 时在新工作区中载入的默认 IDE。

JetBrains IntelliJ IDEA Community Edition

che-incubator/che-idea/latest

技术预览

5.2. OpenShift Dev Spaces 中的存储库级 IDE 配置

您可以直接将 IDE 配置文件存储在包含项目源代码的远程 Git 存储库中。这样,一个常见的 IDE 配置应用于支持该存储库的克隆的所有新工作区。这些 IDE 配置文件可能包括以下内容:

5.3. 定义一个常见的 IDE

虽然 第 2.3.2 节 “IDE 的 URL 参数” 可让您使用支持的 IDE 个人选择启动工作区,但您可能会更轻松地为同一源代码 Git 仓库的所有工作区定义相同的 IDE。要做到这一点,请使用 che-editor.yaml 文件。此文件甚至支持详细的 IDE 配置。

提示

如果您希望使用 Microsoft Visual Studio Code 以外的相同 IDE 启动大多数或所有机构工作区 - Open Source,则一个替代方法是让机构的 OpenShift Dev Spaces 实例的管理员指定另一个支持的 IDE 作为 OpenShift Dev Spaces 实例级别的默认 IDE。这可以通过 CheCluster 自定义资源中的 .spec.devEnvironments.defaultEditor 来完成。

5.3.1. 设置 che-editor.yaml

通过使用 che-editor.yaml 文件,您可以为团队设置共同的默认 IDE,并为项目源代码提供最合适的 IDE。当您需要为特定源代码 Git 存储库设置不同的 IDE 默认而不是机构 OpenShift Dev Spaces 实例的默认 IDE 时,您还可以使用 che-editor.yaml 文件。

流程

  • 在项目源代码的远程 Git 存储库中,使用指定相关参数的行创建一个 /.che/che-editor.yaml 文件。

验证

  1. 使用 Git 存储库的克隆启动新的工作区
  2. 验证在启动工作区的浏览器选项卡中指定的 IDE 加载。

5.3.2. che-editor.yaml 的参数

che-editor.yaml 中选择 IDE 的最简单方法是从支持的 IDE 表中指定 IDE 的 id

Expand
表 5.2. 支持的 IDE
IDEid备注

Microsoft Visual Studio Code - Open Source

che-incubator/che-code/latest

这是在没有使用 URL 参数或 che-editor.yaml 时在新工作区中载入的默认 IDE。

JetBrains IntelliJ IDEA Community Edition

che-incubator/che-idea/latest

技术预览

例 5.1. ID 从插件 registry 中选择一个 IDE

id: che-incubator/che-idea/latest
Copy to Clipboard Toggle word wrap

作为提供 id 参数的替代选择,che-editor.yaml 文件支持对另一个 che-editor.yaml 文件的 URL 的引用,或插件 registry 之外的 IDE 的 内联 定义:

例 5.2. 参考 指向远程 che-editor.yaml 文件

reference: https://<hostname_and_path_to_a_remote_file>/che-editor.yaml
Copy to Clipboard Toggle word wrap

例 5.3. inline 为没有插件 registry 的自定义 IDE 指定一个完整的定义

inline:
  schemaVersion: 2.1.0
  metadata:
    name: JetBrains IntelliJ IDEA Community IDE
  components:
    - name: intellij
      container:
        image: 'quay.io/che-incubator/che-idea:next'
        volumeMounts:
          - name: projector-user
            path: /home/projector-user
        mountSources: true
        memoryLimit: 2048M
        memoryRequest: 32Mi
        cpuLimit: 1500m
        cpuRequest: 100m
        endpoints:
          - name: intellij
            attributes:
              type: main
              cookiesAuthEnabled: true
              urlRewriteSupported: true
              discoverable: false
              path: /?backgroundColor=434343&wss
            targetPort: 8887
            exposure: public
            secure: false
            protocol: https
      attributes: {}
    - name: projector-user
      volume: {}
Copy to Clipboard Toggle word wrap

对于更复杂的场景,che-editor.yaml 文件支持 registryUrl 并覆盖 参数:

例 5.4. registryUrl 指向自定义插件 registry,而不是默认的 OpenShift Dev Spaces 插件 registry

id: <editor_id> 
1

registryUrl: <url_of_custom_plugin_registry>
Copy to Clipboard Toggle word wrap
1
自定义插件 registry 中的 IDE ID。

例 5.5. 覆盖 IDE 的一个或多个定义的属性的默认值

... 
1

override:
  containers:
    - name: che-idea
      memoryLimit: 1280Mi
      cpuLimit: 1510m
      cpuRequest: 102m
    ...
Copy to Clipboard Toggle word wrap
1
id:, registryUrl:, 或 reference:.

5.4. Microsoft Visual Studio Code - Open Source

Microsoft Visual Studio Code 的 OpenShift Dev Spaces 构建 - Open Source 是新工作区的默认 IDE。

您可以在工作区启动时从 Open VSX registry 自动安装 Microsoft Visual Studio Code 扩展。请参阅 工作区启动时自动安装 Microsoft Visual Studio Code 扩展

提示
  • 使用 任务 查找并运行 devfile.yaml 中指定的命令。
  • Status Bar 中的 Dev Spaces 来使用 Dev Spaces 命令,或通过 Command Palette 找到它们:

    • Dev Spaces:Open Dashboard
    • Dev Spaces:打开 OpenShift 控制台
    • dev Spaces: Stop Workspace
    • dev Spaces: Restart Workspace
    • Dev Spaces: 从 Local Devfile 重启 Workspace
    • Dev Spaces:Open 文档
注意

如果您的组织通过品牌构建进行了定制,您可能会在此 IDE 中看到您的机构品牌。

要使 Microsoft Visual Studio Code - Open Source IDE 会自动安装所选扩展,您可以在包含项目源代码的远程 Git 存储库中添加一个 extensions.json 文件,并将克隆到工作区中。

先决条件

流程

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

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

      https://www.open-vsx.org/extension/<publisher>/<extension>
      Copy to Clipboard Toggle word wrap
  2. 在远程 Git 仓库中创建 .vscode/extensions.json 文件。
  3. extensions.json 文件中添加 < publisher > 和名称 <extension>,如下所示:

      {
        "recommendations": [
          "<publisher_A>.<extension_B>",
          "<publisher_C>.<extension_D>",
          "<publisher_E>.<extension_F>"
        ]
      }
    Copy to Clipboard Toggle word wrap

验证

  1. 使用远程 Git 存储库的 URL 来启动一个新的工作区,其中包括创建的 extensions.json 文件。
  2. 在工作区的 IDE 中,按 Ctrl+Shift+X 或进入 Extensions 来查找文件中列出的每个扩展。
  3. 扩展具有此扩展的标签 ,可在全局范围内启用

第 6 章 在工作区中使用凭证和配置

您可以在工作区中使用凭证和配置。

要做到这一点,将凭证和配置挂载到您机构 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器中:

  • 将凭证和敏感配置挂载为 Kubernetes Secret
  • 将非敏感配置挂载为 Kubernetes ConfigMap

如果您需要允许集群中的 Dev Workspace Pod 访问需要身份验证的容器 registry,请为 Dev Workspace Pod 创建 镜像拉取 Secret

挂载过程使用标准 Kubernetes 挂载机制,需要对现有资源应用额外的标签和注解。在启动新的工作区或重启现有工作区时,资源会被挂载。

您可以为各种组件创建永久挂载点:

6.1. 挂载 Secret

要将机密数据挂载到工作区中,请使用 Kubernetes Secret。

使用 Kubernetes Secret,您可以挂载用户名、密码、SSH 密钥对、身份验证令牌(如 AWS)和敏感配置。

将 Kubernetes Secret 挂载到您机构 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器。

先决条件

  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • 在用户项目中,您要创建新的 Secret,或确定要挂载到所有 Dev Workspace 容器的现有 Secret。

流程

  1. 将挂载 Secret 所需的标签添加到 Secret 中。

    $ oc label secret <Secret_name> \
            controller.devfile.io/mount-to-devworkspace=true \
            controller.devfile.io/watch-secret=true
    Copy to Clipboard Toggle word wrap
  2. 可选: 使用注解来配置 Secret 的挂载方式。

    Expand
    表 6.1. 可选注解
    注解描述

    controller.devfile.io/mount-path:

    指定挂载路径。

    默认为 /etc/secret/ <Secret_name>

    controller.devfile.io/mount-as:

    指定如何挂载资源: 文件子路径env

    默认为 文件

    mount-as :文件将 键和值挂载为挂载路径中的文件。

    mount-as: 子路径 使用子路径卷挂载在挂载路径中挂载键和值。

    mount-as: env 将键和值作为环境变量挂载到所有 Dev Workspace 容器中。

例 6.1. 将 Secret 挂载为文件

apiVersion: v1
kind: Secret
metadata:
  name: mvn-settings-secret
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
    controller.devfile.io/watch-secret: 'true'
  annotations:
    controller.devfile.io/mount-path: '/home/user/.m2'
data:
  settings.xml: <Base64_encoded_content>
Copy to Clipboard Toggle word wrap

当您启动一个工作区时,dev Workspace 容器中将提供 /home/user/.m2/settings.xml 文件。

使用 Maven,您可以为 settings.xml 文件设置自定义路径。例如:

$ mvn --settings /home/user/.m2/settings.xml clean install
Copy to Clipboard Toggle word wrap

6.1.1. 创建镜像拉取 secret

要允许机构 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace Pod 访问需要身份验证的容器 registry,请创建一个镜像 pull Secret。

您可以使用 oc.dockercfg 文件或 config.json 文件创建镜像 pull Secret。

6.1.1.1. 使用 oc创建镜像拉取 Secret

先决条件

流程

  1. 在用户项目中,使用私有容器 registry 详情和凭证创建镜像 pull Secret:

    $ oc create secret docker-registry <Secret_name> \
        --docker-server=<registry_server> \
        --docker-username=<username> \
        --docker-password=<password> \
        --docker-email=<email_address>
    Copy to Clipboard Toggle word wrap
  2. 在镜像 pull Secret 中添加以下标签:

    $ oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true
    Copy to Clipboard Toggle word wrap
6.1.1.2. 从 .dockercfg 文件创建镜像 pull Secret

如果您已将私有容器 registry 的凭证存储在 .dockercfg 文件中,您可以使用该文件创建镜像 pull Secret。

先决条件

  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • base64 命令行工具安装在您要使用的操作系统中。

流程

  1. .dockercfg 文件编码为 Base64:

    $ cat .dockercfg | base64 | tr -d '\n'
    Copy to Clipboard Toggle word wrap
  2. 在用户项目中创建一个新的 OpenShift Secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <Secret_name>
      labels:
        controller.devfile.io/devworkspace_pullsecret: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      .dockercfg: <Base64_content_of_.dockercfg>
    type: kubernetes.io/dockercfg
    Copy to Clipboard Toggle word wrap
  3. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard Toggle word wrap
6.1.1.3. 从 config.json 文件创建镜像 pull Secret

如果您已将私有容器 registry 的凭证存储在 $HOME/.docker/config.json 文件中,您可以使用该文件来创建镜像 pull Secret。

先决条件

  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • base64 命令行工具安装在您要使用的操作系统中。

流程

  1. $HOME/.docker/config.json 文件编码为 Base64。

    $ cat config.json | base64 | tr -d '\n'
    Copy to Clipboard Toggle word wrap
  2. 在用户项目中创建一个新的 OpenShift Secret:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <Secret_name>
      labels:
        controller.devfile.io/devworkspace_pullsecret: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      .dockerconfigjson: <Base64_content_of_config.json>
    type: kubernetes.io/dockerconfigjson
    Copy to Clipboard Toggle word wrap
  3. 应用 Secret:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_the_previous_step>
    EOF
    Copy to Clipboard Toggle word wrap

6.1.2. 使用 Git-provider 访问令牌

GitHub、GitLab、Bitbucket 或 Microsoft Azure Repos 的 OAuth 需要 由机构的 OpenShift Dev Spaces 实例的管理员配置。如果管理员无法为 OpenShift Dev Spaces 用户配置它,则临时解决方案是将个人访问令牌作为 Kubernetes Secret 应用。

将访问令牌挂载为 Secret 可让 OpenShift Dev Spaces 服务器访问创建工作区期间克隆的远程存储库,包括访问存储库的 /.che/.vscode 文件夹。

在您的机构 OpenShift Dev Spaces 实例的 OpenShift 集群的用户项目中应用 Secret。

应用 Secret 后,您可以使用托管在 GitHub、GitLab、Bitbucket Server 或 Microsoft Azure Repos 上的私有 Git 存储库克隆来创建工作区。

您可以为每个 Git 供应商创建并应用多个访问令牌 Secret。您必须在用户项目中应用每个 Secret。

先决条件

  • 具有运行机构的 OpenShift Dev Spaces 实例的集群的集群管理员权限。
  • 已登陆到集群。

    提示

    在 OpenShift 中,您可以使用 oc 命令行工具登录到集群:

    $ oc login "https://devspaces-<openshift_deployment_name>.<domain_name>" --username=<my_user>
    Copy to Clipboard Toggle word wrap

流程

  1. 在 Git 提供程序的网站上生成您的访问令牌。
  2. 将您的访问令牌编码为 Base64。

    提示

    如果安装了 base64 命令行工具,可以使用命令行:

    $ echo -n '<your_access_token_string>' | base64
    Copy to Clipboard Toggle word wrap
  3. 进入 "https://devspaces- &lt;openshift_deployment_name& gt; . <domain_name> "/api/user/id,以获取您的 OpenShift Dev Spaces 用户 ID。
  4. 准备新的 OpenShift Secret。

    kind: Secret
    apiVersion: v1
    metadata:
      name: personal-access-token-<your_choice_of_name_for_this_token>
      labels:
        app.kubernetes.io/component: scm-personal-access-token
        app.kubernetes.io/part-of: che.eclipse.org
      annotations:
        che.eclipse.org/che-userid: <devspaces_user_id>
    1
    
        che.eclipse.org/scm-personal-access-token-name: <git_provider_name>
    2
    
        che.eclipse.org/scm-url: <git_provider_endpoint>
    3
    
        che.eclipse.org/scm-username: <git_provider_username>
    4
    
        che.eclipse.org/scm-organization: <git_provider_organization>
    5
    
    data:
      token: <Base64_encoded_access_token>
    type: Opaque
    Copy to Clipboard Toggle word wrap
    1
    您的 OpenShift Dev Spaces 用户 ID。
    2
    Git 供应商名称: githubgitlabbitbucket-serverazure-devops
    3
    Git 供应商 URL。
    4
    Git 供应商用户名。对于 azure-devops,用户的电子邮件地址。
    5
    这一行仅适用于 azure-devops :您的 Git 供应商用户组织。
  5. 访问 "https://devspaces-<openshift_deployment_name>.<domain_name>"/api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间作为 name
  6. 切换到集群中的 OpenShift Dev Spaces 用户命名空间。

    提示

    在 OpenShift 中:

    • oc 命令行工具可以返回集群中当前处于的命名空间,您可以使用它来检查当前的命名空间:

      $ oc project
      Copy to Clipboard Toggle word wrap
    • 如果需要,您可以在命令行中切换到 OpenShift Dev Spaces 用户命名空间:

      $ oc project <your_user_namespace>
      Copy to Clipboard Toggle word wrap
  7. 应用 Secret。

    提示

    在 OpenShift 中,您可以使用 oc 命令行工具:

    $ oc apply -f - <<EOF
    <Secret_prepared_in_step_5>
    EOF
    Copy to Clipboard Toggle word wrap

验证

  1. 使用 Git 提供程序主机的远程 Git 存储库的 URL 来启动新的工作区
  2. 进行一些更改,并从工作区推送到远程 Git 存储库。

6.2. 挂载 ConfigMap

要将非机密配置数据挂载到工作区中,请使用 Kubernetes ConfigMap。

使用 Kubernetes ConfigMap,您可以挂载非敏感数据,如应用程序的配置值。

将 Kubernetes ConfigMap 挂载到您机构 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器。

先决条件

  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • 在用户项目中,您要创建新的 ConfigMap,或确定要挂载到所有 Dev Workspace 容器的现有 ConfigMap。

流程

  1. 将挂载 ConfigMap 所需的标签添加到 ConfigMap 中。

    $ oc label configmap <ConfigMap_name> \
            controller.devfile.io/mount-to-devworkspace=true \
            controller.devfile.io/watch-configmap=true
    Copy to Clipboard Toggle word wrap
  2. 可选: 使用注解来配置 ConfigMap 的挂载方式。

    Expand
    表 6.2. 可选注解
    注解描述

    controller.devfile.io/mount-path:

    指定挂载路径。

    默认为 /etc/config/ <ConfigMap_name>

    controller.devfile.io/mount-as:

    指定如何挂载资源: 文件子路径env

    默认为 文件

    mount-as:file 将键和值挂载为挂载路径中的文件。

    mount-as:subpath 使用子路径卷挂载在挂载路径中挂载键和值。

    mount-as:env 将键和值作为环境变量挂载到所有 Dev Workspace 容器中。

例 6.2. 将 ConfigMap 挂载为环境变量

kind: ConfigMap
apiVersion: v1
metadata:
  name: my-settings
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
    controller.devfile.io/watch-configmap: 'true'
  annotations:
    controller.devfile.io/mount-as: env
data:
  <env_var_1>: <value_1>
  <env_var_2>: <value_2>
Copy to Clipboard Toggle word wrap

当您启动一个工作区时,&lt ;env_var_1&gt; 和 <env_var_2 > 环境变量将在 Dev Workspace 容器中可用。

6.3. 在受限环境中启用工件存储库

通过配置技术堆栈,您可以使用自签名证书处理来自托管软件仓库的工件:

6.3.1. Maven

您可以在受限环境中运行的 Maven 工作区中启用 Maven 工件存储库。

先决条件

  • 您没有运行任何 Maven 工作区。
  • 您知道您的用户命名空间,即 < username&gt; -devspaces,其中 & lt;username& gt; 是 OpenShift Dev Spaces 用户名。

流程

  1. 在 & lt;username> -devspaces 命名空间中,为 TLS 证书应用 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 
    1
    Copy to Clipboard Toggle word wrap
    1
    禁用行嵌套的 Base64 编码。
  2. 在 & lt;username> -devspaces 命名空间中,应用 ConfigMap 来创建 settings.xml 文件:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: settings-xml
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/.m2
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    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/>
          <interactiveMode/>
          <offline/>
          <pluginGroups/>
          <servers/>
          <mirrors>
            <mirror>
              <id>redhat-ga-mirror</id>
              <name>Red Hat GA</name>
              <url>https://<maven_artifact_repository_route>/repository/redhat-ga/</url>
              <mirrorOf>redhat-ga</mirrorOf>
            </mirror>
            <mirror>
              <id>maven-central-mirror</id>
              <name>Maven Central</name>
              <url>https://<maven_artifact_repository_route>/repository/maven-central/</url>
              <mirrorOf>maven-central</mirrorOf>
            </mirror>
            <mirror>
              <id>jboss-public-repository-mirror</id>
              <name>JBoss Public Maven Repository</name>
              <url>https://<maven_artifact_repository_route>/repository/jboss-public/</url>
              <mirrorOf>jboss-public-repository</mirrorOf>
            </mirror>
          </mirrors>
          <proxies/>
          <profiles/>
          <activeProfiles/>
        </settings>
    Copy to Clipboard Toggle word wrap
  3. 可选:在使用基于 JBoss EAP 的 devfile 时,在 < username>-devspaces 命名空间中应用第二个 settings-xml ConfigMap,并具有相同的内容、不同的名称和 /home/jboss/.m2 挂载路径。
  4. 在 & lt;username> -devspaces 命名空间中,为 TrustStore 初始化脚本应用 ConfigMap:

    Java 8

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-truststore
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init-java8-truststore.sh: |
        #!/usr/bin/env bash
    
        keytool -importcert -noprompt -file /home/user/certs/tls.cer -trustcacerts -keystore ~/.java/current/jre/lib/security/cacerts -storepass changeit
    Copy to Clipboard Toggle word wrap

    Java 11

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-truststore
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init-java11-truststore.sh: |
        #!/usr/bin/env bash
    
        keytool -importcert -noprompt -file /home/user/certs/tls.cer -cacerts -storepass changeit
    Copy to Clipboard Toggle word wrap

  5. 启动 Maven 工作区。
  6. tools 容器中打开一个新的终端。
  7. 运行 ~/init-truststore.sh

6.3.2. gradle

您可以在受限环境中运行的 Gradle 工作区中启用 Gradle 工件存储库。

先决条件

  • 您没有运行任何 Gradle 工作区。

流程

  1. 为 TLS 证书应用 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 
    1
    Copy to Clipboard Toggle word wrap
    1
    禁用行嵌套的 Base64 编码。
  2. 为 TrustStore 初始化脚本应用 ConfigMap:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-truststore
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init-truststore.sh: |
        #!/usr/bin/env bash
    
        keytool -importcert -noprompt -file /home/user/certs/tls.cer -cacerts -storepass changeit
    Copy to Clipboard Toggle word wrap
  3. 为 Gradle init 脚本应用 ConfigMap:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-gradle
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /home/user/.gradle
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      init.gradle: |
        allprojects {
          repositories {
            mavenLocal ()
            maven {
              url "https://<gradle_artifact_repository_route>/repository/maven-public/"
              credentials {
                username "admin"
                password "passwd"
              }
            }
          }
        }
    Copy to Clipboard Toggle word wrap
  4. 启动 Gradle 工作区。
  5. tools 容器中打开一个新的终端。
  6. 运行 ~/init-truststore.sh

6.3.3. npm

您可以在受限环境中运行的 npm 工作区中启用 npm 工件存储库。

先决条件

  • 您没有运行任何 npm 工作区。
警告

应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。

如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。

流程

  1. 为 TLS 证书应用 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 
    1
    Copy to Clipboard Toggle word wrap
    1
    禁用行嵌套的 Base64 编码。
  2. 应用 ConfigMap 在 tools 容器中设置以下环境变量:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      NODE_EXTRA_CA_CERTS: /home/user/certs/tls.cer
      NPM_CONFIG_REGISTRY: >-
        https://<npm_artifact_repository_route>/repository/npm-all/
    Copy to Clipboard Toggle word wrap

6.3.4. Python

您可以在受限环境中运行的 Python 工作区中启用 Python 工件存储库。

先决条件

  • 您没有运行任何 Python 工作区。
警告

应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。

如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。

流程

  1. 为 TLS 证书应用 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 
    1
    Copy to Clipboard Toggle word wrap
    1
    禁用行嵌套的 Base64 编码。
  2. 应用 ConfigMap 在 tools 容器中设置以下环境变量:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      PIP_INDEX_URL: >-
        https://<python_artifact_repository_route>/repository/pypi-all/
      PIP_CERT: /home/user/certs/tls.cer
    Copy to Clipboard Toggle word wrap

6.3.5. Go

您可以在受限环境中运行的 Go 工作区中启用 Go 工件存储库。

先决条件

  • 您没有运行任何 Go 工作区。
警告

应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。

如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。

流程

  1. 为 TLS 证书应用 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 
    1
    Copy to Clipboard Toggle word wrap
    1
    禁用行嵌套的 Base64 编码。
  2. 应用 ConfigMap 在 tools 容器中设置以下环境变量:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      GOPROXY: >-
        http://<athens_proxy_route>
      SSL_CERT_FILE: /home/user/certs/tls.cer
    Copy to Clipboard Toggle word wrap

6.3.6. NuGet

您可以在受限环境中运行的 NuGet 工作区中启用 NuGet 工件存储库。

先决条件

  • 您没有运行任何 NuGet 工作区。
警告

应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。

如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。

流程

  1. 为 TLS 证书应用 Secret:

    kind: Secret
    apiVersion: v1
    metadata:
      name: tls-cer
      annotations:
        controller.devfile.io/mount-path: /home/user/certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      tls.cer: >-
        <Base64_encoded_content_of_public_cert> 
    1
    Copy to Clipboard Toggle word wrap
    1
    禁用行嵌套的 Base64 编码。
  2. 应用 ConfigMap 来设置 工具 容器中 TLS 证书文件的路径的环境变量:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: disconnected-env
      annotations:
        controller.devfile.io/mount-as: env
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      SSL_CERT_FILE: /home/user/certs/tls.cer
    Copy to Clipboard Toggle word wrap
  3. 应用 ConfigMap 以创建 nuget.config 文件:

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: init-nuget
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /projects
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
    data:
      nuget.config: |
        <?xml version="1.0" encoding="UTF-8"?>
        <configuration>
          <packageSources>
            <add key="nexus2" value="https://<nuget_artifact_repository_route>/repository/nuget-group/"/>
          </packageSources>
          <packageSourceCredentials>
            <nexus2>
                <add key="Username" value="admin" />
                <add key="Password" value="passwd" />
            </nexus2>
          </packageSourceCredentials>
        </configuration>
    Copy to Clipboard Toggle word wrap

第 7 章 为工作区请求持久性存储

OpenShift Dev Spaces 工作区和工作区数据是临时的,并在工作区停止时丢失。

要在工作空间停止时保留持久性存储中的工作区状态,请为机构的 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器请求 Kubernetes PersistentVolume (PV)。

您可以使用 devfile 或 Kubernetes PersistentVolumeClaim (PVC)请求 PV。

PV 示例是工作区的 /projects/ 目录,默认为非临时工作区挂载。

持久性卷的成本:附加持久性卷会减慢工作空间启动的速度。

警告

启动另一个空间,使用 ReadWriteOnce PV 同时运行工作区可能会失败。

7.1. 在 devfile 中请求持久性存储

当工作区需要其自身持久性存储时,在 devfile 中请求 PersistentVolume (PV),OpenShift Dev Spaces 将自动管理所需的 PersistentVolumeClaim。

先决条件

  • 您没有启动工作区。

流程

  1. 在 devfile 中添加 组件:

    ...
    components:
      ...
      - name: <chosen_volume_name>
        volume:
          size: <requested_volume_size>G
      ...
    Copy to Clipboard Toggle word wrap
  2. 为 devfile 中的相关 容器 添加 volumeMount

    ...
    components:
      - name: ...
        container:
          ...
          volumeMounts:
            - name: <chosen_volume_name_from_previous_step>
              path: <path_where_to_mount_the_PV>
          ...
    Copy to Clipboard Toggle word wrap

例 7.1. 为容器工作区置备 PV 的 devfile

当使用以下 devfile 启动工作区时,缓存 PV 会置备到 ./cache 容器路径中的 golang 容器:

schemaVersion: 2.1.0
metadata:
  name: mydevfile
components:
  - name: golang
    container:
      image: golang
      memoryLimit: 512Mi
      mountSources: true
      command: ['sleep', 'infinity']
      volumeMounts:
        - name: cache
          path: /.cache
  - name: cache
    volume:
      size: 2Gi
Copy to Clipboard Toggle word wrap

7.2. 在 PVC 中请求持久性存储

在以下情况下,您可以选择应用 PersistentVolumeClaim (PVC)为工作区请求 PersistentVolume (PV):

  • 不是项目中的所有开发人员都需要 PV。
  • PV 生命周期超过单个工作区的生命周期。
  • PV 中包含的数据在工作区之间共享。
提示

即使工作区是临时的,并且其 devfile 包含 controller.devfile.io/storage-type: ephemeral 属性,您也可以将 PVC 应用到 Dev Workspace 容器。

先决条件

  • 您没有启动工作区。
  • 一个活跃的 oc 会话,它具有到目标 OpenShift 集群的管理权限。请参阅开始使用 CLI
  • 在用户项目中创建 PVC 以挂载到所有 Dev Workspace 容器。

流程

  1. controller.devfile.io/mount-to-devworkspace: true 标签添加到 PVC。

    $ oc label persistentvolumeclaim <PVC_name> \ controller.devfile.io/mount-to-devworkspace=true$ oc label persistentvolumeclaim <PVC_name> \ controller.devfile.io/mount-to-devworkspace=true$ oc label persistentvolumeclaim <PVC_name> \ controller.devfile.io/mount-to-devworkspace=true
    Copy to Clipboard Toggle word wrap
  2. 可选: 使用注解来配置 PVC 的挂载方式:

    Expand
    表 7.1. 可选注解
    注解描述

    controller.devfile.io/mount-path:

    PVC 的挂载路径。

    默认为 /tmp/<PVC_name>

    controller.devfile.io/read-only:

    设置为 'true''false',以指定 PVC 是否挂载为只读。

    默认为 'false',从而导致 PVC 挂载为读写。

例 7.2. 挂载只读 PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <pvc_name>
  labels:
    controller.devfile.io/mount-to-devworkspace: 'true'
  annotations:
    controller.devfile.io/mount-path: </example/directory> 
1

spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi 
2

  volumeName: <pv_name>
  storageClassName: manual
  volumeMode: Filesystem
Copy to Clipboard Toggle word wrap
1
挂载的 PV 位于工作区的 </example/directory>
2
请求存储的大小值示例。

第 8 章 与 OpenShift 集成

8.1. 使用 OpenShift API 管理工作区

在机构的 OpenShift 集群中,OpenShift Dev Spaces 工作区表示为相同名称的 DevWorkspace 自定义资源。因此,如果在 OpenShift Dev Spaces 仪表板中有一个名为 my-workspace 的工作区,在集群的用户项目中有一个名为 my-workspaceDevWorkspace 自定义资源。

由于集群中的每个 DevWorkspace 自定义资源都代表 OpenShift Dev Spaces 工作区,因此您可以使用带有命令行 oc 等客户端的 OpenShift API 来管理 OpenShift Dev Spaces 工作区。

每个 DevWorkspace 自定义资源都包含从为工作区克隆的 Git 存储库的 devfile 中派生的详细信息。例如,devfile 可能会提供 devfile 命令和工作空间容器配置。

8.1.1. 列出所有工作区

作为用户,您可以使用命令行列出工作区。

先决条件

  • 一个活跃的 oc 会话,具有在集群中的项目中 获取 DevWorkspace 资源的权限。请参阅开始使用 CLI
  • 您知道集群上的相关的 OpenShift Dev Spaces 用户命名空间。

    提示

    访问 "https://devspaces-<openshift_deployment_name>.<domain_name>"/api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间作为 name

  • 您位于集群的 OpenShift Dev Spaces 用户命名空间中。

    提示

    在 OpenShift 上,您可以使用命令行 oc 工具 显示当前的命名空间,或切换到命名空间

流程

  • 要列出您的工作区,请在命令行中输入以下内容:

    $ oc get devworkspaces
    Copy to Clipboard Toggle word wrap

    例 8.1. 输出

    NAMESPACE   NAME                 DEVWORKSPACE ID             PHASE     INFO
    user1-dev   spring-petclinic     workspace6d99e9ffb9784491   Running   https://url-to-workspace.com
    user1-dev   golang-example       workspacedf64e4a492cd4701   Stopped   Stopped
    user1-dev   python-hello-world   workspace69c26884bbc141f2   Failed    Container tooling has state CrashLoopBackOff
    Copy to Clipboard Toggle word wrap
提示

您可以通过在此命令中添加 --watch 标志来查看 PHASE 更改。

注意

集群上具有管理权限的用户可以通过包含 --all-namespaces 标志列出所有来自所有 OpenShift Dev Spaces 用户的所有工作区。

8.1.2. 创建工作区

如果您的用例不允许使用 OpenShift Dev Spaces 仪表板,您可以通过将自定义资源应用到集群来使用 OpenShift API 创建工作区。

注意

与使用命令行相比,通过 OpenShift Dev Spaces 仪表板创建工作区提供更好的用户体验和配置优势:

  • 作为用户,您会自动登录到集群。
  • OpenShift 客户端会自动工作。
  • OpenShift Dev Spaces 及其组件会自动将目标 Git 存储库的 devfile 转换为集群中的 DevWorkspaceDevWorkspaceTemplate 自定义资源。
  • 默认情况下,使用工作区的 DevWorkspace 中的 routingClass: che 对工作区的访问是安全的。
  • DevWorkspaceOperatorConfig 配置的真实性由 OpenShift Dev Spaces 管理。
  • CheCluster 自定义资源中指定的 spec.devEnvironments 中配置,包括:

    • 持久性存储策略通过 devEnvironments.storage 指定。
    • 默认 IDE 使用 devEnvironments.defaultEditor 指定。
    • 默认插件通过 devEnvironments.defaultPlugins 指定。
    • 容器构建配置通过 devEnvironments.containerBuildConfiguration 指定。

先决条件

流程

  1. 要准备 DevWorkspace 自定义资源,请复制目标 Git 存储库的 devfile 的内容。

    例 8.2. 使用 schemaVersion: 2.2.0复制 devfile 内容

    components:
      - name: tooling-container
        container:
          image: quay.io/devfile/universal-developer-image:ubi8-latest
    Copy to Clipboard Toggle word wrap
    提示

    如需了解更多详细信息,请参阅 devfile v2 文档

  2. 创建 DevWorkspace 自定义资源,在 spec.template 字段下粘贴上一步中的 devfile 内容。

    例 8.3. DevWorkspace 自定义资源

    kind: DevWorkspace
    apiVersion: workspace.devfile.io/v1alpha2
    metadata:
      name: my-devworkspace
    1
    
      namespace: user1-dev
    2
    
    spec:
      routingClass: che
      started: true
    3
    
      contributions:
    4
    
        - name: ide
          uri: "https://devspaces-<openshift_deployment_name>.<domain_name>"/plugin-registry/v3/plugins/che-incubator/che-code/latest/devfile.yaml
      template:
        projects:
    5
    
          - name: my-project-name
            git:
              remotes:
                origin: https://github.com/eclipse-che/che-docs
        components:
    6
    
          - name: tooling-container
            container:
              image: quay.io/devfile/universal-developer-image:ubi8-latest
    Copy to Clipboard Toggle word wrap
    1
    DevWorkspace 自定义资源的名称。这将是新工作区的名称。
    2
    用户命名空间,这是新工作区的目标项目。
    3
    决定在创建 DevWorkspace 自定义资源时是否必须启动工作区。
    4
    5
    有关 Git 存储库在启动时要克隆到工作区的详细信息。
    6
    工作空间容器和卷组件等组件列表。
  3. DevWorkspace 自定义资源应用到集群。

验证

  1. 通过检查 DevWorkspacePHASE 状态来验证工作区是否已启动。

    $ oc get devworkspaces -n <user_project> --watch
    Copy to Clipboard Toggle word wrap

    例 8.4. 输出

    NAMESPACE        NAME                  DEVWORKSPACE ID             PHASE      INFO
    user1-dev        my-devworkspace       workspacedf64e4a492cd4701   Starting   Waiting for workspace deployment
    Copy to Clipboard Toggle word wrap
  2. 当工作区成功启动时,其 PHASE 状态会在 oc get devworkspaces 命令的输出中变为 Running

    例 8.5. 输出

    NAMESPACE            NAME                  DEVWORKSPACE ID             PHASE      INFO
    user1-dev            my-devworkspace       workspacedf64e4a492cd4701   Running    https://url-to-workspace.com
    Copy to Clipboard Toggle word wrap

    然后,您可以使用以下选项之一打开工作区:

    • 访问 oc get devworkspaces 命令的输出的 INFO 部分中提供的 URL。
    • 从 OpenShift Dev Spaces 仪表板中打开工作区。

8.1.3. 停止工作区

您可以通过将 Devworkspace 自定义资源中的 spec.started 字段设置为 false 来停止工作区。

先决条件

  • 集群中的一个活跃的 oc 会话。请参阅开始使用 CLI
  • 您知道工作区名称。

    提示

    您可以在 $ oc get devworkspaces 的输出中找到相关的工作区名称。

  • 您知道集群上的相关的 OpenShift Dev Spaces 用户命名空间。

    提示

    访问 "https://devspaces-<openshift_deployment_name>.<domain_name>"/api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间作为 name

  • 您位于集群的 OpenShift Dev Spaces 用户命名空间中。

    提示

    在 OpenShift 上,您可以使用命令行 oc 工具 显示当前的命名空间,或切换到命名空间

流程

  • 运行以下命令来停止工作区:

    $ oc patch devworkspace <workspace_name> \
    -p '{"spec":{"started":false}}' \
    --type=merge -n <user_namespace> && \
    oc wait --for=jsonpath='{.status.phase}'=Stopped \
    dw/<workspace_name> -n <user_namespace>
    Copy to Clipboard Toggle word wrap

8.1.4. 启动停止的工作区

您可以通过将 Devworkspace 自定义资源中的 spec.started 字段设置为 true 来启动已停止的工作空间。

先决条件

  • 集群中的一个活跃的 oc 会话。请参阅开始使用 CLI
  • 您知道工作区名称。

    提示

    您可以在 $ oc get devworkspaces 的输出中找到相关的工作区名称。

  • 您知道集群上的相关的 OpenShift Dev Spaces 用户命名空间。

    提示

    访问 "https://devspaces-<openshift_deployment_name>.<domain_name>"/api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间作为 name

  • 您位于集群的 OpenShift Dev Spaces 用户命名空间中。

    提示

    在 OpenShift 上,您可以使用命令行 oc 工具 显示当前的命名空间,或切换到命名空间

流程

  • 运行以下命令以启动已停止的工作空间:

    $ oc patch devworkspace <workspace_name> \
    -p '{"spec":{"started":true}}' \
    --type=merge -n <user_namespace> && \
    oc wait --for=jsonpath='{.status.phase}'=Running \
    dw/<workspace_name> -n <user_namespace>
    Copy to Clipboard Toggle word wrap

8.1.5. 删除工作区

您可以通过删除 DevWorkspace 自定义资源来删除工作区。

警告

如果 DevWorkspace 自定义资源由 OpenShift Dev Spaces 创建,则删除它们也会删除其他工作区资源:例如,引用的 DevWorkspaceTemplate 和 per-workspace PersistentVolumeClaims

提示

尽可能使用 OpenShift Dev Spaces 仪表板删除工作区。

先决条件

  • 集群中的一个活跃的 oc 会话。请参阅开始使用 CLI
  • 您知道工作区名称。

    提示

    您可以在 $ oc get devworkspaces 的输出中找到相关的工作区名称。

  • 您知道集群上的相关的 OpenShift Dev Spaces 用户命名空间。

    提示

    访问 "https://devspaces-<openshift_deployment_name>.<domain_name>"/api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间作为 name

  • 您位于集群的 OpenShift Dev Spaces 用户命名空间中。

    提示

    在 OpenShift 上,您可以使用命令行 oc 工具 显示当前的命名空间,或切换到命名空间

流程

  • 运行以下命令以删除工作区:

    $ oc delete devworkspace <workspace_name> -n <user_namespace>
    Copy to Clipboard Toggle word wrap

8.2. 自动 OpenShift 令牌注入

本节论述了如何使用自动注入工作空间容器的 OpenShift 用户令牌,允许针对 OpenShift 集群运行 OpenShift Dev Spaces CLI 命令。

流程

  1. 打开 OpenShift Dev Spaces 仪表板并启动工作区。
  2. 工作空间启动后,在包含 OpenShift Dev Spaces CLI 的容器中打开终端。
  3. 执行 OpenShift Dev Spaces CLI 命令,允许您对 OpenShift 集群运行命令。CLI 可用于部署应用程序、检查和管理集群资源以及查看日志。OpenShift 用户令牌将在执行命令时使用。

警告

自动令牌注入目前仅适用于 OpenShift 基础架构。

第 9 章 Dev Spaces 故障排除

本节提供了用户可能出现冲突的最频繁问题的故障排除过程。

9.1. 查看 Dev Spaces 工作区日志

您可以查看 OpenShift Dev Spaces 日志,以便更好地了解和调试后台进程。

IDE 扩展行为或需要调试
日志列出了编辑器载入的插件。
容器内存不足
日志包含 OOMKilled 错误消息。在容器中运行的进程试图请求超过容器可用的内存。
进程内存不足
日志包含错误消息,如 OutOfMemoryException。容器内的进程在没有容器识别的情况下耗尽内存。

9.1.1. CLI 中的工作区日志

您可以使用 OpenShift CLI 观察 OpenShift Dev Spaces 工作区日志。

先决条件

  • OpenShift Dev Spaces 工作区 &lt ;workspace_name&gt; 正在运行。
  • 您的 OpenShift CLI 会话有权访问包含此工作区的 OpenShift 项目 & lt;namespace_name >。

流程

  • 从在 <namespace_name> 项目中的的 <workspace_name> 工作区中运行的 pod 获取日志:

    $ oc logs --follow --namespace='<workspace_namespace>' \
      --selector='controller.devfile.io/devworkspace_name=<workspace_name>'
    Copy to Clipboard Toggle word wrap

9.1.2. OpenShift 控制台中的工作区日志

您可以使用 OpenShift 控制台观察 OpenShift Dev Spaces 工作区日志。

流程

  1. 在 OpenShift Dev Spaces 仪表板中,进入 Workspaces
  2. 单击工作区名称,以显示工作区概览页面。本页显示 OpenShift 项目名称 < project_name>
  3. 点右上角的 Applications 菜单,然后点 OpenShift 控制台链接。
  4. 在 OpenShift 控制台中,在 Administrator 视角中运行后续步骤。
  5. Workloads & gt; Pods 查看所有活跃工作区列表。
  6. Project 下拉菜单中,选择 < project_name&gt; 项目来缩小搜索范围。
  7. 点运行工作区的正在运行的 pod 的名称。Details 选项卡包含所有容器的列表,以及其他信息。
  8. 转至 Logs 选项卡。

在工作区中运行的 Visual Studio Code 编辑器中,您可以配置已安装的语言服务器和调试适配器扩展来查看其日志。

流程

  1. 配置扩展:点 File > Preferences > Settings,展开 Extensions 部分,搜索您的扩展,并将 trace.server 或类似的配置设置为 verbose (如果存在)。如需进一步配置,请参阅扩展文档。
  2. ViewOutput,然后在 Output 视图中选择您的语言服务器,查看您的语言服务器日志。

其他资源

9.2. 工作区启动失败的故障排除

详细模式允许用户访问放大的日志输出,在工作区启动时调查失败。

除了常见的日志条目外,Wbose 模式还会列出每个工作区的容器日志。

本节论述了如何在工作区启动时在 Verbose 模式重启 OpenShift Dev Spaces 工作区。当工作区在启动时失败后,仪表板会在 Verbose 模式中重启工作区。

先决条件

  • 正在运行的 OpenShift Dev Spaces 实例。
  • 无法启动的现有工作区。

流程

  1. 使用仪表板,尝试启动工作区。
  2. 当它无法启动时,点显示的 Open in Verbose mode 链接。
  3. 检查 Logs 选项卡,以查找工作区失败的原因。

本节论述了如何在 Verbose 模式中启动 Red Hat OpenShift Dev Spaces 工作区。

先决条件

  • 正在运行的 Red Hat OpenShift Dev Spaces 实例。
  • 此 OpenShift Dev Spaces 实例上定义的现有工作区。

流程

  1. 打开 Workspaces 选项卡。
  2. 在专用于工作区的行的左侧,访问以三个水平点显示的下拉菜单,然后选择 Open in Verbose mode 选项。或者,此选项也可以在 Actions 下拉菜单的工作区详情中找到。
  3. 检查 Logs 选项卡,以查找工作区失败的原因。

9.3. 慢速工作区故障排除

有时,工作区可能需要很长时间才能启动。调优可减少这个开始时间。根据选项,管理员或用户可以进行调优。

本节包含多个调优选项,用于更快地启动工作区或提高工作空间运行时性能。

9.3.1. 提高工作空间启动时间

使用 Image Puller 缓存镜像

Role: Administrator

在启动工作区时,OpenShift 从 registry 中拉取镜像。工作区可以包含多个容器,意味着 OpenShift 会拉取 Pod 的镜像(每个容器一个)。根据镜像和带宽的大小,可能需要很长时间。

Image Puller 是一个可缓存每个 OpenShift 节点上的镜像的工具。因此,预拉取镜像可以提高开始时间。请参阅 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.6/html-single/administration_guide/index#administration-guide:caching-images-for-faster-workspace-start

选择更好的存储类型

Role: Administrator 和 user

每个工作区都附加了一个共享卷。此卷存储项目文件,以便在重启工作区时,更改仍然可用。根据存储,附加时间最多可能需要几分钟,I/O 可能很慢。

离线安装

Role: Administrator

OpenShift Dev Spaces 的组件是 OCI 镜像。以离线模式设置 Red Hat OpenShift Dev Spaces,以减少运行时的任何额外下载,因为所有操作都需要在启动时可用。请参阅 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.6/html-single/administration_guide/index#administration-guide:installing-che-in-a-restricted-environment

减少公共端点数量

Role: Administrator

对于每个端点,OpenShift 正在创建 OpenShift Route 对象。根据底层配置,此创建速度可能会较慢。

要避免这个问题,请减少暴露。例如,要自动检测容器内监听的新端口,并使用本地 IP 地址(127.0.0.1)重定向进程的流量,Microsoft Visual Code - Open Source 有三个可选路由。

通过减少端点的数量并检查所有插件的端点,工作区启动可能会更快。

9.3.2. 提高工作区运行时性能

提供足够的 CPU 资源

插件消耗 CPU 资源。例如,当插件提供 IntelliSense 功能时,添加更多 CPU 资源可以提高性能。

确保 devfile 定义 devfile.yaml 中的 CPU 设置正确:

components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-latest
      cpuLimit: 4000m 
1

      cpuRequest: 1000m 
2
Copy to Clipboard Toggle word wrap
1
指定 CPU 限制
2
指定 CPU 请求
提供足够的内存

插件消耗 CPU 和内存资源。例如,当插件提供 IntelliSense 功能时,收集数据可能会消耗分配给容器的所有内存。

为容器提供更多内存可以提高性能。确保 devfile 定义 devfile.yaml 文件中的内存设置正确。

components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-latest
      memoryLimit: 6G 
1

      memoryRequest: 512Mi 
2
Copy to Clipboard Toggle word wrap
1
指定内存限制
2
指定内存请求

9.4. 网络问题故障排除

本节论述了如何防止或解决与网络策略相关的问题。OpenShift Dev Spaces 需要 WebSocket Secure (WSS)连接的可用性。安全 WebSocket 连接提高了机密性,以及可靠性,因为它们降低了错误的代理干扰的风险。

先决条件

  • 网络上必须有端口 443 上的 WebSocket Secure (WSS)连接。防火墙和代理可能需要其他配置。

流程

  1. 验证浏览器支持 WebSocket 协议。请参阅: 搜索 websocket 测试
  2. 验证防火墙设置:端口 443 上的 WebSocket 安全(WSS)连接必须可用。
  3. 验证代理服务器设置:代理传输并截获端口 443 上的 WebSocket 安全(WSS)连接。

9.5. Webview 加载错误故障排除

如果您在专用浏览窗口中使用 Microsoft Visual Studio Code - Open Source,您可能会遇到以下出错信息: Error loaded webview: Error: Could not register service worker

这是一个会影响以下浏览器的已知问题:

  • Incognito 模式中的 Google Chrome
  • Mozilla Firefox in Private Browsing mode
Expand
表 9.1. 在专用浏览窗口中处理 Webview 错误
浏览器

临时解决方案

Google Chrome

进入 SettingsPrivacy and securityCookies 和其他站点数据允许所有 Cookie

Mozilla Firefox

Private Browsing 模式不支持 Webview。详情请查看 这个 Mozilla Firefox 错误

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat