Я маю намір використовувати одну VPS для розгортання декількох додатків CherryPy з низьким трафіком як підкаталогів; наприклад: example.com/app1, example.com/app2і т.д.

Після вивчення розгортання WSGI виглядає, що кращим методом розгортання додатків є використання сервера WSGI (Gunicorn, uWSGI тощо) та NGinx у налаштуваннях зворотного проксі. Здається, надмірне використання двох веб-серверів у тандемі - тим більше, що мій додаток CherryPy є самим веб-сервером - але я не хочу відкидати цю ідею, як вона з'являється скрізь . Я, звичайно, не експерт, тому я хотів би це обговорити.

Я бачу три варіанти:

• Розгорніть CherryPy самостійно.
• Розгорнути під Gunicorn або іншим сервером WSGI.
• Розгортання під сервером WSGI та реверс-проксі до NGinx, що, здається, є рішенням кожного.

Мої запитання:

• Яка основна причина, коли я бачу цю закономірність скрізь? Є Nginx тільки що добре?
• Чи достатньо хороший власний сервер CherryPy для додатків із низьким трафіком чи я навіть не намагаюся?

Будь-яка порада цінується, дякую.

Причина, по якій всі ставлять nginx (або інший сервер, наприклад Apache) перед своїми серверами додатків, полягає в тому, що у кожного є статичний вміст, такий як зображення, CSS та JavaScript, і дивні вимоги, характерні для їх застосування.

Ваш сервер додатків (CherryPy, guicorn, будь-який інший) оптимізований для запуску вашої програми та обслуговування її результатів. Хоча сервер додатків також може обслуговувати статичний контент, вони майже ніколи не оптимізовані для цього завдання, оскільки це вторинне значення для основної мети сервера додатків. (Деякі сервери додатків також допоможуть мінімізувати та стискати ваші CSS та JS, щоб веб-сервер спереду міг обслуговувати ці ресурси ще швидше.)

Крім того, власне веб-сервер може зробити набагато більше, ніж високопродуктивний показ вмісту. Такі речі, як кешування, маніпулювання заголовком, переписування URL-адрес, геолокація та багато інших функцій, які просто роздують сервер додатків без жодних цілей.

Як правило, ви б запускали сервер додатків поодинці лише під час розробки програми, коли ви єдиний користувач, а продуктивність не є проблемою. Навіть якщо на вашому сайті мало трафіку, ви хочете, щоб він був швидшим, правда? Сайти з низьким трафіком, які є повільними, як правило, не переростають у сайти з високим трафіком ...

Чому люди ставлять Nginx попереду?

1. Nginx - це асинхронний веб-сервер. Це означає, що він не виділяє потік або процес на з'єднання. Натомість він використовує вподобану бібліотеку опитування сокетів для ОС і, таким чином, може обробляти сто тисяч підключень. Чому ви, як розробник додатків, повинні піклуватися? Оскільки Nginx буферизує з'єднання і передає запит лише вашому екземпляру CherryPy вище за течією, коли запит буде повністю прочитаний. Те саме для відповідей. Таким чином ваша програма CherryPy, яка є потоковим сервером, за Nginx у багатьох сенсах, стає асинхронною. Зокрема, ви подаєте руку на проблему з повільним клієнтом і повільні атаки DOS на лоріс.
2. Nginx має обмеження швидкості з'єднання поза коробкою. Скажімо, я не хочу більше, ніж 8 одночасних з'єднань з одного IP-адреси.
3. У CherryPy проблема з SSL . Nginx ні.
4. Python може надсилати байти назад і назад майже так само добре, як C. Python - zlibце просто обгортка навколо бібліотеки C. Але оскільки Nginx ефективно обробляє з'єднання, це гарна ідея позбавити ваші робочі потоки CherryPy від подачі статичного вмісту у виробництві та присвятити лише динамічному контенту.
5. Мультиплексування декількох екземплярів CherryPy на одному порту, домені, шляху тощо. Взагалі додаткова гнучкість іншого рівня конфігурації.

Чи безпечно використовувати CherryPy самостійно?

За словами одного з оригінальних авторів, так . Більшість релевантних веб-речей, які ви можете зробити з CherryPy самостійно.

CherryPy має поняття програми, і ви можете обслуговувати кілька додатків в одному екземплярі CherryPy. CherryPy також може обслуговувати інші програми WSGI .

Розгортання CherryPy

У традиційному * nix-стилі розгортання ви пишете сценарій init, демонструєте його, опускаєте його привілеї, пишете його PID тощо. Це не велика справа, коли у вас є кілька екземплярів CherryPy. Коли у вас є десятки, це стає стомлюючим, і є сенс передавати управління процесами Gunicorn або uWGSI і переключити ваші екземпляри CherryPy з HTTP на WSGI.

Я написав скелет підручника / проекту, cherrypy-webapp-skeleton , метою якого було заповнити прогалини для розгортання (традиційного) реальної програми CherryPy в реальному світі на Debian для веб-розробника.

Загорнути

1. Недостатній трафік, особливих вимог немає → CherryPy * 1 ⇐ HTTP ⇒ Client.
2. Високий трафік, особливі вимоги → CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.
3. Десятки окремих екземплярів CherryPy на одному сервері, які прагнуть переборщити рішення кожного → CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client.