클라우드 일관성을 위한 Azure Resource Manager 템플릿 개발Develop Azure Resource Manager templates for cloud consistency

중요

PowerShell에서 이 Azure 기능을 사용하려면 AzureRM 모듈이 설치되어 있어야 합니다.Using this Azure feature from PowerShell requires the AzureRM module installed. 이 모듈은 Windows PowerShell 5.1에만 사용할 수 있는 이전 모듈로, 새로운 기능은 더 이상 받지 않습니다.This is an older module only available for Windows PowerShell 5.1 that no longer receives new features. PowerShell의 동일한 버전에 대해 설치된 경우 AzAzureRM 모듈은 호환되지 않습니다.The Az and AzureRM modules are not compatible when installed for the same versions of PowerShell. 두 버전이 모두 필요한 경우:If you need both versions:

  1. PowerShell 5.1 세션에서 Az 모듈을 제거합니다.Uninstall the Az module from a PowerShell 5.1 session.
  2. PowerShell 5.1 세션에서 AzureRM 모듈을 설치합니다.Install the AzureRM module from a PowerShell 5.1 session.
  3. PowerShell Core 6.x 이상을 다운로드하고 설치합니다.Download and install PowerShell Core 6.x or later.
  4. PowerShell Core 세션에서 Az 모듈을 설치합니다.Install the Az module in a PowerShell Core session.

Azure의 핵심 이점은 일관성입니다.A key benefit of Azure is consistency. 한 위치에 대한 개발 투자를 다른 위치에서 다시 사용할 수 있습니다.Development investments for one location are reusable in another. 템플릿을 사용하면 전역 Azure, Azure 소버린 클라우드 및 Azure Stack을 비롯한 전체 환경에서 배포의 일관성이 유지되며 배포를 반복할 수 있습니다.A template makes your deployments consistent and repeatable across environments, including the global Azure, Azure sovereign clouds, and Azure Stack. 그러나 클라우드 간에 템플릿을 재사용하려면 이 가이드에서 설명하는 클라우드 특정 종속성을 고려해야 합니다.To reuse templates across clouds, however, you need to consider cloud-specific dependencies as this guide explains.

Microsoft는 여러 위치에서 다음을 비롯한 지능형 엔터프라이즈 지원 클라우드 서비스를 제공합니다.Microsoft offers intelligent, enterprise-ready cloud services in many locations, including:

  • 전 세계 지역으로 확장되고 있는 Microsoft 관리 데이터 센터 네트워크에서 지원되는 전역 Azure 플랫폼The global Azure platform supported by a growing network of Microsoft-managed datacenters in regions around the world.
  • Azure 독일, Azure Government, Azure 중국(21Vianet에서 운영하는 Azure) 등의 격리된 소버린 클라우드Isolated sovereign clouds like Azure Germany, Azure Government, and Azure China (Azure operated by 21Vianet). 소버린 클라우드는 전역 Azure 고객이 액세스할 수 있는 우수한 기능을 대부분 포함하는 일관성 있는 플랫폼을 제공합니다.Sovereign clouds provide a consistent platform with most of the same great features that global Azure customers have access to.
  • 조직의 데이터 센터에서 Azure 서비스를 제공할 수 있게 해주는 하이브리드 클라우드 플랫폼인 Azure StackAzure Stack, a hybrid cloud platform that lets you deliver Azure services from your organization's datacenter. 엔터프라이즈는 고유한 데이터 센터에서 Azure Stack을 설정하거나, 자체 시설(호스트된 지역이라고도 함)에서 Azure Stack을 실행하는 서비스 공급자의 Azure 서비스를 이용할 수 있습니다.Enterprises can set up Azure Stack in their own datacenters, or consume Azure Services from service providers, running Azure Stack in their facilities (sometimes known as hosted regions).

이러한 모든 클라우드의 핵심은, Azure Resource Manager가 제공하는 API를 통해 다양한 사용자 인터페이스와 Azure 플랫폼 간에 통신할 수 있다는 것입니다.At the core of all these clouds, Azure Resource Manager provides an API that allows a wide variety of user interfaces to communicate with the Azure platform. 이 API는 강력한 코드 인프라 기능을 제공합니다.This API gives you powerful infrastructure-as-code capabilities. Azure 클라우드 플랫폼에서 사용할 수 있는 모든 리소스 종류는 Azure Resource Manager를 통해 배포 및 구성할 수 있습니다.Any type of resource that is available on the Azure cloud platform can be deployed and configured with Azure Resource Manager. 단일 템플릿을 사용하여 전체 애플리케이션을 배포하고 작동 종료 상태로 구성할 수 있습니다.With a single template, you can deploy and configure your complete application to an operational end state.

Azure 환경

데이터 센터에서 전역 Azure, 소버린 클라우드, 호스트 클라우드 및 클라우드의 일관성을 유지하면 Azure Resource Manager를 활용하는 데 도움이 됩니다.The consistency of global Azure, the sovereign clouds, hosted clouds, and a cloud in your datacenter helps you benefit from Azure Resource Manager. 템플릿 기반 리소스 배포 및 구성을 설정할 때 이러한 클라우드 간에 개발 투자를 재사용할 수 있습니다.You can reuse your development investments across these clouds when you set up template-based resource deployment and configuration.

그러나 전역 클라우드, 소버린 클라우드, 호스트 클라우드 및 하이브리드 클라우드가 일관성 있는 서비스를 제공한다 해도 모든 클라우드가 동일하지는 않습니다.However, even though the global, sovereign, hosted, and hybrid clouds provide consistent services, not all clouds are identical. 따라서 특정 클라우드에서만 사용 가능한 기능에 대한 종속성이 있는 템플릿을 만들 수 있습니다.As a result, you can create a template with dependencies on features available only in a specific cloud.

이 가이드의 나머지 부분에서는 Azure Stack용 Azure Resource Manager 템플릿을 새로 개발하거나 기존 템플릿을 업데이트하려는 경우, 고려할 영역을 설명합니다.The rest of this guide describes the areas to consider when planning to develop new or updating existing Azure Resource Manager templates for Azure Stack. 일반적으로 검사 목록에는 다음 항목이 포함되어야 합니다.In general, your checklist should include the following items:

  • 템플릿의 함수, 엔드포인트, 서비스 및 기타 리소스를 대상 배포 위치에서 사용할 수 있는지 확인합니다.Verify that the functions, endpoints, services, and other resources in your template are available in the target deployment locations.
  • 중첩된 템플릿 및 구성 아티팩트를 액세스 가능한 위치에 저장하여 클라우드 간에 액세스를 보장합니다.Store nested templates and configuration artifacts in accessible locations, ensuring access across clouds.
  • 링크 및 요소를 하드 코딩하는 대신 동적 참조를 사용합니다.Use dynamic references instead of hard-coding links and elements.
  • 사용하는 템플릿 매개 변수가 대상 클라우드에서 작동하는지 확인합니다.Ensure the template parameters you use work in the target clouds.
  • 대상 클라우드에서 리소스 특정 속성을 사용할 수 있는지 확인합니다.Verify that resource-specific properties are available the target clouds.

Azure Resource Manger 템플릿에 대한 소개는 템플릿 배포를 참조하세요.For an introduction to Azure Resource Manger templates, see Template deployment.

템플릿 함수가 작동하는지 확인Ensure template functions work

Resource Manager 템플릿의 기본 구문은 JSON입니다.The basic syntax of a Resource Manager template is JSON. 템플릿은 JSON의 상위 집합을 사용하여 식과 함수로 구문을 확장합니다.Templates use a superset of JSON, extending the syntax with expressions and functions. 템플릿 언어 프로세서는 추가 템플릿 함수를 지원하기 위해 자주 업데이트됩니다.The template language processor is frequently updated to support additional template functions. 사용 가능한 템플릿 함수에 대한 자세한 설명은 Azure Resource Manager 템플릿 함수를 참조하세요.For a detailed explanation of the available template functions, see Azure Resource Manager template functions.

