Как написать конвейер CI / CD для запуска интеграционного тестирования java микро сервисов в кластере Google kubernetes?

Question

Справочная информация: В кластере GKE у меня есть 8-9 частных кластеров. Все микросервисы поставляются вместе с интеграционными тестами. Я использую bitbucket и использую maven в качестве инструмента для сборки.

Все микроуслуги общаются друг с другом с помощью вызова rest с URL: http: //: 8080 / rest / api / fetch

Требование: У меня есть готовая среда тестирования со всеми образами docker в кластере GKE Test. Я хочу, чтобы после слияния кода с мастером для службы A конвейер должен был развернуть образ в tes-env и запустить интеграционные тесты. Если тестовые случаи пройдены, его следует развернуть в QA-среде, в противном случае откатить образ службы-A до предыдущего.

Проблема: При каждом слиянии кода с мастером я могу чтобы запустить тестовые примеры JUNIT для service-A, создайте его docker образ, pu sh в GCR и разверните его в кластере test-env. Но как я могу активировать интеграционные тесты после развертывания и выполнить откат к ранее развернутому образу обратно, если интеграционные тесты не пройдены? Там в любом случае?

TIA

Answer 1

Если вы используете 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

Я надеюсь, что приведенный выше фрагмент поможет вам , Если вы хотите узнать больше о развертывании микросервисов с использованием gitlab cicd на GKE, прочитайте это

Answer 2

Вы, вероятно, должны проверить, что предлагает Tekton . Проект Tekton Pipelines предоставляет ресурсы в стиле k8s для объявления конвейеров в стиле CI / CD.

Answer 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

Answer 4

Есть много способов сделать это. Из приведенной выше информации не ясно, какой инструмент сборки вы используете.

1. Допустим, если вы используете бамбук, вы можете создать для него задачу и включить ее в процесс SDL C. В основном задача может иметь бамбуковый скрипт или ansible скрипт.

2. Вы также можете создать отдельный скрипт оболочки для запуска комплекта интеграционных тестов после развертывания.