배포 후 리소스 테스트

• 6분

Bicep 배포의 유효성을 검사하고 미리 본 덕분에 Bicep 파일이 성공적으로 배포될 것이라고 자신할 수 있게 되었습니다. 하지만 배포만으로 끝이 아닙니다. 배포가 완료되면 예상한 대로 배포되었는지 확인하는 것도 도움이 됩니다.

이 단원에서는 배포가 완료된 후에 실행할 수 있는 테스트에 대해 알아봅니다. 또한 배포가 예상대로 되지 않는 경우 배포를 롤백하는 방법을 알아봅니다.

스모크 테스트 및 부정 테스트 실행

Bicep 파일에서 리소스를 정의할 때 목표는 Azure에서 리소스를 만드는 것만이 아닙니다. 조직의 요구 사항을 충족하면서 조직에 가치를 제공하는 것입니다. Bicep 파일의 유효성을 검사하고 미리 보면 다시 한번 리소스 정의가 유효하다는 자신감을 얻을 수 있습니다. 그러나 사용자가 원하는 것을 리소스에서 실제로 수행한다는 것을 반드시 알 필요는 없습니다.

예를 들어 Bicep 배포 워크플로를 사용하여 새 Azure SQL 논리 서버를 배포한다고 가정하겠습니다. 서버의 Bicep 정의가 유효하므로 Linter 및 실행 전 유효성 검사 작업이 전달됩니다. 가상 명령은 서버가 생성된다는 것을 보여주며, 이는 사용자가 원하는 것입니다. 배포도 성공적으로 완료됩니다. 그러나 배포 프로세스가 완료되어도 정상적으로 작동하는 즉시 사용 가능한 데이터베이스 서버가 아직 없을 수도 있습니다. 그 이유는 다음과 같습니다.

• 네트워크 트래픽이 서버에 도달할 수 있도록 방화벽 규칙을 구성하지 않았습니다.
• 없으면 서버에서 Microsoft Entra 인증을 사용하도록 설정했거나 그 반대의 경우도 마찬가지입니다.

기본 Bicep 파일만 배포하는 경우에도 배포하는 리소스가 실제로 작동하고 요구 사항을 충족하는지 확인하는 방법을 생각해 보는 것이 좋습니다. 다음은 이 원칙을 적용하는 예입니다.

• 웹 사이트를 배포하는 경우 워크플로에서 웹 애플리케이션에 연결해 봅니다. 워크플로가 웹 사이트에 성공적으로 연결되고 유효한 응답 코드를 수신하는지 확인합니다.
• CDN(콘텐츠 배달 네트워크)을 배포하는 경우 CDN을 통해 리소스에 연결해 보세요. 워크플로가 CDN에 성공적으로 연결되고 유효한 응답 코드를 수신하는지 확인합니다.

이러한 테스트를 인프라 스모크 테스트라고도 합니다. 스모크 테스트는 배포의 주요 문제를 발견하기 위해 설계된 간단한 형식의 테스트입니다.

음성 테스트를 수행하는 것도 좋은 방법입니다. 음성 테스트는 리소스에 원치 않는 동작이 포함되어 있지는 않은지 확인하는 데 도움이 됩니다. 예를 들어 가상 머신을 배포할 때 Azure Bastion을 사용하여 가상 머신에 안전하게 연결하는 것이 좋습니다. 워크플로에 음성 테스트를 추가하여 원격 데스크톱 연결 또는 SSH를 사용하여 가상 머신에 직접 연결할 수 없는지 확인할 수 있습니다.

GitHub 워크플로에서 테스트 실행

워크플로에서 테스트를 실행하는 여러 가지 방법이 있습니다. 이 모듈에서는 PowerShell을 통해 작성된 테스트를 실행하는 오픈 소스 도구인 Pester를 사용합니다. Pester는 GitHub 호스팅 실행기에 미리 설치됩니다. 스크립트 단계에서 사용하기 위해 특별한 작업을 수행할 필요가 없습니다.

다른 테스트 프레임워크를 사용하거나, 테스트 도구 없이 자체 테스트를 실행해도 됩니다. 예를 들어 생각해 볼 수 있는 또 다른 테스트 도구는 Azure에 대한 규칙과 테스트가 미리 작성되어 있는 PSRule입니다. 이 도구는 템플릿에 대한 유효성 검사를 실행하고, 배포된 Azure 리소스에 대한 테스트를 실행할 수도 있습니다. PSRule 링크는 요약 단원에서 제공합니다.

워크플로에서 테스트를 실행하는 경우 테스트가 실패하면 워크플로를 계속할 수 없습니다. 다음 연습에서는 워크플로에서 인프라 스모크 테스트를 사용하는 방법을 알아봅니다.

테스트 결과는 워크플로 로그에 기록됩니다. 또한 GitHub Marketplace에는 시간 경과에 따라 테스트 결과를 표시하고 추적할 수 있는 타사 작업도 포함됩니다.

