时间戳

首页 > 解决方案 > 如何编写 CI/CD 管道在 Google Kubernetes 集群上运行 Java 微服务的集成测试？

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

问题描述

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

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

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

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

TIA

标签： kubernetesgoogle-cloud-platformgoogle-kubernetes-enginebitbucket-pipelinesgoogle-cloud-build

解决方案

如果您使用 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

我希望上面的片段能帮助你。如果您想了解有关在 GKE 上使用 gitlab cicd 部署微服务的更多信息，请阅读此

推荐阅读