📚 课程目录第3章开发者自助服务入口

3. 开发者自助服务入口

OpenShift 为开发者提供的自助服务并不是单一入口，而是一组围绕同一套 Kubernetes 资源模型构建的访问通道。理解这些入口的差异，能帮助你在不同场景下选择最省力的工具：快速浏览与可视化操作用 Web 控制台，日常脚本化与自动化用 oc，从源码直接构建部署用 odo，在编辑器内闭环开发用 IDE 插件，而在受限网络或远程环境中则依赖终端访问方式。

Web 控制台与 Administrator / Developer 双视角

Administrator 视角面向集群运维，侧边栏按“计算、网络、存储、用户管理、集群配置”等维度组织，关注节点、MachineConfig、Operator、集群级别的配额与策略。它回答的是“集群整体是否健康、资源如何分配”。

Developer 视角面向应用交付，侧边栏围绕“开发者目录、拓扑、构建、流水线、可观测性”组织。它回答的是“我的应用由哪些工作负载组成、它们之间如何连接、构建和部署是否成功”。

Developer 视角中最核心的页面是 Topology（拓扑）。它把 Deployment、Pod、Service、Route、BuildConfig 等对象以图形方式聚合为一个应用节点，节点之间的连线表示流量或依赖关系。当构建失败时，节点上会出现红色标记，点击即可进入构建日志；当 Pod 未就绪时，节点会显示黄色状态。这种“以应用为中心”的聚合视图，是 Developer 视角区别于 Administrator 视角的关键价值。

Developer 视角还提供 +Add 入口，支持从 Git 仓库、容器镜像、开发者目录（Developer Catalog）、YAML 导入等多种方式创建应用。其中“从 Git 导入”会自动探测仓库中的 Dockerfile、S2I 模板或构建包，生成对应的 BuildConfig 与 Deployment，这是自助服务最典型的体现：开发者无需等待运维介入即可完成一次从源码到运行实例的交付。

CLI 工具 oc：与集群对话的主通道

oc 是 OpenShift 的官方命令行客户端，它在 kubectl 的基础上扩展了大量 OpenShift 专有资源与便捷子命令。安装后首先需要登录：

# 使用令牌登录，令牌可在 Web 控制台右上角用户名 -> Copy login command 获取
oc login https://api.crc.testing:6443 --token=sha256~xxxxxxxx

# 查看当前身份与项目
oc whoami
oc project

# 创建并切换到新项目
oc new-project dev-selfservice

日常开发中，oc 的高频用法集中在几类：查看资源（oc get pods -o wide）、查看详情与事件（oc describe pod <name>）、查看日志（oc logs -f <pod>）、进入容器（oc rsh <pod>）、端口转发（oc port-forward <pod> 8080:8080）。此外，oc new-app 可以从源码或镜像一键创建应用，oc start-build 可以手动触发构建，oc rollout status 可以等待部署完成。

一个值得注意的细节是：oc 的很多子命令支持 -o yaml 或 -o json，这使得开发者可以把控制台中的操作“翻译”为可复现的命令。例如在 Web 控制台点击创建应用后，可以通过 oc get deployment <name> -o yaml 导出实际生成的资源定义，再纳入 Git 管理。

CLI 工具 odo：面向源码的开发者工作流

odo（OpenShift Do）是专为开发者设计的简化 CLI，它的设计目标是让开发者不必先理解 Deployment、Service、Route 等概念，就能把本地代码推送到集群运行。odo 的核心抽象是“组件（Component）”，一个组件对应一份源码和一个运行形态。

# 在源码目录中初始化组件，交互式选择语言与运行环境
odo create nodejs

# 推送本地代码，自动触发构建并部署
odo push

# 查看组件状态与访问地址
odo list
odo url list

odo 与 oc 的关系可以这样理解：odo 负责“从源码到可访问服务”的快速路径，oc 负责“对集群资源做任意精细操作”。当 odo push 完成后，底层仍然生成了标准的 Deployment、Service、Route 等资源，可以用 oc get all 查看。因此 odo 不是替代 oc，而是降低了入门门槛。

IDE 插件与终端访问方式

OpenShift 提供 VS Code 与 JetBrains 系列（IntelliJ IDEA、WebStorm 等）的官方插件。以 VS Code 为例，安装 OpenShift 插件后，可以在活动栏看到 OpenShift 视图，登录集群后直接浏览项目、应用、Pod，右键即可执行“打开终端”“查看日志”“端口转发”等操作。插件还支持在编辑器内直接对当前工作区执行 odo 或 oc 命令，减少在编辑器和终端之间切换的成本。

终端访问方式主要有三类。第一类是本地终端，安装 oc 后直接使用，适合日常开发。第二类是 Web 终端，在 Web 控制台 Pod 详情页点击“Terminal”标签即可打开容器内的交互式 shell，适合快速排查而不必配置本地环境。第三类是 oc rsh 与 oc debug，前者进入运行中的容器，后者会创建一个带调试工具的 Pod 副本，适合容器镜像中缺少 shell 或调试工具的场景。

选择入口的经验法则：需要可视化理解应用结构时用 Developer 视角的 Topology；需要可复现、可脚本化的操作时用 oc；从零开始把本地代码跑起来时用 odo；长时间编码时用 IDE 插件；临时排查且不想配置本地环境时用 Web 终端。

把上述入口放在一起看，它们共享同一套底层资源模型：无论从 Web 控制台点击创建、用 oc new-app 创建，还是用 odo push 推送，最终都会在项目中生成 Deployment、Service、Route、BuildConfig 等标准对象。这意味着开发者可以在一个入口中开始，在另一个入口中继续。例如用 odo 快速跑通一个 Node.js 应用后，用 oc get route 获取访问地址，再回到 Developer 视角的 Topology 中观察 Pod 状态与日志。理解这种“多入口、同模型”的关系，是掌握 OpenShift 自助服务的关键。