AWS App Runner n'est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez [AWS App Runner la section Modification de la disponibilité](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html). 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. # Service App Runner basé sur le code source Vous pouvez l'utiliser AWS App Runner pour créer et gérer des services basés sur deux types de source de service fondamentalement différents : le *code source* et *l'image source*. Quel que soit le type de source, App Runner se charge du démarrage, de l'exécution, de la mise à l'échelle et de l'équilibrage de charge de votre service. Vous pouvez utiliser les CI/CD fonctionnalités d'App Runner pour suivre les modifications apportées à votre image source ou à votre code. Lorsqu'App Runner découvre une modification, il crée automatiquement (pour le code source) et déploie la nouvelle version sur votre service App Runner. Ce chapitre traite des services basés sur le code source. Pour plus d'informations sur les services basés sur une image source, consultez[Service App Runner basé sur une image source](service-source-image.md). Le code source est le code d'application qu'App Runner crée et déploie pour vous. Vous pointez App Runner vers un [répertoire source](#service-source-code.source-directory) dans un dépôt de code et vous choisissez un *environnement d'exécution* approprié correspondant à une version de plate-forme de programmation. App Runner crée une image basée sur l'image de base du moteur d'exécution et sur le code de votre application. Il démarre ensuite un service qui exécute un conteneur basé sur cette image. *App Runner fournit des environnements d'exécution gérés pratiques spécifiques à la plate-forme.* Chacun de ces environnements d'exécution crée une image de conteneur à partir de votre code source et ajoute des dépendances de langage d'exécution à votre image. Il n'est pas nécessaire de fournir des instructions de configuration et de construction du conteneur, telles qu'un Dockerfile. Les sous-rubriques de ce chapitre traitent des différentes plateformes prises en charge par App Runner, à savoir des *plateformes gérées* qui fournissent des environnements d'exécution gérés pour différents environnements de programmation et différentes versions. **Topics** + [Fournisseurs de référentiels de code source](#service-source-code.providers) + [Répertoire des sources](#service-source-code.source-directory) + [Plateformes gérées par App Runner](#service-source-code.managed-platforms) + [Fin du support pour les versions d'exécution gérées](#service-source-code.managed-platforms.eos) + [Versions d'exécution gérées et build d'App Runner](#service-source-code.build-detail) + [Utilisation de la plateforme Python](service-source-code-python.md) + [Utilisation de la plateforme Node.js](service-source-code-nodejs.md) + [Utilisation de la plateforme Java](service-source-code-java.md) + [Utilisation de la plateforme .NET](service-source-code-net6.md) + [À l'aide de la plateforme PHP](service-source-code-php.md) + [Utilisation de la plateforme Ruby](service-source-code-ruby.md) + [Utilisation de la plateforme Go](service-source-code-go1.md) ## Fournisseurs de référentiels de code source App Runner déploie votre code source en le lisant depuis un dépôt de code source. App Runner prend en charge deux fournisseurs de référentiels de code source : [GitHub](https://github.com/)et [Bitbucket](https://bitbucket.org/). ### Déploiement depuis votre fournisseur de référentiel de code source Pour déployer votre code source sur un service App Runner à partir d'un référentiel de code source, App Runner établit une connexion avec celui-ci. Lorsque vous utilisez la console App Runner pour [créer un service](manage-create.md), vous fournissez les détails de connexion et un répertoire des sources permettant à App Runner de déployer votre code source. **Connexions** Vous fournissez les détails de connexion dans le cadre de la procédure de création du service. Lorsque vous utilisez l'API App Runner ou le AWS CLI, une connexion constitue une ressource distincte. Tout d'abord, vous créez la connexion à l'aide de l'action [CreateConnection](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateConnection.html)API. Vous devez ensuite fournir l'ARN de la connexion lors de la création du service à l'aide de l'action [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. **Répertoire des sources** Lorsque vous créez un service, vous fournissez également un répertoire source. Par défaut, App Runner utilise le répertoire racine de votre dépôt comme répertoire source. Le répertoire source est l'emplacement de votre référentiel de code source qui stocke le code source et les fichiers de configuration de votre application. Les commandes build et start s'exécutent également à partir du répertoire source. Lorsque vous utilisez l'API App Runner ou AWS CLI pour créer ou mettre à jour un service, vous fournissez le répertoire source dans les actions d'[UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)et. Pour plus d'informations, consultez [Répertoire des sources](#service-source-code.source-directory)la section suivante. Pour plus d'informations sur la création du service App Runner, consultez[Création d'un service App Runner](manage-create.md). Pour plus d'informations sur les connexions App Runner, consultez[Gestion des connexions App Runner](manage-connections.md). ## Répertoire des sources Lorsque vous créez un service App Runner, vous pouvez fournir le répertoire source, ainsi que le référentiel et la branche. Définissez la valeur du champ **Répertoire source** sur le chemin du répertoire du référentiel qui stocke le code source et les fichiers de configuration de l'application. App Runner exécute les commandes de construction et de démarrage à partir du chemin du répertoire source que vous avez indiqué. Entrez la valeur absolue du chemin du répertoire source à partir du répertoire du référentiel racine. Si vous ne spécifiez aucune valeur, il s'agit par défaut du répertoire de premier niveau du référentiel, également appelé répertoire racine du référentiel. Vous avez également la possibilité de fournir différents chemins de répertoire source en plus du répertoire de référentiel de niveau supérieur. Cela prend en charge une architecture de référentiel monorepo, ce qui signifie que le code source de plusieurs applications est stocké dans un seul référentiel. Pour créer et prendre en charge plusieurs services App Runner à partir d'un seul monorepo, spécifiez différents répertoires sources lors de la création de chaque service. **Note** Si vous spécifiez le même répertoire source pour plusieurs services App Runner, les deux services seront déployés et fonctionneront individuellement. Si vous choisissez d'utiliser un fichier `apprunner.yaml` de configuration pour définir les paramètres de votre service, placez-le dans le dossier du répertoire source du référentiel. Si l'option **Déclencheur de déploiement** est définie sur **Automatique**, les modifications que vous validez dans le répertoire source déclencheront un déploiement automatique. * Seules les modifications apportées au chemin du répertoire source* déclencheront un déploiement automatique. Il est important de comprendre comment l'emplacement du répertoire source influe sur l'étendue d'un déploiement automatique. Pour plus d'informations, consultez la section *Déploiements automatisés* dans[Méthodes de déploiement](manage-deploy.md#manage-deploy.methods). **Note** Si votre service App Runner utilise les environnements d'exécution gérés par PHP et que vous souhaitez désigner un répertoire source autre que le dépôt racine par défaut, il est important d'utiliser la bonne version d'exécution de PHP. Pour de plus amples informations, veuillez consulter [À l'aide de la plateforme PHP](service-source-code-php.md). ## Plateformes gérées par App Runner Les plateformes gérées par App Runner fournissent des environnements d'exécution gérés pour différents environnements de programmation. Chaque environnement d'exécution géré facilite la création et l'exécution de conteneurs basés sur une version d'un langage de programmation ou d'un environnement d'exécution. Lorsque vous utilisez un environnement d'exécution géré, App Runner démarre avec une image d'environnement d'exécution géré. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient un package d'exécution de langage ainsi que des outils et des packages de dépendances populaires. App Runner utilise cette image d'exécution gérée comme image de base et ajoute le code de votre application pour créer une image Docker. Il déploie ensuite cette image pour exécuter votre service Web dans un conteneur. Vous spécifiez un environnement d'exécution pour votre service App Runner lorsque vous [créez un service](manage-create.md) à l'aide de la console App Runner ou de l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)API. Vous pouvez également spécifier un environnement d'exécution dans le cadre de votre code source. Utilisez le `runtime` mot clé dans un [fichier de configuration App Runner](config-file.md) que vous incluez dans votre référentiel de code. La convention de dénomination d'un environnement d'exécution géré est{{}}. App Runner met à jour le moteur d'exécution de votre service avec la dernière version à chaque déploiement ou mise à jour de service. Si votre application nécessite une version spécifique d'un environnement d'exécution géré, vous pouvez le spécifier à l'aide du `runtime-version` mot clé dans le [fichier de configuration d'App Runner](config-file.md). Vous pouvez verrouiller n'importe quel niveau de version, y compris une version majeure ou mineure. App Runner apporte uniquement des mises à jour de niveau inférieur à l'environnement d'exécution de votre service. ## Fin du support pour les versions d'exécution gérées Lorsque le fournisseur officiel ou la communauté d'un environnement d'exécution de langage géré déclare officiellement qu'une version est en fin de vie (EOL), App Runner déclare ensuite que le statut de la version est « *Fin de support* ». Si votre service est exécuté sur une version d'exécution du langage géré dont la date de fin de support est arrivée, les politiques et recommandations suivantes s'appliquent. **Fin du support pour une version d'exécution linguistique :** + **Les services existants** continueront à fonctionner et à traiter le trafic même s'ils utilisent un environnement d'exécution ayant atteint la fin du Support. Toutefois, ils s'exécuteront sur des environnements d'exécution non pris en charge qui ne recevront plus de mises à jour, de correctifs de sécurité ou de support technique. + Les **mises à jour des services existants** qui utilisent les environnements d'exécution de fin de support sont toujours autorisées, mais nous ne recommandons pas de continuer à utiliser les environnements d'exécution de fin de support pour un service. + **Les nouveaux services** ne peuvent pas être créés à l'aide des environnements d'exécution ayant atteint la date de fin du Support. **Actions requises pour les versions d'exécution linguistiques présentant le statut de fin de support :** + Si votre service est **basé sur une image source**, aucune autre action de votre part n'est requise pour ce service. + Si votre service est **basé sur le code source**, mettez à jour la configuration de votre service pour utiliser une version d'exécution prise en charge. Pour ce faire, sélectionnez une version d'exécution prise en charge dans la [console App Runner](https://console.aws.amazon.com/apprunner), mettez à jour le `runtime` champ dans le fichier de configuration [apprunner.yaml](config-file.md) ou utilisez les opérations [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)/[UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API ou les outils iAc pour définir le paramètre. `runtime` Pour obtenir la liste des environnements d'exécution pris en charge, consultez la page *d'informations sur les versions relatives* à un environnement d'exécution spécifique dans ce chapitre. + Vous pouvez également passer à l'option de **source d'image conteneur d'**App Runner. Pour en savoir plus, consultez [Service basé sur l'image](service-source-image.md). **Note** Si vous passez de Node.js 12, 14 ou 16 à **Node.js 22**, ou de Python 3.7 ou 3.8 à **Python 3.11**, sachez que Node.js 22 et Python 3.11 utilisent un processus de génération App Runner révisé qui permet des versions plus rapides et plus efficaces. Pour garantir la compatibilité avant la mise à niveau, nous vous recommandons de consulter les [instructions relatives au processus de création](#service-source-code.build-detail) dans la section suivante. Les tableaux suivants répertorient les versions d'exécution gérées par App Runner pour lesquelles une date de fin de support est définie. | **Versions d'exécution** | **Date de fin du Support d'App Runner** | | --- | --- | | [Runtimes compatibles](service-source-code-python-releases.md) avec Python 3.8 | 1er décembre 2025 | | [Runtimes compatibles](service-source-code-python-releases.md) avec Python 3.7 | 1er décembre 2025 | | Node.js 18 [Runtimes pris en charge](service-source-code-nodejs-releases.md) | 1er décembre 2025 | | Node.js 16 [Runtimes pris en charge](service-source-code-nodejs-releases.md) | 1er décembre 2025 | | Node.js 14 [Runtimes pris en charge](service-source-code-nodejs-releases.md) | 1er décembre 2025 | | Node.js 12 [Runtimes pris en charge](service-source-code-nodejs-releases.md) | 1er décembre 2025 | | .NET 6 \* | 1er décembre 2025 | | PHP 8.1 \* | 31 décembre 2025 | | Ruby 3.1 \* | 1er décembre 2025 | | Allez 1 \* | 1er décembre 2025 | **\*** App Runner ne publiera aucune nouvelle version linguistique pour les environnements d'exécution marqués d'un astérisque (\*). Ces environnements d'exécution sont les suivants : .NET, PHP, Ruby et Go. Si vous avez configuré un service basé sur du code pour ces environnements d'exécution, nous vous recommandons l'une des actions suivantes : + Le cas échéant, basculez la configuration de votre service vers un autre environnement d'exécution géré pris en charge. + Vous pouvez également créer une image de conteneur personnalisée avec votre version d'exécution préférée et la déployer à l'aide de l'[Service basé sur l'image](service-source-image.md)option App Runner. Vous pouvez héberger votre image dans Amazon ECR. ## Versions d'exécution gérées et build d'App Runner App Runner propose un processus de génération mis à jour pour les applications qui s'exécutent sur les versions majeures les plus récentes. Ce processus de construction révisé est plus rapide et plus efficace. Il crée également une image finale moins encombrante qui contient uniquement votre code source, les artefacts de build et les temps d'exécution nécessaires à l'exécution de votre application. Nous appelons le nouveau processus de construction la *version révisée d'App Runner* et le processus de construction d'origine la version *originale d'App Runner*. Pour éviter d'interrompre les modifications apportées aux versions antérieures des plateformes d'exécution, App Runner applique la version révisée uniquement à des versions d'exécution spécifiques, généralement des versions majeures récemment publiées. Nous avons introduit un nouveau composant dans le fichier de `apprunner.yaml` configuration afin de rendre la version révisée rétrocompatible pour un cas d'utilisation très spécifique et de fournir plus de flexibilité pour configurer la version de votre application. Il s'agit du [`pre-run`](config-file-ref.md#config-file-ref.run)paramètre facultatif. Nous expliquons quand utiliser ce paramètre ainsi que d'autres informations utiles sur les builds dans les sections qui suivent. Le tableau suivant indique quelle version de la version d'App Runner s'applique à des versions d'exécution gérées spécifiques. Nous continuerons à mettre à jour ce document pour vous tenir au courant de nos durées d'exécution actuelles. - ** Python – [Informations sur la publication](service-source-code-python-releases.md) ** - ****Versions d'exécution**:** Python 3.11 (\!) / ****Processus de construction**:** Révisé / ****Date de fin du Support d'App Runner**:** - ****Versions d'exécution**:** Python 3.8 / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ****Versions d'exécution**:** Python 3.7 / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ** Node.js – [Informations sur la publication](service-source-code-nodejs-releases.md) ** - ****Versions d'exécution**:** Node.js 22 / ****Processus de construction**:** Révisé / ****Date de fin du Support d'App Runner**:** - ****Versions d'exécution**:** Node.js 18 / ****Processus de construction**:** Révisé / ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ****Versions d'exécution**:** Node.js 16 / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ****Versions d'exécution**:** Node.js 14 / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ****Versions d'exécution**:** Node.js 12 / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ** Corretto — [Informations sur la publication](service-source-code-java-releases.md) ** - ****Versions d'exécution**:** Corretto / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** - ****Versions d'exécution**:** Corretto 8 / ****Processus de construction**:** Original / ****Date de fin du Support d'App Runner**:** - ** .NET – [Informations sur la publication](service-source-code-dotnet-releases.md) ** - ****Versions d'exécution**:** .NET 6 \* - ****Processus de construction**:** Original - ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ** PHP – [Informations sur la publication](service-source-code-php-releases.md) ** - ****Versions d'exécution**:** PHP 8.1 \* - ****Processus de construction**:** Original - ****Date de fin du Support d'App Runner**:** 31 décembre 2025 - ** Ruby – [Informations sur la publication](service-source-code-ruby-releases.md) ** - ****Versions d'exécution**:** Ruby 3.1 \* - ****Processus de construction**:** Original - ****Date de fin du Support d'App Runner**:** 1er décembre 2025 - ** Go – [Informations sur la publication](service-source-code-go-releases.md) ** - ****Versions d'exécution**:** Allez 1 \* - ****Processus de construction**:** Original - ****Date de fin du Support d'App Runner**:** 1er décembre 2025 **Note** Certains des environnements d'exécution répertoriés incluent une date **de fin de Support**. Pour de plus amples informations, veuillez consulter [Fin du support pour les versions d'exécution gérées](#service-source-code.managed-platforms.eos). **Important** **Python 3.11** — Nous avons des recommandations spécifiques pour la configuration de build des services qui utilisent le runtime géré Python 3.11. Pour plus d'informations, consultez la rubrique relative [Des légendes pour des versions d'exécution spécifiques](service-source-code-python.md#service-source-code-python.callouts) à la *plateforme Python*. ### En savoir plus sur les versions et la migration d'App Runner Lorsque vous migrez votre application vers un environnement d'exécution plus récent qui utilise la version révisée, vous devrez peut-être modifier légèrement la configuration de votre version. Pour fournir un contexte aux considérations relatives à la migration, nous allons d'abord décrire les processus de haut niveau pour la version originale d'App Runner et pour la version révisée. Nous publierons ensuite une section qui décrit les attributs spécifiques de votre service susceptibles de nécessiter des mises à jour de configuration. #### La version originale d'App Runner Le processus de création de l'application App Runner d'origine tire parti du AWS CodeBuild service. Les étapes initiales sont basées sur des images sélectionnées par le CodeBuild service. Un processus de génération de Docker suit qui utilise l'image d'exécution gérée App Runner applicable comme image de base. Les étapes générales sont les suivantes : 1. Exécutez `pre-build` des commandes dans une CodeBuild image organisée. Les `pre-build` commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier `apprunner.yaml` de configuration. 1. Exécutez les `build` commandes CodeBuild en utilisant la même image que celle de l'étape précédente. Les `build` commandes sont obligatoires. Ils peuvent être spécifiés dans la console App Runner, l'API App Runner ou dans le fichier `apprunner.yaml` de configuration. 1. Exécutez une version Docker pour générer une image basée sur l'image d'exécution gérée par App Runner pour votre plate-forme et votre version d'exécution spécifiques. 1. Copiez le `/app` répertoire à partir de l'image que nous avons générée à **l'étape 2**. La destination est l'image basée sur l'image d'exécution gérée par App Runner, que nous avons générée à **l'étape 3**. 1. Exécutez à nouveau les `build` commandes sur l'image d'exécution gérée par App Runner générée. Nous exécutons à nouveau les commandes de construction pour générer des artefacts de construction à partir du code source du `/app` répertoire que nous y avons copié à **l'étape 4**. Cette image sera ensuite déployée par App Runner pour exécuter votre service Web dans un conteneur. Les `build` commandes sont obligatoires. Ils peuvent être spécifiés dans la console App Runner, l'API App Runner ou dans le fichier `apprunner.yaml` de configuration. 1. Exécutez `post-build` les commandes dans l' CodeBuild image de **l'étape 2**. Les `post-build` commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier `apprunner.yaml` de configuration. Une fois la compilation terminée, App Runner déploie l'image d'exécution gérée App Runner générée à l'**étape 5** pour exécuter votre service Web dans un conteneur. #### La version révisée d'App Runner Le processus de construction révisé est plus rapide et plus efficace que le processus de construction d'origine décrit dans la section précédente. Cela élimine la duplication des commandes de compilation qui se produit dans la version précédente. Il crée également une image finale moins encombrante qui contient uniquement votre code source, les artefacts de build et les temps d'exécution nécessaires à l'exécution de votre application. Ce processus de génération utilise une version en plusieurs étapes de Docker. Les étapes générales du processus sont les suivantes : 1. **Étape de construction** : lancez un processus de génération de docker qui exécute `pre-build` et `build` commande au-dessus des images de build d'App Runner. 1. Copiez le code source de l'application `/app` dans le répertoire. **Note** Ce `/app` répertoire est désigné comme répertoire de travail à chaque étape de la construction de Docker. 1. Exécutez les commandes `pre-build`. Les `pre-build` commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier `apprunner.yaml` de configuration. 1. Exécutez les `build` commandes. Les `build` commandes sont obligatoires. Ils peuvent être spécifiés dans la console App Runner, l'API App Runner ou dans le fichier `apprunner.yaml` de configuration. 1. **Étape d'empaquetage** — Génère l'image finale du conteneur du client, qui est également basée sur l'image exécutée par App Runner. 1. Copiez le `/app` répertoire de l'**étape de construction** précédente vers la nouvelle image Run. Cela inclut le code source de votre application et les artefacts de construction de l'étape précédente. 1. Exécutez les `pre-run` commandes. Si vous devez modifier l'image d'exécution en dehors du `/app` répertoire à l'aide des `build` commandes, ajoutez les mêmes commandes ou les commandes obligatoires à ce segment du fichier de `apprunner.yaml` configuration. Il s'agit d'un nouveau paramètre qui a été introduit pour prendre en charge la version révisée d'App Runner. Les `pre-run` commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier `apprunner.yaml` de configuration. **Remarques** Les `pre-run` commandes ne sont prises en charge que par la version révisée. Ne les ajoutez pas au fichier de configuration si votre service utilise des versions d'exécution qui utilisent la version d'origine. Si vous n'avez pas besoin de modifier quoi que ce soit en dehors du `/app` répertoire à l'aide des `build` commandes, vous n'avez pas besoin de spécifier de `pre-run` commandes. 1. Étape **post-construction : cette étape** reprend à partir de la *phase de construction* et exécute `post-build` des commandes. 1. Exécutez les `post-build` commandes dans le `/app` répertoire. Les `post-build` commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier `apprunner.yaml` de configuration. Une fois la compilation terminée, App Runner déploie l'image Run pour exécuter votre service Web dans un conteneur. **Note** Ne vous laissez pas induire en erreur par les `env` entrées de la section Exécuter du `apprunner.yaml` lors de la configuration du processus de génération. Même si le paramètre de `pre-run` commande, référencé à l'**étape 2 (b)**, se trouve dans la `env` section Exécuter, ne l'utilisez pas pour configurer votre build. Les `pre-run` commandes font uniquement référence aux `env` variables définies dans la section Build du fichier de configuration. Pour plus d'informations, consultez le [Exécuter la section](config-file-ref.md#config-file-ref.run) *chapitre sur le fichier de configuration d'App Runner*. #### Exigences de service pour la prise en compte de la migration Si votre environnement d'application répond à l'une de ces deux exigences, vous devrez revoir la configuration de votre build en ajoutant des `pre-run` commandes. + Si vous devez modifier quoi que ce soit en dehors du `/app` répertoire à l'aide des `build` commandes. + Si vous devez exécuter les `build` commandes deux fois pour créer l'environnement requis. Il s'agit d'une exigence très inhabituelle. La grande majorité des versions ne le feront pas. **Modifications en dehors du `/app` répertoire** + La [version révisée d'App Runner](#service-source-code.build-detail.v2) part du principe que votre application ne possède aucune dépendance en dehors du `/app` répertoire. + Les commandes que vous fournissez avec le `apprunner.yaml` fichier, l'API App Runner ou la console App Runner doivent générer des artefacts de build dans le `/app` répertoire. + Vous pouvez modifier les `post-build` commandes `pre-build``build`, et pour vous assurer que tous les artefacts de construction se trouvent dans le `/app` répertoire. + Si votre application a besoin du build pour modifier davantage l'image générée pour votre service, en dehors du `/app` répertoire, vous pouvez utiliser les nouvelles `pre-run` commandes du`apprunner.yaml`. Pour de plus amples informations, veuillez consulter [Configuration des options du service App Runner à l'aide d'un fichier de configuration](config-file.md). **Exécution des `build` commandes deux fois** + La [version originale d'App Runner](#service-source-code.build-detail.v1) exécute les `build` commandes deux fois, d'abord à **l'étape 2**, puis de nouveau à **l'étape 5**. La version révisée d'App Runner remédie à cette redondance et n'exécute les `build` commandes qu'une seule fois. Si votre application doit exceptionnellement exiger que `build` les commandes s'exécutent deux fois, la version révisée d'App Runner offre la possibilité de spécifier et d'exécuter à nouveau les mêmes commandes à l'aide du `pre-run` paramètre. Cela permet de conserver le même comportement de double construction.