Express-Tutorial Teil 7: Bereitstellen in der Produktion

Sobald Ihre Seite fertig ist (oder „fertig genug“, um mit öffentlichen Tests zu beginnen), müssen Sie diese an einem zugänglicheren und öffentlich zugänglichen Ort als Ihrem persönlichen Entwicklungscomputer hosten.

Bis jetzt haben Sie in einer Entwicklungsumgebung gearbeitet, Express/Node als Webserver verwendet, um Ihre Seite im lokalen Browser/Netzwerk zu teilen, und Ihre Website mit (unsicheren) Entwicklungseinstellungen betrieben, die Debugging und andere private Informationen preisgeben. Bevor Sie eine Website extern hosten können, müssen Sie:

• Eine Umgebung für das Hosting der Express-App auswählen.
• Einige Änderungen an Ihren Projekteinstellungen vornehmen.
• Eine produktionsfähige Infrastruktur für die Bereitstellung Ihrer Website einrichten.

Dieses Tutorial bietet einige Anleitungen zu Ihren Optionen bei der Auswahl eines Hosting-Anbieters, einen kurzen Überblick über das, was Sie tun müssen, um Ihre Express-App bereitzumachen, und ein funktionierendes Beispiel, wie Sie die LocalLibrary-Website beim Cloud-Hosting-Service Railway installieren.

Die Produktionsumgebung ist die Umgebung, die vom Serverrechner bereitgestellt wird, auf dem Sie Ihre Website zur externen Nutzung betreiben. Die Umgebung umfasst:

• Computerhardware, auf der die Website läuft.
• Betriebssystem (z. B. Linux oder Windows).
• Programmiersprachen-Laufzeit und Framework-Bibliotheken, auf denen Ihre Website geschrieben ist.
• Webserver-Infrastruktur, möglicherweise einschließlich eines Webservers, Reverse-Proxys, Load Balancers etc.
• Datenbanken, von denen Ihre Website abhängig ist.

Der Serverrechner könnte sich in Ihren Räumlichkeiten befinden und über eine schnelle Verbindung mit dem Internet verbunden sein, aber es ist viel üblicher, einen Computer zu verwenden, der „in der Cloud“ gehostet wird. Das bedeutet tatsächlich, dass Ihr Code auf einem entfernten Computer (oder möglicherweise einem „virtuellen“ Computer) im Rechenzentrum Ihres Hosting-Anbieters ausgeführt wird. Der Fernserver bietet in der Regel ein garantiertes Maß an Computerressourcen (z. B. CPU, RAM, Speicherkapazität usw.) und Internetverbindung zu einem bestimmten Preis.

Diese Art von fernzugänglicher Computer-/Netzwerk-Hardware wird als Infrastructure as a Service (IaaS) bezeichnet. Viele IaaS-Anbieter bieten Optionen, ein bestimmtes Betriebssystem vorzuninstallieren, auf das Sie dann die anderen Komponenten Ihrer Produktionsumgebung installieren müssen. Andere Anbieter bieten die Möglichkeit, vollständigere Umgebungen auszuwählen, die möglicherweise eine vollständige Node-Einrichtung enthalten.

Andere Hosting-Anbieter unterstützen Express im Rahmen eines Platform as a Service (PaaS) Angebots. Bei der Nutzung dieser Art von Hosting müssen Sie sich keine Sorgen um den größten Teil Ihrer Produktionsumgebung (Server, Load Balancer usw.) machen, da die Hostplattform diese für Sie übernimmt. Dies macht die Bereitstellung recht einfach, da Sie sich nur auf Ihre Webanwendung konzentrieren müssen und nicht auf andere Serverinfrastrukturen.

Einige Entwickler werden die erhöhte Flexibilität von IaaS gegenüber PaaS bevorzugen, während andere den reduzierten Wartungsaufwand und die einfachere Skalierung von PaaS schätzen werden. Wenn Sie anfangen, ist die Einrichtung Ihrer Website auf einem PaaS-System viel einfacher, und das werden wir in diesem Tutorial tun.

Es gibt zahlreiche Hosting-Anbieter, die entweder aktiv unterstützen oder gut mit Node (und Express) arbeiten. Diese Anbieter bieten verschiedene Umgebungstypen (IaaS, PaaS) und unterschiedliche Stufen von Computer- und Netzwerkressourcen zu unterschiedlichen Preisen.

Einige Dinge, die Sie bei der Wahl eines Hosts beachten sollten:

• Wie stark Ihre Website voraussichtlich frequentiert wird und die Kosten für die benötigten Daten- und Computerressourcen, um dieser Nachfrage gerecht zu werden.
• Unterstützungsebene für horizontale (Hinzufügen weiterer Maschinen) und vertikale (Upgrade auf leistungsfähigere Maschinen) Skalierung und die damit verbundenen Kosten.
• Die Standorte, an denen der Anbieter Rechenzentren hat und daher von wo der Zugriff voraussichtlich am schnellsten ist.
• Historische Betriebs- und Ausfallzeiten des Hosts.
• Bereitgestellte Tools zur Verwaltung der Seite – sind sie einfach zu verwenden und sicher (z. B. SFTP vs. FTP).
• Integrierte Frameworks zur Überwachung Ihres Servers.
• Bekannte Einschränkungen. Einige Hosts blockieren absichtlich bestimmte Dienste (z. B. E-Mail). Andere bieten in einigen Preisklassen nur eine bestimmte Anzahl von „Live-Stunden“ an oder bieten nur eine geringe Menge an Speicherplatz.
• Zusätzliche Vorteile. Einige Anbieter bieten kostenlose Domainnamen und Unterstützung für TLS-Zertifikate an, für die Sie sonst bezahlen müssten.
• Ob die „kostenlose“ Stufe, auf die Sie sich verlassen, mit der Zeit abläuft und ob die Kosten für den Wechsel zu einer teureren Stufe bedeuten, dass es besser gewesen wäre, von Anfang an einen anderen Dienst zu nutzen!

