用户指南


Red Hat OpenShift Dev Spaces 3.22

使用 Red Hat OpenShift Dev Spaces 3.22

Red Hat Developer Group Documentation Team

摘要

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

第 1 章 Dev Spaces 入门

如果您的机构已在运行 OpenShift Dev Spaces 实例,您可以作为新用户启动,方法是了解如何启动新的工作区,管理工作区,并从工作区向 Git 服务器验证自己到 Git 服务器:

1.1. 从 Git 存储库 URL 启动工作区

在此过程的上下文中,"Git 存储库 URL"是指存储库的 git clone URL。通常,您可以通过单击 SCM 存储库主页中的 Clone 按钮来获取此 URL。或者,当您位于存储库的主页面时,您也可以从浏览器的地址栏中复制 URL。选择分支或标签会将引用参数添加到 URL。

注意

对于 GitHub,您还可以使用带有 devfile 的目录的存储库 URL,或 devfile 的存储库 URL。devfile 的名称必须是 devfile.yaml.devfile.yaml

其他 Git 提供程序不支持此功能。

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

提示

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

重要
重要

配置个人访问令牌以访问私有存储库。请参阅 第 6.1.2 节 “使用 Git-provider 访问令牌”

先决条件

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

    提示

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

流程

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

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

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>
    Copy to Clipboard Toggle word wrap
    提示

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

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>?<optional_parameters> 
    1
    Copy to Clipboard Toggle word wrap
    提示

    您可以使用 Git+SSH URL 来启动新的工作区。请参阅配置 DevWorkspace 为 Git 操作使用 SSH 密钥

    例 1.1. 用于启动新工作区的 URL

    • https://<openshift_dev_spaces_fqdn>#https://github.com/che-samples/cpp-hello-world
    • https://<openshift_dev_spaces_fqdn>#git@github.com:che-samples/cpp-hello-world.git

    例 1.2. 使用 GitHub 实例存储库克隆来启动新工作区的 URL 语法

    • https://<openshift_dev_spaces_fqdn&gt; #https:/// <user_or_org> / <repository > 启动一个带有默认分支克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn&gt; #https:///<user_or_org&gt; / <repository&gt; /tree/ & lt;branch_name> 启动一个带有指定分支克隆的新工作区。
    • https://<openshift_dev_spaces_fqdn&gt; #https:/// <user_or_org> / <repository> /pull/ & lt;pull_request_id> 启动带有拉取请求分支的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn>#git@:<user_or_org&gt; / <repository > .git 从 Git+SSH URL 启动一个新的工作区。

    例 1.3. 使用 GitLab 实例存储库克隆来启动新工作区的 URL 语法

    • https://<openshift_dev_spaces_fqdn&gt; #https:/// <user_or_org> / <repository > 启动一个带有默认分支克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn&gt; #https:///<user_or_org&gt; / <repository> /-/tree/& lt;branch_name> 启动带有指定分支克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn>#git@:<user_or_org&gt; / <repository > .git 从 Git+SSH URL 启动一个新的工作区。

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

    • https:// &lt;openshift_dev_spaces_fqdn&gt; #https://<bb_host> /scm/ &lt;project-key&gt; / <repository > .git 启动一个带有默认分支克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn>#https:// &lt;bb_host&gt; /users/<user_slug> /repos/ &lt;repository > /repos/ has a new workspace of a clone of the default branch, if an repository was created in the user profile.
    • https:// &lt;openshift_dev_spaces_fqdn&gt; #https://<bb_host> /users/ &lt;user-slug&gt; /repos/ <repository> /browse?at=refs%2Fheads%2F<branch-name > 启动带有指定分支的克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn>#git@ &lt;bb_host&gt;: <user_slug&gt; / <repository > .git 从 Git+SSH URL 启动一个新的工作区。

    例 1.5. 使用 Microsoft Azure DevOps Git 存储库的克隆来启动新工作区的 URL 语法

    • https:// &lt;openshift_dev_spaces_fqdn&gt; #https://<organization> @dev.azure.com/<organization&gt; / <project&gt; /_git/ <repository > 启动一个带有默认分支克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn>#https:// &lt;organization&gt; @dev.azure.com/<organization&gt; / <project> /_git/ <repository &gt; ?version=GB <branch > 启动带有特定分支的克隆的新工作区。
    • https:// &lt;openshift_dev_spaces_fqdn>#git@ssh.dev.azure.com:v3/ &lt;organization&gt; /<project&gt; / <repository > 从 Git+SSH URL 中启动新的工作区。

    在输入 URL 以在浏览器标签页中启动新的工作区后,会显示工作区启动页面。

    当新的工作区就绪后,工作区 IDE 会在浏览器选项卡中加载。

    新工作区的文件系统中会出现 Git 存储库的克隆。

    工作区具有唯一的 URL: https:// <openshift_dev_spaces_fqdn> / <user_name> / &lt;unique_url>

1.1.1. 用于启动新的工作区的 URL 的可选参数

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

1.1.1.1. URL 参数串联

启动新的工作区的 URL 支持使用 & amp; 及以下 URL 语法连接多个可选 URL 参数:

https:// <openshift_dev_spaces_fqdn> #?<url_parameter_1> &amp; <url_parameter_2> &amp; <url_parameter_3>

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

