Deployment Architecture
Understand the deployment architecture of Harness Database DevOps, including components, data flow, and integration points.
Welcome to the Harness Database DevOps Product Documentation. This guide will assist you in integrating database operations into your application deployment workflows. Our Database DevOps module enables you to manage database schemas, orchestrate changes, and ensure consistency across all your environments.
This page explains the deployment architecture of Harness Database DevOps, including how components communicate and how changes are executed against your database infrastructure.
Before you begin:
Familiarize yourself with these resources before proceeding.
Harness DB DevOps architecture
The Harness delegate is crucial to Harness Database DevOps because it gives us access to your infrastructure on which we execute jobs that require database network connectivity. The Harness Delegate acts as an agent that facilitates the connection between the Harness CI/CD pipeline and the database. It enables the execution of database changes in a secure and efficient manner. The Delegate can be configured to connect to various database instances, ensuring that the right credentials and access parameters are used for each environment.
Communication protocol between services and customer infra
Key Notes
Outbound Control
All the communications shown in the diagram operate as part of a single execution flow.
It is not possible to selectively disable individual communications, as doing so would break the orchestration pipeline.
Delegate Communication
The Harness Delegate is the primary component responsible for initiating communication back to Harness SaaS.
Go to Delegate Overview to understand how the Delegate functions.
Log Shipping
During task execution, outbound access to "
googleapis.com" over port 443 is required to ship step logs.This can be avoided by changing the account-level setting: Account Settings → Default Settings → Continuous Integration → Upload Logs via Harness. When enabled, logs are shipped directly to Harness SaaS, removing the dependency on googleapis.com.
Network communication
Initiator
Protocol/Port
Destination
Harness URL / Endpoint
NextGen UI
HTTPS :443
Gateway
https://app.harness.io/gateway
Gateway
HTTPS :443
NG Core
https://app.harness.io/ng/api/*
Gateway
HTTPS :443
Log Service
https://app.harness.io/log-service/*
Gateway
HTTPS :443
Pipeline Service
https://app.harness.io/pipeline-service/*
Pipeline Service
HTTPS :443
NG Manager Service
https://app.harness.io/ng-manager/*
NG Manager
HTTPS :443
DB DevOps Service
https://app.harness.io/dbdevops/*
NG Manager
HTTPS :443
SCM Service
https://app.harness.io/scm/*
Delegate
WSS (WebSockets over HTTPS) :443
Delegate Service (CG Manager)
wss://app.harness.io/delegate-service/*
Delegate
gRPC :20001
Lite Engine
Internal (Pod)
Lite Engine
gRPC :20002-Range
Step Container (Pods)
Internal (Pod)
Step Container
DB Driver (Postgres :5432 / Mongo :27017 / MySQL :3306 / etc.)
Target Database
Customer DB
Delegate
HTTPS :443
Git / Artifact Repositories
External URLs
Delegate / Lite Engine
HTTPS :443
googleapis.com (Log Uploads)
External (unless disabled via account setting)
How secrets are sent to build pods
The following steps describe how Harness handles secrets during pipeline execution.
All secret requests are first sent as expressions from Harness to Delegates, where they are decrypted inside the Pod init request.
Decrypted secrets are added as Kubernetes Secrets in the same namespace where build pods are deployed.
Those secrets are referenced inside the Pod definition using imagePullSecrets.
Next steps
You can now create a Harness Pipeline to execute a database change. For more information, Go to Database DevOps page.
Last updated
Was this helpful?