GitHub Actions 및 Terragrunt를 사용하여 API 기반 리소스 오케스트레이션 프레임워크 생성 - 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구모범 사례에픽관련 리소스추가 정보

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

GitHub Actions 및 Terragrunt를 사용하여 API 기반 리소스 오케스트레이션 프레임워크 생성

Tamilselvan P, Abhigyan Dandriyal, Sandeep Gawande, Akash Kumar, Amazon Web Services

요약

이 패턴은 GitHub Actions 워크플로를 활용하여 표준화된 JSON 페이로드를 통해 리소스 프로비저닝을 자동화하므로 수동 구성이 필요하지 않습니다. 이 자동화된 파이프라인은 전체 배포 수명 주기를 관리하고 사용자 지정 UI 구성 요소에서 ServiceNow에 이르기까지 다양한 프런트엔드 시스템과 원활하게 통합할 수 있습니다. 솔루션의 유연성을 통해 사용자는 표준화된 프로세스를 유지하면서 선호하는 인터페이스를 통해 시스템과 상호 작용할 수 있습니다.

구성 가능한 파이프라인 아키텍처는 다양한 조직 요구 사항을 충족하도록 조정할 수 있습니다. 구현 예제는 Amazon Virtual Private Cloud(Amazon VPC) 및 Amazon Simple Storage Service(Amazon S3) 프로비저닝에 중점을 둡니다. 이 패턴은 조직 전반의 요청을 표준화하고 일관된 통합 지점을 제공하여 일반적인 클라우드 리소스 관리 문제를 효과적으로 해결합니다. 이 접근 방식을 사용하면 팀이 표준화를 보장하면서 리소스를 더 쉽게 요청하고 관리할 수 있습니다.

사전 조건 및 제한 사항

사전 조건 

  • 활성 AWS 계정

  • 구성된 리포지토리에 액세스할 수 있는 활성 GitHub 계정

제한 사항

  • 새 리소스는 리포지토리 구성에 terragrunt.hcl 파일을 수동으로 추가해야 합니다.

  • 일부 AWS 서비스 는 전혀 사용할 수 없습니다 AWS 리전. 리전 가용성은 AWS 리전별 서비스를 참조하세요. 특정 엔드포인트는 서비스 엔드포인트 및 할당량을 참조하고 서비스 링크를 선택합니다.

아키텍처

다음 다이어그램은이 패턴의 구성 요소와 워크플로를 보여줍니다.

GitHub Actions 및 Terraform을 사용하여 리소스 프로비저닝을 자동화하는 워크플로입니다.

아키텍처 다이어그램은 다음 작업을 보여줍니다.

  1. 사용자가 GitHub Actions에 JSON 페이로드를 제출하여 자동화 파이프라인을 트리거합니다.

  2. GitHub Actions 파이프라인은 페이로드 사양에 따라 Terragrunt 및 Terraform 리포지토리에서 필요한 리소스 코드를 검색합니다.

  3. 파이프라인은 지정된 AWS 계정 ID를 사용하여 적절한 AWS Identity and Access Management (IAM) 역할을 수임합니다. 그런 다음 파이프라인은 리소스를 대상에 배포 AWS 계정 하고 계정별 Amazon S3 버킷 및 Amazon DynamoDB 테이블을 사용하여 Terraform 상태를 관리합니다.

각 AWS 계정 에는 보안 액세스를 위한 IAM 역할, Terraform 상태 스토리지를 위한 Amazon S3 버킷, 상태 잠금을 위한 DynamoDB 테이블이 포함되어 있습니다. 이 설계를 통해 제어되고 자동화된 리소스 배포가 가능합니다 AWS 계정. 배포 프로세스는 각 계정의 전용 Amazon S3 버킷 및 IAM 역할을 통해 적절한 상태 관리 및 액세스 제어를 유지합니다.

도구

AWS 서비스

  • Amazon DynamoDB는 빠르고 예측 가능하고 확장 가능한 성능을 제공하는 완전 관리형 NoSQL 데이터베이스 서비스입니다.

  • AWS Identity and Access Management (IAM)는 AWS 리소스에 대한 액세스를 인증하고 사용할 수 있는 권한을 부여받은 사용자를 제어하여 리소스에 대한 액세스를 안전하게 관리하는 데 도움이 됩니다.

  • Amazon Simple Storage Service(S3)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.

  • Amazon Virtual Private Cloud(Amazon VPC)를 사용하면 정의한 가상 네트워크에서 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 AWS의 확장 가능한 인프라를 사용한다는 이점과 함께 고객의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사합니다.

기타 도구

  • GitHub Actions는 GitHub 리포지토리와 긴밀하게 통합된 지속적 통합 및 지속적 전달(CI/CD) 플랫폼입니다. GitHub Actions를 사용하여 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있습니다.

  • Terraform은 HashiCorp의 코드형 인프라(IaC) 도구로, 클라우드 및 온프레미스 리소스를 생성하고 관리하는 데 도움이 됩니다.

  • Terragrunt는 OpenTofu 및 Terraform 기능을 모두 확장하는 오케스트레이션 도구입니다. 일반 인프라 패턴이 적용되는 방식을 관리하므로 대규모 인프라 자산을 더 쉽게 확장하고 유지할 수 있습니다.

