RedHat OpenShift QuickStart 1.1 OpenShift基础

时间 2020-05-12

标签 redhat openshift quickstart 1.1 基础栏目 Linux 繁體版

原文原文链接

openshift 提供了命令行工具和web可视化页面，这些工具经过REST API去和openshift交互html

1、开始为开发人员使用OpenShift

1. 探索命令行

经过OC命令去访问openshift的Command Line Interface（CLI）java

$ oc login

使用whoami查看当前用户：python

$ oc whoami developer $

2. 探索web console

使用web console去登录：git

建立项目：github

建立完成后，以下会显示项目的一些基本信息：web

在导航栏最上面咱们能够看见当前角色是admin，点击administer，能够切换不一样的角色，从而展现不一样的页面：docker

下面是开发人员视角：shell

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/

2、登录到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/

3、使用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/

4、从镜像部署应用

1. 建立一个初始项目

oc login -u developer -p developer

参考上面 1.1 和 2.1

2. 使用web console部署

参考 1.3

3. 探索拓扑视图（Topology）

参考 1.3 和 1.4

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/

5、从源代码部署应用

1. 建立一个初始项目

参考上面 1.1 和 2.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 to oc new-app when 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 the oc command 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/

6、使用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.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: "226780" selfLink: /apis/route.openshift.io/v1/namespaces/myproject/routes/parksmap uid: b186cb83-4cce-11ea-a5bf-0a580a8000e8 spec: host: parksmap-myproject.2886795279-80-simba07.environments.katacoda.com port: targetPort: 8080-tcp subdomain: "" to: kind: Service name: parksmap weight: 100 wildcardPolicy: None status: ingress: - conditions: - lastTransitionTime: "2020-02-11T13:02:01Z" status: "True" type: Admitted host: parksmap-myproject.2886795279-80-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/v1

FIELD: 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": 100 }, "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": 100 }, "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.