Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

Some of our clients deploy applications using GitHub Actions.

Continuous Integration

For each application repository, resources related to the CI Job should be provisioned in the Operations Account.

infra/
  applications/
    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.

    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.

    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. These Actions can be triggered when pull requests are opened by defining triggers in the Job itself.

GitHub Actions will start building and pushing Docker images for your application to ECR whenever developers open pull requests.

Continuous Deployment

For each stage of the software development lifecycle, create a GitHub Actions workflow in your application repository to deploy the latest images and manifests to the cluster. These Actions can be triggered when pull requests are opened by defining triggers in the Job itself. Resources related to the workflow should be provisioned in the Operations account.

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. You can use the github-actions-eks-deploy Terraform module.

    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.

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.

  • No labels