코드 리포지토리

이 패턴의 코드는 GitHub sample-aws-orchestration-pipeline-terraform 리포지토리에서 사용할 수 있습니다.

모범 사례

  • 보안 액세스를 위해 GitHub 리포지토리 보안 암호를 사용하여 AWS 자격 증명과 민감한 데이터를 저장합니다.

  • 정적 자격 증명을 사용하지 않고 IAM 역할을 수임하도록 GitHub Actions에 대한 OpenID Connect(OIDC) 공급자를 구성합니다.

  • 최소 권한 원칙을 따르고 작업을 수행하는 데 필요한 최소 권한을 부여합니다. 자세한 내용은 IAM 설명서의 최소 권한 부여 및 보안 모범 사례를 참조하세요.

에픽

작업설명필요한 기술

GitHub 리포지토리를 초기화합니다.

GitHub 리포지토리를 초기화하려면 다음 단계를 사용합니다.

  1. 파이프라인 코드를 호스팅할 새 GitHub 리포지토리를 생성합니다.

  2. 소스 리포지토리의 .github/workflows 폴더에 있는 deployment.yml 및 workflow-trigger.yml 파일을 가져옵니다.

DevOps 엔지니어

IAM 역할 및 권한을 구성합니다.

IAM 역할 및 권한을 구성하려면 다음 단계를 사용합니다.

  1. OpenID Connect(OIDC) ID 제공업체(IdP)를 사용하여 GitHub Actions가의 작업에 연결하는 데 AWS 필요한 신뢰 관계를 사용하여 IAM 역할을 생성합니다.

  2. IAM 역할에 필요한 권한을 연결하여 백엔드와 원하는 리소스를 생성합니다. 자세한 내용은 백엔드 Amazon S3 버킷 및 DynamoDB 테이블과 함께 Amazon VPC를 사용하여 VPC를 생성하는 샘플 정책을 참조하세요.

DevOps 엔지니어

GitHub 보안 암호 및 변수를 설정합니다.

GitHub 리포지토리에서 리포지토리 보안 암호 및 변수를 설정하는 방법에 대한 지침은 GitHub 설명서의 리포지토리에 대한 구성 변수 생성을 참조하세요. 다음 변수를 구성합니다.

  • 리포지토리 보안 암호

    • PAT_TOKEN - GitHub 작업을 수행할 수 있는 권한이 있는 개인 액세스 토큰

  • 리포지토리 변수

DevOps 엔지니어

리포지토리 구조를 생성합니다.

리포지토리 구조를 생성하려면 다음 단계를 사용합니다.

  1. main 브랜치에 새 폴더를 생성하여 terragrunt.hcl 파일을 저장하고 리소스 생성 후 출력 및 변경 로그를 저장합니다.

  2. 폴더를 통해 프로비저닝하려는 리소스 유형에 따라 소문자를 사용하여 폴더의 이름을 지정합니다. 폴더는 페이로드의 뒷부분에서 있는 그대로 사용됩니다. 자세한 내용은 리포지토리의 Amazon S3 및 Amazon VPC에 대한 샘플 구조를 참조하세요.

DevOps 엔지니어
작업설명필요한 기술

curl을 사용하여 파이프라인을 실행합니다.

curl을 사용하여 파이프라인을 실행하려면 다음 단계를 사용합니다.

  1. 로컬 디렉터리에 payload.json 파일을 생성합니다. 페이로드 파일에 대해 정의된 구조를 따르고 요청을 제출하기 전에 이를 문자열화합니다. 자세한 내용은 리포지토리의 샘플 페이로드를 참조하세요.

  2. 다음 예제와 같이 GitHub API를 사용하여 터미널에서 요청을 제출합니다.

    curl -X POST \
  -H "Accept: application/vnd.github.v3+json" \
  -H "Authorization: token YOUR_GITHUB_TOKEN" \
  -d @payload.json \
  https://api.github.com/repos/OWNER/REPO/actions/workflows/workflow-trigger.yml/dispatches

    이 예제에서는 다음에 대한 고유한 값을 제공합니다.

    • YOUR_GITHUB_TOKEN GitHub 개인 액세스 토큰 사용

    • OWNER 리포지토리 소유자의 이름으로

    • REPO 리포지토리 이름 사용

파이프라인 실행 프로세스에 대한 자세한 내용은 추가 정보를 참조하세요.

DevOps 엔지니어

파이프라인 실행 결과 검증

