Configuration de CloudFront pour héberger votre application Web

Dans mon dernier article, nous avons expliqué comment mettre en place une application Web qui sert des morceaux et des paquets de CSS et JavaScript de CloudFront. Nous l'avons intégré à Vite de sorte que lorsque l'application s'exécute dans un navigateur, les actifs demandés au fichier html racine de l'application se tiennent de CloudFront en tant que CDN.

Bien que la mise en cache Edge de CloudFront offre des avantages, servir les ressources de votre application à partir de ces plusieurs emplacements n'est pas sans coût propre. Jetons un coup d'œil à une trace WebPageTest de ma propre application Web, en cours d'exécution avec la configuration du dernier article de blog.

Ce message vous montrera comment contourner cela. Nous allons parcourir comment héberger l' intégralité de l'application Web sur CloudFront et faire avancer CloudFront - ou «proxy» - des demandes non liées aux données, à l'authentification, etc., sur notre serveur Web sous-jacent.

Notez que c'est beaucoup plus de travail que ce que nous avons vu dans le dernier article, et les instructions sont susceptibles d'être différentes pour vous en fonction des besoins exacts de votre application Web, de sorte que votre kilométrage peut varier. Nous modifierons les enregistrements DNS et, selon votre application Web, vous devrez peut-être ajouter des en-têtes de cache afin d'éviter que certains actifs ne soient mis en cache. Nous entrerons dans tout cela!

Vous vous demandez peut-être si la configuration que nous avons couverte dans le dernier article offre même des avantages en raison de ce que nous faisons ici dans cet article. Compte tenu du long temps de connexion, aurions-nous été mieux de renoncer au CDN et de servir tous nos actifs du serveur Web pour éviter cette attente plus longue? J'ai mesuré cela avec ma propre application Web, et la version CDN, ci-dessus, était en effet plus rapide, mais pas beaucoup. La charge de page LCP initiale était d'environ 200 à 300 ms plus rapidement. Et rappelez-vous, c'est juste pour la charge initiale. Une fois cette connexion configurée, la mise en cache des bords devrait ajouter beaucoup plus de valeur pour tous vos morceaux ultérieurs chargés de manière asynchrone.

Configuration de notre DNS

Notre objectif final est de servir notre application Web entière de CloudFront. Cela signifie que lorsque nous atteignons notre domaine, nous voulons que les résultats proviennent de CloudFront au lieu du serveur Web auquel il est actuellement lié. Cela signifie que nous devrons modifier nos paramètres DNS. Nous utiliserons AWS Route 53 pour cela.

J'utilise MyDemo.Technology comme exemple, qui est un domaine que je possède. Je vais vous montrer toutes les étapes ici. Mais au moment où vous lisez ceci, j'aurai supprimé ce domaine de mon application Web. Donc, plus tard, lorsque je commence à vous montrer des enregistrements CNAME réels, et similaires, ceux-ci n'existeront plus.

Accédez à la page d'accueil de la route 53 et cliquez sur les zones hébergées:

Cliquez sur Créer une zone hébergée et entrez le domaine de l'application:

Nous n'avons pas encore vraiment accompli rien. Nous avons dit à AWS que nous voulions qu'il gère ce domaine pour nous, et AWS nous a donné les serveurs de noms qu'il acheminera notre trafic. Pour mettre cela en vigueur, nous devons aller partout où notre domaine est enregistré. Il devrait y avoir une place pour que vous puissiez entrer dans vos propres serveurs de noms personnalisés.

Notez que mon domaine est enregistré avec GoDaddy et cela se reflète dans les captures d'écran tout au long de cet article. L'interface utilisateur, les paramètres et les options peuvent différer de ce que vous voyez dans votre registraire.

AVERTISSEMENT: Je recommande d'écrire les serveurs de noms d'origine ainsi que tous les enregistrements DNS avant d'apporter des modifications. De cette façon, si quelque chose échoue, vous avez tout ce dont vous avez besoin pour revenir à la façon dont les choses se passaient avant de commencer. Et même si tout fonctionne bien, vous voudrez toujours ré-aérer tous les autres enregistrements dans la route 53, c'est-à-dire les enregistrements MX, etc.

Configuration d'une distribution CloudFront

Faisons une distribution CloudFront pour héberger notre application Web. Nous avons couvert les bases dans le dernier post, nous allons donc y arriver. Un grand changement par rapport à la dernière fois est ce que nous entrons pour le domaine d'origine. Ne mettez pas le domaine de niveau supérieur , par exemple votre apparition. Ce dont vous avez besoin, c'est du domaine sous-jacent où votre application est hébergée. Si c'est Heroku, alors entrez l'URL Heroku vous fournit.

