Супер странное поведение Helm/Jenkins/Artifactory YAML

Используя 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
                }
            }
        }
    }
}

Не показан конвейер параллельной обработки, в котором будет использоваться несколько контейнеров.

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

Iterokun 16.07.2024 08:52

Если изображения находятся в ourartifacts.jfrog.io, я бы предположил, что k8s не может их извлечь, поскольку нет учетных данных для доступа к этому частному репозиторию. Я бы посоветовал создать его и добавить imagePullSecrets в раздел вашего модуля .spec.

Michał Lewndowski 16.07.2024 09:59

Есть ли что-то в коде конвейера Jenkins, что может быть причиной этого? Я считаю необычным запускать несколько контейнеров в одном модуле, и вам не нужно запускать контейнер, который ничего не делает.

David Maze 16.07.2024 12:39

@Iterokun, мы не можем сделать ничего лучше, чем вырезать и вставить сюда, нет возможности прикрепить файл. YAML был тщательно проверен с помощью нескольких инструментов.

Jay Blanchard 16.07.2024 14:11

@MichałLewndowski, пожалуйста, вернитесь и прочитайте — в большинстве случаев учетные данные правильно работают с полученными изображениями. Проблема заключается в добавлении/удалении определений изображений в один файл YAML, что затем приводит к тому, что изображения отображаются с ошибкой. Я понимаю, что указанная ошибка, скорее всего, не соответствует фактической ошибке.

Jay Blanchard 16.07.2024 14:13

@DavidMaze Я добавил к вопросу верхнюю часть кода конвейера. Вы правы, это необычно, но у нас есть два варианта использования, в которых разработчик/оператор хочет запускать контейнеры с разными определениями в одном модуле во время своих сборок. Я согласен, контейнеры должны что-то делать (и они в процессе разработки), но мы их настроили изначально в целях тестирования. Со временем определения будут уточняться.

Jay Blanchard 16.07.2024 14:17

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

Iterokun 16.07.2024 14:20
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
0
7
87
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Поскольку 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 использовал учетную запись службы по умолчанию, у которой не было доступа к некоторым ресурсам. (Это также подчеркнуло, что нам нужно определить, почему некоторые из них разрешены, но это уже другая история.) Добавление служебной учетной записи для этих вызовов решает проблему.

Другие вопросы по теме