GitOps.
This projects represents the main IT architecture/governance configuration for managing a cluster for various teams with different Kubernetes/OpenShift capabilities. Using the GitOps approach.
It uses primarily OpenShift GitOps which includes ArgoCD.
The main objective is, to have one place for managing the Kubernetes/OpenShift cluster the GitOps way. This includes the following use cases
-
bootstrap the existing cluster with main/base capabilities like Pipeline support, Secrets Management or similar
-
manage the teams and apps which includes the namespaces and corresponding pipeline configurations
-
governance all other IT architecture and governance related policies
All use cases (features/capabilities) will be handled with OpenShift GitOps/ArgoCD. This allows flexible modification and expansion of the capabilities.
This solution contains the following components
-
governance: the bootstrap configuration
-
governance/cluster-configs.json: the cluster configuration
-
argocd-project-template: the standardized project template as ArgoCD configuration which will be applied for the teams/apps
-
tekton: Base Tekton task and pipeline definitions
The initial bootstrap will be started with applying the Kubernetes manifest files from governance. This installs the OpenShift GitOps operator if necessary and register a new ArgoCD ApplicationSet
listening on the governance/cluster-configs.json, which contains the configuration for all the cluster capabilities (like Operators, SonarQube or similar) and to maintained applications.
This approach allows a very simple extension of the capabilities (aka ArgoCD applications).
In Figure 1 we see the relationship of the main components (ArgoCD and Kubernetes resources) for one team/project.
The governance
ApplicationSet
holds all common applications, including the gov-teams
which represents the configuration for all teams/projects.
Every team receives
-
a
cicd
namespace holding the Tekton resources, -
the environment related namespaces (e.g. for test, int, prod)
-
and ArgoCD
Applications
managing the resources in the dedicated namespaces
The configuration for a team/project is defined in argocd-project-template/values.yaml. Relevant are the main attributes for
-
Git configuration (repo, revision)
-
name of the
config.json
-
the individual namespaces
Any team has the same structure, see Figure 2.
And Figure 3 give an impression about the relationship to the git repositories.
This chapters list all the available features in this setup
-
uses ArgoCD for the cluster configuration reconciliation
-
manages all cluster capabilities in a JSON file which is the base for
ApplicationSet
-
creates for any team/project an own
ArgoCD
andProject
instance -
bound git repo of the team to the ArgoCD Project instance for more/better multi-tenant restriction
-
define policies and groups which limit the access to the ArgoCD resources
-
creates a project structure in OpenShift with predefined namespaces + an additional namespace for all the pipeline resources
-
configures ArgoCD to exclude
PipelineRun
andTaskRun
, this allows to manually execute/run such runs (for testing) -
Optimize ArgoCD and enable only selective synchronization (out-of-sync) instead always all resources
-
enable Prometheus monitoring for the ArgoCD resources
$ helm template gov governance --output-dir=work/gov $ oc apply -f work/gov/argocd/templates
Rest only via modification of the manifest files in the directory. E.g.
-
adding new teams/project ⇒ argocd-project-template/values.yaml
-
add a new capability to the cluster (e.g. HashiCorp Vault instance) ⇒ governance/cluster-configs.json
-
Enhance/Fix Tekton pipeline definitions ⇒ tekton
-
Set NetworkPolicies for all projects, but transparent from the dev teams ⇒ argocd-project-template
GitOps and IT-Governance to manage a Kubernetes/OpenShift cluster for various teams and capabilities.
-
Managing GitOps control planes for secure GitOps practices - https://developers.redhat.com/articles/2021/08/03/managing-gitops-control-planes-secure-gitops-practices
N/A
This article is licensed under the Apache License, Version 2. Separate third-party code objects invoked within this code pattern are licensed by their respective providers pursuant to their own separate licenses. Contributions are subject to the Developer Certificate of Origin, Version 1.1 and the Apache License, Version 2.
See also Apache License FAQ .