2017-12-14 30 views
-2

여러 응용 프로그램을 호스팅하는 응용 프로그램 서버를 구축하고 싶지만 해당 응용 프로그램은 대부분 잠자기 상태로 유지해야하며 heroku 라우터는 무료 응용 프로그램 .nginx (heroku처럼)를 사용하여 요청시 웹 응용 프로그램을 시작할 수 있습니까?

애플리케이션을 시작하는 프록시 애플리케이션을 추가해야합니까? 아니면 nginx가 어떤 방식 으로든이를 처리하도록 구성 할 수 있습니까?

요청시 응용 프로그램을 시작하고 요청을 프록시하는 노드 응용 프로그램을 추가하는 것에 대해 생각했지만 모든 요청을 프록시해야 할 필요가있을뿐만 아니라 첫 번째 요청이 느슨 할 수도 있으므로 시간이 많이 걸릴 수도 있습니다. 응용 프로그램이 응답 할 준비가되지 않았을 수 있습니다.

나는 또한 ngx_http_auth_request module을 사용하여 응용 프로그램을 시작할 수 있다고 생각했지만 제대로 작동하는지 확신 할 수 없습니다.

아이디어는 새로운 응용 프로그램을 언제든지 설치할 수 있으므로 실행중인 모든 응용 프로그램 목록이 없다는 것입니다.

+0

이유가 무엇인지 분명하지 않기 때문에 투표를 취소 할 때 의견을 추가하십시오. – eloyesp

+0

비현실적인 질문을하기 위해 또 다른 -1, 현상금 기간 동안 명확한 설명을 제공하지 못함, 합리적인 정당화없이 답변을 받아들이지 않고 모두 상쇄하지 말 것. – cnst

답변

0

기본적으로 코어 헤로 쿠 기능을 구현하고자하는 것처럼 들리지만, 몇 줄의 코드로 신뢰할 수 있고, 생산 등급이며, 아마도 그럴 것입니다.

음, 실제로 작동하는 방식이 아닙니다. a lot of things going on behind Heroku이 있습니다. 응용 프로그램이 제대로 잠자기 및 깨어나 기 위해 매우 많은 시간이 소요됩니다.이 응용 프로그램은 병렬 친화적 인 패러다임으로 알려진 Erlang의 중요한 코드베이스에서 처리됩니다.

기본적으로 귀하의 질문은 소프트웨어 권장 사항과 비슷하게 들리며 StackOverflow의 경우 다소 유용 할 수 있습니다. PaaS 필요에 대해 Yandex Cocaine과 같은 것을 시도해 볼 수는 있지만, 내가 원하는 수면 기능을 지원하는지 확실하지는 않습니다.

하루가 끝나면 "잠"때 앱이 실제로 무엇을하고 있는지 고려해야합니다. 페이스 북 시대 이전의 Perl과 PHP의 옛날에는 브라우저로부터의 각 요청으로 인해 종종 서버가 요청을 처리하기위한 별도의 프로세스를 생성하게되어 매우 비효율적이었습니다. "새로운"방법은 스크립트를 항상 준비 상태로 유지하여 스크립트 당 총 요청 수를 높일 수있게하는 것입니다.

귀하의 앱이 맘에 들지 않게하여 요즘 실제로 달성 할 수있는 실제적인 필요성은 분명하지 않습니다. 주어진 시스템에서 여러 개의 앱을 실행 중이고 대부분이 아무 것도하지 않는다면, 스케쥴러는 사용하지 않은 메모리를 결국 스왑에 사용할 수있는 것으로 표시하고, 실제로 유휴 상태이면 CPU를 소비하지 않아야합니다.

+0

아니요, 그렇다고해서 제가 생산하지 않아도됩니다. 백만 건의 연결을 처리해야합니다. 또한 heroku가 확장하거나 여러 서버를 관리 할 때 확장 할 필요가 없습니다. – eloyesp

0

예, nginx을 리버스 프록시로 사용하고 systemd (또는 다른 inted-replacement)을 사용하면 가능합니다.

전략으로 각 응용 프로그램에 자체 TCP 포트를 할당하여 실행할 때 청취 할 수 있으며 nginx을 구성하여 해당 응용 프로그램에 요청을 라우팅 할 수 있습니다.

그런 다음 각 응용 프로그램 포트에서 systemd 소켓 유형 단위를 구성하고 각 요청에서 응용 프로그램을 시작하도록 구성 할 수 있습니다.두 개의 기존 답변에 대한 코멘트에서

https://www.freedesktop.org/software/systemd/man/systemd.socket.html

+0

이것은 systemd (또는 다른 inetd 대체)에 대한 의존성을 추가 할 것입니다. 생각은 inetd 대체 _within_ nginx를 찾는 것입니다. – eloyesp

+0

nginx는 성능 및 린 코어 유지에 대한 의견이 많기 때문에 공식 nginx 코어 또는 모듈에서이를 볼 수있을 것 같지 않습니다. 가장 가까운 곳은 @cnst에서 언급 한 FastCGI 지원입니다. https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html nginx 내부의 모든 것을 처리하는 동기가 무엇입니까? 지금 당장 가지고있는 제약이 걱정과 우아함을 덜어주고 무언가의 길로 인도 할 수있을 것 같은가요? 그냥 내 2c 희망이 도움이 :) – heretik

0

, 당신은, (1), 당신이 실제로 (2), inetd -like 솔루션입니다이 될 생산 등급을 필요로하지 않는다는 것을 언급 정확히 무엇을 찾고 있지만, inetd/xinetd/systemd 종속성을 가질 필요는 없습니다.

글쎄, 내가 당신을 위해 뉴스를 얻었습니다. nginx는 the C10K problem을 처리하기위한 생산 용 웹 서버입니다. CGI 스크립트가 모든 단일 요청에 대해 생성되는 inetd와 같은 솔루션은 사용자가 얻을 수있는 생산 수준의 품질에서 멀리 떨어져 있으며 겸손한 하드웨어에서 C10K를 처리 할 수 ​​없습니다.

그러므로 nginx가 원래 CGI 모델 (각 요청으로 인해 CGI 스크립트의 별도 복사본이 생성됨)을 지원하지 않고, 대신 FastCGI 및 그와 유사한 기능을 지원한다는 점은 놀랍지 않습니다. 프로세스는 하나 이상의 요청을 처리 할 수 ​​있습니다). 기존의 오래된 학교 확장 성이없는 /cgi-bin/ 스타일 아키텍처를 구현하려면 서드 파티 웹 서버 나 보조 유틸리티를 사용해야합니다. 즉, nginx의 상자는 .htaccess 지원과 같은 방식으로 nginx에 절대 추가되지 않습니다. 둘 다 대단히 비효율적이며 확장 성이 없습니다.