浏览器的完整 URL:

https:// &lt;openshift_dev_spaces_fqdn>#https://github.com/che-samples/cpp-hello-world?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml

URL 的部分解释:

https://<openshift_dev_spaces_fqdn> 
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 参数。
1.1.1.2. IDE 的 URL 参数

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

提示

当您无法在 source-code Git 仓库中添加或编辑要克隆的 source-code Git 存储库中的 /.che/che-editor.yaml 文件时,请使用 che-editor= 参数。

注意

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

这个参数接受两种类型的值:

  • che-editor=<editor_key>

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>?che-editor=<editor_key>
    Copy to Clipboard Toggle word wrap
    Expand
    表 1.1. 支持的 IDE 的 URL 参数 <editor_key > 值
    IDEStatus<editor_key>备注

    Microsoft Visual Studio Code - Open Source

    可用

    • che-incubator/che-code/latest
    • che-incubator/che-code/insiders
    • latest 是当不使用 URL 参数或 che-editor.yaml 时,在新的工作区中载入的默认 IDE。
    • Insiders 是开发版本。

    JetBrains IntelliJ IDEA 社区版

    Deprecated

    • Che-incubator/che-idea/latest
    • che-incubator/che-idea/next
    • latest 是稳定版本。
    • 接下来是 开发版本。

    JetBrains IntelliJ IDEA Ultimate Edition (在 JetBrains 网关)

    技术预览

    • che-incubator/che-idea-server/latest
    • che-incubator/che-idea-server/next
    • latest 是稳定版本。
    • 接下来是 开发版本。
  • che-editor=<url_to_a_file>

    https://<openshift_dev_spaces_fqdn>#<git_repository_url>?che-editor=<url_to_a_file>
    1
    Copy to Clipboard Toggle word wrap
    1
    指向包含 devfile 内容的 文件的 URL。
    提示
    • URL 必须指向原始文件内容。
    • 要将此参数与 che-editor.yaml 文件一起使用,请使用另一个名称或路径复制该文件,并从文件中删除 内联 行。
1.1.1.3. IDE 镜像的 URL 参数

您可以使用 editor-image 参数为工作区设置自定义 IDE 镜像。

重要
  • 如果 Git 存储库包含 /.che/che-editor.yaml 文件,则自定义编辑器将使用新的 IDE 镜像覆盖。
  • 如果 Git 存储库中没有 /.che/che-editor.yaml 文件,则默认的编辑器将使用新的 IDE 镜像覆盖。
  • 如果要覆盖支持的 IDE 并更改目标编辑器镜像,您可以同时使用这两个参数: che-editoreditor-image URL 参数。

覆盖 IDE 镜像的 URL 参数是 editor-image=

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?editor-image=<container_registry/image_name:image_tag>
Copy to Clipboard Toggle word wrap

Example:

https:// &lt;openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?editor-image=quay.io/che-incubator/che-code:next

或者

https:// &lt;openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?che-editor=che-incubator/che-code/latest&editor-image=quay.io/che-incubator/che-code:next

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

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

在某些情况下,您可能需要有多个在 devfile 和链接的 Git 仓库中重复的工作区。您可以通过访问同一 URL 来使用 URL 参数启动新工作区来完成此操作。

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

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?new
Copy to Clipboard Toggle word wrap
注意

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

1.1.1.5. devfile 文件名的 URL 参数

当您访问 URL 来启动新的工作区时,OpenShift Dev Spaces 将链接的 Git 存储库搜索带有文件名 .devfile.yamldevfile.yaml 的 devfile。链接 Git 存储库中的 devfile 必须遵循此文件命名惯例。

在某些情况下,您可能需要为 devfile 指定不同的、不协调的文件名。

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

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?df=<filename>.yaml 
1
Copy to Clipboard Toggle word wrap
1
<filename > .yaml 是链接 Git 存储库中的 devfile 的 unconventional 文件名。
提示

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

1.1.1.6. devfile 文件路径的 URL 参数

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

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

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

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?devfilePath=<relative_file_path> 
1
Copy to Clipboard Toggle word wrap
1
<relative_file_path > 是链接 Git 存储库中的 devfile 的 unconventional 文件路径。
1.1.1.7. 工作区存储的 URL 参数

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

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

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?storageType=<storage_type> 
1
Copy to Clipboard Toggle word wrap
1
可能的 &lt ;storage_type&gt; 值:
  • ephemeral
  • 每个用户 (永久)
  • per-workspace (persistent)
提示

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

1.1.1.8. 其他远程的 URL 参数

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

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

https://<openshift_dev_spaces_fqdn>#<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> 的远程将不会为工作区进行克隆。
1.1.1.9. 容器镜像的 URL 参数

在以下情况下,您可以使用 image 参数对容器镜像使用自定义引用:

  • Git 存储库不包含 devfile,您希望使用自定义镜像启动新的工作区。
  • Git 存储库包含一个 devfile,您想要覆盖 devfile 的 components 部分中列出的第一个容器镜像。

容器镜像路径的 URL 参数是 image=

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?image=<container_image_url>
Copy to Clipboard Toggle word wrap

Example

https:// &lt;openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?image=quay.io/devfile/universal-developer-image:ubi8-latest

