Capistrano는 Mongrel 클러스터를 올바르게 다시 시작하지 않습니다
-
03-07-2019 - |
문제
Nginx 아래에서 실행되는 3 개의 몬드 클러스터가 있으며 Capistrano 2.4.3을 사용하여 앱을 배포합니다. 실행중인 시스템이있을 때 "CAP 배포"하면 동작이 다음과 같습니다.
- 앱이 배포되었습니다. 코드가 성공적으로 업데이트됩니다.
캡 배포 출력에는 다음과 같습니다.
- "sudo -p 'sudo password 실행 :'mongrel_rails cluster :: 다시 시작 -c /var/www/rails/myapp/current/config/mongrel_cluster.yml"
- 서버 : [ "myip"
- MYIP] 실행 명령
- ** [out :: myip] 포트 중지 9096
- ** [out :: myip] 포트 9097 중지
- ** [out :: myip] 포트 9098 중지
- ** [out :: myip] 이미 포트 9096을 시작했습니다.
- ** [out :: myip] 이미 포트 9097을 시작했습니다.
- ** [out :: myip] 이미 포트 9098을 시작했습니다.
- 서버에서 즉시 확인하고 Mongrel이 여전히 실행 중인지 확인하고 PID 파일은 이전 세 인스턴스에 대해 여전히 존재합니다.
- 짧은 시간 후 (1 분 미만) Mongrel이 더 이상 실행되지 않고 PID 파일이 사라지고 다시 시작하지 못했습니다.
- 서버에서 수작업으로 Mongrel을 시작하면 앱이 잘 시작됩니다.
'mongrel_rails cluster :: 다시 시작'은 클러스터의 재시작을 시도하기 전에 전체 정지를 제대로 기다리지 않는 것 같습니다. 이 문제를 진단하고 수정하려면 어떻게해야합니까?
편집 : 다음은 답입니다.
Mongrel_Cluster는 "재시작"작업에서 간단히 수행합니다.
def run
stop
start
end
"시작"을 호출하기 전에 프로세스가 종료되었는지 확인하기 위해 기다리거나 확인하지 않습니다. 이것은 뛰어난 패치가 제출 된 알려진 버그. 패치를 Mongrel Cluster에 적용했고 문제가 사라졌습니다.
해결책
Capistrano 레시피에 다음을 추가하여 시작하기 전에 Mongrel_Cluster 레시피를 명시 적으로 알리기 전에 PID 파일을 제거 할 수 있습니다.
# helps keep mongrel pid files clean
set :mongrel_clean, true
이로 인해 -clean 옵션을 Mongrel_Cluster_CTL로 전달합니다.
나는 돌아가서 배포 레시피 중 하나를보고 재시작 작업이 작동하는 방식도 바뀌 었다는 것을 알았습니다. Mongrel 사용자 그룹의 다음 메시지를 살펴보십시오.
다음은 내 배포입니다 : 다시 시작 작업. 나는 그것이 약간의 해킹임을 인정합니다.
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
다른 팁
먼저, 전화만으로 테스트하는 범위를 좁 힙니다. cap deploy:restart
. 당신은 통과하고 싶을 수도 있습니다 --debug
원격 실행 또는 원격 옵션 --dry-run
설정을 조정할 때 무슨 일이 일어나고 있는지 확인하기 위해 옵션.
언뜻보기에 이것은 PID 파일 또는 Mongrel 프로세스에 대한 권한 문제처럼 들리지만 확실히 알기가 어렵습니다. 내 눈을 사로 잡는 몇 가지는 다음과 같습니다.
- 그만큼
:runner
변수는 설명이 설정되어 있습니다nil
- 이에 대한 특별한 이유가 있었습니까? - Capistrano 2.4는 새로운 행동을 소개했습니다
:admin_runner
변하기 쉬운. 전체 레시피를 보지 않고 이것은 문제와 관련이 있습니까?: 러너 대 : admin_runner (에서 Capistrano 2.4 릴리스) 일부 케이퍼는 배치 및 배포 : 설정 : 청소 실행 : 러너 사용자는 신중하게 제작 된 권한을 엉망으로 만들었습니다. 나는 이것이 문제라는 데 동의했다. 이 릴리스를 사용하면 배포 : 시작, 배포 : 중지 및 배포 : 다시 시작 : Sudoing이지만 배포 할 때 : 러너 사용자를 계속 사용하십시오 : 설정 및 배포 : Cleanup은 다음을 사용합니다. : admin_runner 변수는 기본적으로 설정되지 않으므로 해당 작업이 루트로 Sudo를 수행하지만 다음과 같이 실행하려면 : Runner, "Set : Admin_Runner, Runner"를 수행합니다.
다음에해야 할 일에 대한 나의 추천. 몽 그렐을 수동으로 멈추고 PID를 정리하십시오. 몽 그렐을 수동으로 시작하십시오. 다음으로, 계속 실행하십시오 cap deploy:restart
문제를 디버깅하는 동안. 필요에 따라 반복하십시오.
어느 쪽이든, 내 몽 그렐은 이전 중지 명령이 끝나기 전에 시작됩니다.
수면 2.5는 좋은 솔루션이 아닙니다. 모든 러닝 몬드를 중단하는 데 2.5 초 이상이 걸리면 2.5 초가 걸립니다.
필요가있는 것 같습니다.
stop && start
vs.
stop; start
(이것은 Bash의 작동 방식이며 && 첫 번째 명령이 오류없이 오류가 끝나기를 기다리는 동안 ";"다음 명령을 실행합니다).
나는 다음이 있는지 궁금합니다.
wait cluster_stop
then cluster_start
나는 너무 기본적인 것을 싫어하지만 PID 파일이 시작하려고 할 때 여전히 매달려있는 것처럼 들립니다. Mongrel이 손으로 멈춰야합니다. PID 파일을 손으로 정리하십시오. 그런 다음 캡 배포를하십시오.