Docker Hub та приватні registries

Фактично це образ із репозиторію library/nginx у Docker Hub.

Docker Hub і приватний registry

Docker Hub

Docker Hub — публічний хмарний registry, який часто використовують як стандартне джерело образів.

Він підходить для:

• отримання публічних базових образів;

• публікації відкритих проєктів;

• зберігання приватних образів, якщо це дозволяє тариф і налаштування репозиторію;

• інтеграції з CI/CD.

Приклади образів із Docker Hub:

Публічний образ можна завантажити без автентифікації:

Для публікації образу потрібні облікові дані та права запису до відповідного репозиторію.

Приватний registry

Приватний registry доступний лише визначеним користувачам або сервісам. Він може бути:

• розгорнутий всередині компанії;

• наданий хмарним провайдером;

• інтегрований із платформою для зберігання коду;

• доступний за адресою на кшталт registry.example.com.

Приватний registry використовують, коли образи містять:

• код комерційного продукту;

• внутрішні сервіси;

• корпоративні базові образи;

• компоненти, які не можна публікувати у відкритому доступі.

Приклад імені образу:

На відміну від Docker Hub, адресу приватного registry потрібно вказувати в імені образу.

Формат імен образів

Docker визначає registry за першою частиною імені, якщо вона містить крапку, двокрапку або має значення localhost.

Приклади:

• nginx:1.27 — Docker Hub;

• docker.io/library/nginx:1.27 — Docker Hub із явною адресою;

• registry.example.com/team/api:1.0.0 — приватний registry;

• localhost:5000/team/api:dev — registry на локальному порту 5000.

Тег є частиною адреси образу. Якщо тег не вказати, Docker використовує latest:

Це еквівалентно:

У production краще вказувати конкретний тег або digest, щоб результат не змінювався неочікувано.

Автентифікація через docker login

Для входу в Docker Hub виконайте:

Docker попросить ім’я користувача та пароль або access token.

Для іншого registry вкажіть його адресу:

Не додавайте до адреси протокол:

Після успішного входу Docker зберігає облікові дані у файлі конфігурації, зазвичай:

Вхід за допомогою access token

Для автоматизації не слід використовувати основний пароль користувача. Замість нього створіть access token із мінімально необхідними правами.

Для інтерактивного входу:

Коли Docker попросить пароль, введіть access token.

Для CI/CD без передачі токена через аргументи командного рядка:

Для приватного registry:

Параметр --password-stdin кращий за --password, тому що секрет не потрапляє безпосередньо до команди та списку процесів.

Завантаження образу з приватного registry

Після автентифікації можна завантажити приватний образ:

Якщо користувач не має права читання, registry поверне помилку на кшталт:

Це може означати:

• неправильний registry;

• неправильний репозиторій;

• відсутню автентифікацію;

• відсутнє право pull;

• помилковий тег;

• прострочений або відкликаний токен.

Публікація образу

Щоб опублікувати локальний образ у registry, його потрібно позначити повним іменем.

Наприклад, локальний образ має назву:

Підготуємо тег для Docker Hub:

Або для приватного registry:

Після цього виконаємо push:

Повна послідовність може виглядати так:

Під час docker push Docker може завантажувати шари, які ще відсутні в registry. Шари, що вже є там, повторно не завантажуються.

Повний приклад із локальним образом

Нижче наведено послідовність, яку можна виконати у проєкті з Dockerfile.

Перед запуском потрібно встановити змінні середовища:

Скрипт очікує, що:

• Docker daemon доступний;

• у поточному каталозі є коректний Dockerfile;

• користувач має право push до registry.example.com/team/catalog-api;

• змінна REGISTRY_TOKEN не потрапляє до журналів CI.

Права доступу

Типові права для роботи з образами можна поділити на дві категорії:

• pull — читання та завантаження образів;

• push — публікація нових образів і тегів.

Для різних задач потрібні різні облікові дані:

• розробнику зазвичай достатньо pull для production-образів;

• CI для складання має push до конкретного репозиторію;

• production-середовищу потрібен лише pull;

• адміністратору можуть бути потрібні права керування репозиторіями та користувачами.

Не варто використовувати один загальний обліковий запис для всіх середовищ. Краще створювати окремі service account або токени для:

• локальної розробки;

• CI/CD;

• staging;

• production.

Якщо токен скомпрометовано, його потрібно відкликати та створити новий.

Безпечне зберігання облікових даних

Docker може зберігати облікові дані за допомогою credential helper. Це безпечніше, ніж залишати їх у відкритому вигляді у config.json.

Конкретний спосіб залежить від операційної системи та встановлених Docker credential helpers.

Перевірити поточний Docker-конфіг можна так:

Не додавайте такі файли до Git:

Якщо для окремої операції потрібно використовувати ізольований конфіг, задайте DOCKER_CONFIG:

Такий підхід особливо корисний у тимчасових середовищах і CI.

Автентифікація в CI/CD

У CI/CD секрети потрібно зберігати у захищеному сховищі змінних середовища, а не в репозиторії.

Приклад команд для job:

У цьому прикладі тег на основі SHA коміту дає змогу однозначно визначити, з якого коміту створено образ.

Для CI важливо:

• надати токену лише право push до потрібного репозиторію;

• не виводити токен у логи;

• не передавати секрет у docker build через звичайний ARG;

• видаляти або ізолювати Docker-конфіг після завершення job;

• використовувати окремий токен для кожного середовища.

Вихід із registry

Щоб видалити збережені облікові дані для Docker Hub:

Щоб вийти з конкретного registry:

Це не видаляє локальні образи. Команда видаляє облікові дані для відповідного registry з Docker-конфігурації або credential helper.

Типовий робочий процес

Отримання приватного образу

Публікація нового образу

Запуск отриманого образу

Для production-середовища доступ до registry має бути налаштований до запуску контейнера. Сам контейнер не повинен отримувати Docker-токен безпосередньо, якщо цього не вимагає його логіка.

Поширені помилки

Використання пароля в командному рядку

Погано:

Краще:

Неповне ім’я приватного образу

Погано:

У такому випадку Docker шукатиме Docker Hub, а не приватний registry.

Правильно:

Відсутній локальний тег для push

Команда docker push працює з локальним образом, який має повну назву registry:

Використання latest як єдиної версії

Тег latest може вказувати на різний вміст у різний час. Для розгортання краще використовувати версійні теги або унікальні теги комітів:

Надмірні права токена

Токен із правами адміністратора небезпечно використовувати в CI. Створюйте токени з мінімальним набором дозволів і обмежуйте їх конкретним репозиторієм, якщо registry це підтримує.

Зберігання секретів у репозиторії

Не записуйте токени у:

• Dockerfile;

• docker-compose.yml;

• shell-скрипти;

• файли .env, які комітяться;

• документацію з прикладами реальних значень.

Summary

• Docker Hub — готовий хмарний registry, а приватний registry обмежує доступ до образів.

• Адресу приватного registry потрібно вказувати в імені образу.

• Для входу використовуйте docker login.

• У CI/CD передавайте токен через --password-stdin, а не через аргумент --password.

• Розділяйте права pull і push, використовуйте окремі токени та service account.

• Не зберігайте секрети в коді або репозиторії.

• Перед docker push позначайте локальний образ повною назвою registry.

• Для production використовуйте однозначні версійні теги або теги комітів замість залежності лише від latest.