코드 제공 인프라(Infrastructure as Code)

아티클
05/23/2023

IaC(Infrastructure as Code)는 설명적 모델에서 네트워크, 컴퓨팅 서비스, 데이터베이스, 스토리지 및 연결 토폴로지와 같은 인프라 관리를 포함하는 주요 DevOps 사례입니다. IaC를 사용하면 팀이 더 빠르고 높은 신뢰도로 변경 내용을 개발하고 릴리스할 수 있습니다. IaC에는 다음과 같은 이점이 있습니다.

배포에 대한 신뢰도 향상
여러 환경을 관리하는 기능
인프라 상태에 대한 이해 향상

코드 제공 인프라(Infrastructure as Code)를 사용하는 이점에 대한 자세한 내용은 반복 가능한 인프라를 참조하세요.

도구

코드 제공 인프라(Infrastructure as Code)를 구현할 때 수행할 수 있는 두 가지 방법이 있습니다.

명령적 코드 제공 인프라(Infrastructure as Code)에는 Bash 또는 PowerShell과 같은 언어로 스크립트를 작성하는 작업이 포함됩니다. 원하는 결과를 생성하기 위해 실행되는 명령을 명시적으로 지정합니다. 명령적 배포를 사용하는 경우 종속성, 오류 제어 및 리소스 업데이트의 시퀀스를 관리하는 것은 사용자에게 달려 있습니다.
선언적 코드 제공 인프라(Infrastructure as Code)에는 환경의 모양을 정의하는 정의를 작성하는 작업이 포함됩니다. 이 정의에서 어떻게 수행되길 원하는지 대신 원하는 결과를 지정합니다. 도구는 현재 상태를 검사하고 대상 상태와 비교한 다음, 차이점을 적용하여 결과를 발생시키는 방법을 파악합니다.

ARM 템플릿

ARM 템플릿(Azure Resource Manager 템플릿)에 대한 정보를 검토합니다.

Bicep

Bicep은 선언적 구문을 사용하여 Azure 리소스를 배포하는 DSL(도메인 특정 언어)입니다. Bicep 파일에서 배포하려는 인프라와 해당 속성을 정의합니다. ARM 템플릿에 비해 Bicep 파일은 간결한 구문을 사용하기 때문에 개발자가 아닌 사용자들이 더 쉽게 읽고 쓸 수 있습니다.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraform

Terraform에 대한 정보를 검토합니다.

Azure CLI

Azure CLI에 대한 정보를 검토합니다.

코드 제공 인프라(Infrastructure as Code) 모듈

코드를 사용하여 인프라를 배포하는 목표 중 하나는 중복 작업을 방지하거나 동일하거나 유사한 목적으로 여러 템플릿을 만드는 것을 방지하는 것입니다. 인프라 모듈은 재사용 가능하고 유연해야 하며 명확한 목적이 있어야 합니다.

모듈은 일반적으로 함께 배포할 리소스 세트를 포함하는 독립 파일입니다. 모듈을 사용하면 복잡한 템플릿을 더 작고 관리하기 쉬운 코드 집합으로 분할할 수 있습니다. 각 모듈이 특정 작업에 중점을 두고 있으며 여러 배포 및 워크로드에 대해 모든 모듈을 재사용할 수 있는지 확인할 수 있습니다.

Bicep 모듈

Bicep을 사용하면 모듈을 만들고 호출할 수 있습니다. 모듈이 만들어지면 다른 Bicep 템플릿에서 사용할 수 있습니다. 고품질 Bicep 모듈은 여러 관련 리소스를 정의해야 합니다. 예를 들어 Azure 함수를 정의할 때 일반적으로 특정 애플리케이션, 해당 애플리케이션에 대한 호스팅 계획 및 해당 애플리케이션의 메타데이터에 대한 스토리지 계정을 배포합니다. 이러한 구성 요소는 별도로 정의되지만 리소스의 논리적 그룹을 형성하므로 함께 모듈로 정의하는 것이 좋습니다.

Bicep 모듈은 일반적으로 다음을 사용합니다.

