Regenbogen - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

rainbows – Rackup-ähnlicher Befehl zum Starten von Rainbows!

ZUSAMMENFASSUNG

Regenbogen [-c CONFIG_FILE] [-E RACK_ENV] [-D] [RACKUP_FILE]

BESCHREIBUNG

A Rackup(1)-ähnlicher Befehl zum Starten von Rack-Anwendungen mit Rainbows!. Es wird erwartet
kann in Ihrem Anwendungsstammverzeichnis (APP_ROOT) gestartet werden, die Direktive „working_directory“ kann jedoch verwendet werden
in der CONFIG_FILE verwendet werden.

Während Regenbogen! benötigt eine Vielzahl von Befehlszeilenoptionen für die Kompatibilität mit Rubin(1) und
Rackup(1) wird empfohlen, sich an die wenigen in der angegebenen Befehlszeilenoptionen zu halten
SYNOPSIS und verwenden Sie die CONFIG_FILE so oft wie möglich.

RACKUP FILE

Der Standardwert ist „config.ru“ in APP_ROOT. Es sollte dieselbe Datei sein, die von verwendet wird Rackup(1)
und andere Rack-Launcher verwendet es die Rack::Builder DSL.

Eingebettete Befehlszeilenoptionen werden größtenteils auf Kompatibilität mit analysiert Rackup(1) aber
dringend abgeraten.

EINHORN OPTIONAL

-C, --Konfigurationsdatei KONFIGURATIONSDATEI
Pfad zur Unicorn-spezifischen Konfigurationsdatei. Die Konfigurationsdatei ist als Ruby implementiert
DSL, sodass Ruby-Code ausgeführt werden kann. Siehe RDoc/ri für Einhorn::Konfigurator
Klasse für die vollständige Liste der im DSL verfügbaren Anweisungen.

-D, --dämonisieren
Daemonisiert im Hintergrund ausführen. Der Prozess ist vom Controlling losgelöst
Terminal und stdin werden nach „/dev/null“ umgeleitet. Im Gegensatz zu vielen gängigen UNIX-Daemons
Wir chdir bei der Daemonisierung nicht auf „/“, um eine bessere Kontrolle darüber zu ermöglichen
Start-/Upgrade-Prozess. Sofern nicht in CONFIG_FILE, stderr und stdout angegeben
wird auch nach „/dev/null“ umgeleitet.

-IS, --env RACK_ENV
Führen Sie es unter dem angegebenen RACK_ENV aus. Weitere Einzelheiten finden Sie im Abschnitt RACK-UMGEBUNG.

- l, --hören ADRESSE
Hört auf eine bestimmte ADRESSE. ADRESSE kann in der Form HOST:PORT oder PATH vorliegen,
Unter HOST:PORT versteht man einen TCP-Socket und PATH soll ein Pfad zu einem UNIX sein
Domain-Socket. Standardmäßig ist „0.0.0.0:8080“ (alle Adressen auf TCP-Port 8080) Für
Produktionsbereitstellungen, wobei die „listen“-Direktive in CONFIG_FILE angegeben wird
empfohlen, da es eine Feinabstimmung der Sockeloptionen ermöglicht.

RACKUP KOMPATIBILITÄT OPTIONAL

-Ö, --Gastgeber HOST
Lauschen Sie auf einem TCP-Socket, der zu HOST gehört. Der Standardwert ist „0.0.0.0“ (alle Adressen). Wenn
Wird in der Befehlszeile mehrmals angegeben, gilt nur der zuletzt angegebene Wert
Wirkung. Diese Option existiert nur aus Kompatibilitätsgründen mit Rackup(1) Befehl, Verwendung
Stattdessen wird die Verwendung des Schalters „-l“/„--listen“ empfohlen.

-P, --Hafen PORT
Lauschen Sie auf dem angegebenen TCP-PORT, der Standardwert ist 8080. Bei mehrfacher Angabe
In der Befehlszeile wird nur der zuletzt angegebene Wert wirksam. Nur diese Option
existiert für die Kompatibilität mit dem Rackup(1) Befehl, Verwendung des Schalters „-l“/„--listen“.
wird stattdessen empfohlen.