Die gute Nachricht, wenn Sie gerade anfangen, ist, dass es viele Websites gibt, die „kostenlose“ Computerumgebungen bereitstellen, die zur Bewertung und zum Testen gedacht sind. Diese sind normalerweise recht ressourcenschwache Umgebungen, und Sie müssen sich bewusst sein, dass sie nach einem Einführungzeitraum ablaufen können oder andere Beschränkungen haben. Sie eignen sich jedoch hervorragend zum Testen von Websites mit geringem Datenverkehr in einer gehosteten Umgebung und können einen einfachen Wechsel zu einem kostenpflichtigen Dienst ermöglichen, wenn Ihre Website stärker frequentiert wird. Beliebte Optionen in dieser Kategorie sind Glitch, Python Anywhere, Amazon Web Services, Microsoft Azure usw.

Die meisten Anbieter bieten auch eine „Basis-“ oder „Hobby-“ Stufe an, die für kleine Produktionswebsites gedacht ist und die nützlichere Rechenleistung und weniger Einschränkungen bietet. Railway, Heroku, DigitalOcean und Python Anywhere sind Beispiele beliebter Hosting-Anbieter, die eine relativ preisgünstige Basiscomputerschicht (im Bereich von 5 bis 10 USD pro Monat) anbieten.

Die Hauptpunkte, über die Sie nachdenken sollten, wenn Sie Ihre Website veröffentlichen, sind Websicherheit und Performance. Das Mindeste, was Sie tun sollten, ist, die Datenbankkonfiguration so zu ändern, dass Sie eine andere Datenbank für die Produktion verwenden und deren Anmeldedaten sichern, die Stapelüberlauf-Meldungen zu entfernen, die während der Entwicklung auf Fehlerseiten angezeigt werden, Ihr Logging aufzuräumen und die geeigneten Header zu setzen, um viele gängige Sicherheitsbedrohungen zu vermeiden.

In den folgenden Unterabschnitten skizzieren wir die wichtigsten Änderungen, die Sie an Ihrer App vornehmen sollten.

Bisher in diesem Tutorial haben wir eine einzige Entwicklungsdatenbank verwendet, deren Adresse und Anmeldedaten in app.js fest codiert sind. Da die Entwicklungsdatenbank keine Informationen enthält, die wir ungern preisgeben oder beschädigt sehen, besteht kein besonderes Risiko beim Leaken dieser Details. Wenn Sie jedoch mit echten Daten arbeiten, insbesondere mit personenbezogenen Benutzerdaten, ist der Schutz Ihrer Datenbank-Anmeldedaten sehr wichtig.

Aus diesem Grund möchten wir für die Produktion eine andere Datenbank verwenden als für die Entwicklung, und auch die Anmeldedaten der Produktionsdatenbank vom Quellcode trennen, sodass sie ordnungsgemäß geschützt werden können.

Wenn Ihr Hosting-Anbieter die Einrichtung von Umgebungsvariablen über eine Weboberfläche unterstützt (was viele tun), ist eine Möglichkeit, dies zu tun, den Server die Datenbank-URL aus einer Umgebungsvariablen holen zu lassen. Im Folgenden ändern wir die LocalLibrary-Website so, dass die Datenbank-URI aus einer Betriebssystem-Umgebungsvariablen gelesen wird, falls diese definiert wurde, und andernfalls die Entwicklungsdatenbank-URL verwendet wird.

Öffnen Sie app.js und finden Sie die Zeile, die die MongoDB-Verbindungsvariable setzt. Sie wird in etwa wie folgt aussehen:

const mongoDB =
  "mongodb+srv://your_user_name:your_password@cluster0.cojoign.mongodb.net/local_library?retryWrites=true&w=majority";

Ersetzen Sie die Zeile durch den folgenden Code, der process.env.MONGODB_URI verwendet, um den Verbindungsstring aus einer Umgebungsvariablen namens MONGODB_URI zu holen, falls diese gesetzt wurde (verwenden Sie Ihre eigene Datenbank-URL anstelle des Platzhalters unten).

// Set up mongoose connection
const mongoose = require("mongoose");
mongoose.set("strictQuery", false);

const dev_db_url =
  "mongodb+srv://your_user_name:your_password@cluster0.cojoign.mongodb.net/local_library?retryWrites=true&w=majority";
const mongoDB = process.env.MONGODB_URI || dev_db_url;

main().catch((err) => console.log(err));
async function main() {
  await mongoose.connect(mongoDB);
}

Wir können Stapelüberflüsse auf Fehlerseiten entfernen, indem wir die Umgebungsvariable NODE_ENV auf production setzen (standardmäßig ist sie auf 'development' gesetzt). Zusätzlich zu weniger umfangreichen Fehlermeldungen speichert das Setzen der Variable auf production Vorlagenansichten und CSS-Dateien, die aus CSS-Erweiterungen generiert wurden. Tests zeigen, dass das Setzen von NODE_ENV auf production die App-Performance um den Faktor drei verbessern kann!

Diese Änderung kann entweder durch Verwendung von export, einer Umgebungsdatei oder dem OS-Initialisierungssystem vorgenommen werden.

Logging-Aufrufe können sich auf eine Website mit hohem Datenverkehr auswirken. In einer Produktionsumgebung müssen Sie möglicherweise die Website-Aktivität protokollieren (z. B. Verkehrsüberwachung oder API-Aufrufe protokollieren), aber Sie sollten versuchen, die Menge des hinzugefügten Loggings zu minimieren, die zu Debugging-Zwecken hinzugefügt wurde.

