An example of using GitOps for providing a modern application development platform

The yaml configuration above retrieves the value for the secret key, which is stored as awsSecretAccessKey in the AWS Secrets Manager.

Now, you have documented the desired state in the Git repo, which can always be rolled back as no changes to the infrastructure are done imperatively using the CLI for the OpenShift cluster.

When building a platform for your application teams, you will be faced with two questions:

- How might the OpenShift cluster be configured declaratively?
- How might new software development teams be onboarded onto the cluster?

As per the GitOps principle, everything will be managed as code. So, Git repository permissions should be maintained to not allow changes by anyone outside the platform team. Any changes requested by developers for onboarding onto the platform should be done by opening a pull request.

Here is an illustration of how we have used GitOps principles to configure our lab OpenShift setup at Amanox.

The building blocks for enabling declarative cluster configuration are as follows:

Helm-Charts: These are like a package manager for Kubernetes applications described as a set of Kubernetes resources.

Kustomize: It manages different variations of your application configuration without modifying the original YAML files.

The „App of Apps“-Pattern: A parent app deploys multiple child apps.

ArgoCD-Applications: These are Kubernetes resources that define the source (Git repository) and destination (target cluster) for automated delivery of your applications.

ArgoCD ApplicationSets: These are ArgoCD resources for automated generation of ArgoCD Applications based on templates and sources like Git repositories, cluster lists, etc.
The Helm charts are represented as shapes (squares, triangles, etc.) which configure certain parts of the cluster with certain parameters. These parameters can be customized or patched depending on the environment where these need to be installed. This is done by using overlays to patch certain base configurations to these target environments. These could, for example, be different cluster environments representing test, dev, or a prod environment, if these were to be completely isolated.

See a simplified depiction of this concept below which shows three different environments being configured differently based(color-coded) on the base configurations. The base configurations in turn contain different Kubernetes resources configured using Helm or ArgoCD applications. Imagine the overlays like pizza toppings. Your base configuration is like a pizza base and different toppings define the final type of your pizza. A margherita will have different toppings than a napolitana. Similarly, the parameters to be patched in the target environments will differ. Consequently, you can reuse the code for configuring different environments.

One of the things the cluster configuration also does is create namespaces in the cluster for application teams, which we call tenant onboarding. Imagine them as cubicles in a co-working space, where you get to work in them and also use other services like the pantry or the lounge that is shared by other co-workers. Similarly, the tenants will get their own namespace and use the worker nodes or the Tektin/ArgoCD instance, used to build/deploy their applications, shared with other tenants. This, in turn, enables self-service capabilities for your development teams. The workflow could look like this:

The application team will create a pull request to onboard themselves by providing information (parameters) pertaining to them like the AD group to which their team belongs, the number and names of the different environments needed, the repo for their application source code, and Kubernetes application manifests defining their CI/CD pipeline.

Upon adding a tenant parameter file to the Git repo, which could look as follows:

The platform team can easily start by maintaining the cluster configuration,
perform a failover to a warm stand-by cluster and enable their application development teams to quickly start using OpenShift for developing new software. Learn more about a customer success story who adopted OpenShift to modernise their DotNet based Applications: Success Story Galliker.