Azure Resource Manager에 도입된 새 템플릿 함수는 소버린 클라우드 또는 Azure Stack에서 즉시 사용할 수 없습니다.New template functions that are introduced to Azure Resource Manager aren't immediately available in the sovereign clouds or Azure Stack. 템플릿을 성공적으로 배포하려면 템플릿에 참조된 모든 함수를 대상 클라우드에서 사용할 수 있어야 합니다.To deploy a template successfully, all functions referenced in the template must be available in the target cloud.

Azure Resource Manager 기능은 항상 전역 Azure에 먼저 도입됩니다.Azure Resource Manager capabilities will always be introduced to global Azure first. 다음 PowerShell 스크립트를 사용하여 새로 도입된 템플릿 함수를 Azure Stack에서도 사용할 수 있는지 여부를 확인할 수 있습니다.You can use the following PowerShell script to verify whether newly introduced template functions are also available in Azure Stack:

  1. GitHub 리포지토리의 복제본을 만듭니다. https://github.com/marcvaneijk/arm-template-functionsMake a clone of the GitHub repository: https://github.com/marcvaneijk/arm-template-functions.

  2. 리포지토리의 로컬 복제본이 있으면 PowerShell을 사용하여 대상의 Azure Resource Manager에 연결합니다.Once you have a local clone of the repository, connect to the destination's Azure Resource Manager with PowerShell.

  3. psm1 모듈을 가져오고 Test-AzureRmureRmTemplateFunctions cmdlet을 실행합니다.Import the psm1 module and execute the Test-AzureRmureRmTemplateFunctions cmdlet:

    # Import the module
    Import-module <path to local clone>\AzTemplateFunctions.psm1
    
    # Execute the Test-AzureRmTemplateFunctions cmdlet
    Test-AzureRmTemplateFunctions -path <path to local clone>
    

스크립트는 각각 고유한 템플릿 함수만 포함하는 여러 개의 최소화된 템플릿을 배포합니다.The script deploys multiple, minimized templates, each containing only unique template functions. 스크립트 출력은 지원되는 템플릿 함수와 사용할 수 없는 템플릿 함수를 보고합니다.The output of the script reports the supported and unavailable template functions.

연결된 아티팩트 작업Working with linked artifacts

템플릿은 연결된 아티팩트에 대한 참조와, 다른 템플릿에 연결하는 배포 리소스를 포함할 수 있습니다.A template can contain references to linked artifacts and contain a deployment resource that links to another template. 연결된 템플릿(중첩된 템플릿이라고도 함)은 런타임에 리소스 관리자에 의해 검색됩니다.The linked templates (also referred to as nested template) are retrieved by Resource Manager at runtime. 템플릿에 VM(가상 머신) 확장의 아티팩트에 대한 참조가 포함될 수도 있습니다.A template can also contain references to artifacts for virtual machine (VM) extensions. 이러한 아티팩트는 템플릿 배포 중 VM 확장의 구성을 위해 VM 내부에서 실행되는 VM 확장에 의해 검색됩니다.These artifacts are retrieved by the VM extension running inside of the VM for configuration of the VM extension during the template deployment.

다음 섹션에서는 기본 배포 템플릿 외부에 있는 아티팩트를 포함하는 템플릿을 개발할 때 클라우드 일관성을 위해 고려할 사항을 설명합니다.The following sections describe considerations for cloud consistency when developing templates that include artifacts that are external to the main deployment template.

지역 간에 중첩된 템플릿 사용Use nested templates across regions

템플릿은 각각 특정 용도가 있으며 배포 시나리오 간에 재사용할 수 있는 작은 재사용 가능 템플릿으로 분해할 수 있습니다.Templates can be decomposed into small, reusable templates, each of which has a specific purpose and can be reused across deployment scenarios. 배포를 실행하려면 기본 또는 마스터 템플릿으로 알려진 단일 템플릿을 지정합니다.To execute a deployment, you specify a single template known as the main or master template. 가상 네트워크, VM, 웹앱 등 배포할 리소스를 지정합니다.It specifies the resources to deploy, such as virtual networks, VMs, and web apps. 기본 템플릿은 다른 템플릿에 대한 링크를 포함할 수도 있습니다. 즉, 템플릿을 중첩할 수 있습니다.The main template can also contain a link to another template, meaning you can nest templates. 마찬가지로, 중첩된 템플릿은 다른 템플릿에 대한 링크를 포함할 수 있습니다.Likewise, a nested template can contain links to other templates. 최대 5개 수준의 깊이까지 중첩할 수 있습니다.You can nest up to five levels deep.

다음 코드는 templateLink 매개 변수가 중첩된 템플릿을 참조하는 방법을 보여 줍니다.The following code shows how the templateLink parameter refers to a nested template:

"resources": [
  {
     "apiVersion": "2017-05-10",
     "name": "linkedTemplate",
     "type": "Microsoft.Resources/deployments",
     "properties": {
       "mode": "incremental",
       "templateLink": {
          "uri":"https://mystorageaccount.blob.core.windows.net/AzureTemplates/vNet.json",
          "contentVersion":"1.0.0.0"
       }
     }
  }
]

Azure Resource Manager는 런타임에 기본 템플릿을 평가하고, 중첩된 각 템플릿을 검색 및 평가합니다.Azure Resource Manager evaluates the main template at runtime and retrieves and evaluates each nested template. 중첩된 템플릿이 모두 검색되면 템플릿이 평면화되고 추가 처리가 시작됩니다.After all nested templates are retrieved, the template is flattened, and further processing is initiated.

연결된 템플릿을 클라우드 간에 액세스할 수 있도록 설정Make linked templates accessible across clouds

사용하는 연결된 템플릿을 저장하는 방법 및 위치를 고려합니다.Consider where and how to store any linked templates you use. 런타임에 Azure Resource Manager가 연결된 템플릿을 모두 페치하므로, 직접 액세스할 수 있어야 합니다.At runtime, Azure Resource Manager fetches—and therefore requires direct access to—any linked templates. 일반적인 방법은 GitHub를 사용하여 중첩된 템플릿을 저장하는 것입니다.A common practice is to use GitHub to store the nested templates. GitHub 리포지토리는 URL을 통해 공개적으로 액세스할 수 있는 파일을 포함할 수 있습니다.A GitHub repository can contain files that are accessible publicly through a URL. 이 방법은 공용 클라우드 및 소버린 클라우드에서 효과적이지만, Azure Stack 환경이 아웃바운드 인터넷 액세스 없이 회사 네트워크 또는 연결이 끊긴 원격 위치에 있을 수도 있습니다.Although this technique works well for the public cloud and the sovereign clouds, an Azure Stack environment might be located on a corporate network or on a disconnected remote location, without any outbound Internet access. 이러한 경우, Azure Resource Manager가 중첩된 템플릿을 검색하지 못합니다.In those cases, Azure Resource Manager would fail to retrieve the nested templates.

클라우드 간 배포에 더 효과적인 방법은 대상 클라우드가 액세스할 수 있는 위치에 연결된 템플릿을 저장하는 것입니다.A better practice for cross-cloud deployments is to store your linked templates in a location that is accessible for the target cloud. CI/CD(지속적인 통합/지속적인 업데이트) 파이프라인에서 모든 배포 아티팩트를 유지 관리하고 배포하는 것이 이상적입니다.Ideally all deployment artifacts are maintained in and deployed from a continuous integration/continuous development (CI/CD) pipeline. 또는 Azure Resource Manager가 검색할 수 있는 Blob Storage 컨테이너에 중첩된 템플릿을 저장할 수 있습니다.Alternatively, you can store nested templates in a blob storage container, from which Azure Resource Manager can retrieve them.

