Управление многопостовыми интеграционными тестами с kubernetes и jenkins

Question

Я пытаюсь настроить среду тестирования для моего кластера kubernetes, используя jenkins и плагин jenkins kubernetes .

Я могу заставить jenkins подготовить модули и запустить базовые модульные тесты, ночто менее ясно, так это то, как я могу запускать тесты, которые включают координацию между несколькими модулями.

По сути, я хочу сделать что-то вроде этого:

podTemplate(label: 'pod 1', containers: [ containerTemplate(...)]) {
    node('pod1') {
        container('container1') {
            // start service 1
        }
    }
}
podTemplate(label: 'pod 2', containers[ containerTemplate(...)]) {
    node('pod2') {
        container('container2') {
            // start service 2
        }
}
stage ('Run test') {
    node {
        sh 'run something that causes service 1 to query service 2'
    }
}

У меня есть две основные проблемы:

1. Жизненный цикл стручка: как только блок после удаления шаблонной пластины удаляется, стручки завершаются.Есть ли общепринятый способ поддерживать работу модулей до тех пор, пока не будет выполнено определенное условие?

2. ContainerTemplate из образа докера: я использую образ докера для обеспечения контейнеров внутри каждого из модулей kubernetes,однако файлы, которые должны быть внутри этих образов, не кажутся видимыми / доступными внутри блоков «контейнера», даже если установленные среды и зависимости являются правильными для репозитория.Как мне на самом деле заставить службу, определенную в образе докера, работать в модуле, подготовленном jenkins?

Answer 1

Прошло некоторое время с тех пор, как я задал этот вопрос, и в то же время я узнал некоторые вещи, которые позволяют мне выполнить то, что я просил, хотя, возможно, не так аккуратно, как мне бы хотелось.

Решением для мультисервисных тестов стало простое использование шаблона pod с облачной библиотекой Google и назначение этому работнику учетных данных учетной записи службы и секретного ключа, чтобы он мог kubectl командыв кластере.

Dockerfile для работника, замените "X" на желаемую версию:

FROM google/cloud-sdk:alpine

// Install some utility functions.
RUN apk add --no-cache \
  git \
  curl \
  bash \
  openssl

// Used to install a custom version of kubectl
RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/vX.XX.X/bin/linux/amd64/kubectl &&\
  chmod +x ./kubectl &&\
  mv ./kubectl /usr/local/bin/kubectl

// Helm to manage deployments.
RUN curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh &&\
  chmod 700 get_helm.sh && ./get_helm.sh --version vX.XX.X

Затем в Groovy конвейере:

pipeline {
  agent {
    kubernetes {
      label 'kubectl_helm'
      defaultContainer 'jnlp'
      serviceAccount 'helm'
      yaml """
apiVersion: v1
kind: Pod
spec:
containers:
- name: gcloud
  image: your-docker-repo-here
  command:
  - cat
  tty: true
"""
    }
  }
  environment {
      GOOGLE_APPLICATION_CREDENTIALS = credentials('google-creds')
  }
  stages {
    stage('Do something') {
      steps {
        container('gcloud') {
          sh 'kubectl apply -f somefile.yaml'
          sh 'helm install something somerepo/somechart'
        }
      }
    }
 }

Теперь, когда яможет получить доступ к командам helm и kubectl, я могу вызывать модули или службы по желанию.Это по-прежнему не решает проблему возможности использовать их внутренний «контекст» для доступа к файлам, но, по крайней мере, дает мне возможность запускать интеграционные тесты.

ПРИМЕЧАНИЕ. Для правильной работы вам потребуется учетная запись службы, имя которой вы используете в качестве имени учетной записи службы, и учетные данные, хранящиеся в хранилище учетных данных jenkins.Чтобы команды helm работали, вам нужно убедиться, что Tiller установлен в вашем кластере kubernetes.Кроме того, не меняйте имя ключа env с GOOGLE_APPLICATION_CREDENTIALS, так как инструменты gsutils будут искать эту переменную окружения.