2014-12-04 4 views
1

그래서 저는 현재 이전 개발자들이 개발 한 두 개의 CherryPy 웹 앱을 관리하고 있습니다.서로 다른 파이썬 버전을 가진 CherryPy 웹 앱을 여러 개 실행하기

하나는 python2.7로 작성되었고 다른 하나는 python3.0으로 작성되었습니다. 현재 그들은 서로 다른 목적과 다른 데이터베이스를 가진 독립적 인 앱이기 때문에 cherrypy 웹 서버를 사용하고 자체 인스턴스를 시작합니다.

동일한 서버에서 실행되는 세 번째 응용 프로그램과 더 많은 응용 프로그램을 개발할 과제가 있습니다.

우리가 개발하는 모든 응용 프로그램마다 다른 포트에서 새로운 웹 서버를 인스턴스화하는 것이 비효율적 인 것으로 간주되어서 이에 대한 해결책을 찾고 있습니다.

내가 발견 한 첫 번째 일은 아파치 용 mod_wsgi 였지만, 나는 이것이 단지 하나의 파이썬 버전 만 처리 할 수 ​​있다는 것을 빨리 알았다.

지금 당장은 그러한 설정을 위해 어떤 해결책이 있습니까?

트래픽이 적은 내부 앱이지만 각기 고유 한 포트에 6 개의 다른 서버가 실행되는 것을 원하지 않습니다.

답변

1

nginx (아마도 gunicorn)을 사용할 수 있습니다. 나는 아파치로도 똑같은 일을 할 수 있다고 확신하지만 아파치로 WSGI를 설정 한 경험은 없다.

주요 포인트는 당신이 실제로 각 응용 프로그램 하나를 몇 가지 다른 내부 웹 서버를 실행해야하고 nginx

나 '와 같은 포트를 결합 할 수 있습니다 이다 CherryPy가 파일 소켓 대신 포트을 청취 할 수 있는지 확실하지 않으므로 gunicorn을 생략하고 nginx을 CherryPy 서버와 직접 구성 할 수 있습니다.

다음은 nginx의 구성 예입니다. 당신은 즉, nginx.conf에서 서로 다른 하위 도메인 또는 subURLs를 만들 수 있습니다

upstream app1 { 
    server unix:/var/run/user/app1.sock fail_timeout=0; 
} 
upstream app2 { 
    server unix:/var/run/user/app2.sock fail_timeout=0; 
} 

...

server { 
    listen 0.0.0.0:80; 
    server_name app1.yourdomain.com; 
    location/{ 
     proxy_pass http://app1; 
    } 
} 
server { 
    listen 0.0.0.0:80; 
    server_name app2.yourdomain.com; 
    location/{ 
     proxy_pass http://app2; 
    } 
} 

...와 BTW 각 응용 프로그램 (대한 gunicorn 설정, 당신은 두 gunicorns을해야합니다 - gunicorn-2.7gunicorn-3.2) 포트을 수신 대기하지 말고 응용 프로그램을 바인드해야합니다. 유닉스 소켓 예 : /var/run/user/app1.sock

이렇게하면 두 개의 하위 도메인에 대해 서로 다른 두 가지 응용 프로그램이 생성됩니다. 이러한 응용 프로그램은 다른 언어로 작성 될 수도 있습니다.

http : //*****.yourdomain.com으로 이동하면 귀하의 요청은 해당 gunicorn 인스턴스로 전송되므로 적절한 응용 프로그램이이를 처리합니다.

나는 당신이 어떤 경우에 gunicorn을 할 것입니다 생각 : 그것은 당신에게 파일 소켓 및 다른 많은 유용한 기능, 예를 들어,에 바인드 응용 프로그램을 할 수 있습니다동일한 앱의 여러 작업자를 실행 중입니다.

+0

고마워요! 나는 오늘 그것을 시도 할 것이다. 초기 읽기가 유망 해 보인다. – ashrles

1

