Ваша проблема
Ваш 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 .
. Я приведу этот пример, чтобы проиллюстрировать тот факт, что для аутентификации бегуна в реестре используются механизмы, которые не зависят от самого бегуна. В данном случае это механизмы Кубернетеса. Поэтому для бегуна не существует уникального способа аутентификации.