Service App Runner basé sur le code source

Vous pouvez l'utiliser AWS App Runner pour créer et gérer des services basés sur deux types de source de service fondamentalement différents : le code source et l'image source. Quel que soit le type de source, App Runner se charge du démarrage, de l'exécution, de la mise à l'échelle et de l'équilibrage de charge de votre service. Vous pouvez utiliser la fonctionnalité CI/CD 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, consultezService App Runner basé sur une image source.

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 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.

Rubriques

• Fournisseurs de référentiels de code source
• Répertoire des sources
• Plateformes gérées par App Runner
• Versions d'exécution gérées et build d'App Runner
• Utilisation de la plateforme Python
• Utilisation de la plateforme Node.js
• Utilisation de la plateforme Java
• Utilisation de la plateforme .NET
• À l'aide de la plateforme PHP
• Utilisation de la plateforme Ruby
• Utilisation de la plateforme Go

Fournisseurs de référentiels de code source

App Runner déploie votre code source en le lisant depuis un dépôt de code source. App Runner prend en charge deux fournisseurs de référentiels de code source : GitHubet Bitbucket.

Déploiement depuis votre fournisseur de référentiel de code source

Pour déployer votre code source sur un service App Runner à partir d'un référentiel de code source, App Runner établit une connexion avec celui-ci. Lorsque vous utilisez la console App Runner pour créer un service, 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 CreateConnectionAPI. Vous devez ensuite fournir l'ARN de la connexion lors de la création du service à l'aide de l'action CreateServiceAPI.

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 CreateServiceet UpdateServiceAPI. Pour plus d'informations, consultez Répertoire des sourcesla section suivante.

Pour plus d'informations sur la création du service App Runner, consultezCréation d'un service App Runner. Pour plus d'informations sur les connexions App Runner, consultezGestion des connexions App Runner.

Répertoire des sources

Lorsque vous créez un service App Runner, vous pouvez fournir le répertoire source, ainsi que le référentiel et la branche. Définissez la valeur du champ Répertoire source sur le chemin du répertoire du référentiel qui stocke le code source et les fichiers de configuration de l'application. App Runner exécute les commandes de construction et de démarrage à partir du chemin du répertoire source que vous avez indiqué.

Entrez la valeur absolue du chemin du répertoire source à partir du répertoire du référentiel racine. Si vous ne spécifiez aucune valeur, il s'agit par défaut du répertoire de premier niveau du référentiel, également appelé répertoire racine du référentiel.

Vous avez également la possibilité de fournir différents chemins de répertoire source en plus du répertoire de référentiel de niveau supérieur. Cela prend en charge une architecture de référentiel monorepo, ce qui signifie que le code source de plusieurs applications est stocké dans un seul référentiel. Pour créer et prendre en charge plusieurs services App Runner à partir d'un seul monorepo, spécifiez différents répertoires sources lors de la création de chaque service.

Note

Si vous spécifiez le même répertoire source pour plusieurs services App Runner, les deux services seront déployés et fonctionneront individuellement.

Si vous choisissez d'utiliser un fichier apprunner.yaml de configuration pour définir les paramètres de votre service, placez-le dans le dossier du répertoire source du référentiel.

Si l'option Déclencheur de déploiement est définie sur Automatique, les modifications que vous validez dans le répertoire source déclencheront un déploiement automatique. Seules les modifications apportées au chemin du répertoire source déclencheront un déploiement automatique. Il est important de comprendre comment l'emplacement du répertoire source influe sur l'étendue d'un déploiement automatique. Pour plus d'informations, consultez la section Déploiements automatisés dansMéthodes de déploiement.

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 plus d’informations, consultez À l'aide de la plateforme PHP .

Plateformes gérées par App Runner

Les plateformes gérées par App Runner fournissent des environnements d'exécution gérés pour différents environnements de programmation. Chaque environnement d'exécution géré facilite la création et l'exécution de conteneurs basés sur une version d'un langage de programmation ou d'un environnement d'exécution. Lorsque vous utilisez un environnement d'exécution géré, App Runner démarre avec une image d'exécution géré. Cette image est basée sur l'image Docker d'Amazon Linux 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 à l'aide de la console App Runner ou de l'opération CreateServiceAPI. 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 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. 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.

