Контейнеры давно перестали быть экзотикой. Практически любая команда, использующая Kubernetes или CI/CD, сталкивается с необходимостью где-то хранить образы приложений. На первых этапах обычно хватает Docker Hub, но со временем появляются ограничения: приватные проекты, требования безопасности, аудит действий пользователей и контроль цепочки поставки программного обеспечения.

Именно здесь появляется Harbor. Это не просто Docker Registry с красивым интерфейсом, а полноцененная платформа управления OCI-артефактами. Harbor умеет хранить контейнерные образы и Helm-чарты, сканировать их на наличие уязвимостей, интегрироваться с LDAP и Active Directory, экспортировать метрики в Prometheus и поддерживать современные механизмы подписи артефактов.

В этой статье мы рассмотрим два сценария, которые действительно используются в 2026 году: быстрый запуск Harbor на отдельной виртуальной машине и production-развертывание внутри Kubernetes.

Harbor на Ubuntu 24.04: быстрый production-ready стенд

Для большинства компаний этого варианта будет достаточно.

Минимальные требования:

Ресурс Рекомендуемое значение
CPU 4 vCPU
RAM 8 ГБ
Диск от 100 ГБ
ОС Ubuntu 24.04 LTS

Сразу выделите отдельный раздел /data. Опыт показывает, что контейнерные образы растут быстрее любых прогнозов.

Устанавливаем Docker Engine

Используем только официальный репозиторий Docker.

sudo apt-get update

sudo apt-get install \
    ca-certificates \
    curl \
    gnupg -y

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
    | sudo gpg --dearmor \
      -o /etc/apt/keyrings/docker.gpg

echo \
"deb [arch=$(dpkg --print-architecture) \
signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
| sudo tee /etc/apt/sources.list.d/docker.list >/dev/null

sudo apt-get update

sudo apt-get install \
    docker-ce \
    docker-ce-cli \
    containerd.io \
    docker-buildx-plugin \
    docker-compose-plugin -y

sudo systemctl enable docker
sudo systemctl start docker

sudo usermod -aG docker $USER
newgrp docker

Проверяем:

docker version
docker compose version

Устанавливаем Harbor 2.14

export HARBOR_VERSION=2.14.0

wget \
https://github.com/goharbor/harbor/releases/download/v${HARBOR_VERSION}/harbor-online-installer-v${HARBOR_VERSION}.tgz

tar xzf harbor-online-installer-v${HARBOR_VERSION}.tgz

sudo mv harbor /opt/

cd /opt/harbor

Настраиваем сертификаты

Для production используйте Let's Encrypt или корпоративный центр сертификации. Для лаборатории достаточно самоподписанных сертификатов.

export HARBOR_HOST=harbor.example.local

openssl genrsa -out ca.key 4096

openssl req \
    -x509 \
    -new \
    -nodes \
    -key ca.key \
    -sha256 \
    -days 3650 \
    -out ca.crt

openssl genrsa \
    -out ${HARBOR_HOST}.key \
    4096

openssl req \
    -new \
    -key ${HARBOR_HOST}.key \
    -out ${HARBOR_HOST}.csr

cat > extfile.cnf <<EOF
subjectAltName=DNS:${HARBOR_HOST}
EOF

openssl x509 \
    -req \
    -in ${HARBOR_HOST}.csr \
    -CA ca.crt \
    -CAkey ca.key \
    -CAcreateserial \
    -out ${HARBOR_HOST}.crt \
    -days 3650 \
    -sha256 \
    -extfile extfile.cnf

Подготавливаем Docker:

sudo mkdir -p \
/etc/docker/certs.d/${HARBOR_HOST}

sudo cp \
    ${HARBOR_HOST}.crt \
    ${HARBOR_HOST}.key \
    ca.crt \
    /etc/docker/certs.d/${HARBOR_HOST}/

sudo cp \
    ca.crt \
    /usr/local/share/ca-certificates/

sudo update-ca-certificates

sudo systemctl restart docker

Настраиваем Harbor

cp harbor.yml.tmpl harbor.yml

Минимально необходимые параметры:

hostname: harbor.example.local

https:
  port: 443
  certificate: /etc/docker/certs.d/harbor.example.local/harbor.example.local.crt
  private_key: /etc/docker/certs.d/harbor.example.local/harbor.example.local.key

harbor_admin_password: StrongAdminPassword

data_volume: /data

trivy:
  ignore_unfixed: false

metric:
  enabled: true
  port: 9090
  path: /metrics

Запускаем Harbor

sudo ./install.sh \
    --with-trivy

