Spécification de déploiement d'Amplify Hosting - AWS Amplify Hébergement

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.

Spécification de déploiement d'Amplify Hosting

La spécification de déploiement d'Amplify Hosting est une spécification basée sur un système de fichiers qui définit la structure de répertoire qui facilite les déploiements vers Amplify Hosting. Un framework peut générer cette structure de répertoire attendue en sortie de sa commande de construction, ce qui lui permet de tirer parti des types primitifs de service d'Amplify Hosting. Amplify Hosting comprend la structure du bundle de déploiement et le déploie en conséquence.

Voici un exemple de la structure de dossiers qu'Amplify attend pour le bundle de déploiement. À un niveau élevé, il possède un dossier nomméstatic, un dossier nommé compute et un fichier manifeste de déploiement nommédeploy-manifest.json.

.amplify-hosting/ ├── compute/ │ └── default/ │ ├── chunks/ │ │ └── app/ │ │ ├── _nuxt/ │ │ │ ├── index-xxx.mjs │ │ │ └── index-styles.xxx.js │ │ └── server.mjs │ ├── node_modules/ │ └── server.js ├── static/ │ ├── css/ │ │ └── nuxt-google-fonts.css │ ├── fonts/ │ │ ├── font.woff2 │ ├── _nuxt/ │ │ ├── builds/ │ │ │ └── latest.json │ │ └── entry.xxx.js │ ├── favicon.ico │ └── robots.txt └── deploy-manifest.json

Amplify SSR : prise en charge du type primitif

La spécification de déploiement d'Amplify Hosting définit un contrat qui correspond étroitement aux types primitifs suivants.

Actifs statiques

Fournit des frameworks capables d'héberger des fichiers statiques.

Calcul

Fournit des frameworks capables d'exécuter un serveur HTTP Node.js sur le port 3000.

Optimisation de l'image

Fournit aux frameworks un service permettant d'optimiser les images lors de l'exécution.

Règles de routage

Fournit des frameworks dotés d'un mécanisme permettant de mapper les chemins des demandes entrantes vers des cibles spécifiques.

L'.amplify-hosting/staticannuaire

Vous devez placer dans le .amplify-hosting/static répertoire tous les fichiers statiques accessibles au public destinés à être servis à partir de l'URL de l'application. Les fichiers contenus dans ce répertoire sont servis via le type primitif static assets.

Les fichiers statiques sont accessibles à la racine (/) de l'URL de l'application sans aucune modification de leur contenu, de leur nom de fichier ou de leur extension. En outre, les sous-répertoires sont conservés dans la structure de l'URL et apparaissent avant le nom du fichier. À titre d'exemple, .amplify-hosting/static/favicon.ico sera servi depuis https://myAppId.amplify-hostingapp.com/favicon.ico et .amplify-hosting/static/_nuxt/main.js sera servi depuis https://myAppId.amplify-hostingapp.com/_nuxt/main.js

Si un framework permet de modifier le chemin de base de l'application, il doit ajouter le chemin de base aux actifs statiques du .amplify-hosting/static répertoire. Par exemple, si le chemin de base est/folder1/folder2, la sortie de génération pour un actif statique appelé main.css sera.amplify-hosting/static/folder1/folder2/main.css.

L'.amplify-hosting/computeannuaire

Une ressource de calcul unique est représentée par un sous-répertoire unique nommé default contenu dans le .amplify-hosting/compute répertoire. Le chemin est.amplify-hosting/compute/default. Cette ressource de calcul correspond au type de primitive de calcul d'Amplify Hosting.

Le contenu du default sous-répertoire doit être conforme aux règles suivantes.

  • Un fichier doit exister à la racine du default sous-répertoire pour servir de point d'entrée à la ressource de calcul.

  • Le fichier du point d'entrée doit être un module Node.js et il doit démarrer un serveur HTTP qui écoute sur le port 3000.

  • Vous pouvez placer d'autres fichiers dans le default sous-répertoire et y faire référence à partir du code contenu dans le fichier du point d'entrée.

  • Le contenu du sous-répertoire doit être autonome. Le code du module du point d'entrée ne peut référencer aucun module en dehors du sous-répertoire. Notez que les frameworks peuvent regrouper leur serveur HTTP comme ils le souhaitent. Si le processus de calcul peut être lancé avec la node server.js commande, où server.js is est le nom du fichier d'entrée, depuis le sous-répertoire, Amplify considère que la structure du répertoire est conforme à la spécification de déploiement.

Amplify Hosting regroupe et déploie tous les fichiers du default sous-répertoire vers une ressource de calcul provisionnée. Chaque ressource de calcul se voit attribuer 512 Mo de stockage éphémère. Ce stockage n'est pas partagé entre les instances d'exécution, mais est partagé entre les invocations suivantes au sein de la même instance d'exécution. Les instances d'exécution sont limitées à une durée d'exécution maximale de 15 minutes, et le seul chemin accessible en écriture au sein de l'instance d'exécution est le /tmp répertoire. La taille compressée de chaque ensemble de ressources de calcul ne peut pas dépasser 220 Mo. Par exemple, le .amplify/compute/default sous-répertoire ne peut pas dépasser 220 Mo lorsqu'il est compressé.

le fichier .amplify-hosting/deploy-manifest.json ;

Utilisez le deploy-manifest.json fichier pour stocker les détails de configuration et les métadonnées d'un déploiement. Au minimum, un deploy-manifest.json fichier doit inclure un version attribut, l'routesattribut avec une route fourre-tout spécifiée et l'frameworkattribut avec des métadonnées de structure spécifiées.

La définition d'objet suivante illustre la configuration d'un manifeste de déploiement.

type DeployManifest = { version: 1; routes: Route[]; computeResources?: ComputeResource[]; imageSettings?: ImageSettings; framework: FrameworkMetadata; };

Les rubriques suivantes décrivent les détails et l'utilisation de chaque attribut du manifeste de déploiement.

Utilisation de l'attribut version

L'versionattribut définit la version de la spécification de déploiement que vous implémentez. Actuellement, la seule version pour la spécification de déploiement d'Amplify Hosting est la version 1. L'exemple JSON suivant illustre l'utilisation de l'versionattribut.

"version": 1

Utilisation de l'attribut routes

L'routesattribut permet aux frameworks de tirer parti du type primitif des règles de routage Amplify Hosting. Les règles de routage fournissent un mécanisme permettant d'acheminer les chemins des demandes entrantes vers une cible spécifique du bundle de déploiement. Les règles de routage dictent uniquement la destination d'une demande entrante et sont appliquées une fois que la demande a été transformée par des règles de réécriture et de redirection. Pour plus d'informations sur la façon dont Amplify Hosting gère les réécritures et les redirections, consultez. Utilisation des redirections

Les règles de routage ne réécrivent ni ne transforment la demande. Si une demande entrante correspond au modèle de chemin d'un itinéraire, la demande est acheminée telle quelle vers la cible de l'itinéraire.

Les règles de routage spécifiées dans le routes tableau doivent être conformes aux règles suivantes.

  • Un itinéraire fourre-tout doit être spécifié. Un itinéraire fourre-tout possède le /* modèle qui correspond à toutes les demandes entrantes.

  • Le routes tableau peut contenir un maximum de 25 éléments.

  • Vous devez spécifier un Static itinéraire ou un Compute itinéraire.

  • Si vous spécifiez un Static itinéraire, le .amplify-hosting/static répertoire doit exister.

  • Si vous spécifiez un Compute itinéraire, le .amplify-hosting/compute répertoire doit exister.

  • Si vous spécifiez un ImageOptimization itinéraire, vous devez également spécifier un Compute itinéraire. Cela est nécessaire car l'optimisation des images n'est pas encore prise en charge pour les applications purement statiques.

La définition d'objet suivante illustre la configuration de l'Routeobjet.

type Route = { path: string; target: Target; fallback?: Target; }

Le tableau suivant décrit les propriétés de l'Routeobjet.

Clé Type Obligatoire Description

path

Chaîne

Oui

Définit un modèle qui correspond aux chemins des demandes entrantes (à l'exception de la chaîne de requête).

La longueur maximale du chemin est de 255 caractères.

Un tracé doit commencer par la barre oblique/.

Un chemin peut contenir n'importe lequel des caractères suivants : [A-Z], [a-z], [0-9], [_-.*$/~"'@ : +].

Pour la correspondance de modèles, seuls les caractères génériques suivants sont pris en charge :

  • *(correspond à 0 caractères ou plus)

  • Le /* modèle est appelé modèle fourre-tout et correspond à toutes les demandes entrantes.

cible

Cible

Oui

Un objet qui définit la cible vers laquelle acheminer la demande correspondante.

Si un Compute itinéraire est spécifié, un itinéraire correspondant ComputeResource doit exister.

Si un ImageOptimization itinéraire est spécifié, imageSettings il doit également être spécifié.

repli

Cible

Non

Objet qui définit la cible vers laquelle se rabattre si la cible d'origine renvoie une erreur 404.

Le target type et le fallback type ne peuvent pas être identiques pour un itinéraire spécifique. Par exemple, le repli de Static à n'Staticest pas autorisé. Les solutions de secours ne sont prises en charge que pour les requêtes GET qui n'ont pas de corps. Si un corps est présent dans la demande, il sera supprimé lors du repli.

La définition d'objet suivante illustre la configuration de l'Targetobjet.

type Target = { kind: TargetKind; src?: string; cacheControl?: string; }

Le tableau suivant décrit les propriétés de l'Targetobjet.

Clé Type Obligatoire Description

sorte

Type cible

Oui

Et enum qui définit le type de cible. Les valeurs valides sont Static, Compute et ImageOptimization.

src

Chaîne

Oui pour Compute

Non pour les autres types primitifs

Chaîne qui indique le nom du sous-répertoire du bundle de déploiement qui contient le code exécutable du type primitif. Valide et obligatoire uniquement pour le type primitif Compute.

La valeur doit pointer vers l'une des ressources de calcul présentes dans le bundle de déploiement. Actuellement, la seule valeur prise en charge pour ce champ estdefault.

Contrôle du cache

Chaîne

Non

Chaîne qui indique la valeur de l'en-tête Cache-Control à appliquer à la réponse. Valable uniquement pour les types statique et ImageOptimization primitif.

La valeur spécifiée est remplacée par des en-têtes personnalisés. Pour plus d'informations sur les en-têtes clients d'Amplify Hosting, consultez. En-têtes personnalisés

Note

Cet en-tête Cache-Control est uniquement appliqué aux réponses réussies dont le code d'état est défini sur 200 (OK).

La définition d'objet suivante illustre l'utilisation de l'TargetKindénumération.

enum TargetKind { Static = "Static", Compute = "Compute", ImageOptimization = "ImageOptimization" }

La liste suivante indique les valeurs valides pour l'TargetKindénumération.

Statique

Achemine les demandes vers le type primitif des actifs statiques.

Calcul

Achemine les demandes vers le type de primitive de calcul.

ImageOptimization

Achemine les demandes vers le type primitif d'optimisation d'image.

L'exemple JSON suivant illustre l'utilisation de l'routesattribut avec plusieurs règles de routage spécifiées.

"routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ]

Pour plus d'informations sur la spécification des règles de routage dans votre manifeste de déploiement, voir Bonnes pratiques pour configurer les règles de routage

Utilisation de l'attribut ComputerResources

L'computeResourcesattribut permet aux frameworks de fournir des métadonnées sur les ressources de calcul allouées. Chaque ressource de calcul doit être associée à un itinéraire correspondant.

La définition d'objet suivante illustre l'utilisation de l'ComputeResourceobjet.

type ComputeResource = { name: string; runtime: ComputeRuntime; entrypoint: string; }; type ComputeRuntime = 'nodejs16.x' | 'nodejs18.x' | 'nodejs20.x';

Le tableau suivant décrit les propriétés de l'ComputeResourceobjet.

Clé Type Obligatoire Description

name

Chaîne

Oui

Spécifie le nom de la ressource de calcul. Le nom doit correspondre au nom du sous-répertoire situé dans le.amplify-hosting/compute directory.

Pour la version 1 de la spécification de déploiement, la seule valeur valide estdefault.

environnement d’exécution

ComputeRuntime

Oui

Définit le temps d'exécution de la ressource de calcul provisionnée.

Les valeurs valides sont nodejs16.x, nodejs18.x et nodejs20.x.

point d'entrée

Chaîne

Oui

Spécifie le nom du fichier de départ à partir duquel le code sera exécuté pour la ressource de calcul spécifiée. Le fichier doit exister dans le sous-répertoire qui représente une ressource de calcul.

Si vous avez une structure de répertoire qui ressemble à la suivante.

.amplify-hosting |---compute | |---default | |---index.js

Le JSON de l'computeResourceattribut ressemblera à ce qui suit.

"computeResources": [ { "name": "default", "runtime": "nodejs16.x", "entrypoint": "index.js", } ]

Utilisation de l'attribut ImageSettings

L'imageSettingsattribut permet aux frameworks de personnaliser le comportement du type primitif d'optimisation d'image, qui fournit une optimisation à la demande des images lors de l'exécution.

La définition d'objet suivante illustre l'utilisation de l'ImageSettingsobjet.

type ImageSettings = { sizes: number[]; domains: string[]; remotePatterns: RemotePattern[]; formats: ImageFormat[]; minumumCacheTTL: number; dangerouslyAllowSVG: boolean; }; type ImageFormat = 'image/avif' | 'image/webp' | 'image/png' | 'image/jpeg';

Le tableau suivant décrit les propriétés de l'ImageSettingsobjet.

Clé Type Obligatoire Description

tailles

Numéro []

Oui

Un tableau de largeurs d'image prises en charge.

domains

Chaîne []

Oui

Un ensemble de domaines externes autorisés qui peuvent utiliser l'optimisation d'image. Laissez le tableau vide pour autoriser uniquement le domaine de déploiement à utiliser l'optimisation des images.

Motifs distants

RemotePattern[]

Oui

Un tableau de modèles externes autorisés qui peuvent utiliser l'optimisation de l'image. Similaire aux domaines, mais offre un meilleur contrôle avec les expressions régulières (regex).

formats

ImageFormat[]

Oui

Un tableau de formats d'image de sortie autorisés.

Cache minimal TL

Nombre

Oui

Durée du cache en secondes pour les images optimisées.

Autorise dangereusement le SVG

Booléen

Oui

Autorise les URL d'image d'entrée SVG. Cette option est désactivée par défaut pour des raisons de sécurité.

La définition d'objet suivante illustre l'utilisation de l'RemotePatternobjet.

type RemotePattern = { protocol?: 'http' | 'https'; hostname: string; port?: string; pathname?: string; }

Le tableau suivant décrit les propriétés de l'RemotePatternobjet.

Clé Type Obligatoire Description

protocole ;

Chaîne

Non

Protocole du modèle de télécommande autorisé.

Les valeurs valides sont http ou https.

hostname

Chaîne

Oui

Le nom d'hôte du modèle distant autorisé.

Vous pouvez spécifier un littéral ou un caractère générique. Un seul `*` correspond à un seul sous-domaine. Un double `**` correspond à un nombre quelconque de sous-domaines. Amplify n'autorise pas les caractères génériques où seul `**` est spécifié.

port

Chaîne

Non

Port du modèle de télécommande autorisé.

chemin d'accès

Chaîne

Non

Le nom du chemin du modèle de télécommande autorisé.

L'exemple suivant illustre l'imageSettingsattribut.

"imageSettings": { "sizes": [ 100, 200 ], "domains": [ "example.com" ], "remotePatterns": [ { "protocol": "https", "hostname": "example.com", "port": "", "pathname": "/**", } ], "formats": [ "image/webp" ], "minumumCacheTTL": 60, "dangerouslyAllowSVG": false }

Utilisation de l'attribut framework

Utilisez l'frameworkattribut pour spécifier les métadonnées du framework.

La définition d'objet suivante illustre la configuration de l'FrameworkMetadataobjet.

type FrameworkMetadata = { name: string; version: string; }

Le tableau suivant décrit les propriétés de l'FrameworkMetadataobjet.

Clé Type Obligatoire Description

name

Chaîne

Oui

Le nom du framework.

version

Chaîne

Oui

Version du framework.

Il doit s'agir d'une chaîne de version sémantique (semver) valide.

Bonnes pratiques pour configurer les règles de routage

Les règles de routage fournissent un mécanisme pour acheminer les chemins des demandes entrantes vers des cibles spécifiques du bundle de déploiement. Dans un bundle de déploiement, les auteurs du framework peuvent émettre des fichiers vers la sortie de build qui sont déployés sur l'une des cibles suivantes :

  • Type primitif des actifs statiques : les fichiers sont contenus dans le .amplify-hosting/static répertoire.

  • Type primitif de calcul : les fichiers sont contenus dans le .amplify-hosting/compute/default répertoire.

Les auteurs du framework fournissent également un ensemble de règles de routage dans le fichier manifeste de déploiement. Chaque règle du tableau est comparée à la demande entrante dans un ordre séquentiel, jusqu'à ce qu'il y ait une correspondance. Lorsqu'il existe une règle de correspondance, la demande est acheminée vers la cible spécifiée dans la règle de correspondance. Facultativement, une cible de secours peut être spécifiée pour chaque règle. Si la cible d'origine renvoie une erreur 404, la demande est acheminée vers la cible de secours.

La spécification de déploiement exige que la dernière règle de l'ordre de traversée soit une règle fourre-tout. Une règle fourre-tout est spécifiée avec le /* chemin. Si la demande entrante ne correspond à aucune des routes précédentes du tableau de règles de routage, elle est acheminée vers la cible de règles fourre-tout.

Pour les frameworks SSR tels queNuxt.js, la cible de la règle fourre-tout doit être le type primitif de calcul. Cela est dû au fait que les applications SSR ont des pages affichées côté serveur avec des itinéraires qui ne sont pas prévisibles au moment de la création. Par exemple, si une Nuxt.js application possède une page /blog/[slug] où se [slug] trouve un paramètre de route dynamique. La cible de la règle fourre-tout est le seul moyen d'acheminer les demandes vers ces pages.

En revanche, des modèles de trajectoire spécifiques peuvent être utilisés pour cibler des itinéraires connus au moment de la construction. Par exemple, Nuxt.js diffuse les actifs statiques depuis le /_nuxt chemin. Cela signifie que le /_nuxt/* chemin peut être ciblé par une règle de routage spécifique qui achemine les demandes vers le type primitif des actifs statiques.

Routage des dossiers publics

La plupart des frameworks SSR offrent la possibilité de servir des actifs statiques mutables à partir d'un public dossier. Les fichiers tels que favicon.ico et robots.txt sont généralement conservés dans le public dossier et sont servis à partir de l'URL racine de l'application. Par exemple, le favicon.ico fichier est servi à partir dehttps://example.com/favicon.ico. Notez qu'il n'existe aucun modèle de chemin prévisible pour ces fichiers. Ils sont presque entièrement dictés par le nom du fichier. La seule façon de cibler les fichiers contenus dans le public dossier est d'utiliser la méthode fourre-tout. Cependant, la cible de l'itinéraire fourre-tout doit être le type primitif de calcul.

Nous recommandons l'une des approches suivantes pour gérer votre public dossier.

  1. Utilisez un modèle de chemin pour cibler les chemins de requête contenant des extensions de fichiers. Par exemple, vous pouvez l'utiliser /*.* pour cibler tous les chemins de demande contenant une extension de fichier.

    Notez que cette approche peut ne pas être fiable. Par exemple, si le public dossier contient des fichiers sans extension, ils ne sont pas visés par cette règle. Un autre problème à prendre en compte avec cette approche est que l'application peut avoir des pages avec des points dans leur nom. Par exemple, une page /blog/2021/01/01/hello.world sera ciblée par la /*.* règle. Ce n'est pas idéal car la page n'est pas un actif statique. Toutefois, vous pouvez ajouter une cible de secours à cette règle pour garantir qu'en cas d'erreur 404 provenant du type primitif statique, la demande revienne au type primitif de calcul.

    { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }
  2. Identifiez les fichiers du public dossier au moment de la création et émettez une règle de routage pour chaque fichier. Cette approche n'est pas évolutive car la spécification de déploiement impose une limite de 25 règles.

    { "path": "/favicon.ico", "target": { "kind": "Static" } }, { "path": "/robots.txt", "target": { "kind": "Static" } }
  3. Recommandez aux utilisateurs de votre framework de stocker tous les actifs statiques mutables dans un sous-dossier du public dossier.

    Dans l'exemple suivant, l'utilisateur peut stocker tous les actifs statiques modifiables dans le public/assets dossier. Ensuite, une règle de routage avec le modèle de chemin /assets/* peut être utilisée pour cibler tous les actifs statiques mutables présents dans le public/assets dossier.

    { "path": "/assets/*", "target": { "kind": "Static" } }
  4. Spécifiez une solution de secours statique pour l'itinéraire fourre-tout. Cette approche présente des inconvénients qui sont décrits plus en détail dans la Routage de secours fourre-tout section suivante.

Routage de secours fourre-tout

Pour les frameworks SSR tels que ceux Nuxt.js où une route fourre-tout est spécifiée pour la cible de type primitif de calcul, les auteurs du framework peuvent envisager de spécifier une solution de secours statique pour la route fourre-tout afin de résoudre le problème de routage des dossiers. public Cependant, ce type de règle de routage interrompt les pages 404 affichées côté serveur. Par exemple, si l'utilisateur final visite une page qui n'existe pas, l'application affiche une page 404 avec un code d'état 404. Toutefois, si la route fourre-tout comporte une solution de secours statique, la page 404 n'est pas affichée. Au lieu de cela, la demande revient au type primitif statique et aboutit toujours à un code d'état 404, mais la page 404 n'est pas rendue.

{ "path": "/*", "target": { "kind": "Compute", "src": "default" }, "fallback": { "kind": "Static" } }

Routage du chemin de base

Les frameworks qui offrent la possibilité de modifier le chemin de base de l'application sont censés ajouter le chemin de base aux actifs statiques du .amplify-hosting/static répertoire. Par exemple, si le chemin de base est/folder1/folder2, la sortie de génération pour un actif statique appelé main.css sera.amplify-hosting/static/folder1/folder2/main.css.

Cela signifie que les règles de routage doivent également être mises à jour pour refléter le chemin de base. Par exemple, si le chemin de base est/folder1/folder2, la règle de routage pour les actifs statiques du public dossier sera la suivante.

{ "path": "/folder1/folder2/*.*", "target": { "kind": "Static" } }

De même, les routes côté serveur doivent également être précédées du chemin de base. Par exemple, si le chemin de base est/folder1/folder2, la règle de routage de l'/apiitinéraire ressemblera à ce qui suit.

{ "path": "/folder1/folder2/api/*", "target": { "kind": "Compute", "src": "default" } }

Cependant, le chemin de base ne doit pas être ajouté à l'itinéraire fourre-tout. Par exemple, si le chemin de base est le suivant/folder1/folder2, l'itinéraire fourre-tout restera le suivant.

{ "path": "/*", "target": { "kind": "Compute", "src": "default" } }

Exemples de routes Nuxt.js

Voici un exemple de deploy-manifest.json fichier pour une application Nuxt qui montre comment spécifier des règles de routage.

{ "version": 1, "routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs18.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } }

Voici un exemple de deploy-manifest.json fichier pour Nuxt qui montre comment spécifier des règles de routage, y compris des chemins de base.

{ "version": 1, "routes": [ { "path": "/base-path/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/base-path/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs18.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } }

Pour plus d'informations sur l'utilisation de l'routesattribut, consultezUtilisation de l'attribut routes.