Eine Möglichkeit, das Debug-Logging in der Produktion zu minimieren, ist die Verwendung eines Moduls wie debug, das Ihnen ermöglicht, welches Logging ausgeführt wird, indem Sie eine Umgebungsvariable setzen. Das folgende Codefragment zeigt, wie Sie "author" Logging einrichten könnten. Die Debug-Variable wird mit dem Namen 'author' deklariert, und das Präfix "author" wird automatisch für alle Logs dieses Objekts angezeigt.

const debug = require("debug")("author");

// Display Author update form on GET.
exports.author_update_get = asyncHandler(async (req, res, next) => {
  const author = await Author.findById(req.params.id).exec();
  if (author === null) {
    // No results.
    debug(`id not found on update: ${req.params.id}`);
    const err = new Error("Author not found");
    err.status = 404;
    return next(err);
  }

  res.render("author_form", { title: "Update Author", author: author });
});

Anschließend können Sie eine bestimmte Menge an Logs aktivieren, indem Sie sie als durch Kommas getrennte Liste in der Umgebungsvariablen DEBUG angeben. Sie können die Variablen zum Anzeigen von author- und book-Logs wie gezeigt setzen (Wildcard-Zeichen werden ebenfalls unterstützt).

#Windows
set DEBUG=author,book

#Linux
export DEBUG="author,book"

Wenn Sie die Website-Aktivität protokollieren müssen, können Sie eine Loggingbibliothek wie Winston oder Bunyan verwenden. Weitere Informationen zu diesem Thema finden Sie unter: Produktions-Best-Practices: Leistung und Zuverlässigkeit.

Webserver können oft die HTTP-Antwort, die an einen Client gesendet wird, komprimieren und dadurch die Zeit erheblich reduzieren, die der Client benötigt, um die Seite zu erhalten und zu laden. Die verwendete Komprimierungsmethode hängt von den Dekomprimierungsmethoden ab, die der Client in der Anfrage angibt (die Antwort wird unkomprimiert gesendet, wenn keine Komprimierungsmethoden unterstützt werden).

Fügen Sie dies Ihrer Website mit compression Middleware hinzu. Installieren Sie dies im Stammverzeichnis Ihres Projekts, indem Sie den folgenden Befehl ausführen:

npm install compression

Öffnen Sie ./app.js und laden Sie die Komprimierungsbibliothek wie gezeigt. Fügen Sie die Komprimierungsbibliothek mit der use() Methode zur Middleware-Kette hinzu (dies sollte vor allen Routen erscheinen, die Sie komprimieren möchten – in diesem Fall alle!)

const catalogRouter = require("./routes/catalog"); // Import routes for "catalog" area of site
const compression = require("compression");

// Create the Express application object
const app = express();

// …

app.use(compression()); // Compress all routes

app.use(express.static(path.join(__dirname, "public")));

app.use("/", indexRouter);
app.use("/users", usersRouter);
app.use("/catalog", catalogRouter); // Add catalog routes to middleware chain.

// …

Helmet ist ein Middleware-Paket. Es kann die entsprechenden HTTP-Header setzen, die helfen, Ihre App vor bekannten Web-Schwachstellen zu schützen (siehe die Dokumentation für weitere Informationen zu den Headern, die es setzt, und den Schwachstellen, die es schützt).

Installieren Sie dies im Stammverzeichnis Ihres Projekts, indem Sie den folgenden Befehl ausführen:

npm install helmet

Öffnen Sie ./app.js und laden Sie die helmet Bibliothek wie gezeigt. Fügen Sie dann das Modul mit der use() Methode zur Middleware-Kette hinzu.

const compression = require("compression");
const helmet = require("helmet");

// Create the Express application object
const app = express();

// Add helmet to the middleware chain.
// Set CSP headers to allow our Bootstrap and jQuery to be served
app.use(
  helmet.contentSecurityPolicy({
    directives: {
      "script-src": ["'self'", "code.jquery.com", "cdn.jsdelivr.net"],
    },
  }),
);

// …

Wir hätten normalerweise einfach app.use(helmet()); eingefügt, um den Teil der sicherheitsbezogenen Header hinzuzufügen, die für die meisten Websites sinnvoll sind. In der LocalLibrary-Basisvorlage enthalten wir jedoch einige Bootstrap- und jQuery-Skripte. Diese verletzen die Standard- Content Security Policy (CSP) von Helmet, die das Laden von Cross-Site-Skripten nicht erlaubt. Um das Laden dieser Skripte zu ermöglichen, ändern wir die Helmet-Konfiguration, sodass es CSP-Direktiven setzt, die das Laden von Skripten von den angegebenen Domains erlauben. Für Ihren eigenen Server können Sie spezifische Header nach Bedarf hinzufügen/deaktivieren, indem Sie die Anleitung zur Verwendung von Helmet hier befolgen.

Express-rate-limit ist ein Middleware-Paket, das verwendet werden kann, um wiederholte Anfragen an APIs und Endpunkte zu begrenzen. Es gibt viele Gründe, warum übermäßige Anfragen an Ihre Website gestellt werden könnten, wie z. B. Denial-of-Service-Angriffe, Brute-Force-Angriffe oder sogar nur ein Client oder Skript, das sich nicht wie erwartet verhält. Abgesehen von Leistungsproblemen, die durch zu viele Anfragen entstehen können und Ihren Server verlangsamen, könnten Ihnen auch Kosten für den zusätzlichen Datenverkehr entstehen. Dieses Paket kann verwendet werden, um die Anzahl der Anfragen zu begrenzen, die an eine bestimmte Route oder eine Gruppe von Routen gestellt werden können.

Installieren Sie dies im Stammverzeichnis Ihres Projekts, indem Sie den folgenden Befehl ausführen:

npm install express-rate-limit

