배포 후 리소스 테스트
Bicep 배포의 유효성을 검사하고 미리 본 덕분에 Bicep 파일이 성공적으로 배포될 것이라고 자신할 수 있게 되었습니다. 하지만 배포만으로 끝이 아닙니다. 배포가 완료되면 예상한 대로 배포되었는지 확인하는 것도 도움이 됩니다.
이 단원에서는 배포가 완료된 후에 실행할 수 있는 테스트에 대해 알아봅니다. 또한 배포가 예상대로 되지 않는 경우 배포를 롤백하는 방법을 알아봅니다.
스모크 테스트 및 부정 테스트 실행
Bicep 파일에서 리소스를 정의할 때 목표는 Azure에서 리소스를 만드는 것만이 아닙니다. 조직의 요구 사항을 충족하면서 조직에 가치를 제공하는 것입니다. Bicep 파일의 유효성을 검사하고 미리 볼 때 리소스 정의가 유효하다는 확신을 얻을 수 있지만 리소스가 실제로 원하는 작업을 수행할지는 알 수 없습니다.
예를 들어 Bicep 배포 파이프라인을 사용하여 새 Azure SQL 논리 서버를 배포한다고 가정하겠습니다. 서버의 Bicep 정의가 유효하므로 Linter 및 실행 전 유효성 검사 스테이지가 전달됩니다. 가상 명령은 서버가 생성된다는 것을 보여주며, 이는 사용자가 원하는 것입니다. 배포도 성공적으로 완료됩니다. 그러나 배포 프로세스가 완료되어도 정상적으로 작동하는 즉시 사용 가능한 데이터베이스 서버가 아직 없을 수도 있습니다. 그 이유는 다음과 같습니다.
- 네트워크 트래픽이 서버에 도달할 수 있도록 방화벽 규칙을 구성하지 않았습니다.
- 없으면 서버에서 Microsoft Entra 인증을 사용하도록 설정했거나 그 반대의 경우도 마찬가지입니다.
기본 Bicep 파일만 배포하는 경우에도 배포하는 리소스가 실제로 작동하고 요구 사항을 충족하는지 확인하는 방법을 생각해 보는 것이 좋습니다. 다음은 이 원칙을 적용하는 예입니다.
- 웹 사이트를 배포하는 경우 파이프라인에서 웹 애플리케이션에 연결해 봅니다. 파이프라인이 웹 사이트에 성공적으로 연결되고 유효한 응답 코드를 수신하는지 확인합니다.
- CDN(콘텐츠 배달 네트워크)을 배포하는 경우 CDN을 통해 리소스에 연결해 보세요. 파이프라인이 CDN에 성공적으로 연결되고 유효한 응답 코드를 수신하는지 확인합니다.
이러한 테스트를 인프라 스모크 테스트라고도 합니다. 스모크 테스트는 배포의 주요 문제를 발견하기 위해 설계된 간단한 형식의 테스트입니다.
참고
일부 Azure 리소스는 Microsoft 호스팅 파이프라인 에이전트에서 연결하기가 쉽지 않습니다. 개인 네트워크를 통해 리소스에 액세스해야 하는 경우 자체 호스팅 에이전트를 사용하여 스모크 테스트 스테이지를 실행하는 방안을 고려해야 합니다.
음성 테스트를 수행하는 것도 좋은 방법입니다. 음성 테스트는 리소스에 원치 않는 동작이 포함되어 있지는 않은지 확인하는 데 도움이 됩니다. 예를 들어 가상 머신을 배포할 때 Azure Bastion을 사용하여 가상 머신에 안전하게 연결하는 것이 좋습니다. 파이프라인에 음성 테스트를 추가하여 원격 데스크톱 연결 또는 SSH를 사용하여 가상 머신에 직접 연결할 수 없는지 확인할 수 있습니다.
중요
이러한 테스트의 목표는 Bicep이 리소스를 올바르게 배포했는지 확인하는 것이 아닙니다. Bicep 파일에서 지정하는 리소스를 Bicep이 배포한다는 전제 하에 Bicep을 사용하는 것이기 때문입니다. 사용자가 정의한 리소스가 사용자의 상황에 맞게 작동하고 요구 사항을 충족하는지 확인하는 것이 목표입니다.
Azure Pipelines에서 테스트 실행
파이프라인에서 테스트를 실행하는 여러 가지 방법이 있습니다. 이 모듈에서는 PowerShell을 통해 작성된 테스트를 실행하는 오픈 소스 도구인 Pester를 사용합니다. 다른 테스트 프레임워크를 사용하거나, 테스트 도구 없이 자체 테스트를 실행해도 됩니다. 예를 들어 생각해 볼 수 있는 또 다른 테스트 도구는 Azure에 대한 규칙과 테스트가 미리 작성되어 있는 PSRule입니다. 이 도구는 템플릿에 대한 유효성 검사를 실행하고, 배포된 Azure 리소스에 대한 테스트를 실행할 수도 있습니다. PSRule 링크는 요약 단원에서 제공합니다.
지원되는 테스트 프레임워크를 사용하는 경우 Azure Pipelines는 각 테스트의 결과를 이해합니다. Azure Pipelines는 파이프라인 실행 정보와 함께 테스트 결과를 표시하고 각 테스트의 시간별 기록을 추적합니다. 다음 연습에서는 Azure Pipelines에서 인프라 스모크 테스트를 사용하는 방법을 알아봅니다.
단계와 스테이지 간에 데이터 전달
파이프라인을 각각 고유한 책임이 있는 여러 스테이지로 나누는 경우 이러한 스테이지 간에 데이터를 전달해야 할 때가 가끔 있습니다. 예를 들어 한 스테이지에서 만드는 Azure 리소스를 다른 스테이지에서 작업해야 하는 경우가 있습니다. 데이터를 전달하려면 생성된 리소스의 이름을 두 번째 스테이지에서 알아야 합니다. 예를 들어, 스모크 테스트 스테이지는 배포 스테이지가 배포된 리소스에 액세스해야 합니다.
Bicep 파일은 리소스를 배포하므로 리소스 속성에 액세스하여 배포 출력으로 게시할 수 있습니다. 사용자는 파이프라인의 배포 출력에 액세스할 수 있습니다. Azure Pipelines에는 모든 스테이지에서 사용할 수 있도록 변수를 게시하는 특수 구문이 있습니다.
첫 번째로, 파이프라인 스테이지 출력 변수를 게시해야 합니다. 변수를 출력하려면 Azure Pipelines가 이해할 수 있는 특수 형식의 문자열을 파이프라인 로그에 작성합니다. 다음 연습에서는 myVariable이라는 변수를 myValue 값으로 설정합니다.
echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"
Azure Pipelines는 파이프라인 로그에서 문자열을 읽고 해석한 다음, 변수 값을 출력으로 제공합니다. 이 변수 값을 더 많은 스크립팅과 결합하여 Bicep 배포 출력의 값을 파이프라인 스테이지 출력 변수로 게시할 수 있습니다. 다음 연습에서 이 스크립트를 작성하는 방법을 확인할 수 있습니다.
두 번째로, 스모크 테스트 스테이지의 작업에서 변수를 사용할 수 있도록 해야 합니다. 또 다른 특수 형식의 YAML 문자열을 사용하여 작업에 대한 변수를 정의합니다.
- stage: SmokeTest
jobs:
- job: SmokeTest
variables:
myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]
이제 스모크 테스트 작업 내의 모든 단계에서 $(myVariable) 구문을 사용하여 다른 변수와 마찬가지로 myVariable 값에 액세스할 수 있습니다. 이 변수는 다음 연습에서 사용됩니다.
기타 테스트 형식
‘기능 테스트’ 및 ‘통합 테스트’는 배포된 리소스가 예상대로 작동하는지 확인하는 데 주로 사용됩니다. 예를 들어 통합 테스트는 웹 사이트에 연결하고 테스트 트랜잭션을 제출한 다음, 트랜잭션이 성공적으로 완료되었는지 확인할 때까지 대기합니다. 통합 테스트를 사용하면 솔루션이 실행되는 인프라와 더불어 팀에서 빌드하는 솔루션을 테스트할 수 있습니다. 이러한 형식의 테스트를 파이프라인에 추가하는 방법은 뒤에 나오는 모듈에서 알아보겠습니다.
배포 파이프라인에서 성능 테스트 및 보안 침투 테스트를 비롯한 다른 유형의 테스트를 실행할 수도 있습니다. 이 테스트는 이 모듈의 범위를 벗어나지만, 자동화된 배포 프로세스의 가치를 높일 수 있습니다.
롤백 또는 롤포워드
파이프라인에서 리소스를 성공적으로 배포하지만 테스트가 실패한다고 가정하겠습니다. 이 경우 어떻게 해야 할까요?
이 모듈의 앞부분에서 Azure Pipelines를 사용하면 이전 스테이지가 실패할 때 실행되는 ‘롤백 스테이지’를 만들 수 있다고 배웠습니다. 이 방법을 사용하여 테스트 스테이지에서 예기치 않은 결과를 보고할 때 롤백 스테이지를 만들 수 있습니다. 또한 변경 내용을 수동으로 롤백하거나, 또는 일시적인 문제 때문에 오류가 발생했지만 그 후 문제가 해결된 것으로 생각되면 전체 파이프라인을 다시 실행할 수도 있습니다.
참고
Azure Resource Manager에 배포를 제출할 때, 배포가 실패하면 마지막으로 성공한 배포를 자동으로 다시 실행하도록 Resource Manager에 요청할 수 있습니다. 이렇게 하려면 Azure CLI 단계를 사용하여 파일을 배포하고 az deployment group create 명령을 사용하여 배포를 제출할 때 --rollback-on-error 매개 변수를 추가해야 합니다.
롤백 스테이지에서 수행해야 하는 단계를 작업하기가 쉽지 않습니다. Bicep 배포는 일반적으로 복잡하며, 변경 내용을 롤백하기가 쉽지 않습니다. 배포에 다른 구성 요소가 포함되어 있으면 롤백이 매우 어렵습니다.
예를 들어 파이프라인에서 Azure SQL 데이터베이스를 정의하는 Bicep 파일을 배포한 다음, 데이터베이스에 데이터를 추가한다고 가정하겠습니다. 배포를 롤백할 때 데이터를 삭제해야 할까요? 데이터베이스도 제거해야 할까요? 모든 오류와 모든 롤백이 실행 중인 환경에 어떤 영향을 미칠지 예측하기 어렵습니다.
이러한 이유로 많은 조직에서는 오류의 원인을 신속하게 수정하고 다시 배포하는 롤포워드를 선호합니다. 고품질의 자동화된 배포 프로세스를 구축하고 이러한 학습 경로를 통해 배운 모든 모범 사례를 따르면 고품질을 유지하면서도 신속하게 문제를 해결하고 Bicep 파일을 다시 배포할 수 있습니다.
팁
DevOps 사고방식의 원칙 중 하나는 실수에서 배우는 것입니다. 배포를 롤백해야 하는 경우 오류가 발생한 이유를 신중하게 생각하고, 나중에 같은 문제가 발생하면 배포에서 감지할 수 있도록 자동화된 테스트를 추가해야 합니다.