1.1.1.10. 内存限制的 URL 参数

从 devfile URL 启动新工作区时,您可以使用 memoryLimit 参数来指定或覆盖容器内存限值。当您要确保工作区有足够的内存用于开发任务时,这非常有用。

内存限制的 URL 参数是 memoryLimit=

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?memoryLimit=<container_memory_limit>
Copy to Clipboard Toggle word wrap

您可以以字节为单位指定内存限值,或使用 Mi 作为兆字节,Gi 用于千兆字节。

例 1.7. Example

https:// &lt;openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?memoryLimit=4Gi

重要

当您指定 memoryLimit 参数时,它会覆盖为 devfile 的第一个容器定义的内存限值。

目标 devfile 和编辑器定义中的限制总和将应用到工作区 pod spec.containers[0].resources.limits.memory

其他资源

1.1.1.11. CPU 限值的 URL 参数

从 devfile URL 启动新工作区时,您可以使用 cpuLimit 参数来指定或覆盖容器 CPU 限制。当您要确保工作区有足够的内存用于开发任务时,这非常有用。

CPU 限值的 URL 参数是 cpuLimit=

https://<openshift_dev_spaces_fqdn>#<git_repository_url>?cpuLimit=<container_cpu_limit>
Copy to Clipboard Toggle word wrap

您可以在内核中指定 CPU 限制。

例 1.8. Example

https://<openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?cpuLimit=2

重要

当您指定 cpuLimit 参数时,它会覆盖为 devfile 的第一个容器定义的 CPU 限值。

目标 devfile 和编辑器定义中的限制总和将应用到工作区 pod spec.containers[0].resources.limits.cpu

其他资源

1.2. 从原始 devfile URL 启动工作区

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

提示

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

重要

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

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

先决条件

  • 您的机构有一个 OpenShift Dev Spaces 实例运行。
  • 您知道机构的 OpenShift Dev Spaces 实例的 FQDN URL: https:// <openshift_dev_spaces_fqdn >。

流程

从 devfile URL 中启动新的工作区:

  1. 可选:访问 OpenShift Dev Spaces 仪表板页面,以向您的机构的 OpenShift Dev Spaces 实例进行身份验证。
  2. 访问 URL,以使用基本语法从 公共存储库中 启动新的工作区:

    https://<openshift_dev_spaces_fqdn>#<devfile_url>
    Copy to Clipboard Toggle word wrap

    您可以将个人访问令牌传递给 URL,以从 私有仓库 访问 devfile:

    https://<openshift_dev_spaces_fqdn>#https://<token>@<host>/<path_to_devfile> 
    1
    Copy to Clipboard Toggle word wrap
    1
    您在 Git 供应商网站上生成的个人访问令牌。

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

    重要

    在这种情况下,自动化 Git 凭证注入无法正常工作。要配置 Git 凭据,请使用 配置个人访问令牌 指南。

    提示

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

    https://<openshift_dev_spaces_fqdn>#<devfile_url>?<optional_parameters> 
    1
    Copy to Clipboard Toggle word wrap

    例 1.9. 从公共存储库中启动新工作区的 URL

    https:// &lt;openshift_dev_spaces_fqdn>#https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml

    例 1.10. 从私有存储库启动新工作区的 URL

    https://<openshift_dev_spaces_fqdn&gt; #https:// &lt;token> @raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml

    验证

    在输入 URL 以在浏览器标签页中启动新的工作区后,会显示工作区启动页面。当新的工作区就绪后,工作区 IDE 会在浏览器选项卡中加载。

    工作区具有唯一的 URL: https:// <openshift_dev_spaces_fqdn> / <user_name> / &lt;unique_url>

1.3. 您可以对工作区执行的基本操作

