デプロイを実行するようにコンテナーイメージを構成する

[アーティクル]
01/20/2025

Azure Deployment Environments (ADE) は、任意の IaC テンプレートフレームワークを使用して環境定義を構成できる機能拡張モデルをサポートしています。カスタムイメージを Azure Container Registry (ACR) や Docker Hub などのコンテナーレジストリに格納し、環境定義で参照して環境をデプロイできます。

この記事では、カスタム Bicep コンテナーイメージをビルドして ADE に環境定義をデプロイする方法について説明します。 Microsoft によって提供される標準イメージを使用する方法、または Bicep のコードとしてのインフラストラクチャ (IaC) フレームワークを使用してインフラストラクチャをプロビジョニングするようにカスタムイメージを構成する方法について説明します。

この記事では、Azure Deployment Environments (ADE) を使用してデプロイ環境を作成するためのカスタム Terraform コンテナーイメージをビルドする方法について説明します。 Terraform のコードとしてのインフラストラクチャ (IaC) フレームワークを使ってインフラストラクチャをプロビジョニングするようにカスタムイメージを構成する方法について説明します。

この記事では、ADE でのデプロイに Pulumi を利用する方法について説明します。 Pulumi によって提供される標準のイメージを使用する方法、または Pulumi のコードとしてのインフラストラクチャ (IaC) フレームワークを使用してインフラストラクチャをプロビジョニングするようにカスタムイメージを構成する方法について説明します。

前提条件

アクティブなサブスクリプションが含まれる Azure アカウント。無料でアカウントを作成できます。
Azure サブスクリプション内にセットアップされた Azure Deployment Environments。
- ADE を設定するには、「クイックスタート: Azure Deployment Environments を構成する」に従います。

ADE でコンテナーイメージを使用する

ADE でコンテナーイメージを使用するには、次のいずれかの方法を使用できます。

標準コンテナーイメージを使用する 単純なシナリオでは、ADE が提供する標準 ARM-Bicep コンテナーイメージを使用します。
カスタムコンテナーイメージを作成する より複雑なシナリオの場合、特定の要件を満たすカスタムコンテナーイメージを作成します。

標準コンテナーイメージを使用する

ADE では、追加の構成を必要とせずに、Azure Resource Manager (ARM) と Bicep をサポートします。テンプレートファイル (azuredeploy.json、environment.yaml など) をカタログに追加すると、デプロイ環境用の Azure リソースをデプロイする環境定義を作成できます。その後、ADE では標準の ARM-Bicep コンテナーイメージを使用してデプロイ環境を作成します。

environment.yaml ファイルの runner プロパティでは、使用するコンテナーイメージの場所を指定します。 Microsoft アーティファクトレジストリで公開されている標準イメージを使用するには、それぞれの識別子 runner を使用します。

次の例は、標準の ARM-Bicep コンテナーイメージを参照する runner を示しています。

    name: WebApp
    version: 1.0.0
    summary: Azure Web App Environment
    description: Deploys a web app in Azure without a datastore
    runner: Bicep
    templatePath: azuredeploy.json

標準の Bicep コンテナーイメージは、ADE 標準リポジトリの Runner-Images フォルダーにある ARM-Bicep イメージで確認できます。

ADE コンテナーイメージを使用して Azure リソースをデプロイする環境定義を作成する方法の詳細については、「環境定義を構成して追加する」を参照してください。

スクリプトを使用してカスタムコンテナーイメージを作成する

カスタムコンテナーイメージを作成すると、要件に合わせてデプロイをカスタマイズできます。カスタムイメージは、ADE 標準コンテナーイメージを基に作成することができます。

イメージのカスタマイズが完了したら、Microsoft が提供するプロセスを自動化するスクリプトを使用して、イメージをビルドし、コンテナーレジストリにプッシュできます。

カスタムイメージは、ADE 標準イメージをベースとして使用し、標準イメージにあらかじめインストールされている ADE CLI でビルドします。 ADE CLI について詳しくは、CLI カスタムランナーイメージリファレンスに関する記事をご覧ください。

この例では、ADE で作成されたイメージの 1 つを基にして、ADE のデプロイを利用して ADE CLI にアクセスする Docker イメージをビルドする方法について説明します。

ADE 用に構成されたイメージの作成は、次の手順に従って行います。

標準イメージを基にカスタムイメージを作成します。
必要なパッケージをインストールします。
操作シェルスクリプトを構成します。
ARM テンプレートまたは Bicep テンプレートをデプロイするための操作シェルスクリプトを作成します。

1.標準イメージを基にカスタムイメージを作成する

Microsoft アーティファクトレジストリでホストされている標準イメージを指す FROM ステートメントが含まれている DockerFile を作成します。

標準コアイメージを参照する FROM ステートメントの例を次に示します。

FROM mcr.microsoft.com/deployment-environments/runners/core:latest

このステートメントは、最も新しく公開されたコアイメージをプルして、それをカスタムイメージの基礎にします。

2. 必要なパッケージをインストールする

この手順では、Bicep など、イメージに必要なパッケージをインストールします。次の例に示すように、RUN ステートメントを使って、Azure CLI で Bicep パッケージをインストールできます。

RUN az bicep install

ADE 標準イメージは Azure CLI イメージに基づいており、ADE CLI と JQ のパッケージがプレインストールされています。詳しくは、Azure CLI と JQ パッケージに関するページをご覧ください。

イメージ内で必要なパッケージをさらにインストールするには、RUN ステートメントを使います。

3.操作シェルスクリプトを構成する

