GitOps入門與實踐:如何整合Git和K8S?
阿新 • • 發佈:2020-03-09
也許你之前聽說過GitOps,但是對其並不瞭解。在本文中,我將對其進行簡單介紹,它其實是一個應用程式開發和管理中的一個術語,其核心思想是將應用系統的宣告性基礎架構和應用程式存放在Git的版本控制庫中。我們將介紹GitOps是什麼,它將如何影響組織以及如何與Kubernetes保持同步。
![](https://oscimg.oschina.net/oscnet/up-ddf74c4356893f809b7ca727cdd664cca8b.png)
## 什麼是GitOps
GitOps是一種實現持續交付的模型,利用Git開發工具對雲原生應用程式進行操作和管理。當將應用程式部署到Kubernetes時,Git應該是唯一的事實來源。當開發人員更改應用程式時,Git將自動把它們push到Kubernetes進行部署。而且,如果Kubernetes內的執行狀態發生變化但與Git內的狀態不一致,則它們會從Git內恢復到已知狀態。
## GitOps與CI/CD:它們之間有什麼聯絡?
GitOps和CI/CD是十分重要的工作夥伴。CI/CD可以讓開發人員持續迭代、開發和部署應用程式。而迭代通常通過一個Git配置倉庫進行(儘管也會有其他配置倉庫)。在部署/交付階段,構建的基於容器的應用程式被“push”到Kubernetes進行部署。GitOps會通過Kubernetes使用“pull”的方法來增強CI/CD模型,從而將運維層面帶入部署/交付中。
但是,如果有人更改了Kubernetes叢集中執行的某些內容,會發生什麼?我們將使用Git作為宣告性部署工具的主要事實來源,並利用其他工具在出現差異時向我們發出警報。此外,通過利用可以識別執行狀態和宣告狀態之間差異的工具,Kubernetes可以修復為已知/宣告的執行狀態。
注意:持續整合和持續開發是互補但獨立的過程。在理想狀態下,GitOps會將批處理規模拆分為單件流程,每次只處理一個單元。但是,由於CI和CD流程發生在不同的組中,因此組織之間的流程可能會有所不同。
## GitOps和應用程式生命週期
讓我們從應用程式生命週期的視角來看一下GitOps的作用。在典型的生命週期中,應用程式會經歷多個狀態,包括:
- 程式碼
- 構建
- 建立映象
- 測試
- 釋出
而使用GitOps,這些狀態將會擴充套件為:
- 部署
- 在Git倉庫中監控更改
- 日誌更改和事件
- 發生更改時發出警報,並於現有的監控/告警系統整合
- 更新
在GitOps操作模型下,當應用程式釋出時,Kubernetes需要確保其按預期執行。同時,Kubernetes通過確保其穩定性和可用性來管理應用程式的運維工作。如果一個開發人員通過Git更改了該應用程式,Kubernetes將會接受宣告並根據需要應用它。
## GitOps帶來了什麼?
- GitOps為應用程式提供一個操作模型,它可以確保Git提供一個框架來統一應用程式的執行、操作和持續開發。
- 作為CI/CD流水線的一部分,GitOps為應用程式構建/交付與執行它的位置之間提供了粘合劑。
- 在Kubernetes平臺中,Git為應用程式的開發和運維提供了唯一的事實來源。
- 應用程式交付和平臺管理都是宣告式的,同時還能通過Git進行版本控制
- Git可以控制回滾、升級以及更改
- 開發人員不需要知道如何操作運維平臺(如Kubernetes),無需瞭解複雜的部署交付流程,僅需使用熟悉的工具釋出新功能即可。極大提升開發者體驗。
- Git控制並修證差異或“漂移”
- GitOps利用稽核、監控以及回滾功能來增加應用程式釋出的可靠性和穩定性
最後,儘管在GitOps模式下還有很多工作要做,但是GitOps、DevOps以及現有CI/CD模式之間存在十分明顯的協同作用。GitOps提供了一種用於將應用程式交付到Kubernetes平臺的模型,該模型確保了Git是唯一的事實來源並且充分利用Kubernetes平臺上的功能。但值得注意的是,GitOps不能替代工具。恰恰相反,GitOps通過宣告性的流程和工具來強化流程、提高其成熟度並幫助團隊交付應用程式。
## GitOps實踐:FluxCD Demo
FluxCD(或Flux)是一個很棒的工具,它可以將Git和Kubernetes整合起來。Flux本質上是一個Kubernetes Operator,這意味著,你作為一個管理員可以將其安裝到Kubernetes 以管理Git和原生Kubernetes之間的整合。
在Kubernetes中,Operator是Kubernetes原生平臺的擴充套件,是一種自定義資源的模式,該自定義資源主要用於管理應用程式及其元件。這意味著,在Kubernetes內部Operator的幫助下,所需狀態(如執行狀態)將不斷檢查和調整以符合Git倉庫宣告的內容。Flux可以整合到你現有的CI/CD工具集中,以進行其他工作流程、許可權批准和稽核。在Kubernetes中,Flux會監控你通過配置宣告的Git倉庫是否發生更改,並且如果 Kubernetes Pod上在本地發生了不應發生的更改,Flux將會把Kubernetes更新到所需的執行狀態。請記住,Git是事實來源。Flux Operator會檢測到這一點,並將正在執行的配置更改回宣告的狀態。
以下demo,我將會展示如何安裝和實現Flux。
### 前期準備
你將需要:
- 一個Docker Hub映象倉庫,你可以將Flaskapp docker映象上傳到此處
- 一個Git Repo並連線它,然後你可以在整個演示過程中根據需要用你的設定替換“< >”中的任何內容
### 具體步驟
- 安裝Kubernetes
- 安裝並配置fluxctl,Flux部署的原生安裝程式
- 配置Flux以連線到Git Repo
- 在Git Repo中升級deployment manifest
- 升級容器映象並同步
- 配置漂移(drift)並同步
你可以使用以下配置進行測試或演示。它包括Flask應用程式的Docker file以及Kubernetes deployment/配置檔案。在演示中,你會需要它們,此外你還可以將它們上傳到你指定的Git倉庫中。
**Docker File**
```
FROM python:3
RUN pip install flask
RUN mkdir -p /corp/app
WORKDIR /corp/app
COPY main.py .
ENV FLASK_APP=/corp/app/main.py
ENV APP_NAME=MyApp.DevOps
ENV APP_VERSION=v1.0.0
CMD ["flask", "run", "--host=127.0.0.1"]
```
`main.py` Python 指令碼檔案
```
import os
from flask import Flask
app = Flask(__name__)
@app.route('/')
def index():
appname = os.environ['APP_NAME']
appversion = os.environ['APP_VERSION']
response = "%s - %s.%s\n" %('Hello World', appname, appversion)
return response
```
**Kubernetes Deployment檔案**
```
apiVersion: v1
kind: Namespace
metadata:
name: my-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fluxdemo
namespace: my-demo
annotations:
flux.weave.works/tag.flask: glob:develop-v*
flux.weave.works/automated: 'true'
labels:
role: fluxdemo
env: demo
app: flux
spec:
replicas: 1
selector:
matchLabels:
role: fluxdemo
template:
metadata:
labels:
role: fluxdemo
spec:
containers:
- name: nginx
image: nginx:1.16-perl
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
volumeMounts:
- name: nginx-proxy-config
mountPath: /etc/nginx/conf.d/default.conf
subPath: nginx.conf
- name: flask
image: do