Einrichten von CloudFront auf Ihre Web -App zu hosten

In meinem letzten Artikel haben wir uns überlegt, wie man eine Web -App eingerichtet hat, die aus Cloudfront Stücke und Bündel von CSS und JavaScript bedient. Wir haben es in vite integriert, sodass die von der HTML -Datei der App angeforderten Assets, wenn die App in einem Browser ausgeführt wird, aus CloudFront als CDN gefordert wird.

Während Cloudfront's Edge Caching Vorteile bietet, ist es nicht ohne eigene Kosten, die Ressourcen Ihrer App von diesen mehreren Standorten zu bedienen. Schauen wir uns eine WebPagetest -Trace meiner eigenen Web -App an, die mit der Konfiguration aus dem letzten Blog -Beitrag ausgeführt wird.

Dieser Beitrag zeigt Ihnen, wie Sie dies umgehen können. Wir gehen durch, wie die gesamte Web-App auf Cloudfront gehostet werden und CloudFront-oder „Proxy“-nicht zugeschnittene Anfragen nach Daten, Auth usw. auf unserem zugrunde liegenden Webserver vorantreiben.

Beachten Sie, dass dies im Wesentlichen mehr Arbeit ist als das, was wir im letzten Artikel gesehen haben, und die Anweisungen sind für Sie wahrscheinlich unterschiedlich, basierend auf den genauen Anforderungen Ihrer Web -App, sodass Ihre Kilometerleistung möglicherweise variieren kann. Wir werden DNS -Datensätze ändern und müssen je nach Web -App möglicherweise einige Cache -Headers hinzufügen, um zu verhindern, dass bestimmte Vermögenswerte jemals zwischengespeichert werden. Wir werden uns all das einlassen!

Möglicherweise fragen Sie sich, ob das Setup, das wir im letzten Artikel behandelt haben, auch irgendwelche Vorteile bietet, da wir hier in diesem Artikel hier tun. Wären wir angesichts der langen Verbindungszeit besser darauf gegangen, auf die CDN zu verzichten und stattdessen alle unsere Vermögenswerte vom Webserver zu bedienen, um diese längere Wartezeit zu vermeiden? Ich habe dies mit meiner eigenen Web -App gemessen, und die CDN -Version war oben tatsächlich schneller, aber nicht viel. Die anfängliche LCP-Seitenlast betrug etwa 200-300 ms schneller. Und denken Sie daran, das ist nur für die anfängliche Last. Sobald diese Verbindung aufgestellt wurde, sollte das Edge -Caching für alle nachfolgenden, asynchron geladenen Stücke viel mehr Wert verleihen.

Einrichten unserer DNS

Unser Endziel ist es, unsere gesamte Web -App aus Cloudfront zu bedienen. Das heißt, wenn wir auf unsere Domain klicken, möchten wir, dass die Ergebnisse von Cloudfront anstelle des Webservers kommen, mit dem sie derzeit verknüpft sind. Das heißt, wir müssen unsere DNS -Einstellungen ändern. Wir werden dafür AWS Route 53 verwenden.

Ich benutze MyDemo.technology als Beispiel, eine Domäne, die ich besitze. Ich werde Ihnen alle Schritte hier zeigen. Aber wenn Sie dies lesen, habe ich diese Domain aus meiner Web -App entfernt. Wenn ich Ihnen später anfange, Ihnen die tatsächlichen CNAME -Datensätze zu zeigen, und ähnlich, werden diese nicht mehr existieren.

Gehen Sie zur Route 53 -Homepage und klicken Sie auf gehostete Zonen:

Klicken Sie auf Hosted Zone erstellen und geben Sie die Domain der App ein:

Wir haben noch nichts wirklich erreicht. Wir haben AWS gesagt, wir möchten, dass es diese Domain für uns verwaltet, und AWS gab uns die Namenserver, die unseren Verkehr durchführt. Um dies in Kraft zu setzen, müssen wir dorthin gehen, wo unsere Domain registriert ist. Es sollte einen Ort geben, an dem Sie Ihre eigenen benutzerdefinierten Namenserver eingeben können.

