Дженкинс Кубе агент не может вытащить из мерзавца - PullRequest
0 голосов
/ 21 июня 2019

Я запускаю Jenkins в Kubernetes (EKS) и могу успешно извлекать git-репозитории при запуске заданий на главном сервере Jenkins с конвейерным кодом

gitInfo = checkout([$class: 'GitSCM',
                branches: [[name: '*/master']],
                doGenerateSubmoduleConfigurations: false,
                extensions: [[$class: 'CleanCheckout'], [$class: 'RelativeTargetDirectory', relativeTargetDir: 'config']],
                submoduleCfg: [],
                userRemoteConfigs: [[credentialsId: 'Gitlab', url: 'git@gitlab.test.com:USER/config.git']]
            ])

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

using credential Gitlab
Cloning the remote Git repository
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress git@gitlab.test.com:USER/config.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: Warning: Permanently added 'gitlab.test.com,11.11.111.11' (ECDSA) to the list of known hosts.
  Authorized uses only. All activity may be monitored and reported.
  Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
  fatal: Could not read from remote repository.

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

using GIT_SSH to set credentials Git Lab key used to bootstrap Jenkins Master

Кто-нибудь видел эту проблему раньше?

Моя спецификация контейнера

spec:
containers:
- name: jnlp
  image: jenkins/jnlp-slave
  imagePullPolicy: Always
  env:
  - name: POD_IP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP
  - name: DOCKER_HOST
    value: tcp://localhost:2375

Обновление: Похоже, что-то удаляет символы новой строки с конца ключа id_rsa в хранилище учетных данных. Я использую Jenkins Config в качестве кода, чтобы добавить его из хранилища параметров AWS, поэтому я думаю, что здесь что-то идет не так, как если бы я выгружал содержимое секрета из хранилища параметров и копировал и вставлял его в учетные данные через пользовательский интерфейс Jenkins. работа работает ....

1 Ответ

0 голосов
/ 21 июня 2019

Проблема была вызвана тем, что JCasC не смог получить параметры от AWS, поэтому учетные данные Jenkins были повреждены (пусто).

Отладка выполняется путем запуска cat на credentials.xml и расшифровки учетных данных в консоли сценария

println(hudson.util.Secret.decrypt("{XXXXXXXX}"))

Я понятия не имею, как мастер может клонировать из Git с пустыми учетными данными, но даже в интерфейсе он показывался как действительный: /

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...