2016-04-12 9 views
1

Ich habe einige Probleme mit der Migration einer Capistrano-Bereitstellung unserer Rails-App gehabt, um sie so zu konfigurieren, dass mehrere Benutzer sie bereitstellen können. Ursprünglich hatten wir einen Socket für unseren Unicorn-Server unter/tmp im Besitz des Benutzers, der die Bereitstellung durchführen würde. Dies funktioniert nicht mit mehreren Benutzern, da sie nicht über die Berechtigung zum Ändern der Datei verfügen.Einrichten von Unicorn für Multi-User-Capistrano-Bereitstellung

Wir haben einen zweiten Ansatz versucht, bei dem wir die Socket-Datei unter die App im tmp-Verzeichnis gestellt haben. Nach jeder Implementierung setzen wir den Besitz der Socket-Datei auf die Gruppe eines Deployers zurück, die von den Benutzern gemeinsam genutzt wird. Dies würde für die erste Bereitstellung durch einen Benutzer funktionieren, jedoch nicht, wenn derselbe Benutzer eine zweite Bereitstellung in einer Zeile ausführt. Wenn sich ein anderer Benutzer anmeldet, funktioniert es einwandfrei.

Im Grunde hatten wir ein Bereitstellungssystem, bei dem jede Person nur einmal in einer Reihe bereitstellen kann, bevor sie eine andere Person bitten muss, sie einmal dazwischen zu implementieren. Es sieht aus wie auf der zweiten und weiteren Bereitstellungen, die Einhorn-Prozesse werden nicht ordnungsgemäß neu gestartet. Auf dem ersten das Einhorn Protokoll für die erfolgreiche deploy bereitstellen zeigt dies:

INFO -- : Refreshing Gem list 
INFO -- : listening on addr=/var/www/dashboard/current/tmp/dashboard.socket fd=11 
INFO -- : worker=0 ready 
INFO -- : worker=1 ready 
INFO -- : worker=2 ready 
INFO -- : master process ready 
INFO -- : worker=3 ready 

Auf dem zweiten Rechner das ausgefallene Protokoll wie folgt aussieht:

INFO -- : executing ["/var/www/dashboard/shared/bundle/ruby/2.1.0/bin/unicorn", "-c", "/var/www/dashboard/current/config/unicorn/production.rb", "-E  ", "deployment", "-D", {11=>#<Kgio::UNIXServer:/var/www/dashboard/current/tmp/dashboard.socket>}] (in /var/www/dashboard/releases/20160405234438) 
INFO -- : forked child re-executing... 
INFO -- : inherited addr=/var/www/dashboard/current/tmp/dashboard.socket fd=11 
INFO -- : Refreshing Gem list 
INFO -- : reaped #<Process::Status: pid 22939 exit 0> worker=0 
INFO -- : reaped #<Process::Status: pid 22942 exit 0> worker=1 
INFO -- : reaped #<Process::Status: pid 22945 exit 0> worker=2 
INFO -- : reaped #<Process::Status: pid 22948 exit 0> worker=3 
INFO -- : master complete 
INFO -- : worker=0 ready 
INFO -- : worker=1 ready 
INFO -- : worker=2 ready 
INFO -- : master process ready 
INFO -- : worker=3 ready 

Das Juwel wir für unsere Einhorn Bereitstellung verwenden ist Capistrano -Einhorn. Wir verwenden Ruby 2.1.5, Capistrano 2.15.7 und Unicorn 5.0.1.

Antwort

1

Sie sollten Einhorn unter einem separaten Benutzer ausführen, nicht mit einzelnen Entwicklern verwandt, wie www. Dann kann der Einhornsockel anderswo sein, z.B. in /tmp. Verwenden Sie die Option unicorn_user (siehe gem readme), damit Capistrano den Unicorn-Server unter dem angegebenen Benutzer neu lädt oder neu startet.

Sie müssen auch eine sudo-Regel für Ihre Entwicklergruppe einrichten, damit sie Befehle als www-Benutzer ausführen können, ohne ein Kennwort anzugeben. Fügen Sie so etwas zu /etc/sudoers Datei:

%developers ALL=(www) NOPASSWD: ALL 

Warnung: dies jeden Benutzer in der developers Gruppe ermöglicht es ohne Angabe von Passwort jeden Befehl als www Benutzer zu laufen! Eine sauberere und sicherere Vorgehensweise wäre, nur die Befehle zum Starten des Einhorns zuzulassen und ihm die Signale zum erneuten Laden/Stoppen usw. zu senden.