Kubernetes微服務自動化發布系統
本文轉載自微信公眾號「 無敵碼農」，作者 無敵碼農 。轉載本文請聯系 無敵碼農公眾號。
原文鏈接： https://mp.weixin.qq.com/s/WPwoRi240rKaWeIs0yNZ2g
實施微服務架構后，原先單一的系統結構統變成了數量眾多的微服務應用，開發、測試、運維部署等都會面臨不少挑戰。在微服務架構下如何提高工程研發效率，確保開發、測試、運維部署等流程上的順暢，是微服務技術體系能夠真正落地產生效益的關鍵。
要實現上述目標就需要基于DevOps(開發運維)思想構建一套高度自動化的發布系統，在該系統中開發人員可以隨時隨地構建代碼并將其發布至指定的運行環境中，這個過程也就是我們通常所說的CI/CD(持續集成/持續交付)流程。
關于DevOps的具體實踐，不同的公司一般會根據自身的發展階段和實際需要來選擇具體落地的方案。具備條件的公司可以研發功能豐富的可視化發布系統，而條件有限的創業公司則可以通過開源或現有的技術組件(如GitLab、Jenkins等)來實現操作相對簡陋但功能完備的自動化發布系統。
在本篇文章中我將以Spring Cloud微服務技術體系為背景，通過GitLab自帶的CI/CD機制并基于Kubernetes容器化技術來實現一套具備相對完整CI/CD流程的自動化發布系統。
CI/CD流程概述
實際上DevOps并不是微服務架構流行之后才產生的概念，而是業界在多年軟件開發實踐中積累的理論、工具的集合。本文所要討論的自動化發布系統實際上是要通過搭建CI/CD流水線來建立一套應用程序構建、測試、打包及發布的高效自動化方法。關于CI(持續集成)/CD(持續交付)的概念并不是指某一種具體的技術，而是一種軟件工程文化加一系列操作原則和具體實踐的集合。
其中CI(持續集成)的主要目標是通過建立一致的自動化構建方法來打包程序代碼，使得團隊成員能夠以更頻繁地動作提交代碼、更早地進行代碼集成，以及時發現和解決代碼中的問題、提高協作開發效率及軟件交付質量。可持續集成(CI)的基本流程如圖所示：
從實現流程上來說CI的主要過程就是將開發人員提交的代碼以高度自動化的方式打包成可以在具體基礎架構環境運行的程序包(例如Docker鏡像)。而這個過程可以由一組工具如GitLab Runner(CI Pipeline)、Sonar(代碼檢測工具)等去完成，具體構建CI流程時根據實際需要集成運用即可。
持續交付(CD)的主要邏輯則是將CI流程中構建的程序鏡像從鏡像倉庫自動發布到具體的基礎架構環境(如測試/生產Kubernetes集群)，實現CD的工具主要有GitLab Runner(CD Pipeline)、Helm(Kubernetes軟件包管理工具)等。
實際上CD的核心就是通過輸入的各種用戶參數(如yaml文件、環境配置參數等)最終自動生成具體的發布指令(如Helm指令)，并根據參數中設置的相應信息來配置程序的具體運行環境。可持續交付(CD)的基本運行流程如下圖所示：
以上就是CI/CD的基本概念及流程，也是自動化發布系統的實現的依據。在后面的內容中將主要圍繞這兩個階段來實現自動化發布系統的基本流程邏輯。
系統的基本組成
本文所要描述的自動化發布系統主要是利用GitLab提供的GitLab CI機制，實現當代碼發生提交或合并等事件時自動觸發預設的CI/CD流程。其中CI流程主要包括基本的代碼編譯、構建、打包等階段，并在完成上述步驟后將打包好的應用Docker鏡像發布至鏡像倉庫。
而CD階段則是從鏡像倉庫拉取應用Docker鏡像，并根據設置的CD流程將應用發布至指定的Kubernetes集群。具體系統結構如下圖所示：
如上圖所示，該自動化發布系統主要由GitLab、Harbor鏡像倉庫及Kubernetes集群組成。其中GitLab主要承擔代碼版本的管理，以及CI/CD流程定義和觸發， Harbor負責應用Docker鏡像的存儲和分發，而Kubernetes集群則是應用容器運行的基礎架構環境。
GitLab-CI自動化發布系統的關鍵實現
前面我們描述了基于GitLab-CI機制實現自動化發布系統的基本組成，要具體實現這套系統你需要安裝部署GitLab服務器并配置GItLab Runner功能，私有鏡像倉庫服務(Harbor或JFrog)以及Kubernetes集群(具體可參見本專欄的其他文章)。
由于GitLab服務器是CI/CD流程執行的主要承載點，如果你的服務是基于Maven構建的Java服務，那么還需要在GitLab服務器中安裝Maven客戶端，并配置Maven私服的地址，以提高構建速度。此外GitLab服務器在CI/CD流程執行中還會運行Docker鏡像打包構建，將鏡像push到Docker鏡像倉庫以及將Docker鏡像從私有倉庫發布至Kubernetes集群等邏輯，所以GitLab服務器還需要安裝Docker環境及kubelet客戶端。
如果環境都OK，那么我們就可以在Gitlab項目根目錄代碼中創建“.gitlab-ci.yml”文件并定義具體的CI/CD流程了。但在具體定義之前，我們需要在Maven項目中添加應用Docker鏡像打包的插件配置及Dockerfile文件定義，具體如下：
- <!--添加Docker鏡像Maven打包插件-->
- <plugin>
- <groupId>com.spotify</groupId>
- <artifactId>dockerfile-maven-plugin</artifactId>
- <version>1.4.13</version>
- <executions>
- <execution>
- <id>build-image</id>
- <phase>package</phase>
- <goals>
- <goal>build</goal>
- </goals>
- </execution>
- </executions>
- <configuration>
- <!--指定Dockerfile文件位置-->
- <dockerfile>docker/Dockerfile</dockerfile>
- <!--指定Docker鏡像倉庫路徑-->
- <repository>${docker.repository}/springcloud-action/${app.name}</repository>
- <buildArgs>
- <!--提供參數向Dockerfile傳遞-->
- <JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
- </buildArgs>
- </configuration>
- </plugin>
在項目工程pom.xml文件中添加“dockerfile-maven-plugin”插件，該插件是早期“docker-maven-plugin”插件的替代品，支持將Maven項目構建打包為Docker鏡像。上述配置中，針對Docker鏡像的具體構建方式，是通過在
- FROM openjdk:8u191-jre-alpine3.9
- ENTRYPOINT ["/usr/bin/java", "-jar", "/app.jar"]
- ARG JAR_FILE
- ADD ${JAR_FILE} /app.jar
- EXPOSE 8080
配置好Maven打包插件后，就能支持通過Maven打包命令，將應用代碼打包成Docker鏡像了。此時我們在".gitlab-ci.yml"文件中定義具體的CI/CD構建Stages，示例如下：
- #環境參數信息
- variables:
- #Docker鏡像倉庫地址&賬號密碼信息
- DOCKER_REPO_URL: "10.211.55.11:8088"
- DOCKER_REPO_USERNAME: admin
- DOCKER_REPO_PASSWORD: Harbor12345
- #Kubernetes相關信息配置(空間與服務端口)
- K8S_NAMESPACE: "wudimanong"
- PORT: "8080"
- #定義CI/CD階段
- stages:
- - test
- - build
- - push
- - deploy
- #執行單元測試階段
- maven-test:
- stage: test
- script:
- - mvn clean test
- #代碼編譯打包鏡像階段
- maven-build:
- stage: build
- script:
- - mvn clean package -DskipTests
- #將打包的Docker鏡像上傳至私有鏡像倉庫
- docker-push:
- stage: push
- script:
- #對打包的鏡像進行tag
- - docker tag $DOCKER_REPO_URL/$CI_PROJECT_PATH $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
- #登錄私有鏡像倉庫
- - docker login $DOCKER_REPO_URL -u $DOCKER_REPO_USERNAME -p $DOCKER_REPO_PASSWORD
- #上傳應用鏡像至鏡像倉庫
- - docker push $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
- - docker rmi $DOCKER_REPO_URL/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME:${CI_COMMIT_SHA:0:8}
- - docker rmi $DOCKER_REPO_URL/$CI_PROJECT_PATH
- #將應用發布至Kubernetes測試集群（這里指定為手動確認方式）
- deploy-test:
- stage: deploy
- when: manual
- script:
- - kubectl config use-context kubernetes-admin@kubernetes
- - sed -e "s/__REPLICAS__/1/; s/__PORT__/$PORT/; s/__APP_NAME__/$CI_PROJECT_NAME/; s/__PROFILE__/test/; s/__IMAGE__/$DOCKER_REPO_URL\/${CI_PROJECT_PATH//\//\\/}\/${CI_BUILD_REF_NAME//\//\\/}:${CI_COMMIT_SHA:0:8}/" kubernetes/deploy.yaml | kubectl -n ${K8S_NAMESPACE} apply -f -
如上所述，我們在“.gitlab-ci.yml”文件中定義了”test、build、push、deploy”這4個stages階段。這幾個stages的具體說明如下：
- test：執行單元測試代碼;
- build：執行構建打包指令，將應用構建打包為Docker鏡像;
- push：該階段主要是將build構建的本地Docker鏡像經過tag處理后上傳至Harbor鏡像倉庫，并在成功后清理掉本地鏡像文件;
- deploy：該階段主要是執行Kubernetes指令，根據Kubernetes發布部署文件的配置，將容器鏡像部署發布至Kubernetes集群;
在deploy階段，是將Docker鏡像發布運行至Kubernetes集群，其中涉及編寫Kubernetes部署發布yaml文件，具體示例如下：
- ---
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: __APP_NAME__
- spec:
- replicas: __REPLICAS__
- selector:
- matchLabels:
- app: __APP_NAME__
- strategy:
- type: RollingUpdate
- template:
- metadata:
- labels:
- app: __APP_NAME__
- spec:
- imagePullSecrets:
- - name: wudimanong-ecr
- containers:
- - name: __APP_NAME__
- image: __IMAGE__
- resources:
- requests:
- memory: "1000M"
- limits:
- memory: "1000M"
- volumeMounts:
- - name: time-zone
- mountPath: /etc/localtime
- - name: java-logs
- mountPath: /opt/logs
- ports:
- - containerPort: __PORT__
- env:
- - name: SPRING_PROFILES_ACTIVE
- value: __PROFILE__
- - name: JAVA_OPTS
- value: -Xms1G -Xmx1G -Dapp.home=/opt/
- volumes:
- - name: time-zone
- hostPath:
- path: /etc/localtime
- - name: java-logs
- hostPath:
- path: /data/app/deployment/logs
如果一切準備妥當，此時你向GitLab倉庫提交代碼將自動觸發構建Pipeline，而Pipeline將自動運行你在“.gitlab-ci.yml”文件中定義的具體CI/CD流水線邏輯，從而實現應用的自動化發布效果。
基于GitLab-CI機制的自動化發布系統由于其構建方式比較簡單，不需要太多的開發工作，因此目前不少創業公司中都采用了此類方案來實現微服務的自動化構建和交付。
以上就是本文所要表達的全部內容，希望能對你理解自動化發布系統的實現原理有所幫助!