Ensuite, assurez-vous de modifier le protocole par défaut si vous prévoyez d'utiliser ce site via une connexion HTTPS sécurisée:

Cette partie est cruciale. Si votre application Web exécute l'authentification, l'hébergement des données ou quoi que ce soit d'autre, assurez-vous d'activer d'autres verbes en plus d'obtenir. Si vous ignorez cette pièce, toute demande de publication d'authentification, de données musicales, etc., sera rejetée et échouera. Si votre application Web ne fait que servir des actifs et que toutes ces choses sont gérées par des services externes, alors exceptionnel! Vous avez une excellente configuration et vous pouvez ignorer cette étape.

Nous devons apporter pas mal de modifications à la clé de cache et aux paramètres de demande d'origine par rapport à la dernière fois:

Nous devons créer une stratégie de cache avec un TTL minimum de 0, donc les en-têtes non cachés que nous renvoyons seront correctement respectés. Vous pouvez également activer toutes les chaînes de requête. Je voyais un comportement étrange lorsque plusieurs demandes GraphQL sont sorties avec différentes chaînes de requête, qui ont été ignorées, faisant apparaître toutes ces demandes identiques du point de vue de CloudFront.

Ma politique a fini par ressembler à ceci:

Pour une politique de demande d'origine, si nécessaire, nous devons nous assurer d'envoyer des chaînes de requête et des cookies pour des choses comme l'authentification et les requêtes de données pour fonctionner. Pour être clair, cela détermine si les cookies et les chaînes de requête seront envoyés de CloudFront jusqu'à votre serveur Web (par exemple Heroku, ou similaire).

Le mien ressemble à ceci:

Enfin, pour la stratégie des en-têtes de réponse, nous pouvons sélectionner «CORS avec Ferflight» dans la liste. En fin de compte, vos deux premiers auront des noms différents selon la façon dont vous les configurez. Mais le mien ressemble à ceci:

Connectons notre domaine, quoi qu'il en soit, à cette distribution CloudFront. Malheureusement, c'est plus de travail que vous ne vous y attendez. Nous devons prouver à AWS que nous possédons réellement le domaine parce que, pour tout Amazon, nous ne le savons pas. Nous avons créé une zone hébergée dans la route 53. Et nous avons pris les serveurs de noms qu'il nous a donnés et les avons enregistrés avec GoDaddy (ou qui que votre domaine soit enregistré). Mais Amazon ne le sait pas encore. Nous devons démontrer à Amazon que nous contrôlons en fait le DNS pour ce domaine.

Tout d'abord, nous demanderons un certificat SSL.

Ensuite, demandons le lien de certificat:

Maintenant, nous sélectionnerons l'option pour demander une option de certificat public:

Nous devons fournir le domaine:

Et, dans mon cas, le certificat est en attente:

Donc, je vais cliquer dessus:

Cela prouve que nous possédons et contrôlons ce domaine. Dans un onglet séparé, revenez à la route 53 et ouvrez notre zone hébergée:

Nous devons maintenant créer l'enregistrement CNAME. Copiez la première partie pour le nom d'enregistrement . Par exemple, si le nom cname est _xhyqtrajdkrr.mydemo.technology, mettez la pièce _xhyqtrajdkrr. Pour la valeur d'enregistrement , copiez toute la valeur.

En supposant que vous ayez enregistré les serveurs de noms AWS avec votre hôte de domaine, GoDaddy ou qui que ce soit, AWS sera bientôt en mesure de cingler l'entrée DNS, il vous a juste demandé de créer, de voir la réponse qu'il attend et de valider votre certificat.

Cela peut prendre du temps pour les serveurs de noms que vous définissez au début pour se propager. En théorie, cela peut prendre jusqu'à 72 heures, mais il me met généralement à jour dans l'heure pour moi.

Vous verrez le succès sur le domaine:

… Ainsi que le certificat:

Ouf ! Presque terminé. Maintenant, connectons tout cela à notre distribution CloudFront. Nous pouvons retourner à l'écran des paramètres CloudFront. Maintenant, sous un certificat SSL personnalisé, nous devrions voir ce que nous avons créé (et tout autre que vous avez créé dans le passé):

Ensuite, ajoutons le domaine de niveau supérieur de l'application:

Il ne reste plus qu'à dire la route 53 pour acheminer notre domaine vers cette distribution CloudFront. Alors, revenons à la route 53 et créons un autre enregistrement DNS.

Nous devons entrer un enregistrement A pour IPv4 et un enregistrement AAAA pour IPv6. Pour les deux, laissez le nom d'enregistrement vide car nous enregistrons uniquement notre domaine de niveau supérieur et rien d'autre.

