Azure Container Apps のコンテナー

Azure Container Apps により、Kubernetes とコンテナー オーケストレーションの詳細が管理されます。 Azure Container Apps のコンテナーでは、任意のランタイム、プログラミング言語、または開発スタックを使用できます。

Azure Container Apps: Containers

Azure Container Apps では、以下がサポートされています。

  • 必要な基本イメージがない Linux ベースの x86-64 (linux/amd64) コンテナー イメージ
  • 任意のパブリックまたはプライベート コンテナー レジストリからのコンテナー
  • サイドカーinit コンテナー

次のような機能もあります。

  • template 構成セクションを変更すると、新しい コンテナー アプリのリビジョン がトリガーされます。
  • コンテナーがクラッシュした場合は、自動的に再起動されます。

ジョブの機能は次のとおりです。

  • ジョブの実行では、 template 構成セクションを使用して、各実行の開始時にコンテナー イメージとその他の設定を定義します。
  • コンテナーがゼロ以外の終了コードで終了すると、ジョブの実行は失敗としてマークされます。 失敗した実行を再試行するようにジョブを構成できます。

構成

以下のコードは、コンテナー アプリ リソース テンプレートの properties.template セクションの containers 配列の一例です。 次の抜粋は、コンテナーを設定するときに使用できる構成オプションを示しています。

{
  "properties": {
    "template": {
      "containers": [
        {
          "name": "main",
          "image": "[parameters('container_image')]",
          "env": [
            {
              "name": "HTTP_PORT",
              "value": "80"
            },
            {
              "name": "SECRET_VAL",
              "secretRef": "mysecret"
            }
          ],
          "resources": {
            "cpu": 0.5,
            "memory": "1Gi"
          },
          "volumeMounts": [
            {
              "mountPath": "/appsettings",
              "volumeName": "appsettings-volume"
            }
          ],
          "probes": [
            {
              "type": "liveness",
              "httpGet": {
                "path": "/health",
                "port": 8080,
                "httpHeaders": [
                  {
                    "name": "Custom-Header",
                    "value": "liveness probe"
                  }
                ]
              },
              "initialDelaySeconds": 7,
              "periodSeconds": 3
            },
            {
              "type": "readiness",
              "tcpSocket": {
                "port": 8081
              },
              "initialDelaySeconds": 10,
              "periodSeconds": 3
            },
            {
              "type": "startup",
              "httpGet": {
                "path": "/startup",
                "port": 8080,
                "httpHeaders": [
                  {
                    "name": "Custom-Header",
                    "value": "startup probe"
                  }
                ]
              },
              "initialDelaySeconds": 3,
              "periodSeconds": 3
            }
          ]
        }
      ]
    },
    "initContainers": [
      {
        "name": "init",
        "image": "[parameters('init_container_image')]",
        "resources": {
          "cpu": 0.25,
          "memory": "0.5Gi"
        },
        "volumeMounts": [
          {
            "mountPath": "/appsettings",
            "volumeName": "appsettings-volume"
          }
        ]
      }
    ]
    ...
  }
  ...
}
設定 説明 解説
image コンテナー アプリのコンテナー イメージ名。 この値は repository/<IMAGE_NAME>:<TAG> の形式になります。
name コンテナーのフレンドリ名。 レポートと識別に使用されます。
command コンテナーのスタートアップ コマンド。 Docker の entrypoint フィールドと同じです。
args コマンド引数を起動します。 配列内のエントリが結合され、スタートアップ コマンドに渡すパラメーター リストが作成されます。
env 環境変数を定義するキーと値のペアの配列。 シークレットを参照するには、value フィールドの代わりに secretRef を使用します。
resources.cpu コンテナーに割り当てられた CPU の数。 従量課金プラン では、値は次の規則に従う必要があります。

•ゼロより大きい
• 2 以下
• 任意の 10 進数 (小数点以下 2 桁まで) を指定

たとえば、1.25 は有効ですが、1.555 は無効です。
既定値は、コンテナーあたり 0.25 CPU です。

専用プランで従量課金ワークロード プロファイルを使用する場合は、CPU が 4 以下である必要がある点を除き、同じ規則が適用されます。

専用プラン を使用する場合、最大 CPU は、コンテナー アプリが実行されているプロファイルで使用可能なコアの数以下である必要があります。
resources.memory コンテナーに割り当てられた RAM の量。 従量課金プラン では、値は次の規則に従う必要があります。

•ゼロより大きい
4Gi 以下
• 任意の 10 進数 (小数点以下 2 桁まで) を指定

たとえば、1.25Gi は有効ですが、1.555Gi は無効です。
既定値は、コンテナーあたり 0.5Gi です。

専用プランで従量課金ワークロードを使用する場合は、メモリが次の値以下8Giである必要がある点を除き、同じ規則が適用されます。

専用プランを使用する場合、最大メモリは、コンテナー アプリが実行されているプロファイルで使用可能なメモリ数以下である必要があります。
volumeMounts ボリューム マウント定義の配列です。 コンテナーの一時ボリュームまたは複数の永続ストレージ ボリュームを定義できます。 ストレージ ボリュームの詳細については、「Azure Container Apps でのストレージ マウントの使用」を参照してください。
probes コンテナーで有効になっている正常性プローブの配列です。 この機能は、Kubernetes 正常性プローブに基づいています。 プローブ設定の詳細については、「Azure Container Apps での正常性プローブ」を参照してください。

専用プランで従量課金プランまたは従量課金ワークロードを使用する場合、コンテナー アプリ内のすべてのコンテナーに対して要求された CPU とメモリ割り当ての合計が、次のいずれかの組み合わせになっている必要があります。

