Skip to main content
Практика завдань
Запропонувати правку

Як налаштувати приватний Docker registry (Harbor)?

docs.questions.sections.docker~4 хв читання

Harbor це домінантний open-source приватний container-registry. Обгортає базовий OCI Distribution spec (той самий протокол, що Docker Hub) з прод-фічами, що on-prem і enterprise команди реально потребують.

Теорія

TL;DR

  • Open-source registry, побудований на CNCF distribution. CNCF graduated з 2020.
  • Понад звичайний registry: RBAC, multi-tenant projects, vulnerability scanning (Trivy/Clair), image signing (Notary, Cosign), replication до інших registry, retention-policies, garbage collection, OIDC/LDAP auth.
  • Deploy через Compose для single-node або Helm chart для HA на Kubernetes.
  • Використовується як on-prem альтернатива AWS ECR / Google GCR / Docker Hub, коли air-gapped, multi-region або compliance-driven.
  • Говорить звичайним docker pull/push, твій існуючий CI/CD не змінюється.

Архітектура

+----------+ +----------+ +-----------+ | nginx / | | core | | registry | | portal | -> | (API) | -> | (CNCF | | | | + jobsvc | | distrib.) | +----------+ +----------+ +-----------+ | | | v v v +-----+ +--------+ +-------+ | UI | | trivy | | redis | +-----+ | scanner| +-------+ +--------+ | v +-----------+ | postgres | +-----------+

Дюжина container, що крутяться разом (web UI, API, DB, Redis, registry, scanner тощо). Compose-installer піднімає усе.

Single-node install (Compose)

bash
# Завантаження wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-online-installer-v2.11.0.tgz tar xzf harbor-online-installer-v2.11.0.tgz cd harbor # Налаштування cp harbor.yml.tmpl harbor.yml vi harbor.yml # hostname: harbor.example.com # https.port: 443 # https.certificate: /etc/cert/fullchain.pem # https.private_key: /etc/cert/privkey.pem # harbor_admin_password: <сильний-pw> # database.password: <db-pw> # Install з Trivy scanner sudo ./install.sh --with-trivy # Піднімає ~10 container через docker compose

Відкрий https://harbor.example.com → log in як admin з паролем з harbor.yml.

Push/pull

bash
# Log in docker login harbor.example.com -u admin -p <password> # Tag і push docker tag myapp:1.0 harbor.example.com/myproject/myapp:1.0 docker push harbor.example.com/myproject/myapp:1.0 # Pull з іншого host docker pull harbor.example.com/myproject/myapp:1.0

Harbor говорить тим самим протоколом, що Docker Hub. CI/CD-скрипти лише міняють hostname registry.

Projects і RBAC

Harbor групує image у projects. Кожен project це namespace зі своїм:

  • Видимістю: private (auth потрібна) або public (без auth для pull).
  • Member-ролями: Project Admin, Maintainer, Developer, Guest.
  • Vulnerability scan policies.
  • Retention policies.
  • Replication rules.

Типовий multi-tenant setup: один Harbor-інстанс, один project на команду. Project Admins керують image своєї команди; cross-project доступ контролюється.

Vulnerability scanning

З --with-trivy Harbor включає вбудований scanner:

  • Scan на push (налаштовується per project).
  • Заплановані re-scan усіх image.
  • CVE-результати видно у UI; gate pull за severity («prevent vulnerable images»).
  • Tag, marked unsafe, блокують деплої через admission policy.
yaml
# У project-налаштуваннях Vulnerability Scanning: enabled Prevent vulnerable images: HIGH and above Auto-scan on push: true

Replication

Harbor може дзеркалити image до і з інших registry:

  • Pull-through cache: налаштуй Docker Hub як remote, Harbor кешує pull. Прискорює завантаження, переживає Docker Hub rate-limits.
  • Push до іншого Harbor: multi-region setup'и реплікують прод-image у Harbor кожного регіону.
  • Push до Docker Hub / ECR / GCR: розподіляй по кількох registry з одного source.
yaml
# Replication rule Name: replicate-to-eu Mode: pull / push / event-based Filter: project=prod, tag=v* Destination: harbor-eu.example.com Trigger: scheduled / manual / on-push

Image signing

Два варіанти:

  • Notary v1 (вбудовано, DCT-сумісно) — підписує image-manifest.
  • Cosign / Sigstore (сучасно) — підписує OCI-артефакти. Все частіше дефолт.

Enforce «лише підписані image деплояться» через admission control (Kyverno, sigstore-policy-controller).

Retention-policies

Без retention кожен PR-білд накопичується назавжди. Harbor дозволяє ставити правила:

Retain: останні 10 push-tag Exclude: tag, що матчать v* (тримай усі release-tag) Apply to: project=staging

Garbage collection крутиться у scheduled-job; звільнене місце reclaim'ається.

HA install (Helm)

Для проду крути Harbor на Kubernetes:

bash
helm repo add harbor https://helm.goharbor.io helm upgrade --install harbor harbor/harbor \ --set expose.type=ingress \ --set externalURL=https://harbor.example.com \ --set persistence.enabled=true \ --set persistence.persistentVolumeClaim.registry.size=500Gi

