雲原生應用程序以其改進的性能和高效率在市場上占主導地位。儘管有更多資源來支持做爲微服務運行的雲原生應用程序,可是管理複雜的雲架構仍然是一個挑戰。您運行的微服務越多,您必須處理的任務越多,以保持雲環境的健康和平穩運行。html
自動化成爲解決該問題的明顯方法。特別是Kubernetes如今受到新方法的支持,例如基礎架構即代碼和大量自動化工具。儘管如此,當今的CI / CD週期仍須要更強大且敏捷的體系結構。這是GitOps爲Kubernetes就派上用場了。git
GitOps是一種持續部署的新方法,它利用Git做爲聲明性基礎結構和應用程序的單一事實來源,同時提供修訂和變動控制。使用GitOps,經過提交拉取請求(和後續合併)來運行系統,以實現Git存儲庫中表示的系統的所需狀態。github
帶有Kubernetes的GitOps經過聲明性的持續交付系統提供了代碼級基礎架構和不變的基礎架構。聲明式配置和主動對賬模型的樣式擴展了該平臺在Kubernetes應用程序的部署,監視和生命週期管理方面的核心優點。數組
該框架旨在與任何CI / CD管道很好地集成,即便您使用第三方工具來本機管理管道也是如此。安全
實際上,GitOps比實際工具更多的是工做流程或方法。這種方法能夠幫助您優化CI / CD週期,而無需更改將微服務開發和部署到雲的方式。服務器
因爲GitOps是做爲持續交付雲原生應用程序的框架而開發的,所以您能夠依靠該框架來簡化管道中的某些流程。它無縫集成了咱們已經熟悉的Git工具和CD工具。架構
本質上,GitOps將傳統的CI / CD管道與Git工做流結合在一塊兒,從而能夠更好地進行Kubernetes的端到端管理和應用程序開發。二者被視爲統一的過程,而不是分開的過程。框架
GitOps的特色是:運維
經過定義,很容易看出GitOps如何從改進的開發人員體驗開始爲錶帶來不少好處。開發人員再也不須要擔憂將代碼打包在容器中以及使用Kubernetes集羣的問題。相反,他們能夠專一於本身的代碼,依靠熟悉的工具(如Git)來處理其餘全部內容。微服務
這是對開發人員體驗的絕對改善。即便在DevOps專家的協助下,在許多狀況下,應用程序部署仍然是瓶頸,這僅僅是由於須要易於打包的包裝良好的代碼和微服務。GitOps以其很是規的方法解決了這一瓶頸。
實施該方法後,還能夠指望應用程序具備更好的穩定性。Git具備詳細的日誌記錄系統,可輕鬆進行審覈和跟蹤,當您使用GitOps做爲方法時,您將從同一日誌記錄工具中受益。對Kubernetes集羣的更改被記錄在日誌中,從而使雲審計變得更加容易管理。
甚至錯誤和崩潰之類的細節也是能夠追溯的。諸如誰提交更改以及這些更改的結果之類的詳細信息會記錄在每一步中。不管您是嘗試遵循安全性最佳實踐仍是追求SOC 2合規性,Git日誌的使用無疑會使維護穩定的系統變得更加容易。
大多數組織必須對其流程和系統進行大量投資才能合規和可審覈。使用GitOps和Kubernetes,能夠以最小的努力知足大多數合規性和可審覈性要求。在此處閱讀有關與咱們達成SOC 2合規性的更多信息。
還有一個事實,GitOps幫助開發團隊提升了生產率。DevOps運動中出現的最突出的範例之一是聲明性系統和配置的模型。簡而言之,使用聲明性模型描述了要實現的目標,而不是如何實現目標。
消除與基礎架構相關的任務也是巨大的幫助。儘管使用傳統的DevOps方法,但許多開發人員對將其雲基礎架構做爲代碼進行管理並不徹底滿意。該過程仍然涉及必定程度的複雜性。
傳統上,基礎架構維護每每成爲瓶頸,而不是支持功能。許多開發團隊最終將管理基礎架構的任務與主要的CI / CD管道分開,從而致使流程效率進一步下降。GitOps徹底消除了瓶頸,而無需更改管道。
GitOps還有助於改善雲環境的安全性和標準化。將代碼更改推送到Git,而後再進行進一步處理。能夠採起其餘安全措施,例如根據安全標準進行代碼檢查。將登臺服務器集成到流程中也是一種慣例。
在這種狀況下,事實的惟一來源是Git接管的角色。每當安全問題影響系統時,您始終能夠經過查看Git存儲庫找到根本緣由。只要直接對Kubernetes集羣進行更改,警報和日誌就會自動發送到Git,這爲該方法增長了一層安全性。
另外,GitOps經過將其對環境的聲明性規範存儲在源代碼控制中做爲事實來源來幫助恢復基礎結構環境。經過對環境應該是什麼的完整定義(惟一的事實來源),它有助於在發生災難時從新建立環境。
最後,事實是GitOps使整個系統更加可靠。您能夠經過控制Git存儲庫來分叉和還原更改。您用於管理代碼和分支的相同Git命令可用於管理整個雲環境。當出現問題時,回滾到某個快照很容易。
GitOps還增長了複雜的自動化功能。您能夠在Git中自動化的全部事情均可以在GitOps中實現。同時,該方法自己能夠經過簡單的命令自動管理Kubernetes集羣。這是一種真正知足現代雲原生應用程序需求的方法。
在介紹如何實現GitOps做爲一種方法以前,還須要仔細研究這種方法的基本原理。
1.有關基礎架構的全部內容均以聲明方式描述。全部服務器配置都定義爲事實,並已徹底合併到Git存儲庫中,以實現最大的可靠性。聲明式還意味着對應用程序聲明進行完全的版本控制。
2.系統狀態在Git中進行版本控制。這是從GitOps的錯誤中恢復很是容易的主要緣由之一。您能夠以一致的方式回滾到某個版本。無需花費數小時進行災難恢復,您只需花費幾分鐘。
3.須要批准更改,可是能夠在系統中實施批准的更改。在實施以前,不須要單獨的部署工做流或新代碼的預打包。一切都會自動發生。
4.正確性和安全性是流程的一部分。無需將單獨的安全性和完整性工做流程併入CI / CD管道。基礎架構即代碼已提高到一個全新的水平。
GitOps在處理更改方面很是簡單。該過程從將新代碼推送到Git進行進一步審查開始。一旦清除並批准了新代碼,它們就會合併到Git中。這是觸發部署新代碼的動做的地方。
Git將與您喜歡的CD流水線工具一塊兒觸發建立新映像。該過程是徹底自動化的,所以您只須要定義一次參數。與AWS CodePipeline和AWS CodeCommit之類的工具結合使用,可能性是無限的。不是AWS用戶?整合谷歌雲乙ü ILD的連續部署詹金斯的持續集成工具。或者,Cloud Build的CI也能夠連接到Google的Spinnaker CD工具。
經常使用的工具是Flux。Flux與Amazon EKS無縫協做 ,可提供真正可擴展的雲環境。CodeBuild可用於將新代碼推送到ECR,而後Flux將自動對EKS集羣進行必要的更改。
Flux自動將容器部署到Kubernetes。它填補了構建和監視之間存在的自動化空白。
Flux的主要功能是版本控制存儲庫和集羣之間的自動同步。若是您對存儲庫進行任何更改,則這些更改將自動部署到集羣中。
另外一個功能是容器的部署自動化。它將持續監視一系列的容器註冊表,並在適用時部署新版本。
這對於使存儲庫以及羣集保持最新狀態很是有用。因爲Flux可以查看新映像並相應地更新集羣,所以它還容許獨立的團隊擁有本身的部署管道。可是也能夠禁用此功能,而且能夠將圖像鎖定到特定版本。
爲了跨環境和羣集自定義配置,Flux內置了對Kustomize和Helm的支持。
助焊劑工做流程
Flux將監視您指定的全部容器映像存儲庫。它能夠檢測新映像,觸發部署並自動更新Kubernetes集羣的所需運行配置,而且能夠在可配置部署策略的範圍內進行。
若是您已經在使用Kubernetes和Helm,請按照Flux的深刻教程進行操做。該教程是最新的Flux版本1.18.0。
如您所見,設置Flux,部署應用,授予Flux訪問權限以及完成修改所涉及的實際步驟很是簡單。
許多開發人員已經在利用GitOps並實現收益。這種方法將進一步加強Kubernetes做爲雲平臺的能力。指望未來會在更多開發項目中實施GitOps。
更多文章請搜索「運維派」,有驚喜。