Azure Container Apps のコンテナー
Azure Container Apps により、Kubernetes とコンテナー オーケストレーションの詳細が管理されます。 Azure Container Apps のコンテナーでは、任意のランタイム、プログラミング言語、または開発スタックを使用できます。
Azure Container Apps では、以下がサポートされています。
- 任意の Linux ベースの x86-64 (
linux/amd64) コンテナー イメージ - 任意のパブリックまたはプライベート コンテナー レジストリからのコンテナー
- サイドカー と init コンテナー
次のような機能もあります。
template構成セクションを変更すると、新しい コンテナー アプリのリビジョン がトリガーされます。- コンテナーがクラッシュした場合は、自動的に再起動されます。
ジョブの機能は次のとおりです。
- ジョブの実行では、
template構成セクションを使用して、各実行の開始時にコンテナー イメージとその他の設定を定義します。 - コンテナーがゼロ以外の終了コードで終了すると、ジョブの実行は失敗としてマークされます。 失敗した実行を再試行するようにジョブを構成できます。
構成
ほとんどのコンテナー アプリにはコンテナーが 1 つあります。 高度なシナリオでは、アプリにサイドカーと init のコンテナーが含まれる場合もあります。 コンテナー アプリ定義では、メイン アプリとそのサイドカー コンテナーが properties.template セクションの containers 配列に一覧表示され、init コンテナーは initContainers 配列に一覧表示されます。 次の抜粋は、アプリのコンテナーを設定するときに使用できる構成オプションを示しています。
{
"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 の数。 | 「vCPU とメモリ割り当ての要件」を参照してください |
resources.memory |
コンテナーに割り当てられた RAM の量。 | 「vCPU とメモリ割り当ての要件」を参照してください |
volumeMounts |
ボリューム マウント定義の配列です。 | コンテナーの一時または永続的なストレージ ボリュームを定義できます。 ストレージ ボリュームの詳細については、「Azure Container Apps でのストレージ マウントの使用」を参照してください。 |
probes |
コンテナーで有効になっている正常性プローブの配列です。 | プローブ設定の詳細については、「Azure Container Apps での正常性プローブ」を参照してください。 |
vCPU とメモリ割り当ての要件
従量課金プランを使用する場合、コンテナー アプリ内のすべてのコンテナーに割り当てられた 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 |
Note
"従量課金のみ" の環境で従量課金プランを使用するアプリは、最大 2 コアと 4Gi のメモリに制限されます。
複数のコンテナー
1 つのコンテナー アプリで複数のコンテナーを実行することは、高度なユース ケースです。 このパターンは、コンテナーが密結合されている特定のインスタンスでのみ使用します。
ほとんどのマイクロサービス シナリオでは、各サービスを個別のコンテナー アプリとしてデプロイすることをお勧めします。
同じコンテナー アプリ内にある複数のコンテナーは、ハード ディスクとネットワーク リソースを共有し、同じアプリケーション ライフサイクルを経験します。
コンテナー アプリで複数のコンテナーを実行するには、サイドカー コンテナーと init コンテナー の 2 つの方法があります。
サイドカー コンテナー
サイドカー パターンを実装するために、1 つのコンテナー アプリで複数のコンテナーを定義できます。
サイドカー コンテナーの例を次に示します。
共有ボリューム上のプライマリ アプリ コンテナーからログを読み取り、ログ サービスに転送するエージェント。
共有ボリューム内のプライマリ アプリ コンテナーによって使用されるキャッシュを更新するバックグラウンド プロセス。
これらのシナリオは例であり、サイドカーを実装できる唯一の方法を示しているわけではありません。
コンテナー アプリで複数のコンテナーを実行するには、コンテナー アプリ テンプレートの containers 配列に複数のコンテナーを追加します。
Init コンテナー
コンテナー アプリで 1 つ以上の init コンテナー を定義できます。 Init コンテナーはプライマリ アプリ コンテナーの前に実行され、データのダウンロードや環境の準備などの初期化タスクを実行するために使用されます。
Init コンテナーは、コンテナー アプリ テンプレートの initContainers 配列で定義されます。 コンテナーは配列で定義された順に実行され、プライマリ アプリ コンテナーが起動される前に正常に完了する必要があります。
Note
専用プランを使用している、または "従量課金のみ" 環境で実行されているアプリ内の 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": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-password"
}
]
}
}
Note
Docker Hub では、Docker イメージのダウンロード数が制限されています。 制限に達すると、アプリ内のコンテナーは起動できなくなります。 この問題を回避するには、Azure Container Registry などの制限に余裕があるレジストリを使用します。
Azure Container Registry でのマネージド ID
Azure Container Registry に対する認証は、ユーザー名とパスワードの代わりに Azure マネージド ID を使用して行えます。 詳細については、「Azure Container Apps のマネージド ID」を参照してください。
レジストリでマネージド ID を使用するには、アプリでその ID を有効にし、レジストリで acrPull ロールを割り当てる必要があります。 レジストリを構成するには、レジストリの identity プロパティで、ユーザー割り当て ID にマネージド ID リソース ID を使用するか、システム割り当て ID に system を使用します。 マネージド ID を使用する場合は、ユーザー名とパスワードを構成しないでください。
{
"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) コンテナー イメージが必要です。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示