호출 모듈의 값을 수락하는 매개 변수.
호출 모듈에 결과를 반환하는 출력 값.
관리할 모듈에 대해 하나 이상의 인프라 개체를 정의하는 리소스.

Bicep 모듈 게시

Bicep 모듈을 게시하고 공유하기 위한 몇 가지 옵션이 있습니다.

공용 레지스트리: 공용 모듈 레지스트리는 MCR(Microsoft 컨테이너 레지스트리)에서 호스팅됩니다. 소스 코드와 모듈은 GitHub에 저장됩니다.
프라이빗 레지스트리: Azure Container Registry를 사용하여 모듈을 프라이빗 레지스트리에 게시할 수 있습니다. CI/CD 파이프라인의 레지스트리에 모듈을 게시하는 방법에 대한 자세한 내용은 Bicep 및 GitHub Actions를 참조하거나, 원하는 경우 Bicep 및 Azure Pipelines를 참조하세요.
템플릿 사양:템플릿 사양을 사용하여 Bicep 모듈을 게시할 수 있습니다. 템플릿 사양은 완전한 템플릿이지만 Bicep을 사용하면 템플릿 사양을 사용하여 모듈을 배포할 수 있습니다.
버전 제어 시스템: GitHub 또는 Azure DevOps와 같은 버전 제어 도구에서 직접 모듈을 로드할 수 있습니다.

Terraform 모듈

Terraform을 사용하면 모듈을 만들고 호출할 수 있습니다. 각 Terraform 구성에는 기본 작업 디렉터리의 .tf 파일에 정의된 리소스로 구성된 루트 모듈이라고 하는 모듈이 하나 이상 있습니다. 각 모듈은 기본 구성 파일에 자식 모듈을 포함할 수 있는 다른 모듈을 호출할 수 있습니다. 동일한 구성 내에서 또는 다른 구성에서 모듈을 여러 번 호출할 수도 있습니다.

모듈은 동일한 모든 구성 언어 개념으로 정의됩니다. 가장 일반적으로 사용하는 것은 다음과 같습니다.

호출 모듈의 값을 수락하는 입력 변수.
호출 모듈에 결과를 반환하는 출력 값.
관리할 모듈에 대해 하나 이상의 인프라 개체를 정의하는 리소스.

Terraform 모듈 게시

Terraform 모듈을 게시하고 공유하기 위한 몇 가지 옵션이 있습니다.

공용 레지스트리: HashiCorp에는 사용자가 공유 가능한 Terraform 모듈을 생성할 수 있는 자체 Terraform 모듈 레지스트리가 있습니다. 현재 Terraform 모듈 레지스트리에는 여러 Azure 모듈이 게시되어 있습니다.
프라이빗 레지스트리: Terraform 모듈을 Terraform Cloud Private Registry 또는 Azure Container Registry와 같은 프라이빗 리포지토리에 원활하게 게시할 수 있습니다.
버전 제어 시스템: GitHub와 같은 버전 제어 도구에서 직접 프라이빗 모듈을 로드할 수 있습니다. 지원되는 원본에 대한 자세한 내용은 Terraform 모듈 원본을 참조하세요.

디자인 고려 사항

