secretEnvVar — значение из секрета в Kubernetes.

imagePullSecrets — список имён учётных данных для извлечения образов из частного Docker-реестра при использовании ссылки.

annotations — применяемые к модулю аннотации.

inheritFrom — один или несколько шаблонов модулей, от которых нужно наследовать (подробнее см. ниже).

slaveConnectTimeout — время ожидания запроса при подключении узла (в секундах) (подробнее см. ниже).

podRetention — определяет, будет ли сохранён модуль узла: «never()», «onFailure()», «always()» или «default()». Если оставить поле пустым, то по истечении времени, заданного параметром activeDeadlineSeconds, модуль будет удалён.

activeDeadlineSeconds — если podRetention установлен как «never()» или «onFailure()», то после истечения этого времени модуль будет удалён.

idleMinutes — позволяет модулю оставаться активным до повторного использования в течение указанного количества минут после последнего выполнения.

Контейнерный шаблон добавляется в модуль. Его конфигурацию можно настроить через пользовательский интерфейс или конвейер. В неё входят:

• name — имя контейнера;
• image — образ контейнера;
• envVars — переменные среды, применяемые к контейнеру (дополняют переменные на уровне модуля и могут их перезаписывать);
• command — команда, которая будет выполнена при запуске контейнера;
• args — параметры, передаваемые команде запуска;
• ttyEnabled — флаг, указывающий, включён ли tty;
• livenessProbe — параметры проверки живучести контейнера (не поддерживает проверку httpGet);
• ports — порты, открытые в контейнере.

Указание разного времени ожидания подключения для узлов

По умолчанию время ожидания подключения узла составляет 100 секунд. При необходимости это значение можно изменить, установив системное свойство org.csanchez.jenkins.plugins.kubernetes.PodTemplate.connectionTimeout на другое значение. Подробнее о настройке системных свойств в Jenkins см. в разделе «Управление функциями с помощью системных свойств».

Использование yaml для определения шаблона модуля

Чтобы поддерживать все возможные значения объекта Pod в Kubernetes, можно передать фрагмент yaml в качестве основы шаблона. Свойства, заданные вне yaml, имеют более высокий приоритет.

def label = "mypod-${UUID.randomUUID().toString()}"
podTemplate(label: label, yaml: """
apiVersion: v1
kind: Pod
metadata:
  labels:
    some-label: some-label-value
spec:
  containers:
  - name: busybox
    image: busybox
    command:
    - cat
    tty: true
"""
) {
    node (label) {
      container('busybox') {
        sh "hostname"
      }
    }
}

Можно использовать шаги readFile или readTrusted для загрузки yaml из файла. Также доступ к нему возможен через интерфейс конфигурации плагина Jenkins.

Применение проверок живучести

containerTemplate(name: 'busybox', image: 'busybox', ttyEnabled: true, command: 'cat',
    livenessProbe: containerLivenessProbe( execArgs: 'some --command',
    initialDelaySeconds: 30, timeoutSeconds: 1, failureThreshold: 3, periodSeconds: 10, successThreshold: 1))

Подробнее о проверке живучести см. раздел «Определение команды проверки живучести».

Наследование шаблонов модулей

Шаблон модуля может наследоваться от существующего шаблона или не наследоваться. Это означает, что шаблон модуля унаследует селектор узла, служебную учётную запись, учётные данные для извлечения образа, контейнерный шаблон и том.

Yaml никогда не объединяется. Если он определён в дочернем шаблоне модуля, то родительский шаблон не используется.

Служебная учётная запись и селектор узла будут перекрывать значения родительского шаблона.

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

Механизм наследования томов такой же, как и у контейнерных шаблонов.

Учётные данные для извлечения образа — все учётные данные, определённые в родительских и текущих шаблонах, будут использоваться.

В следующем примере наследуется ранее созданный шаблон модуля и переопределяется только версия Maven:

podTemplate(label: 'anotherpod', inheritFrom: 'mypod',  containers: [
    containerTemplate(name: 'maven', image: 'maven:3.3.9-jdk-7-alpine')
  ]) {

      //Let's not repeat ourselves and ommit this part
}