각 클라우드의 Blob Storage는 서로 다른 엔드포인트 FQDN(정규화된 도메인 이름)을 사용하므로 연결된 템플릿의 위치를 두 매개 변수로 지정하여 템플릿을 구성합니다.Since the blob storage on each cloud uses a different endpoint fully qualified domain name (FQDN), configure the template with the location of the linked templates with two parameters. 매개 변수는 배포 시 사용자 입력을 수락할 수 있습니다.Parameters can accept user input at deployment time. 일반적으로 템플릿은 여러 사용자가 작성해서 공유하므로, 이러한 매개 변수에 대해 표준 이름을 사용하는 것이 좋습니다.Templates are typically authored and shared by multiple people, so a best practice is to use a standard name for these parameters. 명명 규칙을 통해 지역, 클라우드 및 작성자 간에 템플릿 재사용을 더 용이하게 만들 수 있습니다.Naming conventions help make templates more reusable across regions, clouds, and authors.

다음 코드에서 _artifactsLocation은 모든 배포 관련 아티팩트를 포함하는 단일 위치를 가리키는 데 사용됩니다.In the following code, _artifactsLocation is used to point to a single location, containing all deployment-related artifacts. 기본값이 제공되었습니다.Notice that a default value is provided. 배포 시 _artifactsLocation에 대해 입력 값이 지정되지 않으면 기본값이 사용됩니다.At deployment time, if no input value is specified for _artifactsLocation, the default value is used. _artifactsLocationSasTokensasToken에 대한 입력으로 사용됩니다.The _artifactsLocationSasToken is used as input for the sasToken. _artifactsLocation이 보안되지 않는 시나리오(예: 공용 GitHub 리포지토리)에서는 기본값이 빈 문자열이어야 합니다.The default value should be an empty string for scenarios where the _artifactsLocation isn't secured — for example, a public GitHub repository.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/201-vm-custom-script-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

템플릿 전체에서 링크는 기본 URI(_artifactsLocation 매개 변수)와 아티팩트 상대 경로 및 _artifactsLocationSasToken을 결합하여 생성됩니다.Throughout the template, links are generated by combining the base URI (from the _artifactsLocation parameter) with an artifact-relative path and the _artifactsLocationSasToken. 다음 코드는 uri 템플릿 함수를 사용하여 중첩된 템플릿에 대한 링크를 지정하는 방법을 보여 줍니다.The following code shows how to specify the link to the nested template using the uri template function:

"resources": [
  {
    "name": "shared",
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2015-01-01",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "[uri(parameters('_artifactsLocation'), concat('nested/vnet.json', parameters('_artifactsLocationSasToken')))]",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

이 방법을 사용하면 _artifactsLocation 매개 변수의 기본값이 사용됩니다.By using this approach, the default value for the _artifactsLocation parameter is used. 다른 위치에서 연결된 템플릿을 검색해야 하는 경우, 배포 시 매개 변수 입력을 사용하여 기본값을 재정의할 수 있습니다. 템플릿 자체는 변경할 필요가 없습니다.If the linked templates need to be retrieved from a different location, the parameter input can be used at deployment time to override the default value—no change to the template itself is needed.

중첩된 템플릿에 사용되는 것 외에도 _artifactsLocation 매개 변수의 URL은 배포 템플릿의 모든 관련 아티팩트에 대한 기준으로 사용됩니다.Besides being used for nested templates, the URL in the _artifactsLocation parameter is used as a base for all related artifacts of a deployment template. 일부 VM 확장에는 템플릿 외부에서 저장된 스크립트에 대한 링크가 포함되어 있습니다.Some VM extensions include a link to a script stored outside the template. 이러한 확장의 경우, 링크를 하드 코딩하면 안 됩니다.For these extensions, you should not hardcode the links. 예를 들어, 사용자 지정 스크립트 및 PowerShell DSC 확장은 다음과 같이 GitHub의 외부 스크립트에 연결될 수 있습니다.For example, the Custom Script and PowerShell DSC extensions may link to an external script on GitHub as shown:

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/scripts/configure-music-app.ps1"
    ]
  }
}

스크립트에 대한 링크를 하드 코딩하면 템플릿이 다른 위치에 배포되지 않을 수 있습니다.Hardcoding the links to the script potentially prevents the template from deploying successfully to another location. VM 리소스 구성 중에 VM 내부에서 실행 중인 VM 에이전트는 VM 확장에 연결된 모든 스크립트의 다운로드를 시작한 다음, VM의 로컬 디스크에 스크립트를 저장합니다.During configuration of the VM resource, the VM agent running inside the VM initiates a download of all the scripts linked in the VM extension, and then stores the scripts on the VM's local disk. 이 방법은 앞의 “지역 간에 중첩된 템플릿 사용” 섹션에서 설명한 중첩된 템플릿 링크처럼 작동합니다.This approach functions like the nested template links explained earlier in the "Use nested templates across regions" section.

리소스 관리자는 런타임에 중첩된 템플릿을 검색합니다.Resource Manager retrieves nested templates at runtime. VM 확장의 경우, VM 에이전트가 외부 아티팩트 검색을 수행합니다.For VM extensions, the retrieval of any external artifacts is performed by the VM agent. 아티팩트 검색의 개시 장치가 다르다는 점을 제외하면 템플릿 정의의 솔루션은 동일합니다.Besides the different initiator of the artifact retrieval, the solution in the template definition is the same. VM 확장 스크립트를 포함한 모든 아티팩트가 저장되는 기본 경로인 기본값이 적용된 _artifactsLocation 매개 변수와 sasToken에 대한 입력을 제공하는 _artifactsLocationSasToken 매개 변수를 사용합니다.Use the _artifactsLocation parameter with a default value of the base path where all the artifacts are stored (including the VM extension scripts) and the _artifactsLocationSasToken parameter for the input for the sasToken.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

아티팩트의 절대 URI를 구성하려는 경우, concat 템플릿 함수 대신 uri 템플릿 함수를 사용하는 것이 좋습니다.To construct the absolute URI of an artifact, the preferred method is to use the uri template function, instead of the concat template function. VM 확장의 스크립트에 대한 하드 코딩된 링크를 uri 템플릿 함수로 바꾸면 템플릿의 이 기능이 클라우드 일관성을 위해 구성됩니다.By replacing hardcoded links to the scripts in the VM extension with the uri template function, this functionality in the template is configured for cloud consistency.

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "[uri(parameters('_artifactsLocation'), concat('scripts/configure-music-app.ps1', parameters('_artifactsLocationSasToken')))]"
    ]
  }
}

이 방법을 사용하면 구성 스크립트를 포함한 모든 배포 아티팩트를 템플릿 자체와 동일한 위치에 저장할 수 있습니다.With this approach, all deployment artifacts, including configuration scripts, can be stored in the same location with the template itself. 모든 링크의 위치를 변경하려면 _artifactsLocation 매개 변수_에 대해 다른 기준 URL을 지정하기만 하면 됩니다.To change the location of all the links, you only need to specify a different base URL for the artifactsLocation parameters.

지역별 기능 차이 고려Factor in differing regional capabilities

Azure에 도입되는 새로운 서비스 및 업데이트의 민첩한 개발 및 지속적인 흐름 때문에 서비스나 업데이트의 가용성은 지역에 따라 다를 수 있습니다.With the agile development and continuous flow of updates and new services introduced to Azure, regions can differ in availability of services or updates. 엄격한 내부 테스트를 수행한 후 기존 서비스에 대한 업데이트 또는 새로운 서비스는 일반적으로 유효성 검사 프로그램에 참여하는 소규모 대상 고객에게 도입됩니다.After rigorous internal testing, new services or updates to existing services are usually introduced to a small audience of customers participating in a validation program. 고객 유효성 검사에 성공하면 서비스 또는 업데이트가 일부 Azure 지역에서만 제공된 다음, 더 많은 지역에 도입되고 소버린 클라우드에 배포되며 Azure Stack 고객에게도 제공될 수 있습니다.After successful customer validation, the services or updates are made available within a subset of Azure regions, then introduced to more regions, rolled out to the sovereign clouds, and potentially made available for Azure Stack customers as well.