vCPU (コア) メモリ 従量課金プラン 従量課金ワークロード プロファイル
0.25 0.5Gi
0.5 1.0Gi
0.75 1.5Gi
1.0 2.0Gi
1.25 2.5Gi
1.5 3.0Gi
1.75 3.5Gi
2.0 4.0Gi
2.25 4.5Gi
2.5 5.0Gi
2.75 5.5Gi
3.0 6.0Gi
3.25 6.5Gi
3.5 7.0Gi
3.75 7.5Gi
4.0 8.0Gi
  • すべてのコンテナーの CPU 要求の合計は、vCPU 列のいずれかの値と一致している必要があります。

  • すべてのコンテナーのメモリ要求の合計は、CPU 列の同じ行にある memory 列のメモリの値と一致している必要があります。

専用プランで従量課金プロファイルを使用する場合、コンテナー アプリ内のすべてのコンテナーに対して要求された CPU とメモリの割り当ての合計が、プロファイルで使用可能なコアとメモリ以下である必要があります。

複数のコンテナー

1 つのコンテナー アプリで複数のコンテナーを実行することは、高度なユース ケースです。 このパターンは、コンテナーが密結合されている特定のインスタンスでのみ使用します。

ほとんどのマイクロサービス シナリオでは、各サービスを個別のコンテナー アプリとしてデプロイすることをお勧めします。

同じコンテナー アプリ内にある複数のコンテナーは、ハード ディスクとネットワーク リソースを共有し、同じ アプリケーション ライフサイクル を体験します。

コンテナー アプリで複数のコンテナーを実行するには、 サイドカー コンテナーinit コンテナー の 2 つの方法があります。

サイドカー コンテナー

サイドカー パターンを実装するために、1 つのコンテナー アプリで複数のコンテナーを定義できます。

サイドカー コンテナーの例を次に示します。

  • 共有ボリューム上のプライマリ アプリ コンテナーからログを読み取り、ログ サービスに転送するエージェント。

  • 共有ボリューム内のプライマリ アプリ コンテナーによって使用されるキャッシュを更新するバックグラウンド プロセス。

これらのシナリオは例であり、サイドカーを実装できる唯一の方法を示しているわけではありません。

コンテナー アプリで複数のコンテナーを実行するには、コンテナー アプリ テンプレートの containers 配列に複数のコンテナーを追加します。

Init コンテナー

コンテナー アプリで 1 つ以上の init コンテナー を定義できます。 Init コンテナーはプライマリ アプリ コンテナーの前に実行され、データのダウンロードや環境の準備などの初期化タスクを実行するために使用されます。

Init コンテナーは、コンテナー アプリ テンプレートの initContainers 配列で定義されます。 コンテナーは配列で定義された順に実行され、プライマリ アプリ コンテナーが起動される前に正常に完了する必要があります。

Note

Init コンテナーでは、マネージド ID を使用したイメージ プル がサポートされていますが、init コンテナーで実行されるプロセスはマネージド ID にアクセスできません。

コンテナー レジストリ

Container Apps 構成に資格情報を提供して、プライベート レジストリでホストされているイメージをデプロイできます。

コンテナー レジストリを使用するには、コンテナー アプリ リソース テンプレートの properties.configuration セクションの registries 配列で必要なフィールドを定義します。 passwordSecretRef フィールドでは、パスワードを定義した secrets 配列名内のシークレットの名前を識別します。

{
  ...
  "registries": [{
    "server": "docker.io",
    "username": "my-registry-user-name",
    "passwordSecretRef": "my-password-secret-name"
  }]
}

保存された資格情報は、アプリのデプロイ時にプライベート レジストリからコンテナー イメージをプルするために使用されます。

次の例は、コンテナー アプリで Azure Container Registry 資格情報を構成する方法を示しています。

{
  ...
  "configuration": {
    "secrets": [
      {
        "name": "acr-password",
        "value": "my-acr-password"
      }
    ],
    ...
    "registries": [
      {
        "server": "myacr.azurecr.io",
        "username": "someuser",
        "passwordSecretRef": "acr-password"
      }
    ]
  }
}

Note

Docker Hub では、Docker イメージのダウンロード数が制限されています。 制限に達すると、アプリ内のコンテナーは起動できなくなります。 この問題を回避するには、Azure Container Registry などの制限に余裕があるレジストリを使用します。

Azure Container Registry でのマネージド ID

Azure Container Registry に対する認証は、ユーザー名とパスワードの代わりに Azure マネージド ID を使用して行えます。 詳細については、「Azure Container Apps のマネージド ID」を参照してください。

マネージド ID をレジストリに割り当てる際、ユーザー割り当て ID にはマネージド ID のリソース ID を、システム割り当て ID には system を使用します。

{
    "identity": {
        "type": "SystemAssigned,UserAssigned",
        "userAssignedIdentities": {
            "<IDENTITY1_RESOURCE_ID>": {}
        }
    }
    "properties": {
        "configuration": {
            "registries": [
            {
                "server": "myacr1.azurecr.io",
                "identity": "<IDENTITY1_RESOURCE_ID>"
            },
            {
                "server": "myacr2.azurecr.io",
                "identity": "system"
            }]
        }
        ...
    }
}

ユーザー割り当て ID の構成について詳しくは、「ユーザー割り当て ID を追加する」を参照してください。

制限事項

Azure Container Apps には、次の制限があります。

  • 特権コンテナー: Azure Container Apps では、ホスト レベルのアクセス権を持つ特権コンテナー モードは許可されません。

  • オペレーティング システム: Linux ベースの (linux/amd64) コンテナー イメージが必要です。

次のステップ