2013-03-08 50 views
13

Tôi đang cố gắng triển khai gunicorn + gevent sau nginx (v 1.3.14) trên dotcloud. Tôi có một vài câu hỏi về nó. Tôi đang hướng đến việc thích ứng với ví dụ python-on-dotcloud. Cho đến nay, tôi đã không thể có được phần websockets làm việc với thiết lập này. Nói cách khác, tôi phải làm mới các trang của mình theo cách thủ công để nhận các bản cập nhật, thay vì thông qua socket.io. Điều này là hoàn toàn mới đối với tôi, vì vậy nó có thể là một lỗi tổng noob. Đây là related question.gunicorn, nginx (v 1.3.14), django và gevent-socket.io, trên dotcloud

Dưới đây là những thay đổi mà tôi đã thực hiện đối với ví dụ python-on-dotcloud.

  1. Dường như nginx (since version 1.3.13) supports web sockets. Tôi đã cập nhật tập lệnh trình xây dựng từ ví dụ python-on-dotcloud để trỏ đến phiên bản phát triển này: nginx_download_url="http://nginx.org/download/nginx-1.3.14.tar.gz"

  2. Tôi thiết lập gunicorn để liên kết với một ổ cắm unix và sau đó thiết lập proxy_pass từ nginx.conf để gửi lưu lượng truy cập ngược dòng gunicorn với proxy_pass http://appserver; nơi tôi đã xác định máy chủ ứng dụng.

  3. Tôi đang chạy một ứng dụng django với gevent-socket.io hoạt động tốt mà không cần chạy nginx. (Tôi chỉ liên kết gunicorn với 0.0.0.0:$PORT_WWW trong dotcloud.yml)

câu hỏi của tôi là như vậy.

  1. Tôi đang cố giải quyết sự cố không?

    a. Tôi đã thực hiện một số lượng công bằng của đọc, nơi nó được khuyên nên đặt gunicorn đằng sau nginx. Trong bối cảnh cân bằng tải của dotcloud trên tuyến đầu, điều này vẫn đúng?

    b. Nếu tôi không nghĩ rằng tôi sẽ bị tấn công DoS, liệu việc đặt gunicorn phía sau nginx có quan trọng không?

  2. Có thể chạy các ổ cắm web thông qua một ổ cắm unix như tôi đã cố thiết lập không?

  3. Ổ cắm unix có mở rộng trên dotcloud không?

  4. Nếu tôi cần sử dụng cổng thay thế, cách thiết lập? Tôi không nghĩ rằng tôi có thể phân bổ hai cổng http trong cùng một ứng dụng. Nếu tôi chia nó thành hai ứng dụng, sau đó tôi không chắc chắn làm thế nào để vượt qua biến môi trường PORT_WWW từ ứng dụng gunicorn vào ứng dụng nginx để nó kết thúc có sẵn cho kịch bản lệnh nginx postinstall và do đó trong kết quả nginx.conf.

  5. Bất kỳ ý tưởng nào về lý do tại sao tính năng này không hoạt động?

Tôi đã bao gồm ba tệp cấu hình bên dưới. Hãy cho tôi biết nếu những người khác sẽ giúp đỡ. Cảm ơn!

dotcloud.yml

www: 
    type: custom 
    buildscript: python/builder 
    systempackages: 
     # needed for the Nginx rewrite module 
     - libpcre3-dev 
     # needed to support python versions 2.7, 3.1, 3.2. 
     - python3-all 
    ports: 
     www: http 
    processes: 
     nginx: nginx 
     app: /home/dotcloud/env/bin/gunicorn -c /home/dotcloud/gunicorn.conf -b unix:/tmp/gunicorn.sock wsgi:application 
     #app: /home/dotcloud/env/bin/gunicorn -c /home/dotcloud/gunicorn.conf -b 0.0.0.0:$PORT_WWW wsgi:application 
    config: 
     # python_version can have one of the following values (2.6, 2.7, 3.1, 3.2). 2.6 is the default if no value is entered. 
     python_version: 2.7 
data: 
    type: redis 
db: 
    type: postgresql 

nginx.conf.in (giống như nginx thông thường.conf, chỉ với PORT_WWW chờ đợi để có được hoán đổi cho số cổng thực)

# template for nginx.conf file. 
# the file will be processed by the postinstall script 
# it will insert the correct value for PORT_WWW and then put this 
# file in /home/dotcloud/nginx/conf/nginx.conf when done. 

# nginx will be managed by supervisord when it starts so we don't need daemon mode 
daemon off; 

worker_processes 1; 

events { 
    worker_connections 1024; 
} 


