Harness GitOps Agent architecture
This topic describes the Harness GitOps architecture.
Harness GitOps has two components:
Harness GitOps service: A REST-based service to manage the GitOps deployment.
Harness GitOps Agent: The worker process responsible for GitOps tasks along with Argo CD components.
Harness GitOps supports Argo CD as the only GitOps reconciler. Flux is not supported.

The following sections describe the Harness GitOps Agent architecture.
Harness GitOps Agent has four components:
GitOps Agent: Harness component
Application controller: Argo CD component
Repo server: Argo CD component
Redis cache: Argo CD component
GitOps Agent
GitOps Agent is a Harness owned and managed worker process responsible for:
Executing GitOps tasks along with the Argo CD Components. Tasks are CRUD events triggered from the UI like creating, reading, updating, or deleting a connection to the repository from where Harness reads the manifests or to a cluster where you want to deploy.
Interacting with Argo CD components to fulfill these tasks. For example, interacting with the repo server for fetching the branches released from a repository, or with the application controller when a user creates an application.
Serving as an entry point to the customer’s premises.
Updating Harness SaaS with GitOps-related details by establishing an outbound connection to the Harness GitOps service.
Application controller
The application controller is an Argo CD component responsible for:
Continuously monitoring the applications.
Comparing the live state against the desired state.
Detecting application state and optionally taking corrective action.
Repo server
The repo server is an Argo CD component responsible for:
Downloading manifests from the repository.
Generating and returning the Kubernetes manifests when asked by the application controller.
Redis cache
Redis cache is an Argo CD component responsible for caching data required by the repo server.

Last updated
Was this helpful?