General
Harness’s most common use case is as a SaaS (software as a service), but some customers, for regulatory and security reasons, select to run Harness in self-managed software on their own hardware or cloud VPC.
Kots provides a complete deployment solution for Harness on Kubernetes or without it and includes configuration management, package management, license management, monitoring, backup, and error reporting.
For customers that already have in-house Kubernetes clusters, and require only configuration and package management, Kots integration with GitOps provides an industry-standard solution. Additionally, Kots with gitops allows all production application YAML to be approved before deployment using merge requests as approval steps in software deployment.
How does it work?
Kots with GitOps turned on will not deploy Harness to a specific cluster, but will allow deployments to be downloaded and configured for. This includes fetching Harness deployment files (in connected mode), processing the deployment file, uploading Harness images to the local repository, processing configurations, and depositing the final files to a git repository.
Once kots is enabled for gitops, the entire Harness application YAML will be committed to a git branch. Each time a Harness application change takes place, including deployment, a new commit to git will take place.
A gitops tool like Flux, Jenkins X, or Harness will monitor git, and upon seeing a new commit will deploy it to the production cluster. This way, any changes or deployment in pre-prod are passed to prod via automated pipeline with, or without approval. As an operator deploying Harness via GitOps, it is your responsibility to bring an existing GitOps pipeline for deploying YAML from your git repo to your cluster(s).
gitops options
Approval
To implement an approval step, it is possible for Kots to commit all code to a dev branch while configuring the gitops tool to pull production code from the master branch. In between, each commit will need to be merged to master using a merge request or pull request, allowing for code review and approval.
Similarly, images committed to the docker repository can be scanned and approved before being promoted for deployment.
Support for multiple environments with local customization
It is possible to use Kots and gitops for multiple environments. Each environment might be slightly different and include a different number of replicas, memory settings, or a different image registry.
In such a pipeline, Kots will unpack Harness images and code to the dev branch.
Each environment will merge the commit from the dev branch to its own branch. Each environment branch will have one or more kustomize files in their respective branch to provide environment-specific customizations.
Dare to compare
What are the main advantages of using gitops?
- Uses of familiar software development tools (git) for configuration managements and approval
- Can be used to deploy the same code to multiple environments, while keeping them in sync via automation
- Changes between environments captured in code and git using kustomize
- Allows running in air-gapped environments where the registry is read-only
What are the disadvantages of using gitops?
- gitops setup is the customer responsibility and requires knowledge beyond the standard Harness installation
- Is not supported in Harness Embedded installation, and requires the customer to manage their own Kubernetes cluster
- Since Kots will not be installed in Prod, Kots services are not included. These include the support bundle, Prometheus, Grafana, and Velero. The customer will be responsible for log aggregation, monitoring, and backup
Summary
The use of Kots gitops and Harness allows for a robust deployment mechanism that can keep environments updated with local customization with automation, approval, and ease of use. This allows Harness customers flexibility in their Harness deployment model, and adherence to compliance, testing, and approval pipelines.