Deployment Configuration
Relevant source files
The following files were used as context for generating this wiki page:
- deploy/compose/README.md
- src/pkg/chart/testdata/harbor-schema2/templates/core/core-dpl.yaml
- src/pkg/chart/testdata/harbor-schema2/templates/nginx/deployment.yaml
- src/pkg/chart/testdata/harbor-schema2/templates/jobservice/jobservice-dpl.yaml
- src/pkg/chart/testdata/harbor-schema2/templates/portal/deployment.yaml
- README.md
Harbor Next supports multiple deployment methodologies to cater to different environment requirements, primarily focusing on Docker Compose for minimal setups and Helm Charts for Kubernetes-based orchestration. The deployment configuration manages the lifecycle, connectivity, and security of core components including the Portal, Core API, JobService, and the Registry.
Sources: README.md:65-67, deploy/compose/README.md:1-5
Component Architecture
The Harbor deployment consists of several interconnected microservices. The Portal serves as the entry point, handling the Angular UI and reverse-proxying requests to the Core service. The Core service acts as the API gateway and business logic layer, communicating with the JobService for asynchronous tasks and the Registry for artifact storage.
The diagram shows the request flow from external clients through the Nginx-based Portal to the internal services. Sources: deploy/compose/README.md:46-77
Service Definitions
| Component | Role | Network Port |
|---|---|---|
| Portal (Nginx) | Serves static UI and reverse proxies /v2/, /api/, and /service/ to Core. | 8080 (internal), 443 (host) |
| Core | API gateway, authentication, and primary business logic provider. | 8080 |
| JobService | Handles long-running jobs such as replication and garbage collection. | 8888 |
| Registry | Distribution-based OCI artifact storage. | 5000 |
| RegistryCtl | Handles storage-level operations for the registry. | 8080 |
Sources: deploy/compose/README.md:46-71, src/pkg/chart/testdata/harbor-schema2/templates/nginx/deployment.yaml:80-84
Kubernetes Deployment (Helm)
The Kubernetes deployment utilizes standard apps/v1 Deployments. Each component is configured with specific security contexts, probes, and volume mounts to ensure reliability and isolation.
Core Service Configuration
The Core service is the central controller. Its deployment includes startup, liveness, and readiness probes targeting /api/v2.0/ping. It requires several secrets for operation, including the CORE_SECRET and JOBSERVICE_SECRET.
livenessProbe:
httpGet:
path: /api/v2.0/ping
scheme: {{ include "harbor.component.scheme" . | upper }}
port: {{ template "harbor.core.containerPort" . }}
Sources: src/pkg/chart/testdata/harbor-schema2/templates/core/core-dpl.yaml:83-89
Security and Runtime Context
Deployments are configured to run with restricted permissions. By default, pods use a specific security context:
- runAsUser: 10000
- fsGroup: 10000
- Termination Grace Period: 120 seconds for Core and JobService to allow for clean shutdowns of active tasks.
Sources: src/pkg/chart/testdata/harbor-schema2/templates/core/core-dpl.yaml:47-49, src/pkg/chart/testdata/harbor-schema2/templates/jobservice/jobservice-dpl.yaml:51-53
Docker Compose Configuration
The Compose deployment is designed for minimal resource footprints. It relies on an .env file for environment-specific variables and secrets.
Prerequisites and Initialization
- Docker Engine: Version 24+ with Compose v2.24+.
- Token Key: A PKCS#1 RSA private key must be generated at
config/token_service_key.pemwith 644 permissions to allow the container user (UID 10000) to read it.
Sources: deploy/compose/README.md:5-24
Security and TLS
TLS is enabled by default in the Nginx configuration. Users must provide absolute paths to TLS_CERT and TLS_KEY in the .env file. If using self-signed certificates, the Docker client must be configured with --insecure-registry.
Sources: deploy/compose/README.md:28-44
Volume and Persistence Management
Harbor services require persistent storage for registry data, database records, and job logs. In Kubernetes, this is handled via PersistentVolumeClaims (PVCs), while Compose uses host-mapped volumes or named Docker volumes.
| Volume Name | Mounted Path | Purpose | Component |
|---|---|---|---|
| config | /etc/core/app.conf | Core application configuration | Core |
| job-logs | /var/log/jobs | Logs generated by background tasks | JobService |
| portal-config | /etc/nginx/nginx.conf | Nginx routing and proxy rules | Portal |
| registry-data | /var/lib/registry | Stored OCI images and artifacts | Registry |
Sources: src/pkg/chart/testdata/harbor-schema2/templates/core/core-dpl.yaml:164-167, src/pkg/chart/testdata/harbor-schema2/templates/jobservice/jobservice-dpl.yaml:142-144, deploy/compose/README.md:73-77
Internal Communication and TLS
Harbor supports internal TLS for encrypted communication between its microservices. This is managed via environment variables and volume mounts that inject certificates into the containers.
Summary
The deployment configuration of Harbor Next is structured to support both portable single-node installations via Docker Compose and scalable multi-node clusters via Helm. Key configuration areas include component-specific probes for health monitoring, strict security contexts for runtime safety, and a robust volume architecture for persistent data management. System administrators must ensure proper secret management and certificate provisioning to maintain a secure registry environment.