Conteneurs dans Azure Container Apps
Azure Container Apps gère automatiquement les détails de Kubernetes et l’orchestration de conteneurs. Dans Azure Container Apps, les conteneurs peuvent utiliser le runtime, le langage de programmation et la pile de développement de votre choix.
Azure Container Apps prend en charge les éléments suivants :
- Toute image conteneur x86-64 linux
linux/amd64sans image de base requise - Les conteneurs de n’importe quel registre de conteneurs public ou privé
- Conteneurs side-car et init
Les fonctionnalités incluent également :
- Les modifications apportées à la
templatesection de configuration déclenchent une nouvelle révision d’application conteneur. - En cas d’incident, les conteneurs redémarrent automatiquement.
Les fonctionnalités de travaux sont les suivantes :
- Les exécutions de travaux utilisent la
templatesection de configuration pour définir l’image conteneur et d’autres paramètres au démarrage de chaque exécution. - Si un conteneur se termine avec un code de sortie autre que zéro, l’exécution du travail est marquée comme ayant échoué. Vous pouvez configurer un travail pour réessayer les exécutions ayant échoué.
Configuration
Voici un exemple de code containers dans la section properties.template d’un modèle de ressource d’application conteneur. L'extrait montre les options de configuration disponibles lors de la mise en place d'un conteneur.
{
"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"
}
]
}
]
...
}
...
}
| Paramètre | Description | Notes |
|---|---|---|
image |
Nom de l’image conteneur de votre application conteneur. | Cette valeur prend la forme repository/<IMAGE_NAME>:<TAG>. |
name |
Nom convivial du conteneur. | Utilisé pour la création de rapports et l’identification. |
command |
Commande de démarrage du conteneur. | Équivalente au champ entrypoint de Docker. |
args |
Arguments de la commande de démarrage. | Les entrées du tableau sont jointes pour créer une liste de paramètres à transmettre à la commande de démarrage. |
env |
Tableau de paires clé/valeur qui définissent des variables d’environnement. | Utilisez secretRef à la place du champ value pour faire référence à un secret. |
resources.cpu |
Nombre de processeurs alloués au conteneur. | Avec le plan Consommation, les valeurs doivent respecter les règles suivantes : • supérieur à zéro • inférieur ou égal à 2 • peut être n’importe quel nombre décimal (avec un maximum de deux décimales) Par exemple, 1.25 est valide, 1.555 non.La valeur par défaut est 0,25 PROCESSEUR par conteneur. Lorsque vous utilisez le profil de charge de travail Consommation sur le plan dédié, les mêmes règles s’appliquent, sauf que les processeurs doivent être inférieurs ou égaux à 4. Lorsque vous utilisez le plan dédié, les processeurs maximum doivent être inférieurs ou égaux au nombre de cœurs disponibles dans le profil dans lequel l’application conteneur est en cours d’exécution. |
resources.memory |
Quantité de RAM allouée au conteneur. | Avec le plan Consommation, les valeurs doivent respecter les règles suivantes : • supérieur à zéro • inférieur ou égal à 4Gi• peut être n’importe quel nombre décimal (avec un maximum de deux décimales) Par exemple, 1.25Gi est valide, 1.555Gi non.La valeur par défaut est de 0.5Gi par conteneur.Lorsque vous utilisez la charge de travail Consommation sur le plan dédié, les mêmes règles s’appliquent à l’exception de la mémoire doit être inférieure ou égale à 8Gi.Lorsque vous utilisez le plan dédié, la mémoire maximale doit être inférieure ou égale à la quantité de mémoire disponible dans le profil où l’application conteneur est en cours d’exécution. |
volumeMounts |
Tableau de définitions de montage de volume. | Vous pouvez définir un volume temporaire ou plusieurs volumes de stockage permanents pour votre conteneur. Pour plus d’informations sur les volumes de stockage, consultez Utiliser des montages de stockage dans Azure Container Apps. |
probes |
Tableau des sondes d’intégrité activées dans le conteneur. | Cette fonctionnalité est basée sur des sondes d’intégrité Kubernetes. Pour plus d’informations sur les paramètres des sondes, consultez Sondes d’intégrité dans Azure Container Apps. |
Lorsque vous utilisez le plan Consommation ou une charge de travail Consommation sur le plan dédié, les allocations totales de processeur et de mémoire demandées pour tous les conteneurs d’une application conteneur doivent correspondre à l’une des combinaisons suivantes.
| Processeurs virtuels (cœurs) | Mémoire | Plan Consommation | Profil de charge de travail consommation |
|---|---|---|---|
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 |
✔ |
Le total des demandes d’UC dans tous vos conteneurs doit correspondre à l’une des valeurs de la colonne processeurs virtuels.
Toutes les demandes de mémoire de tous les conteneurs doivent correspondre à la valeur de mémoire de la colonne Mémoire sur la même ligne que la colonne Processeur.
Lorsque vous utilisez le profil Consommation sur le plan dédié, les allocations totales de processeur et de mémoire demandées pour tous les conteneurs d’une application conteneur doivent être inférieures ou égales aux cœurs et à la mémoire disponibles dans le profil.
Plusieurs conteneurs
Dans les scénarios avancés, vous pouvez exécuter plusieurs conteneurs dans une application conteneur unique. Utilisez ce modèle uniquement dans des instances spécifiques où vos conteneurs sont étroitement couplés.
Pour la plupart des scénarios de microservice, la meilleure pratique consiste à déployer chaque service en tant qu’application conteneur distincte.
Les plusieurs conteneurs de la même application conteneur partagent des ressources réseau et disque dur et connaissent le même cycle de vie d’application.
Il existe deux façons d’exécuter plusieurs conteneurs dans une application conteneur : les conteneurs sidecar et les conteneurs init.
Conteneurs side-car
Vous pouvez définir plusieurs conteneurs dans une application de conteneur unique pour implémenter le modèle sidecar.
Voici quelques exemples de conteneurs sidecar :
Un agent qui lit les journaux à partir du conteneur d’application principal sur un volume partagé et les transfère à un service de journalisation.
Un processus en arrière-plan qui actualise un cache utilisé par le conteneur d’application principal dans un volume partagé.
Ces scénarios sont des exemples et ne représentent pas les seules façons dont vous pouvez implémenter une side-car.
Pour exécuter plusieurs conteneurs dans une application conteneur, ajoutez plusieurs conteneurs dans le tableau containers du modèle d’application conteneur.
Initialiser les conteneurs
Vous pouvez définir un ou plusieurs conteneurs init dans une application conteneur. Les conteneurs Init s’exécutent avant le conteneur d’application principal et sont utilisés pour effectuer des tâches d’initialisation telles que le téléchargement de données ou la préparation de l’environnement.
Les conteneurs Init sont définis dans le initContainers tableau du modèle d’application conteneur. Les conteneurs s’exécutent dans l’ordre dans lequel ils sont définis dans le tableau et doivent se terminer correctement avant le démarrage du conteneur d’application principal.
Remarque
Les conteneurs Init prennent en charge les extractions d’images à l’aide d’identités managées, mais les processus qui s’exécutent dans des conteneurs init n’ont pas accès aux identités managées.
Registres de conteneurs
Vous pouvez déployer des images hébergées sur des registres privés dans lesquels les informations d’identification sont fournies par le biais de la configuration Container Apps.
Pour utiliser un registre de conteneurs, vous définissez les champs requis dans le tableau registries dans la section properties.configuration du modèle de ressource d’application conteneur. Le champ passwordSecretRef identifie le nom du secret dans le nom du tableau secrets où vous avez défini le mot de passe.
{
...
"registries": [{
"server": "docker.io",
"username": "my-registry-user-name",
"passwordSecretRef": "my-password-secret-name"
}]
}
Les informations d’identification enregistrées sont utilisées pour extraire une image conteneur à partir du registre privé à mesure que votre application est déployée.
L’exemple suivant montre comment configurer les informations d’identification Azure Container Registry dans une application conteneur.
{
...
"configuration": {
"secrets": [
{
"name": "acr-password",
"value": "my-acr-password"
}
],
...
"registries": [
{
"server": "myacr.azurecr.io",
"username": "someuser",
"passwordSecretRef": "acr-password"
}
]
}
}
Remarque
Docker Hub limite le nombre de téléchargements d’images Docker. Lorsque cette limite est atteinte, les conteneurs de votre application ne démarrent pas. Utilisez un registre avec des limites suffisantes, telles qu’Azure Container Registry pour éviter ce problème.
Identité managée avec Azure Container Registry
Vous pouvez utiliser une identité managée Azure pour vous authentifier auprès d’Azure Container Registry au lieu d’utiliser un nom d’utilisateur et un mot de passe. Pour plus d'informations, voir Identités managées dans Azure Container Apps.
Lors de l’attribution d’une identité managée à un registre, utilisez l’ID de ressource d’identité managée pour une identité affectée par l’utilisateur ou system pour l’identité affectée par le système.
{
"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"
}]
}
...
}
}
Pour plus d’informations sur la configuration des identités affectées par l’utilisateur, consultez Ajouter une identité affectée par l’utilisateur.
Limites
Azure Container Apps présente les limitations suivantes :
Conteneurs privilégiés : Azure Container Apps n’autorise pas le mode conteneurs privilégiés avec un accès au niveau de l’hôte.
Système d’exploitation : des images conteneur Linux (
linux/amd64) sont requises.