如何编写 CI/CD 管道在 Google Kubernetes 集群上运行 Java 微服务的集成测试？答案

【问题标题】：How to write CI/CD pipeline to run integration testing of java micro services on Google kubernetes cluster?如何编写 CI/CD 管道在 Google Kubernetes 集群上运行 Java 微服务的集成测试？
【发布时间】：2020-01-06 12:54:30
【问题描述】：

背景： 我在 GKE 集群中有 8-9 个私有 clusterIP 基于 spring 的微服务。所有微服务都捆绑了集成测试。我正在使用 bitbucket 并使用 maven 作为构建工具。

所有微服务都通过 url 的 rest 调用相互通信：http://:8080/rest/api/fetch

要求：我已经准备好测试环境，所有 docker 映像都已在 GKE 测试集群上。我希望一旦我将代码合并到服务 A 的 master 中，管道应该将图像部署到 tes-env 并运行集成测试用例。如果测试用例通过，则应部署到 QA 环境，否则将 service-A 的镜像回滚到之前的镜像。

问题：在每次代码合并到 master 时，我都能够运行 service-A 的 JUNIT 测试用例，构建其 docker 映像，将其推送到 GCR 并将其部署到 test-env 集群上。但是，如果集成测试用例失败，如何在部署后触发集成测试用例并回滚到先前部署的映像？有什么办法吗？

TIA

【问题讨论】：

标签： kubernetes google-cloud-platform google-kubernetes-engine bitbucket-pipelines google-cloud-build

【解决方案1】：

有很多方法可以做到这一点。从以上信息中不清楚您使用的是哪个构建工具。

假设您使用的是竹子，您可以为其创建一个任务并将其包含在 SDLC 流程中。大多数任务可以有竹脚本或ansible脚本。
您还可以创建一个单独的 shell 脚本来在部署后运行集成测试套件。

【讨论】：

我们正在使用 maven 构建

【解决方案2】：

您应该检查一下Tekton 提供的内容。 Tekton Pipelines 项目为声明 CI/CD 风格的管道提供了 k8s 风格的资源。

【讨论】：

【解决方案3】：

You can create different steps for each part:

pipelines:
  branches:
    BRANCH_NAME:
    - step:
        script: 
          - BUILD
    - step:
        script: 
          - DEPLOY
    - step:
        script: 
          - First set of JUNIT test
    - step:
        script:
          - Run Integration Tests (Here you can add if you fail to do rollback)
        script:
          - Upload to QA

【讨论】：

【解决方案4】：

如果你使用 Gitlab CICD，你可以按如下方式打破阶段：

stages:
 - compile
 - build
 - test
 - push
 - review
 - deploy

你应该在第一阶段编译代码，然后在下一个阶段从中构建 docker 镜像，然后拉取镜像并运行它们以完成所有测试（包括集成测试）

这是它的外观模型：

compile-stage:
  stage: compile
  script:
    - echo 'Compiling Application'
    # - bash my compile script
  # Compile artifacts can be used in the build stage.
  artifacts:
    paths:
    - out/dist/dir
    expire_in: 1 week

build-stage:
  stage: build
  script:
    - docker build . -t "${CI_REGISTRY_IMAGE}:testversion" ## Dockerfile should make use of out/dist/dir
    - docker push "${CI_REGISTRY_IMAGE}:testversion"

test-stage1:
   stage: test
   script:
     - docker run -it ${CI_REGISTRY_IMAGE}:testversion bash unit_test.sh

test-stage2:
   stage: test
   script:
     - docker run -d ${CI_REGISTRY_IMAGE}:testversion
     - ./integeration_test.sh

## You will only push the latest image if the build will pass all the tests.
push-stage:
   stage: push
   script:
     - docker pull ${CI_REGISTRY_IMAGE}:testversion
     - docker tag ${CI_REGISTRY_IMAGE}:testversion -t ${CI_REGISTRY_IMAGE}:latest
     - docker push ${CI_REGISTRY_IMAGE}:latest

## An app will be deployed on staging if it has passed all the tests.
## The concept of CICD is generally that you should do all the automated tests before even deploying on staging. Staging can be used for User Acceptance and Quality Assurance Tests etc.
deploy-staging:
  stage: review
  environment:
     name: review/$CI_BUILD_REF_NAME
     url: https://$CI_ENVIRONMENT_SLUG.$KUBE_INGRESS_BASE_DOMAIN
     on_stop: stop_review
  only:
    - branches
  script:
     - kubectl apply -f deployments.yml

## The Deployment on production environment will be manual and only when there is a version tag committed.
deploy-production:
  stage: deploy
  environment:
     name: prod
     url: https://$CI_ENVIRONMENT_SLUG.$KUBE_INGRESS_BASE_DOMAIN
  only:
    - tags
  script:
     - kubectl apply -f deployments.yml
  when:
   - manual

希望上面的sn-p对你有帮助。如果你想了解更多关于使用gitlab cicd on GKE read this部署微服务的信息

【讨论】：