랙 : 번들 설치 중 - Bundler :: GemNotFound 오류 --deployment`

Question

랙 상단에 Sinatra 앱을 실행중인 실제 시스템이 몇 대 있습니다. 보통 서버에 대한 변경 사항을 동기화하기 위해 사용하는 Puppet이 프로젝트의 Gemfile.lock이 변경되었음을 알게되고 결과적으로 bundle install --binstubs --deployment 명령을 내 보내야 새로운 보석을 얻을 수 있습니다. 이 경우 새로운 보석이 아직 설치되지 않았기 때문에 ANY http 요청으로 Bundler를 호출하여 보석을 요구하면 500 오류가 발생합니다.

일반적으로 서버가 작동하는지 확인하기 위해 주기적으로 http 요청을하는 다른 프로세스로 인해 적어도 하나의 랙 프로세스가 중지되지만이 경우 랙 프로세스가 작동하지 않습니다. PassengerMinInstances 지시문은 문제가 새로운 인스턴스와 관련되어있는 경우 도움이 될 수 있지만 서버가 여전히 작동 중인지 테스트하기 위해 주기적으로 페이지를 가져 오는 프로세스가 있으므로 최소한 하나의 랙 프로세스가 살아 있어야합니다. 의뢰.

아마 실제로 bundle install가 완료 될 때까지합니다 (restart.txt 파일을 보내고 touch에 의해) 랙을 다시 시작하지 않는 꼭두각시주의해야한다, 그래서 우리의 랙 프로세스에서이 멀리 갈 이유가 이해가되지 않습니다 시각. 아무도 이런 일이 발생 했습니까? 간과 한 모든 요청에 ​​대해 전체 환경을 다시로드하지 않는 랙 옵션이 있습니까?

Answer 1

후임을 위해이 질문에 답해 드리겠습니다. 배포의 일부로 모든 파일에 chown -R이 적용되었습니다.이 파일은 파일의 ctime (그러나 mtime은 아님)을 업데이트합니다. Passenger에 재미있는 bug/feature이있어 /tmp/restart.txt 파일의 mtime 또는 ctime이 변경 될 때마다 서버를 다시 시작합니다.

해결 방법 : 배포 중에 디렉토리에 대한 chowning을 중지하십시오.

Answer 2

나는 이것이 당신의 질문에 직접적으로 대답하지 않는다는 것을 안다. 그러나 나는 이런 종류의 일이 일어나기까지 과거에 애플 리케이션을 버전 번호가 부여 된 dirs에 배치하고, (Nginx) 프록시 서버가 링크에 요청을 라우팅합니다. 배포가 끝나면 배포 스크립트는 새 앱에 대한 링크를 가리 킵니다.

나를 위해 잘 작동하는 것처럼 보였습니다. 실제로 문제가 발생하면 수동으로 이전 버전으로 다시 링크 할 수 있습니다.