Azure 지역 및 클라우드에 따라 사용 가능한 서비스가 다를 수 있음을 알고 있으면 템플릿에 대해 몇 가지 사전 대응형 결정을 내릴 수 있습니다.Knowing that Azure regions and clouds may differ in their available services, you can make some proactive decisions about your templates. 먼저 클라우드에 사용할 수 있는 리소스 공급자를 조사하는 것이 좋습니다.A good place to start is by examining the available resource providers for a cloud. 리소스 공급자는 Azure 서비스에 사용할 수 있는 리소스 및 작업 집합을 알려 줍니다.A resource provider tells you the set of resources and operations that are available for an Azure service.

템플릿은 리소스를 배포하고 구성합니다.A template deploys and configures resources. 리소스 종류는 리소스 공급자가 제공합니다.A resource type is provided by a resource provider. 예를 들어, 계산 리소스 공급자(Microsoft.Compute)는 virtualMachines, availabilitySets 등의 여러 리소스 종류를 제공합니다.For example, the compute resource provider (Microsoft.Compute), provides multiple resource types such as virtualMachines and availabilitySets. 각 리소스 공급자가 공통 계약에 정의된 Azure Resource Manager용 API를 제공하므로 모든 리소스 공급자에서 일관성 있는 통합 작성 환경을 사용할 수 있습니다.Each resource provider provides an API to Azure Resource Manager defined by a common contract, enabling a consistent, unified authoring experience across all resource providers. 그러나 전역 Azure에서 사용할 수 있는 리소스 공급자를 소버린 클라우드 또는 Azure Stack 지역에서는 사용하지 못할 수도 있습니다.However, a resource provider that is available in global Azure may not be available in a sovereign cloud or an Azure Stack region.

리소스 공급자

지정된 클라우드에서 사용할 수 있는 리소스 공급자를 확인하려면 Azure CLI(명령줄 인터페이스)에서 다음 스크립트를 실행합니다.To verify the resource providers that are available in a given cloud, run the following script in the Azure command line interface (CLI):

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table

다음 PowerShell cmdlet을 사용하여 사용 가능한 리소스 공급자를 확인할 수도 있습니다.You can also use the following PowerShell cmdlet to see available resource providers:

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

모든 리소스 종류의 버전 확인Verify the version of all resource types

속성 집합은 모든 리소스 종류에 공통적이지만, 리소스마다 고유한 특정 속성도 있습니다.A set of properties is common for all resource types, but each resource also has its own specific properties. 새 API 버전을 통해 때때로 새로운 기능 및 관련 속성이 기존 리소스 종류에 추가됩니다.New features and related properties are added to existing resource types at times through a new API version. 템플릿의 리소스에는 고유한 API 버전 속성(apiVersion)이 있습니다.A resource in a template has its own API version property - apiVersion. 이 버전 관리는 템플릿의 기존 리소스 구성이 플랫폼의 변경 내용에 영향을 받지 않도록 합니다.This versioning ensures that an existing resource configuration in a template is not affected by changes on the platform.

전역 Azure의 기존 리소스 종류에 도입된 새 API 버전을 모든 지역, 소버린 클라우드 또는 Azure Stack에서 즉시 사용할 수 있는 것은 아닙니다.New API versions introduced to existing resource types in global Azure might not immediately be available in all regions, sovereign clouds, or Azure Stack. 클라우드에 사용할 수 있는 리소스 공급자, 리소스 종류 및 API 버전 목록을 보려면 Azure Portal에서 리소스 탐색기를 사용합니다.To view a list of the available resource providers, resource types, and API versions for a cloud, you can use Resource Explorer in Azure portal. 모든 서비스 메뉴에서 리소스 탐색기를 검색합니다.Search for Resource Explorer in the All Services menu. 리소스 탐색기의 공급자 노드를 확장하여 해당 클라우드에서 사용 가능한 모든 리소스 공급자, 해당 리소스 종류 및 API 버전을 반환합니다.Expand the Providers node in Resource Explorer to return all the available resource providers, their resource types, and API versions in that cloud.

Azure CLI에서 지정된 클라우드의 모든 리소스 종류에 사용할 수 있는 API 버전을 나열하려면 다음 스크립트를 실행합니다.To list the available API version for all resource types in a given cloud in Azure CLI, run the following script:

az provider list --query "[].{namespace:namespace, resourceType:resourceType[]}"

다음 PowerShell cmdlet을 사용할 수도 있습니다.You can also use the following PowerShell cmdlet:

Get-AzureRmResourceProvider | select-object ProviderNamespace -ExpandProperty ResourceTypes | ft ProviderNamespace, ResourceTypeName, ApiVersions

매개 변수를 사용하여 리소스 위치 참조Refer to resource locations with a parameter

템플릿은 항상 지역에 있는 리소스 그룹에 배포됩니다.A template is always deployed into a resource group that resides in a region. 배포 자체 외에도, 템플릿의 각 리소스에는 배포할 지역을 지정하는 데 사용하는 위치 속성이 있습니다.Besides the deployment itself, each resource in a template also has a location property that you use to specify the region to deploy in. 클라우드 일관성을 위한 템플릿을 개발하려면 각 Azure Stack에 고유한 위치 이름이 포함될 수 있으므로 리소스 위치를 참조하는 동적 방법이 필요합니다.To develop your template for cloud consistency, you need a dynamic way to refer to resource locations, because each Azure Stack can contain unique location names. 일반적으로 리소스는 리소스 그룹과 동일한 지역에 배포되지만, 지역 간 애플리케이션 가용성 등의 시나리오를 지원하려면 전체 지역에 리소스를 분산하는 것이 유용할 수 있습니다.Usually resources are deployed in the same region as the resource group, but to support scenarios such as cross-region application availability, it can be useful to spread resources across regions.

템플릿에서 리소스 속성을 지정할 때 지역 이름을 하드 코딩할 수는 있지만, 이 방법을 사용할 경우, 다른 Azure Stack 환경에는 지역 이름이 존재하지 않을 가능성이 크기 때문에 해당 템플릿을 배포하지 못할 수 있습니다.Even though you could hardcode the region names when specifying the resource properties in a template, this approach doesn't guarantee that the template can be deployed to other Azure Stack environments, because the region name most likely doesn't exist there.

여러 지역을 수용하려면 입력 매개 변수 위치를 기본값과 함께 템플릿에 추가합니다.To accommodate different regions, add an input parameter location to the template with a default value. 배포 중에 값이 지정되지 않으면 기본값이 사용됩니다.The default value will be used if no value is specified during deployment.

템플릿 함수 [resourceGroup()]은 다음 키/값 쌍이 포함된 개체를 반환합니다.The template function [resourceGroup()] returns an object that contains the following key/value pairs:

{
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}",
  "name": "{resourceGroupName}",
  "location": "{resourceGroupLocation}",
  "tags": {
  },
  "properties": {
    "provisioningState": "{status}"
  }
}

입력 매개 변수의 defaultValue에서 개체의 위치 키를 참조하면 Azure Resource Manager는 런타임에 [resourceGroup().location] 템플릿 함수를 템플릿이 배포된 리소스 그룹의 위치 이름으로 바꿉니다.By referencing the location key of the object in the defaultValue of the input parameter, Azure Resource Manager will, at runtime, replace the [resourceGroup().location] template function with the name of the location of the resource group the template is deployed to.