Öffnen Sie ./app.js und laden Sie die express-rate-limit Bibliothek wie gezeigt. Fügen Sie dann das Modul mit der use() Methode zur Middleware-Kette hinzu.

const compression = require("compression");
const helmet = require("helmet");

const app = express();

// Set up rate limiter: maximum of twenty requests per minute
const RateLimit = require("express-rate-limit");
const limiter = RateLimit({
  windowMs: 1 * 60 * 1000, // 1 minute
  max: 20,
});
// Apply rate limiter to all requests
app.use(limiter);

// …

Der obige Befehl begrenzt alle Anfragen auf 20 pro Minute (Sie können dies nach Bedarf ändern).

Node-Version festlegen

Für Node-Anwendungen, einschließlich Express, enthält die package.json Datei alles, was ein Hosting-Anbieter benötigt, um Abhängigkeiten der Applikation und die Einstiegsdatei zu ermitteln.

Die einzige wichtige Information, die in unserer aktuellen package.json fehlt, ist die von der Bibliothek benötigte Node-Version. Sie können die bei der Entwicklung verwendete Node-Version ermitteln, indem Sie den Befehl:

>node --version
v16.17.1

Öffnen Sie package.json, und fügen Sie diese Information als engines > node wie gezeigt hinzu (unter Verwendung der Versionsnummer Ihres Systems).

  "engines": {
    "node": ">=16.17.1"
  },

Der Hosting-Service unterstützt möglicherweise nicht die spezifisch angegebene Node-Version, aber diese Änderung sollte sicherstellen, dass er versucht, eine Version mit derselben Hauptversionsnummer oder einer neueren Version zu verwenden.

Beachten Sie, dass es andere Möglichkeiten geben kann, die Node-Version für verschiedene Hosting-Dienste anzugeben, aber der package.json Ansatz wird weithin unterstützt.

Abhängigkeiten beschaffen und erneut testen

Bevor wir fortfahren, lassen Sie uns die Seite erneut testen und sicherstellen, dass sie von unseren Änderungen nicht betroffen ist.

Zuerst müssen wir unsere Abhängigkeiten abrufen. Sie können dies tun, indem Sie den folgenden Befehl in Ihrem Terminal im Stammverzeichnis des Projekts ausführen:

npm install

Führen Sie nun die Seite aus (siehe Testen der Routen für die relevanten Befehle) und prüfen Sie, ob sich die Seite noch so verhält, wie Sie es erwarten.

Viele Hosting-Dienste ermöglichen es Ihnen, Projekte aus einem lokalen Repository oder von cloud-basierten Quellcode-Verwaltungsplattformen zu importieren und/oder zu synchronisieren. Dies kann die Bereitstellung und die iterative Entwicklung erheblich erleichtern.

Für dieses Tutorial richten wir ein GitHub Konto und Repository für die Bibliothek ein und verwenden das git Werkzeug, um unseren Quellcode hochzuladen.

Die Schritte sind:

1. Besuchen Sie https://github.com/ und erstellen Sie ein Konto.

2. Sobald Sie angemeldet sind, klicken Sie auf den + Link in der oberen Toolbar und wählen New repository.

3. Füllen Sie alle Felder in diesem Formular aus. Obwohl diese nicht zwingend sind, werden sie stark empfohlen.

   • Geben Sie einen neuen Repository-Namen (z. B. express-locallibrary-tutorial) und eine Beschreibung ein (z. B. "Local Library Webseite geschrieben in Express (Node)").
   • Wählen Sie Node in der Auswahlliste Add .gitignore aus.
   • Wählen Sie Ihre bevorzugte Lizenz in der Auswahlliste Add license aus.
   • Aktivieren Sie Initialize this repository with a README.

   Warnung: Der Standardzugriff "Public" macht allen Quellcode – einschließlich Ihres Datenbank-Benutzernamens und Passwortes – für jeden im Internet sichtbar! Stellen Sie sicher, dass der Quellcode Anmeldedaten nur aus Umgebungsvariablen liest und keine Anmeldedaten fest codiert sind.

   Andernfalls wählen Sie die "Private" Option, um nur ausgewählten Personen den Zugriff auf den Quellcode zu ermöglichen.

4. Drücken Sie Create repository.

5. Klicken Sie auf die grüne Schaltfläche Clone or download auf Ihrer neuen Repository-Seite.

6. Kopieren Sie den URL-Wert aus dem Textfeld im Dialogfenster, das sich öffnet. Wenn Sie den Repositories-Namen "express-locallibrary-tutorial" verwendet haben, sollte die URL in etwa so aussehen: https://github.com/<your_git_user_id>/express-locallibrary-tutorial.git.

Nun, da das Repository ("Repo") auf GitHub erstellt wurde, möchten wir es auf unseren lokalen Computer klonen (kopieren):

1. Installieren Sie git für Ihren lokalen Computer (Sie können Versionen für verschiedene Plattformen hier finden).

2. Öffnen Sie ein Befehlszeilenfenster/Terminal und klonen Sie Ihr Repo mit der oben kopierten URL:

   bash

   git clone https://github.com/<your_git_user_id>/express-locallibrary-tutorial.git
   

   Dies erstellt das Repository im aktuellen Verzeichnis.

3. Navigieren Sie in den Repo-Ordner.

   bash

   cd express-locallibrary-tutorial
   

Kopieren Sie dann Ihre Anwendungs-Quellen in den Repo-Ordner, fügen Sie sie mit git dem Repo hinzu und laden Sie sie auf GitHub hoch:

1. Kopieren Sie Ihre Express-Anwendung in diesen Ordner (ohne /node_modules, das Abhängigkeits-Dateien enthält, die Sie bei Bedarf von npm abrufen sollten).