작업 간에 데이터 전달

워크플로를 각각 고유한 책임이 있는 여러 작업으로 나누는 경우 이러한 작업 간에 데이터를 전달해야 할 때가 가끔 있습니다. 예를 들어 한 작업에서 만드는 Azure 리소스를 다른 작업에서 사용해야 하는 경우가 있습니다. 데이터를 전달하려면 생성된 리소스의 이름을 두 번째 작업에서 알아야 합니다. 예를 들어 스모크 테스트 작업은 배포 작업이 배포된 리소스에 액세스해야 합니다.

Bicep 파일은 리소스를 배포하므로 리소스 속성에 액세스하여 배포 출력으로 게시할 수 있습니다. arm-deploy 작업을 통해 Bicep 배포를 실행하는 경우 이 작업은 해당 단계 출력에 이러한 Bicep 배포 출력을 저장합니다. 그런 다음, arm-deploy 작업을 보유하는 작업이 이제 이러한 단계 출력을 작업 출력으로 게시할 수 있습니다. 작업은 deploy로 설정한 단계의 id 속성을 참조합니다.

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - 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
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

출력을 생성하는 작업에 의존하는 경우 후속 작업에서 작업의 출력에 액세스할 수 있습니다.

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

특수 구문을 사용하여 워크플로 스크립트의 출력을 전달할 수도 있습니다. 요약 부분에서 자세한 정보 링크를 제공합니다.

기타 테스트 형식

기능 테스트 및 통합 테스트는 배포된 리소스가 예상대로 작동하는지 확인하는 데 주로 사용됩니다. 예를 들어 통합 테스트는 웹 사이트에 연결하고 테스트 트랜잭션을 제출한 다음, 트랜잭션이 성공적으로 완료되었는지 확인할 때까지 대기합니다. 통합 테스트를 사용하면 솔루션이 실행되는 인프라와 더불어 팀에서 빌드하는 솔루션을 테스트할 수 있습니다. 이러한 형식의 테스트를 워크플로에 추가하는 방법은 뒤에 나오는 모듈에서 알아보겠습니다.

배포 워크플로에서 성능 테스트 및 보안 침투 테스트를 비롯한 다른 유형의 테스트를 실행할 수도 있습니다. 이 테스트는 이 모듈의 범위를 벗어나지만, 자동화된 배포 프로세스의 가치를 높일 수 있습니다.

롤백 또는 롤포워드

워크플로에서 리소스를 성공적으로 배포하지만 테스트가 실패한다고 가정하겠습니다. 이 경우 어떻게 해야 할까요?

이 모듈의 앞부분에서는 GitHub 작업을 사용하여 이전 작업이 실패할 때 실행되는 ‘롤백 작업’을 만들 수 있다는 것을 배웠습니다. 이 방법을 사용하여 테스트 작업에서 예기치 않은 결과를 보고할 때 롤백 작업을 만들 수 있습니다. 또한 변경 내용을 수동으로 롤백하거나, 또는 일시적인 문제 때문에 오류가 발생했지만 그 후 문제가 이미 해결된 것으로 생각되면 전체 워크플로를 다시 실행할 수도 있습니다.

예를 들어, 워크플로에 롤백 작업을 추가할 수 있습니다. 스모크 테스트 작업이 실패하면 롤백 작업이 실행됩니다.

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

이 작업은 스모크 테스트 작업에 따라 달라집니다. 스모크 테스트가 실패한 경우에만 실행됩니다. 기본적으로 GitHub 작업은 이전 작업이 실패할 때마다 워크플로를 중지합니다. if 조건에는 이 동작을 재정의하기 위한 always() 검사가 포함됩니다. 식에 always()가 없으면 이전 작업이 실패할 때마다 롤백 작업을 건너뜁니다.

롤백 작업에서 수행해야 하는 단계를 작업하기가 쉽지 않습니다. Bicep 배포는 일반적으로 복잡하며, 변경 내용을 롤백하기가 쉽지 않습니다. 배포에 다른 구성 요소가 포함되어 있으면 롤백이 매우 어렵습니다.

예를 들어 워크플로에서 Azure SQL 데이터베이스를 정의하는 Bicep 파일을 배포한 다음, 데이터베이스에 데이터를 추가한다고 가정하겠습니다. 배포를 롤백할 때 데이터를 삭제해야 할까요? 데이터베이스도 제거해야 할까요? 모든 오류와 모든 롤백이 실행 중인 환경에 어떤 영향을 미칠지 예측하기 어렵습니다.

이러한 이유로 많은 조직에서는 오류의 원인을 신속하게 수정하고 다시 배포하는 롤포워드를 선호합니다. 고품질의 자동화된 배포 프로세스를 구축하고 이러한 학습 경로를 통해 배운 모든 모범 사례를 따르면 고품질을 유지하면서도 신속하게 문제를 해결하고 Bicep 파일을 다시 배포할 수 있습니다.