Настройка 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?

ghcr.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

Как автоматизировать очистку старых версий?

ghcr.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 layers, не трогая образы с тегами. Безопасно запускать по расписанию, например, еженедельно. Настройка политики очистки снижает расходы на хранение на 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 — мы подберём оптимальное решение.