Ответ
Это стандартный рабочий процесс. Я собираю образ, тегирую его в соответствии с политикой именования реестра и отправляю.
Базовые команды:
# 1. Сборка образа из Dockerfile в текущей директории
# Использую --pull для обновления базовых образов и кэширование слоев
docker build --pull -t my-service:1.0.0 .
# 2. Тегирование образа для целевого реестра (например, GitLab Container Registry)
docker tag my-service:1.0.0 registry.gitlab.com/my-group/my-project/my-service:1.0.0
# 3. Аутентификация в реестре (токен или пароль)
echo $CI_REGISTRY_PASSWORD | docker login registry.gitlab.com -u $CI_REGISTRY_USER --password-stdin
# 4. Отправка образа в реестр
docker push registry.gitlab.com/my-group/my-project/my-service:1.0.0
Практические детали из опыта:
- Теги: Помимо версии (
:1.0.0), часто добавляю тег:latestдля основной ветки и тег на основе хэша коммита (:a1b2c3d) для трассируемости. - Multi-stage сборки: Использую для уменьшения итогового размера образа.
- Безопасность: Никогда не хардкожу учетные данные. Использую переменные окружения CI (например,
$CI_JOB_TOKENв GitLab) или Docker Credential Helpers. - CI/CD: В реальных проектах этот процесс автоматизирован в пайплайне (GitHub Actions, GitLab CI). Пример этапа для GitLab CI:
build_and_push: stage: build script: - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG . - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG