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 repositories for environments. It could be one repo for all the environments. In that case, they can be split into branches or directories. If we use directories, we would effectively have a monorepo. Neither of those two strategies is a bad one. Those are as valid as any other, but we won’t use them. Instead, we’ll create a separate repository for each environment. As we’ll see later, it’s easy to configure Argo CD to use a different strategy, so don’t take one-repo-per-env as the only option. We just had to chose a method for the examples.

Fork the repo

We’ll need to make some changes to the manifests in that repo. So, please fork the repo.

Next, we’ll clone the newly forked repository.

> Note: Please replace [...] with your GitHub organization in the command that follows. If you forked the repo into your personal account, then the organization is your GitHub username.