배포 미리 보기 및 승인

완료됨

지금까지 워크플로 작업과 Bicep 코드의 유효성을 검사하는 워크플로 작업을 추가하는 방법을 알아보았습니다. 배포에 대한 신뢰도를 높이는 다음 단계에서는 배포를 통해 무엇이 변경되는지 정확하게 확인하는 또 다른 작업을 추가합니다.

이 단원에서는 워크플로에서 what-if 명령을 사용하는 방법을 알아봅니다. 배포를 실행하기 전에 명령의 출력을 수동으로 확인할 수 있도록 환경 보호 규칙을 추가하는 방법에 대해서도 알아봅니다.

가상 작업

Bicep 파일은 배포가 완료되었을 때 원하는 Azure 상태를 설명합니다. 배포를 제출하면 Azure Resource Manager는 Bicep 파일에 설명된 상태와 일치하도록 Azure 환경을 변경합니다.

배포를 통해 새 리소스가 환경에 배포되거나 기존 리소스가 업데이트될 수 있습니다. 배포를 전체 모드로 실행하면 기존 리소스가 삭제될 수도 있습니다.

리소스가 생성, 업데이트 또는 삭제될 때마다 예상하지 않은 방식으로 변경될 위험이 있습니다. 정확하게 무엇이 생성, 업데이트 및 삭제되는지 확인하는 추가 단계를 추가하는 것이 좋습니다. 이 확인은 자동화 프로세스의 가치를 높입니다. 프로덕션 환경에 배포하는 경우에는 환경에 적용되는 변경 내용이 있는지 확인하는 것이 중요합니다.

Resource Manager는 워크플로 작업 내에서 Bicep 파일에서 실행할 수 있는 what-if 작업을 제공합니다.

arm-deploy 작업은 additionalArguments 속성을 사용하여 가정 작업 트리거를 지원합니다.

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

강조 표시된 코드는 --what-if 인수가 포함된 Azure CLI를 사용하여 배포를 실행하는 것과 같습니다.

가상 작업은 환경을 변경하지는 않고 대신, 생성되는 리소스, 업데이트되는 리소스 속성 및 삭제되는 리소스에 대해 설명합니다.

what-if 작업은 변경이 실제로 발생하지 않았는데 리소스가 변경될 것으로 보여 주는 경우가 있습니다. 이 유형의 출력을 ‘노이즈’라고 합니다. 관련 문제를 줄이기 위해 노력하고 있지만 여러분의 도움이 필요합니다. what-if 문제를 보고합니다.

what-if 작업의 출력이 표시되면 배포를 계속할지 여부를 결정할 수 있습니다. 이 단계에는 일반적으로 사람이 what-if 명령의 출력을 검토한 다음, 확인된 변경 내용이 적절한지 결정하는 과정이 포함됩니다. 사람 검토자는 변경 내용이 합리적이라고 판단되면 워크플로 실행을 수동으로 승인할 수 있습니다.

가상 명령에 대한 자세한 내용은 Microsoft Learn 모듈 가상을 사용하여 Azure 배포 변경 내용 미리 보기를 참조하세요.

환경

GitHub Actions에서 ‘환경’은 솔루션이 배포되는 위치를 나타냅니다. 환경은 복잡한 배포를 작업할 때 도움이 되는 기능을 제공합니다. 환경 및 환경에서 제공하는 기능에 대한 자세한 내용은 뒤에 나오는 모듈에서 알아보겠습니다. 지금은 워크플로에 필요한 검토자를 추가하는 기능에 대해 집중적으로 설명합니다.

GitHub 웹 인터페이스를 사용하여 환경을 만듭니다. 퍼블릭 GitHub 리포지토리로 작업하거나 GitHub Enterprise 계정을 사용할 때 환경을 만들 수 있습니다.

환경을 만든 후에는 워크플로의 모든 작업에서 참조할 수 있습니다.

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

참고 항목

배포 워크플로의 워크로드 ID가 환경 내에서 Resource Manager와 상호 작용하는 경우 환경 이름으로 구성된 페더레이션 자격 증명이 필요합니다. 환경은 뒤에 나오는 모듈에서 알아보겠습니다. 이 모듈에 대한 연습을 실행할 때 필요한 페더레이션 자격 증명을 만듭니다.

환경 보호 규칙

환경을 만든 후에는 ‘보호 규칙’을 정의할 수 있습니다. 보호 규칙은 단계에서 환경을 사용하기 위해 반드시 충족해야 하는 조건을 확인하는 데 사용됩니다. ‘필수 검토자’ 보호 규칙은 사용자가 수동 승인을 제공해야 하는 검사 유형입니다.

보호 규칙은 워크플로가 아니라 환경에 정의됩니다. 워크플로 YAML 파일의 작성자는 이러한 보호 규칙을 제거하거나 추가할 수 없습니다. 리포지토리의 관리자 또는 계정 소유자만 환경과 해당 보호 규칙을 관리할 수 있습니다.

환경 보호 규칙은 적절한 사용자가 배포 프로세스에 관여하는지를 확인하는 데 도움이 됩니다.

환경 보호 규칙의 작동 방식

환경을 단계와 연결하는 경우 환경의 보호 규칙은 단계가 시작되기 직전에 평가됩니다.

필수 검토자는 보호 규칙의 한 가지 유형입니다. 필수 검토자 보호 규칙을 구성할 때 워크플로의 연속을 승인해야 하는 GitHub 사용자를 한 명 이상 할당합니다.

환경에서는 다른 유형의 보호 규칙도 제공합니다. 예를 들어 배포할 수 있는 Git 분기를 특정 환경으로 제한할 수 있습니다. 이 모듈에서는 필수 검토자 규칙만 다루지만, 요약의 다른 보호 규칙에 대한 자세한 정보를 포함하는 링크를 제공합니다.

워크플로가 시작되고 검토자가 필요한 단계에 도달하면, 워크플로 실행이 일시 중지됩니다. 검토자로 지정된 모든 사용자에게 GitHub 및 이메일로 메시지가 전달됩니다.

검토자는 what-if 작업에서 검색하는 변경 내용과 같은 워크플로 로그를 검사할 수 있습니다. 승인자는 이 정보에 따라 변경 내용을 승인하거나 거부합니다. 이들이 변경을 승인하면 워크플로가 다시 시작됩니다. 거부하거나 시간 초과 기간 내에 응답하지 않으면 작업이 실패합니다.

모범 사례의 중요성

GitHub의 환경 기능은 배포를 환경에 연결하는 기능을 제공합니다. 연결된 배포는 환경 관리자가 정의한 보호 규칙을 상속합니다. 그러나 새 워크플로에서 반드시 환경을 사용해야 하는 것은 아닙니다.

조직이 워크플로 정의를 검토하는 모범 사례를 수립하는 것이 중요합니다. 예를 들어 분기 보호 규칙을 사용하여 필수적으로 주 분기의 변경 내용에 대한 끌어오기 요청을 검토하도록 리포지토리를 구성합니다. 이 개념은 후속 모듈에서 좀 더 알아보겠습니다.

환경에 ‘비밀’을 추가할 수도 있습니다. 이렇게 하면 해당 환경도 사용하는 작업에서만 비밀을 사용할 수 있습니다. 환경 보호 규칙과 비밀을 결합하여 워크플로 보안이 유지되도록 할 수 있습니다.