다음을 통해 공유

GitHub Actions를 사용하여 Azure 인프라에 배포

  • 아티클

이 가이드에서는 CI/CD 및 IaC(Infrastructure as Code)를 활용하여 자동화되고 반복 가능한 방식으로 GitHub Actions를 사용하여 Azure에 배포하는 방법을 설명합니다.

이 문서는 아키텍처 개요이며 확장 가능하고 안전하며 복원력이 뛰어나고 고가용성인 Azure에서 애플리케이션을 디자인하기 위한 구조화된 솔루션을 제공합니다. 클라우드 아키텍처 및 솔루션 아이디어 의 실제 예제를 보려면 Azure 아키텍처를 찾아보세요.

배포에 IaC 및 자동화 사용의 이점

Azure Portal, CLI, API 등을 포함하여 Azure에 배포하는 방법에는 여러 가지가 있습니다. 이 가이드에서는 IaC 및 CI/CD 자동화를 사용합니다. 이 방법의 이점은 다음과 같습니다.

  • 선언적: 코드에서 인프라 및 배포 프로세스를 정의할 때 표준 소프트웨어 개발 수명 주기를 사용하여 버전을 지정하고 검토할 수 있습니다. 또한 IaC는 구성에서 드리프트를 방지하는 데 도움이 됩니다.

  • 일관성: IaC 프로세스에 따라 조직 전체가 모범 사례를 통합하고 보안 요구 사항에 맞게 강화되는 인프라를 배포하기 위해 잘 설정된 표준 방법을 따르도록 합니다. 중앙 템플릿의 향상된 기능은 조직 전체에 쉽게 적용할 수 있습니다.

  • 보안: 내부 표준을 충족하기 위해 클라우드 운영 또는 보안 팀에서 중앙에서 관리되는 템플릿을 강화하고 승인할 수 있습니다.

  • 셀프 서비스: Teams는 중앙에서 관리되는 템플릿을 활용하여 자체 인프라를 배포할 수 있습니다.

  • 생산성 향상: 팀은 표준 템플릿을 활용하여 모든 구현 세부 정보를 걱정할 필요 없이 새 환경을 신속하게 프로비전할 수 있습니다.

추가 정보는 Azure 아키텍처 센터의 반복 가능한 인프라 또는 DevOps 리소스 센터의 코드로서의 인프라에서 찾을 수 있습니다.

아키텍처

Architecture overview of using CI/CD to deploy Azure

데이터 흐름

  1. 새 분기를 만들고 필요한 IaC 코드 수정에 검사.
  2. 변경 내용을 환경에 병합할 준비가 되면 GitHub에서 PR(끌어오기 요청)을 만듭니다.
  3. GitHub Actions 워크플로는 코드의 형식이 잘 지정되고 내부적으로 일관되며 보안 인프라를 생성하도록 트리거됩니다. 또한 Terraform 계획 또는 Bicep 가상 분석이 실행되어 Azure 환경에서 발생할 변경 내용의 미리 보기를 생성합니다.
  4. 적절히 검토한 후에는 PR을 기본 분기에 병합할 수 있습니다.
  5. 다른 GitHub Actions 워크플로는 기본 분기에서 트리거되고 IaC 공급자를 사용하여 변경 내용을 실행합니다.
  6. (Terraform 전용) 또한 정기적으로 예약된 GitHub 작업 워크플로를 실행하여 사용자 환경에서 구성 드리프트를 찾고 변경 내용이 감지되면 새 문제를 만들어야 합니다.

필수 조건