Обратите внимание, что мы указываем только те части, которые хотим изменить. Поэтому нет необходимости указывать ttyEnabled и command, так как они будут унаследованы. Кроме того, поскольку в родительском шаблоне есть контейнер golang, он также будет добавлен.

Множественное наследование шаблонов модулей

Поле inheritFrom может ссылаться на один или несколько шаблонов, разделённых пробелами. Порядок обработки шаблонов соответствует порядку их появления (последующие шаблоны перекрывают предыдущие). Если указанный шаблон не найден, он будет проигнорирован.

Вложение шаблонов модулей

Функция inheritFrom предоставляет удобный способ объединения существующих шаблонов модулей. Во многих случаях прямое использование groovy для определения и объединения шаблонов модулей в конвейере может быть полезным. Вложение делает это возможным. Вы можете вложить несколько шаблонов модулей и объединить их в один.

Следующий пример объединяет два разных шаблона модулей, создавая шаблон с возможностями Maven и Docker:

podTemplate(label: 'docker', containers: [containerTemplate(image: 'docker', name: 'docker', command: 'cat', ttyEnabled: true)]) {
    podTemplate(label: 'maven', containers: [containerTemplate(image: 'maven', name: 'maven', command: 'cat', ttyEnabled: true)]) {
        // do stuff
    }
}

Эта функция очень полезна, и разработчики библиотек конвейеров могут обернуть шаблоны модулей в функции и позволить пользователям вызывать эти функции в соответствии со своими потребностями. ## Из рабочей области запустить конвейер или отдельный этап (stage) — если не указано иное, в этом нет необходимости.

pipeline {
  agent {
    kubernetes {
      label 'mypod'
      customWorkspace 'some/other/path'
      defaultContainer 'maven'
      yamlFile 'KubernetesPod.yaml'
    }
  }

  stages {
    stage('Запустить maven') {
      steps {
        sh 'mvn -version'
        sh "echo Workspace dir is ${pwd()}"
      }
    }
  }
}

Доступ к журналу контейнера из конвейера

Если вы используете containerTemplate для запуска некоторых служб в фоновом режиме (например, базы данных для интеграционного тестирования), вы можете захотеть получить доступ к их журналам из конвейера. Это можно сделать с помощью шага containerLog, который будет печатать журналы запрошенного контейнера в журнал сборки.

Необходимые параметры:

• Название — имя контейнера, чей журнал вы хотите получить, определённое в podTemplate. Для простоты использования можно опустить имя параметра:

containerLog 'mongodb'

Необязательные параметры:

• returnLog — возвращает вместо печати в журнал сборки (по умолчанию: false)
• tailingLines — возвращает только последние несколько строк журнала (необязательно)
• sinceSeconds — возвращает только журналы за последние несколько секунд (необязательно)
• limitBytes — ограничивает количество выводимых байтов (считая от начала журнала, неточно)

См. онлайн-справку и examples/containerLog.groovy.

Ограничения

В pod можно определить несколько контейнеров. Контейнер с именем jnlp создаётся автоматически и служит в качестве узла Jenkins JNLP, с параметрами ${computer.jnlpmac} ${computer.name}.

Другие контейнеры должны иметь постоянно работающий процесс, чтобы контейнер не завершал работу. Если команда по умолчанию или entrypoint завершается после выполнения, она должна использовать cat и ttyEnabled: true, чтобы переопределить поведение.

Предупреждение:

Если вам нужно предоставить собственный образ Docker для JNLP-узла, обязательно назовите контейнер jnlp, иначе он будет перекрыт по умолчанию. В противном случае это может привести к тому, что два узла одновременно подключатся к maser.

Переопределение предопределённых параметров

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

Если вы хотите переопределить это поведение и немедленно запускать исполнителя для каждой задачи в очереди без ожидания, вы можете использовать эти флаги при запуске Jenkins:

-Dhudson.slaves.NodeProvisioner.initialDelay=0
-Dhudson.slaves.NodeProvisioner.MARGIN=50
-Dhudson.slaves.NodeProvisioner.MARGIN0=0.85

Настройка на minikube

Создайте и запустите minikube.

Сертификат клиента необходимо преобразовать в PKCS и защитить паролем:

openssl pkcs12 -export -out ~/.minikube/minikube.pfx -inkey ~/.minikube/apiserver.key -in ~/.minikube/apiserver.crt -certfile ~/.minikube/ca.crt -passout pass:secret