"parameters": {
  "location": {
    "type": "string",
    "metadata": {
      "description": "Location the resources will be deployed to."
    },
    "defaultValue": "[resourceGroup().location]"
  }
},
"resources": [
  {
    "name": "storageaccount1",
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2015-06-15",
    "location": "[parameters('location')]",
    ...

이 템플릿 함수를 사용하면 지역 이름을 미리 알지 못해도 모든 클라우드에 템플릿을 배포할 수 있습니다.With this template function, you can deploy your template to any cloud without even knowing the region names in advance. 또한 템플릿의 특정 리소스 위치가 리소스 그룹 위치와 다를 수 있습니다.In addition, a location for a specific resource in the template can differ from the resource group location. 이 경우, 동일한 템플릿의 다른 리소스는 초기 위치 입력 매개 변수를 계속 사용하는 반면, 해당 특정 리소스에 대해 추가 입력 매개 변수를 사용하여 이 설정을 구성할 수 있습니다.In this case, you can configure it by using additional input parameters for that specific resource, while the other resources in the same template still use the initial location input parameter.

API 프로필을 사용하여 버전 추적Track versions using API profiles

Azure Stack에 있는 사용 가능한 모든 리소스 공급자 및 관련 API 버전을 추적하는 것은 매우 어려울 수 있습니다.It can be very challenging to keep track of all the available resource providers and related API versions that are present in Azure Stack. 예를 들어, 이 문서를 작성할 당시, Azure의 Microsoft.Compute/availabilitySets에 대한 최신 API 버전은 2018-04-01이고 Azure 및 Azure Stack에 공통적으로 사용 가능한 API 버전은 2016-03-30입니다.For example, at the time of writing, the latest API version for Microsoft.Compute/availabilitySets in Azure is 2018-04-01, while the available API version common to Azure and Azure Stack is 2016-03-30. 모든 Azure 및 Azure Stack 위치에서 공유되는, Microsoft.Storage/storageAccounts에 대한 공통 API 버전은 2016-01-01이고 Azure의 최신 API 버전은 2018-02-01입니다.The common API version for Microsoft.Storage/storageAccounts shared among all Azure and Azure Stack locations is 2016-01-01, while the latest API version in Azure is 2018-02-01.

따라서 리소스 관리자는 템플릿에 API 프로필 개념을 도입했습니다.For this reason, Resource Manager introduced the concept of API profiles to templates. API 프로필이 없으면 템플릿의 각 리소스가 해당 특정 리소스의 API 버전을 설명하는 apiVersion 요소로 구성됩니다.Without API profiles, each resource in a template is configured with an apiVersion element that describes the API version for that specific resource.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "name": "mystorageaccount",
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2016-01-01",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "name": "myavailabilityset",
            "type": "Microsoft.Compute/availabilitySets",
            "apiVersion": "2016-03-30",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

API 프로필 버전은 Azure 및 Azure Stack에 공통적인 리소스 종류당 단일 API 버전의 별칭으로 사용됩니다.An API profile version acts as an alias for a single API version per resource type common to Azure and Azure Stack. 템플릿의 각 리소스에 대해 API 버전을 지정하는 대신, apiProfile이라는 새 루트 요소에만 API 프로필 버전을 지정하고 개별 리소스에 대한 apiVersion 요소를 생략합니다.Instead of specifying an API version for each resource in a template, you specify only the API profile version in a new root element called apiProfile and omit the apiVersion element for the individual resources.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "name": "mystorageaccount",
            "type": "Microsoft.Storage/storageAccounts",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "name": "myavailabilityset",
            "type": "Microsoft.Compute/availabilitySets",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

API 프로필을 통해 전체 위치에서 API 버전을 사용할 수 있으므로, 특정 위치에서 사용할 수 있는 apiVersions를 수동으로 확인할 필요가 없습니다.The API profile ensures that the API versions are available across locations, so you do not have to manually verify the apiVersions that are available in a specific location. API 프로필에서 참조하는 API 버전이 Azure Stack 환경에 있도록 하려면 Azure Stack 운영자가 지원 정책에 따라 솔루션을 최신 상태로 유지해야 합니다.To ensure the API versions referenced by your API profile are present in an Azure Stack environment, the Azure Stack operators must keep the solution up-to-date based on the policy for support. 6개월 이상 업데이트하지 않은 시스템 버전은 비규격으로 간주되며, Azure Stack 환경을 업데이트해야 합니다.If a system is more than six months out of date, it is considered out of compliance, and the environment must be updated.

API 프로필은 템플릿의 필수 요소가 아닙니다.The API profile isn't a required element in a template. 요소를 추가해도, apiVersion이 지정되지 않은 리소스에만 사용됩니다.Even if you add the element, it will only be used for resources for which no apiVersion is specified. 이 요소는 점진적인 변경을 허용하지만, 기존 템플릿을 변경할 필요는 없습니다.This element allows for gradual changes but doesn't require any changes to existing templates.

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "name": "mystorageaccount",
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2016-01-01",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "name": "myavailabilityset",
            "type": "Microsoft.Compute/availabilitySets",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

엔드포인트 참조 확인Check endpoint references

리소스에 플랫폼의 다른 서비스에 대한 참조가 포함될 수 있습니다.Resources can have references to other services on the platform. 예를 들어, 공용 IP에는 공용 DNS 이름이 할당될 수 있습니다.For example, a public IP can have a public DNS name assigned to it. 공용 클라우드, 소버린 클라우드 및 Azure Stack 솔루션에는 고유한 엔드포인트 네임스페이스가 있습니다.The public cloud, the sovereign clouds, and Azure Stack solutions have their own distinct endpoint namespaces. 대부분의 경우, 템플릿에서 필요한 리소스에 대한 입력은 접두사뿐입니다.In most cases, a resource requires only a prefix as input in the template. 런타임에 Azure Resource Manager가 엔드포인트 값을 접두사에 추가합니다.During runtime, Azure Resource Manager appends the endpoint value to it. 일부 엔드포인트 값은 템플릿에서 명시적으로 지정해야 합니다.Some endpoint values need to be explicitly specified in the template.

참고

클라우드 일관성을 위한 템플릿을 개발하려면 엔드포인트 네임스페이스를 하드 코딩하면 안 됩니다.To develop templates for cloud consistency, don't hardcode endpoint namespaces.

다음 두 예는 리소스를 만들 때 명시적으로 지정해야 하는 공통 엔드포인트 네임스페이스입니다.The following two examples are common endpoint namespaces that need to be explicitly specified when creating a resource:

  • 저장소 계정(Blob, 큐, 테이블 및 파일)Storage accounts (blob, queue, table and file)
  • 데이터베이스 및 Azure Cache for Redis에 대한 연결 문자열Connection strings for databases and Azure Cache for Redis

배포가 완료되면 사용자를 위한 정보로 템플릿 출력에 엔드포인트 네임스페이스를 사용할 수도 있습니다.Endpoint namespaces can also be used in the output of a template as information for the user when the deployment completes. 다음은 일반적인 예입니다.The following are common examples:

  • 저장소 계정(Blob, 큐, 테이블 및 파일)Storage accounts (blob, queue, table and file)
  • 연결 문자열(MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)Connection strings (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
  • Traffic ManagerTraffic Manager
  • 공용 IP 주소의 domainNameLabeldomainNameLabel of a public IP address
  • 클라우드 서비스Cloud services

일반적으로, 템플릿에 하드 코딩된 엔드포인트를 사용하면 안 됩니다.In general, avoid hardcoded endpoints in a template. 모범 사례는 reference 템플릿 함수를 사용하여 엔드포인트를 동적으로 검색하는 것입니다.The best practice is to use the reference template function to retrieve the endpoints dynamically. 예를 들어, 가장 일반적으로 하드 코딩되는 엔드포인트는 저장소 계정의 엔드포인트 네임스페이스입니다.For example, the endpoint most commonly hardcoded is the endpoint namespace for storage accounts. 각 저장소 계정에는 저장소 계정 이름과 엔드포인트 네임스페이스를 연결하여 생성된 고유 FQDN이 있습니다.Each storage account has a unique FQDN that is constructed by concatenating the name of the storage account with the endpoint namespace. mystorageaccount1이라는 Blob Storage 계정은 클라우드에 따라 다른 FQDN을 생성합니다.A blob storage account named mystorageaccount1 results in different FQDNs depending on the cloud:

  • 전역 Azure 클라우드에 만든 경우, mystorageaccount1.blob.core.windows.netmystorageaccount1.blob.core.windows.net when created on the global Azure cloud.
  • Azure 중국 클라우드에 만든 경우, mystorageaccount1.blob.core.chinacloudapi.cnmystorageaccount1.blob.core.chinacloudapi.cn when created in the Azure China cloud.

다음 reference 템플릿 함수는 저장소 리소스 공급자에서 엔드포인트 네임스페이스를 검색합니다.The following reference template function retrieves the endpoint namespace from the storage resource provider:

"diskUri":"[concat(reference(concat('Microsoft.Storage/storageAccounts/', variables('storageAccountName')), '2015-06-15').primaryEndpoints.blob, 'container/myosdisk.vhd')]"

저장소 계정 엔드포인트의 하드 코딩된 값을 reference 템플릿 함수로 바꾸면 엔드포인트 참조를 변경하지 않고도 동일한 템플릿을 사용하여 다른 환경에 배포할 수 있습니다.By replacing the hardcoded value of the storage account endpoint with the reference template function, you can use the same template to deploy to different environments successfully without making any changes to the endpoint reference.

고유 ID로 기존 리소스 참조Refer to existing resources by unique ID

동일한 클라우드의 동일한 테넌트에 있는 동일한 구독 또는 다른 구독과 동일한 리소스 그룹 또는 다른 리소스 그룹의 기존 리소스를 참조할 수도 있습니다.You can also refer to an existing resource from the same or another resource group, and within the same subscription or another subscription, within the same tenant in the same cloud. 리소스 속성을 검색하려면 리소스 자체의 고유 식별자를 사용해야 합니다.To retrieve the resource properties, you must use the unique identifier for the resource itself. 다음 코드에서 볼 수 있듯이, resourceId 템플릿 함수는 SQL Server 같은 리소스의 고유 ID를 검색합니다.The resourceId template function retrieves the unique ID of a resource such as SQL Server as the following code shows:

"outputs": {
  "resourceId":{
    "type": "string",
    "value": "[resourceId('otherResourceGroup', 'Microsoft.Sql/servers', parameters('serverName'))]"
  }
}

그런 다음, reference 템플릿 함수 내에서 resourceId 함수를 사용하여 데이터베이스 속성을 검색할 수 있습니다.You can then use the resourceId function inside the reference template function to retrieve the properties of a database. 반환 개체에는 전체 엔드포인트 값이 포함된 fullyQualifiedDomainName 속성이 있습니다.The return object contains the fullyQualifiedDomainName property that holds the full endpoint value. 이 값은 런타임에 검색되며, 클라우드 환경 특정 엔드포인트 네임스페이스를 제공합니다.This value is retrieved at runtime and provides the cloud environment-specific endpoint namespace. 엔드포인트 네임스페이스를 하드 코딩하지 않고 연결 문자열을 정의하려면 다음과 같이 연결 문자열에서 직접 반환 개체의 속성을 참조할 수 있습니다.To define the connection string without hardcoding the endpoint namespace, you can refer to the property of the return object directly in the connection string as shown:

"[concat('Server=tcp:', reference(resourceId('sql', 'Microsoft.Sql/servers', parameters('test')), '2015-05-01-preview').fullyQualifiedDomainName, ',1433;Initial Catalog=', parameters('database'),';User ID=', parameters('username'), ';Password=', parameters('pass'), ';Encrypt=True;')]"

리소스 속성 고려Consider resource properties

Azure Stack 환경의 특정 리소스에는 템플릿에서 고려해야 하는 고유한 속성이 있습니다.Specific resources within Azure Stack environments have unique properties you must consider in your template.

VM 이미지를 사용할 수 있는지 확인Ensure VM images are available

Azure는 다양한 VM 이미지를 제공합니다.Azure provides a rich selection of VM images. Microsoft 및 파트너가 이러한 이미지를 만들고 배포 준비를 합니다.These images are created and prepared for deployment by Microsoft and partners. 이미지는 플랫폼에서 VM의 토대를 형성합니다.The images form the foundation for VMs on the platform. 그러나 클라우드 일치 템플릿은 전역 Azure, Azure 소버린 클라우드 또는 Azure Stack 솔루션에서 사용할 수 있는 VM 이미지의 사용 가능한 매개 변수(특히 publisher, offer 및 SKU)만 참조해야 합니다.However, a cloud-consistent template should refer to available parameters only — in particular, the publisher, offer, and SKU of the VM images available to the global Azure, Azure sovereign clouds, or an Azure Stack solution.

특정 위치에서 사용 가능한 VM 이미지 목록을 검색하려면 다음 Azure CLI 명령을 실행합니다.To retrieve a list of the available VM images in a location, run the following Azure CLI command:

az vm image list -all

-Location 매개 변수를 통해 원하는 위치를 지정하여 Azure PowerShell cmdlet Get-AzureRmVMImagePublisher를 사용하면 동일한 목록을 검색할 수 있습니다.You can retrieve the same list with the Azure PowerShell cmdlet Get-AzureRmVMImagePublisher and specify the location you want with the -Location parameter. 예를 들면 다음과 같습니다.For example:

Get-AzureRmVMImagePublisher -Location "West Europe" | Get-AzureRmVMImageOffer | Get-AzureRmVMImageSku | Get-AzureRmVMImage

이 명령은 몇 분 후에 전역 Azure 클라우드의 유럽 서부 지역에서 사용 가능한 모든 이미지를 반환합니다.This command takes a couple of minutes to return all the available images in the West Europe region of the global Azure cloud.

Azure Stack이 이러한 VM 이미지를 사용할 수 있도록 설정하면 사용 가능한 모든 저장소가 사용됩니다.If you made these VM images available to Azure Stack, all the available storage would be consumed. 가장 작은 배율 단위까지 수용하기 위해, Azure Stack을 사용하여 환경에 추가할 이미지를 선택할 수 있습니다.To accommodate even the smallest scale unit, Azure Stack allows you to select the images you want to add to an environment.

다음 코드 샘플은 Azure Resource Manager 템플릿의 publisher, offer 및 SKU 매개 변수를 참조하는 일관된 방법을 보여 줍니다.The following code sample shows a consistent approach to refer to the publisher, offer, and SKU parameters in your Azure Resource Manager templates:

"storageProfile": {
    "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "2016-Datacenter",
    "version": "latest"
    }
}

로컬 VM 크기 확인Check local VM sizes

클라우드 일관성을 위한 템플릿을 개발하려면 원하는 VM 크기를 모든 대상 환경에서 사용할 수 있도록 해야 합니다.To develop your template for cloud consistency, you need to make sure the VM size you want is available in all target environments. VM 크기는 성능 특성 및 기능의 그룹화입니다.VM sizes are a grouping of performance characteristics and capabilities. 일부 VM 크기는 VM이 실행되는 하드웨어에 따라 달라집니다.Some VM sizes depend on the hardware that the VM runs on. 예를 들어, GPU 최적화 VM을 배포하려면 하이퍼바이저를 실행하는 하드웨어에 하드웨어 GPU가 있어야 합니다.For example, if you want to deploy a GPU-optimized VM, the hardware that runs the hypervisor needs to have the hardware GPUs.

Microsoft에서 특정 하드웨어 종속성이 있는 새 VM 크기를 도입하는 경우, 해당 VM 크기는 일반적으로 Azure 클라우드의 일부 지역에서만 먼저 제공된 다음,When Microsoft introduces a new size of VM that has certain hardware dependencies, the VM size is usually made available first in a small subset of regions in the Azure cloud. 나중에 다른 지역 및 클라우드에도 제공됩니다.Later, it is made available to other regions and clouds. 배포할 각 클라우드에 VM 크기가 있는지 확인하려면 다음 Azure CLI 명령을 통해 사용 가능한 크기를 검색합니다.To make sure the VM size exists in each cloud you deploy to, you can retrieve the available sizes with the following Azure CLI command:

az vm list-sizes --location "West Europe"

Azure PowerShell의 경우 다음을 사용합니다.For Azure PowerShell, use:

Get-AzureRmVMSize -Location "West Europe"

사용 가능한 서비스의 전체 목록은 지역별 사용 가능한 제품을 참조하세요.For a full list of available services, see Products available by region.

Azure Stack에서 Azure Managed Disks 사용 확인Check use of Azure Managed Disks in Azure Stack

관리 디스크는 Azure 테넌트의 저장소를 처리합니다.Managed disks handle the storage for an Azure tenant. 명시적으로 저장소 계정을 만들고 VHD(가상 하드 디스크)의 URI를 지정하는 대신, VM을 배포할 때 관리 디스크를 사용하여 암시적으로 이러한 작업을 수행할 수 있습니다.Instead of explicitly creating a storage account and specifying the URI for a virtual hard disk (VHD), you can use managed disks to implicitly perform these actions when you deploy a VM. 관리 디스크는 동일한 가용성 집합에 있는 VM의 모든 디스크를 여러 다른 저장 단위에 배치하여 가용성을 향상합니다.Managed disks enhance availability by placing all the disks from VMs in the same availability set into different storage units. 또한 훨씬 짧은 가동 중지 시간으로 기존 VHD를 표준 스토리지에서 Premium Storage로 변환할 수 있습니다.Additionally, existing VHDs can be converted from Standard to Premium storage with significantly less downtime.

관리 디스크는 Azure Stack에 대한 로드맵에 있지만 현재 지원되지 않습니다.Although managed disks are on the roadmap for Azure Stack, they are currently not supported. 지원될 때까지, 다음과 같이 VM 리소스에 대한 템플릿에서 vhd 요소를 통해 명시적으로 VHD를 지정하면 Azure Stack용 클라우드 일치 템플릿을 개발할 수 있습니다.Until they are, you can develop cloud-consistent templates for Azure Stack by explicitly specifying VHDs using the vhd element in the template for the VM resource as shown:

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "name": "osdisk",
    "vhd": {
      "uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName')), '2015-06-15').primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
    },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

반면, 템플릿에서 관리 디스크 구성을 지정하려면 디스크 구성에서 vhd 요소를 제거합니다.In contrast, to specify a managed disk configuration in a template, remove the vhd element from the disk configuration.

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

동일한 변경 내용이 데이터 디스크에도 적용됩니다.The same changes also apply data disks.

Azure Stack에서 VM 확장을 사용할 수 있는지 확인Verify that VM extensions are available in Azure Stack

클라우드 일관성을 위한 또 다른 고려 사항은 가상 머신 확장을 사용하여 VM 내의 리소스를 구성하는 것입니다.Another consideration for cloud consistency is the use of virtual machine extensions to configure the resources inside a VM. Azure Stack에서 모든 VM 확장을 사용할 수 있는 것은 아닙니다.Not all VM extensions are available in Azure Stack. 템플릿은 VM 확장 전용 리소스를 지정하고, 템플릿 내에서 종속성과 조건을 만들 수 있습니다.A template can specify the resources dedicated to the VM extension, creating dependencies and conditions within the template.

예를 들어, Microsoft SQL Server를 실행하는 VM을 구성하려는 경우, VM 확장에서 템플릿 배포의 일부로 SQL Server를 구성할 수 있습니다.For example, if you want to configure a VM running Microsoft SQL Server, the VM extension can configure SQL Server as part the template deployment. SQL Server를 실행하는 VM에서 데이터베이스를 만들도록 구성된 애플리케이션 서버도 배포 템플릿에 포함되어 있을 경우, 발생하는 사항을 고려합니다.Consider what happens if the deployment template also contains an application server configured to create a database on the VM running SQL Server. 애플리케이션 서버에 VM 확장을 사용하는 것 외에도 SQL Server VM 확장 리소스의 성공적인 반환에 대한 애플리케이션 서버의 종속성을 구성할 수 있습니다.Besides also using a VM extension for the application servers, you can configure the dependency of the application server on the successful return of the SQL Server VM extension resource. 이 방법을 사용하면 애플리케이션 서버에 데이터베이스를 만들도록 지시할 때 SQL Server를 실행하는 VM이 구성되어 있고 사용할 수 있습니다.This approach ensures the VM running SQL Server is configured and available when the application server is instructed to create the database.

플랫폼이 종속성에 필요한 논리를 처리하는 동시에, 템플릿의 선언적 방법을 사용하여 리소스의 종료 상태와 상호 종속성을 정의할 수 있습니다.The declarative approach of the template allows you to define the end state of the resources and their inter-dependencies, while the platform takes care of the logic required for the dependencies.

VM 확장을 사용할 수 있는지 확인Check that VM extensions are available

많은 유형의 VM 확장이 있습니다.Many types of VM extensions exist. 클라우드 일관성을 위한 템플릿을 개발하는 경우, 템플릿의 모든 대상 지역에서 사용할 수 있는 확장만 사용해야 합니다.When developing template for cloud consistency, make sure to use only the extensions that are available in all the regions the template targets.

특정 지역(이 예제에서는 myLocation)에 사용할 수 있는 VM 확장 목록을 검색하려면 다음 Azure CLI 명령을 실행합니다.To retrieve a list of the VM extensions that are available for a specific region (in this example, myLocation), run the following Azure CLI command:

az vm extension image list --location myLocation

Azure PowerShell Get-AzureRmVmImagePublisher cmdlet을 실행하고 -Location을 사용하여 가상 머신 이미지의 위치를 지정할 수도 있습니다.You can also execute the Azure PowerShell Get-AzureRmVmImagePublisher cmdlet and use -Location to specify the location of the virtual machine image. 예를 들면 다음과 같습니다.For example:

Get-AzureRmVmImagePublisher -Location myLocation | Get-AzureRmVMExtensionImageType | Get-AzureRmVMExtensionImage | Select Type, Version

버전을 사용할 수 있는지 확인Ensure that versions are available

VM 확장은 자사 리소스 관리자 리소스이므로 고유한 API 버전이 있습니다.Since VM extensions are first-party Resource Manager resources, they have their own API versions. 다음 코드에서 볼 수 있듯이, VM 확장 유형은 Microsoft.Compute 리소스 공급자의 중첩된 리소스입니다.As the following code shows, the VM extension type is a nested resource in the Microsoft.Compute resource provider.

{
    "apiVersion": "2015-06-15",
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "name": "myExtension",
    "location": "[parameters('location')]",
    ...

템플릿의 모든 대상 위치에 VM 확장 리소스의 API 버전이 있어야 합니다.The API version of the VM extension resource must be present in all the locations you plan to target with your template. 위치 종속성은 앞의 “모든 리소스 종류의 버전 확인” 섹션에서 설명한 리소스 공급자 API 버전 가용성처럼 작동합니다.The location dependency works like the resource provider API version availability discussed earlier in the "Verify the version of all resource types" section.

VM 확장 리소스에 사용 가능한 API 버전 목록을 검색하려면 다음과 같이 Get-AzureRmResourceProvider cmdlet에 Microsoft.Compute 리소스 공급자를 사용합니다.To retrieve a list of the available API versions for the VM extension resource, use the Get-AzureRmResourceProvider cmdlet with the Microsoft.Compute resource provider as shown:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachines/extensions"}

가상 머신 확장 집합에 VM 확장을 사용할 수도 있습니다.You can also use VM extensions in virtual machine scale sets. 동일한 위치 조건이 적용됩니다.The same location conditions apply. 클라우드 일관성을 위한 템플릿을 개발하려면 배포할 모든 위치에서 API 버전을 사용할 수 있는지 확인합니다.To develop your template for cloud consistency, make sure the API versions are available in all the locations you plan on deploying to. 확장 집합에 대한 VM 확장 리소스의 API 버전을 검색하려면 이전과 동일한 cmdlet을 사용하되 가상 머신 확장 집합 리소스 종류를 다음과 같이 지정합니다.To retrieve the API versions of the VM extension resource for scale sets, use the same cmdlet as before, but specify the virtual machine scale sets resource type as shown:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachineScaleSets/extensions"}

각 특정 확장의 버전도 관리됩니다.Each specific extension is also versioned. 이 버전은 VM 확장의 typeHandlerVersion 속성에 표시됩니다.This version is shown in the typeHandlerVersion property of the VM extension. 템플릿을 배포할 위치에서 템플릿 VM 확장의 typeHandlerVersion 요소에 지정된 버전을 사용할 수 있는지 확인합니다.Make sure that the version specified in the typeHandlerVersion element of your template's VM extensions are available in the locations where you plan to deploy the template. 예를 들어, 다음 코드는 버전 1.7을 지정합니다.For example, the following code specifies version 1.7:

{
    "name": "MyCustomScriptExtension",
    "type": "extensions",
    "apiVersion": "2016-03-30",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/myVM', copyindex())]"
    ],
    "properties": {
        "publisher": "Microsoft.Compute",
        "type": "CustomScriptExtension",
        "typeHandlerVersion": "1.7",
        ...   

특정 VM 확장에 사용할 수 있는 버전 목록을 검색하려면 Get-AzureRmVMExtensionImage cmdlet을 사용합니다.To retrieve a list of the available versions for a specific VM extension, use the Get-AzureRmVMExtensionImage cmdlet. 다음 예제에서는 myLocation에서 PowerShell DSC(Desired State Configuration) VM 확장에 사용 가능한 버전을 검색합니다.The following example retrieves the available versions for the PowerShell DSC (Desired State Configuration) VM extension from myLocation:

Get-AzureRmVMExtensionImage -Location myLocation -PublisherName Microsoft.PowerShell -Type DSC | FT

게시자 목록을 가져오려면 Get-AzureRmVmImagePublisher 명령을 사용합니다.To get a list of publishers, use the Get-AzureRmVmImagePublisher command. 형식을 요청하려면 Get-AzureRmVMExtensionImageType 명령을 사용합니다.To request type, use the Get-AzureRmVMExtensionImageType commend.

테스트 및 자동화에 대한 팁Tips for testing and automation

템플릿을 작성하는 동안 모든 관련 설정, 기능 및 제한 사항을 추적하는 것은 어렵습니다.It's a challenge to keep track of all related settings, capabilities, and limitations while authoring a template. 일반적인 방법은 다른 위치를 대상으로 지정하기 전에 단일 클라우드에 대해 템플릿을 개발하고 테스트하는 것입니다.The common approach is to develop and test templates against a single cloud before other locations are targeted. 그러나 작성 프로세스에서 더 빨리 테스트를 수행할수록 개발 팀이 수행해야 하는 문제 해결 및 코드 재작성이 줄어듭니다.However, the earlier that tests are performed in the authoring process, the less troubleshooting and code rewriting your development team will have to do. 위치 종속성으로 인해 실패한 배포의 문제를 해결하려면 시간이 오래 걸릴 수 있습니다.Deployments that fail because of location dependencies can be time-consuming to troubleshoot. 이러한 이유 때문에 작성 주기에서 가능한 한 빨리 자동화된 테스트를 수행하는 것이 좋습니다.That’s why we recommend automated testing as early as possible in the authoring cycle. 궁극적으로 필요한 개발 시간과 리소스가 감소하고, 클라우드 일치 아티팩트의 가치가 더욱 증가할 것입니다.Ultimately, you'll need less development time and fewer resources, and your cloud-consistent artifacts will become even more valuable.

다음 이미지는 IDE(통합 개발 환경)를 사용하는 팀의 일반적인 개발 프로세스 예를 보여 줍니다.The following image shows a typical example of a development process for a team using an integrated development environment (IDE). 타임라인의 단계마다 다른 테스트 유형이 실행됩니다.At different stages in the timeline, different test types are executed. 여기서는 두 개발자가 동일한 솔루션에서 작업 중이지만, 이 시나리오는 단일 개발자 또는 대규모 팀에도 똑같이 적용됩니다.Here, two developers are working on the same solution, but this scenario applies equally to a single developer or a large team. 일반적으로 각 개발자가 중앙 리포지토리의 로컬 복사본을 만들어, 동일한 파일에서 작업하는 다른 사용자에게 영향을 주지 않고 로컬 복사본에서 작업할 수 있습니다.Each developer typically creates a local copy of a central repository, enabling each one to work on the local copy without impacting the others who may be working on the same files.

워크플로

테스트 및 자동화에 대한 다음 팁에 유의하세요.Consider the following tips for testing and automation:

  • 테스트 도구를 활용합니다.Do make use of testing tools. 예를 들어, Visual Studio Code 및 Visual Studio에는 템플릿의 유효성 검사에 도움이 되는 IntelliSense 및 기타 기능이 포함되어 있습니다.For example, Visual Studio Code and Visual Studio include IntelliSense and other features that can help you validate your templates.
  • 로컬 IDE에서 개발하는 동안 코드 품질을 개선하려면 단위 테스트 및 통합 테스트를 사용하여 정적 코드 분석을 수행합니다.To improve the code quality during development on the local IDE, perform static code analysis with unit tests and integration tests.
  • 초기 개발 중에 경험을 개선하려면 단위 테스트 및 통합 테스트에서 문제가 발견되었을 때 경고만 하고 테스트를 진행해야 합니다.For an even better experience during initial development, unit tests and integration tests should only warn when an issue is found and proceed with the tests. 이렇게 하면 처리할 문제를 확인하고 변경 순서의 우선 순위를 지정할 수 있습니다. 이를 TDD(테스트 기반 배포)라고도 합니다.That way, you can identify the issues to addressed and prioritize the order of the changes, also referred to as test-driven deployment (TDD).
  • 일부 테스트는 Azure Resource Manager에 연결하지 않고 수행할 수 있습니다.Be aware that some tests can be performed without being connected to Azure Resource Manager. 템플릿 배포 테스트와 같은 기타 테스트의 경우, 오프라인 상태에서 수행할 수 없는 특정 작업을 수행하려면 리소스 관리자가 필요합니다.Others, like testing template deployment, require Resource Manager to perform certain actions that cannot be performed offline.
  • 유효성 검사 API에 대한 배포 템플릿 테스트는 실제 배포와 다릅니다.Testing a deployment template against the validation API isn't equal to an actual deployment. 또한 로컬 파일에서 템플릿을 배포하는 경우에도 템플릿의 중첩된 템플릿에 대한 참조는 리소스 관리자가 직접 검색하고, VM 확장에서 참조되는 아티팩트는 배포된 VM 내에서 실행되는 VM 에이전트가 검색합니다.Also, even if you deploy a template from a local file, any references to nested templates in the template are retrieved by Resource Manager directly, and artifacts referenced by VM extensions are retrieved by the VM agent running inside the deployed VM.

다음 단계Next steps