Bicep 사용

  1. GitHub 환경 만들기

    워크플로는 GitHub 환경 및 비밀을 활용하여 Azure ID 정보를 저장하고 배포에 대한 승인 프로세스를 설정합니다. 다음 지침에 따라 명명된 production 환경을 만듭니다. production 환경에서 보호 규칙을 설정하고 프로덕션 배포에서 로그오프해야 하는 필수 승인자를 추가합니다. 환경을 기본 분기로 제한할 수도 있습니다. 자세한 지침은 여기에서 찾을 수 있습니다.

  2. Azure ID 설정:

    Azure 구독 내에서 배포할 수 있는 권한이 있는 Azure Active Directory 애플리케이션이 필요합니다. 단일 애플리케이션을 만들고 Azure 구독에서 적절한 읽기/쓰기 권한을 부여합니다. 그런 다음 GitHub가 OIDC(OpenID 커넥트)를 사용하여 ID를 활용할 수 있도록 페더레이션된 자격 증명을 설정합니다. 자세한 지침은 Azure 설명서를 참조하세요. 세 개의 페더레이션된 자격 증명을 추가해야 합니다.

    • 엔터티 형식을 Environment 환경 이름으로 설정하고 사용합니다 production .
    • 엔터티 형식을 .로 Pull Request설정합니다.
    • 엔터티 형식을 Branch 분기 이름으로 설정하고 사용합니다 main .

  3. GitHub 비밀 추가

    참고 항목

    Azure ID에 대한 데이터는 비밀이나 자격 증명을 포함하지 않지만, 환경별로 ID 정보를 매개 변수화하는 편리한 수단으로 GitHub 비밀을 계속 활용합니다.

    Azure ID를 사용하여 리포지토리에서 다음 비밀을 만듭니다.

    • AZURE_CLIENT_ID : Azure에서 앱 등록의 애플리케이션(클라이언트) ID
    • AZURE_TENANT_ID : 앱 등록이 정의된 Azure Active Directory의 테넌트 ID입니다.
    • AZURE_SUBSCRIPTION_ID : 앱 등록이 정의된 구독 ID입니다.

    리포지토리에 비밀을 추가하는 지침은 여기에서 찾을 수 있습니다.

Terraform 사용

  1. Terraform 상태 위치 구성

    Terraform은 상태 파일을 사용하여 관리되는 인프라 및 관련 구성의 현재 상태에 대한 정보를 저장합니다. 이 파일은 워크플로의 여러 실행 간에 유지되어야 합니다. 이 파일을 Azure Storage 계정 또는 다른 유사한 원격 백 엔드 내에 저장하는 것이 좋습니다. 일반적으로 이 스토리지는 수동으로 또는 별도의 워크플로를 통해 프로비전됩니다. Terraform 백 엔드 블록은 선택한 스토리지 위치로 업데이트해야 합니다(설명서는 여기 참조).

  2. GitHub 환경 만들기

    워크플로는 GitHub 환경 및 비밀을 활용하여 Azure ID 정보를 저장하고 배포에 대한 승인 프로세스를 설정합니다. 다음 지침에 따라 명명된 production 환경을 만듭니다. production 환경에서 보호 규칙을 설정하고 프로덕션 배포에서 로그오프해야 하는 필수 승인자를 추가합니다. 환경을 기본 분기로 제한할 수도 있습니다. 자세한 지침은 여기에서 찾을 수 있습니다.

  3. Azure ID 설정:

    Azure 구독 내에서 배포할 수 있는 권한이 있는 Azure Active Directory 애플리케이션이 필요합니다. A 및 read/write 계정에 대한 별도의 애플리케이션을 read-only 만들고 Azure 구독에서 적절한 권한을 부여합니다. 또한 두 역할 모두 1단계의 Terraform 상태가 있는 스토리지 계정에 대한 최소 Reader and Data Access 권한이 필요합니다. 다음으로, GitHub가 OIDC(OpenID 커넥트)를 사용하여 ID를 활용할 수 있도록 페더레이션된 자격 증명을 설정합니다. 자세한 지침은 Azure 설명서를 참조하세요.

    ID의 read/write 경우 다음과 같이 하나의 페더레이션 자격 증명을 만듭니다.

    • Environment 환경 이름으로 설정하고 Entity Type 사용합니다production.

    ID의 read-only 경우 다음과 같이 두 개의 페더레이션된 자격 증명을 만듭니다.

    • Entity Type를 Pull Request로 설정합니다.
    • Branch 분기 이름으로 설정하고 Entity Type 사용합니다main.

  4. GitHub 비밀 추가

    참고 항목

    Azure ID에 대한 데이터는 비밀이나 자격 증명을 포함하지 않지만, 환경별로 ID 정보를 매개 변수화하는 편리한 수단으로 GitHub 비밀을 계속 활용합니다.

    ID를 사용하여 read-only 리포지토리에서 다음 비밀을 만듭니다.

    • AZURE_CLIENT_ID : Azure에서 앱 등록의 애플리케이션(클라이언트) ID
    • AZURE_TENANT_ID : 앱 등록이 정의된 Azure Active Directory의 테넌트 ID입니다.
    • AZURE_SUBSCRIPTION_ID : 앱 등록이 정의된 구독 ID입니다.

    리포지토리에 비밀을 추가하는 지침은 여기에서 찾을 수 있습니다.

    ID를 production 사용하여 read-write 환경에 다른 비밀을 만듭니다.

    • AZURE_CLIENT_ID : Azure에서 앱 등록의 애플리케이션(클라이언트) ID

    환경에 비밀을 추가하는 지침은 여기에서 찾을 수 있습니다. 환경 암호는 상승된 읽기/쓰기 권한이 필요할 때 환경에 배포 단계를 수행할 때 리포지토리 비밀을 재정의 production 합니다.

