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 :
- N’importe quelle image conteneur Linux x86-64 (
linux/amd64) - Les conteneurs de n’importe quel registre de conteneurs public ou privé
- Conteneurs sidecar et init facultatifs
Les fonctionnalités incluent également :
- Les applications utilisent la section de configuration
templatepour définir l’image conteneur et d’autres paramètres. Les modifications apportées à la section de configurationtemplatedéclenchent une nouvelle révision de l’application conteneur. - En cas d’incident, les conteneurs redémarrent automatiquement.
Ses caractéristiques de travaux sont les suivantes :
- Les exécutions de travail utilisent la section de la configuration
templatepour définir l’image conteneur et d’autres paramètres lors du 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
La plupart des applications conteneur ont un seul conteneur. Dans les scénarios avancés, une application peut également avoir un side-car et des conteneurs init. Dans une définition d’application conteneur, l’application principale et ses conteneurs side-car sont répertoriés dans le tableau containers de la section properties.template et les conteneurs init sont répertoriés dans le tableau initContainers. L'extrait suivant montre les options de configuration disponibles lors de la configuration des conteneurs d’une application.
{
"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"
}
]
}
]
...
}
...
}
| Setting | 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 nom/valeur qui définit 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. | Consulter Exigences relatives à l’allocation de mémoire et au processeur virtuel |
resources.memory |
Quantité de RAM allouée au conteneur. | Consulter Exigences relatives à l’allocation de mémoire et aux processeurs virtuels |
volumeMounts |
Tableau de définitions de montage de volume. | Vous pouvez définir des volume de stockage permanents ou un volume de stockage temporaire 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. | Pour plus d’informations sur les paramètres des sondes, consultez Sondes d’intégrité dans Azure Container Apps. |
Exigences relatives à l’allocation de mémoire et aux processeurs virtuels
Lorsque vous utilisez le plan Consommation, l’allocation totale de processeurs et de mémoire pour tous les conteneurs d’une application conteneur doit correspondre à l’une des combinaisons suivantes.
| Processeurs virtuels (cœurs) | Mémoire |
|---|---|
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 |
Remarque
Les applications utilisant le plan Consommation dans un environnement Consommation uniquement sont limitées à un nombre maximal de 2 cœurs et 4 Gi de mémoire.
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.
Plusieurs conteneurs d’une application conteneur partagent les mêmes ressources disque dur et réseau et connaissent un cycle de vie d’application identique.
Il existe deux moyens d’exécuter des conteneurs supplémentaires dans une application conteneur : conteneurs de side-car et 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, il existe bien d’autres moyens d’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 tableau initContainers 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 dans des applications utilisant le plan Dédié, ou s’exécutant dans un environnement Consommation uniquement, ne peuvent pas accéder à une identité managée lors d’une exécution.
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 le registre dans le tableau registries de 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": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-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 offrant des limites suffisantes, comme 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.
Pour utiliser une identité managée avec un registre, l’identité doit être activée dans l’application et se voir affecter le rôle acrPull dans le registre. Pour configurer le 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 dans la propriété identity du registre. Ne configurez pas un nom d’utilisateur et un mot de passe lors vous utilisez une identité managée.
{
"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 de 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.Taille d’image maximale :
- Le profil de charge de travail Consommation prend en charge les images conteneur pouvant atteindre jusqu’à 8 Go pour chaque application ou réplica de travail.
- Les profils de charge de travail Dedicated prennent en charge des images conteneur plus grandes. Étant donné qu’un profil de charge de travail Dedicated peut exécuter plusieurs applications ou travaux, plusieurs images conteneur partagent l’espace disque disponible. La taille réelle de l’image prise en charge varie en fonction des ressources consommées par d’autres applications et travaux.