GitLab CI войти в частное репо без DinD - PullRequest
1 голос
/ 13 января 2020

Я новичок в GitLab и не уверен, что это возможно, у меня есть локальная установка и работа с GitLab, а также частное репозиторий Artifactory.

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

Но я слышал, что это можно сделать без DinD, чтобы сократить время выполнения. И необходимое изображение вытягивается в начале этапа.

Вместо этого:

image: docker:latest

services:
  - docker:18.09.8-dind

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_HOST: tcp://localhost:2375 

stages:
  - run_script

run_script:
  stage:
    run_script
  script:
    - docker login -u $DOCKER_TECHNICAL_USER -p $DOCKER_TECHNICAL_USER_PASSWORD $DOCKER_REGISTRY_URL
    - docker pull artifactory.example.com:5000/repo/powershell-core:6.3
    - docker run -it artifactory.example.com:5000/repo/powershell-core:6.3 pwsh -command "get-process"

Я хочу сделать это следующим образом (целый yml):

stages:
  - run_script

run_script:
  before_script:
    - docker login -u $DOCKER_TECHNICAL_USER -p $DOCKER_TECHNICAL_USER_PASSWORD $DOCKER_REGISTRY_URL
  image: artifactory.example.com:5000/repo/powershell-core:6.3
  stage:
    run_script
  script:
    - pwsh -command "get-process"

Если я попробую это, он скажет, что не может аутентифицироваться:

ERROR: Job failed: image pull failed: rpc error: code = Unknown desc = Get https://artifactory.example.com:5000/v2/repo/powershell-core/manifests/6.3: unknown: Authentication is required

Это невозможно или у меня где-то есть ошибка, и она исправима?

1 Ответ

2 голосов
/ 13 января 2020

Ваша проблема

Ваш CI не работает, потому что он не знает учетные данные для artifactory.example.com при загрузке базового образа artifactory.example.com:5000/repo/powershell-core:6.3. Чтобы вы поняли, я объясню различные шаги 2-х КИ, которые вы дали, а затем я дам треки для решения.

Первый КИ (DinD)

В вашем первом КИ (тот, который использует DinD), что происходит:

  • Исполнитель Gitlab-runner загружает образ docker:18.09.8-dind, а затем запускает образ как сервис для вашего CI
  • . Gitlab-runner executor загружает базовый образ docker:latest и затем использует его для выполнения вашей работы run_script
  • В вашем docker docker:latest журнале задания run_script в вашем личном хранилище с вашими учетными данными и через службу DinD
  • Затем он загружает ваше изображение artifactory.example.com:5000/repo/powershell-core:6.3 и запускает скрипт, используя его, через службу DinD

Второй CI

В этом примере вы пытаетесь просто выполнить ваше изображение artifactory.example.com:5000/repo/powershell-core:6.3 и запустить скрипт с его использованием. Вы правы, для такой простой цели, как эта, DinD не нужен. Вот анализ того, что делает ваш CI:

  • Исполнитель Gitlab-runner пытается загрузить базовое изображение , указанное в задании run_script: artifactory.example.com:5000/repo/powershell-core:6.3
  • Репозиторий artifactory.example.com запрашивать учетные данные
  • Исполнитель не знает учетных данных, поэтому возвращает ошибку и останавливается

Как вы можете видеть, в этом В этом случае задание run_script никогда не выполнялось, поскольку исполнителю не удалось загрузить базовый образ , указанный заданием. Часть задания before_script, которая отвечает за вход в систему, также не выполняется, потому что before_script выполняется в базовом образе , и этот последний не мог быть загружен исполнителем.

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

Решение

Так что вы ищете способ дать учетные данные для вашего хранилища artifactory.example.com для исполнителя Gilab-runner, который ваша работа использует. К сожалению, не существует уникального способа сделать такую ​​вещь, потому что это зависит от исполнителя, которого вы используете. Поскольку вы не указали исполнителя в своем вопросе, я приведу решения, которые, на мой взгляд, являются наиболее используемыми и удобными для Docker и Kubernetes.

Использование DOCKER_AUTH_CONFIG

Одним из решений, которое работает с несколькими исполнителями, является определение (секретной) переменной непосредственно в Gitlab, как описано в этой документации Gitlab .

Здесь я представляю второй метод для подготовки ваших учетных данных , Адаптируйте следующее, чтобы создать свой собственный auth fied:

echo -n "USERNAME:PASSWORD" | base64
VVNFUk5BTUU6UEFTU1dPUkQ=

Затем создайте переменную DOCKER_AUTH_CONFIG в Gitlab со следующим контентом, который вы сначала адаптировали:

{
  "auths": {
    "artifactory.example.com:5000": {
      "auth": "VVNFUk5BTUU6UEFTU1dPUkQ="
    }
  }
}

Используя это метод, ваш CI просто становится:

stages:
  - run_script

run_script:
  image: artifactory.example.com:5000/repo/powershell-core:6.3
  stage:
    run_script
  script:
    - pwsh -command "get-process"

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

Kubernetes executor

Если вы используете Kubernetes executor, самое простое решение это создать секрет, содержащий учетные данные для вашего хранилища. Используя карту Хелма, этот секрет может быть передан во время установки карты с помощью ключа runners.imagePullSecrets, который описан в values.yaml графика . Это решение использует механизм Kubernetes для аутентификации в реестре, как описано в документации Kubernetes .

. Я приведу этот пример, чтобы проиллюстрировать тот факт, что для аутентификации бегуна в реестре используются механизмы, которые не зависят от самого бегуна. В данном случае это механизмы Кубернетеса. Поэтому для бегуна не существует уникального способа аутентификации.

...