GitHub Actions를 사용하여 배포

Bicep 사용

참조 아키텍처에는 두 가지 기본 워크플로가 포함되어 있습니다.

  1. Bicep 단위 테스트

    이 워크플로는 모든 커밋에서 실행되며 인프라 코드에 대한 단위 테스트 집합으로 구성됩니다. bicep 빌드를 실행하여 bicep을 ARM 템플릿으로 컴파일합니다. 이렇게 하면 서식 오류가 없습니다. 다음으로 템플릿을 배포할 수 있는지 확인하기 위해 유효성 검사를 수행합니다. 마지막으로 IaC에 대한 오픈 소스 정적 코드 분석 도구인 검사ov가 실행되어 보안 및 규정 준수 문제를 검색합니다. 리포지토리가 GHAS(GitHub Advanced Security)를 사용하는 경우 결과가 GitHub에 업로드됩니다.

  2. Bicep What-If /Deploy

    이 워크플로는 모든 끌어오기 요청과 기본 분기에 대한 각 커밋에서 실행됩니다. 워크플로의 가상 단계는 가상을 실행하여 IaC 변경이 Azure 환경에 미치는 영향을 이해하는 데 사용됩니다. 이 보고서는 쉽게 검토할 수 있도록 PR에 첨부됩니다. 배포 단계는 워크플로가 기본 분기에 푸시하여 트리거될 때 가상 분석 후에 실행됩니다. 이 단계에서는 수동 검토가 로그오프된 후 Azure에 템플릿을 배포 합니다.

Terraform 사용

참조 아키텍처에는 세 가지 기본 워크플로가 포함되어 있습니다.

  1. Terraform 단위 테스트

    이 워크플로는 모든 커밋에서 실행되며 인프라 코드에 대한 단위 테스트 집합으로 구성됩니다. terraform fmt를 실행하여 코드가 제대로 보풀이 되도록 하고 terraform 모범 사례를 따릅니다. 다음으로, terraform 유효성 검사를 수행하여 코드가 구문적으로 정확하고 내부적으로 일관성이 있는지 검사. 마지막으로 IaC에 대한 오픈 소스 정적 코드 분석 도구인 검사ov가 실행되어 보안 및 규정 준수 문제를 검색합니다. 리포지토리가 GHAS(GitHub Advanced Security)를 사용하는 경우 결과가 GitHub에 업로드됩니다.

  2. Terraform 계획/적용

    이 워크플로는 모든 끌어오기 요청과 기본 분기에 대한 각 커밋에서 실행됩니다. 워크플로의 계획 단계는 terraform 계획을 실행하여 IaC 변경이 Azure 환경에 미치는 영향을 이해하는 데 사용됩니다. 이 보고서는 쉽게 검토할 수 있도록 PR에 첨부됩니다. 적용 단계는 워크플로가 기본 분기로 푸시에 의해 트리거될 때 계획 이후에 실행됩니다. 이 단계에서는 계획 문서를 가져와 서 환경에 보류 중인 변경 내용이 있는 경우 수동 검토가 로그오프된 후 변경 내용을 적용 합니다.

  3. Terraform 드리프트 검색

    이 워크플로는 주기적으로 실행되어 Terraform 외부에서 수행된 구성 드리프트 또는 변경 내용에 대해 환경을 검사합니다. 드리프트가 감지되면 프로젝트의 기본tainers에 경고하기 위해 GitHub 문제가 발생합니다.