如何编写CI/CD流水线,在Google Kubernetes集群上运行Java微服务的集成测试?

huangapple go评论64阅读模式
英文:

How to write CI/CD pipeline to run integration testing of java micro services on Google kubernetes cluster?

问题

背景:
我在一个GKE集群中有8-9个基于Spring的私有ClusterIP微服务。所有的微服务都附带了集成测试。我正在使用Bitbucket,并使用Maven作为构建工具。

所有的微服务通过以下URL进行REST调用来相互通信:http://:8080/rest/api/fetch

需求: 我已经准备好了具有所有Docker镜像的测试环境,这些镜像位于GKE测试集群上。我希望一旦我将代码合并到service-A的主分支上,流水线就会部署镜像到测试环境并运行集成测试用例。如果测试用例通过,它应该部署到QA环境,否则回滚service-A的镜像到以前的版本。

问题: 在每次合并代码到主分支时,我能够运行service-A的JUNIT测试用例,构建其Docker镜像,将其推送到GCR并部署到测试环境集群。但在部署后如何触发集成测试用例,并在集成测试用例失败时回滚到以前部署的镜像?是否有任何方法?

TIA

英文:

Background:
I have 8-9 private clusterIP spring based microservices in a GKE cluster. All of the microservices are having integration tests bundled with them. I am using bitbucket and using maven as build tool.

All of the microservices are talking to each other via rest call with url: http://<service-name>:8080/rest/api/fetch

Requirement: I have testing enviroment ready with all the docker images up on GKE Test cluster. I want that as soon as I merge the code to master for service-A, pipeline should deploy image to tes-env and run integration test cases. If test cases passes, it should deploy to QA-environment, otherwise rollback the image of service-A back to previous one.

Issue: On every code merge to master, I am able to run JUNIT test cases of service-A, build its docker image, push it on GCR and deploy it on test-env cluster. But how can I trigger integration test cases after the deployment and rollback to previously deployed image back if integration test cases fails? Is there any way?

TIA

答案1

得分: 0

  1. 做这件事有许多方法。从上面的信息中并不清楚你正在使用哪个构建工具。

  2. 假设你正在使用Bamboo,你可以为此创建一个任务,并将其包含在SDLC流程中。大多数情况下,任务可以包含Bamboo脚本或Ansible脚本。

  3. 你也可以创建一个单独的Shell脚本,在部署后运行集成测试套件。

英文:

There are many ways you can do it. From the above information its not clear which build tool you are using.

  1. Lets say if you are using bamboo you can create a task for the same and include it in the SDLC process. Mostly the task can have bamboo script or ansible script.

  2. You could also create a separate shell script to run the integration test suite after deployment.

答案2

得分: 0

你应该检查一下Tekton提供的内容。
Tekton Pipelines项目提供了用于声明CI/CD风格流水线的k8s风格资源。

英文:

You should probably check what Tekton is offering.
The Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines.

答案3

得分: 0

你可以为每个部分创建不同的步骤:

pipelines(流水线):
branches(分支):
BRANCH_NAME(分支名称):
- 步骤(step):
脚本(script):
- 构建(BUILD)
- 步骤(step):
脚本(script):
- 部署(DEPLOY)
- 步骤(step):
脚本(script):
- 第一组 JUNIT 测试
- 步骤(step):
脚本(script):
- 运行集成测试(在这里,如果失败,可以添加回滚操作)
脚本(script):
- 上传到 QA

英文:
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

得分: 0

如果您使用Gitlab CICD,可以按照以下方式分解各个阶段:

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

在第一个阶段中,您应该编译代码,然后在下一个阶段中构建Docker镜像,然后拉取镜像并运行它们以进行所有测试(包括集成测试)。

以下是它将如何看起来的示例:

compile-stage:
  stage: compile
  script:
    - echo 'Compiling Application'
    # - bash my compile script
  # 编译产物可以在构建阶段中使用。
  artifacts:
    paths:
    - out/dist/dir
    expire_in: 1 week

build-stage:
  stage: build
  script:
    - docker build . -t "${CI_REGISTRY_IMAGE}:testversion" ## Dockerfile应该使用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

## 只有在构建通过了所有测试后,才会推送最新的镜像。
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

## 只有在通过了所有测试后,才会部署到暂存环境。
## CICD的概念通常是在部署到暂存环境之前,应进行所有自动化测试。暂存环境可用于用户验收和质量保证测试等。
deploy-staging:
  stage: review
  environment:
     name: review/$CI_COMMIT_REF_NAME
     url: https://$CI_ENVIRONMENT_SLUG.$KUBE_INGRESS_BASE_DOMAIN
     on_stop: stop_review
  only:
    - branches
  script:
     - kubectl apply -f deployments.yml

## 在有版本标签提交时,生产环境上的部署将是手动的。
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

希望以上片段能对您有所帮助。如果您想了解如何使用Gitlab CICD在GKE上部署微服务,请阅读此文章

英文:

If you use Gitlab CICD you can break the stages as follows:

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

where you should compile the code in the first stage, then build the docker images from it in the next and then pull images and run them to do all your tests (including the integration tests)

here is the mockup of how it will look like:

compile-stage:
  stage: compile
  script:
    - echo &#39;Compiling Application&#39;
    # - 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 &quot;${CI_REGISTRY_IMAGE}:testversion&quot; ## Dockerfile should make use of out/dist/dir
    - docker push &quot;${CI_REGISTRY_IMAGE}:testversion&quot;

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_COMMIT_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

I hope the above snippet will help you. If you want to learn more about deploying microservices using gitlab cicd on GKE read this

huangapple
  • 本文由 发表于 2020年1月6日 20:54:30
  • 转载请务必保留本文链接:https://go.coder-hub.com/59612496.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定