Beachten Sie, dass meine Domain bei Godaddy registriert ist und sich dies in den Screenshots in diesem Artikel widerspiegelt. Die Benutzeroberfläche, die Einstellungen und die Optionen können sich von dem unterscheiden, was Sie in Ihrem Registrar sehen.

WARNUNG: Ich empfehle, die ursprünglichen Namenserver sowie alle DNS -Datensätze aufzuschreiben, bevor Sie Änderungen vornehmen. Sollte etwas scheitern, haben Sie alles, was Sie brauchen, um zurückzurollen, wie die Dinge waren, bevor Sie angefangen haben. Und selbst wenn alles einwandfrei funktioniert, möchten Sie noch andere Datensätze in Route 53, dh MX Records usw. neu einordnen.

Einrichten einer Cloudfront -Verteilung

Lassen Sie uns eine CloudFront -Verteilung für die Hosten unserer Web -App erstellen. Wir haben die Grundlagen im letzten Beitrag behandelt, also werden wir es richtig machen. Eine große Veränderung gegenüber dem letzten Mal ist das, was wir für die Herkunftsdomäne eingeben. Setzen Sie die Domäne der obersten Ebene nicht , z. B. Ihr-App.net. Was Sie brauchen, ist die zugrunde liegende Domain, in der Ihre App gehostet wird. Wenn das Heroku ist, dann betreten Sie die URL, die Heroku Ihnen bietet.

Ändern Sie als nächstes das Standardprotokoll, wenn Sie diese Site über eine sichere HTTPS -Verbindung verwenden möchten:

Dieser Teil ist entscheidend. Wenn in Ihrer Web -App Authentifizierung, Hosting -Daten oder etwas anderes ausgeführt wird, sollten Sie auch andere Verben aktivieren. Wenn Sie diesen Teil überspringen, werden alle Postanfragen nach Authentifizierung, Mutationsdaten usw. abgelehnt und fehlschlägt. Wenn Ihre Web -App nichts anderes tut, als Vermögenswerte zu bedienen und all diese Dinge von externen Diensten behandelt werden, dann ist hervorragend! Sie haben ein tolles Setup und können diesen Schritt überspringen.

Wir müssen einige Änderungen an den Einstellungen für Cache -Schlüssel und Ursprungsanforderungen im Vergleich zum letzten Mal vornehmen:

Wir müssen eine Cache-Richtlinie mit einem Mindest-TTL von 0 erstellen. Daher werden die von uns zurückgesendeten Nicht-Caching-Header ordnungsgemäß respektiert. Möglicherweise möchten Sie auch alle Abfragebräge aktivieren. Ich sah ein seltsames Verhalten, als mehrere GraphQL -Anfragen mit verschiedenen Abfragesteichen ausgingen, die ignoriert wurden, was dazu führte, dass alle diese Anfragen aus der Perspektive von Cloudfront identisch erscheinen.

Meine Politik sah so aus:

Bei einer Origin -Anfrage -Richtlinie sollten wir bei Bedarf sicherstellen, dass Abfragebräge und Cookies für Dinge wie Authentifizierung und Datenfragen zur Arbeit gesendet werden. Um klar zu sein, bestimmt dies, ob Cookies und Abfragebräge von Cloudfront an Ihren Webserver (z. B. Heroku oder ähnliches) gesendet werden.

Meins sieht so aus:

Zum Schluss können wir für die Richtlinien der Antwortheader aus der Liste „CORs mit Vorflug“ auswählen. Am Ende haben Ihre ersten beiden unterschiedliche Namen, je nachdem, wie Sie sie einrichten. Aber meine sieht so aus:

Lassen Sie uns unsere Domain, was auch immer sie ist, mit dieser Cloudfront -Verteilung verbinden. Leider ist dies mehr Arbeit als Sie vielleicht erwarten. Wir müssen AWS beweisen, dass wir die Domain tatsächlich besitzen, weil wir für alle wissen, dass wir es nicht tun. Wir haben eine gehostete Zone in Route 53 erstellt. Und wir haben die Namenserver genommen, die sie uns gegeben haben, und registrierte sie bei Godaddy (oder mit wem auch immer Ihre Domain registriert ist). Aber Amazon weiß das noch nicht. Wir müssen Amazon demonstrieren, dass wir tatsächlich die DNS für diese Domäne steuern.

Zunächst fordern wir ein SSL -Zertifikat an.

Lassen Sie uns als nächstes den Zertifikat -Link anfordern:

Wir werden nun die Option zum Anfordern einer öffentlichen Zertifikatsoption auswählen:

Wir müssen die Domain bereitstellen:

Und in meinem Fall steht das Zertifikat an:

Also werde ich darauf klicken:

Dies beweist, dass wir diese Domäne besitzen und kontrollieren. Gehen Sie in einer separaten Registerkarte zurück zur Route 53 und öffnen Sie unsere gehostete Zone:

Jetzt müssen wir den CNAME -Datensatz erstellen. Kopieren Sie den ersten Teil für den Datensatznamen . Wenn der CNAME beispielsweise _xhyqtrajdkrr.mydemo.technology ist, setzen Sie den Teil _xhyqtrajdkrr ein. Kopieren Sie für den Datensatzwert den gesamten Wert.

Angenommen, Sie haben die AWS -Namenserver mit Ihrem Domain -Host, Godaddy oder Whoeaver registriert, kann AWS bald in der Lage sein, den DNS -Eintrag zu pingen. Sie hat Sie nur gebeten, die erwartete Antwort zu erstellen und Ihr Zertifikat zu validieren.

Es kann einige Zeit dauern, bis die Namenserver, die Sie am Anfang eingestellt haben, sich zu vermehren. Theoretisch kann es bis zu 72 Stunden dauern, aber es wird normalerweise innerhalb einer Stunde für mich aktualisiert.

Sie werden Erfolg in der Domain sehen:

… Sowie das Zertifikat:

Puh ! Fast fertig. Lassen Sie uns nun all dies mit unserer CloudFront -Verteilung verbinden. Wir können zurück zum CloudFront -Einstellungsbildschirm gehen. Unter benutzerdefiniertem SSL -Zertifikat sollten wir nun sehen, was wir erstellt haben (und alle anderen, die Sie in der Vergangenheit erstellt haben):

Fügen wir dann die oberste Domain der App hinzu:

Alles, was übrig bleibt, ist, Route 53 zu sagen, dass er unsere Domain zu dieser CloudFront -Verteilung weiterleitet. Gehen wir also zurück zur Route 53 und erstellen Sie einen weiteren DNS -Rekord.

Wir müssen einen A -Datensatz für IPv4 und einen AAAA -Datensatz für IPv6 eingeben. Lassen Sie den Datensatznamen für beide leer, da wir nur unsere Domain auf der obersten Ebene registrieren und nichts anderes.

Wählen Sie den A -Datensatztyp aus. Geben Sie als Nächstes den Datensatz als Alias ​​an und zeichnen Sie den Alias ​​der CloudFront -Verteilung ab. Dies sollte eine Option zur Auswahl Ihrer CloudFront -Verteilung eröffnen. Da wir zuvor die Domain mit CloudFront registriert haben, sollten Sie diese Verteilung und nur diese Verteilung bei einer Auswahl sehen.

Wir wiederholen genau die gleichen Schritte für den AAAA -Datensatztyp, den wir für IPv6 -Unterstützung benötigen.

Führen Sie Ihre Web -App aus und stellen Sie sicher, dass sie tatsächlich funktioniert. Es sollte!

Dinge zu testen und zu überprüfen

