Verwendung des Thruster-Webservers für Ruby-Apps

Kürzlich habe ich einige Bereitstellungsskripte für eine Ruby-App eingerichtet, bei der ich wollte, dass der Server die SSL-Terminierung übernimmt.

Früher habe ich Caddy mit Reverse-Proxy für die App so eingerichtet:

# Caddyfile
yourdomain.com {
    reverse_proxy localhost:3000
    tls
}

Darüber hinaus würde ich Caddy normalerweise als eine der Abhängigkeiten in einer docker-compose.yml-Datei ausführen, um die Installation und Neuinstallation von allem zu vereinfachen.

Kürzlich hat Basecamp einen einfachen Reverse-Proxy-Server veröffentlicht, der alles verwaltet, was ich zum Bereitstellen von Ruby-Apps in einem Gem namens Thruster benötige.

Laut dem GitHub-Repo bietet dieser Server Folgendes:

• HTTP/2-Unterstützung
• Automatische TLS-Zertifikatsverwaltung mit Let's Encrypt
• Grundlegendes HTTP-Caching öffentlicher Assets
• X-Sendfile-Unterstützung und -Komprimierung, um statische Dateien effizient bereitzustellen

Für 99 % der verfügbaren Anwendungsfälle entspricht dies perfekt den Anforderungen. Und das Beste daran: Ich konnte dies im selben Container wie meine Ruby-App ausführen. Das bedeutet, dass ich keinen separaten Container benötige, um Caddy auszuführen.

Konfiguration

Das Juwel wird als „keine Konfiguration“-Software angegeben, und das ist fast wahr.

Tatsächlich müssen Sie Thruster immer noch (zumindest) angeben, für welche Domänen SSL-Zertifikate angefordert werden sollen.

Dies geschieht über die Umgebungsvariable TLS_DOMAIN.

Das Gute daran ist, dass es möglich ist, mehrere Domänen anzugeben, sodass Thruster automatisch die richtigen Let's Encrypt-Zertifikate für jede von ihnen anfordern kann.

Wenn meine App beispielsweise von domain1.com und domain2.com aus bereitgestellt wird, könnte ich sie einfach als TLD_DOMAIN=domain1.com,domain2.com angeben und Thruster würde das problemlos erkennen.

Laufendes Triebwerk

Um Thruster auszuführen, müssen Sie ihm lediglich den Befehl voranstellen, den Sie normalerweise zum Ausführen Ihrer Ruby-App verwenden.

Wenn Sie beispielsweise Rails verwenden, geben Sie normalerweise bin/rails server ein.

Die Modifikation für das Triebwerk wäre Schubbehälter/Schienenserver.

Ich glaube, das ist der Grund, dass ich Thruster so sehr mag. Bei Caddy musste ich einen Reverse-Proxy einrichten (oft mit Versuch und Irrtum mit dieser verdammten Caddy-Datei). Mit Thruster konnte ich alles in weniger als 3–5 Minuten einrichten.

Anwendungsfälle

Heutzutage gibt es viele Möglichkeiten, Webanfragen von Ruby- (und Rails-)Apps in Produktionsumgebungen zu bedienen.

1. Sie können einen Reverse-Proxy erstellen, beispielsweise mit Nginx oder Caddy.
2. Sie können Kamal verwenden (das in Version 2 Thruster verwendet).
3. Oder Sie können einfach Thruster verwenden und Docker den Dienst selbst überwachen lassen.

Ich denke, in den meisten Fällen sind die Optionen (1) und (2) am sinnvollsten, wenn es sich um Server handelt, die Sie kontrollieren.

Für (3) gibtein besonderer Anwendungsfall: selbst gehostete Anwendungen. Mit anderen Worten: Ruby-Apps, die Ihre Kunden auf ihrer eigenen Infrastruktur ausführen und bei denen sie die App installieren.

Der Unterschied zwischen den drei beschriebenen Optionen besteht darin, dass es in den Fällen (1) und (2) für den Entwickler einfach ist, hineinzugehen und die Dinge einfach neu zu konfigurieren.

Bei der Bereitstellung eines Docker-Images (wahrscheinlich das häufigste Szenario) für einen Kunden zum Selbsthosten kann eine Menge Dinge schief gehen.

Der Kunde ist beispielsweise möglicherweise nicht mit der Verwaltung seines eigenen Servers vertraut. Oder vielleicht möchte der Kunde nicht mit Reverse-Proxys herumspielen, damit alles funktioniert.

In diesen Fällen ist es einfacher, einfach einen Docker-Container zu übergeben, in dem die Dinge „einfach funktionieren“.

Ich bin bei der Entwicklung meiner selbst gehosteten E-Mail-Marketing-Software auf dieses Problem gestoßen, und zum Glück war Thruster verfügbar.

Da ich sowieso alles in Container gepackt habe und eine docker-compose.yml-Datei bereitstellte, sanken dadurch auch meine Containerabhängigkeiten von 4 auf 3, sodass ich nicht mehr Nginx oder Caddy ausführen musste.

Abschluss

Thruster ist eine ziemlich gute Alternative für die Verwaltung von Reverse-Proxys für Ihre Ruby-App.

Durch die einfache Option „Keine Konfiguration“ funktioniert es in vielen Szenarien sehr gut.

Für mich selbst ist dies der richtige Weg, wenn ich Ruby-Apps paketiere, die in Umgebungen ausgeführt werden müssen, die ich nicht kontrolliere (z. B. selbst gehostete Apps auf Kundencomputern).

Das obige ist der detaillierte Inhalt vonVerwendung des Thruster-Webservers für Ruby-Apps. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!