unicorn_rails – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

unicorn_rails – ein skript-/serverähnlicher Befehl zum Starten des Unicorn-HTTP-Servers

ZUSAMMENFASSUNG

unicorn_rails [-c CONFIG_FILE] [-E RAILS_ENV] [-D] [RACKUP_FILE]

BESCHREIBUNG

A Rackup(1)-ähnlicher Befehl zum Starten von Rails-Anwendungen mit Unicorn. Es wird erwartet, dass dies der Fall ist
in Ihrem Rails-Anwendungsstamm (RAILS_ROOT) gestartet, aber die Direktive „working_directory“.
kann in der CONFIG_FILE verwendet werden.

Es soll Benutzern von Rails 1.x und 2.y den Übergang zu Rack erleichtern, wird jedoch NICHT benötigt
für Rails 3-Anwendungen. Benutzern von Rails 3 wird die Nutzung empfohlen Einhorn(1) statt
unicorn_rails(1). Benutzer von Rails 1.x/2.y können ebenfalls verwenden Einhorn(1) statt
unicorn_rails(1).

Die äußere Schnittstelle ähnelt Rackup(1) Die Interna und das Standard-Middleware-Laden sind
Entworfen wie der mit Rails verteilte Skript-/Serverbefehl.

Während Unicorn aus Kompatibilitätsgründen eine Vielzahl von Befehlszeilenoptionen benötigt 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.

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. Verwendung eines Absoluten
Der Pfad für CONFIG_FILE wird empfohlen, da dadurch mehrere Instanzen von Unicorn erstellt werden
beim Betrachten leicht zu erkennen ps(1) Ausgabe.

-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. Dämonisierung wird überspringen Laden der
Rails::Rack::LogTailer Middleware unter Rails >= 2.3.x. Standardmäßig,
unicorn_rails(1) erstellt eine PID-Datei in „RAILS_ROOT/tmp/pids/unicorn.pid“. Sie
kann dies überschreiben, indem Sie die „pid“-Direktive angeben, um diese Unicorn-Konfiguration zu überschreiben
Datei.

-IS, --env RAILS_ENV
Unter dem angegebenen RAILS_ENV ausführen. Dadurch wird die Umgebungsvariable RAILS_ENV festgelegt.
Akzeptable Werte sind normalerweise genau die, die Sie in Ihrer Rails-Anwendung erwarten
„Entwicklung“ oder „Produktion“.

- 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 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.

--Weg PATH
Mountet die Rails-Anwendung unter dem angegebenen PATH (anstelle von „/“). Das ist
entspricht dem Festlegen der Umgebungsvariablen RAILS_RELATIVE_URL_ROOT. Das ist
Wird derzeit nur unter Rails 2.3 oder höher unterstützt.

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. Für Rails >= 2.3.x, dies
lädt die Rails::Rack::Debugger Middleware.

-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.

RACKUP FILE

Dies ist standardmäßig „config.ru“ in RAILS_ROOT. Es sollte dieselbe Datei sein, die von verwendet wird Rackup(1)
und andere Rack-Launcher verwendet es die Rack::Builder DSL. Im Gegensatz zu vielen anderen Racks
Anwendungen, RACKUP_FILE ist vollständig optional für Rails, kann aber zum Deaktivieren verwendet werden
einige der Standard-Middleware für die Leistung.

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

VARIABLEN

Die Variable RAILS_ENV wird durch den oben genannten Schalter -E festgelegt. Der
RAILS_RELATIVE_URL_ROOT wird durch den oben genannten Schalter --path festgelegt. Eins von denen
Variablen können auch in der Shell oder der Unicorn CONFIG_FILE festgelegt werden. Alle Bewerbungs- bzw
Bibliotheksspezifische Umgebungsvariablen (z. B. TMPDIR, RAILS_ASSET_ID) können immer gesetzt werden
die Unicorn CONFIG_FILE zusätzlich zur Spawning-Shell. Beim transparenten Upgrade
Unicorn, alle im alten Masterprozess festgelegten Umgebungsvariablen werden vom neuen geerbt
Master-Prozess. Unicorn verwendet nur die UNICORN_FD-Umgebung (und überschreibt diese).
Variable intern, wenn transparente Upgrades durchgeführt werden.

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://unicorn.bogomips.org/SIGNALS.html) Dokument für eine vollständige Beschreibung
aller von Unicorn verwendeten Signale.

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