OpenShift Origin 容器化部署与 Sample App 环境准备指南-平芜编程栈

测试
云原生
质量保障

【免费下载链接】origin

Conformance test suite for OpenShift

项目地址：https://gitcode.com/gh_mirrors/or/origin

本文基于 origin 仓库中的 container-setup.md 展开，介绍如何以 Docker 容器方式拉起一个自带全部软件包的 OpenShift Origin 实例，完成宿主机 Docker 守护进程适配、客户端证书信任、私有镜像仓库部署等前置配置，最终衔接 sample-app 示例的完整构建、部署与更新流程。读完本文，你将掌握“容器即集群”的单机部署要点、/var/lib/openshift数据持久化方案，以及 sample app 从模板到 STI 构建的端到端准备工作。

一、文档定位与适用前提

examples/sample-app/目录是 OpenShift 3 时代的应用生命周期示例，包含一组配置文件和脚本，用于演示如何创建新应用并执行应用构建。该目录核心资产包括：

application-template-stibuild.json：STI（Source-to-Image）构建模板，也是 container-setup 文档中唯一需要拉取到容器内的应用代码文件；
application-template-dockerbuild.json、application-template-pullspecbuild.json：Dockerfile 构建与 PullSpec 构建的同类模板；
cleanup.sh：一键清理脚本；
README.md：完整的应用构建、部署、更新流程说明，container-setup 文档中的“Setup”“Application Build, Deploy, and Update Flow”步骤均指向其对应章节。

container-setup.md 的定位是：当你使用预构建的openshift/originDocker 容器（而非本地make build出的openshift二进制）时，需要在执行 README 主流程之前额外完成的容器专属准备步骤。sample-app 的 README 开头也明确提示：

if you are using the openshift/origin container, please make sure you follow these instructions first

需要注意的适用前提：当前 origin 仓库自 2020 年 7 月起，main分支的维护范围已收敛为openshift-tests测试二进制（见根目录 README.md），不再产出hyperkube。因此本文所述容器化部署属于该示例的历史性单机演示路径，其中的 Docker 版本要求（1.3.2 以上支持--insecure-registry）与命令形态均以仓库文档原文为准，用于理解原理与复现旧版演示环境时尤其适用。

二、下载并运行 OpenShift Origin 容器

2.1 基础启动命令

container-setup 文档给出的最小启动命令为：

$ docker run -d --name "openshift-origin" --net=host --privileged \ -v /var/run/docker.sock:/var/run/docker.sock \ openshift/origin start

各参数在 Origin 单机场景下的作用：

参数	作用说明
`--net=host`	容器直接使用宿主网络栈。Origin 的 router、Service 端口映射等都需要在宿主网络平面可见，sample-app README 中后续`--insecure-registry 172.30.0.0/16`也依赖服务子网在宿主机上可达
`--privileged`	以特权模式运行。Origin 的构建操作（STI 构建 Pod）和 registry 服务会启动特权容器，并直接调用宿主 Docker daemon 执行`docker build`/`docker push`
`-v /var/run/docker.sock:/var/run/docker.sock`	把宿主 Docker socket 挂载进容器，使容器内的 Kubernetes/OpenShift 控制面能够驱动宿主 Docker 引擎创建容器。这也是 sample-app README “Security Warning” 章节强调的安全风险来源：任意镜像的`docker run`操作等效于在宿主获得 root 能力
`openshift/origin start`	镜像入口以`start`子命令启动 all-in-one 的 Origin 服务

2.2 数据持久化

文档明确指出：上述基础命令“won't hold any data after a restart”（重启后不保留任何数据）。原因是 Origin 的所有状态数据都落在容器内的/var/lib/openshift目录下（etcd 数据、openshift.local.config证书目录、openshift.local.volumes存储卷等）。要保留数据，需要在 Docker 宿主机上创建/var/lib/openshift目录并挂载进去：

$ docker run -d --name "openshift-origin" --net=host --privileged \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /var/lib/openshift:/var/lib/openshift \ openshift/origin start

从文档与 cleanup.sh 的内容可以推断出该目录的实际结构：cleanup 脚本会卸载openshift.local.volumes挂载点并删除openshift.local.*目录，而 container-setup 后文的CURL_CA_BUNDLE步骤又引用了openshift.local.config/master/ca.crt——即openshift.local.config（master/admin 证书与 kubeconfig）和openshift.local.volumes（节点存储）正是/var/lib/openshift下的核心数据面。

三、准备 Docker 宿主机

3.1 预拉取示例应用所需镜像

文档要求在你的Docker 宿主机（注意不是容器内部）上运行pullimages.sh脚本拉取 sample app 运行所需的若干容器镜像：

