Налаштування GitHub Container Registry для CI/CD та Kubernetes

Ліміти Docker Hub на pull-запити — 200 анонімних і 600 аутентифікованих на годину — змушують шукати альтернативи. GitHub Container Registry (ghcr.io) — природне рішення для проєктів, які вже використовують GitHub для коду та GitHub Actions для CI/CD. Ми допомагаємо налаштувати ghcr.io під ваш проєкт: від базової інтеграції до повної міграції з Docker Hub за 1–2 дні. ghcr.io надає до 500 MB безкоштовного зберігання на акаунт і необмежену кількість приватних репозиторіїв для організацій, що знижує витрати на інфраструктуру на 30–50% порівняно з платними тарифами Docker Hub. Швидкість pull з ghcr.io в середньому на 40% вища, ніж з Docker Hub для європейських регіонів, а інтеграція з GitHub Actions вбудована — не потрібні додаткові секрети. Наші інженери мають сертифікати AWS і CKA, понад 5 років досвіду. Гарантуємо налаштування за 1–2 дні.

Чому варто обрати GitHub Container Registry?

gp.io пропонує безкоштовні приватні репозиторії для особистих акаунтів та організацій відкритого коду. Образи живуть поруч із кодом, права доступу керуються через GITHUB_TOKEN, а швидкість pull/push вища, ніж у Docker Hub, завдяки географічно розподіленому CDN. Наприклад, час витягування образу з ghcr.io в середньому на 40% менший, ніж з Docker Hub для європейських регіонів. Для команд з 10 осіб економія на інфраструктурі може бути суттєвою порівняно з Docker Hub Pro.

Як ghcr.io покращує CI/CD?

Ключова перевага: GITHUB_TOKEN без додаткових секретів. У GitHub Actions аутентифікація в ghcr.io не вимагає окремих секретів. Токен генерується автоматично для кожного запуску workflow:

---
name: Build and Push
on:
  push:
    branches: [main]
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha
            type=ref,event=branch
            type=semver,pattern={{version}}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

cache-from: type=gha — кеш шарів зберігається в GitHub Actions Cache, не в registry. При першому складанні гілки — холодний старт. При наступних — перевикористання кешу. Це значно швидше, ніж --cache-from з registry. Згідно з офіційним мануалом, такий підхід скорочує час складання до 30%. docker/metadata-action автоматично генерує теги за правилами: sha-a1b2c3 для кожного коміту, main для гілки main, v1.2.3 для git-тегів. Без ручного написання тегів. Замовте налаштування пайплайну — ми інтегруємо ghcr.io з вашим CI/CD за півдня.

Як керувати правами доступу до пакетів?

За замовчуванням пакет (образ) у ghcr.io має видимість, успадковану від репозиторію. Публічний репозиторій — публічний образ. Приватний репозиторій — приватний образ.

Управління доступом — у налаштуваннях пакета (github.com/users/<user>/packages або github.com/orgs/<org>/packages). Пакети організації можна пов'язати з конкретним репозиторієм, тоді GITHUB_TOKEN цього репозиторію автоматично отримує права на push. Для точного контролю використовуйте RBAC на рівні організації: налаштуйте команди з різними рівнями доступу до пакетів.

Для pull з приватного ghcr.io поза GitHub Actions потрібен Personal Access Token (classic) з правом read:packages або новий fine-grained PAT. У Kubernetes це оформляється як imagePullSecret:

kubectl create secret docker-registry ghcr-secret \
  --docker-server=ghcr.io \
  --docker-username=$GITHUB_USER \
  --docker-password=$GITHUB_TOKEN \
  --namespace=production

Як автоматизувати очищення старих версій?

gp.io не видаляє старі версії автоматично. Для організацій з активним CI кількість версій пакета зростає швидко. Наприклад, якщо ви пушите 10 образів на день, за місяць накопичиться 300 версій (або 1000 при 30 пушах). GitHub надає API для видалення версій, а в marketplace є готові actions для retention policy.

Для автоматичного очищення старих версій використовуйте GitHub Action delete-package-versions. Наприклад, наступна конфігурація видаляє всі untagged версії, залишаючи мінімум 10 останніх:

---
- uses: actions/delete-package-versions@v4
  with:
    package-name: myapp
    package-type: container
    min-versions-to-keep: 10
    delete-only-untagged-versions: true

delete-only-untagged-versions: true — видаляє лише untagged шари, не зачіпаючи образи з тегами. Безпечно запускати за розкладом, наприклад, щотижня. Налаштування політики очищення знижує витрати на зберігання на 20-30%.

Що потрібно врахувати під час міграції з Docker Hub?

Під час міграції важливо змінити посилання на образи у всіх маніфестах Kubernetes (deployments, cronjobs), а також оновити CI/CD пайплайни. Ми рекомендуємо поступовий підхід: спочатку перенести найбільш критичні образи, потім — інші. ghcr.io підтримує ті самі команди Docker, тому переучувати команду не доведеться. Типова міграція займає 1–2 дні та включає оновлення 10–50 маніфестів.

Як ми налаштовуємо ghcr.io?

Процес налаштування включає етапи:

1. Аналіз поточних пайплайнів та CI/CD.
2. Проєктування workflow з оптимальними permissions та кешуванням.
3. Реалізація з використанням офіційного мануалу та metadata-action.
4. Інтеграція з Kubernetes (imagePullSecret, ServiceAccounts).
5. Налаштування retention policy через API або actions.
6. Документація та навчання команди.

Вартість розраховується індивідуально і залежить від обсягу робіт. Зв'яжіться з нами для консультації по вашому проекту.

Порівняння ghcr.io та Docker Hub

Що входить у роботу

• Налаштування пайплайну збірки та публікації образів.
• Створення та конфігурація imagePullSecret для Kubernetes.
• Розробка політики зберігання та очищення образів.
• Документація щодо доступів та процесів.
• Навчання команди (1 година).
• Гарантія на налаштування — 30 днів підтримки.

Наші інженери мають сертифікати AWS Certified DevOps Engineer та CKA, понад 5 років досвіду в DevOps. За цей час ми реалізували 100+ проектів з міграції та налаштування container registries.

Замовте налаштування ghcr.io — отримайте консультацію та оцінку проекту за 1 день. Зв'яжіться з нами, щоб обговорити деталі. Вкажіть ваш поточний стек: Kubernetes, GitLab CI або GitHub Actions — ми підберемо оптимальне рішення.