Через несколько минут Harbor будет доступен по адресу:

https://harbor.example.local

Логин по умолчанию:

admin
StrongAdminPassword

Работаем с образами

Создаем проект через веб-интерфейс, например:

backend

Авторизация:

docker login harbor.example.local

Сборка приложения:

docker build \
    -t demo-api:1.0 .

Тегирование:

docker tag \
    demo-api:1.0 \
    harbor.example.local/backend/demo-api:1.0

Публикация:

docker push \
    harbor.example.local/backend/demo-api:1.0

Проверка:

docker pull \
    harbor.example.local/backend/demo-api:1.0

OCI Helm Registry

ChartMuseum постепенно уходит в прошлое. Harbor умеет работать с Helm напрямую через OCI.

Авторизация:

helm registry login harbor.example.local

Упаковка чарта:

helm package mychart

Публикация:

helm push \
    mychart-0.1.0.tgz \
    oci://harbor.example.local/helm

Получение:

helm pull \
    oci://harbor.example.local/helm/mychart \
    --version 0.1.0

Резервное копирование

Минимальный набор:

  • каталог /data;

  • файл harbor.yml;

  • сертификаты;

  • дамп PostgreSQL при использовании внешней БД.

Для встроенной PostgreSQL:

docker exec harbor-db \
    pg_dumpall -U postgres \
    > harbor.sql

Harbor в Kubernetes

Когда количество разработчиков растет, появляется несколько кластеров и требования к высокой доступности, Harbor обычно переезжает в Kubernetes.

Устанавливаем репозиторий:

helm repo add harbor \
https://helm.goharbor.io

helm repo update

Создаем namespace:

kubectl create namespace harbor

Пример values.yaml:

expose:
  type: ingress

  ingress:
    className: nginx

    hosts:
      core: harbor.example.com

externalURL: https://harbor.example.com

persistence:
  enabled: true

  imageChartStorage:
    type: s3

    s3:
      region: us-east-1
      bucket: harbor
      accesskey: minio
      secretkey: miniosecret
      regionendpoint: http://minio.minio.svc:9000

database:
  type: external

externalDatabase:
  host: postgres.example.local
  port: 5432
  username: harbor
  password: StrongPassword
  coreDatabase: harbor

redis:
  type: external

externalRedis:
  host: redis.example.local
  port: 6379

trivy:
  enabled: true

metrics:
  enabled: true

Установка:

helm install harbor \
    harbor/harbor \
    -n harbor \
    -f values.yaml

cert-manager

ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: admin@example.com
    server: https://acme-v02.api.letsencrypt.org/directory

    privateKeySecretRef:
      name: letsencrypt

    solvers:
    - http01:
        ingress:
          class: nginx

После этого Harbor будет автоматически получать сертификаты Let's Encrypt.

GitOps и ArgoCD

Harbor отлично вписывается в GitOps-подход.

Достаточно хранить:

  • values.yaml;

  • манифест Application;

  • настройки Ingress;

в Git-репозитории.

ArgoCD будет автоматически применять изменения и контролировать состояние платформы.

Подпись образов через Cosign

Notary v1 постепенно уступает место Sigstore.

Установка Cosign:

curl -O -L \
https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64

chmod +x cosign-linux-amd64

sudo mv cosign-linux-amd64 \
    /usr/local/bin/cosign

Генерируем ключи:

cosign generate-key-pair

Подписываем образ:

cosign sign \
harbor.example.local/backend/demo-api:1.0

Проверяем подпись:

cosign verify \
    --key cosign.pub \
    harbor.example.local/backend/demo-api:1.0

Итоги

Harbor в 2026 году - это уже не просто внутренний Docker Registry. Это центральный элемент цепочки поставки программного обеспечения, объединяющий хранение OCI-артефактов, анализ уязвимостей, контроль доступа и механизмы доверия.

Если команда только начинает путь контейнеризации, достаточно отдельной виртуальной машины. Такой подход позволяет получить работающий корпоративный реестр буквально за один вечер.

Когда же появляются десятки сервисов, несколько кластеров Kubernetes и требования к отказоустойчивости, Harbor логично становится частью платформенной инфраструктуры и разворачивается внутри Kubernetes с использованием GitOps, внешних сервисов и объектных хранилищ.

Главное помнить одну простую вещь: контейнерный реестр очень быстро превращается из "небольшого вспомогательного сервиса" в один из критически важных компонентов всей инфраструктуры. Поэтому проектировать его стоит так же внимательно, как базы данных, системы мониторинга и сам Kubernetes.