Three repositories:
terraformkubernetesapplication_code
In reality, you would likely have multiple application_code repositories - probably one per service, unless you were taking a mono-repo approach.
Hosts your Infrastructure as Code.
Set out as follows:
terraform
├── environments
│ ├── development
│ ├── production
│ └── staging
├── modules
│ ├── aurora_serverless
│ ├── eks_cluster
│ ├── eks_node_group
│ └── vpc
└── services
├── decisioning
└── wallet
modulescontains any group of reusable code, e.g.eks_clusterorvpc.servicescontains any group of infrastructure associated with a given service, e.g. thewalletservice may require an S3 bucket and an RDS instance. Can callmodulesor specify individual infrastructure resourcesenvironmentsis where the infrastructure is "called". References modules created inmodulesandservicesfolders. Any deployment pipeline would use these directories to deploy to different environments, e.g.development
Multiple approaches possible for Kubernetes, such as Helm. This structure uses Kustomize which is now built into the kubectl binary.
- The
basefolder creates resources for each service. Store in here any part of a resource which is shared across all environments, such as the service selectors, pod affinity rules and container resource requirements etc. - The environment folders such as
developmentthen use Kustomize to merge any configuration which is environment-specific, e.g. the container image and any environment variables
Creating a new service in this framework is quite straightforward:
- In the
terraformrepository, create a new folder inservices. Create.tffiles for any resources the new service requires. In each of theenvironments, create amy-new-service.tffile which references the components created in theservicessubfolder you just created - In the
kubernetesrepository, create a new folder for your service in thebasefolder and each of the environment folders. Create your YAML resource definitions in thebasefolder, then any environment-specific configuration in the environment subfolders you just created. Usekustomization.ymlfiles to indicate which YAML files need to be merged - Update the terraform and application pipelines to deploy your new service
My favoured approach is "GitOps". An agent, such as ArgoCD, can sit inside the Kubernetes cluster and continually check the kubernetes repository for any changes to resource definition YAML files. If it sees this change, it applies it to the cluster.
From the application pipeline, all you then need to do is commit a changed image tag to the kubernetes repository and watch the ArgoCD UI to see all of the Kubernetes moving parts (e.g. deployment, then replicaset, then pods).