openshift 提供了命令行工具和web可视化页面，这些工具通过REST API去和openshift交互
一、开始为开发人员使用OpenShift
1. 探索命令行
2. 探索web console
3. 部署一个docker镜像
4. 扩展应用实例
5. 路由HTTP请求
6. 从源代码构建
二、登陆到OpenShift集群
1. 通过web console登陆
2. 通过命令行去登陆
3. 与其他用户合作
4. 账户之间切换
5. 关键命令总结
三、使用odo开发
1. 应用概述
2. 创建一个初始应用
3. 创建一个新的二进制组件
4. 从源代码部署组件
5. 连接组件
6. 向外界暴露组件
7. 对代码进行改动
四、从镜像部署应用
1. 创建一个初始项目
2. 使用web console部署
3. 探索拓扑视图（Topology）
4. 删除应用
5. 使用命令行部署
五、从源代码部署应用
1. 创建一个初始项目
2. 使用web console部署
3. 查看构建日志
4. 访问应用
5. 删除应用
6. 使用命令行部署
7. 触发新的构建
8. 关键命令
六、使用CLI管理资源对象
1. 部署应用
2. 资源对象类型
3. 查询资源对象
4. 编辑资源对象
5. 创建资源对象
6. 替代资源对象
7. 标签资源对象
8. 删除资源对象
9. 关键命令总结
命令总结：
一、开始为开发人员使用OpenShift
1. 探索命令行
通过OC命令去访问openshift的Command Line Interface（CLI）
登陆：
$ oc login
使用whoami查看当前用户：
$ oc whoami
developer
$
2. 探索web console
使用web console去登陆：
创建项目：
创建完成后，如下会显示项目的一些基本信息：
在导航栏最上面我们可以看见当前角色是admin，点击administer，可以切换不同的角色，从而展示不同的页面：
下面是开发人员视角：
3. 部署一个docker镜像
由于这是一个空项目，拓扑图里有这些选项：
From Git, Container Image, From Catalog, From Dockerfile, YAML, Database;
下面从容器镜像（Container Image）选项去创建一个应用：
在将来，要返回这个方法菜单去给你的项目添加新的内容，你可以点击左侧导航栏的 +Add
在Image Name里输入如下镜像信息（官方文档提供）
docker.io/openshiftroadshow/parksmap-katacoda:1.2.0
然后点击搜索按钮，会显示镜像的相关信息
此时应用名称（Application Name）会自动填充为parksmap-katacoda-app，名称（Name）会填充为parksmap-katacoda
Application Name：相互有关联应用的合集，类似项目的前段和后端
Name：Service的名称，不可以重复，即使是在不同的Application中
默认情况下，通过容器镜像的方式创建会自动给你的应用创建一个路由，这个路由可以使你的应用可以被一个公开的URL访问，如果项目不想被外界访问，或者这不是一个Web程序，可以将其取消勾选。
为了后续学习路由的创建，这里先把取消复选框的选择。
点击蓝色的create按钮，此时会为你创建你选择的应用
这就是在openshift上部署容器镜像的所有步骤
4. 扩展应用实例
先点击应用的圈，在点击overview，在点击上箭头
为了验证我们是否成功扩展应用为两个，点击旁边的resource，会显示有两个副本，显示如下：
总的来说，扩展应用就是如此简单。应用扩展可以非常快的发生是因为openshift只是启动存在镜像的新的实例，特别是该镜像已经缓存在节点上的情况下。
应用程序自愈：
Openshift的deploymentConfigs会不断监控，去查看pods是否以期待的数量运行，如果实际状态偏离的期望状态，openshift将会修复这种情况。
点击pods列表中其中一个名字，再点击Actions，选择Delete Pod，在弹出的对话框中选择delete：
此时，会发现出现了三个pods：
我们删除的那个pod此时正在终止（Terminating）（正在被清理），一个新的pod会被创建出来，因为openshift总是确保一个pod挂掉，就会创建出一个新的pod去顶替死掉的位置。
缩放容量：
使我们应用减少为一个实例，点击侧面导航栏Topology返回拓扑视图，点击我们创建的应用，点击overview，点击向下箭头缩放到一个实例。
5. 路由HTTP请求
Services在openshift中提供内部抽象和负载均衡。但是有时候在openshift之外的客户（用户、系统、设备等）访问在openshift中的应用是通过路由层，控制这个资源的对象就是一个路由。
默认的openshift路由器（HAProxy)使用传入的http请求头来确定代理连接的位置。你可以将路由设置为安全的，例如TLS。如果你想要你的服务扩展一下，能够被外界所访问，那么你就需要设置一个路由。
在之前教程中提到，通过容器镜像的方式去创建去部署应用会默认给你创建了一个路由，因为我们取消勾选了这个选项，所以我们现在手动去创建一个路由。
创建一个路由
幸运的是，创建一个路由是一个非常简单的过程。首先，在develper下拉菜单中选择administer视图，确保你的myproject项目在项目列表中是勾选的。其次，在左边导航栏点击networking，然后routes。
点击create route 按钮
在name中输入parksmap-katacoda，Service选择parksmap-katacoda，目标端口选择8080，其他设置默认。
当你点击create后，这个路由将被创建并展示在路由详情页。
你同样可以在开发人员视图下看见这个路由。现在切换回开发人员视图，进入到拓扑视图，在parksmap-katacoda可视化中，你应该在圆圈的右上角看见一个图标。这个就代表路由，如果你点击它，它就会在你浏览器中打开这个URL。
当你点击了路由图标，你会在浏览器中看见下面这个：
6. 从源代码构建
在这章节中，我们将要去部署ParksMap应用的后端服务。后端服务将会通过REST API提供各个国家公园的数据，ParksMap前端应用将会去查询这些数据并显示在你浏览器的交互式地图上。
背景：Source-to-Image（S2I）
在之前的章节中，学会了通过存在的容器镜像去部署应用。在这个章节中，将会学如何直接通过远程Git仓库中保存的源代码来部署应用。这将使用Source-to-Image（S2I）工具来完成。
S2I的文档从以下方面描述它：
Source-to-Image(S2I)是一个构建可复制容器镜像的工具。S2I通过将源代码注入到容器镜像中，组装后的新镜像包含了构建器镜像和已经构建完成的源代码，产生的结果就可以与docker run一起使用了。S2I支持增量构建，可以重用之前下载的依赖和之前构建的工具包。
openshift支持S2I，并将其作为构建机制之一（除了从Dockerfile和自定义构建容器镜像之外）。
关于S2I的详细资料可以在 OpenShift S2I documentation 和 GitHub project respository for S2I 去查看。
关于S2I，你只需要记住唯一关键点是它从你的源代码构建处理你的容器镜像。
部署应用代码
这章要部署的应用叫做nationalparks-katacoda，它是一个python应用，将会通过REST API以JSON格式返回世界各地主要国家公园的坐标。
源代码可以在这个GitHub仓库查看：https://github.com/openshift-roadshow/nationalparks-katacoda
构建这个应用你需要在开发人员视图下点击左侧导航栏的+Add。确保你的web console打开并且你所在的项目叫做myproject，这次不是使用容器镜像，而是使用From Catalog，将会出现以下界面：
在语言一节中，在受支持的语言列表中选python，当提供Django + Postgres SQL、Django + Postgres SQL (Ephemeral)和Python选项时，选择Python选项并单击Create Application。
使用以下Git代码仓库：
https://github.com/openshift-roadshow/nationalparks-katacoda
输入完成后，在输入框外面点击一下，name输入框就会出现nationalparks-katacoda
其他选项默认。
点击屏幕右侧create按钮会回到拓扑视图，点击nationalparks-katacoda 应用你会看见resource里，你会看见在builds部分里你的构建正在运行。
这是S2I在git仓库中拉取源码创建镜像然后将要运行的步骤。
点击构建的View Logs链接，你可以看见S2I下载运行应用程序，准备应用程序和创建镜像所需要的所有python包。
当构建完成后返回拓扑视图，查看正在部署的镜像和正在启动的应用。当你在构建日志中看见Push successful时，构建就完成了。
nationalparks-katacoda组建左下角绿色勾标记表示构建已经完成，圆圈从淡蓝色变为蓝色，后端应用nationalparks-katacoda已经被部署。
现在，回到浏览器中的ParksMap前端应用程序，应该能够看到显示的国家公园的位置。如果浏览器中还没有打开应用程序，请转到拓扑视图，并单击parksmap-katacoda应用程序右上角的图标，以在浏览器中打开URL。
原文：https://learn.openshift.com/introduction/getting-started/
二、登陆到OpenShift集群
在使用openshift集群时，可以使用web console、命令行OC工具或者REST API，无论使用哪种方法来访问openshift集群，都需要在集群中创建用户进行身份验证，证明你有权限去使用集群。
在本章节可以学习通过web console和命令行去访问集群，也可以给你的项目添加协作者，方便他们去查看或者处理你的应用程序。
1. 通过web console登陆
最简单的方式就是通过web console去访问openshift并与之交互。web console的URL是在openshift集群设定时指定的URL，访问控制台后，如何登陆将取决于配置身份的提供程序。
此处同第一章相同略
点击左侧导航栏Home选项中的project可以查看你当前的所有项目。
2. 通过命令行去登陆
OpenShift 的web console提供了方便的方法可以快速的操作、查看你部署在OpenShift上的应用。不是所有你想做的事情都可以在web console上去完成，因此你还需要熟悉OpenShift的命令行工具OC。
官方教程中提供的终端已经集成了OC因此你无需在去下载OC客户端。
如果你使用的是另外的openshift集群并且还没有openshift的OC命令行工具，你可以点下面的链接去下载它。
当你访问的集群没有项目时，你会看见欢迎页中显示了在哪里去获取命令行工具的链接信息。
当你进入下载列表后，选择你对应的平台选项下载并解压安装它。
使用OC登陆OpenShift使用如下命令：
oc login
使用提供的用户名和密码登录：
登陆成功后，你可以使用下面命令验证当前用户：
oc whoami
你可以验证你登录哪个正在运行的服务器：
oc whoami --show-server
可以列出所有目前可以访问到的项目，
oc get projects
外部验证服务作为身份验证者提供的情况，所需的步骤略有不同。
如果你使用 oc login 呈现类似下面的错误：
Login failed (401 Unauthorized) You must obtain an API token by visiting https://api.starter-us-east-1.openshift.com/oauth/token/request
可以通过访问给定的链接，如果需要可能会先通过单独的身份验证服务，你将会被重定向到一个页面提供详细的登录命令信息，包括通过token为这次对话验证你的身份。
即使是openshift接受用户名密码的情况下，你也可以选择使用token去访问，你可以在访问端点URL手动输入/oauth/token/请求路径来检索要运行的命令。
如果你已经登录了web console，你可以点击登录用户名下面的Copy Login Command来检索登录命令和访问token的信息。
无论你使用哪种方式来使用OC命令行登录，登录都将会过期。有效期通常为24h。
3. 与其他用户合作
OpenShift支持很多用户，每个用户都在自己的应用上工作。为了支持在同一个项目上工作，你需要给其他用户访问你项目的权限。根据在项目中做什么来授予不同的访问权限。
测试用户如何协作，需要另外一个用户，在命令行中登录user1:
oc login --username user1 --password user1
这是这个用户第一次登录，使用下面命令：
oc get projects
发现没有项目可以访问。
要给用户权限去访问你的项目，来到web console 点击项目名称右边的下拉菜单，选择edit project
当项目信息展示出来的时候，选择role bindings标签：
你会发现只有developer是这个项目的成员，并且拥有admin的权限。
点击create binding按钮分配一个额外的成员给这个项目。
role binding的名字叫做user1-edit
确保namespace里myproject是被选中的，并且role name为edit。user1作为Subject name，点击create。
现在user1也是这个项目中的一员了，去终端中运行以下命令：
oc get projects
现在终端中应该显示user1可以访问myproject项目了。
在本例中，赋予了user1 edit的权限，这允许该用户在项目中执行大多数权限，除了项目管理的相关任务。因此user1不能修改项目成员关系或者删除项目。
其他你可以分配给合作者的角色可以是view，这意味着他们可以查看项目中的一切，但是不可以修改任何东西。或者是和项目所有者平级的admin，包含编辑项目成员或者删除项目。
还可以使用oc命令修改成员权限:
由于user1此时没有项目，通过命令来创建一个：
oc new-project mysecrets
如何通过命令赋予developer view的权限：
oc adm policy add-role-to-user view developer -n mysecrets
然后返回web console，在项目列表中你应该看见了mysecrets项目。
4. 账户之间切换
在使用oc命令行工具的时候，一次只能与一个openshift集群交互。在同一个计算机上作为同一本地用户打开一个单独的shell，同时在不同的openshift集群上工作是不可能的，那是因为当前会话状态保存在正在运行这个oc命令工具用户的home文件夹下。
如果你确实需要同时处理多个openshift集群，或者不同用户工作在同一个openshift集群，你需要记住切换他们。
我们之前先使用developer登陆，随后又使用了user1登陆。
此时你仍然登陆并拥有两个活动的会话token，但当前以user1来操作。
选择回developer用户使用以下命令：
oc login --username developer
因为你已经为developer提供过密码，所以不会需要你再次输入密码。在切换用户时，只有会话过期时才会要求你重新输入密码。
你可以使用： oc whoami 来验证是否切换成功。
如果你需要在多个openshift集群中切换，你再次登陆，但是只需要提供openshift集群的URL。例如：
oc login https://api.starter-us-east-1.openshift.com
在切换使用openshift集群时，如果你没有指明要使用哪个用户，那么默认使用最后一个登陆集群的用户，如果需要指定的话，你可以使用 --username
切换时，不需要提供密码或者注册token，因为密码和token就分别保存在所谓的上下文中，你可以使用下面的命令来看到什么是上下文：
oc whoami --show-context
你可以用以下命令得到一个你曾经登陆过的列表：
oc config get-clusters
你可以用下面命令得到一个你曾经登陆和创建过哪些应用的列表：
oc config get-contexts
5. 关键命令总结
可以使用--help选项查看帮助
oc login: Log in to your OpenShift cluster and save the session token for subsequent use. You will be prompted for the user name and password or directed to a web console page where you can obtain a token you must then use to use to login from the command line. The web page will require you to first login in to the web console if you are not already logged in. oc login <server>: Log in to a specific OpenShift cluster. You will need to specify the name of the server as argument the first time you are using it, or if switching back to it after having used a different cluster. oc login --username <user>: Log in to your OpenShift cluster as a specific user. oc login --username <username> --password <password>: Log in to your OpenShift cluster as a specific user and supply the password on the command line. Note that this is not recommended for real systems as your password may be logged or retained in command history. oc login --token <token>: Log in to your server using a token for an existing session. oc logout: Log out of the active session by clearing the session token. oc whoami: Show the name of the user for the current login session. oc whoami --token: Show the token for the current login session. oc whoami --show-server: Show which OpenShift cluster you are logged into. oc whoami --show-context: Shows the context for the current session. This will include details about the project, server and name of user, in that order. oc config get-clusters: Show a list of all OpenShift clusters ever logged in to. oc config get-contexts: Show a list of contexts for all sessions ever created. For each context listed, this will include details about the project, server and name of user, in that order. oc adm policy add-role-to-user edit <username> -n <project>: Add another user to a project so that they can work within the project, including creating new deployments or deleting applications. oc adm policy add-role-to-user view <username> -n <project>: Add another user to a project but such that they can only view what is in the project. oc adm policy add-role-to-user admin <username> -n <project>: Add another user to a project such that they are effectively a joint owner of the project and have administration rights over it, including the ability to delete the project.
原文：https://learn.openshift.com/introduction/cluster-access/
三、使用odo开发
本章将会使用OpenShift Do（odo）在openshift容器平台上部署应用。
什么是odo？
odo是一个提供给在openshift编写、构建、部署的开发人员的CLI工具。使用odo，开发人员可以得到一个支持快速迭代开发的CLI工具。odo抽象了kubernetes和openshift，这样开发者可以专注于对他们来说最重要的东西：代码。
odo的创建是为了提高openshift开发人员的体验。像oc这种现有工具更侧重于操作，需要深入理解kubernetes和openshift的概念。odo设计的更为简单简洁，因此你可以更加专注于编写代码而不是如何去部署它。当你保存你的变动后，odo会立即构建、部署你的代码到你的集群中，你可以即时获取反馈并且可以实时验证你的更改。odo的语法以开发人员数序的概念为中心，例如：项目、应用和组件。
1. 应用概述
本章将要部署的是西部狂野风格的游戏。
应用程序通常会根据逻辑划分成多个组件。例如一个应用可能存在数据存储和后端组件来存储和执行主要工作。后端组件和用户界面配对，前端组件通过访问后端来检索数据并展示给用户。
本章部署的应用包含了上述两种组件。
后端：
后端是一个java spirngboot的应用。它对kubernetes和openshift REST API执行查询，来检索部署应用时创建的资源对象列表。然后将这些资源对象列表的详细信息返回给前端。
前端是用Node.js编写的狂野西部风格的用户界面，它可以拍摄弹出的图像，对应后端返回的资源对象。
2. 创建一个初始应用
登陆openshift
使用以下命令登陆到openshift集群：
odo login -u developer -p developer
这将记录你使用的证书：
Username：developer
Password：developer
你将会看见下图提示：
可以通过运行odo project create 来创建一个新项目：
odo project create myproject
将会看见下图创建了一个myproject，并且此时odo正在使用myproject
创建一个服务账户：
应用的后端使用OpenShift REST API，为了能让后端访问API，我们需要去赋予后端使用的账号权限。我们将在web console去完成这件事。
登陆进web console，点击刚才用odo创建的项目：myproject
点击项目名，你将会进入展示项目详情页，展示了这个项目发生事件的详细信息。点击项目名后，当前正在使用这个项目，所有的操作都会发生在这个项目上。
然后点击左边administration中的Role Bindings
在Role Bindings页面点击create binding按钮，按照如下信息填写：
现在后端拥有了view权限去访问API，你也可以使用edit去代替，这样你将可以检索、修改、删除对象。
3. 创建一个新的二进制组件
正如之前提到，应用通常包含两个或者多个组件共同工作来实现整个应用程序。openshift帮助组织这些模块化程序，OpenShift应用程序表示应用程序在逻辑管理单元中的所有组件。odo工具帮助您管理这组组件，并将它们作为应用程序链接在一起。
可以在openshift上选择运行时、框架、和其他组件来构建你的应用，这个列表被称为Developer Catalog
通过下面的命令列出支持的组件类型：
odo catalog list components
管理员可以去配置目录确定哪些组件可以用，因此在不同的openshift集群它的目录也可能不同。当前场景必须包含Java和nodejs
进入到后端项目的存放路径，使用maven打包成jar.第一次构建可能时间略长，以后就会快很多。
使用odo命令部署运行jar包：创建一个叫backend的java组件配置
odo create java:8 backend --binary target/wildwest-1.0.jar
此时组件还未被部署在openshift上，使用odo创建命令，会在backend组件的本地文件夹下生成一个叫做config.yaml的文件，这个文件包含了组件部署的相关信息。
可以使用下面命令来查看backend的config.yaml的配置信息：
odo config view
由于backend是一个二进制组件，在对组件的源代码更改后应该将生成的jar文件推送到运行的容器中，mvn编译出一个新的jar包，使用odo push命令将该应用推送到openshift：
odo push
在odo push后，openshift创建了一个容器来装载backend组件，将容器部署在openshift的pod中，并启动backend组件。
此时可以在web console的开发者视角，点击拓扑图看见运行的backend组件。
如果你需要查看odo中操作的状态，可以使用 odo log命令：
odo log
odo log -f //持续输出 类似tail -f
4. 从源代码部署组件
因为nodejs是解释型语言，因此不需要像maven一样去构建，直接指定openshift集群 catalog中的nodejs环境。
odo create nodejs frontend
和backend一样会创建一个config.yaml文件。使用 odo push将当前文件夹的源代码推送到openshift容器。
backend通过终端查看的log，同样可以通过web console去查看。当容器圆圈是淡蓝色的时候，说明这个镜像还没启动完成。点击镜像圆圈，点击resource标签下的View Logs
5. 连接组件
应用的所有组件都运行在集群中，我们需要将他们连接才能交换数据。openshift提供了将程序和客户端绑定的机制，称之为连接。
使用以下命令将backend 和frontend连接起来：
odo link backend --component frontend --port 8080
这将会把backend的配置信息注入给frontend，然后重启frontend。
重启完成后，frontend 的log会显示：
Listening on 0.0.0.0, port 8080
Frontend available at URL_PREFIX: /
Proxying "/ws/*" to 'backend-app:8080'
现在backend和frontend已经连接上了，下面来将frontend公开访问。
6. 向外界暴露组件
我们已经将backend 和frontend连接起来使其能够交互。现在创建一个额外的URL让我们能够看见。
odo url create frontend --port 8080
一旦配置URL在frontend的配置文件创建完成，你将会看见下面的输出：
✓ URL created for component: frontend
To create URL on the OpenShift cluster, please run `odo push`
现在将变动推送：
odo push
在push完成后，你可以在浏览器访问输出的URL。
7. 对代码进行改动
之前已经发布了第一版应用并测试通过浏览器访问，现在来看openshift和odo如何让应用在运行时更容易的迭代的。
首先进入frontend文件夹，然后告诉odo在后台监控文件更改。& 这个是可以不加，使用ctrl+c终结它。
odo watch &
使用unix流编辑器搜索并替换一行代码来编辑index.html文件：
sed -i "s/Wild West/My App/" index.html
在odo意识到变化之前，可能会有一个轻微的延迟。一旦识别到更改，odo将把更改推到前端组件，并将其状态打印到终端:
File /root/frontend/index.html changed
File changed Pushing files...
Waiting for component to start [10ms]
Syncing files to the component [16s]
Building component [6s]
Note：如果没有在浏览器中打开页面，可以使用下面命令恢复URL：
odo url list
原文：https://learn.openshift.com/introduction/developing-with-odo/
四、从镜像部署应用
1. 创建一个初始项目
oc login -u developer -p developer
2. 使用web console部署
参考 1.3
3. 探索拓扑视图（Topology）
4. 删除应用
删除应用可以通过控制台，访问创建的每个资源类型，然后一次删除一个。更简单的方式是通过命令行oc程序。
使用下面命令查看目前项目中创建的所有资源列表：
oc get all -o name
会得到类似下面的输出
pod/blog-django-py-1-cbp96
pod/blog-django-py-1-deploy
replicationcontroller/blog-django-py-1
service/blog-django-py
deploymentconfig.apps.openshift.io/blog-django-py
imagestream.image.openshift.io/blog-django-py
route.route.openshift.io/blog-django-py
目前只创建了一个应用，所以列出来的所有资源都是这个项目相关。当你有多个项目被部署，你需要识别哪些应用是你要删除的。你可以使用标签选择器将命令应用到子集上来实现。
要确定向资源添加了哪些标签，选择一个并展示它的详细信息。要查看创建的路由，可以执行以下命令：
oc describe route/blog-django-py
应该展示输出像这样：
Name: blog-django-py
Namespace: myproject
Created: 2 minutes ago
Labels: app=blog-django-py
app.kubernetes.io/component=blog-django-py
app.kubernetes.io/instance=blog-django-py
app.kubernetes.io/part-of=blog-django-py-app
Annotations: openshift.io/generated-by=OpenShiftWebConsole
openshift.io/host.generated=true
Requested Host: blog-django-py-myproject.2886795274-80-frugo03.environments.katacoda.com exposed on router default (host apps-crc.testing) 2 minutes ago
Path: <none>
TLS Termination: <none>
Insecure Policy: <none>
Endpoint Port: 8080-tcp
Service: blog-django-py
Weight: 100 (100%)
Endpoints: 10.128.0.205:8080
由于是通过web console创建的，openshift已经自动应用于所有资源的标签app=blog-django-py ， 可以通过命令去验证：
oc get all --selector app=blog-django-py -o name
这个显示结果应该和 oc get all -o name一样。再次使用下面命令检查是否执行所描述的动作：
oc get all --seletor app=blog -o name
由于没有资源使用 app=blog这个标签，所以列表结果为空。
有一个方法可以选择只是一个应用的资源，可以调度下面命令去删除他们：
oc delete all --selector app=blog-django-py
验证资源是否被删除，再次运行下面命令：
oc get all -o name
如果你仍然可以看见资源列表，那么继续执行命令直至他们显示都被删除。你会发现你调用删除并没有立即删除他们，删除他们的速度取决于他们关闭的速度。
虽然标签选择器可以来限制查询或者删除的资源，但是要注意，它不一定是你需要使用的应用标签。从模板创建应用程序时，应用的标签及其名称由模板指定。因此，模板可以使用不同的标签约定。总是使用oc description来验证应用了哪些标签，并使用oc get all -selector来验证在删除任何资源之前匹配了哪些资源。
5. 使用命令行部署
之前使用的镜像名字是：
openshiftkatacoda/blog-django-py
如果你已经获得了要部署的镜像名称，你想要通过命令行验证它是否有效，那么可以使用oc new-app search命令：
oc new-app --search openshiftkatacoda/blog-django-py
它应该显示的输出类似：
Docker images (oc new-app --docker-image=<docker-image> [--code=<source>])
-----
openshiftkatacoda/blog-django-py
Registry: Docker Hub
Tags: latest
这确定了在docker Hub注册表中找到了这个镜像。
可以使用下面命令来部署应用：
oc new-app openshiftkatacoda/blog-django-py
显示的输出应该像下面这样：
openshift将会基于镜像名赋予一个默认名字，这个列子是 blog-django-py。使用 --name 跟着一个你希望是名字的参数给应用和创建的资源指定一个不同的名字。
通过命令行部署存在的镜像与web console不同，它默认情况下不会将应用暴露给外部。如果要将应用程序暴露给openshift外部，可以运行下面命令：
oc export service/blog-django-py
切换到web console验证是否被部署，在拓扑视图中应用应该会出现URL的快捷方式图标来访问应用。
或者查看通过命令行分配的路由主机名，可以使用下面命令：
oc get route/blog-django-py
oc new-app <docker-image> --name <name>: Deploy an application from a container image found on an external image registry. If there is any ambiguity as to the source of the image, use the --docker-image option.
原文：https://learn.openshift.com/introduction/deploying-images/
五、从源代码部署应用
1. 创建一个初始项目
2. 使用web console部署
参考 1.3
3. 查看构建日志
一旦构建开始，在web console的项目Resources面板点击view logs
这将运行你在构建运行时监控其进度。当构建完成时你会看见“push successfully”，这表示应用被推送到openshift的内部镜像注册表中。
4. 访问应用
参考1.5
5. 删除应用
参考4.4
6. 使用命令行部署
参考4.5
当构建运行时使用下面命令监控输出日志：
oc logs bc/blog-django-py --follow
7. 触发新的构建
使用下面命令触发新的构建（应用名称替换为自己的）：
oc start-build blog-django-py
会显示：
build.build.openshift.io/blog-django-py-2 started
可以使用下面命令监视任何项目的构建进度：
oc get builds --watch
当项目fork到你自己的git仓库或者这个是你自己的应用，你可以配置webhook以便提交到git仓库时自动触发新的构建。
可以使用下面命令来使用本地source code构建：
git clone https://github.com/openshift-katacoda/blog-django-py
cd blog-django-py
echo 'BLOG_BANNER_COLOR=blue' >> .s2i/environment
此命令将更新S2I（Source to Image）使用的环境变量设置文件，以确定将哪些环境变量放入创建的应用程序映像中。
oc start-build blog-django-py --from-dir=. --wait
除了 --from-dir之外和之前的命令类似，这个表明从主机目录上传源代码，而不是git仓库。
还提供了——wait选项来指示命令应该只在构建完成时返回。如果要将其集成到脚本中，并且需要在运行后续命令之前确保构建已经完成，则此选项非常有用。
要继续使用git构建则继续使用：
oc start-build blog-django-py
应该显示：
build.build.openshift.io/blog-django-py-4 started
可以用下面命令取消构建：
oc cancel-build blog-django-py-4
8. 关键命令
oc new-app <image:tag>~<source-code> --name <name>: Deploy an application from source code hosted on a Git repository using the specified S2I builder image.
oc start-build <name>: Trigger a new build and deployment of the application where source code is taken from the hosted Git repository specified tooc new-appwhen the build configuration was created.
oc start-build <name> --from-dir=.: Trigger a new build and deployment of the application where source code is taken from the current working directory of the local machine where theoccommand is being run.
oc cancel-build <build>: Cancel a running build.
oc logs bc/<name> --follow: Monitor the log output from the current build for the application.
oc get builds: Display a list of all builds, completed, cancelled and running.
oc get builds --watch: Monitor the progress of any active builds.
oc get pods --watch: Monitor any activity related to pods in the project. This will include pods run to handle building and deployment of an application.
原文链接：https://learn.openshift.com/introduction/deploying-python/
六、使用CLI管理资源对象
1. 部署应用
//使用oc登陆
oc login -u developer -p developer
//或者
oc login --username developer -password developer
//创建一个项目
oc new-project myproject
//创建一个应用
oc new-app openshiftroadshow/parksmap-katacoda:1.0. --name parksmap
//将应用暴露给外界
oc expose svc/parksmap
2. 资源对象类型
使用下面命令去查看创建的资源对象：
oc get all
//或者只看名称
oc get all -o name
oc get 是一个十分常用到的命令，除了使用all 来查询关键资源对象类型，也可以指定资源对象类型，例如用下面命令来查询向外暴露的路由：
oc get routes
也可以运行下面命令查看不同资源类型列表：
oc api-resources
除了能够使用它们的全名进行查询外，许多资源对象类型还可以使用更短的别名进行查询。因此，您可以使用cm而不是configmaps。
在资源对象的类型以单数形式列出的所有情况中，您也可以使用类型的单数形式。因此，您可以使用route而不是route。
3. 查询资源对象
为了获取指定资源的更多信息，可以使用oc describe命令：
oc describe route/parksmap
无论何时将特定的资源对象作为参数传递给oc命令，都可以使用两种约定。第一种方法是使用表单类型/名称的单个字符串。第二种方法是将类型和名称作为单独的连续参数传递。命令:
oc describe route Parkmap
可以使用下面oc get命令来将输出格式修改为JSON 或者YAML：
oc get route/parkmap -o json
oc get route/parkmap -o yaml
会输入如下所示：
$ oc get route/parksmap -o yaml
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
openshift.io/host.generated: "true"
creationTimestamp: "2020-02-11T13:02:01Z"
labels:
app: parksmap
name: parksmap
namespace: myproject
resourceVersion: ""
selfLink: /apis/route.openshift.io/v1/namespaces/myproject/routes/parksmap
uid: b186cb83-4cce-11ea-a5bf-0a580a8000e8
spec:
host: parksmap-myproject.--simba07.environments.katacoda.com
port:
targetPort: -tcp
subdomain: ""
to:
kind: Service
name: parksmap
weight:
wildcardPolicy: None
status:
ingress:
- conditions:
- lastTransitionTime: "2020-02-11T13:02:01Z"
status: "True"
type: Admitted
host: parksmap-myproject.--simba07.environments.katacoda.com
routerCanonicalHostname: apps-crc.testing
routerName: default
wildcardPolicy: None
要查看原始对象中特定字段的描述，可以使用oc explain 命令，为其提供选择字段的路径：
要查看spec对象的host字段，可以通过下面命令：
oc explain route.spec.host
会输出如下所示：
$ oc explain route.spec.host
KIND: Route
VERSION: route.openshift.io/v1FIELD: host <string>
DESCRIPTION:
host is an alias/DNS that points to the service. Optional. If not specified
a route name will typically be automatically chosen. Must follow DNS952
subdomain conventions.
4. 编辑资源对象
修改存在的资源对象可以使用oc edit命令。
比如修改样本应用的route对象，可以用：
oc edit route/parkmap
将会启动一个vi编辑器来编辑对象的定义，如果你对vi不熟悉可以使用:q退出，前提是你没有做任何更改。
默认情况下，将通过yaml格式提供，如果需要提供json格式，使用：
oc edit route/parkmap -o json
完成编辑后，将自动上传并替换原始定义。
由于OpenShift是在声明性配置模型上工作的，因此平台将运行使集群的状态与资源对象定义的所需状态一致的任何步骤。
请注意，并不是资源对象的所有字段都可以更改。有些字段可能是不可变的。其他变量可能表示相应资源的当前状态，任何更改都将被当前状态再次覆盖。
5. 创建资源对象
使用oc edit修改对象，使用oc create创建对象。
oc create命令提供了从JSON或YAML定义创建任何资源对象的通用方法，以及用于资源对象类型子集的更简单的选项驱动方法。
如果需要给自己的应用创建一个安全的路由，可以创建一个parkmap-fqdn.json文件包含定义的路由
cat > parksmap-fqdn.json << !
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {
"name": "parksmap-fqdn",
"labels": {
"app": "parksmap"
}
},
"spec": {
"host": "www.example.com",
"to": {
"kind": "Service",
"name": "parksmap",
"weight":
},
"port": {
"targetPort": "8080-tcp"
},
"tls": {
"termination": "edge",
"insecureEdgeTerminationPolicy": "Allow"
}
}
}
!
通过运行下面命令来通过parkmap-fqdn.json来创建路由：
oc create -f parkmap-fqdn.json
这个路由定义对route.metadata.name有唯一的，之前没用过的值。
对于创建路由，oc create 提供了一个专门创建路由的子命令：
oc create route edge parksmap-fqdn --service parksmap --insecure-policy Allow --hostname www.example.com
要查看oc create 支持创建资源对象类型的列表，使用：
oc create --help
6. 替代资源对象
为了能够在现有的json或yaml中修改存在的资源对象，使用oc replace命令：
若要禁用不安全的路由，请创建修改后的路由对象定义:
cat > parksmap-fqdn.json << !
{
"kind": "Route",
"apiVersion": "v1",
"metadata": {
"name": "parksmap-fqdn",
"labels": {
"app": "parksmap"
}
},
"spec": {
"host": "www.example.com",
"to": {
"kind": "Service",
"name": "parksmap",
"weight":
},
"port": {
"targetPort": "8080-tcp"
},
"tls": {
"termination": "edge",
"insecureEdgeTerminationPolicy": "Redirect"
}
}
}
!
然后运行：
oc replace -f parkmap-fqdn.json
为了让oc replace更改正确的对象，json或者yaml中定义的metadata.name的值必须和要修改的对象的值相同。
要使用oc replace脚本更新现有资源对象中的值，需要使用oc get获取现有资源对象的定义。然后可以编辑定义并使用oc replace来更新现有的资源对象。
要编辑定义，需要一种动态编辑JSON或YAML定义的方法。此过程的替代方法是使用oc patch命令，该命令将根据提供的规范编辑适当的值。
例如：通过下面的命令将route.spec.tls.insecureEdgeTerminationPolicy的值切换为不安全的路由。
oc patch route/parksmap-fqdn --patch '{"spec":{"tls": {"insecureEdgeTerminationPolicy": "Allow"}}}'
对于这两种情况，要更新的资源对象必须已经存在，否则命令将失败。如果您不知道资源对象是否已经存在，并且希望在存在时对其进行更新，但是如果不存在则创建资源对象，那么您可以使用oc apply而不是使用oc replace。
7. 标签资源对象
当您使用oc new-app部署应用程序时，标签会自动应用到创建的资源对象上。标签的名称是app，它将被设置为应用程序的名称。此标签可用于在运行查询时选择资源对象的子集。
当您部署了多个应用程序时，可以使用oc get all命令列出与特定应用程序相关的所有资源对象，并将描述要匹配的标签的选择器传递给该命令。
通过下面命令来查询你部署的应用的资源：
oc get all -o name --selector app=parkmap
如果需要向资源对象应用其他标签，可以使用oc label命令。
要将label web添加到应用程序的服务对象中，并将其值赋给true，请运行:
oc label service/parksmap web=true
然后查询那个标签对应的所有资源：
oc get all -o name --selector web=true
在服务中应该只返回资源对象。
要从资源对象中删除标签，使用：
oc label service/parkmap web-
这个命令中的label声明是这种形式的 name-, 使用-而不是=value 表示这个标签应该被移除。
8. 删除资源对象
如果需要删除整个应用程序或单个资源，可以使用oc delete命令。特定的资源对象可以通过它们的名称删除，或者使用标签匹配资源对象的一个子集。
通过名字来删除单个资源对象：
oc delete route/parkmap-fqdn
要使用标签删除特定类型的所有资源对象，请提供资源对象类型名称和选择器。
oc delete route --selector app=parkmap
在使用标签选择器时，可以用逗号分隔多个资源对象类型名。
oc delete svc, route --selector app=parkmap
还可以使用all的捷径来匹配与应用程序的构建和部署直接相关的所有关键资源对象类型。
oc delete all --selector app=parkmap
这里建议在删除任何资源对象之前，先使用 oc get 命令来确认要删除的内容，这对于oc delete all 后面拼接的参数来说非常重要，也就是说，后面不提供selector。
在这种情况下，将删除项目中所有匹配的资源对象。因为存在意外删除所有工作的危险，所以有必要提供--all选项来确认您确实希望从项目中删除所有资源对象。
oc delete all --all
9. 关键命令总结
oc api-resources: Outputs a list of all resource types supported by the cluster. oc explain <setting-path>: Shows a description of the purpose of a specific resource object type setting. oc get <type>: Shows summary details of all resource objects of a specific type. oc get <type> --selector app=<name>: Shows summary details of all resource objects of a type with the specified label. oc get <type/name>: Show summary details of a resource object. oc get <type/name> -o <json|yaml>: Shows raw details of a resource object type as JSON or YAML. oc get all: Shows summary details of the key resource objects in a project. The list of resource object types matched by all includes buildconfigs, builds, imagestreams, deploymentconfigs, replicationcontrollers, routes, services and pods. oc get all --selector app=<name>: Shows summary details of the key resource objects in a project with the specified label. oc describe <type/name>: Shows human readable long form description of a resource object. oc edit <type/name> -o <json|yaml>: Edit the raw details of a resource object type as JSON or YAML. oc create -f <definition.json>: Create a resource object from a definition stored in a file. The format of the definition must be JSON or YAML. The metadata.name field of the definition must not correspond to an existing resource object. oc replace -f <definition.json>: Replace the definition of a resource object with that stored in a file. The format of the definition must be JSON or YAML. The metadata.name field of the definition must correspond to an existing resource object. oc apply -f <definition.json>: Replace the definition of a resource object if it exists with that stored in a file. The format of the definition must be JSON or YAML. The metadata.name field of the definition must correspond to an existing resource object. If the resource object does not already exist, it will be created. oc patch <type/name> --patch <patch>: Update a resource object using a patch specification. oc label <type/name> <name=value>: Add a label to a resource object. oc label <type/name> <name->: Remove a label from a resource object. oc delete <type/name>: Delete a resource object. oc delete <type> --selector app=<name>: Delete all resource objects of a type with the specified label. oc delete <type> --all: Delete all resource objects of a specific type. oc delete all --all: Delete all key resource objects in a project. The list of resource object types matched by all includes buildconfigs, builds, imagestreams, deploymentconfigs, replicationcontrollers, routes, services and pods. oc delete all --selector app=<name>: Delete all key resource objects in a project with the specified label.