Capistrano non riavvia i cluster Mongrel correttamente
-
03-07-2019 - |
Domanda
Ho un cluster di tre ibridi in esecuzione sotto nginx e distribuisco l'app usando Capistrano 2.4.3. Quando "cap cap deploy" quando c'è un sistema in esecuzione, il comportamento è:
- L'app è distribuita. Il codice è stato aggiornato con successo.
-
Nell'output di distribuzione cap, c'è questo:
- eseguendo " sudo -p 'sudo password:' cluster mongrel_rails :: restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml"
- server: [" myip "]
- [myip] comando di esecuzione
- ** [out :: myip] arresto porta 9096
- ** [out :: myip] arresto porta 9097
- ** [out :: myip] arresto porta 9098
- ** [out :: myip] ha già avviato la porta 9096
- ** [out :: myip] ha già avviato la porta 9097
- ** [out :: myip] ha già avviato la porta 9098
- Controllo immediatamente sul server e trovo che Mongrel sia ancora in esecuzione e che i file PID siano ancora presenti per le tre precedenti istanze.
- Poco dopo (meno di un minuto), trovo che Mongrel non è più in esecuzione, i file PID sono spariti e non è stato possibile riavviare.
- Se avvio a mano ibrida sul server, l'app si avvia correttamente.
Sembra che 'cluster mongrel_rails :: restart' non sia in attesa di un arresto completo prima di tentare un riavvio del cluster. Come posso diagnosticare e risolvere questo problema?
EDIT: ecco la risposta:
mongrel_cluster, nel campo " riavvia " compito, semplicemente fa questo:
def run
stop
start
end
Non fa alcuna attesa o verifica per vedere che il processo è terminato prima di invocare " start " ;. Questo è un bug noto con una patch eccezionale inviata . Ho applicato la patch a Mongrel Cluster e il problema è scomparso.
Soluzione
Puoi esplicitamente dire alle ricette mongrel_cluster di rimuovere i file pid prima di iniziare aggiungendo quanto segue nelle tue ricette capistrano:
# helps keep mongrel pid files clean
set :mongrel_clean, true
Questo fa sì che passi l'opzione --clean a mongrel_cluster_ctl.
Sono tornato indietro e ho esaminato una delle mie ricette di distribuzione e ho notato che avevo anche cambiato il modo in cui la mia attività di riavvio funzionava. Dai un'occhiata al seguente messaggio nel gruppo utenti mongrel:
discussione di riavviamento degli utenti
La seguente è la mia attività deploy: restart. Ammetto che è un po 'un trucco.
namespace :deploy do
desc "Restart the Mongrel processes on the app server."
task :restart, :roles => :app do
mongrel.cluster.stop
sleep 2.5
mongrel.cluster.start
end
end
Altri suggerimenti
Per prima cosa, restringere l'ambito di ciò che il test chiama solo cap deploy: restart
. Potresti voler passare l'opzione --debug
per richiedere prima dell'esecuzione remota o l'opzione --dry-run
solo per vedere cosa sta succedendo mentre modifichi le tue impostazioni.
A prima vista, questo sembra un problema di permessi sui file pid o sui processi ibridi, ma è difficile saperlo con certezza. Un paio di cose che catturano la mia attenzione sono:
- la variabile
: runner
è esplicitamente impostata sunil
- C'era un motivo specifico per questo? - Capistrano 2.4 ha introdotto un nuovo comportamento per la variabile
: admin_runner
. Senza vedere l'intera ricetta, questo è forse correlato al tuo problema?: runner vs.: admin_runner (da capistrano 2.4 release ) Alcuni capper hanno notato che avere deploy: setup e deploy: cleanup viene eseguito mentre l'utente: runner ha incasinato le proprie autorizzazioni accuratamente predisposte. Ho concordato che questo era un problema. Con questa versione, deploy: start, deploy: stop e deploy: restart tutti continuano a utilizzare l'utente: runner durante il sudo, ma deploy: setup e deploy: cleanup utilizzerà l'utente: admin_runner. La variabile: admin_runner non è impostata, per impostazione predefinita, il che significa che quelle attività verranno eseguite come root, ma se vuoi che vengano eseguite come: runner, fai semplicemente “set: admin_runner, runner”.
La mia raccomandazione su cosa fare dopo. Fermare manualmente i bastardi e ripulire i PID. Avvia i bastardi manualmente. Quindi, continua a eseguire cap deploy: restart
durante il debug del problema. Ripeti se necessario.
Ad ogni modo, i miei bastardi stanno iniziando prima che il precedente comando di arresto abbia finito di spegnerli tutti.
sleep 2.5 non è una buona soluzione, se ci vogliono più di 2,5 secondi per fermare tutti i bastardi in esecuzione.
Sembra che sia necessario:
stop && start
vs.
stop; start
(ecco come funziona bash, & amp; & amp; attende che il primo comando finisca senza errore, mentre " ;; " esegue semplicemente il comando successivo).
Mi chiedo se esista un:
wait cluster_stop
then cluster_start
Odio essere così semplice, ma sembra che i file pid siano ancora in giro quando sta tentando di avviarsi. Assicurati che il bastardo venga fermato a mano. Pulisci i file pid a mano. Quindi distribuire un limite.
Buona discussione: http://www.ruby-forum.com/topic/ 139734 # 745030