Как пройти аутентификацию в реестре контейнеров GitLab перед созданием образа Docker?

Question

У меня есть частный проект GitLab с конвейером для сборки и отправки изображения Docker. Поэтому я должен сначала пройти аутентификацию в реестре GitLab Docker.

Исследования

Я прочитал Аутентификация в реестре контейнеров с помощью GitLab CI / CD :

Существует три способы аутентификации в Реестре контейнеров через GitLab CI / CD, которые зависят от видимости вашего проекта.

Доступно для всех проектов, хотя больше подходит для публичных c:

• Использование специальной переменной CI_REGISTRY_USER: Пользователь, указанный в этой переменной, создан для вас, чтобы отправить sh в Реестр, связанный с вашим проектом. Его пароль автоматически устанавливается с помощью переменной CI_REGISTRY_PASSWORD. Это позволяет автоматизировать создание и развертывание ваших Docker изображений и имеет доступ для чтения / записи к реестру. Это эфемерно, поэтому действует только для одной работы. Вы можете использовать следующий пример "как есть":

  docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  

Для частных и внутренних проектов:

• Использование личного доступа токен: Вы можете создать и использовать токен личного доступа, если ваш проект закрыт:

  • Для доступа для чтения (извлечения) область должна быть read_registry.
  • Для доступа на чтение / запись (pull / pu sh) используйте api.

  Замените <username> и <access_token> в следующем примере:

     docker login -u <username> -p <access_token> $CI_REGISTRY
  

• Использование токена развертывания GitLab: Вы можете создавать и использовать специальный токен развертывания для своих частных проектов. Он обеспечивает доступ только для чтения (pull) к реестру. После создания вы можете использовать специальные переменные окружения, и GitLab CI / CD заменит их для вас. Вы можете использовать следующий пример как есть:

     docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
  

и Реестр контейнеров :

С обновлением В модели разрешений мы также расширили поддержку доступа к Реестрам контейнеров для частных проектов.

История версий

Ваши задания могут получить доступ ко всем изображениям контейнеров, к которым у вас обычно был бы доступ. Единственный смысл в том, что вы можете отправить sh в Реестр контейнеров проекта, для которого запущено задание.

Вот как может выглядеть пример использования:

test:
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker pull $CI_REGISTRY/group/other-project:latest
    - docker run $CI_REGISTRY/group/other-project:latest

Я попробовал первый и четвертый способ, и я мог аутентифицироваться.

Вопрос

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

И почему четвертый способ не указан в другой документации? Это не рекомендуется?

Answer 1

Я полагаю, что различия связаны только с навыками и разрешениями пользователя.

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

Второй, любой, с любым Права доступа могут создавать личный токен доступа (но имеет дополнительный шаг по сравнению с 1 для создания токена доступа).

В-третьих, кто-то с правильными разрешениями может создать ключ развертывания. Ключи развертывания не дают доступа к API, как это делают персональные токены доступа, и имеют только разрешение на извлечение / чтение данных в хранилище, они не могут записывать / pu sh.

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