Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Container Apps verwaltet die Details von Kubernetes und der Containerorchestrierung für Sie. Container in Azure Container Apps können eine beliebige Laufzeit, Programmiersprache oder einen Entwicklungsstapel Ihrer Wahl verwenden.
Azure Container Apps unterstützt Folgendes:
- Jedes Linux-basierte x86-64 (
linux/amd64)-Containerimage - Container aus einer öffentlichen oder privaten Containerregistrierung
- Optionale Sidecar- und init-Container
Zu den Features gehören auch:
- Apps verwenden den Abschnitt
templateder Konfiguration, um das Containerimage und andere Einstellungen zu definieren. Änderungen am Abschnitttemplateder Konfiguration lösen eine neue Container-App-Revision aus. - Wenn ein Container abstürzt, wird er automatisch neu gestartet.
Zu den Auftragsfeatures gehören:
- Auftragsausführungen verwenden den Abschnitt
templateder Konfiguration, um das Containerimage und andere Einstellungen zu definieren, wenn die einzelnen Ausführungen gestartet werden. - Wenn ein Container beendet wird und der Beendigungscode nicht 0 (null) lautet, wird die Auftragsausführung als fehlerhaft markiert. Sie können einen Auftrag so konfigurieren, dass fehlerhafte Ausführungen wiederholt werden.
Konfiguration
Die meisten Container-Apps verfügen über einen einzelnen Container. In erweiterten Szenarien kann eine App auch über Sidecar- und Startcontainer verfügen. In einer Container-App-Definition werden die Haupt-App und die zugehörigen Sidecar-Container im Array containers im Abschnitt properties.template aufgeführt, und Startcontainer werden im Array initContainers aufgeführt. Der folgende Auszug zeigt die beim Einrichten der Container einer App verfügbaren Konfigurationsoptionen.
{
"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"
}
]
}
]
...
}
...
}
| Einstellung | BESCHREIBUNG | Bemerkungen |
|---|---|---|
image |
Der Name des Containerimages für Ihre Container-App. | Dieser Wert hat das Format repository/<IMAGE_NAME>:<TAG>. Vermeiden Sie statische Tags wie latest bei Containerimages. Die Verwendung statischer Tags kann zu Zwischenspeicherungsproblemen führen und die Problembehandlung Ihrer App erschweren. Verwenden Sie stattdessen eindeutige Tags für jede Bereitstellung, z. B. einen Git-Hash oder ein Datum und eine Uhrzeit, um sicherzustellen, dass Updates ordnungsgemäß nachverfolgt und bereitgestellt werden können. |
name |
Anzeigename des Containers. | Dient zur Berichterstellung und Identifizierung. |
command |
Der Startbefehl des Containers. | Entspricht dem Feld entrypoint von Docker. |
args |
Startbefehlsargumente. | Einträge im Array werden miteinander so verbunden, dass eine Parameterliste erstellt wird, die an den Startbefehl übergeben wird. |
env |
Ein Array von Name-Wert-Paaren, die Umgebungsvariablen festlegen. | Verwenden Sie secretRef anstelle des value Felds beim Verweisen auf einen geheimen Schlüssel. |
resources.cpu |
Die Anzahl der CPUs, die dem Container zugeordnet sind. | Siehe Anforderungen an vCPU- und Speicherbelegung |
resources.memory |
Die Größe des dem Container zugeteilten RAM. | Siehe Anforderungen an vCPU- und Speicherbelegung |
volumeMounts |
Ein Array der Volumebereitstellungsdefinitionen. | Sie können ein temporäres Volume oder dauerhafte Speichervolumes für Ihren Container definieren. Weitere Informationen zu Speichervolumes finden Sie unter Verwenden von Speicherbereitstellungen in Azure Container Apps. |
probes |
Ein Array von Integritätstasten, die im Container aktiviert sind. | Weitere Informationen zu Testeinstellungen finden Sie unter Integritätstests in Azure Container Apps. |
Anforderungen an vCPU- und Speicherbelegung
Wenn Sie den Verbrauchsplan nutzen, muss die Gesamtbelegung für CPU und Speicher, die für alle Container in einer Container-App zugeordnet ist, zusammen eine der folgenden Kombinationen ergeben.
| vCPUs (Kerne) | Arbeitsspeicher |
|---|---|
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 |
Hinweis
Apps, die den Verbrauchsplan in einer Umgebung vom Typ Nur Verbrauch verwenden, sind auf maximal 2 Kerne und 4 Gi Arbeitsspeicher beschränkt.
Mehrere Container
In erweiterten Szenarien können Sie mehrere Container in einer einzelnen Container-App ausführen. Verwenden Sie dieses Muster nur in bestimmten Fällen, in denen Ihre Container eng gekoppelt sind.
In den meisten Szenarien mit Microservices empfiehlt es sich, jeden Dienst als separate Container-App bereitzustellen.
Mehrere Container in derselben Container-App teilen sich Festplatten- und Netzwerkressourcen und durchlaufen den gleichen Anwendungslebenszyklus.
Es gibt zwei Möglichkeiten, zusätzliche Container in einer Container-App auszuführen: Sidecar-Container und Startcontainer.
Sidecar-Container
Sie können mehrere Container in einer einzelnen Container-App definieren, um das Sidecar-Muster zu implementieren.
Beispiele für Sidecar-Container sind:
Ein Agent, der Protokolle aus dem primären App-Container auf einem Freigabevolume liest und sie an einen Protokollierungsdienst weiterleitet.
Ein Hintergrundprozess, der einen Cache aktualisiert, der vom primären App-Container in einem Freigabevolume verwendet wird.
Diese Szenarien sind lediglich Beispiele und stellen nicht die einzigen Möglichkeiten dar, wie Sie ein Sidecar implementieren können.
Fügen Sie zum Ausführen mehrerer Container in einer Container-App mehr als einen Container im Array containers der Container-App-Vorlage hinzu.
Initialisierungscontainer.
Sie können einen oder mehrere Startcontainer in einer Container-App definieren. Initialisierungscontainer werden vor dem primären App-Container ausgeführt und dienen dazu, Initialisierungsaufgaben auszuführen, z. B. das Herunterladen von Daten oder das Vorbereiten der Umgebung.
Startcontainer werden im Array initContainers der Container-App-Vorlage definiert. Die Container werden in der Reihenfolge ausgeführt, in der sie im Array definiert wurden. Sie müssen erfolgreich abgeschlossen werden, bevor der primäre App-Container gestartet wird.
Hinweis
Startcontainer in Apps, die den Dedicated-Plan verwenden oder in einer Umgebung vom Typ Nur Verbrauch ausgeführt werden, können zur Laufzeit nicht auf die verwaltete Identität zugreifen.
Containerregistrierungen
Sie können Images bereitstellen, die in privaten Registrierungen gehostet werden, indem Sie Anmeldeinformationen in der Container Apps-Konfiguration angeben.
Um eine Containerregistrierung zu verwenden, definieren Sie die Registrierung im Array registries im Abschnitt properties.configuration der Container-App-Ressourcenvorlage. Das Feld passwordSecretRef identifiziert den Namen des Geheimen im secrets-Arraynamen, in dem Sie das Kennwort definiert haben.
{
...
"registries": [{
"server": "docker.io",
"username": "my-registry-user-name",
"passwordSecretRef": "my-password-secret-name"
}]
}
Mithilfe gespeicherter Anmeldeinformationen wird ein Containerimage aus der privaten Registrierung abgerufen, während Ihre App bereitgestellt wird.
Im folgenden Beispiel wird gezeigt, wie Sie Azure Container Registry-Anmeldeinformationen in einer Container-App konfigurieren.
{
...
"configuration": {
"secrets": [
{
"name": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-password"
}
]
}
}
Hinweis
Docker Hub beschränkt die Anzahl der Docker-Imagedownloads. Wenn der Grenzwert erreicht ist, können Container in Ihrer App nicht gestartet werden. Verwenden Sie eine Registrierung mit ausreichenden Grenzwerten wie Azure Container Registry, um dieses Problem zu vermeiden.
Verwaltete Identität mit Azure Container Registry
Sie können anstelle eines Benutzernamens und eines Kennworts eine verwaltete Azure-Identität verwenden, um sich mit Azure Container Registry zu authentifizieren. Weitere Informationen finden Sie unter Verwaltete Identitäten in Azure Container Apps.
Um eine verwaltete Identität mit einer Registrierung zu verwenden, muss die Identität in der App aktiviert werden, und ihr muss die Rolle acrPull in der Registrierung zugewiesen werden. Verwenden Sie zum Konfigurieren der Registrierung die Ressourcen-ID der verwalteten Identität (bei benutzerseitig zugewiesener Identität) oder system (bei systemseitig zugewiesener Identität) in der Eigenschaft identity der Registrierung. Konfigurieren Sie bei Verwendung einer verwalteten Identität keinen Benutzernamen und kein Kennwort.
{
"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"
}]
}
...
}
}
Weitere Informationen zum Konfigurieren benutzerseitig zugewiesener Identitäten finden Sie unter Hinzufügen einer benutzerseitig zugewiesenen Identität.
Einschränkungen
Für Azure Container Apps gelten die folgenden Einschränkungen:
Privilegierte Container: Azure Container Apps lassen den Modus für privilegierte Container mit Zugriff auf Hostebene nicht zu.
Betriebssystem: Linux-basierte (
linux/amd64) Containerimages sind erforderlich.Maximale Bildgröße:
- Das Workloadprofil „Verbrauch“ unterstützt Containerimages mit bis zu 8 GB für jede App oder jedes Auftragsreplikat.
- Dedizierte Workloadprofile unterstützen größere Containerimages. Da ein dediziertes Workloadprofil mehrere Apps oder Aufträge ausführen kann, teilen mehrere Containerimages den verfügbaren Speicherplatz. Die tatsächliche unterstützte Bildgröße variiert je nach Ressourcen, die von anderen Apps und Aufträgen verbraucht werden.