OK, während wir hier technisch gesehen sind, sind wahrscheinlich noch ein paar Dinge zu tun, um die genauen Anforderungen Ihrer Web -App zu erfüllen. Unterschiedliche Apps haben unterschiedliche Bedürfnisse und das, was ich bisher gezeigt habe, hat uns durch die gemeinsamen Schritte geführt, um die Dinge durch Cloudfront für eine bessere Leistung zu leiten. Wahrscheinlich gibt es Dinge, die für Ihre App einzigartig sind, die mehr Liebe erfordern. Lassen Sie mich dafür ein paar mögliche zusätzliche Elemente abdecken, die Sie während des Setups möglicherweise begegnen.

Stellen Sie zunächst sicher, dass alle Beiträge, die Sie haben, korrekt an Ihren Ursprung gesendet werden. Angenommen, Cloudfront ist korrekt konfiguriert, um Cookies an Ihren Ursprung weiterzuleiten, sollte dies bereits funktionieren, aber es gibt keine Schäden bei der Überprüfung.

Das größere Anliegen sind alle anderen GET -Anfragen, die an Ihre Web -App gesendet werden. Standardmäßig werden alle GET -Anforderungen CloudFront mit der zwischengespeicherten Antwort Ihrer Web -App empfangen. Dies kann katastrophal sein. Alle Datenanfragen an alle mit GET gesendeten REST- oder GRAFQL -Endpunkte werden von der CDN zwischengespeichert. Und wenn Sie einen Servicemitarbeiter versenden, wird dies auch anstelle des normalen Verhaltens zwischengespeichert, wobei die aktuelle Version im Hintergrund gesendet und bei Änderungen aktualisiert wird.

Um Cloudfront nicht zu sagen, dass bestimmte Dinge nicht zwischengespeichert werden sollen, stellen Sie sicher, dass Sie den Header "Cache-Control" auf "No-Cache" einstellen. Wenn Sie ein Framework wie Express verwenden, können Sie Middleware für Ihren Datenzugriff mit so etwas festlegen:

 app.use ("/graphql", (req, res, next) => {
  res.set ("cache-control", "no-cache");
  nächste();
});
app.use (
  "/graphql",
  expressgraphql ({{
    Schema: Ausführbare Verschärfung,
    Graphiql: true,
    RootValue: Wurzel
  })
);

Für Dinge wie Servicearbeiter können Sie vor Ihrer statischen Middleware bestimmte Regeln für diese Dateien eingeben:

 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});

Und so weiter. Testen Sie alles gründlich, weil so viel schief gehen kann. Achten Sie nach jeder Änderung, die Sie vornehmen, eine vollständige Ungültigmachung in CloudFront und löschen Sie den Cache, bevor Sie Ihre Web-App erneut durchführen, um zu testen, dass die Dinge korrekt vom Cache ausgeschlossen sind. Sie können dies von der Registerkarte "Invalidation" in Cloudfront tun. Öffnen Sie das und geben Sie /* für den Wert ein, um alles zu klären.

Eine funktionierende Cloudfront -Implementierung

Jetzt, da wir alles laufen lassen, lassen Sie uns unsere Spur in WebPagetest erneut ausführen:

Und einfach so haben wir keine Einstellungsverbindungen mehr wie zuvor für unsere Vermögenswerte. Für meine eigene Web -App sah ich eine erhebliche Verbesserung von 500 ms in LCP. Das ist ein solider Sieg!

Das Hosting einer gesamten Web -App auf einem CDN kann das Beste aller Welten bieten. Wir erhalten Edge -Caching für statische Ressourcen, jedoch ohne die Verbindungskosten. Leider kommt diese Verbesserung nicht kostenlos. Es ist nicht ganz intuitiv, alle notwendigen Proxen korrekt einzurichten zu erhalten, und dann müssen Cache-Header immer noch eingerichtet werden, um nicht zugeschnittene Anforderungen zu vermeiden, dass sich die Anfragen im Cache des CDN auswickeln.

Das obige ist der detaillierte Inhalt vonEinrichten von CloudFront auf Ihre Web -App zu hosten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!