Реплікує сервіси між node; персистентні volume для registry-storage і Postgres. Переживає node-failure, якщо backed by network storage.

Типові помилки

Забути налаштувати TLS

Дефолти harbor.yml припускають HTTP для тестування. Прод вимагає HTTPS — Docker daemon відмовляє push на untrusted HTTP-registry за замовчуванням. Згенеруй серти (Let's Encrypt, internal CA) і налаштуй https: блок у harbor.yml.

Запуск на тому самому host, що критичні навантаження

Registry, що хостить твої прод-image, сам критична інфраструктура. Якщо крашиться, не можеш деплоїти. Крути на dedicated-залізі або своєму K8s-кластері.

Без retention-policy → диск переповнюється

2 TB CI-білдів накопичено. Backup-вікно: 12 годин. Recovery-вікно: нервово.

Став retention-policies з першого дня. Garbage collection scheduled щотижня мінімум.

Відсутність storage-backup

Harbor Postgres має метадані; filesystem registry має реальні blob. Обидва потребують backup. Втрата метаданих = image osirотіли. Втрата blob = метадані вказують у нікуди.

Деплой без scanning

Якщо маєш Harbor з Trivy і не вмикаєш scanning, ти платиш за фічу і не використовуєш. Мінімум: scan-on-push для усіх project.

Реальне застосування

  • On-prem enterprise: фінанси, healthcare, telecom — Harbor дефолт для self-hosted регульованих середовищ.
  • Multi-cloud: Harbor як центральний registry, з replication до AWS ECR / GCR для region-local pull.
  • Air-gapped: classified мережі, де public-інтернет заборонено; Harbor + Trivy DB-update через offline sync.
  • Open-source проекти: деякі тримають свій Harbor для community-built image.
  • Pull-through cache: Harbor кешував Docker Hub для тисяч CI-runs без удару у rate-limit.

Питання для поглиблення

Q: Яка різниця між Harbor і голим registry:2 image?


A: registry:2 це базовий CNCF distribution-server — pull/push, усе. Harbor обгортає auth, RBAC, UI, scanning, signing, replication. Для toy-use або швидкого local-testing бери registry:2. Для реального проду Harbor.

Q: Чи Harbor може scan'ити image з external-registry?


A: Лише image, збережені у Harbor. Щоб scan'ити external, налаштуй replication, щоб затягувати їх у Harbor.

Q: Як Harbor обробляє storage?


A: Filesystem (дефолт), S3-сумісний (AWS S3, Minio, GCS, Azure Blob) або Swift. Налаштовується через storage-секцію harbor.yml.

Q: Чи можу крутити Harbor у HA?


A: Так — Helm chart з кількома replica, external Postgres (HA), external Redis (HA), shared storage-backend (S3 або NFS). Single-node Compose-install для малих/staging; прод = HA.

Q: (Senior) Як спроектувати Harbor для глобального multi-region деплою?


A: Центральний «hub» Harbor, куди CI пушить; «spoke» Harbor у кожному регіоні для low-latency pull. Hub-to-spoke replication on event (push тригерить replica-push за хвилини). Spoke-storage використовує cloud-region-local object-store (S3, GCS). Hub backed up offsite. Прод K8s у кожному регіоні pull'ить зі свого spoke; якщо spoke down, fallback на hub. Audit-логи централізовано через syslog. Дизайн: image авторитетно у hub, розподілено для performance, survive'абельне для resilience.

Приклади

Compose-based small install

bash
# Після того, як install.sh завершується, маєш: $ docker compose ps NAME IMAGE STATUS harbor-core goharbor/harbor-core running harbor-db goharbor/harbor-db running harbor-jobservice goharbor/harbor-jobservice running harbor-portal goharbor/harbor-portal running harbor-registry goharbor/registry-photon running harbor-trivy-adapter goharbor/trivy-adapter running nginx goharbor/nginx-photon running redis goharbor/redis-photon running # ... ~10 сервісів $ curl -k https://harbor.example.com/api/v2.0/health {"status":"healthy","components":[...]}

CI-інтеграція

yaml
# GitHub Actions - uses: docker/login-action@v3 with: registry: harbor.example.com username: ci-robot password: ${{ secrets.HARBOR_TOKEN }} - uses: docker/build-push-action@v5 with: push: true tags: harbor.example.com/myproject/api:${{ github.sha }}

Robot-акаунти Harbor (long-lived API-токени) це стандартний CI auth-патерн.

Replication: Docker Hub pull-through cache

Harbor settings → Registries Add registry: type=docker-hub, url=https://hub.docker.com Project "library" → Replications Pull-based replication, source=docker-hub, filter=*nginx*

Тепер docker pull harbor.example.com/library/nginx:1.27 реально pull'ить з Docker Hub (якщо не закешовано), потім обслуговує з Harbor на наступних pull. Rate-limits Docker Hub per-IP, твій Harbor це один IP, значно важче вдарити у ліміти.

Коротка відповідь

Для співбесіди
Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.

Коментарі

Ще немає коментарів