用户指南
使用 Red Hat OpenShift Dev Spaces 3.22
摘要
第 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 来启动新的工作区。
- 如果使用 SSH URL 启动新的工作区,您必须传播 SSH 密钥。如需更多信息,请参阅配置 DevWorkspace 为 Git 操作使用 SSH 密钥。
-
如果 SSH URL 指向私有存储库,您必须应用访问令牌来获取
devfile.yaml内容。您可以通过接受 SCM 身份验证页面或按照 个人访问令牌 流程进行此操作。
配置个人访问令牌以访问私有存储库。请参阅 第 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 存储库克隆来启动一个新的工作区:
- 可选:访问 OpenShift Dev Spaces 仪表板页面,以向您的机构的 OpenShift Dev Spaces 实例进行身份验证。
访问 URL,以使用基本语法启动新的工作区:
https://<openshift_dev_spaces_fqdn>#<git_repository_url>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您可以使用可选参数扩展此 URL:
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?<optional_parameters>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?<optional_parameters>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 提示您可以使用 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> #https:/// <user_or_org> / <repository> 启动一个带有默认分支克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn> #https:///<user_or_org> / <repository> /tree/ & lt;branch_name> 启动一个带有指定分支克隆的新工作区。 -
https://<openshift_dev_spaces_fqdn> #https:/// <user_or_org> / <repository> /pull/ & lt;pull_request_id> 启动带有拉取请求分支的新工作区。 -
https:// <openshift_dev_spaces_fqdn>#git@:<user_or_org> / <repository > .git从 Git+SSH URL 启动一个新的工作区。
例 1.3. 使用 GitLab 实例存储库克隆来启动新工作区的 URL 语法
-
https://<openshift_dev_spaces_fqdn> #https:/// <user_or_org> / <repository> 启动一个带有默认分支克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn> #https:///<user_or_org> / <repository> /-/tree/& lt;branch_name> 启动带有指定分支克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn>#git@:<user_or_org> / <repository > .git从 Git+SSH URL 启动一个新的工作区。
例 1.4. 使用 BitBucket 服务器存储库克隆来启动新工作区的 URL 语法
-
https:// <openshift_dev_spaces_fqdn> #https://<bb_host> /scm/ <project-key> / <repository > .git启动一个带有默认分支克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn>#https:// <bb_host> /users/<user_slug> /repos/ <repository> /repos/ has a new workspace of a clone of the default branch, if an repository was created in the user profile. -
https:// <openshift_dev_spaces_fqdn> #https://<bb_host> /users/ <user-slug> /repos/ <repository> /browse?at=refs%2Fheads%2F<branch-name> 启动带有指定分支的克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn>#git@ <bb_host>: <user_slug> / <repository > .git从 Git+SSH URL 启动一个新的工作区。
例 1.5. 使用 Microsoft Azure DevOps Git 存储库的克隆来启动新工作区的 URL 语法
-
https:// <openshift_dev_spaces_fqdn> #https://<organization> @dev.azure.com/<organization> / <project> /_git/ <repository> 启动一个带有默认分支克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn>#https:// <organization> @dev.azure.com/<organization> / <project> /_git/ <repository > ?version=GB <branch> 启动带有特定分支的克隆的新工作区。 -
https:// <openshift_dev_spaces_fqdn>#git@ssh.dev.azure.com:v3/ <organization> /<project> / <repository> 从 Git+SSH URL 中启动新的工作区。
在输入 URL 以在浏览器标签页中启动新的工作区后,会显示工作区启动页面。
当新的工作区就绪后,工作区 IDE 会在浏览器选项卡中加载。
新工作区的文件系统中会出现 Git 存储库的克隆。
工作区具有唯一的 URL:
https:// <openshift_dev_spaces_fqdn> / <user_name> / <unique_url>。-
其他资源
1.1.1. 用于启动新的工作区的 URL 的可选参数 复制链接链接已复制到粘贴板!
当您启动新的工作区时,OpenShift Dev Spaces 根据 devfile 中的说明配置工作区。当使用 URL 启动新的工作区时,您可以将可选参数附加到进一步配置工作区的 URL 中。您可以使用这些参数来指定工作区 IDE,启动重复的工作区,并指定 devfile 文件名或路径。
- 第 1.1.1.1 节 “URL 参数串联”
- 第 1.1.1.2 节 “IDE 的 URL 参数”
- 第 1.1.1.3 节 “IDE 镜像的 URL 参数”
- 第 1.1.1.4 节 “用于启动重复工作区的 URL 参数”
- 第 1.1.1.5 节 “devfile 文件名的 URL 参数”
- 第 1.1.1.6 节 “devfile 文件路径的 URL 参数”
- 第 1.1.1.7 节 “工作区存储的 URL 参数”
- 第 1.1.1.8 节 “其他远程的 URL 参数”
- 第 1.1.1.9 节 “容器镜像的 URL 参数”
- 第 1.1.1.10 节 “内存限制的 URL 参数”
- 第 1.1.1.11 节 “CPU 限值的 URL 参数”
1.1.1.1. URL 参数串联 复制链接链接已复制到粘贴板!
启动新的工作区的 URL 支持使用 & amp; 及以下 URL 语法连接多个可选 URL 参数:
https:// <openshift_dev_spaces_fqdn> #?<url_parameter_1> & <url_parameter_2> & <url_parameter_3>
例 1.6. 使用 Git 存储库的 URL 和可选 URL 参数启动新工作区的 URL
浏览器的完整 URL:
https:// <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> #https://github.com/che-samples/cpp-hello-world ?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml
https://<openshift_dev_spaces_fqdn>
#https://github.com/che-samples/cpp-hello-world
?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml
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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?che-editor=<editor_key>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表 1.1. 支持的 IDE 的 URL 参数 <editor_key > 值 IDE Status <editor_key>值备注 可用
-
che-incubator/che-code/latest -
che-incubator/che-code/insiders
-
latest是当不使用 URL 参数或che-editor.yaml时,在新的工作区中载入的默认 IDE。 -
Insiders是开发版本。
Deprecated
-
Che-incubator/che-idea/latest -
che-incubator/che-idea/next
-
latest是稳定版本。 -
接下来是开发版本。
技术预览
-
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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?che-editor=<url_to_a_file>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指向包含 devfile 内容的 文件的 URL。
提示- URL 必须指向原始文件内容。
-
要将此参数与
che-editor.yaml文件一起使用,请使用另一个名称或路径复制该文件,并从文件中删除内联行。
- che-editors.yaml 文件包含 所有支持的 IDE 的 devfile。
1.1.1.3. IDE 镜像的 URL 参数 复制链接链接已复制到粘贴板!
您可以使用 editor-image 参数为工作区设置自定义 IDE 镜像。
-
如果 Git 存储库包含
/.che/che-editor.yaml文件,则自定义编辑器将使用新的 IDE 镜像覆盖。 -
如果 Git 存储库中没有
/.che/che-editor.yaml文件,则默认的编辑器将使用新的 IDE 镜像覆盖。 -
如果要覆盖支持的 IDE 并更改目标编辑器镜像,您可以同时使用这两个参数:
che-editor和editor-imageURL 参数。
覆盖 IDE 镜像的 URL 参数是 editor-image= :
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?editor-image=<container_registry/image_name:image_tag>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?editor-image=<container_registry/image_name:image_tag>
Example:
https:// <openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?editor-image=quay.io/che-incubator/che-code:next
或者
https:// <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
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?new
如果您目前有一个使用 URL 启动的工作区,那么在没有 新 URL 参数的情况下再次访问 URL 会导致错误消息。
1.1.1.5. devfile 文件名的 URL 参数 复制链接链接已复制到粘贴板!
当您访问 URL 来启动新的工作区时,OpenShift Dev Spaces 将链接的 Git 存储库搜索带有文件名 .devfile.yaml 或 devfile.yaml 的 devfile。链接 Git 存储库中的 devfile 必须遵循此文件命名惯例。
在某些情况下,您可能需要为 devfile 指定不同的、不协调的文件名。
用于指定 devfile 的 unconventional 文件名的 URL 参数为 df= <filename>.yaml :
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?df=<filename>.yaml
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?df=<filename>.yaml
- 1
<filename > .yaml是链接 Git 存储库中的 devfile 的 unconventional 文件名。
df= <filename> .yaml 参数也有一个长版本: devfilePath= <filename>.yaml。
1.1.1.6. devfile 文件路径的 URL 参数 复制链接链接已复制到粘贴板!
当您访问 URL 来启动新的工作区时,OpenShift Dev Spaces 会在链接 Git 存储库的根目录中搜索名为 .devfile.yaml 或 devfile.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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?devfilePath=<relative_file_path>
- 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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?storageType=<storage_type>
- 1
- 可能的 <
;storage_type> 值:-
ephemeral -
每个用户(永久) -
per-workspace(persistent)
-
使用 ephemeral 或 per-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>},...}
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?remotes={{<name_1>,<url_1>},{<name_2>,<url_2>},{<name_3>,<url_3>},...}
-
如果您没有为任何其他远程输入名称
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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?image=<container_image_url>
Example
https:// <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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?memoryLimit=<container_memory_limit>
您可以以字节为单位指定内存限值,或使用 Mi 作为兆字节,Gi 用于千兆字节。
例 1.7. Example
https:// <openshift_dev_spaces_fqdn>#https://github.com/eclipse-che/che-docs?memoryLimit=4Gi
当您指定 memoryLimit 参数时,它会覆盖为 devfile 的第一个容器定义的内存限值。
目标 devfile 和编辑器定义中的限制总和将应用到工作区 pod spec.containers[0].resources.limits.memory。
其他资源
- 限制资源使用量
- {editor-definition-samples-link}
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>
https://<openshift_dev_spaces_fqdn>#<git_repository_url>?cpuLimit=<container_cpu_limit>
您可以在内核中指定 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。
其他资源
- 限制资源使用量
- {editor-definition-samples-link}
1.2. 从原始 devfile URL 启动工作区 复制链接链接已复制到粘贴板!
使用 OpenShift Dev Spaces,您可以在浏览器中打开 devfile URL 来启动新的工作区。
您可以使用 OpenShift Dev Spaces 仪表板的 Create Workspace 页面中的 Git Repo URL 字段输入 devfile 的 URL 来启动新的工作区。
要在新工作区的文件系统中启动 Git 存储库克隆,devfile 必须包含项目信息。
先决条件
- 您的机构有一个 OpenShift Dev Spaces 实例运行。
-
您知道机构的 OpenShift Dev Spaces 实例的 FQDN URL:
https:// <openshift_dev_spaces_fqdn>。
流程
从 devfile URL 中启动新的工作区:
- 可选:访问 OpenShift Dev Spaces 仪表板页面,以向您的机构的 OpenShift Dev Spaces 实例进行身份验证。
访问 URL,以使用基本语法从 公共存储库中 启动新的工作区:
https://<openshift_dev_spaces_fqdn>#<devfile_url>
https://<openshift_dev_spaces_fqdn>#<devfile_url>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以将个人访问令牌传递给 URL,以从 私有仓库 访问 devfile:
https://<openshift_dev_spaces_fqdn>#https://<token>@<host>/<path_to_devfile>
https://<openshift_dev_spaces_fqdn>#https://<token>@<host>/<path_to_devfile>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 您在 Git 供应商网站上生成的个人访问令牌。
这适用于 GitHub、GitLab、Bitbucket、Microsoft Azure 以及支持个人访问令牌的其他供应商。
重要在这种情况下,自动化 Git 凭证注入无法正常工作。要配置 Git 凭据,请使用 配置个人访问令牌 指南。
提示您可以使用可选参数扩展此 URL:
https://<openshift_dev_spaces_fqdn>#<devfile_url>?<optional_parameters>
https://<openshift_dev_spaces_fqdn>#<devfile_url>?<optional_parameters>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例 1.9. 从公共存储库中启动新工作区的 URL
https:// <openshift_dev_spaces_fqdn>#https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml例 1.10. 从私有存储库启动新工作区的 URL
https://<openshift_dev_spaces_fqdn> #https:// <token> @raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml验证
在输入 URL 以在浏览器标签页中启动新的工作区后,会显示工作区启动页面。当新的工作区就绪后,工作区 IDE 会在浏览器选项卡中加载。
工作区具有唯一的 URL:
https:// <openshift_dev_spaces_fqdn> / <user_name> / <unique_url>。
1.3. 您可以对工作区执行的基本操作 复制链接链接已复制到粘贴板!
您可以在 OpenShift Dev Spaces 仪表板的 Workspaces 页面中管理您的工作区并验证它们的当前状态(https:// <openshift_dev_spaces_fqdn> /dashboard/:/workspaces)。
启动新的工作区后,您可以在 Workspaces 页面中执行以下操作:
| 操作 | Workspaces 页面中的 GUI 步骤 |
|---|---|
| 重新打开正在运行的工作区 | 点 Open。 |
| 重启正在运行的工作区 | 进入 ⋮ > Restart Workspace。 |
| 停止正在运行的工作区 | 进入 && amp ; & gt; Stop Workspace。 |
| 启动已停止的工作空间 | 点 Open。 |
| 删除工作区 | 进入 && amp ; & gt; Delete Workspace。 |
1.4. 从工作区向 Git 服务器进行身份验证 复制链接链接已复制到粘贴板!
在工作区中,您可以运行需要用户身份验证的 Git 命令,如克隆远程私有 Git 存储库或推送到远程公共或私有 Git 存储库。
从工作区对 Git 服务器的用户身份验证由管理员配置,或者在某些情况下由单个用户配置:
1.5. 为 Podman 和 Buildah 使用 fuse-overlayfs 存储驱动程序 复制链接链接已复制到粘贴板!
默认情况下,新创建的不使用 devfile 的工作区将使用通用基础镜像(UDI)。UDI 包含开发人员常用的开发工具和依赖项。
Podman 和 Buildah 包含在 UDI 中,允许开发人员从工作区构建和推送容器镜像。
默认情况下,UDI 中的 Podman 和 Buildah 被配置为使用 vfs 存储驱动程序。要更有效地镜像管理,请使用 fuse-overlayfs 存储驱动程序,该驱动程序在无根环境中支持 copy-on-write。
您必须在工作区中使用 fuse-overlayfs 的以下要求:
-
对于早于 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访问。 -
工作区具有使用
/dev/fuse设备所需的注解。请参阅 第 1.5.1 节 “访问 /dev/fuse”。 -
工作区容器中的
storage.conf文件已配置为使用 fuse-overlayfs。请参阅 第 1.5.2 节 “使用 ConfigMap 启用 fuse-overlayfs”。
其他资源
1.5.1. 访问 /dev/fuse 复制链接链接已复制到粘贴板!
您必须有权访问 /dev/fuse,才能使用 fuse-overlayfs。本节论述了如何使 /dev/fuse 可以被工作区容器访问。
先决条件
-
对于早于 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的访问。 - 确定要使用 fuse-overlayfs 的工作区。
流程
使用
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$ 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=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 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$ oc patch devworkspace <DevWorkspace_name> \ --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse"}}}}}}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证步骤
启动工作区,并验证
/dev/fuse是否在工作区容器中可用。stat /dev/fuse
$ stat /dev/fuseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
完成此步骤后,按照 第 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"
[storage]
driver = "vfs"
要使用 fuse-overlayfs,storage.conf 可以设置为以下内容:
storage.conf
[storage] driver = "overlay" [storage.options.overlay] mount_program="/usr/bin/fuse-overlayfs"
[storage]
driver = "overlay"
[storage.options.overlay]
mount_program="/usr/bin/fuse-overlayfs"
- 1
fuse-overlayfs二进制文件的绝对路径。/usr/bin/fuse-overlayfs路径是 UDI 的默认路径。
您可以在启动工作区后手动执行此操作。另一种选择是基于 UDI 构建新镜像,并更改 storage.conf,并将新镜像用于工作区。
否则,您可以通过创建一个挂载更新文件的 ConfigMap,为项目中的所有工作区更新 /home/user/.config/containers/storage.conf。请参阅 第 6.2 节 “挂载 ConfigMap”。
先决条件
-
对于早于 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的访问。 - 如下设置带有所需注解的工作区: 第 1.5.1 节 “访问 /dev/fuse”
由于按照 本指南 挂载的 ConfigMap 将 ConfigMap 的数据挂载到所有工作区,因此此流程会将存储驱动程序设置为 fuse-overlayfs。确保工作区包含使用以下 第 1.5.1 节 “访问 /dev/fuse” 来使用 fuse-overlayfs 所需的注解。
流程
应用在项目中挂载
/home/user/.config/containers/storage.conf文件的 ConfigMap。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告创建此 ConfigMap 将导致所有正在运行的工作区重启。
验证步骤
启动包含所需注解的工作区,并验证存储驱动程序是否已
覆盖。podman info | grep overlay
$ podman info | grep overlayCopy to Clipboard Copied! Toggle word wrap Toggle overflow 输出示例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意现有工作区可能会出现以下错误:
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 toolsERRO[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 toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 在这种情况下,删除错误信息中所述的 libpod 本地文件。
1.6. 使用 kubedock 运行容器 复制链接链接已复制到粘贴板!
Kubedock 是一个最小的容器引擎实现,您可以在 OpenShift Dev Spaces 工作区内为您提供类似 Podman-/docker 的体验。在处理临时、临时和测试容器时,Kubedock 特别有用,比如在以下列出的用例中:
- 执行依赖 Testcontainers 框架的应用程序测试。
- 使用 Quarkus Dev Services.
- 运行存储在远程容器注册表中的容器,用于本地开发目的
您要与 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
# kubedock server --helpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Example
您必须在运行容器时将 Podman 或 docker API 配置为指向 kubedock 设置 CONTAINER_HOST=tcp://127.0.0.1:2475 或 DOCKER_HOST=tcp://127.0.0.1:2475。
同时,您必须将 Podman 配置为在构建容器时指向本地 Podman。
第 2 章 在团队工作流中使用 Dev Spaces 复制链接链接已复制到粘贴板!
在以下文章中了解在您的机构中使用 OpenShift Dev Spaces 的好处:
2.1. 首次贡献者的徽标 复制链接链接已复制到粘贴板!
要启用第一次使用项目启动工作区,请添加一个带有链接到 OpenShift Dev Spaces 实例的徽标。
图 2.1. 工厂徽标
流程
替换 OpenShift Dev Spaces URL (
https:// <openshift_dev_spaces_fqdn>)和存储库 URL (<your_repository_url>),并将链接添加到项目README.md文件中的存储库。[](https://<openshift_dev_spaces_fqdn>/#https://<your_repository_url>)
[](https://<openshift_dev_spaces_fqdn>/#https://<your_repository_url>)Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
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 实例。
流程
- 打开功能分支,以在 OpenShift Dev Spaces 中查看。分支的克隆会在工作区中打开,其中包含用于调试和测试的工具。
- 检查拉取或合并请求更改。
运行所需的调试和测试工具:
- 运行 linter。
- 运行单元测试。
- 运行构建。
- 运行应用以检查问题。
- 导航到 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。
流程
-
在 GitHub 仓库中,创建一个
.github/workflows目录(如果还没有存在)。 在
.github/workflows目录中创建example.yml文件,其内容如下:例 2.1. example.yml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此代码片段在
Web IDE 示例 中创建一个名为 Try的工作流,其中有一个运行redhat-actions/try-in-web-ide社区操作的v1版本的作业。工作流在打开的活动类型上的pull_request_target事件 上触发。(可选)配置
on.pull_request_target.types字段中的活动类型,以便在工作流触发器时进行自定义。重新打开活动类型非常有用。和同步等例 2.2. 在
打开和同步活动类型上触发工作流on: pull_request_target: types: [opened, synchronize]on: pull_request_target: types: [opened, synchronize]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
(可选)在
example.yml中配置add_comment和add_statusGitHub 操作输入。这些输入会发送到 Web IDE GitHub 操作中的 Try,以自定义是否进行注释和状态检查。
2.3.2. 提供 devfile 复制链接链接已复制到粘贴板!
建议在存储库的根目录中提供 devfile,以定义由工厂 URL 创建的工作区的开发环境。这样,工作区包含用户查看拉取请求所需的所有内容,如插件、开发命令和其他环境设置。
Che 文档存储库 devfile 是定义良好的有效 devfile 的示例。
第 3 章 自定义工作区组件 复制链接链接已复制到粘贴板!
自定义工作区组件:
- 为您的工作区选择一个 Git 存储库。
- 使用 devfile。
- 配置 IDE。
- 除了通用 devfile 规格外,添加 OpenShift Dev Spaces 特定的属性。
第 4 章 Dev Spaces 中的 devfile 介绍 复制链接链接已复制到粘贴板!
devfile 是用于开发环境自定义的 yaml 文本文件。https://devfile.io/使用它们配置 devfile 以满足您的特定需求,并在多个工作区间共享自定义的 devfile,以确保在您的团队中使用相同的用户体验和构建、部署和部署行为。
Red Hat OpenShift Dev Spaces 应该与 devfile 的 components 部分中定义的大多数流行镜像一起工作。对于生产环境,建议使用其中一个 通用基础镜像 作为定义云开发环境的基础镜像。
由于 Visual Studio Code - 开源("Code - OSS")在缺少 openssl 和 libbrotli 的容器中,无法用作定义云环境的一些镜像。缺少的库应在 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:
| IDE | Status | id | 备注 |
|---|---|---|---|
| 可用 |
|
| |
| Deprecated |
|
| |
| 技术预览 |
|
|
5.2. OpenShift Dev Spaces 中的存储库级 IDE 配置 复制链接链接已复制到粘贴板!
您可以将 IDE 配置文件直接存储在包含项目源代码的远程 Git 存储库中。这样,一个常见的 IDE 配置应用于具有该存储库克隆的所有新工作区。这种 IDE 配置文件可能包含以下内容:
- 保存 所选 IDE 定义的 /.che/che-editor.yaml 文件。
- 特定于 IDE 的配置文件通常会为桌面 IDE 存储在本地。例如: /.vscode/extensions.json 文件。
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 中看到您所在机构的品牌。
5.3.1. 在工作区启动时自动安装 Microsoft Visual Studio Code 扩展 复制链接链接已复制到粘贴板!
要让 Microsoft Visual Studio Code - 开源 IDE 自动安装所选的扩展,您可以在包含项目源代码的远程 Git 存储库中添加 extensions.json 文件,并将其克隆到工作区中。
先决条件
选择 open-vsx.org 上的公共 OpenVSX 注册表,并通过互联网访问。请参阅 选择 Open VSX 注册表实例。
提示
流程
获取每个所选扩展的发布程序和扩展名称:
- 在 Open VSX 注册表网站中查找 扩展,再复制扩展列表页面的 URL。
从复制的 URL 中提取 <publisher > 和名称 <extension> :
https://www.open-vsx.org/extension/<publisher>/<extension>
https://www.open-vsx.org/extension/<publisher>/<extension>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
在远程 Git 仓库中创建
.vscode/extensions.json文件。 在
extensions.json文件中添加 & <extension> lt; publisher > 和 name,如下所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
-
使用包含创建的
extensions.json文件的远程 Git 存储库的 URL 来启动新的工作区。 - 在工作区的 IDE 中,按 Ctrl+Shift+X 或转至 Extensions 以查找文件中列出的每个扩展。
- 扩展具有标签 This extension is globally 启用。
目前,仅对 x86 OpenShift 集群实施与 JetBrains 网关 的集成。
Red Hat OpenShift Dev Spaces 支持在 JetBrains 网关上将本地 IntelliJ IDE 连接到正在运行的 OpenShift Dev Spaces 工作区。
先决条件
- 已安装 JetBrains 网关应用程序。
- 已安装 OpenShift Dev Spaces 的网关供应商。
在本地终端中,您使用 OpenShift 客户端登录到 OpenShift 服务器。
注意oc login命令建立经过身份验证的会话,并将连接信息保存到配置文件,该文件由 OpenShift Dev Spaces 的网关提供程序读取。
流程
在 OpenShift Dev Spaces 仪表板中创建一个工作区,并选择
IntelliJ IDEA Ultimate (desktop)编辑器:等待提示打开您的本地 JetBrains 网关应用程序:
点击 Open Gateway 按钮启动连接到您的 Dev Spaces 工作区的本地 JetBrains 客户端应用程序:
将 JetBrains IntelliJ IDEA Ultimate Edition 连接到现有的工作区
将本地 IntelliJ IDE 连接到现有工作区有两个选项:
- 在 Che 仪表板中
- 从网关应用程序
连接到现有工作区的最简单方法是从 OpenShift Dev Spaces 仪表板启动工作区,然后点 Open Gateway 按钮。但是,使用网关应用程序,您可以在访问 OpenShift Dev Spaces 仪表板的情况下将 IntelliJ IDE 连接到工作区。
流程
打开 Gateway 应用程序并点
Connect to Dev Spaces:在下一页中,提供用于连接 OpenShift API 服务器的参数,然后点
Check Connection 和 Continue按钮:选择工作区并点
Connect按钮:
验证
您的本地网关应用程序正在运行 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文件。
验证
- 使用 Git 存储库 克隆来启动新的工作区。
- 验证指定的 IDE 是否在启动工作区的浏览器选项卡中加载。
5.5.2. che-editor.yaml 的参数 复制链接链接已复制到粘贴板!
在 che-editor.yaml 中选择 IDE 的最简单方法是从支持的 IDE 表中指定 IDE 的 id :
| IDE | Status | id | 备注 |
|---|---|---|---|
| 可用 |
|
| |
| Deprecated |
|
| |
| 技术预览 |
|
|
例 5.1. ID 从插件 registry 中选择一个 IDE
id: che-incubator/che-idea/latest
id: che-incubator/che-idea/latest
作为提供 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
reference: https://<hostname_and_path_to_a_remote_file>/che-editor.yaml
例 5.3. inline 为没有插件 registry 的自定义 IDE 指定一个完整的定义
对于更复杂的场景,che-editor.yaml 文件支持 registryUrl 和 override 参数:
例 5.4. registryUrl 指向自定义插件 registry,而不是默认的 OpenShift Dev Spaces 插件 registry
id: <editor_id> registryUrl: <url_of_custom_plugin_registry>
id: <editor_id>
registryUrl: <url_of_custom_plugin_registry>
- 1
自定义插件registry 中的 IDE ID。
例 5.5. 覆盖 IDE 的一个或多个定义属性的默认值
- 1
id:,registryUrl:, 或reference:.
第 6 章 在工作区中使用凭证和配置 复制链接链接已复制到粘贴板!
您可以在工作区中使用凭证和配置。
要做到这一点,将凭证和配置挂载到您的机构 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器中:
如果您需要允许集群中的 Dev Workspace Pod 访问需要身份验证的容器 registry,请为 Dev Workspace Pod 创建镜像 pull Secret。
挂载过程使用标准 Kubernetes 挂载机制,需要将额外的标签和注解应用到现有资源。在启动新的工作区或重启现有工作区时,会挂载资源。
您可以为各种组件创建永久挂载点:
-
Maven 配置,如 特定于用户的
settings.xml文件 - SSH 密钥对
- Git-provider 访问令牌
- Git 配置
- AWS 授权令牌
- 配置文件
- 持久性存储
6.1. 挂载 Secret 复制链接链接已复制到粘贴板!
要将机密数据挂载到工作区中,请使用 Kubernetes Secret。
使用 Kubernetes Secret,您可以挂载用户名、密码、SSH 密钥对、身份验证令牌(如 AWS)和敏感配置。
将 Kubernetes Secret 挂载到您组织的 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器。
先决条件
-
对目标 OpenShift 集群具有管理权限的活动
oc会话。请参阅 CLI 入门。 -
在用户项目中,您创建新的 Secret,或确定要挂载到所有
Dev Workspace容器的现有 Secret。
流程
将 Secret 挂载所需的标签添加到 Secret 中。
oc label secret <Secret_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-secret=true$ oc label secret <Secret_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-secret=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:使用注解来配置如何挂载 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 挂载为文件
当您启动一个工作区时,/home/user/.m2/settings.xml 文件将在 Dev Workspace 容器中提供。
使用 Maven,您可以为 settings.xml 文件设置自定义路径。例如:
mvn --settings /home/user/.m2/settings.xml clean install
$ mvn --settings /home/user/.m2/settings.xml clean install
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 入门。
流程
在用户项目中,使用私有容器 registry 详情和凭证创建一个镜像 pull Secret:
oc create secret docker-registry <Secret_name> \ --docker-server=<registry_server> \ --docker-username=<username> \ --docker-password=<password> \ --docker-email=<email_address>$ oc create secret docker-registry <Secret_name> \ --docker-server=<registry_server> \ --docker-username=<username> \ --docker-password=<password> \ --docker-email=<email_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在镜像拉取 Secret 中添加以下标签:
oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=true
$ oc label secret <Secret_name> controller.devfile.io/devworkspace_pullsecret=true controller.devfile.io/watch-secret=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.1.2. 从 .dockercfg 文件创建镜像拉取 Secret 复制链接链接已复制到粘贴板!
如果您已将私有容器 registry 的凭证存储在 .dockercfg 文件中,您可以使用该文件来创建镜像 pull Secret。
流程
将
.dockercfg文件编码到 Base64 :cat .dockercfg | base64 | tr -d '\n'
$ cat .dockercfg | base64 | tr -d '\n'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在用户项目中创建新的 OpenShift Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.1.1.3. 从 config.json 文件创建镜像 pull Secret 复制链接链接已复制到粘贴板!
如果您已将私有容器 registry 的凭证存储在 $HOME/.docker/config.json 文件中,您可以使用该文件来创建镜像 pull Secret。
流程
将
$HOME/.docker/config.json文件编码为 Base64。cat config.json | base64 | tr -d '\n'
$ cat config.json | base64 | tr -d '\n'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在用户项目中创建新的 OpenShift Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 Secret:
oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_the_previous_step> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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>
流程
在 Git 提供程序的网站上生成您的访问令牌。
重要个人访问令牌是敏感信息,应保留机密。将它们视为密码。如果您在身份验证时遇到问题,请确保使用正确的令牌并具有适当的克隆存储库权限:
- 在您的计算机上本地打开终端
-
使用
git命令,使用您的个人访问令牌克隆存储库。git命令的格式因 Git 提供程序而异。例如,可以使用以下命令进行 GitHub 个人访问令牌验证:
git clone https://<PAT>@github.com/username/repo.git
git clone https://<PAT>@github.com/username/repo.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<PAT> 替换为您的个人访问令牌,并将username/repo替换为适当的存储库路径。如果令牌有效并且具有必要的权限,克隆过程应该可以成功。否则,这代表了不正确的个人访问令牌、权限不足或其他问题。重要对于 GitHub Enterprise Cloud,请验证 令牌是否在机构 中使用。
-
进入 web
浏览器中的 https:// <openshift_dev_spaces_fqdn> /api/user/id来获取您的 OpenShift Dev Spaces 用户 ID。 准备新的 OpenShift Secret。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
访问
https://<openshift_dev_spaces_fqdn> /api/kubernetes/namespace来获取您的 OpenShift Dev Spaces 用户命名空间,名为。 切换到集群中的 OpenShift Dev Spaces 用户命名空间。
提示在 OpenShift 中:
oc命令行工具可返回您当前位于集群中的命名空间,您可以使用该命名空间检查当前的命名空间:$ oc project如果需要,您可以在命令行中切换到 OpenShift Dev Spaces 用户命名空间:
$ oc project & lt;your_user_namespace>
应用 Secret。
提示在 OpenShift 中,您可以使用
oc命令行工具:oc apply -f - <<EOF <Secret_prepared_in_step_5> EOF
$ oc apply -f - <<EOF <Secret_prepared_in_step_5> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
如果使用 Azure DevOps 服务器,还必须使用以下部分修改 工作区的 gitconfig :
[http]
extraheader = "Authorization: Basic <base64-encoded(:personal-access-token)>"
[http]
extraheader = "Authorization: Basic <base64-encoded(:personal-access-token)>"
要生成键值对,请使用以下命令:
echo -n "extraheader = \"Authorization: Basic "$(printf ":%s" <personal access token> | base64)\"
echo -n "extraheader = \"Authorization: Basic "$(printf ":%s" <personal access token> | base64)\"
如需更多信息 ,请参阅文档页面。
远程 git 操作需要 extraheader 配置,例如 git clone Server。此授权方法的优先级高于 git 凭证存储,因此对其他 Git 供应商的远程操作将失败。
验证
- 使用 Git 提供程序主机的远程 Git 存储库的 URL,启动新的工作区。
- 进行一些更改,并从工作区推送到远程 Git 存储库。
6.2. 挂载 ConfigMap 复制链接链接已复制到粘贴板!
要将非机密配置数据挂载到工作区中,请使用 Kubernetes ConfigMap。
使用 Kubernetes ConfigMap,您可以挂载非敏感数据,如应用程序的配置值。
将 Kubernetes ConfigMap 挂载到您组织的 OpenShift Dev Spaces 实例的 OpenShift 集群中的 Dev Workspace 容器。
先决条件
-
对目标 OpenShift 集群具有管理权限的活动
oc会话。请参阅 CLI 入门。 -
在用户项目中,您创建新的 ConfigMap 或确定要挂载到所有
Dev Workspace容器的现有 ConfigMap。
流程
将 ConfigMap 挂载所需的标签添加到 ConfigMap 中。
oc label configmap <ConfigMap_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-configmap=true$ oc label configmap <ConfigMap_name> \ controller.devfile.io/mount-to-devworkspace=true \ controller.devfile.io/watch-configmap=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:使用注解来配置如何挂载 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 作为环境变量挂载
当您启动一个工作区时,< ;env_var_1> 和 < env_var_ 2> 环境变量将在 Dev Workspace 容器中提供。
6.2.1. 挂载 Git 配置 复制链接链接已复制到粘贴板!
user.name 和 user.email 字段会自动设置为 git 供应商中的 gitconfig 内容,连接到 Git-provider 访问令牌 或通过 OAuth 生成的令牌,如果供应商的用户配置集页面中设置了用户名和电子邮件。
按照下面的说明在工作区中挂载 Git 配置文件。
先决条件
- 已登陆到集群。
流程
准备新的 OpenShift ConfigMap。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 ConfigMap。
oc apply -f - <<EOF <ConfigMap_prepared_in_step_1> EOF
$ oc apply -f - <<EOF <ConfigMap_prepared_in_step_1> EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
- 使用 Git 提供程序主机的远程 Git 存储库的 URL,启动新的工作区。
-
启动工作区后,在
tools容器中运行一个新的终端,并运行git config --get-regexp user ""。您的 Git 用户名和电子邮件应当会显示在输出中。
6.3. 在受限环境中启用工件存储库 复制链接链接已复制到粘贴板!
通过配置技术堆栈,您可以使用自签名证书从内部存储库中处理工件:
6.3.1. Maven 复制链接链接已复制到粘贴板!
您可以在受限环境中运行的 Maven 工作区中启用 Maven 工件存储库。
先决条件
- 您没有运行任何 Maven 工作区。
-
您知道您的用户命名空间,即 <
username>-devspaces,其中 <username> 是您的 OpenShift Dev Spaces 用户名。
流程
在 &
lt;username>-devspaces命名空间中,为 TLS 证书应用 Secret:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 带有禁用行嵌套的 Base64 编码。
在 &
lt;username>-devspaces命名空间中,应用 ConfigMap 来创建settings.xml文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
可选:在使用基于 JBoss EAP 的 devfile 时,在 <
username>-devspaces命名空间中应用第二个settings-xmlConfigMap,并使用相同的内容、不同的名称和/home/jboss/.m2挂载路径。 在 &
lt;username>-devspaces命名空间中,为 TrustStore 初始化脚本应用 ConfigMap:Java 8
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Java 11
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 启动 Maven 工作区。
-
在
tools容器中打开一个新的终端。 -
运行
~/init-truststore.sh。
6.3.2. gradle 复制链接链接已复制到粘贴板!
您可以在受限环境中运行的 Gradle 工作区中启用 Gradle 工件存储库。
先决条件
- 您没有运行任何 Gradle 工作区。
流程
为 TLS 证书应用 Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 带有禁用行嵌套的 Base64 编码。
为 TrustStore 初始化脚本应用 ConfigMap:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为 Gradle 初始化脚本应用 ConfigMap:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 启动一个 Gradle 工作区。
-
在
tools容器中打开一个新的终端。 -
运行
~/init-truststore.sh。
6.3.3. npm 复制链接链接已复制到粘贴板!
您可以在受限环境中运行的 npm 工作区中启用 npm 工件存储库。
先决条件
- 您没有运行任何 npm 工作区。
应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。
如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。
流程
为 TLS 证书应用 Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 带有禁用行嵌套的 Base64 编码。
应用 ConfigMap 在
工具容器中设置以下环境变量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.3.1. 禁用自签名证书验证 复制链接链接已复制到粘贴板!
运行以下命令禁用 SSL/TLS,绕过自签名证书验证。请注意,这是一个潜在的安全风险。为获得更好的解决方案,请使用 NODE_EXTRA_CA_CERTS 配置您信任的自签名证书。
流程
在终端中运行以下命令:
npm config set strict-ssl false
npm config set strict-ssl falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.3.2. 配置 NODE_EXTRA_CA_CERTS 以使用证书 复制链接链接已复制到粘贴板!
使用以下命令,将 NODE_EXTRA_CA_CERTS 设置为指向您具有 SSL/TLS 证书的位置。
流程
在终端中运行以下命令:
`export NODE_EXTRA_CA_CERTS=/public-certs/nexus.cer` `npm install`
`export NODE_EXTRA_CA_CERTS=/public-certs/nexus.cer`1 `npm install`Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/public-certs/HEKETI.cer是 Nexus 工件ory 自签名 SSL/TLS 证书的路径。
6.3.4. Python 复制链接链接已复制到粘贴板!
您可以在受限环境中运行的 Python 工作区中启用 Python 工件存储库。
先决条件
- 您没有运行任何 Python 工作区。
应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。
如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。
流程
为 TLS 证书应用 Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 带有禁用行嵌套的 Base64 编码。
应用 ConfigMap 在
工具容器中设置以下环境变量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.5. Go 复制链接链接已复制到粘贴板!
您可以在受限环境中运行的 Go 工作区中启用 Go 工件存储库。
先决条件
- 您没有运行 Go 工作区。
应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。
如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。
流程
为 TLS 证书应用 Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 带有禁用行嵌套的 Base64 编码。
应用 ConfigMap 在
工具容器中设置以下环境变量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.6. NuGet 复制链接链接已复制到粘贴板!
您可以在受限环境中运行的 NuGet 工作区中启用 NuGet 工件存储库。
先决条件
- 您没有运行任何 NuGet 工作区。
应用设置环境变量的 ConfigMap 可能会导致工作区引导循环。
如果您遇到此行为,请删除 ConfigMap 并直接编辑 devfile。
流程
为 TLS 证书应用 Secret:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 带有禁用行嵌套的 Base64 编码。
应用 ConfigMap 为
工具容器中的 TLS 证书文件的路径设置环境变量:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 应用 ConfigMap 以创建
nuget.config文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 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。
先决条件
- 您尚未启动工作区。
流程
在 devfile 中添加
卷组件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 devfile 中为相关
容器添加volumeMount:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
例 7.1. 为容器置备 PV 的 devfile
当使用以下 devfile 启动工作区时,缓存 PV 会置备到 ./cache 容器路径中的 golang 容器:
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容器。
流程
将
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=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 可选:使用注解来配置如何挂载 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
第 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:// <openshift_dev_spaces_fqdn> /api/kubernetes/namespace来获取您的 OpenShift Dev Spaces 用户命名空间,名为。您位于集群的 OpenShift Dev Spaces 用户命名空间中。
提示在 OpenShift 中,您可以使用命令行
oc工具来显示当前命名空间或切换到命名空间。
流程
要列出您的工作区,请在命令行中输入以下内容:
oc get devworkspaces
$ oc get devworkspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例 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
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 CrashLoopBackOffCopy to Clipboard Copied! Toggle word wrap Toggle overflow
您可以通过在此命令中添加-- watch 标志来查看实时的 PHASE 更改。
具有管理权限的用户可以通过包含- all-namespaces 标志来列出所有 OpenShift Dev Spaces 用户的所有工作区。
8.1.2. 创建工作区 复制链接链接已复制到粘贴板!
如果您的用例不允许使用 OpenShift Dev Spaces 仪表板,您可以通过将自定义资源应用到集群来使用 OpenShift API 创建工作区。
与使用命令行相比,通过 OpenShift Dev Spaces 仪表板创建工作区提供了更好的用户体验和配置优势:
- 作为用户,您会自动登录到集群。
- OpenShift 客户端会自动工作。
-
OpenShift Dev Spaces 及其组件会自动将目标 Git 存储库的 devfile 转换为集群中的
DevWorkspace和DevWorkspaceTemplate自定义资源。 -
默认情况下,使用工作区的
DevWorkspace中的routingClass: che对工作区的访问会被保护。 -
DevWorkspaceOperatorConfig配置的认可由 OpenShift Dev Spaces 管理。 在
CheCluster自定义资源中指定的spec.devEnvironments中识别配置,包括:-
持久存储策略通过
devEnvironments.storage指定。 -
默认 IDE 使用
devEnvironments.defaultEditor指定。 -
默认插件通过
devEnvironments.defaultPlugins指定。 -
容器构建配置通过
devEnvironments.containerBuildConfiguration指定。
-
持久存储策略通过
先决条件
-
具有在集群中的项目中创建
DevWorkspace资源的活跃的oc会话。请参阅 CLI 入门。 您知道集群中的相关的 OpenShift Dev Spaces 用户命名空间。
提示您可以访问
https:// <openshift_dev_spaces_fqdn> /api/kubernetes/namespace来获取您的 OpenShift Dev Spaces 用户命名空间,名为。您位于集群的 OpenShift Dev Spaces 用户命名空间中。
提示在 OpenShift 中,您可以使用命令行
oc工具来显示当前命名空间或切换到命名空间。注意打算为其他用户创建工作区的 OpenShift Dev Spaces 管理员必须在 OpenShift Dev Spaces 或管理员置备的用户命名空间中创建
DevWorkspace自定义资源。请参阅 https://access.redhat.com/documentation/zh-cn/red_hat_openshift_dev_spaces/3.22/html-single/administration_guide/index#administration-guide:configuring-namespace-provisioning。
流程
要准备
DevWorkspace自定义资源,请复制目标 Git 存储库的 devfile 的内容。例 8.2. 使用
schemaVersion: 2.2.0复制 devfile 内容components: - name: tooling-container container: image: quay.io/devfile/universal-developer-image:ubi8-latestcomponents: - name: tooling-container container: image: quay.io/devfile/universal-developer-image:ubi8-latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 提示如需了解更多详细信息,请参阅 devfile v2 文档。
创建
DevWorkspace自定义资源,粘贴spec.template字段下上一步中的 devfile 内容。-
将
DevWorkspace自定义资源应用到集群。
验证
通过检查
DevWorkspace的 PHASE 状态来验证工作区是否已启动。oc get devworkspaces -n <user_project> --watch
$ oc get devworkspaces -n <user_project> --watchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例 8.4. 输出
NAMESPACE NAME DEVWORKSPACE ID PHASE INFO user1-dev my-devworkspace workspacedf64e4a492cd4701 Starting Waiting for workspace deployment
NAMESPACE NAME DEVWORKSPACE ID PHASE INFO user1-dev my-devworkspace workspacedf64e4a492cd4701 Starting Waiting for workspace deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 当工作区成功启动时,在
oc get devworkspaces命令的输出中,其 PHASE 状态将变为 Running。例 8.5. 输出
NAMESPACE NAME DEVWORKSPACE ID PHASE INFO user1-dev my-devworkspace workspacedf64e4a492cd4701 Running https://url-to-workspace.com
NAMESPACE NAME DEVWORKSPACE ID PHASE INFO user1-dev my-devworkspace workspacedf64e4a492cd4701 Running https://url-to-workspace.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 然后,您可以使用以下选项之一打开工作区:
-
访问
oc get devworkspaces命令的输出的 INFO 部分中提供的 URL。 - 从 OpenShift Dev Spaces 仪表板打开工作区。
-
访问
8.1.3. 停止工作区 复制链接链接已复制到粘贴板!
您可以通过将 Devworkspace 自定义资源中的 spec.started 字段设置为 false 来停止工作区。
先决条件
-
集群中的活跃
oc会话。请参阅 CLI 入门。 您知道工作区名称。
提示您可以在
$ oc get devworkspaces的输出结果中找到相关的工作区名称。您知道集群中的相关的 OpenShift Dev Spaces 用户命名空间。
提示您可以访问
https:// <openshift_dev_spaces_fqdn> /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>$ 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 Copied! Toggle word wrap Toggle overflow
8.1.4. 启动停止的工作区 复制链接链接已复制到粘贴板!
您可以通过将 Devworkspace 自定义资源中的 spec.started 字段设置为 true 来启动已停止的工作空间。
先决条件
-
集群中的活跃
oc会话。请参阅 CLI 入门。 您知道工作区名称。
提示您可以在
$ oc get devworkspaces的输出结果中找到相关的工作区名称。您知道集群中的相关的 OpenShift Dev Spaces 用户命名空间。
提示您可以访问
https:// <openshift_dev_spaces_fqdn> /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>$ 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 Copied! Toggle word wrap Toggle overflow
8.1.5. 删除工作区 复制链接链接已复制到粘贴板!
您可以通过只删除 DevWorkspace 自定义资源来删除工作区。
如果 OpenShift Dev Spaces 创建它们,则删除 DevWorkspace 自定义资源也会删除其他工作区资源:例如,引用的 DevWorkspaceTemplate 和 per-workspace PersistentVolumeClaims。
尽可能使用 OpenShift Dev Spaces 仪表板来删除工作区。
先决条件
-
集群中的活跃
oc会话。请参阅 CLI 入门。 您知道工作区名称。
提示您可以在
$ oc get devworkspaces的输出结果中找到相关的工作区名称。您知道集群中的相关的 OpenShift Dev Spaces 用户命名空间。
提示您可以访问
https:// <openshift_dev_spaces_fqdn> /api/kubernetes/namespace来获取您的 OpenShift Dev Spaces 用户命名空间,名为。您位于集群的 OpenShift Dev Spaces 用户命名空间中。
提示在 OpenShift 中,您可以使用命令行
oc工具来显示当前命名空间或切换到命名空间。
流程
运行以下命令以删除工作区:
oc delete devworkspace <workspace_name> -n <user_namespace>
$ oc delete devworkspace <workspace_name> -n <user_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2. 自动 OpenShift 令牌注入 复制链接链接已复制到粘贴板!
本节论述了如何使用自动注入工作区容器的 OpenShift 用户令牌,允许针对 OpenShift 集群运行 OpenShift Dev Spaces CLI 命令。
流程
- 打开 OpenShift Dev Spaces 仪表板并启动工作区。
- 启动工作区后,在包含 OpenShift Dev Spaces CLI 的容器中打开一个终端。
执行 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 工作区 < ;workspace_name> 正在运行。
- 您的 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>'
$ oc logs --follow --namespace='<workspace_namespace>' \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.1.2. OpenShift 控制台中的工作区日志 复制链接链接已复制到粘贴板!
您可以使用 OpenShift 控制台观察 OpenShift Dev Spaces 工作区日志。
流程
- 在 OpenShift Dev Spaces 仪表板中,进入 Workspaces。
- 单击工作区名称,以显示工作区概览页面。此页面显示 OpenShift 项目名称 < project_name >。
- 单击右上角的 Applications 菜单,然后单击 OpenShift 控制台链接。
- 在 OpenShift 控制台中,在 Administrator 视角中运行后续步骤。
- 点 Workloads & gt; Pods 查看所有活跃工作区的列表。
- 在 Project 下拉菜单中,选择 < project_name> 项目来缩小搜索范围。
- 单击运行工作区的正在运行的 Pod 的名称。Details 选项卡包含所有容器的列表,其中含有其他信息。
- 转至 Logs 选项卡。
9.1.3. 编辑器中的语言服务器和调试适配器日志 复制链接链接已复制到粘贴板!
在 Microsoft Visual Studio Code - 在工作区中运行的开源编辑器,您可以配置安装的语言服务器和调试适配器扩展来查看其日志。
流程
-
配置扩展:点 File > Preferences > Settings,展开 Extensions 部分,搜索扩展名,并将
trace.server或类似配置设置为verbose(如果此类配置存在)。如需进一步配置,请参阅扩展文档。 - 点 View → Output,在 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正确:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 提供足够的内存
插件会消耗 CPU 和内存资源。例如,当插件提供 IntelliSense 功能时,收集数据可以使用分配给容器的所有内存。
为容器提供更多内存可提高性能。确保 devfile 定义
devfile.yaml文件中的内存设置正确。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3. 网络问题故障排除 复制链接链接已复制到粘贴板!
本节论述了如何防止或解决与网络策略相关的问题。OpenShift Dev Spaces 需要 WebSocket Secure (WSS)连接可用。安全 WebSocket 连接提高了机密性和可靠性,因为它们降低了代理干扰的风险。
先决条件
- 网络上必须有端口 443 上的 WebSocket Secure (WSS)连接。防火墙和代理可能需要额外的配置。
流程
- 验证浏览器支持 WebSocket 协议。请参阅: 搜索 websocket 测试。
- 验证防火墙设置:必须在端口 443 上使用 WebSocket 安全(WSS)连接。
- 验证代理服务器设置:代理传输和截获端口 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
| 浏览器 |
|---|
| 临时解决方案 |
| Google Chrome |
| 进入 Settings → Privacy and security → Cookies 和其他站点数据 → Allow all cookies。 |
| Mozilla Firefox |
| Private Browsing 模式不支持 Web 视图。详情请查看 这个报告的错误。 |