Infrastructure as Code:
- 顧名思義就是用程式碼來定義基礎建設(Infrastructure),這是最初的解釋
- 現在則廣泛包含以下
- 1.Infrastructure as Code
- 2.Network as Code
- 3.Policy as Code
- 4.Configuration as Code
- 5.Security as Code
- 撇除過往都需要人工手動地建置伺服器,網路,組態設定…etc
- 例如現在要在AWS上面建置Kubernetes等基礎建設,元件等等
- 我們可以透過撰寫Terraform Code,Ansible Code,或是
- 一堆K8s的Manifest檔案..等
- 就可以定義建置出基礎建設平台或組態等
錯誤的Infrastructure as Code實行方式:
- 例如DevOps人員在本機撰寫並測試以下這些Code:
- Terraform/Ansible/K8s Manifest YAMLs
- 最後該DevOps人員也在本機執行這些程式碼來建置基礎建設
- 又或者是有建立Git Repository來儲存上述這些Code
- 也就是至少有版本控制這些Infrastructure as Code
- 並且也能讓其他人能夠從Git Repository取得這些Code
- 但是有可能缺乏實行Pull Request等機制
- 甚至將修改的Code內容直接地commit進Main Branch
- 亦即沒有Code Review!
- 也沒有實際的維護Code的協同合作(collaboration)的存在
- 甚至也缺少自動化Code的測試
- 導致常見的問題例如錯誤的YAML格式,宣告名稱錯誤等等
- 甚至變更的Code內容將導致基礎設施/應用程式出問題等等
執行問題:
- 實際驅動這些Infrastructure as Code,可能是在自己筆電
- 直接地執行kubectl apply指令,或是terraform apply
- 也就是有一個執行者透過個人電腦進入到基礎設施內執行
- 這將會造成難以追蹤到底是誰?執行了什麼變更異動?
- 僅有執行當下才有機會確認到是否有誤執行的內容
- 並且變成需要拿開發環境來測試這些Code是否正常
- 最終再由個人電腦來執行到下一個環境甚至是正式環境的建置上
- 也就是雖然做到了Infrastructure as Code
- 卻還是存在太多手動作業
所以GitOps則是將Infrastructure as Code如同應用程式的程式碼依樣
並且可以製作成CICD pipeline
實際GitOps該如何運作:
- 1.一樣將Infrastructure as Code置於Git做版控,供團隊存取
- 2.遵行GitOps Flow:
首先可能由工程師從Main Branch建立異動分支:
- a.如上圖經過工程師團隊協力異動後,經由啟動PR進入CI Pipeline流程
- b.CI Pipeline流程進行Code的檢核(格式等),以及自動化測試(就像應用程式的UnitTest)
- c.接著再交由其他成員進行覆核,覆核執行者可能是開發/資安/資深人員
- (亦即此時Code經過良好的測試流程與Code Review)
- d.當前面步驟c.完成覆核後才會merge進Main Branch
- 然後進行CD Pipeline(實際佈署到環境上,異動實際K8s環境/AWS基礎設施)
- 整體過程更多的自動化,流程更加透明(大家都能看到改了啥),高品質IaC
CD Pipeline方式:
現在我們專注在後半部:
實際執行方式有二:
- Push式(例如常見的如Jenkins,或GitLab CI/CD)
- 如上工具透過指令驅動實際的物件佈署進環境上:
- Pull式(這類CD工具代表的有flux,Argo)
- 通常透過工具在環境上安裝Agent,自動從Git上拉取(Pull)異動內容
- Agent會週期性監測確認Git上是否有相關的異動
- 並比對跟實際環境是否有差異
- 是否Git端定義的Code(IaC),i.e. 要求的狀態(Desire state)
- 與環境上實際(Actual state)狀態是否相等
- 若兩邊有出現不一致,則會依據Git端(Desire state)來做佈署
更容易Rollback:
- 如上以Pull式的方式,Agent會隨時syncing changes
- 持續地比對git Repository的內容是否有差異
- 例如改動造成了環境問題,就可以透過git revert進行修復!
- 讓環境退回(還原)到前一次可以運行的狀態!
Single source of Truth:
- 即便IaC內容都在許多人各自本機上修改
- 但是實際會造成異動的都是Git Repository上的那一份
- 也就是實際環境僅參照到Git Repository的Code
- 這也在管理上更加統一
增加安全性:
- 各種人員不再能夠自行隨意且直接地異動環境(如個人筆電就連上去改)
- 僅限定由CD Pipeline工具才能做出實際的異動
- 但是人員將可透過Git Flow進行變更後最終觸發CD Pipeline
- 而實際能透過Git Flow變更的人員或是過程覆核的人員還可以限制
- 這將得到以下益處:
- 1.Less Permissions to Manage(最小化管理)
- 2.More Secure Environment(更高的環境安全性)