결과를 검증하려면 다음 단계를 사용합니다.

  1. 리포지토리의 작업 탭에서 GitHub 작업 워크플로 실행을 모니터링합니다.

  2. 워크플로를 성공적으로 실행한 후 다음과 AWS Management Console 같이를 사용하여 리소스 생성을 확인합니다.

    1. Amazon VPC의 경우:

      • 지정된에서 Amazon VPC 서비스로 이동합니다 AWS 리전.

      • 요청 파라미터와 일치하는 태그가 있는 새 VPC를 확인합니다.

      • CIDR 블록 및 기타 구성을 확인합니다.

    2. Amazon S3의 경우:

      • Amazon S3 버킷으로 이동합니다.

      • 범용 버킷에서 요청 파라미터와 일치하는 새 버킷을 확인합니다.

      • S3 버킷 이름 및 기타 구성을 확인합니다.

terragrunt.hcl 파일과 동일한 리소스 내에 있는 리포지토리에서 생성된 output.json 파일을 사용하여 생성된 리소스를 교차 확인할 수도 있습니다.

DevOps 엔지니어
작업설명필요한 기술

정리 요청을 제출합니다.

더 이상 필요하지 않은 리소스를 삭제하려면 다음 단계를 사용합니다.

  1. 동일한 API 엔드포인트를 사용하여 삭제 요청을 제출하되 다음과 같이 페이로드를 수정합니다.

    • delete에서를 RequestType로 변경합니다RequestParameters.

    • 다른 모든 파라미터는 create 요청과 동일하게 유지합니다.

  2. GitHub Actions에서 삭제 프로세스를 모니터링합니다.

  3. 워크플로가 완료된 후 리소스 폴더 내의 changelog.json 파일에 상태가 표시되는지 확인합니다deleted.

  4. 를 사용하여 리소스 제거를 확인합니다 AWS Management Console.

DevOps 엔지니어

관련 리소스

AWS 블로그

AWS 서비스 설명서

GitHub 리소스

추가 정보

파이프라인 실행 프로세스

파이프라인 실행 단계는 다음과 같습니다.

  1. JSON 페이로드 형식 검증 - 수신 JSON 구성이 올바르게 구성되고 필요한 모든 파라미터가 포함되어 있는지 확인합니다.

  2. 지정된 IAM 역할 수임 - AWS 작업에 필요한 IAM 역할을 인증하고 수임합니다.

  3. 필요한 Terraform 및 Terragrunt 코드 다운로드 - 지정된 버전의 리소스 코드 및 종속성을 검색합니다.

  4. 리소스 배포 실행 - 구성을 적용하여 대상 환경에서 AWS 리소스를 배포하거나 업데이트합니다.

VPC 생성에 사용되는 샘플 페이로드

다음은 Terraform 백엔드 상태 버킷 생성을 위한 예제 코드입니다.

state_bucket_name = "${local.payload.ApplicationName}-${local.payload.EnvironmentId}-tfstate"
lock_table_name = "${local.payload.ApplicationName}-${local.payload.EnvironmentId}-tfstate-lock"

다음은 Amazon VPC를 사용하여 VPC를 생성하기 위한 예제 페이로드입니다. 여기서는 VPC에 대한 CIDR 블록 사양을 vpc_cidr 정의합니다. Terraform 상태 버킷은 terraform 파일에 정의된 변수에 매핑됩니다. ref 파라미터에는 실행할 코드의 브랜치 이름이 포함됩니다.

{
    "ref": "main",
    "inputs": {
        "RequestParameters": {
            "RequestId": "1111111",
            "RequestType": "create",
            "ResourceType": "vpc",
            "AccountId": "1234567890",
            "AccountAlias": "account-alias",
            "RegionId": "us-west-2",
            "ApplicationName": "myapp",
            "DivisionName": "division-name",
            "EnvironmentId": "dev",
            "Suffix": "poc"
        },
        "ResourceParameters": [
            {
                "VPC": {
                    "vpc_cidr": "10.0.0.0/16"
                }
            }
        ]
    }
}

RequestParameters는 파이프라인 섹션에서 요청 상태를 추적하는 데 사용되며이 정보를 기반으로 tfstate 생성됩니다. 다음 파라미터에는 메타데이터 및 제어 정보가 포함됩니다.

  • RequestId - 요청의 고유 식별자

  • RequestType - 작업 유형(생성, 업데이트 또는 삭제)

  • ResourceType - 프로비저닝할 리소스 유형

  • AccountId - 배포 AWS 계정 대상

  • AccountAlias -의 표시 이름 AWS 계정

  • RegionId - 리소스 배포 AWS 리전 용

  • ApplicationName - 애플리케이션 이름

  • DivisionName - 조직 분할

  • EnvironmentId – 환경(예: dev 및 prod)

  • Suffix - 리소스에 대한 추가 식별자

ResourceParameters 에는 Terraform 파일에 정의된 변수에 매핑되는 리소스별 구성이 포함되어 있습니다. Terraform 모듈로 전달해야 하는 모든 사용자 지정 변수는에 포함되어야 합니다ResourceParameters. Amazon VPC의 경우 파라미터vpc_cidr는 필수입니다.