사실 피하려고하는 것은 microservice architecture (Martin Fowler article)처럼 보입니다. 기본적으로 하나의 모 놀리 식 응용 프로그램 대신 전체적으로 작동하도록 다중화 된 최소한의 자체 포함 서비스를 제안합니다. 그것의 찬반 양론이 있지만, 오늘은 더 좋은 것으로 간주됩니다. 최소한 큰 규모로.

따라서 애플리케이션을 설계하는 한 가지 방법은 마이크로 서비스 아키텍처이며 여러 내부 서버를 실행하는 것은 문제가되지 않습니다. 이 접근법의 일부 복잡성이 인프라로 옮겨졌습니다. 즉, 품질 배치, 모니터링 등이 필요합니다.

Andew의 대답은 정확합니다. 그러나 구체적으로 CherryPy은 모든 기능을 갖춘 HTTP 서버입니다. 일반적으로 gunicorn 정도의 다른 중간 지점이 필요하지 않으므로 WSGI를 피할 수 있습니다. HTTP를 사용하십시오. 즉, nginx은 CherryPy 내부 HTTP 서버에 대한 역방향 HTTP 프록시 역할을합니다.

가장 간단한 방법은 다음과 같습니다.

파이썬이 본격적인 CherryP를 들어 응용 프로그램

#!/usr/bin/env python 
# -*- coding: utf-8 -*- 


import cherrypy 



config = { 
    'global' : { 
    'server.socket_host' : '127.0.0.1', 
    'server.socket_port' : 8080, 
    'server.thread_pool' : 8 
    }, 
    '/' : { 
    'tools.proxy.on' : True 
    } 
} 


class App: 

    @cherrypy.expose 
    def index(self): 
    return type({}.keys()).__name__ 


if __name__ == '__main__': 
    cherrypy.quickstart(App(), '/app1', config) 

파이썬 3 응용 프로그램

#!/usr/bin/env python3 


import cherrypy 


config = { 
    'global' : { 
    'server.socket_host' : '127.0.0.1', 
    'server.socket_port' : 8081, 
    'server.thread_pool' : 8 
    }, 
    '/' : { 
    'tools.proxy.on' : True 
    } 
} 


class App: 

    @cherrypy.expose 
    def index(self): 
    return type({}.keys()).__name__ 


if __name__ == '__main__': 
    cherrypy.quickstart(App(), '/app2', config) 

의 nginx의 설정

server { 
    listen 80; 

    server_name ngx-test; 

    root /var/www/ngx-test/www; 

    location /app1 { 
    proxy_pass   http://127.0.0.1:8080; 
    proxy_set_header Host    $host; 
    proxy_set_header X-Real-IP  $remote_addr; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 

    location /app2 { 
    proxy_pass   http://127.0.0.1:8081; 
    proxy_set_header Host    $host; 
    proxy_set_header X-Real-IP  $remote_addr; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 

} 

y 배치를 this answer에서 살펴보십시오.

+0

나는 오버 헤드와 실패 지점을 최소화하는 방법을 좋아합니다. 이것은 마이크로 서비스 아키텍처가 소비하는 리소스의 양을 줄입니까? gunicorn이 모든 앱을 동일한 우산 아래에 가져다 놓은 것처럼 보이기 때문에 이와 비슷한 기능을 수행 할 수 있습니까? 아직 자체 프로세스로 응용 프로그램을 시작해야하는 것처럼 보입니다. "새로운"서버의 인스턴스를 빨리 만들지 않겠습니까? – ashrles

+0

먼저, 내 대답은 * CherryPy <= HTTP => Nginx * 대신 * CherryPy <= WSGI => gunicorn <= HTTP => Nginx *를 사용하는 것이 좋습니다. 다중 응용 프로그램 아키텍처를 정당화 할 수있는 근거가됩니다. 둘째, 중개자가 적고 리소스가 적습니다. 셋째, 네, 각 애플리케이션을 별도의 프로세스로 시작해야하며, nginx를 멀티플렉싱해야합니다. 위의 예제는'quickstart()'가 CherryPy를 배포하는 방법이 아니므로 데모입니다. 실제 배포를 위해서는 링크를 클릭하십시오. – saaj