本节书摘来自华章出版社《开源容器云openshift：构建基于kubernetes的企业应用云平台》一书中的第2章，第2.3节，作者 陈耿 ，更多章节内容可以访问云栖社区“华章计算机”公众号查看
在部署更复杂的应用之前，有一项重要的任务需要完成，那就是完善openshift集群。在上一章中，通过二进制的安装包，我们快速完成了openshift集群的安装，但是这个集群还只是一个“空”的集群。面对复杂的应用，openshift需要更多组件的支持。而这些组件并没有在上一章的安装中完成。同时，openshift作为一个容器云平台，默认提供了一系列用户开箱即用、一键部署的应用和服务，这些应用和服务的信息也需要在系统中注册，以便用户在类似软件市场（app store）的服务目录中选用。现在让我们一起完善这个openshift实例。
在上一章中，我们使用openshf?it的web控制台部署了第一个容器应用。openshift的web控制台的用户体验非常好，通过图形界面，用户可以高效快速地完成操作。除了web控制台外，openshift还提供了一系列命令行工具。
oc是openshift中一个重要的命令行客户端。openshift web控制台能完成的事情，通过oc命令也能完成。在进行自动化及重复性的操作时，命令行工具比图形界面更加高效。为了方便读者进行实验操作，本书后续的示例将以命令行进行操作。
可以尝试执行oc version命令查看openshift的集群版本信息，测试oc命令是否正常工作。
可以看到命令输出了openshift及其使用的kubernetes的版本信息。
因为oc命令是带有权限管控的，所以在使用oc命令进行实际的操作前，需要先通过oc login命令登录。如下例所示，通过oc login命令，以dev用户的身份登录。
通过oc new-project命令创建一个新项目hello-world-oc。
前文我们通过web控制台部署了hello-openshift镜像。在命令行可以通过oc new-app命令方便地部署dockerhub等docker镜像仓库的镜像。
执行oc get pod命令可以查看当前项目的容器的列表。和在kubernetes一样，在open-
shift中，所有的docker容器都是被“包裹”在一种称为pod的容器内部。用户可以近似地认为pod就是我们要运行的docker容器本身。
openshift-1-8gv1i的详细信息，包含容器的名称、状态、所处的命名空间（项目）、标签、ip地址等。
在后续的介绍中，我们会使用oc命令进行大量的操作，相信你很快就会熟悉它的使用方法。
在安装组件之前，我们需要以集群管理员的角色登录。在openshift中，默认的集群管理员是system:admin。system:admin这个用户拥有最高的权限。有意思的是，和其他用户不同，system:admin用户并没有密码！system:admin的登录依赖于证书密钥。以下是登录的方法。
1）拷贝登录配置文件。如果提示文件已存在，请选择覆盖。
2）通过oc login命令登录。
3）执行ocwhoami命令，即可见当前登录用户为system:admin。
可以尝试执行oc get node命令查看集群节点信息。只有集群管理员才有权限查看集群的节点信息。
可以看到我们的机器中有且只有一个节点master.example.com，它的状态是就绪（ready）的。在实际的生产环境中，集群中将会有许多节点，这会是一个庞大的列表。
首先，为集群添加一个router组件。router是openshift集群中一个重要的组件，它是外界访问集群内容器应用的入口。集群外部的请求都会到达router，并由router分发到具体的容器中。关于router的详细信息我们会在后续的章节详细探讨。
切换到default项目。
router组件需要读取集群的信息，因此它关联一个系统账号service account，并为这个账号赋权。service account是openshift中专门供程序和组件使用的账号。openshift中有严格的权限和安全保障机制。不同的用户会关联到不同的安全上下文（security context constraint，scc）。同时，用户或组也会关联到不同的系统角色（role）。
执行oadm router命令创建router实例。
oadm命令是oc命令的好搭档。oc命令更多地是面向一般用户，而oadm命令是面向集群管理员，可以进行集群的管理和配置。在上面的命令中，我们指定创建一个名为router的router。
参数--replicas=1表明，我们只想创建一个实例。在实际的生产中，为了达到高可用的效果，可以创建多个router实例实现负载均衡并防止单点失效。
执行片刻之后，通过oc get pod -n default命令可以查看router容器的状态。
上面的输出显示router容器的状态是running。如果此时检查实验主机上的端口监听状态，可以发现主机的端口80、443正在被haproxy监听。
其实，从技术上来说，router就是一个运行在容器中的haproxy，当然这个haproxy经过了特别的配置来实现特殊的功能。这些我们在后面再详细讨论。
至此，router组件部署就已经完成了。
接下来部署集群内部的docker registry，即内部的docker镜像仓库。从功能上说，open-
shift内部的镜像仓库和外部的企业镜像仓库或者dockerhub没有本质的区别。只是这个内部的镜像仓库会用来存放一些“特殊的”镜像，这些镜像是由一个叫source to image（s2i）的流程产生的。简单地说，s2i的工作是辅助将应用的源代码转换成可以部署的docker镜像。关于s2i，后续再详细介绍。
1）切换到default项目。
2）执行如下命令部署registry。
3）稍候片刻，执行oc get pod便可见registry容器处于运行状态了。
4）重启docker服务，使修改的配置生效。
至此，registry组件部署完成。
image stream是一组镜像的集合。可以在一个image stream中定义一些名称及标签（tag），并定义这些名字及标签指向的具体镜像。值得指出的是，在openshift上部署容器应用，并不一定要用到image stream，直接指定镜像的地址也可以完成部署。使用image stream为的是方便地将一组相关联的镜像进行整合管理和使用。openshift origin默认为用户定义了一系列开箱即用的image stream。
1）切换到openshift项目。
2）通过以下命令可以导入image stream。
3）通过oc get is -n openshift命令，可以列出刚才导入的image stream对象。
此时，如果访问openshift的web控制台，进入hello world项目，单击项目overview页面顶部的add to project按钮，则会看见一系列可用的镜像被罗列在页面上，如图2-11所示。
部署容器应用，可以很简单：直接通过docker run或oc new-app命令即可完成。但是有时候它也可以是一项很复杂的任务。在现实中，企业的应用往往不是孤立存在的，应用往往有多个模块；部署需要满足外部的依赖；用户需要根据实际的需求，结合环境的配置给部署传递不同的参数。为了满足用户对复杂应用部署的需求，提高应用部署的效率，openshift引入了应用部署模板（template）的概念。通过template，用户可以定义一个或多个需要部署的镜像，定义部署依赖的对象，定义可供用户输入配置的参数项。openshift默认提供了一些示例的template供用户使用。后续用户可以根据实际的需求，定义满足企业需求的应用部署模板，构建企业内部的软件市场。
2）下载并创建一个cakephp示例应用的template。通过这个template，用户可以在服务目录单击相关的条目一键部署一个cakephp应用和一个mysql数据库。
3）创建完毕后，可以通过oc get template -n openshift命令查看导入的模板信息。
如果要查看模板的详细内容，可以通过oc get template cakephp-mysql-example
-o json -n openshift命令查看。-o参数指定了命令以json格式输出返回值。
刷新openshift web控制台的服务目录界面，在过滤器中输入cake，即可看到刚导入的应用模板，如图2-12所示。
在openshift origin的github仓库中还有许多预定义好的template示例。你可以按需下载，并通过oc create -f命令导入系统中。
请执行下面的命令导入wildfly-basic-s2i模板，这在后面的章节会使用到。
细心的读者也许会发现之前创建router和registry是在default项目中，而创建image stream是在openshift项目中。openshift项目是一个特殊的项目，在这个项目下创建的所有image stream及template对集群内所有的用户和项目可见。如果image stream及template在其他项目创建，则只能在创建这些对象的项目内可见。