Sélectionnez le type d'enregistrement A. Ensuite, spécifiez l'enregistrement en tant qu'alias, puis mappez l'alias à la distribution CloudFront. Cela devrait ouvrir une option pour choisir votre distribution CloudFront, et puisque nous avons précédemment enregistré le domaine avec CloudFront, vous devriez voir cette distribution et seulement cette distribution lors de la sélection.

Nous répétons les mêmes étapes exactes pour le type d'enregistrement AAAA dont nous avons besoin pour la prise en charge IPv6.

Exécutez votre application Web et assurez-vous que cela, vous savez, fonctionne. Cela devrait!

Choses à tester et à vérifier

OK, bien que nous ayons techniquement terminé ici, il y a de fortes chances qu'il reste encore quelques choses à faire pour répondre aux besoins exacts de votre application Web. Différentes applications ont des besoins différents et ce que j'ai démontré jusqu'à présent nous a parcouru les étapes courantes pour acheminer les choses à travers CloudFront pour de meilleures performances. Il y a des chances qu'il y ait des choses propres à votre application qui nécessitent plus d'amour. Donc, pour cela, permettez-moi de couvrir quelques éléments supplémentaires possibles que vous pourriez rencontrer lors de la configuration.

Tout d'abord, assurez-vous que tous les messages que vous avez sont correctement envoyés à votre origine. En supposant que CloudFront est correctement configuré pour transmettre des cookies à votre origine, cela devrait déjà fonctionner, mais il n'y a pas de mal à vérifier.

La plus grande préoccupation est que toutes les autres demandes de reçus qui sont envoyées à votre application Web. Par défaut, toutes les demandes de GET que CloudFront reçoit, si elles sont mises en cache, sont servies à votre application Web avec la réponse en cache. Cela peut être désastreux. Toutes les demandes de données à tout repos ou points de terminaison GraphQL envoyées avec GET sont mises en cache par le CDN. Et si vous expédiez un employé de service, cela sera également mis en cache, au lieu du comportement normal, où la version actuelle est envoyée en arrière-plan et mise à jour en cas de modifications.

Afin de dire à CloudFront de ne pas mettre en cache certaines choses, assurez-vous de définir l'en-tête "Cache-Control" vers "sans cache". Si vous utilisez un framework, comme Express, vous pouvez définir middleware pour votre accès aux données avec quelque chose comme ceci:

 app.use ("/ graphQl", (req, res, suivant) => {
  res.set ("Cache-Control", "No-cache");
  suivant();
});
app.use (
  "/ graphQL",
  ExpressGraphQl ({
    schéma: exécutablechema,
    graphiql: true,
    rootvalue: root
  })
));

Pour des choses comme les travailleurs de service, vous pouvez mettre des règles spécifiques pour ces fichiers avant votre middleware statique:

 app.get ("/ service-worker.js", express.static (__ dirname "/ react / dist", {Setheaders: resp => resp.set ("cache-control", "no-cache")}));
app.get ("/ sw-index-bundle.js", express.static (__ dirname "/ react / dist", {Setheaders: resp => resp.set ("cache-control", "no-cache")}));
app.use (express.static (__ dirname "/ react / dist", {maxage: 432000 * 1000 * 10}));

Et ainsi de suite. Testez tout à fond parce qu'il y a tellement de choses qui peuvent mal tourner. Et après chaque modification que vous apportez, assurez-vous d'exécuter une invalidation complète dans CloudFront et effacez le cache avant de réinstaller votre application Web pour tester que les choses sont correctement exclues du cache. Vous pouvez le faire à partir de l'onglet Invalidations dans CloudFront. Ouvrez cela et mettez / * pour la valeur, pour tout effacer.

Une implémentation de cloudfront qui fonctionne

Maintenant que nous avons tout en cours d'exécution, remettons notre trace dans WebPageTest:

Et juste comme ça, nous n'avons plus de connexions d'installation comme nous l'avons déjà vu pour nos actifs. Pour ma propre application Web, je voyais une amélioration substantielle de 500 ms en LCP. C'est une victoire solide!

Héberger une application Web entière sur un CDN peut offrir le meilleur de tous les mondes. Nous obtenons la mise en cache de bord pour les ressources statiques, mais sans les coûts de connexion. Malheureusement, cette amélioration ne vient pas gratuitement. L'obtention de la configuration correcte nécessaire correctement n'est pas entièrement intuitive, puis il est toujours nécessaire de configurer des en-têtes de cache afin d'éviter les demandes non liées à la liquidation dans le cache du CDN.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!