Затем проверьте доступность сертификата:

curl --cacert ~/.minikube/ca.crt --cert ~/.minikube/minikube.pfx:secret --cert-type P12 https://$(minikube ip):8443

Добавьте сертификат типа в учётные данные Jenkins, загрузив его из ~/.minikube/minikube.pfx с паролем secret:

Используйте содержимое файла ~/.minikube/ca.crt в качестве ключа сертификата службы Kubernetes.

Настроить в Google Container Engine

Создать кластер:

`gcloud container clusters create jenkins --num-nodes 1 --machine-type g1-small`

Запишите пароль администратора и сертификат службы.

Или просто используйте консоль разработчика Google для создания кластера контейнеров, а затем выполните следующую команду:

gcloud container clusters get-credentials jenkins
kubectl config view --raw

Последняя команда выведет конфигурацию кластера Kubernetes, включая адрес API службы, пароль администратора и корневой сертификат.

Отладка

Сначала убедитесь, что вы находитесь в правильном кластере и пространстве имён, и наблюдайте за запуском узлов Jenkins.

kubectl get -a pods --watch

Если их состояние не Running, используйте describe для получения информации о событиях:

kubectl describe pods/my-jenkins-agent

Если они находятся в состоянии Running, используйте logs для просмотра вывода журнала:

kubectl logs -f pods/my-jenkins-agent jnlp

Если pod ещё не запущен или нет других ошибок, проверьте журнал master.

Для получения более подробной информации настройте новый журнал регистрации Jenkins, установив уровень org.csanchez.jenkins.plugins.kubernetes на ALL.

Чтобы проверить данные JSON, отправленные в службу Kubernetes API, вы можете настроить новый журнал регистрации Jenkins, установив уровень okhttp3 на ALL.

Удалить pod с ошибочным состоянием

kubectl get pods -o name --selector=jenkins=slave --all-namespaces  | xargs -I {} kubectl delete {}

Сборка и тестирование

Интеграционные тесты будут использовать конфигурацию, автоматически обнаруженную из kube config файла или service account.

Ручное тестирование

Запустите mvn clean install и скопируйте target/kubernetes.hpi в каталог плагинов Jenkins.

Запуск интеграционных тестов в Kubernetes

Обратите внимание, что система, на которой вы запускаете mvn, должна иметь возможность доступа к кластеру. Если вы видите, что узел подключился к неправильному хосту, вы можете заменить его на указанный jenkins.host.address.

Запуск в Minikube для интеграционных тестов

Для интеграционных тестов необходимо установить и запустить minikube. Тестовая программа обнаружит и запустит её в новом пространстве имён.

Некоторые интеграционные тесты запускают локальный Jenkins, поэтому хост, на котором вы работаете, должен иметь доступ к кластеру Kubernetes. По умолчанию, из соображений безопасности, Jenkins прослушивает только 192.168.64.1. Если ваш minikube не работает в этой сети, вы можете передать параметр connectorHost в maven.

mvn clean install IP соединяется через внутреннюю сеть. В данном примере это `http://10.175.244.232`.

Для тестирования установите разумное значение в поле Container Cap, например, 3.

Добавьте образ следующим образом:

• Образ Docker: jenkins/jnlp-slave
• Корневой каталог узла Jenkins: /home/jenkins

Теперь можно начинать использовать.

Чтобы остановить процесс, используйте команду: kubectl delete namespace/kubernetes-plugin

Пользовательское развёртывание

Изменение запросов или ограничений CPU и памяти (Kubernetes Resource API)

Измените файл ./src/main/kubernetes/jenkins.yml на необходимые ограничения:

resources:
      limits:
        cpu: 1
        memory: 1Gi
      requests:
        cpu: 0.5
        memory: 500Mi

Примечание: виртуальная машина будет использовать память requests как ограничение для кучи (-Xmx).

Сборка

docker build -t csanchez/jenkins-kubernetes .

Связанные проекты

• Kubernetes Pipeline plugin: расширение конвейера, которое предоставляет прямую поддержку для Kubernetes pods, secrets и томов в сборках.
• kubernetes-credentials: поставщик учётных данных, используемый для чтения секретов Kubernetes.