2. Öffnen Sie ein Befehlszeilenfenster/Terminal und verwenden Sie den add Befehl, um alle Dateien zu git hinzuzufügen.

   bash

   git add -A
   

3. Verwenden Sie den status Befehl, um zu prüfen, ob alle Dateien, die Sie commit wollen, korrekt sind (Sie möchten Quellcode-Daten hinzufügen, nicht Binärdateien, temporäre Dateien etc.). Es sollte ein wenig wie die folgende Liste aussehen.

   bash

   git status
   

   On branch main
   Your branch is up-to-date with 'origin/main'.
   Changes to be committed:
     (use "git reset HEAD <file>..." to unstage)
   
           new file:   ...
   

4. Wenn Sie zufrieden sind, committen Sie die Dateien zu Ihrem lokalen Repo. Dies entspricht der Bestätigung der Änderungen und deren offizielle Integration in das lokale Repo.

   bash

   git commit -m "First version of application moved into GitHub"
   

5. An dieser Stelle ist das entfernte Repo nicht verändert worden. Der letzte Schritt besteht darin, Ihr lokales Repo mit dem folgenden Befehl mit dem entfernten GitHub-Repo zu synchronisieren (push).

   bash

   git push origin main
   

Wenn dieser Vorgang abgeschlossen ist, sollten Sie zur Seite auf GitHub zurückkehren können, auf der Sie Ihr Repo erstellt haben, die Seite aktualisieren und sehen, dass Ihre gesamte Anwendung jetzt hochgeladen wurde. Sie können Ihr Repo weiterhin aktualisieren, während sich Dateien ändern, indem Sie diesen add/commit/push-Zyklus verwenden.

Dies ist ein guter Zeitpunkt, um ein Backup Ihrer „Vanille“ zu erstellen – obwohl einige der Änderungen, die wir in den folgenden Abschnitten vornehmen, nützlich für die Bereitstellung auf jedem Hosting-Dienst sein könnten (oder für die Entwicklung), andere möglicherweise nicht. Sie können dies auf der Befehlszeile mit git tun:

# Create branch vanilla_deployment from the current branch (main)
git checkout -b vanilla_deployment

# Push the new branch to GitHub
git push origin vanilla_deployment

# Switch back to main
git checkout main

# Make any further changes in a new branch
git pull upstream main # Merge the latest changes from GitHub
git checkout -b my_changes # Create a new branch

Dieser Abschnitt bietet eine praktische Demonstration, wie man die LocalLibrary auf Glitch hostet.

Wir wählen Glitch aus mehreren Gründen:

• Glitch hat einen kostenlosen Starterplan, der wirklich kostenlos ist, wenn auch mit einigen Einschränkungen. Dass es erschwinglich für alle Entwickler ist, ist für MDN sehr wichtig!

• Glitch kümmert sich um die Infrastruktur, sodass Sie dies nicht tun müssen. Sich nicht um Server, Load Balancer, Reverse Proxys usw. kümmern zu müssen, macht es viel einfacher, anzufangen.

• Die Fähigkeiten und Konzepte, die Sie beim Verwenden von Glitch lernen, lassen sich übertragen.

• Die Einschränkungen des Dienstes und des Plans beeinträchtigen uns bei der Verwendung von Glitch für das Tutorial nicht wirklich. Zum Beispiel:

  • Der Starterplan bietet nur 1000 "Projektstunden" pro Monat, die monatlich zurückgesetzt werden. Dies wird verwendet, wenn Sie die Seite aktiv bearbeiten oder if jemand darauf zugreift. Wenn niemand auf die Seite zugreift oder diese bearbeitet wird, schläft sie.
  • Die Starterplan-Umgebung hat eine begrenzte Menge an Container-RAM und Speicherplatz. Es gibt mehr als genug für das Tutorial, insbesondere weil unsere Datenbank woanders gehostet wird.
  • Benutzerdefinierte Domains werden nicht gut unterstützt (zum Zeitpunkt der Erstellung).
  • Weitere Einschränkungen finden sich auf der Seite zu technischen Einschränkungen von Glitch.

Obwohl Glitch für die Hosting-Demonstration geeignet ist, sollten Sie sich die Zeit nehmen, um festzustellen, ob es für Ihre eigene Website geeignet ist.

Glitch bietet eine webbasierte Schnittstelle, in der Sie Projekte aus Startervorlagen erstellen oder aus GitHub importieren und dann die Projektdateien hinzufügen und bearbeiten können. Wenn Sie Änderungen vornehmen, wird das Projekt in seinem eigenen isolierten und unabhängigen virtualisierte Container kompiliert und ausgeführt.

Wie das alles „unter der Haube“ funktioniert, ist ein Rätsel – Glitch sagt es nicht. Klar ist, dass solange Sie eine recht standardisierte nodejs-Webanwendung erstellen (z. B. durch die Verwendung von package.json zur Verwaltung Ihrer Abhängigkeiten), und nicht mehr Ressourcen verbrauchen, als in den technischen Einschränkungen aufgeführt sind, Ihre Anwendung „einfach funktionieren“ sollte.

Sobald die Anwendung ausgeführt wird, kann sie für die Produktion eingerichtet werden, indem private Daten in einer .env Datei angegeben werden. Die geheimen Daten werden von der Anwendung als Umgebungsvariablen gelesen, welche, wie Sie sich aus einem vorherigen Abschnitt erinnern, ist, wie wir unsere Anwendung konfiguriert haben, um ihre Datenbank-URL zu erhalten. Beachten Sie, dass die Variablen geheim sind: die .env sollte nicht in Ihr GitHub-Repository aufgenommen werden.

Die Glitch-Bearbeitungsansicht bietet auch Terminal-Zugriff auf die Web-App-Umgebung, die Sie verwenden können, um mit der Web-App so zu arbeiten, als würde sie auf Ihrem lokalen Computer laufen.

