This is a personal project to test some tools that I want to learn in a hands-on manner.
This project contains two main folders:
Contains the application code. Each service has its own folder.
utils folder contains Go packages used by microservice code.
Contains the Terraform code and K8 manifests divided by different stages:
- 1-base-stage: This stage deploys the AWS networking needed for the project(VPC,subnets,endpoints, etc) and some resources like KMS keys and IAM roles.
- 2-eks-cluster-stage: This stage creates the EKS cluster and deploy the first kubernetes resources like, flux CRD, namespaces, nginx-ingress. This stage defines the core resources for the project.
- 3-k8-common-stage: This stage deploys k8 and AWS resources that are used for the whole environment.
- 4-workloads-stage: This stage contains the infrastructure for the services to deploy, each service has its own folder where the TF code is defined based on the infrastructure requirements.
Deployment is done per stage, all the stages uses a GitHub workflow template that executes terrafrom. The template can be found in ./github/workflows/template-run-terraform. The following Diagram shows in high level the stages executed.
- The bash script that detect the folders updated and generated the array can be found in _.github/jobs/detect-folders-updated.sh
- The bash script to configure the Terraform backend is located in .github/jobs/terraform-backend.sh.
- Terraform Plan and Apply have benn configure as a composite action located in **_./github/actions.
The following image shows in high level some kubernetes resources used:
The K8 manifest for each stage can be found in a folder named k8-manifests, these are pushed to GitHub by Terraform and FluxCD create/delete them in the Kubernetes cluster.
The app folder contains the different services to deploy. Each service has its own Dockerfile that is used to build the image and push it to AWS ECR to be used by the pods.
There is a main workflow that is triggered when new changes are detected in the app folder. The workflow can be found in ./github/workflows/service-build-push-${ENVIRONMENT}.
This calls a workflow tamplate that can be found in _./github/workflows/template-service-deploy. The following image shows the steps executed by the template:
- Set up Docker Buildx: This step installs and configures docker Buildx used to build the Docker image.
- Build image: Docker build command is executed iniside the folder name passed in the previous job.
- Image security scanning: Trivy is used as a security scanning tool.
- Upload to Github Security report: The report generated by Trivy is converted to SARIF format and uploaded to Github fo review then.
- Validate severity: If the severity of the vulnerabilities found by Trivy is HIGH or CRITICAL, the pipeline will fail.
- Push to AWS ECR: The image is tagged and pushed to AWS ECR.
The destroy process can be done by a GitHub workflow. This must be executed manually, where you can choose which stage to destroy. To avoid dependency errors, please execute the job for the microservices first, then destroy the EKS cluster, and finally the base stage.
The name of the workflow is DESTROY INFRASTRUCTURE. Inside the workflow, you can choose the branch and the stage to execute.