In Betracht ziehen, RVM auf einer neuen Maschine in Produktion zu setzen (leichte Beanspruchung). Aber ich visualisiere nicht, wie es funktioniert, wenn ein Benutzer nicht angemeldet ist. RVM wurde in /usr/local/rvm/bin/rvm installiert, so dass es für jeden verfügbar ist.
Wenn der Server neu startet und auf dem Anmeldebildschirm ist und Hintergrund-Dämonen apache / rails usw. bedienen und keine .bashrc , etc. geladen haben ... wie / wo geben wir an, welche von RVMs Rubies geladen werden sollen?
Vielleicht irgendwo in Phusions Passagier?
Wer verwaltet diese Edelsteine? Werden sie geteilt?
Sie können den Befehl wrapper von RVM verwenden, um Skripts zu generieren, die die korrekte RVM-Umgebung laden, bevor die erforderlichen Binärdateien ausgeführt werden. Das Format ist:
Um beispielsweise eine Binärdatei namens system_unicorn zu erstellen, die ruby-1.9.2-p180 lädt und anschließend unicorn ausführt, verwenden Sie Folgendes:
Sie können mehrere Binärdateien übergeben, um Wrapper für zu erstellen. Um beispielsweise Wrapper für unicorn und god zu erstellen, führen Sie
ruby_string kann alles sein, was du an rvm use übergeben kannst und somit auch Edelsteine enthalten kann; Wenn Sie beispielsweise myapp_unicorn für das Gemset my_app_gemset erstellen möchten, verwenden Sie:
Wenn Sie Passenger heutzutage installieren, erstellt es automatisch einen Wrapper für seine ruby (ziemlich sicher, dass es passenger_ruby heißt), der die korrekte Version von Ruby lädt (diejenige, die Sie bei der Installation verwenden). . Sie können config/setup_load_paths.rb verwenden, um einen Edelsteinsatz anzugeben - siehe diesen Stapelüberlauf antwort .
Ich habe in der Vergangenheit damit umgegangen, indem ich alle Jobs mit einem Benutzer ausgeführt habe, der rvm eingerichtet hat. Es fügt vielen einfachen Jobs Komplexität hinzu, da Sie sicherstellen müssen, dass rvm geladen ist. Wenn Sie Befehle als root ausführen und rvm verwenden möchten, können Sie den Befehl rvmsudo verwenden.
Sie können RVM auch systemweit als Root installieren:
1) root installiert die Ruby-Versionen und Gems unter RVM, wenn Sie sie global installieren (Lesen Sie die RVM Readme - es scheint mögliche Probleme bei der globalen Installation zu geben!)
2) Wenn Sie mit UNIX arbeiten, wird jeder Ihrer Systemprozesse als bestimmter Benutzer gestartet. z.B. auf LINUX durch die init-Skripte in /etc/init.d/ ... während die Prozesse sind erstellt als ein bestimmter Benutzer, die Zuordnung von Benutzernamen zu UID / GID, das Home-Verzeichnis, und Login-Shell werden in der Datei / etc / passwd nachgeschlagen - Hier wird die Login-Shell (z. B. bash) für einen bestimmten Benutzer definiert.
Also, zurück zu Ihrer Aussage:
%Vor%Sie sehen das Problem mit dieser Aussage?
Wenn der Server startet und die Hintergrundprozesse gestartet werden, wird jeder von ihnen als ein bestimmter Benutzer mit einer bestimmten Login-Shell und mit einem bestimmten Home-Verzeichnis gestartet.
RVM benötigt, dass Ihre Login-Shell auf / bin / bash gesetzt ist - andernfalls könnte es die RVM-Umgebung für keinen der Prozesse einrichten, die von diesem bestimmten Benutzer ausgeführt werden. z.B. RVM funktioniert nicht, wenn Sie / bin / nologin als Standard-Shell verwenden.
Problem1: Das ist natürlich ein Sicherheitsproblem! Im Allgemeinen sollten Daemons aus Sicherheitsgründen keine Shell haben.
Problem2: Sie möchten keine leistungsstarken Tools für jemanden bereitstellen, der in Ihren Server einbricht - deshalb sollten Sie keine cc und andere Tools auf einem Produktionsserver haben - deshalb sollten Sie Ihre Rubys und Gems nicht auf dem Produktionsserver kompilieren, Kopieren Sie stattdessen das .rvm-Verzeichnis auf die Produktionsserver ...
Problem3: (allgemeiner) Die Art und Weise, wie RVM alle Ruby und Gem Versionen verwaltet, ist sehr sehr kludgy Ansatz zur Versionsverwaltung. Es ist keine gute Idee, spezielle Features einer bestimmten Login-Shell zu verwenden, um die Versionsverwaltung zu erleichtern. IMHO - sicher, dass es im Moment nichts Besseres gibt, aber in den alten Zeiten war die Idee hinter Lude ein weitaus besserer Ansatz, verschiedene Versionen von Software zu installieren : Ссылка
Fazit:
Wie ich bereits in einem früheren Post erwähnt habe, empfehle ich RVM, ein normales Benutzerkonto einzurichten, um Ihre Ruby und Rails Prozesse auszuführen und dieses Konto mit / bin / bash als Login Shell einzurichten und zu kopieren .rvm Verzeichnis von Ihrem dev-Server zu Ihren Produktionsmaschinen über scp oder rsync - es ist der bessere und sicherere Ansatz.
Ich hatte ein ähnliches Problem, bei dem ich die Ruby-Version und alle damit verbundenen Edelsteine auf den Produktionsmaschinen bereitstellen möchte ...
Aus den Gründen, die in meinem anderen Beitrag beschrieben wurden, entschied ich mich für eine lokale RVM-Installation. Ich habe einen Benutzer "deploy" sowohl auf meinen Dev-Servern als auch auf meinen Produktionsservern.
Ich würde empfehlen, entweder "rsync" oder "scp -rp" zu verwenden, um das komplette Unterverzeichnis ~ / .rvm auf den Zielrechner zu kopieren (denken Sie daran, dass Sie keine cc und andere Werkzeuge in einer Produktion haben wollen) Server!)
Ein wichtiger Gotcha:
Stellen Sie sicher, dass Sie das Benutzerkonto mit identischem Namen auf allen Computern verwenden, wenn Sie das .rvm-Verzeichnis replizieren!
Ich habe bemerkt, dass die interne Buchhaltung von RVM während der Installation von Ruby-Versionen und Gems einige Umgebungsvariablen verfolgt und insbesondere den Namen des verwendeten Benutzerkontos und den Pfad zur Benutzer Heimverzeichnis. Beats me, warum sie nicht $ HOME und $ USER verwenden, die auf allen UNIXen Standard sind .. scheint mir ein echter Bug in RVM zu sein.
Wenn Sie das gleiche Benutzerkonto für alle Maschinen verwenden, wird es gut funktionieren.
z.B. Ich verwende einen Benutzer "deploy", der das .rvm-Verzeichnis besitzt und Eigentümer der laufenden Prozesse ist.
Wenn Sie rsync oder scp zum Synchronisieren Ihres Bereitstellungskontos verwenden, ist der Nachteil, dass Sie Ihre Server neu starten müssen, z. Einhorn, manuell.
Eine weitere vielversprechende Möglichkeit für die Bereitstellung von RVM- und Rails-Apps ist die Bereitstellung auf einem Rechner, auf dem das Bundle-Update ausgeführt wird. Anschließend wird ein RPM aus dem gesamten Bereitstellungskonto erstellt, das dann über rpm -Uhv oder ein privates yum-Repository installiert wird auf alle Knoten. Vorteil hierbei ist, dass die Dienste auf den Knoten einfach über eine% post-Aktion im RPM neu gestartet werden können.
Tags und Links ruby-on-rails-3 passenger rvm