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

登錄：node

$ 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.

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。