Einhorn – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

unicorn – ein Rackup-ähnlicher Befehl zum Starten des Unicorn-HTTP-Servers

ZUSAMMENFASSUNG

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

BESCHREIBUNG

A Rackup(1)-ähnlicher Befehl zum Starten von Rack-Anwendungen mit Unicorn. Es wird erwartet, dass dies der Fall ist
in Ihrem Anwendungsstammverzeichnis (APP_ROOT) gestartet, möglicherweise jedoch in der Direktive „working_directory“.
Wird in der CONFIG_FILE verwendet.

Während Unicorn eine Vielzahl von Befehlszeilenoptionen benötigt, um die Kompatibilität zu gewährleisten 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. 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.

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

-N, --no-default-middleware
Deaktiviert das Laden der durch RACK_ENV implizierten Middleware. Dadurch wird die Konfiguration umgangen
Dies ist im Abschnitt „RACK ENVIRONMENT“ dokumentiert, ermöglicht aber weiterhin die Verwendung von RACK_ENV
für anwendungs-/frameworkspezifische Zwecke.

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.

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

Ab Unicorn 0.94.0 wird RACK_ENV auch als prozessweite Umgebungsvariable exportiert.
Obwohl dies ab Rack 1.0.1 kein aktueller Bestandteil der Rack-Spezifikation ist, ist dies zu einer de geworden
Faktisch Standard in der Rack-Welt.

Beachten Sie, dass die Middlewares Rack::ContentLength und Rack::Chunked auch durch „Bereitstellung“ geladen werden.
und „Entwicklung“, aber keine anderen Werte von RACK_ENV. Bei Bedarf müssen sie einzeln sein
in der RACKUP_FILE angegeben sind, sind sie für einige Frameworks nicht erforderlich.

VARIABLEN

Die Variable RACK_ENV wird durch den oben genannten Schalter -E festgelegt. Alle Anwendungs- oder Bibliotheks-
Spezifische Umgebungsvariablen (z. B. TMPDIR) können immer in der Unicorn CONFIG_FILE festgelegt werden
zusätzlich zur Laichschale. Beim transparenten Upgrade von Unicorn alle Umgebungen
Im alten Masterprozess festgelegte Variablen werden vom neuen Masterprozess geerbt. Einhorn
Dabei wird intern nur die Umgebungsvariable UNICORN_FD verwendet (und überschrieben).
transparente Upgrades.

UNICORN_FD ist eine durch Kommas getrennte Liste von einem oder mehreren Dateideskriptoren, die zur Implementierung verwendet werden
USR2-Upgrades. Init-Systeme können Listen-Sockets selbst binden und Einhorn mit erzeugen
UNICORN_FD wird auf die Dateideskriptornummern der Listen-Sockets gesetzt. Das Einhorn
In CONFIG_FILE müssen weiterhin die geerbten Listen-Socket-Parameter wie in einer normalen Datei definiert sein
Startup, andernfalls wird der Socket geschlossen.

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