Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Ce chapitre décrit les informations d'exécution et les directives de développement que vous devez prendre en compte lors du développement ou de la migration du code d'application à des fins de AWS App Runner déploiement.
Informations d'exécution
Que vous fournissiez une image de conteneur ou qu'App Runner en crée une pour vous, App Runner exécute le code de votre application dans une instance de conteneur. Voici quelques aspects clés de l'environnement d'exécution des instances de conteneurs.
-
Support du framework : App Runner prend en charge toute image implémentant une application Web. Il est indépendant du langage de programmation que vous choisissez et du serveur ou du framework d'applications Web que vous utilisez, le cas échéant. Pour votre commodité, nous proposons des environnements d'exécution gérés spécifiques aux différentes plateformes de programmation, afin de rationaliser le processus de création d'applications et de création d'images abstraites.
-
Demandes Web : App Runner prend en charge les protocoles HTTP 1.0 et HTTP 1.1 pour les instances de conteneur. Pour plus d'informations sur la configuration de votre service, consultezConfiguration d'un service App Runner. Il n'est pas nécessaire d'implémenter la gestion du trafic sécurisé HTTPS. App Runner redirige toutes les requêtes HTTP entrantes vers les points de terminaison HTTPS correspondants. Il n'est pas nécessaire de configurer de paramètres pour permettre la redirection des requêtes Web HTTP. App Runner met fin au TLS avant de transmettre les demandes à votre instance de conteneur d'applications.
Note
-
Le délai d'expiration des requêtes HTTP est de 120 secondes au total. Les 120 secondes incluent le temps nécessaire à l'application pour lire la demande, y compris le corps, et terminer l'écriture de la réponse HTTP.
-
Le délai limite de lecture et de réponse des demandes dépend des applications que vous utilisez. Ces applications peuvent avoir leurs propres délais d'expiration internes, comme le serveur HTTP pour Python, Gunicorn, qui a une limite de délai d'expiration par défaut de 30 secondes. Dans de tels cas, le délai d'expiration de l'application dépasse le délai d'expiration de 120 secondes d'App Runner.
-
Vous n'avez pas besoin de configurer les suites de chiffrement TLS ni aucun autre paramètre, car App Runner est un service entièrement géré qui gère la terminaison du protocole TLS pour vous.
-
-
Applications apatrides — Actuellement, App Runner ne prend pas en charge les applications statiques. Par conséquent, App Runner ne garantit pas la persistance de l'état au-delà de la durée de traitement d'une seule requête Web entrante.
-
Stockage : App Runner augmente ou diminue automatiquement les instances de votre application App Runner en fonction du volume de trafic entrant. Vous pouvez configurer les options de dimensionnement automatique pour votre application App Runner. Étant donné que le nombre d'instances actuellement actives traitant les requêtes Web est basé sur le volume de trafic entrant, App Runner ne peut garantir que les fichiers puissent persister au-delà du traitement d'une seule demande. Par conséquent, App Runner implémente le système de fichiers dans votre instance de conteneur sous forme de stockage éphémère, ce qui implique que les fichiers sont transitoires. Par exemple, les fichiers ne sont pas conservés lorsque vous interrompez et reprenez votre service App Runner.
App Runner vous fournit 3 Go de stockage éphémère et utilise une partie des 3 Go de stockage éphémère pour son image de conteneur extraite, compressée et non compressée sur l'instance. Le stockage éphémère restant peut être utilisé par votre service App Runner. Toutefois, il ne s'agit pas d'un stockage permanent en raison de son caractère apatride.
Note
Il peut arriver que les fichiers de stockage persistent malgré les demandes. Par exemple, si la demande suivante arrive sur la même instance, les fichiers de stockage seront conservés. La persistance des fichiers de stockage entre les demandes peut être utile dans certaines situations. Par exemple, lors du traitement d'une demande, vous pouvez mettre en cache les fichiers que votre application télécharge si de futures demandes peuvent en avoir besoin. Cela peut accélérer le traitement des demandes futures, mais ne garantit pas les gains de vitesse. Votre code ne doit pas partir du principe qu'un fichier téléchargé lors d'une demande précédente existe toujours.
-
Variables d'environnement : par défaut, App Runner rend la variable d'
PORTenvironnement disponible dans votre instance de conteneur. Vous pouvez configurer la valeur de la variable avec les informations de port et ajouter des variables et des valeurs d'environnement personnalisées. Vous pouvez également référencer des données sensibles stockées dans AWS Secrets Managerou AWS Systems Manager Parameter Store en tant que variables d'environnement. Pour plus d'informations sur la création de variables d'environnement, consultezRéférencement des variables d'environnement. -
Rôle d'instance : si le code de votre application appelle un service, en utilisant le service APIs ou l'un d'entre eux AWS SDKs, créez un rôle d'instance à l'aide de AWS Identity and Access Management (IAM). AWS Ensuite, attachez-le à votre service App Runner lorsque vous le créez. Incluez toutes les autorisations d'action de AWS service requises par votre code dans votre rôle d'instance. Pour de plus amples informations, veuillez consulter Rôle de l'instance.
Directives de développement du code
Tenez compte de ces directives lorsque vous développez du code pour une application Web App Runner.
-
Corriger les images du conteneur : lorsque vous fournissez des images du conteneur, vous êtes responsable de les mettre à jour et de corriger régulièrement ces images. Pendant qu'App Runner gère l'infrastructure, vous devez vous assurer de la sécurité et de l' up-to-dateétat des images de conteneur fournies. Pour plus d'informations, consultez la documentation AWS App Runner
-
Concevez un code apatride : concevez l'application Web que vous déployez sur votre service App Runner pour qu'elle soit apatride. Votre code doit partir du principe qu'aucun état ne persiste au-delà de la durée de traitement d'une seule requête Web entrante.
-
Supprimer les fichiers temporaires : lorsque vous créez des fichiers, ils sont stockés sur un système de fichiers et occupent une partie de l'espace de stockage alloué à votre service. Pour éviter les out-of-storage erreurs, ne conservez pas les fichiers temporaires pendant de longues périodes. Équilibrez la taille du stockage avec la vitesse de traitement des demandes lorsque vous prenez des décisions relatives à la mise en cache des fichiers.
-
Démarrage de l'instance : App Runner permet de démarrer l'instance en cinq minutes. Votre instance doit écouter les demandes sur ses ports d'écoute configurés et être saine dans les cinq minutes suivant son démarrage. Au démarrage, les instances App Runner se voient attribuer un processeur virtuel (vCPU) en fonction de la configuration de votre vCPU. Pour plus d'informations sur la configuration des vCPU disponibles, consultez. Configurations compatibles avec App Runner
Une fois que l'instance a démarré avec succès, elle passe à l'état inactif et attend les demandes. Vous payez en fonction de la durée de démarrage de l'instance, avec un minimum d'une minute par démarrage d'instance. Pour plus d’informations sur la tarification, consultez Tarification AWS App Runner
.
