Some of our clients deploy applications using GitHub Actions.
Common Resources
In the infrastructure repository, create a root module for common CI/CD resources:
Code Block |
---|
infra/
cicd-common/ |
In order to successfully run CI/CD through GitHub Actions, you’ll need:
A role with permission to pull container image from remote (for example, AWS ECR) and to deploy the application to the cluster. You can provision one using the EKS deploy role Terraform module.
This resource should be provisioned in the Operations account.
After adding all necessary modules to your root module, apply the module.
Continuous Integration
For each application repository, resources related to the CI Job should be provisioned in the Operations Account.
Code Block |
---|
infra/ ciapplications/ APPLICATION/ operations/ |
In order to build Docker images for an application, you'll need:
A Dockerfile. This can be kept in the application repository.
An ECR repository. You can use the ECR repository Terraform module to set this up.
Code Block module "ecr_repository" { source = "github.com/thoughtbot/terraform-eks-cicd//modules/ecr-repository?ref=v0.1.0" name = "example-org/example-app" # AWS accounts allowed to pull this image workload_account_ids = [ "123456789010", # Sandbox account ID "123456789010", # Production account ID ] }
An IAM OIDC provider which trusts your GitHub Actions workflow. If you used the landing zone template, one will already be created in the Operations account and you can locate its ARN using the SSM parameter /GitHubActions/OIDCProviderArn.
An IAM role that can be assumed by GitHub using OIDC and access ECR in order to push your built Docker image. Example here..
Code Block module "ecr_role" { source = "github.com/thoughtbot/terraform-eks-cicd//modules/github-actions-ecr-role?ref=v0.1.1" allow_github_pull_requests = true ecr_repositories = [module.ecr_repository.name] github_branches = ["main", "production"] github_organization = "example-org" github_repository = "example-app" iam_oidc_provider_arn = data.aws_ssm_parameter.iam_oidc_provider_arn.value name = "github-actions-ecr-example" depends_on = [module.ecr_repository] } data "aws_ssm_parameter" "iam_oidc_provider_arn" { name = "/GitHubActions/OIDCProviderArn" }
Once this root module is applied, create GitHub Actions job(s) to build Docker images and generate manifests (example here). These Actions can be triggered when pull requests are opened by defining triggers in the Job itself.
...
Code Block |
---|
infra/ cd/ APPLICATION/ |
An IAM OIDC provider which trusts your GitHub Actions workflow. If you used the landing zone template, one will already be created in workload accounts and you can locate its ARN using the SSM parameter /GitHubActions/OIDCProviderArn.
An IAM role that can be assumed by GitHub using OIDC and deploy to each cluster Example here. Example here.A manifests repository to store configuration and manifests for your application. You can use the github-actions-eks-deploy Terraform module.
Code Block module "deploy_role" { source = "github.com/thoughtbot/terraform-eks-cicd//modules/github-actions-eks-deploy-role?ref=v0.1.1" cluster_names = ["example-sandbox-v1"] github_branches = ["main"] github_organization = "example-org" github_repository = "example-app" iam_oidc_provider_arn = data.aws_ssm_parameter.iam_oidc_provider_arn.value name = "example-staging-deploy" } data "aws_ssm_parameter" "iam_oidc_provider_arn" { name = "/GitHubActions/OIDCProviderArn" }
Helm or Kustomize manifests to describe how the application should run in the Kubernetes cluster.
A GitHub Actions Job for deploying the latest Docker images and manifests to the cluster. Example for Fulfillment here.A buildspec for generating application manifests. This can be stored in the manifests repository and should contain Kustomize or Helm commands for generating Kubernetes manifests . This buildspec must produce YAML files as artifacts that can later be applied to the cluster to deploy the application.
Once a GitHub Actions Job is successfully created, it will be triggered to deploy your application whenever a pull request is merged. The artifacts from the manifest project will be provided to the deploy job, which can apply the manifests to the cluster.