Azure에 랜딩 존 리소스를 배포할 때 IaC를 사용하는 것이 좋습니다. IaC는 배포 최적화를 완전히 실현하고, 구성 작업을 줄이며, 전체 환경의 배포를 자동화합니다.
명령적 또는 선언적 IaC 접근 방식을 취해야 하는지 여부를 결정합니다.
- 명령적 접근 방식을 사용하는 경우 실행될 명령을 명시적으로 상태 지정하여 원하는 결과를 생성합니다.
- 선언적 접근 방식을 사용하는 경우 원하는 방식보다는 원하는 결과를 지정합니다.
배포 범위를 고려합니다. Azure 관리 수준 및 계층 구조를 잘 이해합니다. 각 IaC 배포는 Azure 리소스가 배포되는 범위를 알고 있어야 합니다.
Azure 네이티브 또는 Azure 비 네이티브 IaC 도구를 사용해야 하는지 여부를 결정합니다. 몇 가지 고려할 점은 다음과 같습니다.
- Azure CLI, ARM 템플릿 및 Bicep과 같은 Azure 네이티브 도구는 Microsoft에서 완전히 지원되므로 새 기능을 더 빠르게 통합할 수 있습니다.
- Terraform과 같은 네이티브가 아닌 도구를 사용하면 AWS 또는 GCP와 같은 여러 클라우드 공급자에서 코드 제공 인프라(Infrastructure as Code)를 관리할 수 있습니다. 그러나 새 Azure 기능은 네이티브가 아닌 기능에 포함되기까지 다소 시간이 걸릴 수 있습니다. 조직이 다중 클라우드이거나 조직에서 이미 Terraform을 사용하고 있고 잘 알고 있는 경우 Terraform을 사용하여 Azure 랜딩 존을 배포하는 것이 좋습니다.
모듈을 사용하면 복잡한 템플릿을 더 작은 코드 집합으로 분할할 수 있으므로 일반적으로 함께 배포되는 리소스에 IaC 모듈을 사용하는 것이 좋습니다. 각 모듈이 특정 작업에 중점을 두고 있으며 여러 배포 및 워크로드에 대해 재사용할 수 있는지 확인할 수 있습니다.
공용 레지스트리, 프라이빗 레지스트리 또는 Git 리포지토리와 같은 버전 제어 시스템 중에서 선택하여 IaC 모듈에 대한 게시 전략을 채택하는 것이 좋습니다.
IaC 배포에 CI/CD 파이프라인을 사용하는 것이 좋습니다. 파이프라인은 배포 및 Azure 환경의 품질을 보장하기 위해 설정한 재사용 가능 프로세스를 적용합니다.

디자인 권장 사항

Azure 랜딩 존 배포를 배포, 관리, 거버넌스 및 지원하는 IaC 접근 방식을 채택합니다.
다음 시나리오에서는 IaC용 Azure 네이티브 도구를 사용합니다.
- Azure 네이티브 도구만 사용하려고 합니다. organization 이전 ARM 또는 Bicep 템플릿 배포 환경이 있을 수 있습니다.
- 조직에서는 모든 미리 보기 및 GA 버전의 Azure 서비스를 즉시 지원하려고 합니다.
다음 시나리오에서는 네이티브가 아닌 도구를 IaC에 사용합니다.
- 조직에서는 현재 Terraform을 사용하여 AWS 또는 GCP와 같은 다른 클라우드에 인프라를 배포합니다.
- 조직에서는 모든 미리 보기 및 GA 버전의 Azure 서비스를 즉시 지원할 필요가 없습니다.
재사용 가능한 IaC 모듈을 사용하여 반복적인 작업을 방지합니다. 조직 전체에서 모듈을 공유하여 여러 프로젝트 또는 워크로드를 배포하고 덜 복잡한 코드를 관리할 수 있습니다.
다음 시나리오에서 공용 레지스트리의 IaC 모듈을 게시하고 사용합니다.
- 공용 레지스트리에 이미 게시된 Azure 랜딩 존에 대한 모듈을 사용하려고 합니다. 자세한 내용은 Azure 랜딩 존 Terraform 모듈을 참조하세요.
- Microsoft, Terraform 또는 기타 모듈 공급자가 유지 관리, 업데이트 및 지원하는 모듈을 사용하려고 합니다.
  - 평가한 모듈 공급자에서 지원 문을 검사.
다음 시나리오에서 프라이빗 레지스트리 또는 버전 제어 시스템의 IaC 모듈을 게시하고 사용합니다.
- 조직의 요구 사항에 따라 고유한 모듈을 만들려고 합니다.
- 모든 기능을 완전히 제어하고 새 버전의 모듈을 유지 관리, 업데이트 및 게시하려고 합니다.
CI/CD 파이프라인을 사용하여 IaC 아티팩트를 배포하고 배포 및 Azure 환경의 품질을 확인합니다.

다음을 통해 공유