Versions d'exécution gérées et build d'App Runner

App Runner propose désormais un processus de création actualisé pour vos applications. Il invoque actuellement la nouvelle version pour les services qui s'exécutent sur les environnements d'exécution gérés Python 3.11 et Node.js 18, publiée pour la dernière fois le 29 décembre 2023. 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-runparamè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.

Plateforme	Construction originale	Version révisée
Python – Informations sur la publication	Python 3.8 Python 3.7	Python 3.11 (!)
Node.js – Informations sur la publication	Node.js 16 Node.js 14 Node.js 12	Node.js 18
Corretto — Informations sur la publication	Corretto Corretto 8
.NET – Informations sur la publication	.NET 6
PHP – Informations sur la publication	PHP 8.1
Ruby – Informations sur la publication	Ruby 3.1
Go – Informations sur la publication	Go 1

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 à la plateforme Python.

En savoir plus sur les versions et la migration d'App Runner

Lorsque vous migrez votre application vers un environnement d'exécution plus récent qui utilise la version révisée, vous devrez peut-être modifier légèrement la configuration de votre version.

Pour fournir un contexte aux considérations relatives à la migration, nous allons d'abord décrire les processus de haut niveau pour la version originale d'App Runner et pour la version révisée. Nous publierons ensuite une section qui décrit les attributs spécifiques de votre service susceptibles de nécessiter des mises à jour de configuration.

La version originale d'App Runner

Le processus de création de l'application App Runner d'origine tire parti du AWS CodeBuild service. Les étapes initiales sont basées sur des images sélectionnées par le CodeBuild service. Un processus de génération de Docker suit qui utilise l'image d'exécution gérée App Runner applicable comme image de base.

Les étapes générales sont les suivantes :

1. Exécutez pre-build des commandes dans une CodeBuild image organisée.

   Les pre-build commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier apprunner.yaml de configuration.

2. 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.

3. 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.

4. 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.

5. 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.

6. Exécutez post-build les commandes dans l' CodeBuild image de l'étape 2.

   Les post-build commandes sont facultatives. Ils ne peuvent être spécifiés que dans le fichier apprunner.yaml de configuration.

Une fois la compilation terminée, App Runner déploie l'image d'exécution gérée App Runner générée à l'étape 5 pour exécuter votre service Web dans un conteneur.

La version révisée d'App Runner

Le processus de construction révisé est plus rapide et plus efficace que le processus de construction d'origine décrit dans la section précédente. Cela élimine la duplication des commandes de compilation qui se produit dans la version précédente. Il crée également une image finale moins encombrante qui contient uniquement votre code source, les artefacts de build et les temps d'exécution nécessaires à l'exécution de votre application.

Ce processus de génération utilise une version en plusieurs étapes de Docker. Les étapes générales du processus sont les suivantes :

1. Étape de construction : lancez un processus de génération de docker qui exécute pre-build et build commande au-dessus des images de build d'App Runner.

   1. Copiez le code source de l'application /app dans le répertoire.

      Note

      Ce /app répertoire est désigné comme répertoire de travail à chaque étape de la construction de Docker.

   2. 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.

   3. 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.

2. É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.

   2. 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.

3. É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 chapitre sur le fichier de configuration d'App Runner.

Exigences de service pour la prise en compte de la migration

Si votre environnement d'application répond à l'une de ces deux exigences, vous devrez revoir la configuration de votre build en ajoutant des pre-run commandes.

• Si vous devez modifier quoi que ce soit en dehors du /app répertoire à l'aide des build commandes.

• Si vous devez exécuter les build commandes deux fois pour créer l'environnement requis. Il s'agit d'une exigence très inhabituelle. La grande majorité des versions ne le feront pas.

Modifications en dehors du /app répertoire

• La version révisée d'App Runner 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-buildbuild, et pour vous assurer que tous les artefacts de construction se trouvent dans le /app répertoire.

• Si votre application a besoin de la compilation 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 duapprunner.yaml. Pour plus d’informations, consultez Configuration des options du service App Runner à l'aide d'un fichier de configuration.

Exécution des build commandes deux fois

• La version originale d'App Runner 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.