Kubernetes微服務自動化發(fā)布系統(tǒng)
本文轉載自微信公眾號「 無敵碼農」，作者 無敵碼農 。轉載本文請聯系 無敵碼農公眾號。
原文鏈接： https://mp.weixin.qq.com/s/WPwoRi240rKaWeIs0yNZ2g
實施微服務架構后，原先單一的系統(tǒng)結構統(tǒng)變成了數量眾多的微服務應用，開發(fā)、測試、運維部署等都會面臨不少挑戰(zhàn)。在微服務架構下如何提高工程研發(fā)效率，確保開發(fā)、測試、運維部署等流程上的順暢，是微服務技術體系能夠真正落地產生效益的關鍵。
要實現上述目標就需要基于DevOps(開發(fā)運維)思想構建一套高度自動化的發(fā)布系統(tǒng)，在該系統(tǒng)中開發(fā)人員可以隨時隨地構建代碼并將其發(fā)布至指定的運行環(huán)境中，這個過程也就是我們通常所說的CI/CD(持續(xù)集成/持續(xù)交付)流程。
關于DevOps的具體實踐，不同的公司一般會根據自身的發(fā)展階段和實際需要來選擇具體落地的方案。具備條件的公司可以研發(fā)功能豐富的可視化發(fā)布系統(tǒng)，而條件有限的創(chuàng)業(yè)公司則可以通過開源或現有的技術組件(如GitLab、Jenkins等)來實現操作相對簡陋但功能完備的自動化發(fā)布系統(tǒng)。
在本篇文章中我將以Spring Cloud微服務技術體系為背景，通過GitLab自帶的CI/CD機制并基于Kubernetes容器化技術來實現一套具備相對完整CI/CD流程的自動化發(fā)布系統(tǒng)。
CI/CD流程概述
實際上DevOps并不是微服務架構流行之后才產生的概念，而是業(yè)界在多年軟件開發(fā)實踐中積累的理論、工具的集合。本文所要討論的自動化發(fā)布系統(tǒng)實際上是要通過搭建CI/CD流水線來建立一套應用程序構建、測試、打包及發(fā)布的高效自動化方法。關于CI(持續(xù)集成)/CD(持續(xù)交付)的概念并不是指某一種具體的技術，而是一種軟件工程文化加一系列操作原則和具體實踐的集合。
其中CI(持續(xù)集成)的主要目標是通過建立一致的自動化構建方法來打包程序代碼，使得團隊成員能夠以更頻繁地動作提交代碼、更早地進行代碼集成，以及時發(fā)現和解決代碼中的問題、提高協(xié)作開發(fā)效率及軟件交付質量?？沙掷m(xù)集成(CI)的基本流程如圖所示：
從實現流程上來說CI的主要過程就是將開發(fā)人員提交的代碼以高度自動化的方式打包成可以在具體基礎架構環(huán)境運行的程序包(例如Docker鏡像)。而這個過程可以由一組工具如GitLab Runner(CI Pipeline)、Sonar(代碼檢測工具)等去完成，具體構建CI流程時根據實際需要集成運用即可。
持續(xù)交付(CD)的主要邏輯則是將CI流程中構建的程序鏡像從鏡像倉庫自動發(fā)布到具體的基礎架構環(huán)境(如測試/生產Kubernetes集群)，實現CD的工具主要有GitLab Runner(CD Pipeline)、Helm(Kubernetes軟件包管理工具)等。
實際上CD的核心就是通過輸入的各種用戶參數(如yaml文件、環(huán)境配置參數等)最終自動生成具體的發(fā)布指令(如Helm指令)，并根據參數中設置的相應信息來配置程序的具體運行環(huán)境?？沙掷m(xù)交付(CD)的基本運行流程如下圖所示：
以上就是CI/CD的基本概念及流程，也是自動化發(fā)布系統(tǒng)的實現的依據。在后面的內容中將主要圍繞這兩個階段來實現自動化發(fā)布系統(tǒng)的基本流程邏輯。
系統(tǒng)的基本組成
本文所要描述的自動化發(fā)布系統(tǒng)主要是利用GitLab提供的GitLab CI機制，實現當代碼發(fā)生提交或合并等事件時自動觸發(fā)預設的CI/CD流程。其中CI流程主要包括基本的代碼編譯、構建、打包等階段，并在完成上述步驟后將打包好的應用Docker鏡像發(fā)布至鏡像倉庫。
而CD階段則是從鏡像倉庫拉取應用Docker鏡像，并根據設置的CD流程將應用發(fā)布至指定的Kubernetes集群。具體系統(tǒng)結構如下圖所示：
如上圖所示，該自動化發(fā)布系統(tǒng)主要由GitLab、Harbor鏡像倉庫及Kubernetes集群組成。其中GitLab主要承擔代碼版本的管理，以及CI/CD流程定義和觸發(fā)， Harbor負責應用Docker鏡像的存儲和分發(fā)，而Kubernetes集群則是應用容器運行的基礎架構環(huán)境。
GitLab-CI自動化發(fā)布系統(tǒng)的關鍵實現
前面我們描述了基于GitLab-CI機制實現自動化發(fā)布系統(tǒng)的基本組成，要具體實現這套系統(tǒng)你需要安裝部署GitLab服務器并配置GItLab Runner功能，私有鏡像倉庫服務(Harbor或JFrog)以及Kubernetes集群(具體可參見本專欄的其他文章)。
由于GitLab服務器是CI/CD流程執(zhí)行的主要承載點，如果你的服務是基于Maven構建的Java服務，那么還需要在GitLab服務器中安裝Maven客戶端，并配置Maven私服的地址，以提高構建速度。此外GitLab服務器在CI/CD流程執(zhí)行中還會運行Docker鏡像打包構建，將鏡像push到Docker鏡像倉庫以及將Docker鏡像從私有倉庫發(fā)布至Kubernetes集群等邏輯，所以GitLab服務器還需要安裝Docker環(huán)境及kubelet客戶端。
如果環(huán)境都OK，那么我們就可以在Gitlab項目根目錄代碼中創(chuàng)建“.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，示例如下：
- #環(huán)境參數信息
- 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
- #執(zhí)行單元測試階段
- 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
- #將應用發(fā)布至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：執(zhí)行單元測試代碼;
- build：執(zhí)行構建打包指令，將應用構建打包為Docker鏡像;
- push：該階段主要是將build構建的本地Docker鏡像經過tag處理后上傳至Harbor鏡像倉庫，并在成功后清理掉本地鏡像文件;
- deploy：該階段主要是執(zhí)行Kubernetes指令，根據Kubernetes發(fā)布部署文件的配置，將容器鏡像部署發(fā)布至Kubernetes集群;
在deploy階段，是將Docker鏡像發(fā)布運行至Kubernetes集群，其中涉及編寫Kubernetes部署發(fā)布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倉庫提交代碼將自動觸發(fā)構建Pipeline，而Pipeline將自動運行你在“.gitlab-ci.yml”文件中定義的具體CI/CD流水線邏輯，從而實現應用的自動化發(fā)布效果。
基于GitLab-CI機制的自動化發(fā)布系統(tǒng)由于其構建方式比較簡單，不需要太多的開發(fā)工作，因此目前不少創(chuàng)業(yè)公司中都采用了此類方案來實現微服務的自動化構建和交付。
以上就是本文所要表達的全部內容，希望能對你理解自動化發(fā)布系統(tǒng)的實現原理有所幫助!
