Defining Whole Environments

What do we need?

We need at least three distinct types of definitions. We need to define a manifest for each of the applications we’re working on. We’ve already got that. We saw the manifest of the devops-toolkit app. As a matter of fact, we saw two manifests of the same app, one in the “pure” Kubernetes YAML format, and one as a Helm chart.

However, we’re missing one more. We need manifests of whole environments (e.g., production). Those can be split into two groups. We need a way to define references to all the apps running in an environment with all the environment-specific parameters. We also need environment-specific policies like, for example, the namespaces in which the apps can run, quotas and limits, allowed types of resources, and so on.

All in all, we need:

• Application-specific manifests
• Environment-specific manifests

We already have the first group, so let’s explore the second. While we’re at it, let’s try to automate everything instead of relying on the “SYNCHRONIZE” and similar buttons. After all, UIs are supposed to help us gain insights, not convert us into button-clicking machines.

So, we need environment-specific manifests. Given that an environment usually contains more than one application, we can’t have those in a repo of one of the apps. So, it makes sense to keep separate ...