目錄
- 一、今天想干啥？
- 二、今天干點啥？
- 三、今天怎么干？
- 3.1、常規打法
- 3.2、不走尋常路
- 四、開干吧！
- 4.3.1、GitLab
- 4.3.2、Jenkins
- 4.3.3、Harbor
- 4.1、工具鏈部署
- 4.2、網絡配置
- 4.3、驗證工具鏈部署結果
- 4.4、流水線配置
- 4.5、驗證流水線配置結果
- 五、總結
請注意這里的關鍵詞：快速（有多快呢？我希望這個時間是5分鐘 。）
我知道你想要一條閃閃亮的工具鏈來支撐你的應用 CICD 流程，你想要“最佳實踐” ， 你想要既靈活又簡單還易維護 ， 你有一肚子的既要，又要，還要……
行，今天我就給你一個“既有，又有，還有”的《GitLab + Jenkins + Harbor 落地方案》 。
二、今天干點啥？今天我們要搭建一條怎樣的工具鏈呢？且看效果圖：
文章插圖
- 首先我們需要完成 GitLab、Jenkins 和 Harbor 三個工具的部署；
- 接著我們需要在 GitLab 上創建一個代碼庫，并且在 Jenkins 上創建相應的流水線，這個流程最好也自動化（確實可以自動化）；
- 然后適當地配置這三個工具，實現如下 CI 流程：
- 當用戶推送代碼到 GitLab，也就是 GitLab 上相應代碼庫產生 push 或者 merge 事件的時候，這個事件能夠自動觸發 Jenkins 上的流水線執行；
- Jenkins 上流水線執行的結果能夠回顯到 GitLab；
- Jenkins 上完成了編譯、構建等等流程后，最終制品是一個容器鏡像 ， 這個鏡像可以被推送到 Harbor 上 。
當然我也知道多數情況下你并不需要考慮 GitLab 如何部署，因為95% 的概率你們公司已經有可用的 GitLab 了，或者你們考慮使用 SaaS 版的 GitLab 。外加 Kubernetes 上部署 GitLab 的復雜度不低，運維成本高，所以 ， GitLab 的“高可用部署”不是本文重點，我們把重點放在如何部署和配置好 Jenkins + Harbor，然后對接 GitLab，走通一個 CI 流程 。
綜上，今天我準備 sale 的部署模式是：
- GitLab：Docker
- Jenkins：Helm(Kubernetes)
- Harbor：Helm(Kubernetes)
聽起來就復雜 。
這個流程不應該讓所有人都重頭體驗一遍，被折磨一遍 。假如有人已經研究了一遍這些工具的部署模式 ， 并且將這個流程代碼化，做一個工具出來，并且開源免費，讓大家“開箱即用”，那該多好！
3.2、不走尋常路沒錯，你已經猜到了 ， 我不打算按常理出牌，我要找一個能夠管理 DevOps 工具鏈的工具！
有這種工具？還真有！
DevStream 就干這事 。DevStream 是啥？一句話：一個 DevOps 工具鏈管理器 。
我們看下 DevStream 如何完成這三個工具的落地：
文章插圖
DevStream 官網里有這么一個圖 。所以，這個花里胡哨的 DevStream 做了啥？
從上面的流程圖，結合官方文檔和源碼，大致我可以猜到它的工作流和原理：
- DevStream 首先將 GitLab、Jenkins、Harbor 等工具的部署流程代碼化 ， 通過插件的形式支持這些工具的安裝部署；
- 工具部署完成后 ， DevStream 會從 SCM（GitHub 或者 GitLab 都可以）下載一個項目腳手架模板，模板源碼在這里；這個模板支持高度自定義，本質就是將一些需要自定義的內容抽離成變量，供用戶自由渲染，然后批量生產項目腳手架；
- 接著 DevStream 根據用戶給定的配置文件渲染模板庫，然后將其上傳到 SCM（GitHub 或者 GitLab 都可以）；
- 然后 DevStream 會配置 Jenkins ， 安裝一些必要的插件等，用戶支持最終的 Pipeline 順利執行；
推薦閱讀