Das ist alles, was Sie an Übersicht brauchen, um anzufangen. Als Nächstes richten wir ein Glitch-Konto ein, laden das Bibliotheksprojekt von GitHub hoch und verbinden es mit einer Datenbank.

Um Glitch zu verwenden, müssen Sie zunächst ein Konto erstellen:

• Gehen Sie zu glitch.com und klicken Sie auf die Schaltfläche Sign up in der oberen Toolbar.
• Wählen Sie GitHub im Popup, um sich mit Ihren GitHub-Anmeldedaten anzumelden.
• Sie werden dann in das Glitch-Dashboard eingeloggt: https://glitch.com/dashboard.

Hosting-Anbieter unterstützen häufig eine Hauptversion der neuesten Node.js-Releases. Wenn die genaue "Neben"-Version, die Sie in Ihrer package.json Datei angegeben haben, nicht unterstützt wird, gehen sie in der Regel zur nächsten unterstützten Version über (und oft funktioniert das einfach).

Leider ist zum Zeitpunkt des Schreibens die höchste unterstützte Version auf Glitch Node.js 16. Wenn Sie mit Node.js 17 oder höher entwickelt haben, sollten Sie die in Ihrer package.json Datei verwendete Version wie gezeigt reduzieren. Sie müssen auch erneut testen:

  "engines": {
    "node": ">=v16"
  },

Glitch plant, node zu aktualisieren und in Zukunft besser auf dem neuesten Stand zu halten – und es mag sein, dass der Versionslimitierung nicht mehr existiert, wenn Sie diesen Artikel lesen. Anstatt die node Version herunterzustufen, könnten Sie Ihr Projekt hochladen, um zu sehen, ob es gebaut wird. Wenn Fehler auftreten und Ihre Anwendung nicht geladen wird, sollten Sie versuchen, die node Version in der Glitch-Editor package.json auf >=v16 zu setzen.

ls -l /opt/nvm/versions/node | grep '^d' | awk '{ print $9 }'

Als Nächstes importieren wir das Bibliotheksprojekt von GitHub. Wählen Sie zuerst die Dashboard Option im oberen Menü der Seite aus und klicken Sie dann auf die Schaltfläche New project. Glitch zeigt eine Liste von Optionen für das neue Projekt an; wählen Sie Import from GitHub.

Ein Popup erscheint. Geben Sie die URL Ihres GitHub-Bibliotheks-Repositorys in das Popup ein und drücken Sie OK. Unten haben wir das Repo für das durchgearbeitete Projekt eingegeben.

Glitch importiert dann das Projekt und zeigt Fortschrittsmeldungen an. Nach Abschluss wird die Bearbeitungsansicht für das neue Projekt angezeigt, wie unten gezeigt.

Sie können die Live-Site-URL erhalten, indem Sie die Schaltfläche Share auswählen.

Öffnen Sie ein neues Browser-Tab und kopieren Sie den Link für die Live-Seite in die Adressleiste. Die LocalLibrary-Seite sollte geöffnet werden und Daten aus der Entwicklungsdatenbank anzeigen.

Sie sollten für die Produktion eine andere Datenbank verwenden als für die Entwicklung. Obwohl Glitch nur SQLite-Datenbanken hostet (und wir eingerichtet sind, um MongoDB zu verwenden), bieten viele andere Websites MongoDB-Datenbanken als Dienst an.

Eine Möglichkeit besteht darin, den Anweisungen zum Einrichten der MongoDB-Datenbank aus einem früheren Teil des Tutorials zu folgen, um eine neue Produktionsdatenbank einzurichten.

Um die Produktionsdatenbank für die Bibliotheksanwendung zugänglich zu machen, öffnen Sie die .env Datei in der Editoransicht für das Projekt. Geben Sie die Datenbank-URL-Variablen MONGODB_URI und die URL Ihrer Produktionsdatenbank ein. Die Website aktualisiert sich, während Sie Werte in den Editor eingeben.

Sie erinnern sich aus einem vorhergehenden Abschnitt, dass wir NODE_ENV auf 'production' setzen müssen, um unsere Leistung zu verbessern und weniger ausführliche Fehlermeldungen zu generieren. Wir tun dies in derselben Datei, in der wir die MONGODB_URI Variable setzen.

Öffnen Sie .env und fügen Sie eine NODE_ENV Variable mit dem Wert production hinzu (siehe den Screenshot im vorherigen Abschnitt).

Die Local Library-Anwendung ist nun eingerichtet und für den Produktionseinsatz konfiguriert. Sie können Daten über die Website-Oberfläche hinzufügen, und sie sollte so funktionieren wie während der Entwicklung (jedoch mit weniger Debug-Informationen für ungültige Seiten).

Glitch ermöglicht effektives Debugging. Einige der Dinge, die Sie tun können, sind:

• Wählen Sie die Schaltfläche "Logs" am unteren Rand der Bearbeitungsansicht, um Log-Informationen von Ihrem Server, wie z. B. Konsolen-Log-Ausgaben, zu sehen.
• Wählen Sie die Schaltfläche "Terminal" am unteren Rand der Bearbeitungsansicht, um ein Terminal in der Hosting-Umgebung zu öffnen. Sie können dies verwenden, um Befehle und Werkzeuge in der Umgebung auszuführen. Zum Beispiel könnten Sie node -v verwenden, um die Node-Version zu überprüfen.
• Interaktives Debugging in VS Code mit der GLITCH-Erweiterung für VS Code.

Dieser Abschnitt bietet eine praktische Demonstration, wie man die LocalLibrary auf Railway installiert.

Railway ist eine attraktive Hosting-Option aus mehreren Gründen:

