인프라를 코드로 사용하여 Azure 랜딩 존 업데이트

  • 아티클

이 문서에서는 IaC(Infrastructure as Code)를 사용하여 Azure 랜딩 존을 업데이트할 때의 이점에 대해 설명합니다. 조직은 구성이 올바르고 변경의 필요성에 응답하도록 작동할 때 랜딩 존을 업데이트해야 합니다.

IaC는 전체 수명 주기를 관리할 수 있으며 배포하는 리소스를 관리하는 데 탁월합니다. 조직은 IaC를 사용하여 Azure 랜딩 존을 배포할 계획입니다. 기존 비 IaC 리소스를 상태 관리로 지원되는 IaC 리소스와 일치하도록 계획해야 합니다. 기존 리소스를 원하는 상태로 매핑해야 합니다.

자세한 내용은 Azure 랜딩 존을 최신 상태로 유지를 참조하세요.

코드로서의 인프라 작동 방식

IaC는 컴퓨터에서 읽을 수 있는 정의 파일을 사용하여 인프라 리소스의 수명 주기를 관리하기 위한 연습 및 도구를 나타냅니다. 인프라에 대한 정의는 파이프라인을 통해 작성, 버전 관리, 배포된 다음 워크로드에 대한 배포의 일부가 됩니다.

IaC 기술은 선언적입니다. 즉, IaC가 실행되면 현재 상태에 관계없이 코드에 설명된 구성으로 구성을 설정합니다. Azure CLI 또는 Azure PowerShell 과 같은 스크립트를 통해 인프라를 구성하는 경우 필수입니다. 명령적 스크립트는 일련의 작업을 수행하며 결과는 현재 상태와 작업 뒤의 상태에 따라 달라집니다.

따라서 Azure 리소스에 대한 코드 정의로 인프라가 있는 경우 원하는 만큼 자주 해당 정의를 실행할 수 있으며 다음과 같은 경우에만 변경이 만들어집니다.

  • 정의는 새 리소스를 추가하거나, 이전에 배포된 리소스를 제거하거나, 이전에 배포된 리소스를 수정하도록 변경됩니다.
  • 배포된 리소스는 구성에서 드리프트되어 구성을 정의된 리소스로 다시 설정합니다.

더 이상 필요하지 않은 리소스를 제거하고 많은 변경 내용을 통해 리소스의 수명 주기를 관리하여 IaC를 사용하여 상태를 복원할 수 있습니다.

참고 항목

IaC를 사용하여 리소스를 제거하는 특정 메커니즘은 다양합니다. 예를 들어 Azure Bicep을 사용하려면 배포 유형을 사용하여 complete 범위 외부 리소스를 수정해야 합니다. 이 명령은 특정 범위에서만 작동합니다. Terraform의 경우 리소스에는 lifecycle Terraform이 리소스를 처리하는 방법에 대한 지침을 제공하는 메타 인수가 있습니다.

Azure 랜딩 존의 경우 코드로 인프라에 대한 두 가지 기본 옵션이 있습니다.

  • Azure Bicep은 Microsoft에서 개발한 Azure 리소스를 배포하는 데 사용되는 기본 특정 언어입니다. 자세한 내용은 Azure 랜딩 존 - Bicep 모듈 디자인 고려 사항을 참조 하세요.
  • Hashicorp에서 생산한 제품인 Terraform은 클라우드 및 온-프레미스에 인프라를 배포합니다. Terraform에는 Azure 리소스 배포를 위한 특정 Microsoft 생성 리소스 공급자가 있습니다. 자세한 내용은 Azure 랜딩 존 - Terraform 모듈 디자인 고려 사항을 참조 하세요.

코드로 인프라를 사용하여 ALZ를 업데이트할 경우의 이점

다음 이점은 인프라를 코드로 사용하여 랜딩 존을 업데이트해야 하는 이유를 설명합니다.

노력 줄이기

수동으로 변경하는 것에 비해 인프라를 코드로 사용하여 업데이트를 수행하는 데 더 적은 노력이 필요합니다. IaC 배포는 다음 질문에 답변하는 데 도움이 됩니다.

  • 현재 리소스는 어떻게 구성되었나요?
  • 이 업데이트는 어떻게 구성되나요?
  • 이 업데이트와 일치하도록 어떤 변경이 수행되나요?

코드 도구 집합으로 인프라가 실행되면 변경 내용의 비교 또는 "차등" 읽기를 생성할 수 있습니다. 환경에 변경 내용을 커밋하기 전에 이 읽기를 검토합니다.

도구 집합은 운영자나 엔지니어가 아닌 변경에 대한 정보를 컴파일할 수 있습니다.

오류 줄이기

