ministryofjustice / cloud-platform-environments

cloud-platform-environments Intro This repository is where kubernetes namespaces are managed, across all the clusters. Kubernetes namespaces and resources are defined in the directory in this repository under the corresponding name. Functionality The pipeline will for each defined : • Create a namespace as defined in the namespaces/ directory. If the namespace already exists on the cluster it will be ignored. • Delete any namespaces that exist in the cluster but are not defined in the repository. • Create any kubernetes resource that is defined under namespaces/ / Namespaces The directory contains sub directories named after the existing cluster names, and inside, sub directories named after each of the desired namespaces you want to create for each cluster. Placed inside are the kubernetes resource files you want to create in the kubernetes format. Those will be created automatically after a push is made to the Repositories master branch by the AWS code pipeline. AWS resources In a similar fashion as namespaces, you can create AWS resources in your desired namespace. The file structure for that is namespaces/ / /terraform/ and Terraform files should be placed in that route for the pipeline to be triggered and create those AWS resources. Different terraform modules exist, for example: ECR credentials, S3 bucket, and should be used to create these resources as follows: Changes within namespaces Changes within namespaces directory are managed by the concourse job configured here. GitHub triggers the build process using webhook. Build itself runs script checking for last commit changes, and if it detects any within namespace folder it executes with appropriate cluster(s) parameter. Example terraform file concourse-ci/status Check There are occasions where Terraform in the code/pipeline plan will return something like the following which appears to remove policy config. However examination of the plan will reveal that it has been re-added by terraform