Was wäre ein sinnvolles und logisches Verzeichnis für die Bereitstellung meiner Produktions-Rails-Apps auf einem Linux-System?
Einige Kandidaten...
/var/rails <= There's a /var/www so this would be consistent with that
pattern. But I.T. guys have complained about stuff in /var
before.
/home/my_home_dir/rails <= OK, not /var, but I'm not the only developer.
Seems like it really ought to be a systemwide
location.
/home/rails <= I don't know. That just seems weird.
/rails <= Seems even weirder.
Was ist das am wenigsten Erstaunliche und Normalste, was man hier tun kann?
(Hintergrundinformationen: Eine Rails-App besteht aus einer Reihe von serverseitigem Code, der in Ruby geschrieben ist, sowie einem publicVerzeichnis, das JavaScript, CSS und vielleicht ein wenig HTML enthält. Das publicVerzeichnis ist einem Apache-Vhost zugeordnet. Apache verarbeitet den Ruby-Code über ein Modul namens Passenger oder mod_rails.)
Vielen Dank für die Hilfe, alle. Ich glaube, ich werde mich für entscheiden /opt/deployed_rails_apps. (Ich mag lange, aussagekräftige Verzeichnisnamen und Tab-Vervollständigung.) ist auch eine gute Möglichkeit, aber ich habe von der IT-Abteilung heftiges Gemurre bekommen, als ich versucht habe, Sachen dort bereitzustellen. Wenn es meine eigene Maschine wäre, würde ich vielleicht oder /var/...wählen ./var/srv
Antwort1
Ich finde/optwäre der Ort für eineAnwendungso. Ich bin damit einverstanden, den FHS zu befolgen, wie von chmeee vorgeschlagen, aber ich stimme nicht zu, dass eine Rails-App per se ein Dienst ist.
Antwort2
Folgen Sie bitte denDateisystem-Hierarchiestandard (FHS)und legen Sie es in
/srv : Data for services provided by this system
BEARBEITEN:
Ich würde es nicht hier platzieren /opt:
/opt : Add-on application software packages
Sein Zweck lautet:
/opt ist für die Installation von zusätzlichen Anwendungssoftwarepaketen reserviert.
Ein in /opt zu installierendes Paket muss seine statischen Dateien in einem separaten Verzeichnisbaum /opt/ oder /opt/ platzieren, wobei ein Name ist, der das Softwarepaket beschreibt, und der registrierte LANANA-Name des Anbieters ist.
Ich glaube nicht, dass eine entwickelte Anwendung ein „Softwarepaket“ ist.
Die Begründung dafür /srvist
Der Hauptzweck dieser Angabe besteht darin, dass Benutzer den Speicherort der Datendateien für einen bestimmten Dienst finden können und dass Dienste, die einen einzelnen Baum für schreibgeschützte Daten, beschreibbare Daten und Skripte (wie etwa CGI-Skripte) erfordern, sinnvoll platziert werden können.
Ich verstehe, dass eine Rails-App ein CGI-Skript ist und in platziert werden sollte /srv.
Antwort3
Wenn Sie bei CentOS-Linux-Distributionen (und später auch bei RedHat) das httpd-Paket (für Apache 2) installieren, wird erstellt /var/wwwund es wird erwartet, dass Ihre virtuellen Hosts hier auf Ihre Webinhalte verweisen. Der Standard-vhost wird normalerweise in abgelegt /var/www/htdocsund nachfolgende Sites/Apps sollten in abgelegt werden /var/www/sitename.
Der tatsächliche Standort sollte keine große Rolle spielen, aber häufig werden /opt/www/sitename, /var/www/sitename, oder einfach /opt/wwwoder angezeigt /var/www.
Du hast ja bereits einige Gründe genannt, warum andere Standorte (z. B. /home) hierfür nicht so gut geeignet sind.
Ich persönlich bevorzuge es, /var/www/sitenameda es Apache- und Rails-kompatibel und systemweit ist.
Antwort4
In Debian/Ubuntu-basierten Systemen werden solche Anwendungen normalerweise im Ordner /usr/share (also /usr/share/ruby) installiert, da es sich um nicht kompilierte Dateien handelt (die in /usr/lib landen würden). Da Ihre Anwendung keine Standardanwendung ist, würden Sie sie wahrscheinlich in /usr/local/share ablegen, um zu verhindern, dass sie dort durch Systemupdates überschrieben wird.
/opt ist hier sicherlich auch eine Möglichkeit.