배포의 프로그래밍 방식 특성으로 인해 코드로서의 인프라는 변경하면서 사람의 오류를 줄입니다. 정의된 내용만 변경하고 미리 보기 옵션이 있으므로 실패하거나 불완전한 변경으로 인한 중단을 줄입니다. 또한 테스트 옵션도 향상되었습니다.

버전 제어 및 기록

코드 배포로서의 인프라는 정의 파일에서 지원되므로 소스 제어를 사용하여 정의 버전을 관리할 수 있습니다. 사용하는 IaC 방법에 따라 Azure for Bicep의 배포 또는 Terraform의 상태 파일을 참조하여 이전 배포의 기록을 검토할 수 있습니다.

소스 제어 방법을 사용하는 경우 IaC의 새 분기를 만들어 변경 내용 및 수정 버전을 추가합니다. 소스 제어 시스템의 분기 기록은 반복 및 변경 내용을 캡처합니다. 변경 내용을 병합하고 프로덕션 환경에 배포할 준비가 될 때까지 테스트 환경에 변경 내용을 배포하는 데 사용할 수 있습니다. 자세한 내용은 Azure 랜딩 존에 대한 테스트 방법을 참조 하세요. 이 주기 동안 배포 레코드는 사용되는 버전과 배포된 리소스를 캡처하여 눈에 잘 띄는 기록을 제공합니다.

일반적인 테스트 목적으로 Bicep과 함께 이러한 테스트 방법을 사용합니다. 이러한 방법을 사용하면 코드를 배포하기 전에 테스트를 수행할 수 있으며 분기의 비프로덕션 환경에서 테스트할 수 있습니다.

테스트 환경

IaC 배포는 반복 가능하므로 동일한 정의를 사용하여 배포에 따라 두 번째(또는 그 이상) 환경을 배포할 수 있습니다. 이 방법은 변경 내용을 테스트하는 데 유용합니다.

예를 들어 프리미엄 SKU를 사용하여 Azure Firewall을 대체하려는 경우 프로덕션을 변경하지 않고 테스트 환경을 배포하고 변경 내용의 유효성을 검사할 수 있습니다.

구성 드리프트 catch

IaC는 업데이트 중에 구성 드리프트를 catch하는 고유한 옵션을 제공합니다. 배포는 정의 파일의 변경 내용을 catch하고 리소스 구성이 정의와 다른 인스턴스를 제공합니다.

IaC를 사용한 랜딩 존 업데이트는 이 구성 드리프트를 catch하고 코드를 적절하게 업데이트하거나, 업데이트를 통해 이러한 잘못된 구성을 해결하거나, 다른 방법으로 해결할 수 있도록 도와줍니다.

포털, CLI 또는 비 IaC 메서드를 통해 리소스를 변경하면 변경 내용이 구현됩니다. 다음에 IaC를 통해 배포를 실행할 때는 what-if 또는 plan 함수를 사용하여 포털의 코드 정의 상태와 실제 상태 간의 비교에 플래그를 지정합니다. 이 메서드를 사용하여 코드 파일 외부에서 환경이 수정되었는지 식별합니다.

잘못된 정렬이 식별되면 IaC를 실행하여 배포를 정의에 맞게 정렬할 수 있습니다. 이 메서드를 사용하여 문제의 특성, 실행의 특성 및 변경 내용에 따라 문제를 식별하고 시나리오를 수정합니다. 예를 들어 Terraform은 배포한 리소스에 대한 기준을 복원하려고 시도하고, Complete Bicep의 모드 배포는 정의에 속하지 않는 리소스 그룹의 리소스를 제거합니다. 이러한 도구는 구성 드리프트를 검색하고 복구하지만 모든 문제를 해결하지는 못할 수 있습니다.

자세한 내용은 대역 외 변경 내용 및 Terraform을 사용하여 드리프트 감지 및 관리를 참조하세요.

포털에 정의된 변경 내용은 IaC로 다시 구현하는 데 번거롭습니다. 현재 상태와 일치하도록 코드를 업데이트해야 합니다. 여기에는 종종 각 리소스 변경 내용을 검토하고 "있는 그대로" 구성과 일치하도록 해당 매개 변수를 업데이트하는 작업이 포함됩니다.

IaC를 사용하여 랜딩 존 또는 기타 리소스를 관리하는 경우 비상 사태의 일환으로 IaC 외부에서만 변경해야 합니다. Privileged Identity Management와 같이 직접 변경할 수 있는 액세스 권한이 있는 계정으로 예방 조치를 취합니다.

다음 문서에서 일반적인 자동화 및 보안 사례를 검토합니다.

다음 단계

다음 문서에서 IaC 도구에 대한 소개를 살펴보세요.