Kubernetes微服務自動化發佈系統

實施微服務架構後，原先單一的系統結構統變成了數量衆多的微服務應用，開發、測試、運維部署等都會面臨很多挑戰。在微服務架構下如何提升工程研發效率，確保開發、測試、運維部署等流程上的順暢，是微服務技術體系可以真正落地產生效益的關鍵。
java

要實現上述目標就須要基於DevOps（開發運維）思想構建一套高度自動化的發佈系統，在該系統中開發人員能夠隨時隨地構建代碼並將其發佈至指定的運行環境中，這個過程也就是咱們一般所說的CI/CD（持續集成/持續交付）流程。
git

關於DevOps的具體實踐，不一樣的公司通常會根據自身的發展階段和實際須要來選擇具體落地的方案。具有條件的公司能夠研發功能豐富的可視化發佈系統，而條件有限的創業公司則能夠經過開源或現有的技術組件（如GitLab、Jenkins等）來實現操做相對簡陋但功能完備的自動化發佈系統。
web

在本篇文章中我將以Spring Cloud微服務技術體系爲背景，經過GitLab自帶的CI/CD機制並基於Kubernetes容器化技術來實現一套具有相對完整CI/CD流程的自動化發佈系統。spring

CI/CD流程概述
docker

實際上DevOps並非微服務架構流行以後才產生的概念，而是業界在多年軟件開發實踐中積累的理論、工具的集合。本文所要討論的自動化發佈系統其實是要經過搭建CI/CD流水線來創建一套應用程序構建、測試、打包及發佈的高效自動化方法。關於CI(持續集成)/CD（持續交付）的概念並非指某一種具體的技術，而是一種軟件工程文化加一系列操做原則和具體實踐的集合。
api

其中CI（持續集成）的主要目標是經過創建一致的自動化構建方法來打包程序代碼，使得團隊成員可以以更頻繁地動做提交代碼、更早地進行代碼集成，以及時發現和解決代碼中的問題、提升協做開發效率及軟件交付質量。可持續集成（CI）的基本流程如圖所示：
服務器

從實現流程上來講CI的主要過程就是將開發人員提交的代碼以高度自動化的方式打包成能夠在具體基礎架構環境運行的程序包（例如Docker鏡像）。而這個過程能夠由一組工具如GitLab Runner（CI Pipeline）、Sonar（代碼檢測工具）等去完成，具體構建CI流程時根據實際須要集成運用便可。微信

持續交付（CD）的主要邏輯則是將CI流程中構建的程序鏡像從鏡像倉庫自動發佈到具體的基礎架構環境（如測試/生產Kubernetes集羣），實現CD的工具主要有GitLab Runner（CD Pipeline）、Helm（Kubernetes軟件包管理工具）等。
架構

實際上CD的核心就是經過輸入的各類用戶參數（如yaml文件、環境配置參數等）最終自動生成具體的發佈指令（如Helm指令），並根據參數中設置的相應信息來配置程序的具體運行環境。可持續交付（CD）的基本運行流程以下圖所示：
app

以上就是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鏡像的具體構建方式，是經過在<configuration>標籤中指定Dockerfile文件來實現的。具體可在項目工程中建立docker目錄，並建立Dockerfile文件，內容以下：

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機制的自動化發佈系統因爲其構建方式比較簡單，不須要太多的開發工做，所以目前很多創業公司中都採用了此類方案來實現微服務的自動化構建和交付。

以上就是本文所要表達的所有內容，但願能對你理解自動化發佈系統的實現原理有所幫助！

—————END—————

本文分享自微信公衆號 - 無敵碼農（jiangqiaodege）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。