次の方法で共有


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

この記事では、カスタム コンテナー イメージを構築し、Azure Deployment Environments (ADE) に環境定義をデプロイする方法を説明します。

環境定義は、少なくとも 2 つのファイル、すなわち、テンプレート ファイル (例: azuredeploy.json) とマニフェスト ファイル (environment.yaml という名前) で構成されます。 ADE は、コンテナーを使用して環境定義をデプロイし、Azure Resource Manager (ARM) と Bicep IaC のフレームワークをネイティブにサポートします。

ADE 機能拡張モデルにより、カスタム コンテナー イメージを作成して環境定義で使用することができます。 拡張性モデルを使うと、独自のカスタム コンテナー イメージを作成して、Azure Container Registry (ACR) や Docker Hub のようなコンテナー レジストリにそれを格納できます。 その後、環境定義でこれらのイメージを参照して、環境をデプロイできます。

ADE チームからは作業を始めるのに適したイメージが選択されて提供されており、それにはコア イメージや Azure Resource Manager (ARM)/Bicep イメージが含まれます。 これらのサンプル イメージには、Runner-Images フォルダーでアクセスできます。

前提条件

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

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

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

選択した方法に関係なく、Azure リソースをデプロイするには、環境定義でコンテナー イメージを指定する必要があります。

標準イメージを使用する

ADE では Bicep がネイティブにサポートされるため、テンプレート ファイル (azuredeploy.json と environment.yaml) をカタログに追加することで、デプロイ環境用の Azure リソースをデプロイする環境定義を構成できます。 その後、ADE では標準の Bicep コンテナー イメージを使用してデプロイ環境を作成します。

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

次の例は、サンプルの 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 コンテナー イメージは、ARM-Bicep イメージの Runner-Images フォルダーの下にある ADE サンプル リポジトリで確認できます。

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

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

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

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

Docker を使用してコンテナー イメージを作成し、カスタマイズする

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

ADE CLI は、ADE の基本イメージを使ってカスタム イメージを構築できるツールです。 ADE CLI を使い、ワークフローに合わせてデプロイと削除をカスタマイズできます。 サンプル イメージには、ADE CLI がプレインストールされています。 ADE CLI について詳しくは、CLI カスタム ランナー イメージ リファレンスに関する記事をご覧ください。

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

  1. ADE で作成されたサンプル イメージまたは FROM ステートメントを使って選んだ任意のイメージを基にして、イメージを作成します。
  2. RUN ステートメントを使って、イメージに必要なパッケージをインストールします。
  3. Dockerfile と同じレベルに scripts フォルダーを作成し、その中に deploy.shdelete.sh ファイルを格納して、作成されたコンテナー内でそれらのスクリプトを検出して実行できるようにします。 デプロイが ADE コア イメージを使って動作するためには、このステップが必要です。

FROM ステートメントを使用してサンプル コンテナー イメージを選択する

ADE のデプロイを利用して ADE CLI にアクセスする Docker イメージをビルドするには、ADE で作成されたイメージのいずれかを、そのイメージの基にする必要があります。 Microsoft Artifact Registry でホストされている ADE で作成されたサンプル イメージを指す FROM ステートメントを、新しいイメージ用に作成される DockerFile に含めます。 ADE で作成したイメージを使用する場合、カスタム イメージは ADE コア イメージに基づくものにします。

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

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

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

イメージにパッケージをインストールする

次の例に示すように、RUN ステートメントを使って、Azure CLI でパッケージをインストールできます。

RUN az bicep install

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

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

操作のシェル スクリプトを実行する

サンプル イメージ内では、操作名に基づいて操作が決定されて実行されます。 現在サポートされている 2 つの操作名は、deploydelete です。

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

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

Docker イメージをビルドし、それをコンテナー レジストリにプッシュして、ADE で使用できるようにする必要があります。

Docker CLI を使用するか、ADE から提供されるスクリプトを使用してイメージをビルドできます。

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

レジストリにプッシュされるイメージをビルドする前に、コンピューターに 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

イメージをレジストリにプッシュする

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

Docker Hub などの別のコンテナー レジストリにイメージを格納することもできますが、その場合は公的にアクセスできる必要があります。

注意事項

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

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

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

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

レジストリで匿名イメージ プルを有効に設定するには、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}

セキュリティで保護されたアクセスで ACR を使用する

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

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

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

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

  1. ACR インスタンスを作成するか、既存のインスタンスを使用します。

  2. Azure portal で、構成する ACR に移動します。

  3. 左側のメニューの [設定] で、[ネットワーク] を選択します。

  4. [ネットワーク] ページの [パブリック アクセス] タブの [公衆ネットワーク アクセス] で、[無効] を選択します。

    ACR ネットワーク設定で [パブリック アクセス] と [無効] が強調表示されている Azure portal のスクリーンショット。

  5. [ファイアウォール例外] で、[信頼された Microsoft サービスによるこのコンテナー レジストリへのアクセスを許可] が選択されていることを確認し、[保存] を選択します。

    ACR ネットワーク設定で [信頼された Microsoft サービスによるこのコンテナー レジストリへのアクセスを許可] と [保存] が強調表示されているスクリーンショット。

AcrPull ロールを割り当てる

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

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

  1. Azure portal で、構成する ACR に移動します。

  2. 左側のメニューで、[アクセス制御 (IAM)] を選択します。

  3. [追加]>[ロール割り当ての追加] の順に選択します。

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

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

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

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

この構成では、システム割り当てかユーザー割り当てかに関係なく、ADE には PET のマネージド ID が使用されます。

ヒント

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

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

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 は、失敗したデプロイに関するエラーの詳細をコンテナー内の $ADE_ERROR_LOG ファイルに格納します。

失敗したデプロイのトラブルシューティングを行うには:

  1. 開発者ポータルにサインインします。

  2. デプロイに失敗した環境を特定して、[詳細の表示] を選びます。

    失敗したデプロイ エラーの詳細 (具体的にはストレージ アカウントの無効な名前) を示すスクリーンショット。

  3. [エラーの詳細] セクションでエラーの詳細を確認します。

    [詳細の表示] ボタンが表示されている、環境のデプロイ失敗を示すスクリーンショット。

さらに、Azure CLI の次のコマンドを使って、環境のエラーの詳細を表示できます。

az devcenter dev environment show --environment-name {YOUR_ENVIRONMENT_NAME} --project {YOUR_PROJECT_NAME}

環境のデプロイまたは削除の操作ログを表示するには、Azure CLI を使って環境の最新の操作を取得し、その操作 ID のログを表示します。

# Get list of operations on the environment, choose the latest operation
az devcenter dev environment list-operation --environment-name {YOUR_ENVIRONMENT_NAME} --project {YOUR_PROJECT_NAME}
# Using the latest operation ID, view the operation logs
az devcenter dev environment show-logs-by-operation --environment-name {YOUR_ENVIRONMENT_NAME} --project {YOUR_PROJECT_NAME} --operation-id {LATEST_OPERATION_ID}