In this section we are going to set up a lot of things. We are going to use helm with Argo CD. We are going to need at least 3 types of definitions and we need to define a manifest for each of the applications we are going to work on, and manifests of the whole environment (such as production or preview).
Environment manifests can be split into two groups. We need a way to define references to all the apps that are running in an environment with all of it’s environment specific parameters.
We also need environment specific policies - For example namespaces, quotas, limits, allowed types of resources, IAM, etc.
| Environment Manifests |
|---|
| Application-specific manifests |
| Environment-specific manifests |
We have already learned about application specific manifests so we are going to focus on Environment specific manifests.
UIs are really only supposed to help us gain insights, not convert humans into button clicky clacky mindless machines. If you know anything about me, UI’s and design matters. So for a tool to be a good option, it has to have a great UI and argo nails it. However, the UI is more for the end customer (developers) and for triage purposes, not for routine operations.
As such, we are going to try to automate everything instead of using clicky buttons to synchronize our environments. I know some of you are thrilled pink about this.
Environments usually contain more than one application - we can not have those in a repository of one of the applications.
It could be 1 repo for all environments with a branch for each environment or even directories for each environment. If we use directories, it’d basically be a gross monorepo - let’s avoid that. While neither of these strategies are “bad”, they are still valid.
I want the best one for developer experiences and since I get to pick we are going to create a separate repository for each environment.
As you will see later, Argo makes it easy to use a different approach so don’t take this as the “ONLY” way, just the best way as Drew sees it for his use cases.
Fork this repo: https://github.com/DrewKarr/environments. If you don’t know how to fork a repo, shame on you. Google it. lol. No seriously, here is a link to a solid resource on forking a project: https://docs.github.com/en/get-started/quickstart/fork-a-repo
Clone your newly formed repository
Run the following command, set the GH_NAME to your github repository account name, mine is drewkarr
export GH_NAME=drewkarr
git clone <https://github.com/$GH_NAME/environments.git>
cd environments
We need to find a way to restrict the environment. As I previously mentioned we may also need to be able to define which namespaces can be used, which resources are allowed to be created, what the quota limits are, etc...
We can do some of those things using standard kubernetes resources.