http { 

include  mime.types; 
default_type application/octet-stream; 

sendfile  on; 
#tcp_nopush  on; 

keepalive_timeout 65; 

log_format combined-realip '$remote_addr ($http_x_real_ip) - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"'; 
access_log /var/log/supervisor/nginx_access.log combined-realip; 
error_log /var/log/supervisor/nginx_error.log error; 

gzip on; 


    upstream appserver { 
     server unix:/tmp/gunicorn.sock; 
     # For a TCP configuration: 
     # server 192.168.0.7:8000 fail_timeout=0; 
    } 


    server { 
    # PORT_WWW value is added via postinstall script. 
    listen @[email protected] default; 

    server_name localhost; 

    root /home/dotcloud/current/; 

    location/{ 
     if (-f /home/dotcloud/current/maintenance) { 
      return 503; 
     } 
     proxy_pass http://appserver; 
     proxy_http_version 1.1; 
     proxy_set_header upgrade $http_upgrade; 
     proxy_set_header Connection "upgrade"; 

    } 

    error_page 404 @404; 
    error_page 500 @500; 
    error_page 502 @502; 
    error_page 503 @503; 
    error_page 504 @504; 

    location @404 { 
     rewrite^/static/404.html; 
    } 
    location @500 { 
     rewrite^/static/500.html; 
    } 
    location @502 { 
     rewrite^/static/502.html; 
    } 
    location @503 { 
     rewrite^/static/503.html; 
    } 
    location @504 { 
     rewrite^/static/504.html; 
    } 

    location /static { 
     alias /home/dotcloud/current/static; 
    } 

    location /robots.txt { 
     alias /home/dotcloud/current/static/robots.txt; 
    } 

    location /favicon.ico { 
     alias /home/dotcloud/current/static/favicon.ico; 
    } 

    } 
} 

gunicorn.conf

workers = 1 
worker_class = 'socketio.sgunicorn.GeventSocketIOWorker' 
pidfile = '/tmp/gunicorn.pid' 
debug = True 
loglevel = 'debug' 
errorlog = '/var/log/supervisor/gunicorn.log' 
django_settings='/home/dotcloud/settings.py' 

def post_fork(server, worker): 
    from psycogreen.gevent import patch_psycopg 
    patch_psycopg() 

# MySQL 
#def post_fork(server, worker): 
# import pymysql 
# pymysql.install_as_MySQLdb() 
+2

Để dễ dàng hơn, tôi sẽ xóa nginx khỏi hỗn hợp trừ khi bạn thực sự cần nó. Nginx không thực sự cần thiết vì các cổng dotCloud sẽ phục vụ cùng một mục đích. Để làm cho mọi thứ trở nên dễ dàng hơn, bạn có thể làm điều tương tự với python-worker nguyên gốc và bạn sẽ không cần phải sử dụng dịch vụ tùy chỉnh chút nào. bạn chỉ cần chạy quy trình gunicorn và đảm bảo bạn yêu cầu một cổng http giống như cách bạn thực hiện cho dịch vụ tùy chỉnh. –

+0

Đó là câu trả lời tôi đã hy vọng! Cảm ơn, Ken. -Tim – t1m0

+0

Chưa kể đến các ổ cắm web không được hỗ trợ hoàn toàn ở bất kỳ thứ gì bên dưới phiên bản 1.4 trong nginx, do đó có thể là vấn đề của bạn ngay tại đó. Khác với cấu hình của bạn trông tốt. –

Trả lời

1

Tôi hỏi 5 câu hỏi liên quan trên, và tôi sẽ cố gắng trả lời là người đầu tiên 3 đây. (Tôi không biết đủ dotcloud nền tảng để trả lời hai câu cuối). Tôi cũng hy vọng hầu hết mọi người tìm thấy câu hỏi này tập trung chủ yếu vào websockets với gunicorn và nginx (và ít hơn trên các chi tiết dotcloud). Đối với những folks, bạn có thể nhảy đến một thiết lập tài liệu tham khảo ở đây: gunicorn deployment scheme with nginx

  1. Am Tôi cố gắng giải quyết một tổ chức phi vấn đề?

    a. Tôi đã thực hiện một số tiền hợp lý để đọc khi được khuyên nên đặt gunicorn phía sau nginx. Trong bối cảnh cân bằng tải dotcloud trên tuyến đầu, điều này vẫn đúng?

    b. Nếu tôi không mong đợi rằng tôi sẽ bị tấn công DoS, liệu nó vẫn là quan trọng để đặt gunicorn sau nginx?

Từ comment Ken Cochrane của trên, tôi tin rằng các cơ sở hạ tầng dotcloud tự cung cấp sự an toàn mà nginx thường sẽ cung cấp trong một thiết lập DIY. Do đó, trong trường hợp đặc biệt này, đây thực sự là một "không vấn đề". Tuy nhiên, nói chung, bạn không muốn gunicorn đằng sau nginx, và bạn chắc chắn có thể chạy websockets với thiết lập đó.

  1. Có thể chạy các ổ cắm web thông qua một ổ cắm unix như tôi đã cố gắng thiết lập không?

Có. Đây là một tài liệu tham khảo tốt trên gunicorn deployment scheme with nginx. Đối với WebSockets, hãy chắc chắn để đọc mà toàn phần và bao gồm proxy_buffering off;

  1. ổ cắm unix sẽ phá vỡ rộng trên dotcloud?

Hiểu biết của tôi là ổ cắm và cổng đều hoạt động tốt như nhau.