$ sh <(curl \ https://raw.githubusercontent.com/openshift/origin/main/examples/sample-app/pullimages.sh)

一个需要如实说明的事实边界：经在当前仓库中检索，examples/sample-app/目录下并不存在pullimages.sh文件（目录实际包含 OWNERS、README 与三个应用模板 JSON 等文件）。这表明文档编写时所引用的脚本后来已从仓库移除，属于文档的历史残留引用。结合 application-template-stibuild.json 的内容可以确认该脚本的目标镜像类别：模板中通过 ImageStream 引用的基础镜像registry.access.redhat.com/ubi8/ruby-27、以及构建产物推送的私有 registry 镜像等。在当前的仓库环境中，应自行根据模板中出现的镜像地址执行docker pull来完成等效的预拉取。

3.2 配置“不安全”容器镜像仓库

文档要求接下来遵循 sample-app README 中 “Setup” 章节关于 insecure registry 的说明。对应原文要求把--insecure-registry 172.30.0.0/16加入 Docker daemon 启动参数：

$ docker daemon --insecure-registry 172.30.0.0/16

其原理是：sample app 的私有镜像仓库运行在 OpenShift 内部（后文第 5.2 节oc adm registry部署的 registry，构建日志中可见其端点形如172.30.163.205:5000/test/origin-ruby-sample:latest），该地址落在服务子网172.30.0.0/16内且没有可被公共 CA 验证的证书。Docker daemon 默认只信任受验证的 registry，因此需要显式信任整个服务子网。原文补充两点约束：

该 flag 要求 Docker 1.3.2 或更高版本；
若通过systemd管理 Docker 服务，可将该参数写入/etc/sysconfig/docker的 options 值；
前提是未修改 kubernetes/openshift 服务子网的默认值172.30.0.0/16。

README 同时说明使用 Vagrant 镜像的用户可跳过此项。

3.3 关闭 firewalld

README 指出 OpenShift 的 firewalld 规则当时仍在演进中，最省事的做法是整体停用：

$ sudo systemctl stop firewalld

示例验证完毕后手动恢复：$ sudo systemctl start firewalld（重启系统也会自动拉起）。Vagrant 用户同样可跳过。

3.4 安全警告

sample-app README 的 “Security Warning” 章节值得完整继承：OpenShift 已不要求禁用 SELinux，但构建操作与 registry 服务确实会使用特权容器并访问宿主 Docker daemon 执行docker build/docker push。在宿主机上直接运行 OpenShift 节点时，应充分意识到运行任意镜像带来的等效 root 风险——这也是第二节中--privileged与 docker.sock 挂载的组合必须仅用于测试环境的根本原因。

四、连接 OpenShift 容器并配置客户端信任

容器启动后，需要进入容器执行管理命令：

$ docker exec -it openshift-origin bash

文档建议修改 bash 提示符以便区分你正处于容器内部：

$ PS1="openshift-dock: [\u@\h \W]\$ "

随后在容器内完成 sample app 所需的“代码位”拉取——把 STI 构建模板下载到容器内的/var/lib/openshift下：

$ cd /var/lib/openshift $ mkdir -p examples/sample-app $ wget \ https://raw.githubusercontent.com/openshift/origin/main/examples/sample-app/application-template-stibuild.json \ -O examples/sample-app/application-template-stibuild.json

之所以要专门下载该模板，是因为后续oc new-app直接以它为输入创建整套应用资源；在本仓库中可以直接查看 application-template-stibuild.json 了解其结构（见下文第 5.1 节）。

接着配置客户端证书信任（文档称为 Configure client security，对应 README 构建流程的第 3 步）：

$ export CURL_CA_BUNDLE=`pwd`/openshift.local.config/master/ca.crt

该变量让 curl 等客户端信任由 Origin 自签 CA（master 目录下的ca.crt）签发的 API 证书。README 中对应的 web console 步骤也说明了同样的背景：浏览器需要先接受https://<host>:8443的自签证书，console 才能正常调用 OpenShift API；生产环境使用合法证书则无此问题。

五、部署私有镜像仓库并衔接 Sample App 流程

5.1 模板内容：这一步之后你将构建什么

在oc adm registry之前，先明确整个 sample app 的构成。application-template-stibuild.json 是一个名为ruby-helloworld-sample的 Template，apiVersion为template.openshift.io/v1，声明参数包括MYSQL_USER、MYSQL_PASSWORD（生成）与MYSQL_DATABASE（默认 root）。其objects列表一次创建：

Secret dbsecret：保存mysql-user/mysql-password字符串数据；
Service frontend：ClusterIP 类型，5432 端口转发到容器 8080；
Route route-edge：host 为www.example.com，edge TLS 终结，指向 frontend 服务，并带expose-uri注解；
ImageStream origin-ruby-sample（构建产物流）与ImageStream ruby-27（基础镜像流，指向registry.access.redhat.com/ubi8/ruby-27）;
BuildConfig ruby-sample-build：Source 类型构建，携带 GitHub webhook 触发器（secretsecret101）、Generic 触发器与 ImageChange 触发器，带template.alpha.openshift.io/wait-for-ready: true注解。

5.2 部署私有容器镜像仓库

文档给出的命令只有两行：

$ oc adm registry $ cd examples/sample-app

oc adm registry在集群内部署私有镜像仓库。README 的构建流程第 8 步解释了它为什么必要：STI 构建完成后，产物镜像会以 ImageStream（origin-ruby-sample）命名推送到该私有仓库——构建日志示例显示推送目标形如172.30.163.205:5000/test/origin-ruby-sample:latest，这正是第三节必须配置 insecure registry 的直接原因。README 同时提醒：私有 registry 使用临时存储，registry 停止后镜像即丢失。

5.3 从第 5 步继续 Sample App 主流程

文档指示：完成上述容器专属准备后，即可继续 sample-app README 的 “Application Build, Deploy, and Update Flow” 从第 5 步开始执行。把 README 中第 1～4 步的摘要与容器场景对齐后，完整执行顺序为：

oc adm policy add-cluster-role-to-user cluster-admin test-admin --kubeconfig=openshift.local.config/master/admin.kubeconfig，然后oc login --certificate-authority=openshift.local.config/master/ca.crt -u test-admin（任意密码）；
oc new-project test --display-name="OpenShift 3 Sample" --description=...创建项目；
（可选）浏览器访问https://<host>:8443/console，接受自签证书后用test-admin登录，页面会随资源部署实时刷新；
（可选）Fork ruby 示例仓库（README 示例为 openshift/ruby-hello-world），便于演示“仓库变更触发构建”；
（可选）在 GitHub 仓库 settings 中配置 webhook，URL 形如https://<host>:8443/osapi/v1/namespaces/test/buildconfigs/ruby-sample-build/webhooks/secret101/github，需要“Disable SSL Verification”；
编辑模板中的 BuildConfigsourceURI指向自己的 fork；
oc new-app application-template-stibuild.json提交模板，生成 Secret、两个 Service、Route、两个 ImageStream、BuildConfig 与两个 DeploymentConfig，标签统一为app=ruby-helloworld-sample；
oc get builds/oc logs -f bc/ruby-sample-build跟踪构建，镜像推送到172.30.x.x:5000/test/origin-ruby-sample；
ImageChange 触发器自动触发部署，oc logs -f dc/frontend观察滚动部署（先扩缩至 1 做验收检查，再扩至 2），oc get pods确认 frontend 与 database Pod Running；
oc get services取 frontend 的 ClusterIP（示例为172.30.17.4，端口 5432），浏览器/curl 访问确认应用可用，或按 Vagrant 用户指引做 SSH 端口转发；
修改代码 push 后（无 webhook 时oc start-build ruby-sample-build）等待新构建完成并刷新页面验证更新。

在整个流程进行期间，文档给出的最后一个实用技巧是在Docker 宿主机上查看 Origin 容器日志：

$ docker attach openshift-origin

六、环境清理

演示结束后的清理由 cleanup.sh 完成（README “Cleaning Up” 章节），需要 root 权限：

$ sudo ./cleanup.sh

脚本依次执行四步，从源码可直接读出其清理面：

sudo pkill -x openshift停止 openshift all-in-one 进程；
通过docker ps过滤^k8s_前缀并逐个docker stop，停掉所有 Kubernetes 创建的容器；
从mount输出中提取openshift.local.volumes挂载点并umount（呼应第二节的持久化目录结构）；
sudo rm -rf openshift.local.*删除运行时生成的全部本地文件。

README 对此标注了明确警告：该脚本会杀掉所有k8s_前缀的容器，请谨慎使用。对于第二节采用宿主目录挂载的容器化部署，运行该脚本后还需自行停止/删除openshift-origin容器，并视需要清理宿主机的/var/lib/openshift目录。

七、小结

container-setup.md 的价值在于把“Origin 容器 = 一个自带控制面的黑盒”拆成了可审计的五步：特权启动与 socket 挂载、数据目录持久化、宿主 Docker 守护进程适配（insecure registry 与防火墙）、容器内客户端证书信任与模板落盘、私有 registry 部署，最后平滑交接给 sample-app README 的标准构建部署流程。文中的每一个命令都能在当前仓库中找到对应佐证——模板结构见 application-template-stibuild.json，数据目录与清理面见 cleanup.sh。需要注意的是该文档保留了 OpenShift 3 时代的命令形态，且其中引用的pullimages.sh已不在当前仓库中，实际复现时应以模板内声明的镜像地址自行拉取；理解这一历史脉络，正是把仓库中的示例资产当作架构教材来读的正确方式。