Используя YAML (с Helm), мы создали следующий файл для определения контейнеров агентов. Этот файл в том виде, в котором он представлен ниже, работает правильно, как и другой файл с другим набором определений агентов.
apiVersion: v1
kind: Pod
metadata:
name: pod-yaml
spec:
containers:
- name: maven
image: maven:3.8.1-jdk-8
command:
- sleep
args:
- 99d
- name: python
image: python:latest
command:
- sleep
args:
- 99d
- name: node10jdk8
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node10_jdk8:v4
command:
- sleep
args:
- 99d
- name: node10jdk11
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node10_jdk11:v2
command:
- sleep
args:
- 99d
- name: node12jdk8
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node12_jdk8:v2
command:
- sleep
args:
- 99d
- name: node12jdk11
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node12_jdk11:v2
command:
- sleep
args:
- 99d
- name: node14jdk8
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node14_jdk8:v2
command:
- sleep
args:
- 99d
- name: node16jdk11
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node16_jdk11:v2
command:
- sleep
args:
- 99d
- name: node18jdk11
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node18_jdk11:v2
command:
- sleep
args:
- 99d
- name: node20jdk11
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node20_jdk11:v2
command:
- sleep
args:
- 99d
- name: jra-base
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_base:v3
command:
- sleep
args:
- 99d
У нас было определено еще несколько контейнеров, но при запуске конвейера Jenkins мы получали подобные ошибки:
14:26:47 Created Pod: kubernetes jenkins-dev/agents-jenkins-yaml-agents-test-128-tlk8h-tnw11-gf62j
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_base:v3". Check if image tag name is spelled correctly.
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node12_jdk11:v2". Check if image tag name is spelled correctly.
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node12_jdk8:v2". Check if image tag name is spelled correctly.
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node14_jdk8:v2". Check if image tag name is spelled correctly.
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node16_jdk11:v2". Check if image tag name is spelled correctly.
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node18_jdk11:v2". Check if image tag name is spelled correctly.
14:26:53 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node20_jdk11:v2". Check if image tag name is spelled correctly.
Я взял все проблемные образы контейнеров и поместил их в отдельный файл YAML, запустил тест, и тест сработал.
Тогда я решила добавить еще одно изображение, протестировать, вспенить, сполоснуть, повторить. Добавляю одно изображение:
- name: node16jdk17
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node16_jdk17:v2
command:
- sleep
args:
- 99d
И ошибка появилась снова, но не с добавленным новым определением контейнера. Я удалил это определение, и оно снова заработало идеально. Я решил попробовать другое изображение и добавил это:
- name: node14jdk11
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node14_jdk11:v2
command:
- sleep
args:
- 99d
И это не удалось, но на этот раз только новое изображение оказалось неудачным:
13:10:58 [Pipeline] node
13:11:08 Created Pod: kubernetes jenkins-dev/agents-jenkins-yaml-agents-test-125-93416-q6bzf-bqr63
13:11:12 ERROR: Unable to pull Docker image "ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node14_jdk11:v2". Check if image tag name is spelled correctly.
13:11:12 [Pipeline] // node
Что мне здесь не хватает? Насколько мне известно, файлы YAML не приближаются к ограничению по длине. Имена тегов изображений должны быть «написаны правильно», поскольку артефакты извлекаются, когда ни одно из этих дополнений не сделано. Я проверил и перепроверил синтаксис. В файле нет никаких странных символов.
Я упускаю что-то действительно очевидное?
Вот упрощенная версия конвейера, использующая определения модуля/контейнера:
@Library('SCMLibraries@jenkins-pod-tests')_ // Load External Libraries
def podDefs = libraryResource('./pod.yaml')
pipeline {
agent any
environment {
PATH = '/var/jenkins/.nvm/versions/node/v10.24.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin'
NVM_DIR = '/var/jenkins/.nvm'
NVM_INC = '/var/jenkins/.nvm/versions/node/v10.24.1/include/node'
NVM_CD_FLAGS = ''
NVM_BIN = '/var/jenkins/.nvm/versions/node/v10.24.1/bin'
}
stages {
stage('Setup the Build') {
agent {
kubernetes {
defaultContainer 'jnlp'
yaml podDefs
}
}
steps {
container('node10jdk8') {
// code goes here
}
}
}
}
}
Не показан конвейер параллельной обработки, в котором будет использоваться несколько контейнеров.
Если изображения находятся в ourartifacts.jfrog.io
, я бы предположил, что k8s
не может их извлечь, поскольку нет учетных данных для доступа к этому частному репозиторию. Я бы посоветовал создать его и добавить imagePullSecrets в раздел вашего модуля .spec
.
Есть ли что-то в коде конвейера Jenkins, что может быть причиной этого? Я считаю необычным запускать несколько контейнеров в одном модуле, и вам не нужно запускать контейнер, который ничего не делает.
@Iterokun, мы не можем сделать ничего лучше, чем вырезать и вставить сюда, нет возможности прикрепить файл. YAML был тщательно проверен с помощью нескольких инструментов.
@MichałLewndowski, пожалуйста, вернитесь и прочитайте — в большинстве случаев учетные данные правильно работают с полученными изображениями. Проблема заключается в добавлении/удалении определений изображений в один файл YAML, что затем приводит к тому, что изображения отображаются с ошибкой. Я понимаю, что указанная ошибка, скорее всего, не соответствует фактической ошибке.
@DavidMaze Я добавил к вопросу верхнюю часть кода конвейера. Вы правы, это необычно, но у нас есть два варианта использования, в которых разработчик/оператор хочет запускать контейнеры с разными определениями в одном модуле во время своих сборок. Я согласен, контейнеры должны что-то делать (и они в процессе разработки), но мы их настроили изначально в целях тестирования. Со временем определения будут уточняться.
@JayBlanchard сломать синтаксис yaml довольно сложно, но испортить вложенность очень легко. Поэтому, если эти инструменты линтинга не поддерживают схему, я бы не стал им слишком доверять. Извините, я хотел бы быть более полезным.
Поскольку pod.yaml вызывается как ресурс, он не наследует учетную запись службы, используемую для экземпляра Jenkins в Kubernetes. Мы создали отдельную учетную запись службы для модулей, а затем включили ее в файл YAML:
apiVersion: v1
kind: Pod
metadata:
name: pod-yaml
spec:
serviceAccountName: agent-pods
containers:
- name: maven
image: maven:3.8.1-jdk-8
command:
- sleep
args:
- 99d
- name: python
image: python:latest
command:
- sleep
args:
- 99d
- name: node10jdk8
image: ourartifacts.jfrog.io/docker-local/jenkins_remote_agent_node10_jdk8:v4
command:
- sleep
args:
- 99d
pod.yaml использовал учетную запись службы по умолчанию, у которой не было доступа к некоторым ресурсам. (Это также подчеркнуло, что нам нужно определить, почему некоторые из них разрешены, но это уже другая история.) Добавление служебной учетной записи для этих вызовов решает проблему.
Если бы мне пришлось угадывать, я бы сказал, что это проблема с пробелами, но подобные проблемы трудно устранить, не глядя на реальные файлы, а не на их скопированный/вставленный текст.