AWS App Runner ne sera plus ouvert aux nouveaux clients à compter du 30 avril 2026. Si vous souhaitez utiliser App Runner, inscrivez-vous avant cette date. 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
<a name="service-source-code"></a>

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
<a name="service-source-code.providers"></a>

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
<a name="service-source-code.providers.github"></a>

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
<a name="service-source-code.source-directory"></a>

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
<a name="service-source-code.managed-platforms"></a>

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*<language-name><major-version>*. 

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
<a name="service-source-code.managed-platforms.eos"></a>

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 \$1  |  1er décembre 2025  | 
|  PHP 8.1 \$1  |  31 décembre 2025  | 
|  Ruby 3.1 \$1  |  1er décembre 2025  | 
|  Allez 1 \$1  | 1er décembre 2025 | 

**\$1** App Runner ne publiera aucune nouvelle version linguistique pour les environnements d'exécution marqués d'un astérisque (\$1). 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
<a name="service-source-code.build-detail"></a>

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.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code.html)

**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
<a name="service-source-code.build-detail.builds-and-migr"></a>

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
<a name="service-source-code.build-detail.v1"></a>

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
<a name="service-source-code.build-detail.v2"></a>

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
<a name="service-source-code.build-detail.migrating"></a>

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.

# Utilisation de la plateforme Python
<a name="service-source-code-python"></a>

**Important**  
App Runner mettra fin au support de **Python 3.7** et **Python 3.8** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

La plateforme AWS App Runner Python fournit des environnements d'exécution gérés. Chaque environnement d'exécution facilite la création et l'exécution de conteneurs avec des applications Web basées sur une version de Python. Lorsque vous utilisez un environnement d'exécution Python, App Runner démarre avec une image d'exécution Python gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution d'une version de Python ainsi que certains outils et 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*<language-name><major-version>*. 

Pour les noms et versions d'exécution Python valides, consultez[Informations sur la version de Python Runtime](service-source-code-python-releases.md).

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.

Syntaxe de version pour les environnements d'exécution Python : `major[.minor[.patch]]`

Par exemple : `3.8.5`

Les exemples suivants illustrent le verrouillage des versions :
+ `3.8`— Verrouillez les versions majeures et mineures. App Runner met à jour uniquement les versions de correctif.
+ `3.8.5`— Verrouillez vers une version de correctif spécifique. App Runner ne met pas à jour votre version d'exécution.