• Railway kümmert sich um den größten Teil der Infrastruktur, sodass Sie dies nicht tun müssen. Sich nicht um Server, Load Balancer, Reverse Proxys usw. kümmern zu müssen, macht es viel einfacher, anzufangen.
• Railway hat einen Fokus auf Entwicklererfahrung für Entwicklung und Bereitstellung, was zu einer schnelleren und milderen Lernkurve führt als bei vielen anderen Alternativen.
• Die Fähigkeiten und Konzepte, die Sie beim Verwenden von Railway lernen, lassen sich übertragen. Obwohl Railway einige hervorragende neue Funktionen bietet, verwenden viele andere beliebte Hosting-Dienste ähnliche Ideen und Ansätze.
• Railway-Dokumentation ist klar und vollständig.
• Der Dienst scheint sehr zuverlässig zu sein, und wenn Ihnen Railway gefällt, ist die Preisgestaltung vorhersehbar und die Skalierung Ihrer App ist sehr einfach.

Sie sollten sich die Zeit nehmen, um herauszufinden, ob Railway für Ihre eigene Website geeignet ist.

Webanwendungen werden jeweils in ihrem eigenen isolierten und unabhängigen virtualisierten Container ausgeführt. Um Ihre Anwendung auszuführen, muss Railway in der Lage sein, die entsprechende Umgebung und die Abhängigkeiten einzurichten und auch zu verstehen, wie sie gestartet wird.

Railway macht dies einfach, da es viele verschiedene Webanwendungs-Frameworks und Umgebungen basierend auf deren Verwendung von "Standard-Konventionen" automatisch erkennen und installieren kann. Zum Beispiel erkennt Railway Node-Anwendungen, da sie eine package.json Datei besitzen, und kann den für den Build verwendeten Paketmanager aus der "Lock"-Datei bestimmen. Zum Beispiel, wenn die Anwendung die Datei package-lock.json enthält, weiß Railway, dass npm verwendet wird, um die Pakete zu installieren, während wenn es yarn.lock findet, weiß es, dass yarn verwendet wird. Nachdem alle Abhängigkeiten installiert wurden, sucht Railway nach Skripts mit den Namen "build" und "start" in der Paketdatei und verwendet diese, um den Code zu bauen und auszuführen.

Sobald die Anwendung läuft, kann sie sich mit Informationen konfigurieren, die in Umgebungsvariablen bereitgestellt werden. Zum Beispiel muss eine Anwendung, die eine Datenbank verwendet, die Adresse mit einer Variablen abrufen. Der Datenbankdienst selbst kann von Railway oder einem anderen Anbieter gehostet werden.

Entwickler interagieren mit Railway über die Railway-Site und ein spezielles Command Line Interface (CLI) Werkzeug. Das CLI ermöglicht es Ihnen, ein lokales GitHub-Repository mit einem Railway-Projekt zu assoziieren, das Repository vom lokalen Branch zur Live-Site hochzuladen, die Protokolle des laufenden Prozesses zu inspizieren, Konfigurationsvariablen zu setzen und abzurufen und vieles mehr. Eine der nützlichsten Funktionen ist, dass Sie das CLI verwenden können, um Ihr lokales Projekt mit denselben Umgebungsvariablen wie das Live-Projekt auszuführen.

Das ist alles, was Sie an Übersicht brauchen, um die App auf Railway zu deployen. Als Nächstes richten wir ein Railway-Konto ein, installieren unsere Website und eine Datenbank und probieren den Railway-Client aus.

Um Railway zu verwenden, müssen Sie zunächst ein Konto erstellen:

• Gehen Sie zu railway.com und klicken Sie auf den Login Link in der oberen Toolbar.
• Wählen Sie GitHub im Popup, um sich mit Ihren GitHub-Anmeldedaten anzumelden.
• Möglicherweise müssen Sie dann in Ihre E-Mails gehen und Ihr Konto verifizieren.
• Sie werden dann in das Railway.com-Dashboard eingeloggt: https://railway.com/dashboard.

Als Nächstes richten wir Railway ein, um unsere Bibliothek von GitHub bereitzustellen. Wählen Sie zuerst die Dashboard Option im oberen Menü der Seite aus und klicken Sie dann auf die Schaltfläche New Project:

Railway zeigt eine Liste von Optionen für das neue Projekt an, einschließlich der Option, ein Projekt aus einer Vorlage zu deployen, die zuerst in Ihrem GitHub-Konto erstellt wurde, und einer Reihe von Datenbanken. Wählen Sie Deploy from GitHub repo.

Alle Projekte in den GitHub-Repos, die Sie während der Einrichtung mit Railway geteilt haben, werden angezeigt. Wählen Sie Ihr GitHub-Repository für die lokale Bibliothek aus: <user-name>/express-locallibrary-tutorial.

Bestätigen Sie Ihre Bereitstellung, indem Sie Deploy Now auswählen.

Railway lädt und deployt dann Ihr Projekt, wobei der Fortschritt auf der Registerkarte Bereitstellungen angezeigt wird. Wenn die Bereitstellung erfolgreich abgeschlossen wurde, sehen Sie einen Bildschirm wie den unten gezeigten.

Wählen Sie nun die Registerkarte Settings aus, scrollen Sie dann nach unten zum Abschnitt Domains und drücken Sie die Schaltfläche Generate Domain.

Dies veröffentlicht die Website und setzt die Domain an die Stelle der Schaltfläche, wie unten gezeigt.

Wählen Sie die Domain-URL aus, um Ihre Bibliotheksanwendung zu öffnen. Beachten Sie, dass wir kein Produktion-Datenbank spezifiziert haben, die Local Library daher mit Ihren Entwicklungsdaten geöffnet wird.

