Managing Multiple Environments With Weave GitOps

My previous blog post provided an introduction to GitOps and a guide on how to get started with Weave GitOps Core. This follow-on post explains how to use GitOps to manage a single application deployed into multiple environments, for example, staging and production.

There are many ways application environments can be separated. Different namespaces within a single cluster, different clusters within a single cloud provider or different clusters across multiple cloud providers and/or bare metal. Managing multiple application instances across multiple environments is also known as Application Portability and it’s a non-trivial task to accomplish effectively. There are many challenges to overcome including configuration management, identity and access management, and networking. 

GitOps with its single source of truth simplifies configuration management. Because GitOps runs inside the Kubernetes clusters it significantly reduces the need for direct access to the clusters which simplifies identity and access management. Utilising a service mesh such as Linkerd enables policy control of network traffic.

Strategies

There are essentially two strategies for managing different configurations of the same application in different environments.

Branches

Probably the first one that springs to mind is using different Git branches for each environment. This alternative is supported by Weave GitOps, the branch to monitor can be set when the application is added.

$ gitops add app –branch=staging –name=my-app-staging

Using different branches is the easiest to implement, however, it can present some challenges when merging changes from one environment branch to the other e.g. staging to production. You do not want to accidentally merge into production the configuration for a staging data store. There are ways to avoid this for example by putting the data store configuration in a separate file and adding an entry to gitignore; it’s a bit of kludge though.

Kustomize

Kustomize uses a base configuration then applies overlays for different environments. It’s beyond the scope of this article to delve into finer points of Kustomize. Weave GitOps has native support for Kustomize, just as kubectl does. The overlay subdirectory can be specified when the application is added.

$ gitops add app –path=prod –name=my-app-prod

Using Kustomize requires a little more effort and complexity to implement but ultimately provides greater flexibility while reducing the risk of accidentally merging in a staging configuration into a production environment.

For my simple example, I modified the deployment manifest in both environments to change the background colour of the Podinfo sample application. Staging has a rather vibrant green background while production is a more sombre mid gray.

Under the Covers

There’s no magic smoke and mirrors required to get this working, it’s just a bunch of YAML files arranged in a structured hierarchy of directories. This is why it’s required to specify a unique name for each application and environment pairing, as shown in the examples above.

The structure above was created by Weave GitOps when adding the same application to two different environments. These files in the main branch of the Git repository are continually monitored and reconciled with Kubernetes.

The applications show up in the web dashboard under the names specified.

Watch a short video explaining this in more detail.

GitOps Is the Answer

This basic example shows how easy it is to manage the same application in different environments with different configurations using Weave GitOps. There’s no change to the day-to-day workflows of DevOps engineers, they continue to make changes, push them to Git and create a Pull Request for approval, and, ultimately, merging. Once merged into the monitored branch Weave GitOps will reconcile the changes in Kubernetes. Immediate and consistent deployments across multiple environments.

Find out more and get started with Weave GitOps today.