クラウドの一貫性のための 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 Germany、Azure Government、Azure China (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 Stack。Azure 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 Resource Manager では、Azure クラウド プラットフォームで利用可能なすべての種類のリソースを展開して構成できます。Any type of resource that is available on the Azure cloud platform can be deployed and configured with Azure Resource Manager. 1 つのテンプレートを使って、完全なアプリケーションを展開して構成し、最終的な運用状態にすることができます。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 Stack では、Azure Resource Manager に導入された新しいテンプレート関数をすぐに利用することはできません。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-functions の複製を作成します。Make 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 コマンドレットを実行します。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. リンクされたテンプレート (入れ子になったテンプレートとも呼ばれます) は、Resource Manager によって実行時に取得されます。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. 展開を実行するには、メイン テンプレートまたはマスター テンプレートと呼ばれる 1 つのテンプレートを指定します。To execute a deployment, you specify a single template known as the main or master template. そこでは、仮想ネットワーク、VM、Web アプリなど、展開するリソースが指定されています。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. または、入れ子になったテンプレートを BLOB ストレージ コンテナーに格納することもでき、Azure Resource Manager はそこからテンプレートを取得できます。Alternatively, you can store nested templates in a blob storage container, from which Azure Resource Manager can retrieve them.

各クラウド上の BLOB ストレージは異なるエンドポイントの完全修飾ドメイン名 (FQDN) を使用するので、リンクされたテンプレートの場所を 2 つのパラメーターで指定してテンプレートを構成します。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 はすべての展開関連アイテムを含む 1 つの場所を示すために使用されています。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. sasToken に対する入力としては _artifactsLocationSasToken が使用されます。The _artifactsLocationSasToken is used as input for the sasToken. パブリック GitHub リポジトリのような _artifactsLocation がセキュリティで保護されていないシナリオでは、既定値を空の文字列にする必要があります。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 は入れ子になったテンプレートを実行時に取得します。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. 各リソース プロバイダーは、共通のコントラクトによって定義されている API を Azure Resource Manager に提供し、すべてのリソース プロバイダーで一貫性があり統合されたオーサリング エクスペリエンスを可能にします。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 コマンドレットを使って、使用可能なリソース プロバイダーを確認することもできます。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 コマンドレットを使うこともできます。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 環境にテンプレートを展開できる保証はありません。なぜなら、他の 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.

異なるリージョンに対応するには、既定値を持つ入力パラメーター location をテンプレートに追加します。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 内のオブジェクトの location キーを参照することにより、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.

このため、Resource Manager ではテンプレートに 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 に共通するリソースの種類ごとの 1 つの 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 バージョンを使用できることが保証されるので、特定の場所で使用可能な apiVersion を手動で確認する必要はありません。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 か月以上期限が切れている場合、準拠していないものと見なされ、環境を更新する必要があります。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.

次の 2 つの例は、リソースを作成するときに明示的に指定する必要がある共通のエンドポイント名前空間です。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. ベスト プラクティスは、参照テンプレート関数を使ってエンドポイントを動的に取得することです。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 ストレージ アカウントは、クラウドによって異なる FQDN になります。A blob storage account named mystorageaccount1 results in different FQDNs depending on the cloud:

  • mystorageaccount1.blob.core.windows.net: グローバル Azure クラウドで作成されたとき。mystorageaccount1.blob.core.windows.net when created on the global Azure cloud.
  • mystorageaccount1.blob.core.chinacloudapi.cn: Azure China クラウドで作成されたとき。mystorageaccount1.blob.core.chinacloudapi.cn when created in the Azure China cloud.

次の参照テンプレート関数は、ストレージ リソース プロバイダーからエンドポイントの名前空間を取得します。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 イメージのパブリッシャー、オファー、および 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

Azure PowerShell コマンドレット Get-AzureRmVMImagePublisher を使用し、-Location パラメーターで目的の場所を指定して、同じ一覧を取得できます。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.

これらの VM イメージを Azure Stack で使用できるようにする場合は、使用可能なすべてのストレージが消費されます。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 テンプレートでパブリッシャー、オファー、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 を導入するときは、通常、最初に Azure クラウド内のリージョンの小さなサブセットでその VM サイズを利用できるようにします。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 を Standard ストレージから Premium ストレージに変換できます。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.

VM 拡張機能が Azure Stack で使用できることを確認するVerify that VM extensions are available in Azure Stack

クラウドの一貫性のためのもう 1 つの考慮事項は、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 コマンドレットを実行し、-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 拡張機能はファースト パーティ Resource Manager リソースであるため、独自の 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 バージョンの一覧を取得するには、次に示すように、Microsoft.Compute リソース プロバイダーで Get-AzureRmResourceProvider コマンドレットを使います。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 バージョンを取得するには、前と同じコマンドレットを使用しますが、次に示すように、仮想マシン スケール セットのリソースの種類を指定します。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 コマンドレットを使います。To retrieve a list of the available versions for a specific VM extension, use the Get-AzureRmVMExtensionImage cmdlet. 次の例では、PowerShell DSC (Desired State Configuration) VM 拡張機能で使用可能なバージョンを myLocation から取得しています。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. 一般的な方法は、他の場所を対象にする前に、1 つのクラウドに対してテンプレートを開発してテストすることです。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. ここでは 2 人の開発者が同じソリューションで作業していますが、このシナリオは単独開発者や大規模なチームにも等しく適用されます。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. テンプレート展開テストなど、他のテストには、オフラインで実行できない特定のアクションを実行するために 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. また、ローカル ファイルからテンプレートを展開する場合でも、テンプレート内の入れ子になったテンプレートへの参照は Resource Manager によって直接取得され、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