Anstatt unsere Entwicklungsdaten zu verwenden, lassen Sie uns als Nächstes eine Produktions-MongoDB-Datenbank erstellen, um sie stattdessen zu verwenden. Wir werden die Datenbank als Teil des Railway-Anwendungsprojekts erstellen, obwohl nichts dagegen spricht, sie in einem eigenen separaten Projekt zu erstellen, oder tatsächlich eine MongoDB Atlas-Datenbank für Produktionsdaten zu verwenden, wie Sie es für die Entwicklungsdatenbank getan haben.

Auf Railway, wählen Sie die Dashboard Option aus dem oberen Menü der Seite und wählen Sie dann Ihr Anwendungsprojekt. Zu diesem Zeitpunkt enthält es nur einen einzigen Dienst für Ihre Anwendung (dieser kann ausgewählt werden, um Variablen und andere Dienstdetails festzulegen). Wählen Sie die Schaltfläche New aus, die verwendet wird, um Dienste zum aktuellen Projekt hinzuzufügen.

Wählen Sie Datenbank aus, wenn die Art des hinzuzufügenden Dienstes abgefragt wird:

Wählen Sie dann Add MongoDB aus, um mit dem Hinzufügen der Datenbank zu beginnen

Railway erstellt dann einen Dienst mit einer leeren Datenbank im selben Projekt. Nach Abschluss sehen Sie nun sowohl den Anwendungs- als auch den Datenbankdienst in der Projektansicht.

Wählen Sie den MongoDB-Dienst aus, um Informationen über die Datenbank anzuzeigen. Öffnen Sie die Variablen Registerkarte und kopieren Sie die "Mongo_URL" (dies ist die Adresse der Datenbank).

Um dies für die Bibliotheksanwendung zugänglich zu machen, müssen wir es als Umgebungsvariable zum Anwendungsprozess hinzufügen. Öffnen Sie zunächst den Anwendungsdienst. Dann wählen Sie die Variablen Registerkarte aus und drücken die Schaltfläche Neue Variable.

Geben Sie den Variablennamen MONGODB_URI und die Verbindungs-URL, die Sie für die Datenbank kopiert haben, ein (MONGODB_URI ist der Name der Umgebungsvariable, aus der wir die Anwendung konfiguriert haben, um die Datenbankadresse zu lesen). Dies wird in etwa wie der unten gezeigte Bildschirm aussehen.

Wählen Sie Hinzufügen, um die Variable hinzuzufügen.

Railway startet Ihre App neu, wenn es Variablen aktualisiert. Wenn Sie jetzt die Startseite überprüfen, sollte es null Werte für Ihre Objekte zählen, da die oben genannten Änderungen bedeuten, dass wir jetzt eine neue (leere) Datenbank verwenden.

Sie erinnern sich aus einem vorhergehenden Abschnitt, dass wir NODE_ENV auf 'production' setzen müssen, um unsere Leistung zu verbessern und weniger ausführliche Fehlermeldungen zu generieren. Wir können dies auf dem gleichen Bildschirm tun, auf dem wir die MONGODB_URI Variable gesetzt haben.

Öffnen Sie den Anwendungsdienst. Dann wählen Sie die Variablen Registerkarte, wo Sie sehen werden, dass MONGODB_URI bereits definiert ist, und drücken die Schaltfläche Neue Variable.

Geben Sie NODE_ENV als Namen der neuen Variable ein und production als Namen des Environment. Drücken Sie dann die Hinzufügen-Schaltfläche.

Die Local Library-Anwendung ist nun eingerichtet und für den Produktionseinsatz konfiguriert. Sie können Daten über die Website-Oberfläche hinzufügen, und sie sollte so funktionieren wie während der Entwicklung (jedoch mit weniger Debug-Informationen für ungültige Seiten).

Laden Sie den Railway-Client für Ihr lokales Betriebssystem herunter und installieren Sie ihn, indem Sie den Anweisungen hier folgen.

Nachdem der Client installiert ist, können Sie Befehle ausführen. Einige der wichtigeren Operationen umfassen die Bereitstellung des aktuellen Verzeichnisses Ihres Computers zu einem zugeordneten Railway-Projekt (ohne es auf GitHub hochzuladen) und das Ausführen Ihres Projekts lokal mit denselben Einstellungen wie auf dem Produktionsserver.

Sie können eine Liste aller möglichen Befehle erhalten, indem Sie die folgende Eingabe im Terminal verwenden.

railway help

Der Railway-Client bietet den Logs-Befehl, um das Ende der Logs zu zeigen (ein vollständigeres Log ist auf der Website für jedes Projekt verfügbar):

railway logs

Das ist das Ende dieses Tutorials zur Einrichtung von Express-Apps in der Produktion und auch der Serie von Tutorials zur Arbeit mit Express. Wir hoffen, dass Sie sie nützlich fanden. Sie können sich eine vollständig durchgearbeitete Version des Quellcodes auf GitHub hier ansehen.

• Produktions-Best-Practices: Leistung und Zuverlässigkeit (Express-Dokumente)

• Produktions-Best-Practices: Sicherheit (Express-Dokumente)

• Railway-Dokumentation

  • CLI

• DigitalOcean

  • Express Tutorials
  • Node.js Tutorials

• Heroku

  • Einstieg auf Heroku mit Node.js (Heroku-Dokumente)
  • Bereitstellen von Node.js-Anwendungen auf Heroku (Heroku-Dokumente)
  • Heroku Node.js Unterstützung (Heroku-Dokumente)
  • Optimierung der Node.js-Anwendungskonkurrenz (Heroku-Dokumente)
  • Wie Heroku funktioniert (Heroku-Dokumente)
  • Dynos und der Dyno-Manager (Heroku-Dokumente)
  • Konfiguration und Konfigurationsvariablen (Heroku-Dokumente)
  • Grenzen (Heroku-Dokumente)

• Zurück
• Übersicht: Express Web Framework (Node.js/JavaScript)