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源创计划”，欢迎正在阅读的你也加入，一块儿分享。