-S, --Server SERVER
No-op, dies existiert nur aus Kompatibilitätsgründen mit Rackup(1).

RUBIN OPTIONAL

-e, --eval LINE
Bewerten Sie eine Zeile Ruby-Code. Diese Auswertung erfolgt sofort, wenn der Befehl
Zeile wird analysiert.

-D, --debuggen
Aktivieren Sie den Debug-Modus. Die Variable $DEBUG wird auf true gesetzt.

-w, --warnen
Aktivieren Sie ausführliche Warnungen. Die Variable $VERBOSE wird auf „true“ gesetzt.

-ICH, --enthalten PATH
Geben Sie $LOAD_PATH an. PATH wird $LOAD_PATH vorangestellt. Das Zeichen „:“ kann
kann zur Abgrenzung mehrerer Verzeichnisse verwendet werden. Diese Direktive kann mehr als verwendet werden
einmal. Änderungen an $LOAD_PATH werden sofort und in der Reihenfolge vorgenommen, in der sie durchgeführt werden
wurden in der Befehlszeile angegeben.

-R, --benötigen BIBLIOTHEK
erfordern eine bestimmte BIBLIOTHEK, bevor die Anwendung ausgeführt wird. Das „erfordern“
Die Anweisung wird sofort und in der Reihenfolge ausgeführt, in der sie angegeben wurden
Befehlszeile.

SIGNALE

Die folgenden UNIX-Signale können an den Masterprozess gesendet werden:

· HUP – Konfigurationsdatei und App neu laden und alle Mitarbeiter ordnungsgemäß neu starten

· INT/TERM – schnelles Herunterfahren, tötet alle Arbeiter sofort

· QUIT – ordnungsgemäßes Herunterfahren, wartet darauf, dass die Mitarbeiter ihre aktuelle Anfrage zuvor abgeschlossen haben
Fertigstellung.

· USR1 – Öffnen Sie alle Protokolle erneut, die dem Master und allen Arbeitern gehören. Siehe Unicorn::Util.reopen_logs
für das, was als Protokoll betrachtet wird.

· USR2 – Führen Sie die laufende Binärdatei erneut aus. Ein separater QUIT sollte an das Original gesendet werden
Der Vorgang wird ausgeführt, sobald sichergestellt ist, dass das Kind betriebsbereit ist.

· WINDE – stoppt die Arbeiter sanft, hält den Master jedoch am Laufen. Dies funktioniert nur für
dämonisierte Prozesse.

· TTIN – Erhöhen Sie die Anzahl der Arbeitsprozesse um eins

· TTOU – verringert die Anzahl der Arbeitsprozesse um eins

Siehe die SIGNALE (http://rainbows.rubyforge.org/SIGNALS.html) Dokument für eine vollständige Beschreibung
aller von Rainbows! verwendeten Signale.

RACK

Akzeptierte Werte von RACK_ENV und der Middleware, die sie automatisch laden (außerhalb von
RACKUP_FILE) entsprechen genau denen in Rackup(1):

· Entwicklung – lädt die Middleware Rack::CommonLogger, Rack::ShowExceptions und Rack::Lint

· Bereitstellung – lädt die Rack::CommonLogger-Middleware

· keine – lädt überhaupt keine Middleware und verlässt sich ausschließlich auf RACKUP_FILE

Alle nicht erkannten Werte für RACK_ENV werden als „none“ angenommen. Produktionsbereitstellungen sind
Für maximale Leistung wird dringend empfohlen, „Bereitstellung“ oder „Keine“ zu verwenden.

Beachten Sie, dass die Middlewares Rack::ContentLength und Rack::Chunked niemals von geladen werden
Standard. Bei Bedarf sollten sie einzeln in der RACKUP_FILE angegeben werden, einige davon
Frameworks erfordern sie nicht.

Nutzen Sie Regenbogen online über die Dienste von onworks.net