您可以在 OpenShift Dev Spaces 仪表板的 Workspaces 页面中管理您的工作区并验证它们的当前状态(https:// &lt;openshift_dev_spaces_fqdn> /dashboard/:/workspaces)。

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

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

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

Open

重启正在运行的工作区

进入 > Restart Workspace

停止正在运行的工作区

进入 && amp ; & gt; Stop Workspace

启动已停止的工作空间

Open

删除工作区

进入 && amp ; & gt; Delete Workspace

1.4. 从工作区向 Git 服务器进行身份验证

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

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

默认情况下,新创建的不使用 devfile 的工作区将使用通用基础镜像(UDI)。UDI 包含开发人员常用的开发工具和依赖项。

Podman 和 Buildah 包含在 UDI 中,允许开发人员从工作区构建和推送容器镜像。

默认情况下,UDI 中的 Podman 和 Buildah 被配置为使用 vfs 存储驱动程序。要更有效地镜像管理,请使用 fuse-overlayfs 存储驱动程序,该驱动程序在无根环境中支持 copy-on-write。

您必须在工作区中使用 fuse-overlayfs 的以下要求:

  1. 对于早于 4.15 的 OpenShift 版本,管理员已通过 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.22/html-single/administration_guide/index#administration-guide:configuring-fuse 在集群中启用了 /dev/fuse 访问。
  2. 工作区具有使用 /dev/fuse 设备所需的注解。请参阅 第 1.5.1 节 “访问 /dev/fuse”
  3. 工作区容器中的 storage.conf 文件已配置为使用 fuse-overlayfs。请参阅 第 1.5.2 节 “使用 ConfigMap 启用 fuse-overlayfs”

1.5.1. 访问 /dev/fuse

您必须有权访问 /dev/fuse,才能使用 fuse-overlayfs。本节论述了如何使 /dev/fuse 可以被工作区容器访问。

先决条件

流程

  1. 使用 pod-overrides 属性将 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.22/html-single/administration_guide/index#administration-guide:configuring-fuse 中定义的所需注解添加到工作区。pod-overrides 属性允许合并工作区 pod 的 spec 中的某些字段。

    对于早于 4.15 的 OpenShift 版本:

    $ oc patch devworkspace <DevWorkspace_name> \
      --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse","io.openshift.podman-fuse":""}}}}}}}' \
      --type=merge
    Copy to Clipboard Toggle word wrap

    对于 OpenShift 版本 4.15 及更新的版本:

    $ oc patch devworkspace <DevWorkspace_name> \
      --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse"}}}}}}}' \
      --type=merge
    Copy to Clipboard Toggle word wrap

验证步骤

  1. 启动工作区,并验证 /dev/fuse 是否在工作区容器中可用。

    $ stat /dev/fuse
    Copy to Clipboard Toggle word wrap

完成此步骤后,按照 第 1.5.2 节 “使用 ConfigMap 启用 fuse-overlayfs” 中的步骤为 Podman 使用 fuse-overlayfs。

1.5.2. 使用 ConfigMap 启用 fuse-overlayfs

您可以在 ~/.config/containers/storage.conf 文件中定义 Podman 和 Buildah 的存储驱动程序。以下是 UDI 容器中 /home/user/.config/containers/storage.conf 文件的默认内容:

storage.conf

[storage]
driver = "vfs"
Copy to Clipboard Toggle word wrap

要使用 fuse-overlayfs,storage.conf 可以设置为以下内容:

storage.conf

[storage]
driver = "overlay"

[storage.options.overlay]
mount_program="/usr/bin/fuse-overlayfs" 
1
Copy to Clipboard Toggle word wrap

1
fuse-overlayfs 二进制文件的绝对路径。/usr/bin/fuse-overlayfs 路径是 UDI 的默认路径。

您可以在启动工作区后手动执行此操作。另一种选择是基于 UDI 构建新镜像,并更改 storage.conf,并将新镜像用于工作区。

否则,您可以通过创建一个挂载更新文件的 ConfigMap,为项目中的所有工作区更新 /home/user/.config/containers/storage.conf。请参阅 第 6.2 节 “挂载 ConfigMap”

先决条件

注意

由于按照 本指南 挂载的 ConfigMap 将 ConfigMap 的数据挂载到所有工作区,因此此流程会将存储驱动程序设置为 fuse-overlayfs。确保工作区包含使用以下 第 1.5.1 节 “访问 /dev/fuse” 来使用 fuse-overlayfs 所需的注解。

流程

  1. 应用在项目中挂载 /home/user/.config/containers/storage.conf 文件的 ConfigMap。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: fuse-overlay
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
      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 Toggle word wrap
    警告

    创建此 ConfigMap 将导致所有正在运行的工作区重启。

验证步骤

  1. 启动包含所需注解的工作区,并验证存储驱动程序是否已 覆盖

    $ podman info | grep overlay
    Copy to Clipboard Toggle word wrap

    输出示例:

    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 Toggle word wrap
    注意

    现有工作区可能会出现以下错误:

    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 Toggle word wrap

    在这种情况下,删除错误信息中所述的 libpod 本地文件。

1.6. 使用 kubedock 运行容器

Kubedock 是一个最小的容器引擎实现,您可以在 OpenShift Dev Spaces 工作区内为您提供类似 Podman-/docker 的体验。在处理临时、临时和测试容器时,Kubedock 特别有用,比如在以下列出的用例中:

重要

您要与 kubedock 搭配使用的镜像必须符合 Openshift Container Platform 指南。否则,使用 kubedock 运行镜像会导致失败,即使同一镜像在没有问题的情况下在本地运行。

启用 kubedock

启用 kubedock 环境变量后,kubedock 将运行以下 podman 命令:

  • Podman 运行
  • Podman ps
  • podman exec
  • podman cp
  • podman logs
  • podman inspect
  • Podman kill
  • podman rm
  • Podman wait
  • Podman stop
  • Podman start

podman build 等其他命令由本地 Podman 启动。

重要

在 kubedock 中使用 podman 命令有以下限制

  • podman build -t <image> . && podman run <image > 命令将失败。使用 podman build -t <image> . && podman push <image> && podman run <image > 替代。
  • 不支持 podman generate kube 命令。
  • --env 选项会导致 podman run 命令失败。

Process

  • KUBEDOCK_ENABLED=true 环境变量添加到 devfile。

    • (可选)使用 KUBEDOCK_PARAM 变量来指定额外的 kubedock 参数。变量列表位于 此处。另外,您可以使用以下命令查看可用选项:

      # kubedock server --help
      Copy to Clipboard Toggle word wrap

Example

schemaVersion: 2.2.0
metadata:
  name: kubedock-sample-devfile
components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:latest
      memoryLimit: 8Gi
      memoryRequest: 1Gi
      cpuLimit: "2"
      cpuRequest: 200m
      env:
        - name: KUBEDOCK_PARAMS
          value: "--reverse-proxy --kubeconfig /home/user/.kube/config --initimage quay.io/agiertli/kubedock:0.13.0"
        - name: USE_JAVA17
          value: "true"
        - value: /home/jboss/.m2
          name: MAVEN_CONFIG
        - value: -Xmx4G -Xss128M -XX:MetaspaceSize=1G -XX:MaxMetaspaceSize=2G
          name: MAVEN_OPTS
        - name: KUBEDOCK_ENABLED
          value: 'true'
        - name: DOCKER_HOST
          value: 'tcp://127.0.0.1:2475'
        - name: TESTCONTAINERS_RYUK_DISABLED
          value: 'true'
        - name: TESTCONTAINERS_CHECKS_DISABLE
          value: 'true'
      endpoints:
        - exposure: none
          name: kubedock
          protocol: tcp
          targetPort: 2475
        - exposure: public
          name: http-booster
          protocol: http
          targetPort: 8080
          attributes:
            discoverable: true
            urlRewriteSupported: true
        - exposure: internal
          name: debug
          protocol: http
          targetPort: 5005
      volumeMounts:
        - name: m2
          path: /home/user/.m2
  - name: m2
    volume:
      size: 10G
Copy to Clipboard Toggle word wrap

重要

您必须在运行容器时将 Podman 或 docker API 配置为指向 kubedock 设置 CONTAINER_HOST=tcp://127.0.0.1:2475DOCKER_HOST=tcp://127.0.0.1:2475

同时,您必须将 Podman 配置为在构建容器时指向本地 Podman。

第 2 章 在团队工作流中使用 Dev Spaces

在以下文章中了解在您的机构中使用 OpenShift Dev Spaces 的好处:

2.1. 首次贡献者的徽标

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

图 2.1. 工厂徽标

流程

  1. 替换 OpenShift Dev Spaces URL (https:// &lt;openshift_dev_spaces_fqdn&gt;)和存储库 URL (<your_repository_url>),并将链接添加到项目 README.md 文件中的存储库。

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

2.2. 查看拉取和合并请求

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.3. 在 Web IDE GitHub 操作中尝试

Web IDE GitHub 操作中的 Try 可以添加到 GitHub 存储库工作流中,以帮助检查人员快速测试由红帽托管的 Eclipse Che 的拉取请求。此操作通过侦听拉取请求事件并提供工厂 URL 来达到此目的,方法是创建一个注释、状态检查或两者。此工厂 URL 从由红帽托管的 Eclipse Che 上的拉取请求分支创建一个新的工作区。

注意

Che 文档存储库https://github.com/eclipse/che-docs是一个现实生命周期示例,Web IDE GitHub 操作中的 Try 可帮助审查程序快速测试拉取请求。进入最新的拉取请求并打开 factory URL 来体验工作流。

图 2.2. 在 Web IDE GitHub 操作中的 Try 创建的拉取请求注释。点徽标会打开检查者的新工作区来测试拉取请求。

图 2.3. 拉取由 Try 在 Web IDE GitHub 操作中创建的拉取请求状态检查。单击"Details"链接会打开新的工作区,供检查者进行测试拉取请求。

2.3.1. 将操作添加到 GitHub 存储库工作流

本节论述了如何将 Web IDE GitHub 操作中的 Try 集成到 GitHub 仓库工作流中。

先决条件

  • A GitHub repository
  • GitHub 仓库根目录中的 devfile。

流程

  1. 在 GitHub 仓库中,创建一个 .github/workflows 目录(如果还没有存在)。
  2. .github/workflows 目录中创建 example.yml 文件,其内容如下:

    例 2.1. example.yml

    name: Try in Web IDE example
    
    on:
      pull_request_target:
        types: [opened]
    
    jobs:
      add-link:
        runs-on: ubuntu-20.04
        steps:
          - name: Web IDE Pull Request Check
            id: try-in-web-ide
            uses: redhat-actions/try-in-web-ide@v1
            with:
              # GitHub action inputs
    
              # required
              github_token: ${{ secrets.GITHUB_TOKEN }}
    
              # optional - defaults to true
              add_comment: true
    
              # optional - defaults to true
              add_status: true
    Copy to Clipboard Toggle word wrap

    此代码片段在 Web IDE 示例 中创建一个名为 Try 的工作流,其中有一个运行 redhat-actions/try-in-web-ide 社区操作的 v1 版本的作业。工作流在打开的活动类型上的 pull_request_target 事件 上触发。

  3. (可选)配置 on.pull_request_target.types 字段中的活动类型,以便在工作流触发器时进行自定义。重新打开 和同步 活动类型非常有用。

    例 2.2. 在 打开 和同步 活动类型上触发工作流

    on:
      pull_request_target:
        types: [opened, synchronize]
    Copy to Clipboard Toggle word wrap
  4. (可选)在 example.yml 中配置 add_commentadd_status GitHub 操作输入。这些输入会发送到 Web IDE GitHub 操作中的 Try,以自定义是否进行注释和状态检查。

2.3.2. 提供 devfile

建议在存储库的根目录中提供 devfile,以定义由工厂 URL 创建的工作区的开发环境。这样,工作区包含用户查看拉取请求所需的所有内容,如插件、开发命令和其他环境设置。

Che 文档存储库 devfile 是定义良好的有效 devfile 的示例。

第 3 章 自定义工作区组件

自定义工作区组件:

第 4 章 Dev Spaces 中的 devfile 介绍

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

Red Hat OpenShift Dev Spaces 特定的 devfile 功能

Red Hat OpenShift Dev Spaces 应该与 devfile 的 components 部分中定义的大多数流行镜像一起工作。对于生产环境,建议使用其中一个 通用基础镜像 作为定义云开发环境的基础镜像。

警告

由于 Visual Studio Code - 开源("Code - OSS")在缺少 openssllibbrotli 的容器中,无法用作定义云环境的一些镜像。缺少的库应在 Dockerfile 级别上明确安装,例如 RUN yum install compat-openssl11 libbrotli

devfile 和通用基础镜像

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

devfile Registry

Devfile Registry 包含用于不同语言和技术的可随时使用社区支持的 devfile。registry 中包含的 devfile 应该被视为示例而不是模板。

第 5 章 工作区中的 IDE

5.1. 支持的 IDE

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

Expand
表 5.1. 支持的 IDE
IDEStatusid备注

Microsoft Visual Studio Code - Open Source

可用

  • che-incubator/che-code/latest
  • che-incubator/che-code/insiders
  • latest 是当不使用 URL 参数或 che-editor.yaml 时,在新的工作区中载入的默认 IDE。
  • Insiders 是开发版本。

JetBrains IntelliJ IDEA 社区版

Deprecated

  • Che-incubator/che-idea/latest
  • che-incubator/che-idea/next
  • latest 是稳定版本。
  • 接下来是 开发版本。

JetBrains IntelliJ IDEA Ultimate Edition (在 JetBrains 网关)

技术预览

  • che-incubator/che-idea-server/latest
  • che-incubator/che-idea-server/next
  • latest 是稳定版本。
  • 接下来是 开发版本。

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

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

5.3. 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: 打开 Dashboard
    • Dev Spaces: 打开 OpenShift Console
    • dev Spaces: Stop Workspace
    • dev Spaces: Restart Workspace
    • dev Spaces: Restart Workspace from Local Devfile
    • dev Spaces: Open Documentation
提示

通过调用 Command busybox 并选择 Preferences: Open Workspace Settings,按工作区配置 IDE 首选项。

注意

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

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

先决条件

流程

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

    1. Open VSX 注册表网站中查找 扩展,再复制扩展列表页面的 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 文件中添加 & <extension> lt; publisher > 和 name,如下所示:

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

验证

  1. 使用包含创建的 extensions.json 文件的远程 Git 存储库的 URL 来启动新的工作区
  2. 在工作区的 IDE 中,按 Ctrl+Shift+X 或转至 Extensions 以查找文件中列出的每个扩展。
  3. 扩展具有标签 This extension is globally 启用
重要

目前,仅对 x86 OpenShift 集群实施与 JetBrains 网关 的集成。

Red Hat OpenShift Dev Spaces 支持在 JetBrains 网关上将本地 IntelliJ IDE 连接到正在运行的 OpenShift Dev Spaces 工作区。

先决条件

  1. 已安装 JetBrains 网关应用程序
  2. 已安装 OpenShift Dev Spaces 的网关供应商
  3. 在本地终端中,您使用 OpenShift 客户端登录到 OpenShift 服务器。

    注意

    oc login 命令建立经过身份验证的会话,并将连接信息保存到配置文件,该文件由 OpenShift Dev Spaces 的网关提供程序读取。

流程

  1. 在 OpenShift Dev Spaces 仪表板中创建一个工作区,并选择 IntelliJ IDEA Ultimate (desktop) 编辑器:

  2. 等待提示打开您的本地 JetBrains 网关应用程序:

点击 Open Gateway 按钮启动连接到您的 Dev Spaces 工作区的本地 JetBrains 客户端应用程序:

将 JetBrains IntelliJ IDEA Ultimate Edition 连接到现有的工作区

将本地 IntelliJ IDE 连接到现有工作区有两个选项:

  • 在 Che 仪表板中
  • 从网关应用程序

连接到现有工作区的最简单方法是从 OpenShift Dev Spaces 仪表板启动工作区,然后点 Open Gateway 按钮。但是,使用网关应用程序,您可以在访问 OpenShift Dev Spaces 仪表板的情况下将 IntelliJ IDE 连接到工作区。

流程

  1. 打开 Gateway 应用程序并点 Connect to Dev Spaces

  2. 在下一页中,提供用于连接 OpenShift API 服务器的参数,然后点 Check Connection 和 Continue 按钮:

  3. 选择工作区并点 Connect 按钮:

验证

  1. 您的本地网关应用程序正在运行 JetBrains 客户端,并连接到工作区。

5.5. 定义通用 IDE

虽然 第 1.1.1.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.5.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.5.2. che-editor.yaml 的参数

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

Expand
表 5.2. 支持的 IDE
IDEStatusid备注

Microsoft Visual Studio Code - Open Source

可用

  • che-incubator/che-code/latest
  • che-incubator/che-code/insiders
  • latest 是当不使用 URL 参数或 che-editor.yaml 时,在新的工作区中载入的默认 IDE。
  • Insiders 是开发版本。

JetBrains IntelliJ IDEA 社区版

Deprecated

  • Che-incubator/che-idea/latest
  • che-incubator/che-idea/next
  • latest 是稳定版本。
  • 接下来是 开发版本。

JetBrains IntelliJ IDEA Ultimate Edition (在 JetBrains 网关)

技术预览

  • che-incubator/che-idea-server/latest
  • che-incubator/che-idea-server/next
  • 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 文件支持 registryUrloverride 参数:

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

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

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

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

  • 将您的凭据和敏感配置挂载为 Kubernetes Secret
  • 将您的非敏感配置挂载为 Kubernetes ConfigMap

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

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

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

6.1. 挂载 Secret

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

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

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

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 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

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

使用 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 文件来创建镜像拉取 Secret。

6.1.1.1. 使用 oc创建镜像 pull Secret

先决条件

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

流程

  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. 在镜像拉取 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 文件创建镜像拉取 Secret

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

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 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。

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 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 用户配置它,则临时解决方案是使用个人访问令牌。您可以在 OpenShift Dev Spaces 仪表板的 用户首选项 页面中配置个人访问令牌: https:// <openshift_dev_spaces_fqdn>/dashboard/#/user-preferences?tab=personal-access-tokens,或者在命名空间中手动应用它作为 Kubernetes Secret。

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

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

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

您可以为每个 Git 供应商创建并应用多个 access-token Secret。您必须在用户项目中应用每个 Secret。

先决条件

  • 已登陆到集群。

    提示

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

    $ oc login https://<openshift_dev_spaces_fqdn> --username=<my_user>

流程

  1. 在 Git 提供程序的网站上生成您的访问令牌。

    重要

    个人访问令牌是敏感信息,应保留机密。将它们视为密码。如果您在身份验证时遇到问题,请确保使用正确的令牌并具有适当的克隆存储库权限:

    1. 在您的计算机上本地打开终端
    2. 使用 git 命令,使用您的个人访问令牌克隆存储库。git 命令的格式因 Git 提供程序而异。例如,可以使用以下命令进行 GitHub 个人访问令牌验证:
    git clone https://<PAT>@github.com/username/repo.git
    Copy to Clipboard Toggle word wrap

    <PAT > 替换为您的个人访问令牌,并将 username/repo 替换为适当的存储库路径。如果令牌有效并且具有必要的权限,克隆过程应该可以成功。否则,这代表了不正确的个人访问令牌、权限不足或其他问题。

    重要

    对于 GitHub Enterprise Cloud,请验证 令牌是否在机构 中使用

  2. 进入 web 浏览器中的 https:// <openshift_dev_spaces_fqdn> /api/user/id 来获取您的 OpenShift Dev Spaces 用户 ID。
  3. 准备新的 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-organization: <git_provider_organization>
    4
    
    stringData:
      token: <Content_of_access_token>
    type: Opaque
    Copy to Clipboard Toggle word wrap
    1
    您的 OpenShift Dev Spaces 用户 ID。
    2
    Git 提供程序名称: githubgitlabbitbucket-serverazure-devops
    3
    Git 提供程序 URL。
    4
    这一行仅适用于 azure-devops :您的 Git 供应商用户机构,或者在使用 Azure DevOps Server 时收集。
  4. 访问 https://<openshift_dev_spaces_fqdn&gt; /api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间,名为。
  5. 切换到集群中的 OpenShift Dev Spaces 用户命名空间。

    提示

    在 OpenShift 中:

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

      $ oc project

    • 如果需要,您可以在命令行中切换到 OpenShift Dev Spaces 用户命名空间:

      $ oc project & lt;your_user_namespace>

  6. 应用 Secret。

    提示

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

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

如果使用 Azure DevOps 服务器,还必须使用以下部分修改 工作区的 gitconfig

[http]
    extraheader = "Authorization: Basic <base64-encoded(:personal-access-token)>"
Copy to Clipboard Toggle word wrap

要生成键值对,请使用以下命令:

echo -n "extraheader = \"Authorization: Basic "$(printf ":%s" <personal access token> | base64)\"
Copy to Clipboard Toggle word wrap

如需更多信息 ,请参阅文档页面

远程 git 操作需要 extraheader 配置,例如 git clone Server。此授权方法的优先级高于 git 凭证存储,因此对其他 Git 供应商的远程操作将失败。

验证

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

6.2. 挂载 ConfigMap

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

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

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

先决条件

  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 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.2.1. 挂载 Git 配置

注意

user.nameuser.email 字段会自动设置为 git 供应商中的 gitconfig 内容,连接到 Git-provider 访问令牌 或通过 OAuth 生成的令牌,如果供应商的用户配置集页面中设置了用户名和电子邮件。

按照下面的说明在工作区中挂载 Git 配置文件。

先决条件

  • 已登陆到集群。

流程

  1. 准备新的 OpenShift ConfigMap。

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: workspace-userdata-gitconfig-configmap
      namespace: <user_namespace> 
    1
    
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-configmap: 'true'
      annotations:
        controller.devfile.io/mount-as: subpath
        controller.devfile.io/mount-path: /etc/
    data:
      gitconfig: <gitconfig content> 
    2
    Copy to Clipboard Toggle word wrap
    1
    用户命名空间。访问 https://<openshift_dev_spaces_fqdn&gt; /api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间,名为。
    2
    gitconfig 文件内容的内容。
  2. 应用 ConfigMap。

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

验证

  1. 使用 Git 提供程序主机的远程 Git 存储库的 URL,启动新的工作区
  2. 启动工作区后,在 tools 容器中运行一个新的终端,并运行 git config --get-regexp user ""。您的 Git 用户名和电子邮件应当会显示在输出中。

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 初始化脚本应用 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: /public-certs
        controller.devfile.io/mount-as: file
      labels:
        controller.devfile.io/mount-to-devworkspace: 'true'
        controller.devfile.io/watch-secret: 'true'
    data:
      nexus.cer: >-
        <Base64_encoded_content_of_public_cert>__ 
    1
    Copy to Clipboard Toggle word wrap
    1
    带有禁用行嵌套的 Base64 编码。
  2. 应用 ConfigMap 在 工具容器中设置以下环境变量

    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:
      NPM_CONFIG_REGISTRY: >-
        https://<npm_artifact_repository_route>/repository/npm-all/
    Copy to Clipboard Toggle word wrap
6.3.3.1. 禁用自签名证书验证

运行以下命令禁用 SSL/TLS,绕过自签名证书验证。请注意,这是一个潜在的安全风险。为获得更好的解决方案,请使用 NODE_EXTRA_CA_CERTS 配置您信任的自签名证书。

流程

  • 在终端中运行以下命令:

    npm config set strict-ssl false
    Copy to Clipboard Toggle word wrap
6.3.3.2. 配置 NODE_EXTRA_CA_CERTS 以使用证书

使用以下命令,将 NODE_EXTRA_CA_CERTS 设置为指向您具有 SSL/TLS 证书的位置。

流程

  • 在终端中运行以下命令:

    `export NODE_EXTRA_CA_CERTS=/public-certs/nexus.cer` 
    1
    
    `npm install`
    Copy to Clipboard Toggle word wrap
    1
    /public-certs/HEKETI.cer 是 Nexus 工件ory 自签名 SSL/TLS 证书的路径。

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 在 工具容器中设置以下环境变量

    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 在 工具容器中设置以下环境变量

    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 容器。

先决条件

  • 您尚未启动工作区。
  • 对目标 OpenShift 集群具有管理权限的活动 oc 会话。请参阅 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
    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

    controller.devfile.io/read-only: 'true'
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi 
2

  storageClassName: <storage_class_name> 
3

  volumeMode: Filesystem
Copy to Clipboard Toggle word wrap
1
挂载的 PV 位于工作区的 </example/directory>
2
请求存储的大小值示例。
3
声明所需的 StorageClass 的名称。如果要使用默认 StorageClass,请删除此行。

第 8 章 与 OpenShift 集成

8.1. 使用 OpenShift API 管理工作区

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

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

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

8.1.1. 列出所有工作区

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

先决条件

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

    提示

    您可以访问 https:// &lt;openshift_dev_spaces_fqdn&gt; /api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间,名为。

  • 您位于集群的 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: http://devspaces-dashboard.openshift-devspaces.svc.cluster.local:8080/dashboard/api/editors/devfile?che-editor=che-incubator/che-code/latest
      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
    User namespace,这是新工作区的目标项目。
    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. 当工作区成功启动时,在 oc get devworkspaces 命令的输出中,其 PHASE 状态将变为 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:// &lt;openshift_dev_spaces_fqdn&gt; /api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间,名为。

  • 您位于集群的 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:// &lt;openshift_dev_spaces_fqdn&gt; /api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间,名为。

  • 您位于集群的 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 自定义资源来删除工作区。

警告

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

提示

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

先决条件

  • 集群中的活跃 oc 会话。请参阅 CLI 入门
  • 您知道工作区名称。

    提示

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

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

    提示

    您可以访问 https:// &lt;openshift_dev_spaces_fqdn&gt; /api/kubernetes/namespace 来获取您的 OpenShift Dev Spaces 用户命名空间,名为。

  • 您位于集群的 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 选项卡。

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

流程

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

其他资源

9.2. 慢速工作区故障排除

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

本节包括几个用于更快地启动工作区或改进工作区运行时性能的调优选项。

9.2.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.22/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.22/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.2.2. 提高工作区运行时性能

提供足够的 CPU 资源

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

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

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.3. 网络问题故障排除

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

先决条件

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

流程

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

9.4. Web 视图加载错误故障排除

如果您在私有浏览窗口中使用 Microsoft Visual Studio Code - 开源,您可能会遇到以下错误消息: Error loading webview: Error: Could not register service workers

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

  • Google Chrome in Incognito 模式
  • 私有 Browsing 模式中的 Mozilla Firefox
Expand
表 9.1. 在私有浏览窗口中处理 webview 错误
浏览器

临时解决方案

Google Chrome

进入 SettingsPrivacy and securityCookies 和其他站点数据Allow all cookies

Mozilla Firefox

Private Browsing 模式不支持 Web 视图。详情请查看 这个报告的错误

法律通告

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

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat