本示例基於開源的 KubeSphere 容器平臺 演示如何經過 GitHub 倉庫中的 Jenkinsfile 來建立流水線,流水線共包括 8 個階段,最終將一個 Hello World 頁面部署到 Kubernetes 集羣中的不一樣 namespace。java
下面的流程圖簡單說明了流水線完整的工做過程:git
流程說明:github
- 階段一. Checkout SCM: 拉取 GitHub 倉庫代碼
- 階段二. Unit test: 單元測試,若是測試經過了才繼續下面的任務
- 階段三. sonarQube analysis:sonarQube 代碼質量檢測
- 階段四. Build & push snapshot image: 根據行爲策略中所選擇分支來構建鏡像,並將 tag 爲
SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER
推送至 Harbor (其中$BUILD_NUMBER
爲 pipeline 活動列表的運行序號)。- 階段五. Push latest image: 將 master 分支打上 tag 爲 latest,並推送至 DockerHub。
- 階段六. Deploy to dev: 將 master 分支部署到 Dev 環境,此階段須要審覈。
- 階段七. Push with tag: 生成 tag 並 release 到 GitHub,並推送到 DockerHub。
- 階段八. Deploy to production: 將發佈的 tag 部署到 Production 環境。
使用 project-regular 登陸 KubeSphere,進入已建立的 devops-demo 工程,開始建立憑證。web
一、本示例代碼倉庫中的 Jenkinsfile 須要用到 DockerHub、GitHub 和 kubeconfig (kubeconfig 用於訪問接入正在運行的 Kubernetes 集羣) 等一共 3 個憑證 (credentials) 。 二、而後建立一個 Java 的 Token 並複製。docker
三、最後在 KubeSphere 中進入 devops-demo
的 DevOps 工程中,與上面步驟相似,在 憑證 下點擊 建立,建立一個類型爲 祕密文本
的憑證,憑證 ID 命名爲 sonar-token,密鑰爲上一步複製的 token 信息,完成後點擊 肯定。shell
至此,4 個憑證已經建立完成,下一步須要在示例倉庫中的 jenkinsfile 修改對應的四個憑證 ID 爲用戶本身建立的憑證 ID。瀏覽器
登陸 GitHub,將本示例用到的 GitHub 倉庫 devops-java-sample Fork 至您我的的 GitHub。安全
一、Fork 至您我的的 GitHub 後,在 根目錄 進入 Jenkinsfile-online。網絡
二、在 GitHub UI 點擊編輯圖標,須要修改以下環境變量 (environment) 的值。運維
修改項 | 值 | 含義 |
---|---|---|
DOCKER_CREDENTIAL_ID | dockerhub-id | 填寫建立憑證步驟中的 DockerHub 憑證 ID,用於登陸您的 DockerHub |
GITHUB_CREDENTIAL_ID | github-id | 填寫建立憑證步驟中的 GitHub 憑證 ID,用於推送 tag 到 GitHub 倉庫 |
KUBECONFIG_CREDENTIAL_ID | demo-kubeconfig | kubeconfig 憑證 ID,用於訪問接入正在運行的 Kubernetes 集羣 |
REGISTRY | docker.io | 默認爲 docker.io 域名,用於鏡像的推送 |
DOCKERHUB_NAMESPACE | your-dockerhub-account | 替換爲您的 DockerHub 帳號名 <br> (它也能夠是帳戶下的 Organization 名稱) |
GITHUB_ACCOUNT | your-github-account | 替換爲您的 GitHub 帳號名,例如 https://github.com/kubesphere/ 則填寫 kubesphere (它也能夠是帳戶下的 Organization 名稱) |
APP_NAME | devops-java-sample | 應用名稱 |
SONAR_CREDENTIAL_ID | sonar-token | 填寫建立憑證步驟中的 SonarQube token憑證 ID,用於代碼質量檢測 |
注: Jenkinsfile 中 mvn
命令的參數 -o
,表示開啓離線模式。本示例爲適應某些環境下網絡的干擾,以及避免在下載依賴時耗時太長,已事先完成相關依賴的下載,默認開啓離線模式。
三、修改以上的環境變量後,點擊 Commit changes,將更新提交到當前的 master 分支。
CI/CD 流水線會根據示例項目的 yaml 模板文件,最終將示例分別部署到 Dev 和 Production 這兩個項目 (Namespace) 環境中,即 kubesphere-sample-dev
和 kubesphere-sample-prod
,這兩個項目須要預先在控制檯依次建立,參考以下步驟建立該項目。
一、使用項目管理員 project-admin
帳號登陸 KubeSphere,在以前建立的企業空間 (demo-workspace) 下,點擊 項目 → 建立,建立一個 資源型項目,做爲本示例的開發環境,填寫該項目的基本信息,完成後點擊 下一步。
kubesphere-sample-dev
,若須要修改項目名稱則需在 yaml 模板文件 中修改 namespace二、本示例暫無資源請求和限制,所以高級設置中無需修改默認值,點擊 建立,項目可建立成功。
第一個項目建立完後,還須要項目管理員 project-admin
邀請當前的項目普通用戶 project-regular
進入 kubesphere-sample-dev
項目,進入「項目設置」→「項目成員」,點擊「邀請成員」選擇邀請 project-regular
並授予 operator
角色。
同上,參考以上兩步建立一個名稱爲 kubesphere-sample-prod
的項目做爲生產環境,並邀請普通用戶 project-regular
進入 kubesphere-sample-prod
項目並授予 operator
角色。
說明:當 CI/CD 流水線後續執行成功後,在
kubesphere-sample-dev
和kubesphere-sample-prod
項目中將看到流水線建立的部署 (Deployment) 和服務 (Service)。
一、進入已建立的 DevOps 工程,選擇左側菜單欄的 流水線,而後點擊 建立。
二、在彈出的窗口中,輸入流水線的基本信息。
一、點擊代碼倉庫,以添加 Github 倉庫爲例。
二、點擊彈窗中的 獲取 Token。
三、在 GitHub 的 access token 頁面填寫 Token description,簡單描述該 token,如 DevOps demo,在 Select scopes 中無需任何修改,點擊 Generate token
,GitHub 將生成一串字母和數字組成的 token 用於訪問當前帳戶下的 GitHub repo。
四、複製生成的 token,在 KubeSphere Token 框中輸入該 token 而後點擊保存。
五、驗證經過後,右側會列出此 Token 關聯用戶的全部代碼庫,選擇其中一個帶有 Jenkinsfile 的倉庫。好比此處選擇準備好的示例倉庫 devops-java-sample,點擊 選擇此倉庫,完成後點擊 下一步。
完成代碼倉庫相關設置後,進入高級設置頁面,高級設置支持對流水線的構建記錄、行爲策略、按期掃描等設置的定製化,如下對用到的相關配置做簡單釋義。
一、構建設置中,勾選 丟棄舊的構建
,此處的 保留分支的天數 和 保留分支的最大個數 默認爲 -1。
說明:
分支設置的保留分支的天數和保持分支的最大個數兩個選項能夠同時對分支進行做用,只要某個分支的保留天數和個數不知足任何一個設置的條件,則將丟棄該分支。假設設置的保留天數和個數爲 2 和 3,則分支的保留天數一旦超過 2 或者保留個數超過 3,則將丟棄該分支。默認兩個值爲 -1,表示不自動刪除分支。
丟棄舊的分支將肯定什麼時候應丟棄項目的分支記錄。分支記錄包括控制檯輸出,存檔工件以及與特定分支相關的其餘元數據。保持較少的分支能夠節省 Jenkins 所使用的磁盤空間,咱們提供了兩個選項來肯定應什麼時候丟棄舊的分支:
- 保留分支的天數:若是分支達到必定的天數,則丟棄分支。
- 保留分支的個數:若是已經存在必定數量的分支,則丟棄最舊的分支。
二、行爲策略中,KubeSphere 默認添加了三種策略。因爲本示例還未用到 從 Fork 倉庫中發現 PR 這條策略,此處能夠刪除該策略,點擊右側刪除按鈕。
說明:
支持添加三種類型的發現策略。須要說明的是,在 Jenkins 流水線被觸發時,開發者提交的 PR (Pull Request) 也被視爲一個單獨的分支。
發現分支:
- 排除也做爲 PR 提交的分支:選擇此項表示 CI 將不會掃描源分支 (好比 Origin 的 master branch),也就是須要被 merge 的分支
- 只有被提交爲 PR 的分支:僅掃描 PR 分支
- 全部分支:拉取的倉庫 (origin) 中全部的分支
從原倉庫中發現 PR:
- PR 與目標分支合併後的源代碼版本:一次發現操做,基於 PR 與目標分支合併後的源代碼版本建立並運行流水線
- PR 自己的源代碼版本:一次發現操做,基於 PR 自己的源代碼版本建立並運行流水線
- 當 PR 被發現時會建立兩個流水線,一個流水線使用 PR 自己的源代碼版本,一個流水線使用 PR 與目標分支合併後的源代碼版本:兩次發現操做,將分別建立兩條流水線,第一條流水線使用 PR 自己的源代碼版本,第二條流水線使用 PR 與目標分支合併後的源代碼版本
三、默認的 腳本路徑 爲 Jenkinsfile,請將其修改成 Jenkinsfile-online。
注:路徑是 Jenkinsfile 在代碼倉庫的路徑,表示它在示例倉庫的根目錄,若文件位置變更則需修改其腳本路徑。
四、在 掃描 Repo Trigger 勾選 若是沒有掃描觸發,則按期掃描
,掃描時間間隔可根據團隊習慣設定,本示例設置爲 5 minutes
。
說明:按期掃描是設定一個週期讓流水線週期性地掃描遠程倉庫,根據 行爲策略 查看倉庫有沒有代碼更新或新的 PR。
Webhook 推送:
Webhook 是一種高效的方式可讓流水線發現遠程倉庫的變化並自動觸發新的運行,GitHub 和 Git (如 Gitlab) 觸發 Jenkins 自動掃描應該以 Webhook 爲主,以上一步在 KubeSphere 設置按期掃描爲輔。在本示例中,能夠經過手動運行流水線,如需設置自動掃描遠端分支並觸發運行,詳見 設置自動觸發掃描 - GitHub SCM。
完成高級設置後點擊 建立。
流水線建立後,點擊瀏覽器的 刷新 按鈕,可見一條自動觸發遠程分支後的運行記錄。
一、點擊右側 運行,將根據上一步的 行爲策略 自動掃描代碼倉庫中的分支,在彈窗選擇須要構建流水線的 master
分支,系統將根據輸入的分支加載 Jenkinsfile-online (默認是根目錄下的 Jenkinsfile)。
二、因爲倉庫的 Jenkinsfile-online 中 TAG_NAME: defaultValue
沒有設置默認值,所以在這裏的 TAG_NAME
能夠輸入一個 tag 編號,好比輸入 v0.0.1。
三、點擊 肯定,將新生成一條流水線活動開始運行。
說明: tag 用於在 Github 和DockerHub 中分別生成帶有 tag 的 release 和鏡像。 注意: 在主動運行流水線以發佈 release 時,
TAG_NAME
不該與以前代碼倉庫中所存在的tag
名稱重複,若是重複會致使流水線的運行失敗。
至此,流水線 已完成建立並開始運行。
注:點擊 分支 切換到分支列表,查看流水線具體是基於哪些分支運行,這裏的分支則取決於上一步 行爲策略 的發現分支策略。
爲方便演示,此處默認用當前帳戶來審覈,當流水線執行至 input
步驟時狀態將暫停,須要手動點擊 繼續,流水線才能繼續運行。注意,在 Jenkinsfile-online 中分別定義了三個階段 (stage) 用來部署至 Dev 環境和 Production 環境以及推送 tag,所以在流水線中依次須要對 deploy to dev, push with tag, deploy to production
這三個階段審覈 3
次,若不審覈或點擊 終止 則流水線將不會繼續運行。
說明:在實際的開發生產場景下,可能須要更高權限的管理員或運維人員來審覈流水線和鏡像,並決定是否容許將其推送至代碼或鏡像倉庫,以及部署至開發或生產環境。Jenkinsfile 中的
input
步驟支持指定用戶審覈流水線,好比要指定用戶名爲 project-admin 的用戶來審覈,能夠在 Jenkinsfile 的 input 函數中追加一個字段,若是是多個用戶則經過逗號分隔,以下所示:
··· input(id: 'release-image-with-tag', message: 'release image with tag?', submitter: 'project-admin,project-admin1') ···
一、點擊流水線中 活動
列表下當前正在運行的流水線序列號,頁面展示了流水線中每一步驟的運行狀態,注意,流水線剛建立時處於初始化階段,可能僅顯示日誌窗口,待初始化 (約一分鐘) 完成後便可看到流水線。黑色框標註了流水線的步驟名稱,示例中流水線共 8 個 stage,分別在 Jenkinsfile-online 中被定義。
二、當前頁面中點擊右上方的 查看日誌
,查看流水線運行日誌。頁面展現了每一步的具體日誌、運行狀態及時間等信息,點擊左側某個具體的階段可展開查看其具體的日誌。日誌可下載至本地,如出現錯誤,下載至本地更便於分析定位問題。
一、若流水線執行成功,點擊該流水線下的 代碼質量
,便可看到經過 SonarQube 的代碼質量檢測結果,以下圖(僅供參考)。
二、流水線最終 build 的 Docker 鏡像也將被成功地 push 到 DockerHub 中,咱們在 Jenkinsfile-online 中已經配置過 DockerHub,登陸 DockerHub 查看鏡像的 push 結果,能夠看到 tag 爲 snapshot、TAG_NAME(master-1)、latest 的鏡像已經被 push 到 DockerHub,而且在 GitHub 中也生成了一個新的 tag 和 release。Hello World 示例頁面最終將以 deployment 和 service 分別部署到 KubeSphere 的 kubesphere-sample-dev
和 kubesphere-sample-prod
項目環境中。
環境 | 訪問地址 | 所在項目 (Namespace) | 部署 (Deployment) | 服務 (Service) |
---|---|---|---|---|
Dev | http://{$Virtual IP}:{$8080} <br> 或者 http://{$內網/公網 IP}:{$30861} |
kubesphere-sample-dev | ks-sample-dev | ks-sample-dev |
Production | http://{$Virtual IP}:{$8080} <br> 或者 http://{$內網/公網 IP}:{$30961} |
kubesphere-sample-prod | ks-sample | ks-sample |
三、可經過 KubeSphere 回到項目列表,依次查看以前建立的兩個項目中的部署和服務的狀態。例如,如下查看 kubesphere-sample-prod
項目下的部署。
進入該項目,在左側的菜單欄點擊 工做負載 → 部署,能夠看到 ks-sample 已建立成功。正常狀況下,部署的狀態應該顯示 運行中。
四、在菜單欄中選擇 網絡與服務 → 服務 也能夠查看對應建立的服務,能夠看到該服務的 Virtual IP 爲 10.233.42.3
,對外暴露的節點端口 (NodePort) 是 30961
。
查看服務
五、查看推送到您我的的 DockerHub 中的鏡像,能夠看到 devops-java-sample
就是 APP_NAME 的值,而 tag 也是在 jenkinsfile-online 中定義的 tag。
六、點擊 release
,查看 Fork 到您我的 GitHub repo 中的 v0.0.1
tag 和 release,它是由 jenkinsfile 中的 push with tag
生成的。
若在內網環境訪問部署的 HelloWorld 示例服務,可經過 SSH 登錄集羣節點,或使用集羣管理員登錄 KubeSphere 在 web kubectl 中輸入如下命令驗證訪問,其中 Cluster IP 和節點端口 (NodePort) 可經過對應項目下的服務中查看:
驗證 Dev 環境的示例服務
# curl {$Virtual IP}:{$Port} 或者 curl {$內網 IP}:{$NodePort} curl 10.233.40.5:8080 Hello,World!
驗證 Prodcution 環境的示例服務
# curl {$Virtual IP}:{$Port} 或者 curl {$內網 IP}:{$NodePort} curl 10.233.42.3:8080 Hello,World!
KubeSphere (https://github.com/kubesphere/kubesphere) 是一個開源的以應用爲中心的容器管理平臺,支持部署在任何基礎設施之上,並提供簡單易用的 UI,極大減輕平常開發、測試、運維的複雜度,旨在解決 Kubernetes 自己存在的存儲、網絡、安全和易用性等痛點,幫助企業輕鬆應對敏捷開發與自動化監控運維、端到端應用交付、微服務治理、多租戶管理、多集羣管理、服務與網絡管理、鏡像倉庫、AI 平臺、邊緣計算等業務場景。