在好幾天前我們聊到了第 3 代的 CI/CD Pipeline ,也提過筆者認為 CNCF 那一派的 GitOps 就是一種第 3 代的 CI/CD Pipeline,今天就讓我們順著這個主題繼續聊下去。
我們先來複習一下第 3 代的 CI/CD Pipeline 與 GitOps!
筆者認為第 3 代的 CI/CD Pipeline 就是「完全根據 Cloud Native 思維而打造的 CI/CD Pipeline。」,而 GitOps 按著 weaveworks 的說法則是:
Pioneered in 2017, GitOps is a way to do Kubernetes cluster management and application delivery. GitOps works by using Git as a single source of truth for declarative infrastructure and applications. With GitOps, the use of software agents can alert on any divergence between Git with what's running in a cluster, and if there's a difference, Kubernetes reconcilers automatically update or rollback the cluster depending on the case. With Git at the center of your delivery pipelines, developers use familiar tools to make pull requests to accelerate and simplify both application deployments and operations tasks to Kubernetes.
也就是說 GitOps 是以 Git 為中心點,仰賴 K8s 生態系,搭建了一座 infrastructure 及一套自動化流程,讓 infrastructure 異動及應用程式部署能夠自動化。
(截圖來源:Weaveworks 的 Guide To GitOps)
而根據他們的說法,GitOps 能夠帶來許多好處,像是提高生產力、提升穩定性與可靠性、⋯⋯,以及筆者認為很重要的 3 個好處:
其實這三個好處,我覺得都可以合併在第二項好處中「更高的一致性與標準化」。
GitOps 仰賴於 CNCF + K8s 生態系,將從開發、交付、部署至維運整個流程,以及 infrastructure 全都給標準化了。
Dev 別再煩惱什麼開發環境?或是煩惱要編譯出哪種 Artifacts?或是到底該如何交付?Dev 不用再搞一堆 Ops 的繁瑣細節工作,只要按著大家商議好的 Cloud Native 標準原則來開發適合 Cloud Native 的應用程式,然後送出你的 Commit。
Ops 也一樣,別再煩惱什麼測試、pre-prod 還是 prod 環境?或是到底 Dev 會丟出一包奇怪的 Artifacts?Ops 不用再煩惱不同團隊的 Dev 會丟出採用不同規則、不同部署方式的應用程式,一切都按著 Cloud Native(或 K8s 生態系)的原則,只要撰寫與審核 IaC 就能完成應用程式的部署上線;連 Ops 都不用把手弄髒去搞一堆 Ops 的繁瑣細節工作,Ops 可以像 Dev 一樣工作,也只需要送出 Commit,剩下的事情都會自動搞定。
你看看,這是多麼美好的情景啊,多麼良好的開發者體驗與安全性。大家都不用把手弄髒,就可以完成開發及維運工作;只需要給予 git 的權限給 Dev 及 Ops 的 User,其他的權限都可以鎖著不開放使用,多麼安全啊。
這就是我說的「更高的一致性與標準化」,因此就如我前幾天文章聊過的,隨著思維及技術的演進,在這趟「持續改善」的旅程中,很自然的有了新一代的協作方式,讓團隊能夠更好的「交付價值」,讓 Dev 與 Ops 能更順暢的協作,讓雙方都能做好自己該做的事。
可是事情真的有這麼美好嗎?
讓我們先來看一下這份刊登在 CNCF Blog 的 GitOps Checklist (這 checklist 其實來自於 weaveworks),在第 1、2 條告訴了我們很驚人的事實!
(截圖來源:GitOps Checklist )
這樣看來 GitOps 並不是一件簡單的事情,這裡有很多「工程 / 技術」面的議題需要搞定,同時也有很多「文化 / 人 / 協作」面的議題需要搞定。
聊到這裡,你還想要搞 GitOps 嗎?
歡迎與我分享你的想法~DevOps 輕鬆聊,明天見啦~