Гитлаб ки СШ входа в систему реестра

У меня есть проект GitLab gitlab.com/my-group/my-project, который имеет конвейер CI, который строит образ и отправляет его в реестр GitLab проекта registry.gitlab.com/my-group/my-project:tag. Я хочу развернуть этот образ в Google Compute Engine, где у меня есть виртуальная машина под управлением docker.

Достаточно легко сделать это вручную, введя ssh в виртуальную машину, затем docker login registry.gitlab.com и docker run ... registry.gitlab.com/my-group/my-project:tag. За исключением того, что команда docker login интерактивна, что является запретом для CI. Он может принимать имя пользователя и пароль в командной строке, но это вряд ли кажется правильным, даже если мои данные для входа находятся в секретной переменной (хранение моих учетных данных для входа в GitLab в секретной переменной GitLab?...)

Это предполагаемый рабочий процесс на этапе развертывания конвейера:

  1. либо установите инструмент gcloud, либо используйте образ с предустановленным инструментом
  2. gcloud compute ssh my-gce-vm-name --quiet --command "docker login registry.gitlab.com && docker run registry.gitlab.com/my-group/my-project:tag"

Поскольку команда gcloud будет выполняться в GitLab CI Runner, она Может иметь доступ к секретным переменным, но действительно ли это лучший способ войти в систему Реестр GitLab по ssh из GitLab ?

3 3
docker gitlab docker-registry gitlab-ci

3 ответа:

Я сам отвечу на свой вопрос, если кто-нибудь еще на него наткнется. GitLab создает эфемерные маркеры доступа для каждой сборки конвейера, которые предоставляют пользователю gitlab-ci-token доступ к реестру GitLab. Решение состояло в том, чтобы войти в систему как пользователь gitlab-ci-token в сборке.

.gitlab-ci.yml (выдержка): 

deploy:
  stage: deploy
  before_script:
    - gcloud compute ssh my-instance-name --command "docker login registry.gitlab.com/my-group/my-project -u gitlab-ci-token -p $CI_BUILD_TOKEN"
2

Команда docker login создает локальный конфигурационный файл, в котором ваши учетные данные хранятся в $HOME/.docker/config.json, который выглядит следующим образом (Также см. документацию по этому вопросу): 

{
    "auths": {
        "<registry-url>": {
            "auth": "<credentials>"
        }
    }
}

Пока файл config.json присутствует на вашем Хосте и ваши учетные данные (в данном случае просто хранятся как base64("<username>:<password>")) не изменяются, нет необходимости запускать docker login на каждой сборке или хранить ваши учетные данные в качестве переменных для вашего задания CI.

Мое предложение было бы просто гарантировать, что config.json файл присутствует на вашей целевой машине (либо запустив docker login один раз вручную, либо развернув файл с помощью любого инструмента управления конфигурацией, который вам нравится). Это избавит вас от необходимости обрабатывать логин и управлять учетными данными в конвейере сборки.

Что касается логина SSH как такового; это должно работать просто отлично. Если вы действительно хотите исключить SSH-логин, вы можете настроить Docker engine на вашей целевой машине для прослушивания внешнего сокета, настроить аутентификацию и шифрование с использованием клиентских сертификатов TLS, как описано в официальной документации, и прямой доступ к API Docker удаленного сервера из задания сборки: 

variables:
  DOCKER_HOST: "tcp://<target-server>:2376"
  DOCKER_TLS_VERIFY: "1"
script:
  - docker run registry.gitlab.com/my-group/my-project:tag
1

У нас была такая же "проблема" с другими хостинг-провайдерами. Наше решение-использовать какой-то пользовательский скрипт, который запускается на целевой машине и может быть вызван через конечную точку REST-Api (защищенную Basic-Auth или чем-либо еще).

Таким образом, вы можете просто вызвать удаленный хост для входа в docker и обновить свой сервис, не предоставляя SSH-доступ через gitlab-ci.

0