標準イメージ内では、操作名に基づいて操作が決定されて実行されます。現在サポートされている 2 つの操作名は、deploy と delete です。

この構造を利用するようにカスタムイメージを設定するには、Dockerfile のレベルで scripts という名前のフォルダー指定し、2 つのファイル deploy.sh と delete.sh を指定します。deploy シェルスクリプトは環境の作成時または再デプロイ時に実行され、delete シェルスクリプトは環境の削除時に実行されます。リポジトリ内のシェルスクリプトの例は、ARM-Bicep 用の Runner-Images フォルダーのイメージの下で確認できます。

これらのシェルスクリプトを確実に実行できるようにするには、Dockerfile に次の行を追加します。

COPY scripts/* /scripts/
RUN find /scripts/ -type f -iname "*.sh" -exec dos2unix '{}' '+'
RUN find /scripts/ -type f -iname "*.sh" -exec chmod +x {} \;

4.ARM テンプレートまたは Bicep テンプレートをデプロイするための操作シェルスクリプトを作成する

ADE を介して ARM または Bicep インフラストラクチャを正常にデプロイできるようにするには、次の操作を行う必要があります。

ADE パラメーターを ARM 許容パラメーターに変換する
リンクされたテンプレートがデプロイで使用されている場合は解決する
特権マネージド ID を使用してデプロイを実行する

コアイメージのエントリポイント中に、現在の環境に設定されているすべてのパラメーターが変数 $ADE_OPERATION_PARAMETERS の下に格納されます。それらを ARM 許容パラメーターに変換するには、JQ を使用して次のコマンドを実行します。

# format the parameters as arm parameters
deploymentParameters=$(echo "$ADE_OPERATION_PARAMETERS" | jq --compact-output '{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": (to_entries | if length == 0 then {} else (map( { (.key): { "value": .value } } ) | add) end) }' )

次に、ARM JSON ベースのテンプレート内で使用されるリンクされたテンプレートを解決するには、メインテンプレートファイルを逆コンパイルします。これによって、多くの Bicep モジュールに使用されているすべてのローカルインフラストラクチャファイルが解決されます。次に、メイン ARM テンプレートに入れ子になったテンプレートとして埋め込まれたリンク済みテンプレートを使用して、これらのモジュールを 1 つの ARM テンプレートにリビルドします。この手順は、デプロイ操作中にのみ必要です。メインテンプレートファイルは、コアイメージのエントリポイント中に $ADE_TEMPLATE_FILE セットを使用して指定できます。この変数は、再コンパイルされたテンプレートファイルで設定し直す必要があります。次の例を参照してください。

if [[ $ADE_TEMPLATE_FILE == *.json ]]; then

    hasRelativePath=$( cat $ADE_TEMPLATE_FILE | jq '[.. | objects | select(has("templateLink") and (.templateLink | has("relativePath")))] | any' )

    if [ "$hasRelativePath" = "true" ]; then
        echo "Resolving linked ARM templates"

        bicepTemplate="${ADE_TEMPLATE_FILE/.json/.bicep}"
        generatedTemplate="${ADE_TEMPLATE_FILE/.json/.generated.json}"

        az bicep decompile --file "$ADE_TEMPLATE_FILE"
        az bicep build --file "$bicepTemplate" --outfile "$generatedTemplate"

        # Correctly reassign ADE_TEMPLATE_FILE without the $ prefix during assignment
        ADE_TEMPLATE_FILE="$generatedTemplate"
    fi
fi

デプロイにおいて、サブスクリプション内のリソースのデプロイと削除を実行するために必要なアクセス許可を付与するには、ADE プロジェクト環境の種類に関連付けられている特権マネージド ID を使用します。特定のロールなど、デプロイを完了するために特別なアクセス許可が必要な場合は、それらのロールをプロジェクト環境の種類の ID に割り当てます。場合によっては、コンテナーに入る時点で直ちにマネージド ID を使用できないこともあるため、サインインは成功するまで再試行できます。

echo "Signing into Azure using MSI"
while true; do
    # managed identity isn't available immediately
    # we need to do retry after a short nap
    az login --identity --allow-no-subscriptions --only-show-errors --output none && {
        echo "Successfully signed into Azure"
        break
    } || sleep 5
done

ARM テンプレートまたは Bicep テンプレートのデプロイを開始するには、az deployment group create コマンドを実行します。コンテナー内でこのコマンドを実行する場合は、過去のデプロイをオーバーライドしないデプロイ名を選択し、--no-prompt true フラグと --only-show-errors フラグを使用して、次の例に示すように、警告やユーザー入力の待機中にデプロイが失敗したり、止まってしまったりしないようにします。

deploymentName=$(date +"%Y-%m-%d-%H%M%S")
az deployment group create --subscription $ADE_SUBSCRIPTION_ID \
    --resource-group "$ADE_RESOURCE_GROUP_NAME" \
    --name "$deploymentName" \
    --no-prompt true --no-wait \
    --template-file "$ADE_TEMPLATE_FILE" \
    --parameters "$deploymentParameters" \
    --only-show-errors

環境を削除するには、完全モードのデプロイを実行し、空の ARM テンプレートを指定します。これにより、次の例に示すように、指定した ADE リソースグループ内のすべてのリソースが削除されます。

deploymentName=$(date +"%Y-%m-%d-%H%M%S")
az deployment group create --resource-group "$ADE_RESOURCE_GROUP_NAME" \
    --name "$deploymentName" \
    --no-prompt true --no-wait --mode Complete \
    --only-show-errors \
    --template-file "$DIR/empty.json"

次のコマンドを実行して、プロビジョニングの状態と詳細を確認できます。プロビジョニングの詳細に基づいて追加のコンテキストを読み取り、提供するために、ADE ではいくつかの特殊な関数を使用します。それらは Runner-Images フォルダーにあります。単純な実装は次のようになります。

if [ $? -eq 0 ]; then # deployment successfully created
    while true; do

        sleep 1

        ProvisioningState=$(az deployment group show --resource-group "$ADE_RESOURCE_GROUP_NAME" --name "$deploymentName" --query "properties.provisioningState" -o tsv)
        ProvisioningDetails=$(az deployment operation group list --resource-group "$ADE_RESOURCE_GROUP_NAME" --name "$deploymentName")

        echo "$ProvisioningDetails"

        if [[ "CANCELED|FAILED|SUCCEEDED" == *"${ProvisioningState^^}"* ]]; then

            echo -e "\nDeployment $deploymentName: $ProvisioningState"

            if [[ "CANCELED|FAILED" == *"${ProvisioningState^^}"* ]]; then
                exit 11
            else
                break
            fi
        fi
    done
fi

最後に、デプロイの出力を表示し、それらを ADE に渡して Azure CLI 経由でアクセスできるようにするには、次のコマンドを実行します。

deploymentOutput=$(az deployment group show -g "$ADE_RESOURCE_GROUP_NAME" -n "$deploymentName" --query properties.outputs)
if [ -z "$deploymentOutput" ]; then
    deploymentOutput="{}"
fi
echo "{\"outputs\": $deploymentOutput}" > $ADE_OUTPUTS

スクリプトを使用してコンテナーイメージをビルドする

カスタムイメージを自分でビルドしてコンテナーレジストリにプッシュするのではなく、スクリプトを使用してビルドし、指定されたコンテナーレジストリにプッシュすることができます。

Microsoft では、カスタムイメージをビルドしてレジストリにプッシュするのに役立つクイックスタートスクリプトを提供しています。このスクリプトは、イメージをビルドし、リポジトリ ade とタグ latest を使用して指定された Azure Container Registry (ACR) にプッシュします。

スクリプトを使うには、次のことが必要です。

ADE 拡張性モデルをサポートするように Dockerfile と scripts フォルダーを作成します。
カスタムイメージのレジストリ名とディレクトリを指定します。
Azure CLI と Docker Desktop をインストールし、PATH 変数に含めます。
Docker Desktop を実行している。
指定したレジストリにプッシュするアクセス許可を持っています。

こちらのスクリプトを表示できます。

PowerShell で次のコマンドを使って、スクリプトを呼び出すことができます。

.\quickstart-image-build.ps1 -Registry '{YOUR_REGISTRY}' -Directory '{DIRECTORY_TO_YOUR_IMAGE}'

さらに、特定のリポジトリとタグ名にプッシュする場合は、次を実行できます。

.\quickstart-image.build.ps1 -Registry '{YOUR_REGISTRY}' -Directory '{DIRECTORY_TO_YOUR_IMAGE}' -Repository '{YOUR_REPOSITORY}' -Tag '{YOUR_TAG}'

カスタムコンテナーイメージを手動で作成する

イメージのカスタマイズが完了したら、イメージをビルドしてコンテナーレジストリに手動でプッシュできます。

ADE 用に構成されたイメージの作成は、次の手順に従って行います。

標準イメージを基にカスタムイメージを作成します。
必要なパッケージをインストールします。
操作シェルスクリプトを構成します。
ARM テンプレートまたは Bicep テンプレートをデプロイするための操作シェルスクリプトを作成します。

1.標準イメージを基にカスタムイメージを作成する

Microsoft アーティファクトレジストリでホストされている標準イメージを指す FROM ステートメントが含まれている DockerFile を作成します。

標準コアイメージを参照する FROM ステートメントの例を次に示します。

FROM mcr.microsoft.com/deployment-environments/runners/core:latest

このステートメントは、最も新しく公開されたコアイメージをプルして、それをカスタムイメージの基礎にします。

2. 必要なパッケージをインストールする

RUN az bicep install

イメージ内で必要なパッケージをさらにインストールするには、RUN ステートメントを使います。

3.操作シェルスクリプトを構成する

標準イメージ内では、操作名に基づいて操作が決定されて実行されます。現在サポートされている 2 つの操作名は、deploy と delete です。

これらのシェルスクリプトを確実に実行できるようにするには、Dockerfile に次の行を追加します。

COPY scripts/* /scripts/
RUN find /scripts/ -type f -iname "*.sh" -exec dos2unix '{}' '+'
RUN find /scripts/ -type f -iname "*.sh" -exec chmod +x {} \;

4.ARM テンプレートまたは Bicep テンプレートをデプロイするための操作シェルスクリプトを作成する

ADE を介して ARM または Bicep インフラストラクチャを正常にデプロイできるようにするには、次の操作を行う必要があります。

ADE パラメーターを ARM 許容パラメーターに変換する
リンクされたテンプレートがデプロイで使用されている場合は解決する
特権マネージド ID を使用してデプロイを実行する

# format the parameters as arm parameters
deploymentParameters=$(echo "$ADE_OPERATION_PARAMETERS" | jq --compact-output '{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": (to_entries | if length == 0 then {} else (map( { (.key): { "value": .value } } ) | add) end) }' )

if [[ $ADE_TEMPLATE_FILE == *.json ]]; then

    hasRelativePath=$( cat $ADE_TEMPLATE_FILE | jq '[.. | objects | select(has("templateLink") and (.templateLink | has("relativePath")))] | any' )

    if [ "$hasRelativePath" = "true" ]; then
        echo "Resolving linked ARM templates"

        bicepTemplate="${ADE_TEMPLATE_FILE/.json/.bicep}"
        generatedTemplate="${ADE_TEMPLATE_FILE/.json/.generated.json}"

        az bicep decompile --file "$ADE_TEMPLATE_FILE"
        az bicep build --file "$bicepTemplate" --outfile "$generatedTemplate"

        # Correctly reassign ADE_TEMPLATE_FILE without the $ prefix during assignment
        ADE_TEMPLATE_FILE="$generatedTemplate"
    fi
fi

echo "Signing into Azure using MSI"
while true; do
    # managed identity isn't available immediately
    # we need to do retry after a short nap
    az login --identity --allow-no-subscriptions --only-show-errors --output none && {
        echo "Successfully signed into Azure"
        break
    } || sleep 5
done

deploymentName=$(date +"%Y-%m-%d-%H%M%S")
az deployment group create --subscription $ADE_SUBSCRIPTION_ID \
    --resource-group "$ADE_RESOURCE_GROUP_NAME" \
    --name "$deploymentName" \
    --no-prompt true --no-wait \
    --template-file "$ADE_TEMPLATE_FILE" \
    --parameters "$deploymentParameters" \
    --only-show-errors

deploymentName=$(date +"%Y-%m-%d-%H%M%S")
az deployment group create --resource-group "$ADE_RESOURCE_GROUP_NAME" \
    --name "$deploymentName" \
    --no-prompt true --no-wait --mode Complete \
    --only-show-errors \
    --template-file "$DIR/empty.json"

if [ $? -eq 0 ]; then # deployment successfully created
    while true; do

        sleep 1

        ProvisioningState=$(az deployment group show --resource-group "$ADE_RESOURCE_GROUP_NAME" --name "$deploymentName" --query "properties.provisioningState" -o tsv)
        ProvisioningDetails=$(az deployment operation group list --resource-group "$ADE_RESOURCE_GROUP_NAME" --name "$deploymentName")

        echo "$ProvisioningDetails"

        if [[ "CANCELED|FAILED|SUCCEEDED" == *"${ProvisioningState^^}"* ]]; then

            echo -e "\nDeployment $deploymentName: $ProvisioningState"

            if [[ "CANCELED|FAILED" == *"${ProvisioningState^^}"* ]]; then
                exit 11
            else
                break
            fi
        fi
    done
fi

最後に、デプロイの出力を表示し、それらを ADE に渡して Azure CLI 経由でアクセスできるようにするには、次のコマンドを実行します。

deploymentOutput=$(az deployment group show -g "$ADE_RESOURCE_GROUP_NAME" -n "$deploymentName" --query properties.outputs)
if [ -z "$deploymentOutput" ]; then
    deploymentOutput="{}"
fi
echo "{\"outputs\": $deploymentOutput}" > $ADE_OUTPUTS

カスタムイメージをビルドする

イメージをビルドするには、Docker CLI を使用することができます。お使いのコンピューターに Docker エンジンがインストールされていることを確認します。その後、Dockerfile のディレクトリに移動して、次のコマンドを実行します。

docker build . -t {YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}

たとえば、customImage という名前のレジストリ内のリポジトリにイメージを保存し、1.0.0 のタグバージョンを使ってアップロードする場合は、次のように実行します。

docker build . -t {YOUR_REGISTRY}.azurecr.io/customImage:1.0.0

ADE でコンテナーイメージを使用する

ADE でコンテナーイメージを使用するには、次のいずれかの方法を使用できます。

GitHub ワークフローを利用してコンテナーイメージを作成する: まず、"Leveraging ADE's Extensibility Model With Terraform" リポジトリから公開されている GitHub ワークフローを使用できます。
カスタムコンテナーイメージを作成する: 必要なすべてのソフトウェア、設定、構成を使用してカスタマイズされた Terraform 固有のイメージを作成するワークフローを作成できます。

GitHub ワークフローを使用してコンテナーイメージを作成する

イメージのカスタマイズが完了したら、イメージをビルドし、それをコンテナーレジストリにプッシュする必要があります。

イメージをビルドしてプッシュすることも、Microsoft が提供するスクリプトを使用してプロセスを自動化することもできます。

公開された GitHub アクションは、イメージをビルドして Azure Container Registry (ACR) にプッシュするのに役立ちます。 ADE の環境定義内で提供された ACR イメージリンクを参照して、指定されたイメージを使用して環境をデプロイまたは削除できます。

ADE 用に構成されたイメージの作成は、次の手順に従って行います。

GitHub ワークフローを基にカスタムイメージを作成します。
必要なパッケージをインストールします。
操作シェルスクリプトを構成します。
Terraform CLI を使用する操作シェルスクリプトを作成します。

1.GitHub ワークフローを基にカスタムイメージを作成する

公開済みリポジトリを使用して GitHub ワークフローを利用します。リポジトリには、Terraform IaC テンプレートを使用して環境をデプロイおよび削除するための Dockerfile やシェルスクリプトなど、ADE 互換のサンプルイメージコンポーネントが含まれています。このサンプルコードは、独自のコンテナーイメージを作成するのに役立ちます。

2.必要なパッケージをインストールする この手順では、Terraform など、イメージに必要なパッケージをインストールします。 Terraform CLI を実行可能な場所にインストールして、デプロイと削除のスクリプトで使用できるようにできます。

Terraform CLI のバージョン 1.7.5 をインストールするプロセスの例を次に示します。

RUN wget -O terraform.zip https://releases.hashicorp.com/terraform/1.7.5/terraform_1.7.5_linux_amd64.zip
RUN unzip terraform.zip && rm terraform.zip
RUN mv terraform /usr/bin/terraform

ヒント

Hashicorp リリースから任意のバージョンの Terraform CLI のダウンロード URL を取得できます。

3.操作シェルスクリプトを構成する

標準イメージ内では、操作名に基づいて操作が決定されて実行されます。現在サポートされている 2 つの操作名は、deploy と delete です。

この構造を利用するようにカスタムイメージを設定するには、Dockerfile のレベルで scripts という名前のフォルダー指定し、2 つのファイル deploy.sh と delete.sh を指定します。deploy シェルスクリプトは環境の作成時または再デプロイ時に実行され、delete シェルスクリプトは環境の削除時に実行されます。シェルスクリプトの例は、Terraform用の scripts フォルダーのリポジトリ内にあります。

これらのシェルスクリプトを確実に実行できるようにするには、Dockerfile に次の行を追加します。

COPY scripts/* /scripts/
RUN find /scripts/ -type f -iname "*.sh" -exec dos2unix '{}' '+'
RUN find /scripts/ -type f -iname "*.sh" -exec chmod +x {} \;

4.Terraform CLI を使用する操作シェルスクリプトを作成する

Terraform を使ってインフラストラクチャをデプロイするには、次の 3 つのステップがあります。

terraform init - 作業ディレクトリ内でアクションを実行するように Terraform CLI を初期化します
terraform plan - 受け取った Terraform インフラストラクチャファイルと変数および既存の状態ファイルに基づいてプランを作成し、.tf ファイルで指定されているインフラストラクチャを作成または更新するために必要な手順を作成します
terraform apply - Azure でプランを適用して、新しいインフラストラクチャを作成するか、既存のものを更新します

コアイメージのエントリポイントの間に、既存の状態ファイルが、コンテナーと、環境変数 $ADE_STORAGE に保存されているディレクトリにプルされます。さらに、変数 $ADE_OPERATION_PARAMETERS に格納されている現在の環境に対してパラメータが設定されます。既存の状態ファイルにアクセスし、.tfvars.json ファイル内の変数を設定するには、次のコマンドを実行します。

set -e #set script to exit on error
EnvironmentState="$ADE_STORAGE/environment.tfstate"
EnvironmentPlan="/environment.tfplan"
EnvironmentVars="/environment.tfvars.json"

echo "$ADE_OPERATION_PARAMETERS" > $EnvironmentVars

さらに、ADE の特権によってサブスクリプション内にインフラストラクチャをデプロイするには、使用するスクリプトの中で、Terraform AzureRM プロバイダーを利用してインフラストラクチャをプロビジョニングするとき、マネージドサービス ID (MSI) を使用する必要があります。特定のロールなど、デプロイを完了するためにデプロイで特別なアクセス許可が必要な場合は、環境のデプロイに使われているプロジェクト環境の種類の ID に、それらのアクセス許可を割り当てます。関連する環境変数 (コアイメージのエントリポイント内のクライアント、テナント、サブスクリプションの ID など) は ADE によって設定されるため、プロバイダーで確実に ADE MSI が使われるように以下のコマンドを実行します。

export ARM_USE_MSI=true
export ARM_CLIENT_ID=$ADE_CLIENT_ID
export ARM_TENANT_ID=$ADE_TENANT_ID
export ARM_SUBSCRIPTION_ID=$ADE_SUBSCRIPTION_ID

テンプレート内で参照する他の変数が環境のパラメータで指定されていない場合は、プレフィックス TF_VAR を使って環境変数を設定します。指定の ADE 環境変数の一覧には、Azure デプロイメント環境 CLI 変数リファレンスが提供されます。それらのコマンドの例を次に示します。

export TF_VAR_resource_group_name=$ADE_RESOURCE_GROUP_NAME
export TF_VAR_ade_env_name=$ADE_ENVIRONMENT_NAME
export TF_VAR_env_name=$ADE_ENVIRONMENT_NAME
export TF_VAR_ade_subscription=$ADE_SUBSCRIPTION_ID
export TF_VAR_ade_location=$ADE_ENVIRONMENT_LOCATION
export TF_VAR_ade_environment_type=$ADE_ENVIRONMENT_TYPE

これで、前に示した手順を実行して Terraform CLI を初期化し、インフラストラクチャをプロビジョニングするプランを生成して、デプロイスクリプトの間にプランを適用できます。

terraform init
terraform plan -no-color -compact-warnings -refresh=true -lock=true -state=$EnvironmentState -out=$EnvironmentPlan -var-file="$EnvironmentVars"
terraform apply -no-color -compact-warnings -auto-approve -lock=true -state=$EnvironmentState $EnvironmentPlan

削除スクリプトの間に、destroy フラグをプラン生成に追加して既存のリソースを削除できます。次にその例を示します。

terraform init
terraform plan -no-color -compact-warnings -destroy -refresh=true -lock=true -state=$EnvironmentState -out=$EnvironmentPlan -var-file="$EnvironmentVars"
terraform apply -no-color -compact-warnings -auto-approve -lock=true -state=$EnvironmentState $EnvironmentPlan

最後に、デプロイの出力をアップロードして、Azure CLI で環境にアクセスするときにアクセスできるようにするには、Terraform からの出力オブジェクトを、JQ パッケージを使って ADE で指定されている形式に変換します。次の例で示すように、$ADE_OUTPUTS 環境変数に値を設定します。

tfOutputs=$(terraform output -state=$EnvironmentState -json)
# Convert Terraform output format to ADE format.
tfOutputs=$(jq 'walk(if type == "object" then 
            if .type == "bool" then .type = "boolean" 
            elif .type == "list" then .type = "array" 
            elif .type == "map" then .type = "object" 
            elif .type == "set" then .type = "array" 
            elif (.type | type) == "array" then 
                if .type[0] == "tuple" then .type = "array" 
                elif .type[0] == "object" then .type = "object" 
                elif .type[0] == "set" then .type = "array" 
                else . 
                end 
            else . 
            end 
        else . 
        end)' <<< "$tfOutputs")

echo "{\"outputs\": $tfOutputs}" > $ADE_OUTPUTS

カスタムイメージをビルドする

docker build . -t {YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}

docker build . -t {YOUR_REGISTRY}.azurecr.io/customImage:1.0.0

Pulumi から提供される標準コンテナーイメージを使用する

Pulumi チームは、作業を開始するための事前構築済みイメージを提供しています。これは、Runner-Image フォルダー内にあります。このイメージは、Pulumi Docker Hub で pulumi/azure-deployment-environments として一般提供されているため、ADE 環境定義から直接使用できます。

事前構築済みイメージを利用するサンプルの environment.yaml ファイルを次に示します。

name: SampleDefinition
version: 1.0.0
summary: First Pulumi-Enabled Environment
description: Deploys a Storage Account with Pulumi
runner: pulumi/azure-deployment-environments:0.1.0
templatePath: Pulumi.yaml

Environments フォルダーには、いくつかのサンプル環境定義があります。

カスタムイメージを作成する

カスタムコンテナーイメージを作成すると、要件に合わせてデプロイをカスタマイズできます。 Pulumi 標準イメージを基にカスタムイメージを作成し、要件に合わせてカスタマイズできます。イメージのカスタマイズが完了したら、イメージをビルドし、それをコンテナーレジストリにプッシュする必要があります。

ADE 用に構成されたイメージの作成は、次の手順に従って行います。

標準イメージを基にカスタムイメージを作成します。
必要なパッケージをインストールします。
操作シェルスクリプトを構成します。
Pulumi CLI を使用する操作シェルスクリプトを作成します。

1.標準イメージを基にカスタムイメージを作成する

Microsoft アーティファクトレジストリでホストされている標準イメージを指す FROM ステートメントが含まれている DockerFile を作成します。

標準コアイメージを参照する FROM ステートメントの例を次に示します。

FROM mcr.microsoft.com/deployment-environments/runners/core:latest

このステートメントは、最も新しく公開されたコアイメージをプルして、それをカスタムイメージの基礎にします。

2. 必要なパッケージをインストールする

Pulumi CLI を実行可能ファイルの場所にインストールすると、デプロイおよび削除シナリオで使用することができます。

このプロセスの例を次に示します。この例では、最新版の Pulumi CLI をインストールします。

RUN apk add curl
RUN curl -fsSL https://get.pulumi.com | sh
ENV PATH="${PATH}:/root/.pulumi/bin"

Pulumi プログラムに使用するプログラミング言語によっては、1 つ以上の対応するランタイムをインストールすることが必要な場合があります。 Python ランタイムは、基本イメージで既に使用できます。

Node.js と TypeScript をインストールする例を次に示します。

# install node.js, npm, and typescript
RUN apk add nodejs npm
RUN npm install typescript -g

イメージ内で必要なパッケージをさらにインストールするには、RUN ステートメントを使います。

Pulumi を使用してインフラストラクチャをデプロイするには、次の 4 つのステップがあります。

pulumi login - ローカルファイルシステムまたは Pulumi Cloud 内の状態ストレージに接続する
pulumi stack select - 特定の環境に使用するスタックを作成または選択する
pulumi config set - デプロイパラメーターを Pulumi 構成値として渡す
pulumi up - デプロイを実行して、Azure で新しいインフラストラクチャを作成するか、既存のインフラストラクチャを更新する

コアイメージのエントリポイントでは、既存のローカル状態ファイルが、コンテナーと、環境変数 $ADE_STORAGE に保存されているディレクトリにプルされます。既存の状態ファイルにアクセスするには、次のコマンドを実行します。

mkdir -p $ADE_STORAGE
export PULUMI_CONFIG_PASSPHRASE=
pulumi login file://$ADE_STORAGE

代わりに Pulumi Cloud にサインインするには、Pulumi アクセストークンを環境変数として設定し、次のコマンドを実行します。

export PULUMI_ACCESS_TOKEN=YOUR_PULUMI_ACCESS_TOKEN
pulumi login

現在の環境に設定されているすべてのパラメーターは、変数 $ADE_OPERATION_PARAMETERS に格納されます。さらに、選択した Azure リージョンとリソースグループ名がそれぞれ、ADE_ENVIRONMENT_LOCATION と ADE_RESOURCE_GROUP_NAME に渡されます。 Pulumi スタック構成を設定するには、次のコマンドを実行します。

# Create or select the stack for the current environment
pulumi stack select $ADE_ENVIRONMENT_NAME --create

# Store configuration values in durable storage
export PULUMI_CONFIG_FILE=$ADE_STORAGE/Pulumi.$ADE_ENVIRONMENT_NAME.yaml

# Set the Pulumi stack config
pulumi config set azure-native:location $ADE_ENVIRONMENT_LOCATION --config-file $PULUMI_CONFIG_FILE
pulumi config set resource-group-name $ADE_RESOURCE_GROUP_NAME --config-file $PULUMI_CONFIG_FILE
echo "$ADE_OPERATION_PARAMETERS" | jq -r 'to_entries|.[]|[.key, .value] | @tsv' |
  while IFS=$'\t' read -r key value; do
    pulumi config set $key $value --config-file $PULUMI_CONFIG_FILE
  done

さらに、ADE の特権を利用してサブスクリプション内にインフラストラクチャをデプロイするには、Pulumi Azure Native または Azure Classic プロバイダーを使用してインフラストラクチャをプロビジョニングするときに、スクリプトで ADE マネージドサービス ID (MSI) を使用する必要があります。特定のロールなど、デプロイを完了するためにデプロイで特別なアクセス許可が必要な場合は、環境のデプロイに使われているプロジェクト環境の種類の ID に、それらのアクセス許可を割り当てます。 ADE により、コアイメージのエントリポイント内のクライアント、テナント、サブスクリプションの ID など、関連する環境変数が設定されるため、次のコマンドを実行して、プロバイダーで ADE の MSI が使用されていることを確認します。

export ARM_USE_MSI=true
export ARM_CLIENT_ID=$ADE_CLIENT_ID
export ARM_TENANT_ID=$ADE_TENANT_ID
export ARM_SUBSCRIPTION_ID=$ADE_SUBSCRIPTION_ID

これで、pulumi up コマンドを使用して、デプロイを実行できるようになりました。

pulumi up --refresh --yes --config-file $PULUMI_CONFIG_FILE

削除スクリプトでは、次の例に示すように、代わりに destroy コマンドを実行できます。

pulumi destroy --refresh --yes --config-file $PULUMI_CONFIG_FILE

最後に、デプロイの出力をアップロードして、Azure CLI で環境にアクセスするときにアクセスできるようにするには、JQ パッケージを使用して、出力オブジェクトを Pulumi から、ADE で指定されている形式に変換します。次の例で示すように、$ADE_OUTPUTS 環境変数に値を設定します。

stackout=$(pulumi stack output --json | jq -r 'to_entries|.[]|{(.key): {type: "string", value: (.value)}}')
echo "{\"outputs\": ${stackout:-{\}}}" > $ADE_OUTPUTS

カスタムイメージをビルドする

docker build . -t {YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}

docker build . -t {YOUR_REGISTRY}.azurecr.io/customImage:1.0.0

カスタムイメージを ADE で利用できるようにする

カスタムイメージを使用するには、それらをコンテナーレジストリに格納する必要があります。パブリックコンテナーレジストリまたはプライベートコンテナーレジストリを使用できます。 Azure Container Registry (ACR) は ADE と緊密に統合されており、パブリック匿名プルアクセスを許可することなくイメージを公開できるため、ACR を強くお勧めします。カスタムコンテナーイメージをビルドし、それをコンテナーレジストリにプッシュして、ADE で使用できるようにする必要があります。

イメージを別のコンテナーレジストリ (たとえば Docker Hub) に格納することもできますが、その場合はパブリックアクセスできることが必要になります。

注意事項

匿名 (認証されていない) プルアクセスが可能なレジストリにコンテナーイメージを格納すると、パブリックアクセス可能になります。イメージに機密情報が含まれている場合は、このようにしないでください。代わりに、匿名プルアクセスを無効化した Azure Container Registry (ACR) に格納します。

ACR に格納されているカスタムイメージを使用するには、そのイメージにアクセスするための適切なアクセス許可が ADE に付与されていることを確認する必要があります。 ACR インスタンスを作成すると、既定でセキュリティで保護され、認証されたユーザーのみがアクセスできます。

Pulumi を使用して、Azure Container Registry を作成し、それにイメージを発行できます。必要なすべてのリソースを Azure アカウントに作成する自己完結型の Pulumi プロジェクトについては、Provisioning/custom-image の例を参照してください。

適切なタブを選択し、各アプローチの詳細を確認します。

プライベートレジストリ
パブリックレジストリ

セキュリティで保護されたアクセスでプライベートレジストリを使用する

既定では、Azure Container Registry からコンテンツをプルまたはプッシュするためのアクセスは、認証済みユーザーのみが使用できます。特定のネットワークからのアクセスを制限し、特定のロールを割り当てることで、ACR へのアクセスのセキュリティをさらに強化できます。

Azure CLI、Azure portal、PowerShell コマンドなどを使って ACR のインスタンスを作成するには、いずれかのクイックスタートのようにします。

ネットワークアクセスを制限する

ACR へのネットワークアクセスをセキュリティで保護するために、自身のネットワークへのアクセスを制限することで、パブリックネットワークアクセスを完全に無効化できます。ネットワークアクセスを制限する場合は、ファイアウォールの例外 "信頼された Microsoft サービスによるこのコンテナーレジストリへのアクセスを許可" を有効化する必要があります。

パブリックネットワークからのアクセスを無効にするには:

ACR インスタンスを作成するか、既存のインスタンスを使用します。
Azure portal で、構成する ACR に移動します。
左側のメニューの [設定] で、[ネットワーク] を選択します。
[ネットワーク] ページの [パブリックアクセス] タブの [パブリックネットワークアクセス] で、[無効] を選択します。
[ファイアウォールの例外] で、[信頼された Microsoft サービスによるこのコンテナーレジストリへのアクセスを許可] が選択されていることを確認してから [保存] を選択します。

AcrPull ロールを割り当てる

コンテナーイメージを使用して環境を作成するには、ADE インフラストラクチャを使用しますが、これにはプロジェクトと環境の種類も含まれます。各プロジェクトには 1 つ以上のプロジェクト環境の種類があり、デプロイされる環境を定義するコンテナーイメージへの読み取りアクセスがこれらのプロジェクト環境の種類に付与されている必要があります。 ACR 内のイメージに安全にアクセスできるように、AcrPull ロールをプロジェクト環境の種類のそれぞれに割り当てます。

プロジェクト環境の種類に AcrPull ロールを割り当てるには:

Azure portal で、構成する ACR に移動します。
左側のメニューで、[アクセス制御 (IAM)] を選択します。
[追加]>[ロール割り当ての追加] の順に選択します。

次のロールを割り当てます。詳細な手順については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。

設定	値
Role	[AcrPull] を選択します。
アクセスの割り当て先	ユーザー、グループ、またはサービスプリンシパルを選択します。
メンバー	コンテナー内のイメージにアクセスする必要があるプロジェクト環境の種類の名前を入力します。

プロジェクト環境の種類は、次の例のように表示されます。

[メンバーの選択] ペインのスクリーンショット。プロジェクト環境の種類の一覧が表示され、名前の一部が強調表示されています。

この構成では、ADE はプロジェクト環境の種類のマネージド ID を使用します。これはシステム割り当てのことも、ユーザー割り当てのこともあります。

ヒント

このロールの割り当ては、すべてのプロジェクト環境の種類について行う必要があります。これは、Azure CLI を使用して自動化できます。

イメージをレジストリにプッシュする準備ができたら、次のコマンドを実行します。

docker push {YOUR_REGISTRY}.azurecr.io/{YOUR_IMAGE_LOCATION}:{YOUR_TAG}

匿名プルでパブリックレジストリを使用する

レジストリで匿名イメージプルを有効に設定するには、Azure CLI で次のコマンドを実行します。

az login
az acr login -n {YOUR_REGISTRY}
az acr update -n {YOUR_REGISTRY} --public-network-enabled true
az acr update -n {YOUR_REGISTRY} --anonymous-pull-enabled true

イメージをレジストリにプッシュする準備ができたら、次のコマンドを実行します。

docker push {YOUR_REGISTRY}.azurecr.io/{YOUR_IMAGE_LOCATION}:{YOUR_TAG}

環境定義にイメージを接続する

デプロイ内のカスタムイメージを使用する環境定義を作成するときは、マニフェストファイル (environment.yaml または manifest.yaml) で runner プロパティを編集します。

runner: "{YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}"

ADE コンテナーイメージを使用して環境定義を作成して Azure リソースをデプロイする方法の詳細については、「環境定義の追加と構成」を参照してください。

Pulumi の azure-deployment-environments レジストリ

次の方法で共有

デプロイを実行するようにコンテナーイメージを構成する

前提条件

ADE でコンテナーイメージを使用する

標準コンテナーイメージを使用する

カスタムコンテナーイメージを作成する

スクリプトを使用してカスタムコンテナーイメージを作成する

スクリプトを使用してコンテナーイメージをビルドする

カスタムコンテナーイメージを手動で作成する

カスタムイメージをビルドする

ADE でコンテナーイメージを使用する

GitHub ワークフローを使用してコンテナーイメージを作成する

カスタムイメージをビルドする

Pulumi から提供される標準コンテナーイメージを使用する

カスタムイメージを作成する

カスタムイメージをビルドする

カスタムイメージを ADE で利用できるようにする

セキュリティで保護されたアクセスでプライベートレジストリを使用する

ネットワークアクセスを制限する

AcrPull ロールを割り当てる

匿名プルでパブリックレジストリを使用する

環境定義にイメージを接続する

フィードバック

その他のリソース

次の方法で共有

デプロイを実行するようにコンテナー イメージを構成する

前提条件

ADE でコンテナー イメージを使用する

標準コンテナー イメージを使用する

カスタム コンテナー イメージを作成する

スクリプトを使用してカスタム コンテナー イメージを作成する

スクリプトを使用してコンテナー イメージをビルドする

ADE でコンテナー イメージを使用する

GitHub ワークフローを使用してコンテナー イメージを作成する

カスタム イメージをビルドする

Pulumi から提供される標準コンテナー イメージを使用する

カスタム イメージを作成する

カスタム イメージをビルドする

カスタム イメージを ADE で利用できるようにする

セキュリティで保護されたアクセスでプライベート レジストリを使用する

ネットワーク アクセスを制限する

AcrPull ロールを割り当てる

環境定義にイメージを接続する

関連するコンテンツ

フィードバック

その他のリソース

デプロイを実行するようにコンテナーイメージを構成する

ADE でコンテナーイメージを使用する

標準コンテナーイメージを使用する

カスタムコンテナーイメージを作成する

スクリプトを使用してカスタムコンテナーイメージを作成する

スクリプトを使用してコンテナーイメージをビルドする

ADE でコンテナーイメージを使用する

GitHub ワークフローを使用してコンテナーイメージを作成する

カスタムイメージをビルドする

Pulumi から提供される標準コンテナーイメージを使用する

カスタムイメージを作成する

カスタムイメージをビルドする

カスタムイメージを ADE で利用できるようにする

セキュリティで保護されたアクセスでプライベートレジストリを使用する

ネットワークアクセスを制限する