배포 스택이란?
Azure 배포 스택은 여러 리소스 그룹 또는 구독에 걸쳐 있는 경우에도 Azure 리소스 컬렉션의 수명 주기를 단일 원자성 단위로 관리할 수 있는 Azure 리소스 형식입니다. 일관되고 반복 가능한 배포가 가능하고, 관리가 간소화되며, 리소스의 효율적인 크기 조정 및 업데이트가 가능합니다.
이 단원에서는 Azure의 리소스 조직에 대해 알아보고 배포 스택을 통해 이전에는 가능하지 않았던 방식으로 리소스를 관리하는 방법을 알아봅니다.
리소스 조직
Azure에서 리소스를 구성하는 방법에는 여러 가지가 있습니다. 환경(프로덕션, 스테이징, 개발), 애플리케이션 수명 주기 또는 기능(예: 연결 또는 컴퓨팅 리소스)를 기준으로 리소스를 구성하도록 선택할 수 있습니다. 조직의 크기, 애플리케이션 수 및 데이터 보존과 같은 요소는 이러한 결정에 영향을 미치며 각 시나리오에 대한 일반적인 모범 사례가 있습니다.
배포 환경의 경우 다른 구독 또는 관리 그룹으로 구분할 수 있습니다. 애플리케이션의 모든 구성 요소가 단일 리소스 그룹에 있거나, 여러 리소스 그룹에 있거나, 여러 구독에 걸쳐 있을 수도 있습니다. Azure 리소스 조직의 경우 모범 사례에 따르면 수명 주기 및 보안에 따라 리소스를 리소스 그룹으로 구성하는 것이 좋습니다.
단일 리소스 그룹 애플리케이션
애플리케이션에 대해 단일 리소스 그룹을 사용하는 것이 적절한 경우도 있습니다. Azure를 처음 사용하며 개발 환경을 시작하거나 많은 리소스 없이 프로덕션 애플리케이션을 배포하려는 경우 단일 리소스 그룹이 효과적일 수 있습니다.
리소스 그룹은 권한을 허가하기 위한 보안 경계로 자주 사용됩니다. 보안 요구 사항이 엄격하지 않은 경우 리소스 그룹 범위에서 단일 RBAC(역할 기반 액세스 제어) 할당을 관리할 수 있습니다.
애플리케이션이 단일 리소스 그룹에 배포된 앱 서비스, 애플리케이션 인사이트 및 SQL 데이터베이스로 구성되었다고 가정해 보겠습니다. 조직에는 컴퓨팅, 웹 애플리케이션 및 데이터베이스를 관리하기 위한 별도의 팀이 있습니다. 조직의 보안 정책에 세분화된 RBAC가 필요한 경우 리소스 그룹 범위 대신 리소스 범위에서 사용 권한 범위를 지정해야 합니다.
시간이 지남에 따라 애플리케이션과 관련이 없는 리소스도 동일한 리소스 그룹에 배포될 수 있습니다. 예를 들어 동료가 새 Azure Key Vault를 배포하고 배포 시 실수로 잘못된 리소스 그룹을 선택합니다. 이 시나리오에서는 어떤 리소스가 어떤 애플리케이션에 속하는지 확인하기 어려울 수 있으며 잠재적으로 중요한 리소스를 실수로 삭제하는 것과 같은 문제가 발생할 수 있습니다.
다중 리소스 그룹 애플리케이션
애플리케이션이 변경이 필요한 지점으로 스케일링되면 어떻게 되나요? 간소화된 보안 제어를 위해 애플리케이션의 일부를 가져와서 별도의 리소스 그룹으로 분할해야 할 수 있습니다. 예를 들어 모든 컴퓨팅 리소스를 컴퓨팅 리소스 그룹에 배치하고 애플리케이션 리소스를 애플리케이션 리소스 그룹에 배치하고 모든 데이터베이스를 데이터베이스 리소스 그룹에 배치할 수 있습니다.
이 모델을 사용하면 컴퓨팅, 애플리케이션 및 데이터베이스 팀에 대한 사용 권한 범위를 해당 리소스 그룹으로 지정할 수 있습니다. 이 방법으로 문제를 해결할 수도 있지만 탈중앙화 관리를 도입했습니다. Azure의 배포 대부분은 리소스 그룹으로 범위가 지정되어 있으므로 더 이상 리소스를 단일 단위로 관리할 수 없습니다.
애플리케이션 리소스가 별도의 리소스 그룹에 배포되는 경우 애플리케이션에 속하는 리소스를 식별하기 어려울 수 있습니다. Azure 태그를 사용하여 애플리케이션에서 리소스를 식별할 수 있지만 리소스에 태그가 올바르게 지정되지 않을 수 있습니다.
다중 리소스 그룹 모델에서는 배포 작업을 두 번 이상 수행해야 할 수 있습니다. 리소스를 배포할 때 배포 방법에 따라 여러 배포 명령을 실행해야 할 수 있습니다. Azure에서 대부분의 배포 범위는 리소스 그룹으로 지정되므로 먼저 네트워킹 리소스를 배포한 다음, 애플리케이션 리소스를 배포해야 합니다. 삭제 작업의 경우도 마찬가지입니다. 애플리케이션과 관련된 모든 리소스 그룹을 제거해야 하는 경우 여러 삭제 작업을 실행해야 할 수 있습니다.
배포 스택 입력
배포 스택은 리소스 그룹 및 구독 전반에서 리소스 구성에 대해 생각하는 방식을 변경합니다. 배포 스택을 사용하면 Azure 리소스 조직 계층 구조의 위치에 관계없이 애플리케이션을 구성하는 모든 리소스를 그룹화할 수 있습니다. 하나의 단위로 관리할 수 있습니다. 배포 스택을 사용하면 스택을 구성하는 리소스 컬렉션에 대해 수명 주기 작업을 수행할 수 있습니다.
배포 스택을 애플리케이션의 리소스를 단일 단위로 그룹화하는 일련의 포인터라고 생각해 보세요. 배포 스택은 리소스 그룹, 구독, 관리 그룹 등 다양한 범위에서 만들어질 수 있습니다.
이전 예제를 고려해 보겠습니다. 이제 구독 수준 및 리소스 그룹 간에 범위가 지정된 단일 스택으로 애플리케이션 및 해당 리소스를 배포하여 애플리케이션을 단일 단위로 관리할 수 있습니다. 각 리소스 그룹 및 해당 리소스는 스택에서 관리됩니다.
배포 스택 사용
배포 스택에서 수행할 수 있는 작업은 무엇인가요? 배포 스택을 만들고 나열하고 업데이트하고 삭제할 수 있습니다. 리소스의 경우 스택의 리소스를 보고, 스택 내에서 리소스를 추가 및 제거하고, 스택 및 해당 리소스를 삭제로부터 보호할 수 있습니다.
배포 스택 및 해당 리소스를 만들고 배포하는 것은 표준 Azure 배포와 거의 동일하며, 익숙한 ARM JSON 템플릿, Bicep 파일 또는 템플릿 사양을 사용합니다. 예시:
Bicep 파일을 리소스 그룹에 배포하는 Azure CLI 명령은 다음과 같습니다.
az deployment group create \
--resource-group rg-depositsApplication \
--template-file ./main.bicep
리소스 그룹 범위에서 배포 스택을 만드는 Azure CLI 명령은 다음과 같습니다.
az stack group create \
--name stack-deposits \
--resource-group rg-depositsApplication \
--template-file ./main.bicep \
--action-on-unmanage detachAll \
--deny-settings-mode none
배포 스택을 사용하면 환경을 효율적으로 정리할 수 있습니다. 배포 스택을 사용하면 종속성을 이해할 필요 없이 단일 API 호출을 통해 스택과 모든 리소스를 삭제할 수 있습니다. 이 기능은 안정적인 방식으로 리소스 제거를 간소화하고 리소스 제거 속도를 향상합니다. 예시:
리소스 그룹 범위에서 해당 리소스와 함께 배포 스택을 삭제하는 Azure CLI 명령은 다음과 같습니다.
az stack group delete \
--name stack-deposits \
--resource-group rg-depositsApplication \
--action-on-unmanage detachAll
참고 항목
기존 배포 전략의 일부로 이미 전체 모드 배포를 사용할 수 있습니다. 이 경우 배포 스택을 더 안전한 옵션이자 넥스트 에볼루션으로 간주할 수 있습니다.
관리형 리소스
Bicep 파일, ARM JSON 템플릿 또는 템플릿 사양을 배포 스택에 제출하면 스택이 파일에 설명된 리소스 관리를 담당하게 됩니다. 스택에서 관리하는 리소스를 관리되는 리소스라고 하지만 해당 리소스는 원래 템플릿 파일을 통해 계속 수정됩니다.
더 이상 배포 스택에서 리소스를 관리할 필요가 없는 경우 더 이상 리소스를 포함하지 않게 스택을 수정할 수 있습니다. 배포 스택의 관리되지 않는 작업 동작은 배포 스택의 정의에서 제거된 리소스에 어떤 결과가 나타나는지 결정합니다. 이 동작은 이 단원의 뒷부분에서 설명하며, 리소스, 리소스 그룹 또는 관리 그룹이 스택에서 분리되거나 삭제되는지를 결정합니다.
거부 설정
또한 스택 및 해당 리소스에 대해 권한 없는 변경을 방지하는 "거부 설정"을 구성할 수 있습니다. 이러한 거부 할당은 사용자 지정할 수 있습니다. 모드를 플래그 없음, 삭제 거부 또는 쓰기 및 삭제 거부(Azure 잠금과 비슷할 수 있음)로 설정할 수 있습니다. 또한 거부 할당에서 특정 작업 또는 서비스 주체를 제외할 수 있습니다. 거부 설정을 실수로 수정 및 삭제하지 않도록 하기 위한 추가 보호 계층으로 간주하세요.