[YT-CC-1174:] 승객 5 응용 프로그램 제어 개선

묘사

패치 설명

CC-1174에 기록된 Passenger5 오류를 수정한 것입니다.
승객에게 잘못이 하나 있다.언제 시작하든지/tmp/passenger-standalone-xxxx 디렉터리를 만들 것입니다.이것은 그것이 임시 파일을 저장하는 곳이다.문제는 승객이 시동을 걸 수 없을 때 이 디렉터리가 지워지지 않는다는 것이다.
우리는 승객들이 사망할 때 다시 작동할 수 있도록 Monit를 운행한다.우리의 기본 모니터링 주기는 30초다.이는 몬트가 승객이 사망했다고 판단하면 30초에 한 번씩 승객을 가동시키려는 뜻이다.만약 승객의 시동을 막는 것이 있다면, 모니트는 결국 승객의 시동을 반복적으로 시도할 것이다.시간이 지날수록 수천 개의 독립 디렉터리로 누적될 수도 있다.우리는 이미 몇몇 응용 실례의inode가 이미 다 쓴 것을 보았다.
어떤 이유로 승객들이 시동을 걸 수 없었는지는 아직 밝혀지지 않았지만, 우리는 다음 두 가지 기술 중 하나를 통해 이 문제를 복제할 수 있습니다.

승객 독립 PID 파일 삭제

승객 프로세스를 종료하지만 Nginx 프로세스를 종료하지 않습니다(Nginx는 승객이 독립적으로 시작합니다)

이 복구 프로그램은 상기 두 가지 상황을 처리하기 위해 추가 검사를 추가할 것입니다.

권장 릴리즈 노트

Passenger5 시작 스크립트에 체크를 추가하여/tmp/passer standalone이 중복되지 않도록 합니다.*카탈로그

위험을 예측하다

높다Passenger5 응용 프로그램 제어 스크립트가 변경됩니다.만약 이것이 파괴된다면, 프로그램은 시작할 수 없을 것이다.

관련된 구성 요소

승객

테스트 완료 설명

QA 참고 사항 - 테스트는 별도의 환경에서 수행됩니다.새로운 실례를 추가하는 테스트가 완료되지 않았습니다.

품질 보증 설명

Passenger5 스택을 실행하는 최신 V5(비 QA) 스택에서 클러스터 환경을 시작합니다.todo 프로그램을 사용합니다.테스트 시작 시 app 메인 실례만 사용하십시오.

현재의 행동을 되돌아보다

1) PID 파일을 삭제할 때
- 승객 독립 PID 파일 삭제rm /data/todo/shared/pids/passenger.8000.pid- 운행watch cat /data/todo/shared/pids/passenger.8000.pid 및 몇 분 대기 - 승객이 성공적으로 작동하고 PID를 쓸 수 있는지 관찰
- 몇 분 후 ls -lah /tmp를 운행하고 신규 승객을 독립적으로 계산합니다.*목록PID 파일을 삭제하면 디렉토리가 분당 하나씩 표시됩니다.
인스턴스를 복원하는 데 도움을 주려면 PID 파일을 다시 작성합니다.운행ps ax | grep [P]assengerAgent을 통해 승객 PID를 받을 수 있습니다.출력의 첫 번째 열은 PID입니다.PID를 가져온 후 실행echo <PID> > /data/todo/shared/pids/passenger.8000.pid2) 승객 프로세스가 종료되었지만 Nginx 프로세스가 종료되지 않은 경우

승객 PID를 획득하여 sudo kill -9 <PID>

로 종료

운행watch cat /data/todo/shared/pids/passenger.8000.pid을 하고 몇 분을 기다린다. - 승객이 성공적으로 작동하는지 관찰하고 PID

를 쓴다.

운행 몇 분 후ls -lah /tmp 신규 승객을 별도로 계산합니다.*목록독립 프로세스

를 죽인 이후로, 매 분마다 디렉터리를 볼 수 있다
인스턴스 복구를 지원하려면 Nginx 프로세스를 종료합니다.실행ps aux | grep nginx | grep passenger - 결과의 첫 번째 열이 Nginx PID입니다.그리고 kill -9 <PID>로 이 과정을 중지한다.

QA 스택으로 업그레이드 및 오류 수정 확인

프로모션 후 위와 같은 단계에 따라 새 동작을 테스트합니다.
1) PID 파일을 삭제할 때
2) 승객 프로세스가 종료되었지만 Nginx 프로세스가 종료되지 않은 경우
이 두 가지 상황에 대해 승객의 독립을 더 이상 보지 마십시오.*목록은 /tmp에 누적되어 있습니다.최대 5분 후에는 /tmp에 생성된 새 승객 독립 목록을 볼 수 없습니다.
다중 응용 프로그램 환경에서 같은 그룹의 테스트를 실행합니다.

이전 기능이 여전히 유효한지 확인

1) 배포
루트 사용자로 실행passenger-status합니다.승객 직원의 PID를 적으세요.
배치하다
배포가 완료되면 다시 실행passenger-status합니다.승객 스태프의 새 PID를 보셔야 합니다.
2) 신규 애플리케이션 시작 사례
새 프로그램을 시작합니다.
응용 프로그램 실례가 자원 공급을 완성한 후 ssh를 응용 프로그램 실례에 연결합니다.
승객이 HTTP 요청을 실행하고 처리하는지 확인합니다.
- 작업자passenger-status를 실행하고 작업자의 처리 완료 수를 확인합니다.
- 어플리케이션 URL을 여러 번 클릭하여 최소한 하나의 요청이 새 어플리케이션 인스턴스에 적중될 가능성 증가
- 재실행passenger-status 및 작업자

토론 #1

LGTM

토론 #2

코드 검토 의견

의 "처리됨"개수 확인

NGINX PID에서는 포트 확인이 더 엄격해야 합니다grep ":<%= @port %> ".승객들은 PID를 변경할 필요가 없습니다.

-n와$NGINX_PID의 조건에서 사용하면$PASSENGER_PID 어때요?-n는 비지 않는다는 뜻이고! -z도 비지 않는다는 뜻이죠?

pidfile의 새 코드를 만드는 부분에 Nginx와 승객의 독립된 프로세스가 존재합니다.우리는 계속 운행하는 것이 아니라 직접 돌아가는 것을 고려해야 한다. /usr/local/bin/passenger start

승객들이 여러 앱을 실행하는 환경에서 작업을 할 수 있도록 하기 때문에 QA 테스트는 이를 포함해야 한다.

토론 #셋

@mikong
제가'약속'을 넣었어요.https://github.com/engineyard/ey-cookbooks-stable-v5/pull/319/commits/300b1eec5c1444f9f9f5e3ced5afc3ca97322dd4제1항을 처리하다.
다중 애플리케이션 환경을 테스트하기 위해 QA 지침을 업데이트했습니다.

토론 #4