**Topics**
+ [Configuration de l'environnement d'exécution Python](#service-source-code-python.config)
+ [Des légendes pour des versions d'exécution spécifiques](#service-source-code-python.callouts)
+ [Exemples d'exécution en Python](#service-source-code-python.examples)
+ [Informations sur la version de Python Runtime](service-source-code-python-releases.md)

## Configuration de l'environnement d'exécution Python
<a name="service-source-code-python.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

## Des légendes pour des versions d'exécution spécifiques
<a name="service-source-code-python.callouts"></a>

**Note**  
App Runner exécute désormais un processus de génération mis à jour pour les applications basé sur les versions d'exécution suivantes : Python 3.11, Node.js 22 et Node.js 18. Si votre application s'exécute sur l'une de ces versions d'exécution, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail) pour plus d'informations sur le processus de génération révisé. Les applications qui utilisent toutes les autres versions d'exécution ne sont pas affectées et continuent à utiliser le processus de génération d'origine. 

### Python 3.11 (version révisée d'App Runner)
<a name="service-source-code-python.callouts.python311"></a>

Utilisez les paramètres suivants dans le fichier *apprunner.yaml pour* le runtime géré de Python 3.11.
+ Réglez la `runtime` clé dans la section supérieure sur `python311`   
**Example**  

  ```
  runtime: python311
  ```
+ Utilisez le `pip3` au lieu de `pip` pour installer les dépendances.
+ Utilisez l'`python3`interpréteur au lieu de`python`.
+ Exécutez le `pip3` programme d'installation sous forme de `pre-run` commande. Python installe les dépendances en dehors du `/app` répertoire. Comme App Runner exécute la version révisée d'App Runner pour Python 3.11, tout ce qui est installé en dehors du `/app` répertoire par le biais de commandes dans la section Build du `apprunner.yaml` fichier sera perdu. Pour de plus amples informations, veuillez consulter [La version révisée d'App Runner](service-source-code.md#service-source-code.build-detail.v2).  
**Example**  

  ```
  run:
    runtime-version: 3.11
    pre-run:  
      - pip3 install pipenv
      - pipenv install
      - python3 copy-global-files.py
    command: pipenv run gunicorn django_apprunner.wsgi --log-file -
  ```

Pour plus d'informations, consultez également l'[exemple d'un fichier de configuration étendu pour Python 3.11](#service-source-code-python.examples.extended-v2) plus loin dans cette rubrique.

## Exemples d'exécution en Python
<a name="service-source-code-python.examples"></a>

Les exemples suivants montrent les fichiers de configuration App Runner permettant de créer et d'exécuter un service Python. Le dernier exemple est le code source d'une application Python complète que vous pouvez déployer sur un service d'exécution Python.

**Note**  
La version d'exécution utilisée dans ces exemples est *3.7.7* et*3.11*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution de Python prise en charge, consultez[Informations sur la version de Python Runtime](service-source-code-python-releases.md).

### Fichier de configuration Python minimal
<a name="service-source-code-python.examples.minimal"></a>

Cet exemple montre un fichier de configuration minimal que vous pouvez utiliser avec un environnement d'exécution géré en Python. Pour les hypothèses formulées par App Runner avec un fichier de configuration minimal, consultez[Exemples de fichiers de configuration](config-file-examples.md#config-file-examples.managed).

Python 3.11 utilise les `python3` commandes `pip3` et. Pour plus d'informations, consultez l'[exemple d'un fichier de configuration étendu pour Python 3.11](#service-source-code-python.examples.extended-v2) plus loin dans cette rubrique.

**Example apprunner.yaml**  

```
version: 1.0
runtime: python3 
build:
  commands:
    build:
      - pip install pipenv
      - pipenv install 
run: 
  command: python app.py
```

### Fichier de configuration Python étendu
<a name="service-source-code-python.examples.extended"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré par Python.

**Note**  
La version d'exécution utilisée dans ces exemples est*3.7.7*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution de Python prise en charge, consultez[Informations sur la version de Python Runtime](service-source-code-python-releases.md).  
Python 3.11 utilise les `python3` commandes `pip3` et. Pour plus d'informations, consultez l'exemple d'un fichier de configuration étendu pour Python 3.11 plus loin dans cette rubrique.

**Example apprunner.yaml**  

```
version: 1.0
runtime: python3 
build:
  commands:
    pre-build:
      - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz
    build:        
      - pip install pipenv
      - pipenv install
    post-build:
      - python manage.py test
  env:
    - name: DJANGO_SETTINGS_MODULE
      value: "django_apprunner.settings"
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 3.7.7
  command: pipenv run gunicorn django_apprunner.wsgi --log-file -
  network: 
    port: 8000
    env: MY_APP_PORT  
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
  secrets:
    - name: my-secret
      value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::"
    - name: my-parameter
      value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name"
    - name: my-parameter-only-name
      value-from: "parameter-name"
```

### Fichier de configuration Python étendu — Python 3.11 (utilise une version révisée)
<a name="service-source-code-python.examples.extended-v2"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré Python 3.11 dans le`apprunner.yaml`. Cet exemple inclut une `pre-run` section, car cette version de Python utilise la version révisée d'App Runner.

Le `pre-run` paramètre n'est pris en charge que par la version révisée d'App Runner. N'insérez pas ce paramètre dans votre fichier de configuration si votre application utilise des versions d'exécution prises en charge par la version originale d'App Runner. Pour de plus amples informations, veuillez consulter [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

**Note**  
La version d'exécution utilisée dans ces exemples est*3.11*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution de Python prise en charge, consultez[Informations sur la version de Python Runtime](service-source-code-python-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: python311
build:
  commands:
    pre-build:
      - wget -c https://s3.amazonaws.com/amzn-s3-demo-bucket/test-lib.tar.gz -O - | tar -xz
    build:        
      - pip3 install pipenv
      - pipenv install
    post-build:
      - python3 manage.py test
  env:
    - name: DJANGO_SETTINGS_MODULE
      value: "django_apprunner.settings"
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 3.11
  pre-run:  
    - pip3 install pipenv
    - pipenv install
    - python3 copy-global-files.py
  command: pipenv run gunicorn django_apprunner.wsgi --log-file -
  network: 
    port: 8000
    env: MY_APP_PORT  
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
  secrets:
    - name: my-secret
      value-from: "arn:aws:secretsmanager:us-east-1:123456789012:secret:testingstackAppRunnerConstr-kJFXde2ULKbT-S7t8xR:username::"
    - name: my-parameter
      value-from: "arn:aws:ssm:us-east-1:123456789012:parameter/parameter-name"
    - name: my-parameter-only-name
      value-from: "parameter-name"
```

### Source complète de l'application Python
<a name="service-source-code-python.examples.end2end"></a>

Cet exemple montre le code source d'une application Python complète que vous pouvez déployer sur un service d'exécution Python.

**Example requirements.txt**  

```
pyramid==2.0
```

**Example server.py**  

```
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response
import os

def hello_world(request):
    name = os.environ.get('NAME')
    if name == None or len(name) == 0:
        name = "world"
    message = "Hello, " + name + "!\n"
    return Response(message)

if __name__ == '__main__':
    port = int(os.environ.get("PORT"))
    with Configurator() as config:
        config.add_route('hello', '/')
        config.add_view(hello_world, route_name='hello')
        app = config.make_wsgi_app()
    server = make_server('0.0.0.0', port, app)
    server.serve_forever()
```

**Example apprunner.yaml**  

```
version: 1.0
runtime: python3
build:
  commands:
    build:
      - pip install -r requirements.txt
run:
  command: python server.py
```

# Informations sur la version de Python Runtime
<a name="service-source-code-python-releases"></a>

**Important**  
App Runner mettra fin au support de **Python 3.7** et **Python 3.8** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

Cette rubrique répertorie tous les détails des versions d'exécution de Python prises en charge par App Runner.


**Versions d'exécution prises en charge — version révisée d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-python-releases.html)

**Remarques**  
**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 consacrée [Des légendes pour des versions d'exécution spécifiques](service-source-code-python.md#service-source-code-python.callouts) à la *plateforme Python*.
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).


**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-python-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

# Utilisation de la plateforme Node.js
<a name="service-source-code-nodejs"></a>

**Important**  
App Runner mettra fin à la prise en charge de **Node.js 12**, **Node.js 14**, **Node.js 16** et **Node.js 18** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

La plateforme AWS App Runner Node.js fournit des environnements d'exécution gérés. Chaque environnement d'exécution facilite la création et l'exécution de conteneurs avec des applications Web basées sur une version de Node.js. Lorsque vous utilisez un environnement d'exécution Node.js, App Runner démarre avec une image d'exécution Node.js gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution pour une version de Node.js ainsi que certains outils. 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*<language-name><major-version>*. 

Pour connaître les noms et versions d'exécution de Node.js valides, consultez[Informations sur la version d'exécution de Node.js](service-source-code-nodejs-releases.md).

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.

Syntaxe de version pour les environnements d'exécution de Node.js : `major[.minor[.patch]]`

Par exemple : `22.14.0`

Les exemples suivants illustrent le verrouillage des versions :
+ `22.14`— Verrouillez les versions majeures et mineures. App Runner met à jour uniquement les versions de correctif.
+ `22.14.0`— Verrouillez vers une version de correctif spécifique. App Runner ne met pas à jour votre version d'exécution.

**Topics**
+ [Configuration d'exécution de Node.js](#service-source-code-nodejs.config)
+ [Des légendes pour des versions d'exécution spécifiques](#service-source-code-nodejs.callouts)
+ [Exemples d'exécution de Node.js](#service-source-code-nodejs.examples)
+ [Informations sur la version d'exécution de Node.js](service-source-code-nodejs-releases.md)

## Configuration d'exécution de Node.js
<a name="service-source-code-nodejs.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

En ce qui concerne les environnements d'exécution de Node.js en particulier, vous pouvez également configurer le build et le runtime à l'aide d'un fichier JSON nommé `package.json` à la racine de votre référentiel source. À l'aide de ce fichier, vous pouvez configurer la version du moteur Node.js, les packages de dépendances et diverses commandes (applications en ligne de commande). Les gestionnaires de packages tels que npm ou yarn interprètent ce fichier comme entrée pour leurs commandes.

Par exemple :
+ **npm install**installe les packages définis par le `devDependencies` nœud `dependencies` et dans`package.json`.
+ **npm start**ou **npm run start** exécute la commande définie par le `scripts/start` nœud dans`package.json`.

Voici un exemple de fichier `package.json`.

### package.json
<a name="service-source-code-nodejs.config.package-json-example"></a>

```
{
  "name": "node-js-getting-started",
  "version": "0.3.0",
  "description": "A sample Node.js app using Express 4",
  "engines": {
    "node": "22.14.0"
  },
  "scripts": {
    "start": "node index.js",
    "test": "node test.js"
  },
  "dependencies": {
    "cool-ascii-faces": "^1.3.4",
    "ejs": "^2.5.6",
    "express": "^4.15.2"
  },
  "devDependencies": {
    "got": "^11.3.0",
    "tape": "^4.7.0"
  }
}
```

Pour plus d'informations`package.json`, voir [Création d'un fichier package.json sur le](https://docs.npmjs.com/creating-a-package-json-file) site Web de *npm* Docs. 

**Conseils**  
Si votre `package.json` fichier définit une **start** commande, vous pouvez l'utiliser comme **run** commande dans votre fichier de configuration App Runner, comme le montre l'exemple suivant.  

**Example**  
package.json  

  ```
  {
    "scripts": {
      "start": "node index.js"
    }
  }
  ```
apprunner.yaml  

  ```
  run:
    command: npm start
  ```
Lorsque vous exécutez **npm install** dans votre environnement de développement, npm crée le fichier`package-lock.json`. Ce fichier contient un instantané des versions de package que npm vient d'installer. Par la suite, lorsque npm installe des dépendances, il utilise ces versions exactes. Si vous installez le fil, il crée un `yarn.lock` fichier. Enregistrez ces fichiers dans votre référentiel de code source pour vous assurer que votre application est installée avec les versions des dépendances avec lesquelles vous l'avez développée et testée.
Vous pouvez également utiliser un fichier de configuration App Runner pour configurer la version Node.js et la commande de démarrage. Dans ce cas, ces définitions remplacent celles figurant dans`package.json`. Un conflit entre la `node` version `package.json` et la `runtime-version` valeur du fichier de configuration d'App Runner entraîne l'échec de la phase de création d'App Runner.

## Des légendes pour des versions d'exécution spécifiques
<a name="service-source-code-nodejs.callouts"></a>

### Node.js 22 et Node.js 18 (version révisée d'App Runner)
<a name="service-source-code-nodejs.callouts.nodejs18"></a>

App Runner exécute désormais un processus de génération mis à jour pour les applications basé sur les versions d'exécution suivantes : Python 3.11, Node.js 22 et Node.js 18. Si votre application s'exécute sur l'une de ces versions d'exécution, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail) pour plus d'informations sur le processus de génération révisé. Les applications qui utilisent toutes les autres versions d'exécution ne sont pas affectées et continuent à utiliser le processus de génération d'origine. 

## Exemples d'exécution de Node.js
<a name="service-source-code-nodejs.examples"></a>

Les exemples suivants montrent les fichiers de configuration App Runner permettant de créer et d'exécuter un service Node.js. 

**Note**  
La version d'exécution utilisée dans ces exemples est*22.14.0*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour connaître la dernière version d'exécution de Node.js prise en charge, consultez[Informations sur la version d'exécution de Node.js](service-source-code-nodejs-releases.md).

### Fichier de configuration Node.js minimal
<a name="service-source-code-nodejs.examples.minimal"></a>

Cet exemple montre un fichier de configuration minimale que vous pouvez utiliser avec un environnement d'exécution géré par Node.js. Pour les hypothèses formulées par App Runner avec un fichier de configuration minimal, consultez[Exemples de fichiers de configuration](config-file-examples.md#config-file-examples.managed).

**Example apprunner.yaml**  

```
version: 1.0
runtime: nodejs22
build:
  commands:    
    build:
      - npm install --production                                  
run:                              
  command: node app.js
```

### Fichier de configuration Node.js étendu
<a name="service-source-code-nodejs.examples.extended"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré par Node.js.

**Note**  
La version d'exécution utilisée dans ces exemples est*22.14.0*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour connaître la dernière version d'exécution de Node.js prise en charge, consultez[Informations sur la version d'exécution de Node.js](service-source-code-nodejs-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: nodejs22
build:
  commands:
    pre-build:
      - npm install --only=dev
      - node test.js
    build:
      - npm install --production
    post-build:
      - node node_modules/ejs/postinstall.js
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 22.14.0
  command: node app.js
  network:
    port: 8000
    env: APP_PORT
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
```

### Fichier de configuration Node.js étendu — Node.js 22 (utilise la version révisée)
<a name="service-source-code-nodejs.examples.extended-v2"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré par Node.js dans le`apprunner.yaml`. Cet exemple inclut une `pre-run` section, car cette version de Node.js utilise la version révisée d'App Runner.

Le `pre-run` paramètre n'est pris en charge que par la version révisée d'App Runner. N'insérez pas ce paramètre dans votre fichier de configuration si votre application utilise des versions d'exécution prises en charge par la version originale d'App Runner. Pour de plus amples informations, veuillez consulter [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

**Note**  
La version d'exécution utilisée dans ces exemples est*22.14.0*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour connaître la dernière version d'exécution de Node.js prise en charge, consultez[Informations sur la version d'exécution de Node.js](service-source-code-nodejs-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: nodejs22
build:
  commands:
    pre-build:
      - npm install --only=dev
      - node test.js
    build:
      - npm install --production
    post-build:
      - node node_modules/ejs/postinstall.js
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 22.14.0
  pre-run: 
    - node copy-global-files.js
  command: node app.js
  network:
    port: 8000
    env: APP_PORT
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
```

### Application Node.js avec Grunt
<a name="service-source-code-nodejs.examples.grunt"></a>

Cet exemple montre comment configurer une application Node.js développée avec Grunt. [Grunt](https://gruntjs.com/) est un lanceur de JavaScript tâches en ligne de commande. Il exécute des tâches répétitives et gère l'automatisation des processus afin de réduire les erreurs humaines. Les plugins Grunt et Grunt sont installés et gérés à l'aide de npm. Vous configurez Grunt en incluant le `Gruntfile.js` fichier à la racine de votre dépôt source.

**Example package.json**  

```
{
  "scripts": {
    "build": "grunt uglify",
    "start": "node app.js"
  },
  "devDependencies": {
    "grunt": "~0.4.5",
    "grunt-contrib-jshint": "~0.10.0",
    "grunt-contrib-nodeunit": "~0.4.1",
    "grunt-contrib-uglify": "~0.5.0"
  },
  "dependencies": {
    "express": "^4.15.2"
  },
}
```

**Example Gruntfile.js**  

```
module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    uglify: {
      options: {
        banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n'
      },
      build: {
        src: 'src/<%= pkg.name %>.js',
        dest: 'build/<%= pkg.name %>.min.js'
      }
    }
  });

  // Load the plugin that provides the "uglify" task.
  grunt.loadNpmTasks('grunt-contrib-uglify');

  // Default task(s).
  grunt.registerTask('default', ['uglify']);

};
```

**Example apprunner.yaml**  
La version d'exécution utilisée dans ces exemples est*22.14.0*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour connaître la dernière version d'exécution de Node.js prise en charge, consultez[Informations sur la version d'exécution de Node.js](service-source-code-nodejs-releases.md).

```
version: 1.0
runtime: nodejs22
build:
  commands:
    pre-build:
      - npm install grunt grunt-cli
      - npm install --only=dev
      - npm run build
    build:
      - npm install --production
run:
  runtime-version: 22.14.0
  command: node app.js
  network:
    port: 8000
    env: APP_PORT
```

# Informations sur la version d'exécution de Node.js
<a name="service-source-code-nodejs-releases"></a>

**Important**  
App Runner mettra fin à la prise en charge de **Node.js 12**, **Node.js 14**, **Node.js 16** et **Node.js 18** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

**Note**  
La politique d'obsolescence standard d'App Runner consiste à déprécier un environnement d'exécution lorsqu'un composant majeur de celui-ci atteint la fin du support communautaire à long terme (LTS) et que les mises à jour de sécurité ne sont plus disponibles. Dans certains cas, App Runner peut retarder la dépréciation d'un environnement d'exécution pendant une période limitée, au-delà de la end-of-support date de publication de la version linguistique prise en charge par le moteur d'exécution. Un exemple d'un tel cas pourrait être l'extension du support pour un environnement d'exécution afin de laisser aux clients le temps de migrer.

Cette rubrique répertorie tous les détails des versions d'exécution de Node.js prises en charge par App Runner.


**Versions d'exécution prises en charge — version révisée d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-nodejs-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).


**Versions d'exécution prises en charge — version révisée d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-nodejs-releases.html)




**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-nodejs-releases.html)

# Utilisation de la plateforme Java
<a name="service-source-code-java"></a>

La plate-forme AWS App Runner Java fournit des environnements d'exécution gérés. Chaque environnement d'exécution facilite la création et l'exécution de conteneurs avec des applications Web basées sur une version Java. Lorsque vous utilisez un environnement d'exécution Java, App Runner démarre avec une image d'exécution Java gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution pour une version de Java et certains outils. 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*<language-name><major-version>*. 

À l'heure actuelle, tous les environnements d'exécution Java pris en charge sont basés sur Amazon Corretto. Pour les noms et versions d'exécution Java valides, consultez[Informations sur la version de Java Runtime](service-source-code-java-releases.md).

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.

Syntaxe de version pour les environnements d'exécution Amazon Corretto :


| **Exécution** | **Syntaxe** | **Exemple** | 
| --- | --- | --- | 
|  corretto11  |  `11.0[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]`  |  `11.0.13.08.1`  | 
|  corretto8  |  `8[.openjdk-update[.openjdk-build[.corretto-specific-revision]]]`  |  `8.312.07.1`  | 

Les exemples suivants illustrent le verrouillage des versions :
+ `11.0.13`— Verrouillez la version de mise à jour d'Open JDK. App Runner met à jour uniquement les versions de niveau inférieur d'Open JDK et d'Amazon Corretto.
+ `11.0.13.08.1`— Verrouillez vers une version spécifique. App Runner ne met pas à jour votre version d'exécution.

**Topics**
+ [Configuration de l'environnement d'exécution Java](#service-source-code-java.config)
+ [Exemples d'exécution Java](#service-source-code-java.examples)
+ [Informations sur la version de Java Runtime](service-source-code-java-releases.md)

## Configuration de l'environnement d'exécution Java
<a name="service-source-code-java.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

## Exemples d'exécution Java
<a name="service-source-code-java.examples"></a>

Les exemples suivants présentent les fichiers de configuration App Runner permettant de créer et d'exécuter un service Java. Le dernier exemple est le code source d'une application Java complète que vous pouvez déployer sur un service d'exécution Corretto 11.

**Note**  
La version d'exécution utilisée dans ces exemples est*11.0.13.08.1*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution Java prise en charge, voir[Informations sur la version de Java Runtime](service-source-code-java-releases.md).

### Fichier de configuration Minimal Corretto 11
<a name="service-source-code-java.examples.minimal"></a>

Cet exemple montre un fichier de configuration minimal que vous pouvez utiliser avec un environnement d'exécution géré par Corretto 11. Pour les hypothèses formulées par App Runner avec un fichier de configuration minimal, consultez.

**Example apprunner.yaml**  

```
version: 1.0
runtime: corretto11
build:
  commands:    
    build:
      - mvn clean package
run:                              
  command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar .
```

### Fichier de configuration étendu de Corretto 11
<a name="service-source-code-java.examples.extended"></a>

Cet exemple montre comment utiliser toutes les clés de configuration avec un environnement d'exécution géré par Corretto 11.

**Note**  
La version d'exécution utilisée dans ces exemples est*11.0.13.08.1*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution Java prise en charge, voir[Informations sur la version de Java Runtime](service-source-code-java-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: corretto11
build:
  commands:
    pre-build:
      - yum install some-package
      - scripts/prebuild.sh
    build:
      - mvn clean package
    post-build:
      - mvn clean test
  env:
    - name: M2
      value: "/usr/local/apache-maven/bin"
    - name: M2_HOME
      value: "/usr/local/apache-maven/bin"
run:
  runtime-version: 11.0.13.08.1
  command: java -Xms256m -jar target/MyApp-1.0-SNAPSHOT.jar .
  network:
    port: 8000
    env: APP_PORT
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
```

### Source complète de l'application Corretto 11
<a name="service-source-code-java.examples.end2end"></a>

Cet exemple montre le code source d'une application Java complète que vous pouvez déployer sur un service d'exécution Corretto 11.

**Example src/main/java/com/HelloWorld/HelloWorld.java**  

```
package com.HelloWorld;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloWorld {

    @RequestMapping("/")
    public String index(){
        String s = "Hello World";
        return s;
    }
}
```

**Example src/main/java/com/HelloWorld/Main.java**  

```
package com.HelloWorld;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Main {

    public static void main(String[] args) {

        SpringApplication.run(Main.class, args);
    }
}
```

**Example apprunner.yaml**  

```
version: 1.0
runtime: corretto11
build:
  commands:    
    build:
      - mvn clean package
run:                              
  command: java -Xms256m -jar target/HelloWorldJavaApp-1.0-SNAPSHOT.jar .
  network:
    port: 8080
```

**Example pom.xml**  

```
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.3.1.RELEASE</version>
    <relativePath/>
  </parent>
  <groupId>com.HelloWorld</groupId>
  <artifactId>HelloWorldJavaApp</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <java.version>11</java.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-rest</artifactId>
    </dependency>

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
      <scope>test</scope>
      <exclusions>
        <exclusion>
          <groupId>org.junit.vintage</groupId>
          <artifactId>junit-vintage-engine</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.0</version>
        <configuration>
          <release>11</release>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>
```

# Informations sur la version de Java Runtime
<a name="service-source-code-java-releases"></a>

Cette rubrique répertorie tous les détails des versions d'exécution Java prises en charge par App Runner.


**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-java-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

# Utilisation de la plateforme .NET
<a name="service-source-code-net6"></a>

**Important**  
App Runner mettra fin au support de **.NET 6** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

La plate-forme AWS App Runner .NET fournit des environnements d'exécution gérés. Chaque environnement d'exécution facilite la création et l'exécution de conteneurs avec des applications Web basées sur une version .NET. Lorsque vous utilisez un environnement d'exécution .NET, App Runner démarre avec une image d'exécution .NET gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution d'une version de .NET ainsi que certains outils et 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*<language-name><major-version>*. 

Pour connaître les noms et versions d'environnement d'exécution .NET valides, consultez[Informations sur la version de .NET Runtime](service-source-code-dotnet-releases.md).

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.

Syntaxe de version pour les environnements d'exécution .NET : `major[.minor[.patch]]`

Par exemple : `6.0.9`

Les exemples suivants illustrent le verrouillage des versions :
+ `6.0`— Verrouillez les versions majeures et mineures. App Runner met à jour uniquement les versions de correctif.
+ `6.0.9`— Verrouillez vers une version de correctif spécifique. App Runner ne met pas à jour votre version d'exécution.

**Topics**
+ [Configuration de l'environnement d'exécution .NET](#service-source-code-net6.config)
+ [Exemples d'exécution .NET](#service-source-code-net6.examples)
+ [Informations sur la version de .NET Runtime](service-source-code-dotnet-releases.md)

## Configuration de l'environnement d'exécution .NET
<a name="service-source-code-net6.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

## Exemples d'exécution .NET
<a name="service-source-code-net6.examples"></a>

Les exemples suivants présentent les fichiers de configuration App Runner permettant de créer et d'exécuter un service .NET. Le dernier exemple est le code source d'une application .NET complète que vous pouvez déployer sur un service d'exécution .NET.

**Note**  
La version d'exécution utilisée dans ces exemples est*6.0.9*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour connaître la dernière version d'exécution .NET prise en charge, consultez[Informations sur la version de .NET Runtime](service-source-code-dotnet-releases.md).

### Fichier de configuration .NET minimal
<a name="service-source-code-net6.examples.minimal"></a>

Cet exemple montre un fichier de configuration minimal que vous pouvez utiliser avec un environnement d'exécution géré .NET. Pour les hypothèses formulées par App Runner avec un fichier de configuration minimal, consultez[Exemples de fichiers de configuration](config-file-examples.md#config-file-examples.managed).

**Example apprunner.yaml**  

```
version: 1.0
runtime: dotnet6
build:
  commands:    
    build:
      - dotnet publish -c Release -o out
run:                              
  command: dotnet out/HelloWorldDotNetApp.dll
```

### Fichier de configuration .NET étendu
<a name="service-source-code-net6.examples.extended"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré par .NET.

**Note**  
La version d'exécution utilisée dans ces exemples est*6.0.9*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour connaître la dernière version d'exécution .NET prise en charge, consultez[Informations sur la version de .NET Runtime](service-source-code-dotnet-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: dotnet6
build:
  commands:
    pre-build:
      - scripts/prebuild.sh
    build:
      - dotnet publish -c Release -o out
    post-build:
      - scripts/postbuild.sh
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"    
run:
  runtime-version: 6.0.9
  command: dotnet out/HelloWorldDotNetApp.dll
  network:
    port: 5000
    env: APP_PORT
  env:
    - name: ASPNETCORE_URLS
      value: "http://*:5000"
```

### Source d'application .NET complète
<a name="service-source-code-net6.examples.end2end"></a>

Cet exemple montre le code source d'une application .NET complète que vous pouvez déployer sur un service d'exécution .NET.

**Note**  
 Exécutez la commande suivante pour créer une application Web .NET 6 simple : ` dotnet new web --name HelloWorldDotNetApp -f net6.0`
 Ajoutez le `apprunner.yaml` à l'application Web .NET 6 créée. 

**Example HelloWorldDotNetApp**  

```
version: 1.0
runtime: dotnet6
build:
  commands:
    build:
      - dotnet publish -c Release -o out
run:
  command: dotnet out/HelloWorldDotNetApp.dll
  network:
    port: 5000
    env: APP_PORT
  env:
    - name: ASPNETCORE_URLS
      value: "http://*:5000"
```

# Informations sur la version de .NET Runtime
<a name="service-source-code-dotnet-releases"></a>

**Important**  
App Runner mettra fin au support de **.NET 6** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

Cette rubrique fournit des informations complètes sur les versions d'exécution .NET prises en charge par App Runner.


**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-dotnet-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

# À l'aide de la plateforme PHP
<a name="service-source-code-php"></a>

**Important**  
App Runner mettra fin au support de **PHP 8.1** le 31 décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

La plateforme AWS App Runner PHP fournit des environnements d'exécution gérés. Vous pouvez utiliser chaque environnement d'exécution pour créer et exécuter des conteneurs avec des applications Web basées sur une version de PHP. Lorsque vous utilisez un environnement d'exécution PHP, App Runner démarre avec une image d'exécution PHP gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution pour une version de PHP et certains outils. 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*<language-name><major-version>*. 

Pour les noms et versions d'exécution PHP valides, consultez[Informations sur la version d'exécution de PHP](service-source-code-php-releases.md).

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.

Syntaxe de version pour les environnements d'exécution PHP : `major[.minor[.patch]]`

Par exemple : `8.1.10`

Voici des exemples de verrouillage de version :
+ `8.1`— Verrouillez les versions majeures et mineures. App Runner met à jour uniquement les versions de correctif.
+ `8.1.10`— Verrouillez vers une version de correctif spécifique. App Runner ne met pas à jour votre version d'exécution.

**Important**  
 Si vous souhaitez spécifier le [répertoire source](service-source-code.md#service-source-code.source-directory) du référentiel de code pour votre service App Runner dans un emplacement autre que le répertoire racine du dépôt par défaut, votre version d'exécution gérée de PHP doit être PHP `8.1.22` ou une version ultérieure. Les versions d'exécution de PHP antérieures ne `8.1.22` peuvent utiliser que le répertoire source racine par défaut. 

**Topics**
+ [Configuration de l'environnement d'exécution PHP](#service-source-code-php.config)
+ [Compatibilité](#service-source-code-php.compatibility)
+ [Exemples d'exécution PHP](#service-source-code-php.examples)
+ [Informations sur la version d'exécution de PHP](service-source-code-php-releases.md)

## Configuration de l'environnement d'exécution PHP
<a name="service-source-code-php.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

## Compatibilité
<a name="service-source-code-php.compatibility"></a>

Vous pouvez exécuter vos services App Runner sur la plateforme PHP en utilisant l'un des serveurs Web suivants : 
+ Apache HTTP Server
+ NGINX

Apache HTTP Serveret NGINX sont compatibles avec PHP-FPM. Vous pouvez démarrer *Apache HTTP Server*et *NGINX*en utilisant l'une des méthodes suivantes :
+ [Supervisord](http://supervisord.org/introduction.html#supervisor-components/) - Pour plus d'informations sur l'exécution d'un superviseur *supervisord*, consultez [Exécuter un superviseur](http://supervisord.org/running.html#running-supervisord). 
+ Script de démarrage 

Pour des exemples sur la façon de configurer votre service App Runner avec la plate-forme PHP à l'aide *du serveur HTTP Apache* ou de *NGINX, consultez*. [Source complète de l'application PHP](#service-source-code-php.examples.end2end) 

### Structure de fichier
<a name="service-source-code-php.compatibility.file-structure"></a>

`index.php`Il doit être installé dans le `public` dossier situé sous le `root` répertoire du serveur Web. 

**Note**  
Nous recommandons de stocker `supervisord.conf` les fichiers `startup.sh` or dans le répertoire racine du serveur Web. Assurez-vous que la `start` commande pointe vers l'emplacement où les `supervisord.conf` fichiers `startup.sh` ou sont stockés.

 Voici un exemple de structure de fichier que vous utilisez *supervisord*. 

```
/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```

Voici un exemple de structure de fichier si vous utilisez un *script de démarrage*.

```
/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```

Nous vous recommandons de stocker ces structures de fichiers dans le [répertoire source](service-source-code.md#service-source-code.source-directory) du référentiel de code désigné pour le service App Runner.

```
/<sourceDirectory>/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```

**Important**  
 Si vous souhaitez spécifier le [répertoire source](service-source-code.md#service-source-code.source-directory) du référentiel de code pour votre service App Runner dans un emplacement autre que le répertoire racine du dépôt par défaut, votre version d'exécution gérée de PHP doit être PHP `8.1.22` ou une version ultérieure. Les versions d'exécution de PHP antérieures ne `8.1.22` peuvent utiliser que le répertoire source racine par défaut.   
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. Votre service utilisera les environnements d'exécution les plus récents par défaut, sauf si vous avez spécifié le verrouillage de version à l'aide du `runtime-version` mot clé dans le [fichier de configuration d'App Runner](config-file.md).

## Exemples d'exécution PHP
<a name="service-source-code-php.examples"></a>

Voici des exemples de fichiers de configuration App Runner utilisés pour créer et exécuter un service PHP. 

### Fichier de configuration PHP minimal
<a name="service-source-code-php.examples.minimal"></a>

L'exemple suivant est un fichier de configuration minimale que vous pouvez utiliser avec un environnement d'exécution géré en PHP. Pour plus d'informations sur un fichier de configuration minimale, consultez[Exemples de fichiers de configuration](config-file-examples.md#config-file-examples.managed).

**Example apprunner.yaml**  

```
version: 1.0 
runtime: php81
build:
  commands:
    build:
      - echo example build command for PHP
run:
  command: ./startup.sh
```

### Fichier de configuration PHP étendu
<a name="service-source-code-php.examples.extended"></a>

L'exemple suivant utilise toutes les clés de configuration avec un environnement d'exécution géré par PHP.

**Note**  
La version d'exécution utilisée dans ces exemples est*8.1.10*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution de PHP prise en charge, voir[Informations sur la version d'exécution de PHP](service-source-code-php-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: php81
build:
  commands:
     pre-build:
      - scripts/prebuild.sh
    build:
      - echo example build command for PHP
    post-build:
      - scripts/postbuild.sh
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 8.1.10
  command: ./startup.sh
  network:
    port: 5000
    env: APP_PORT
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
```

### Source complète de l'application PHP
<a name="service-source-code-php.examples.end2end"></a>

Les exemples suivants concernent le code source d'une application PHP que vous pouvez utiliser pour déployer sur un service d'exécution PHP à l'aide de *Apache HTTP Server*ou *NGINX*. Ces exemples supposent que vous utilisez la structure de fichier par défaut.

#### Exécution de la plate-forme PHP en Apache HTTP Server utilisant supervisord
<a name="service-source-code-php.examples.end2end.appache-supervisord"></a>

**Example Structure de fichier**  
+ Le `supervisord.conf` fichier peut être stocké n'importe où dans le référentiel. Assurez-vous que la `start` commande pointe vers l'endroit où le `supervisord.conf` fichier est stocké.
+ `index.php`Il doit être installé dans le `public` dossier situé sous le `root` répertoire.

```
/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```

**Example supervisord.conf**  

```
[supervisord]
nodaemon=true

[program:httpd]
command=httpd -DFOREGROUND
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[program:php-fpm]
command=php-fpm -F
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
```

**Example apprunner.yaml**  

```
version: 1.0
runtime: php81
build:
  commands:
    build:
      - PYTHON=python2 amazon-linux-extras install epel
      - yum -y install supervisor
run:
  command: supervisord
  network:
    port: 8080
    env: APP_PORT
```

**Example index.php**  

```
<html>
<head> <title>First PHP App</title> </head>
<body>
<?php
    print("Hello World!");
    print("<br>");
?>
</body>
</html>
```

#### Exécution de la plate-forme PHP en Apache HTTP Server utilisant startup script
<a name="service-source-code-php.examples.end2end.appache-startupscript"></a>

**Example Structure de fichier**  
+ Le `startup.sh` fichier peut être stocké n'importe où dans le référentiel. Assurez-vous que la `start` commande pointe vers l'endroit où le `startup.sh` fichier est stocké.
+ `index.php`Il doit être installé dans le `public` dossier situé sous le `root` répertoire.

```
/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```

**Example startup.sh**  

```
#!/bin/bash

set -o monitor

trap exit SIGCHLD

# Start apache
httpd -DFOREGROUND &

# Start php-fpm
php-fpm -F &

wait
```

**Note**  
Assurez-vous d'enregistrer le `startup.sh` fichier en tant qu'exécutable avant de le valider dans un dépôt Git. `chmod +x startup.sh`À utiliser pour définir l'autorisation d'exécution sur votre `startup.sh` fichier. 
Si vous n'enregistrez pas le `startup.sh` fichier en tant qu'exécutable, entrez `chmod +x startup.sh` la `build` commande dans votre `apprunner.yaml` fichier. 

**Example apprunner.yaml**  

```
version: 1.0
runtime: php81
build:
  commands:
    build:
      - echo example build command for PHP
run:
  command: ./startup.sh
  network:
    port: 8080
    env: APP_PORT
```

**Example index.php**  

```
<html>
<head> <title>First PHP App</title> </head>
<body>
<?php
    print("Hello World!");
    print("<br>");
?>
</body>
</html>
```

#### Exécution de la plate-forme PHP en NGINX utilisant supervisord
<a name="service-source-code-php.examples.end2end.nginx-supervisord"></a>

**Example Structure de fichier**  
+ Le `supervisord.conf` fichier peut être stocké n'importe où dans le référentiel. Assurez-vous que la `start` commande pointe vers l'endroit où le `supervisord.conf` fichier est stocké.
+ `index.php`Il doit être installé dans le `public` dossier situé sous le `root` répertoire.

```
/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ supervisord.conf
```

**Example supervisord.conf**  

```
[supervisord]
nodaemon=true

[program:nginx]
command=nginx -g "daemon off;"
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[program:php-fpm]
command=php-fpm -F
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0
```

**Example apprunner.yaml**  

```
version: 1.0
runtime: php81
build:
  commands:
    build:
      - PYTHON=python2 amazon-linux-extras install epel
      - yum -y install supervisor
run:
  command: supervisord
  network:
    port: 8080
    env: APP_PORT
```

**Example index.php**  

```
<html>
<head> <title>First PHP App</title> </head>
<body>
<?php
    print("Hello World!");
    print("<br>");
?>
</body>
</html>
```

#### Exécution de la plate-forme PHP en NGINX utilisant startup script
<a name="service-source-code-php.examples.end2end.nginx-startupscript"></a>

**Example Structure de fichier**  
+ Le `startup.sh` fichier peut être stocké n'importe où dans le référentiel. Assurez-vous que la `start` commande pointe vers l'endroit où le `startup.sh` fichier est stocké. 
+ `index.php`Il doit être installé dans le `public` dossier situé sous le `root` répertoire.

```
/
├─ public/
│  ├─ index.php
├─ apprunner.yaml
├─ startup.sh
```

**Example startup.sh**  

```
#!/bin/bash

set -o monitor

trap exit SIGCHLD

# Start nginx 
nginx -g 'daemon off;' &

# Start php-fpm
php-fpm -F &

wait
```

**Note**  
Assurez-vous d'enregistrer le `startup.sh` fichier en tant qu'exécutable avant de le valider dans un dépôt Git. `chmod +x startup.sh`À utiliser pour définir l'autorisation d'exécution sur votre `startup.sh` fichier. 
Si vous n'enregistrez pas le `startup.sh` fichier en tant qu'exécutable, entrez `chmod +x startup.sh` la `build` commande dans votre `apprunner.yaml` fichier. 

**Example apprunner.yaml**  

```
version: 1.0
runtime: php81
build:
  commands:
    build:
      - echo example build command for PHP
run:
  command: ./startup.sh
  network:
    port: 8080
    env: APP_PORT
```

**Example index.php**  

```
<html>
<head> <title>First PHP App</title> </head>
<body>
<?php
    print("Hello World!");
    print("<br>");
?>
</body>
</html>
```

# Informations sur la version d'exécution de PHP
<a name="service-source-code-php-releases"></a>

**Important**  
App Runner mettra fin au support de **PHP 8.1** le 31 décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

Cette rubrique répertorie tous les détails des versions d'exécution de PHP prises en charge par App Runner.


**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-php-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

# Utilisation de la plateforme Ruby
<a name="service-source-code-ruby"></a>

**Important**  
App Runner mettra fin au support de **Ruby 3.1** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

La plateforme AWS App Runner Ruby fournit des environnements d'exécution gérés. Chaque environnement d'exécution facilite la création et l'exécution de conteneurs avec des applications Web basées sur une version Ruby. Lorsque vous utilisez un environnement d'exécution Ruby, App Runner démarre avec une image d'exécution Ruby gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution pour une version de Ruby et certains outils. 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*<language-name><major-version>*. 

Pour les noms et versions d'exécution Ruby valides, consultez[Informations sur la version de Ruby Runtime](service-source-code-ruby-releases.md).

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.

Syntaxe de version pour les environnements d'exécution Ruby : `major[.minor[.patch]]`

Par exemple : `3.1.2`

Les exemples suivants illustrent le verrouillage des versions :
+ `3.1`— Verrouillez les versions majeures et mineures. App Runner met à jour uniquement les versions de correctif.
+ `3.1.2`— Verrouillez vers une version de correctif spécifique. App Runner ne met pas à jour votre version d'exécution.

**Topics**
+ [Configuration du runtime Ruby](#service-source-code-ruby.config)
+ [Exemples d'exécution Ruby](#service-source-code-ruby.examples)
+ [Informations sur la version de Ruby Runtime](service-source-code-ruby-releases.md)

## Configuration du runtime Ruby
<a name="service-source-code-ruby.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

## Exemples d'exécution Ruby
<a name="service-source-code-ruby.examples"></a>

Les exemples suivants montrent les fichiers de configuration d'App Runner permettant de créer et d'exécuter un service Ruby. 

### Fichier de configuration Ruby minimal
<a name="service-source-code-ruby.examples.minimal"></a>

Cet exemple montre un fichier de configuration minimal que vous pouvez utiliser avec un environnement d'exécution géré par Ruby. Pour les hypothèses formulées par App Runner avec un fichier de configuration minimal, consultez[Exemples de fichiers de configuration](config-file-examples.md#config-file-examples.managed).

**Example apprunner.yaml**  

```
version: 1.0
runtime: ruby31
build:
  commands:
    build:
      - bundle install
run:
  command: bundle exec rackup --host 0.0.0.0 -p 8080
```

### Fichier de configuration Ruby étendu
<a name="service-source-code-ruby.examples.extended"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré par Ruby.

**Note**  
La version d'exécution utilisée dans ces exemples est*3.1.2*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution de Ruby prise en charge, voir[Informations sur la version de Ruby Runtime](service-source-code-ruby-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: ruby31
build:
  commands:
     pre-build:
      - scripts/prebuild.sh
    build:
      - bundle install
    post-build:
      - scripts/postbuild.sh
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 3.1.2
  command: bundle exec rackup --host 0.0.0.0 -p 4567
  network:
    port: 4567
    env: APP_PORT
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
```

### Source complète de l'application Ruby
<a name="service-source-code-ruby.examples.end2end"></a>

Ces exemples montrent le code source d'une application Ruby complète que vous pouvez déployer sur un service d'exécution Ruby.

**Example serveur.rb**  

```
# server.rb
require 'sinatra'

get '/' do    
  'Hello World!'
end
```

**Example config.ru**  

```
# config.ru

require './server'

run Sinatra::Application
```

**Example Gemfile**  

```
# Gemfile
source 'https://rubygems.org (https://rubygems.org/)'

gem 'sinatra'
gem 'puma'
```

**Example apprunner.yaml**  

```
version: 1.0
runtime: ruby31
build:
  commands:
    build:
      - bundle install
run:
  command: bundle exec rackup --host 0.0.0.0 -p 4567
  network:
    port: 4567
    env: APP_PORT
```

# Informations sur la version de Ruby Runtime
<a name="service-source-code-ruby-releases"></a>

**Important**  
App Runner mettra fin au support de **Ruby 3.1** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

Cette rubrique répertorie tous les détails des versions d'exécution de Ruby prises en charge par App Runner.


**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-ruby-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).

# Utilisation de la plateforme Go
<a name="service-source-code-go1"></a>

**Important**  
App Runner mettra fin au support de **Go 1.18** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

La plateforme AWS App Runner Go fournit des environnements d'exécution gérés. Chaque environnement d'exécution facilite la création et l'exécution de conteneurs avec des applications Web basées sur une version Go. Lorsque vous utilisez un environnement d'exécution Go, App Runner démarre avec une image d'exécution Go gérée. Cette image est basée sur l'[image Docker d'Amazon Linux](https://hub.docker.com/_/amazonlinux) et contient le package d'exécution pour une version de Go ainsi que certains outils. 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*<language-name><major-version>*. 

Pour les noms et versions d'exécution Go valides, consultez[Informations sur les versions de Go Runtime](service-source-code-go-releases.md).

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.

Syntaxe de version pour les environnements d'exécution Go : `major[.minor[.patch]]`

Par exemple : `1.18.7`

Les exemples suivants illustrent le verrouillage des versions :
+ `1.18`— Verrouillez les versions majeures et mineures. App Runner met à jour uniquement les versions de correctif.
+ `1.18.7`— Verrouillez vers une version de correctif spécifique. App Runner ne met pas à jour votre version d'exécution.

**Topics**
+ [Configuration de l'environnement d'exécution Go](#service-source-code-go1.config)
+ [Exemples d'exécution Go](#service-source-code-go1.examples)
+ [Informations sur les versions de Go Runtime](service-source-code-go-releases.md)

## Configuration de l'environnement d'exécution Go
<a name="service-source-code-go1.config"></a>

Lorsque vous choisissez un environnement d'exécution géré, vous devez également configurer, au minimum, créer et exécuter des commandes. Vous les configurez lors de [la création](manage-create.md) ou de la [mise à jour](manage-configure.md) de votre service App Runner. Pour ce faire, vous pouvez utiliser l'une des méthodes suivantes :
+ **Utilisation de la console App Runner** : spécifiez les commandes dans la section **Configurer le build** de l'onglet Processus de création ou configuration.
+ **Utilisation de l'API App Runner** : appelez l'opération [CreateService](https://docs.aws.amazon.com/apprunner/latest/api/API_CreateService.html)ou [UpdateService](https://docs.aws.amazon.com/apprunner/latest/api/API_UpdateService.html)API. Spécifiez les commandes à l'aide des `StartCommand` membres `BuildCommand` et du type de [CodeConfigurationValues](https://docs.aws.amazon.com/apprunner/latest/api/API_CodeConfigurationValues.html)données.
+ **Utilisation d'un [fichier de configuration](config-file.md)** : spécifiez une ou plusieurs commandes de génération en trois phases de génération au maximum, ainsi qu'une seule commande d'exécution servant à démarrer votre application. Il existe d'autres paramètres de configuration facultatifs.

La fourniture d'un fichier de configuration est facultative. Lorsque vous créez un service App Runner à l'aide de la console ou de l'API, vous spécifiez si App Runner obtient vos paramètres de configuration directement lors de sa création ou à partir d'un fichier de configuration.

## Exemples d'exécution Go
<a name="service-source-code-go1.examples"></a>

Les exemples suivants montrent les fichiers de configuration App Runner permettant de créer et d'exécuter un service Go. 

### Fichier de configuration Minimal Go
<a name="service-source-code-go1.examples.minimal"></a>

Cet exemple montre un fichier de configuration minimal que vous pouvez utiliser avec un environnement d'exécution géré par Go. Pour les hypothèses formulées par App Runner avec un fichier de configuration minimal, consultez[Exemples de fichiers de configuration](config-file-examples.md#config-file-examples.managed).

**Example apprunner.yaml**  

```
version: 1.0
runtime: go1
build:
  commands:
    build:
      - go build main.go
run:
  command: ./main
```

### Fichier de configuration Extended Go
<a name="service-source-code-go1.examples.extended"></a>

Cet exemple montre l'utilisation de toutes les clés de configuration avec un environnement d'exécution géré par Go.

**Note**  
La version d'exécution utilisée dans ces exemples est*1.18.7*. Vous pouvez le remplacer par la version que vous souhaitez utiliser. Pour la dernière version d'exécution Go prise en charge, voir[Informations sur les versions de Go Runtime](service-source-code-go-releases.md).

**Example apprunner.yaml**  

```
version: 1.0
runtime: go1
build:
  commands:
     pre-build:
      - scripts/prebuild.sh
    build:
      - go build main.go
    post-build:
      - scripts/postbuild.sh
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
run:
  runtime-version: 1.18.7
  command: ./main
  network:
    port: 3000
    env: APP_PORT
  env:
    - name: MY_VAR_EXAMPLE
      value: "example"
```

### Source complète de l'application Go
<a name="service-source-code-go1.examples.end2end"></a>

Ces exemples montrent le code source d'une application Go complète que vous pouvez déployer sur un service d'exécution Go.

**Example main.go**  

```
package main
import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprint(w, "<h1>Welcome to App Runner</h1>")
    })
    fmt.Println("Starting the server on :3000...")
    http.ListenAndServe(":3000", nil)
}
```

**Example apprunner.yaml**  

```
version: 1.0
runtime: go1
build:
  commands:
    build:
      - go build main.go
run:
  command: ./main
  network:
    port: 3000
    env: APP_PORT
```

# Informations sur les versions de Go Runtime
<a name="service-source-code-go-releases"></a>

**Important**  
App Runner mettra fin au support de **Go 1.18** le 1er décembre 2025. Pour des recommandations et de plus amples informations, consultez[Fin du support pour les versions d'exécution gérées](service-source-code.md#service-source-code.managed-platforms.eos).

Cette rubrique répertorie tous les détails des versions d'exécution Go prises en charge par App Runner.


**Versions d'exécution prises en charge : version originale d'App Runner**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/apprunner/latest/dg/service-source-code-go-releases.html)

**Note**  
App Runner fournit un processus de compilation révisé pour des environnements d'exécution majeurs spécifiques qui ont été publiés plus récemment. Pour cette raison, vous verrez des références à la *version révisée d'App Runner et à la version* *originale d'App Runner* dans certaines sections de ce document. Pour plus d'informations, consultez [Versions d'exécution gérées et build d'App Runner](service-source-code.md#service-source-code.build-detail).