GitOps:Weaveworks通過開發者工具實現CI/CD
在過去的一年中,Weaveworks團隊逐步改進了有關“GitOps”實踐的想法。“GitOps”是指他們通過開發者工具來推動運營和實現持續交付。
\\GitOps是通過使用Git分散式版本控制系統(DVCS)作為宣告性基礎設施和應用程式的單一事實來源來實現的。團隊中的每個開發人員都可以向Git儲存庫發出拉取請求,在合併請求時,“diff and sync”工具將檢測系統的預期狀態和實際狀態之間的差異,然後觸發工具對基礎設施進行更新和同步,使其達到預期狀態。
\\Weaveworks的創始人兼執行長Alexis Richardson和Weaveworks的社群工程師Ilya Dmitrichenko在他們的公司部落格上撰寫了一系列文章,解釋了GitOps的概念。在進行GitOps實踐時,一旦有變更被提交到Git,自動構建/交付管道就會使用“拉模型”來檢測和釋出對基礎設施做出的變更。GitOps實踐並不強制使用特定的工具或產品,它只需要所選工具提供的某些功能(例如“diff and sync”)。
\\Weaveworks團隊聲稱,GitOps可以幫助開發團隊提高效率並提高系統的可靠性。他們討論瞭如何在團隊內部實現GitOps來幫助交付他們的產品,以及如何通過他們的Weave CloudSaaS產品為這種方法提供構建模組。Weave Cloud提供“容器和微服務的部署、監控和管理”,並支援Git叢集同步。
\\目前,Weaveworks使用容器和Kubernetes進行部署來實現GitOps,包括:
\\- 軟體系統中可以被描述為程式碼的內容都必須儲存在Git中:通過使用Git作為事實的來源,可以觀察一個叢集的變化,並將其與預期的狀態進行比較。目標是描述和對所有內容進行版本控制:策略、程式碼、配置,甚至是監控事件和儀表盤定義。\
- 不應直接使用Kubernetes CLI工具(kubectl):作為一般規則,使用kubectl直接部署到叢集不是一個好習慣。Weaveworks團隊認為,很多人通過CI工具來推動部署,但這樣做會阻礙他們實現良好的關注點分離,並且“提供了某種臭名昭著的可以訪問生產環境的方式”。\
- 使用遵循“操作員模式”的Kubernetes控制器:通過擴充套件Kubernetes提供的功能以及使用遵循操作員模式的自定義控制器,群集可以被配置成始終與基於Git的“真實來源”保持同步。Weaveworks團隊使用“diff”和“sync”工具(如開源的kubediff,內部工具“terradiff”和“ansiblediff”,分別用於Terraform和Ansible)對預期狀態與實際狀態進行對比。\
“擁抱GitOps理念和最佳實踐”就是通過比較和管理基礎設施和應用程式的當前狀態,讓團隊可以使用Git日誌中的完整審計路徑進行測試、部署和回滾。與舊技術相比,現代平臺元件讓這種方法更加可行,例如,Kubernetes幾乎完全可以通過宣告性配置進行管理,並且容器可以相對容易地變為不可變的。
\\例如,在Weave Cloud SaaS平臺上,一個用於在應用程式中建立或更新新功能的典型開發者工作流程是這樣的:
\\- 工程師在新的Git分支上開發新功能,並在他們準備好提交程式碼進行評審時發起拉取請求。\\t
- 對程式碼進行評審,新增評論或由同事批准變更。在進行必要的修訂之後,批准的拉取請求將被合併到主幹或主線分支。\\t
- Git合併將觸發持續整合(CI)和構建管道,並執行一系列測試。成功完成這些測試後,將構建一個新的容器映象,並上載到映象登錄檔。\\t
- Weave Cloud的“Deployment Automator”會監控映象登錄檔,一旦發現新映像,就從登錄檔中拉取它,並更新儲存庫中包含配置的的相關YAML檔案。\\t
- Weave Cloud的“Deployment Synchronizer”(安裝在群集中)會檢測到群集狀態“已過期”,並從配置儲存庫中拉取已發生變更的清單,並將新功能部署到生產環境中。\
GitOps管道示例(影象來自Weaveworks部落格)
\\Weaveworks團隊表示,GitOps是一種“面向釋出的模型”,用於實現和管理運營和功能。通過增加良好的可觀察性實踐和工具,完成假設驅動開發的反饋迴圈,團隊為客戶提供新功能的速度將部分取決於他們在OODA迴圈中經歷各個階段的速度:
\\\\GitOps SDLC,受OODA迴圈的啟發(圖片來自Weaveworks部落格)
\\對於有興趣瞭解GitOps的讀者,可以閱讀Weavework網站上的一系列部落格。第一篇文章解釋了“拉取請求運營”模型,並提供了該概念的動機和高階概述。第二篇文章討論了GitOps交付管道的核心階段。本系列的第三部分探討了可觀察性在這種實踐中的作用。來自軟體交付社群的反應相當鼓舞人心,包括Kelsey Hightower在內的行業傑出人士對這種方法給予了積極的評價。
\\還有一篇獨立文章探討了GitOps與“CIOps”的關係,並認為使用CI工具可能不是協調持續交付軟體部署的最佳方法。並不是每個人都對這篇文章中選擇的術語感到滿意,例如,Conflux Digital諮詢主管Matthew Skelton認為,“CIOps”一詞可能會導致一些工程師得出錯誤的結論,即GitOps在某種程度上是CI的替代方案。
\\有關GitOps的更多資訊,請訪問Weaveworks部落格。
\\檢視英文原文:\"GitOps\": Weaveworks Explain Their Model for Using Developer Tooling to Implement CI/CD
相關文章
- 開發.NET Core NuGet包並實現CI/CD
- gitlab 實現CI/CDGitlab
- 純 Git 實現前端 CI/CDGit前端
- 使用Kubernetes-Jenkins實現CI/CDJenkins
- Docker 整合 Jenkins Gitlab 實現 CI/CDDockerJenkinsGitlab
- 透過雲效 CI/CD 實現微服務全鏈路灰度微服務
- 透過 Drone CLI 手動觸發 CI/CD 流程
- 使用Github Actions + Watchtower 實現專案CI/CDGithub
- dagger:用於CI/CD管道的行動式開發工具包
- CI & CD ?
- 應該使用什麼 CI/CD 工具?
- .NetCore 配合 Gitlab CI&CD 實踐 - 開篇NetCoreGitlab
- 開源一套快速部署程式的工具(CI/CD)
- Azure Data Factory(三)整合 Azure Devops 實現CI/CDdev
- 簡述如何使用ArgoCD實現CI/CD部署? - redditGo
- 使用Kubernetes實現CI/CD幾個注意點 - harness
- GitOps 應用實踐系列 - Argo CD 上手實踐GitGo
- CI/CD理解
- 90%的開發都沒搞懂的CI和CD!
- 基於 GitLab CI 的前端工程CI/CD實踐Gitlab前端
- Springboot 專案通過 gitlab CI/CD 整合 k8s 自動部署Spring BootGitlabK8S
- .Net微服務實戰之CI/CD微服務
- CI/CD 持續整合部署實踐
- GitLab-CI/CD入門實操Gitlab
- CI/CD的概述
- Electron-vue開發實戰4——通過CI釋出以及更新的方式Vue
- 5步實現規模化的Kubernetes CI/CD 流水線
- 基於Drone實現CI/CD【0到1架構系列】架構
- 5.新增Koa專案的CI指令碼,提交到gitlab實現CI&CD指令碼Gitlab
- 4.新增Angular專案的CI指令碼,提交到gitlab實現CI&CDAngular指令碼Gitlab
- Azure DevOps+Docker+Asp.NET Core 實現CI/CD(二.建立CI持續整合管道)devDockerASP.NET
- 實踐分享!GitLab CI/CD 快速入門Gitlab
- ?(不要錯過!)【CI/CD技術專題】「Jenkins實戰系列」(3)Jenkinsfile+DockerFile實現自動部署JenkinsDocker
- Dockerfile+Jenkinsfile+GitLab輕鬆實現.NetCore程式的CI&CDDockerJenkinsGitlabNetCore
- 使用 Gitlab CI/CD 實現自動化釋出站點到 IISGitlab
- ArgoCD + KubeVela:以開發者為中心的 GitOpsGoGit
- Drone CI/CD 介紹
- 前端初探 Gitlab CI/CD前端Gitlab