Слово "розгортання" може мати два значення в залежності від контексту. Ви також плутаєте ролі Apache / Nginx з ролями інших компонентів.
Історична примітка: Ця стаття спочатку була написана 6 листопада 2010 року, коли екосистема сервера додатків Ruby була обмежена. Цю статтю я оновив 15 березня 2013 року з усіма останніми оновленнями в екосистемі.
Відмова : Я один з авторів Phusion Passenger, одного з серверів додатків.
Apache проти Nginx
Вони обидва веб-сервери. Вони можуть обслуговувати статичні файли, але - за допомогою правильних модулів - також можуть обслуговувати динамічні веб-додатки, наприклад, написані на PHP. Apache є більш популярним і має більше функцій, Nginx менший і швидший і має менше функцій.
Ні Apache, ні Nginx не можуть обслуговувати веб-додатки Ruby поза коробкою, для цього потрібно використовувати Apache / Nginx у поєднанні з деяким доповненням, описаним пізніше.
Apache та Nginx також можуть діяти як зворотні проксі, тобто вони можуть приймати вхідний HTTP-запит та пересилати його на інший сервер, який також говорить HTTP. Коли цей сервер відповідає у відповідь HTTP, Apache / Nginx передасть відповідь назад клієнту; Пізніше ви дізнаєтесь, чому це актуально.
Mongrel та інші сервери виробничих додатків проти WEBrick
Mongrel - це сервер додатків Ruby: конкретно, це означає, що Mongrel - це програма, яка:
- Завантажте додаток Ruby всередині власного технологічного простору.
- Встановлює розетку TCP, що дозволяє їй спілкуватися із зовнішнім світом (наприклад, Інтернетом). Mongrel слухає HTTP-запити в цьому сокеті і передає дані запиту веб-додатку Ruby.
- Потім веб-додаток Ruby повертає об’єкт, в якому описується, як має виглядати відповідь HTTP, і Mongrel піклується про перетворення його на фактичну відповідь HTTP (фактичні байти) і відправляє його назад через сокет.
Однак Монгрель досить датований, сьогодні він більше не підтримується. Новіші альтернативні сервери додатків:
- Пасажир Phusion
- Єдиноріг
- Тонка
- Пума
- Тринідад (лише JRuby)
- TorqueBox (лише JRuby)
Я висвітлю їх згодом і опишу, чим вони відрізняються один від одного та від Монгрела.
WEBrick робить те саме, що і Монгрель, але відмінності:
- WEBrick не підходить для виробництва, на відміну від усього іншого, що я згадував раніше. WEBrick повністю написаний на Ruby. Mongrel (і більшість інших серверів додатків Ruby) є частиною Ruby і частиною C (В основному Ruby), але його HTTP-аналізатор написаний на C для продуктивності.
- WEBrick повільніше і менш надійний. У ньому є деякі відомі витоки пам'яті та деякі відомі проблеми розбору HTTP.
- WEBrick зазвичай використовується лише як сервер за замовчуванням під час розробки, оскільки WEBrick за замовчуванням включений до Ruby. Mongrel та інші сервери додатків потрібно встановити окремо. Не рекомендується використовувати WEBrick у виробничих середовищах, хоча чомусь Heroku вибрав WEBrick як свій сервер за замовчуванням. Раніше вони використовували Thin, тому я поняття не маю, чому вони перейшли на WEBrick.
Сервер додатків і весь світ
Всі поточні сервери додатків Ruby розмовляють HTTP, однак деякі сервери додатків можуть бути безпосередньо підключені до Інтернету через порт 80, а інші можуть.
- Сервери додатків, які можуть бути безпосередньо піддані впливу Інтернету: Phusion Passenger, Rainbows
- Сервери додатків, які можуть не піддаватися впливу Інтернету: Mongrel, Unicorn, Thin, Puma. Ці сервери додатків повинні бути поставлені позаду зворотного проксі-сервера, наприклад Apache та Nginx.
- Я недостатньо знаю про Тринідад і TorqueBox, тому я їх опустив.
Чому деякі сервери додатків повинні бути поставлені за зворотним проксі?
- Деякі сервери додатків можуть обробляти лише 1 запит одночасно за процес. Якщо ви хочете одночасно обробляти 2 запити, вам потрібно запустити кілька примірників сервера додатків, кожен з яких обслуговує одне і те саме додаток Ruby. Цей набір процесів на сервері додатків називається кластерним сервером додатків (звідси назва Mongrel Cluster, Thin Cluster тощо). Потім потрібно встановити Apache або Nginx, щоб повернути проксі-сервер до цього кластеру. Apache / Nginx подбає про розподіл запитів між екземплярами кластеру (докладніше про це в розділі "Моделі одночасності вводу / виводу").
- Веб-сервер може буферувати запити та відповіді, захищаючи сервер додатків від "повільних клієнтів" - клієнтів HTTP, які не надсилають та не приймають дані дуже швидко. Ви не хочете, щоб ваш сервер додатків нічого не робив, дочекавшись, коли клієнт надішле повний запит або отримає повну відповідь, оскільки за цей час сервер додатків може не змогти нічого іншого. Apache і Nginx дуже добре одночасно робити багато речей, тому що вони або багатопоточні, або парні.
- Більшість серверів додатків можуть обслуговувати статичні файли, але це не особливо добре. Apache і Nginx можуть зробити це швидше.
- Люди зазвичай налаштовують Apache / Nginx для прямого обслуговування статичних файлів, але переадресація запитів, які не відповідають статичним файлам, на сервер додатків - це хороша практика безпеки. Apache і Nginx дуже зрілі і можуть захищати сервер додатків від (можливо, зловмисно) пошкоджених запитів.
Чому деякі сервери додатків можуть бути безпосередньо піддані впливу Інтернету?
- Phusion Passenger - це зовсім інший звір від усіх інших серверів додатків. Однією з його унікальних особливостей є те, що він інтегрується у веб-сервер.
- Автор Rainbows публічно заявив, що безпечно прямо викрити його в Інтернеті. Автор досить впевнений, що в HTTP-аналізаторі (і подібних) немає вразливих місць. Проте автор не надає гарантій і каже, що використання на власний ризик.
Порівнюються сервери додатків
У цьому розділі я порівняю більшість згаданих я серверів прикладних програм, але не Phusion Passenger. Пасажир Фьюзії - настільки інший звір від решти, що я дав йому спеціальний розділ. Я також опустив Тринідад і TorqueBox, тому що я їх не знаю досить добре, але вони так чи інакше актуальні, якщо ви використовуєте JRuby.
- У Монгреля були досить голі кістки. Як згадувалося раніше, Mongrel - це суто однопотоковий багатопроцесовий процес, тому він корисний лише у кластері. Немає моніторингу процесів: якщо процес у кластері виходить з ладу (наприклад, через помилку в додатку), його потрібно перезапустити вручну. Люди схильні використовувати зовнішні засоби моніторингу процесів, такі як Моніт і Бог.
- Єдиноріг - це виделка Монгрель. Він підтримує обмежений моніторинг процесів: якщо процес виходить з ладу, він автоматично запускається головним процесом. Це може змусити всі процеси прослуховувати в одному спільному сокеті, а не окремому сокеті для кожного процесу. Це спрощує конфігурацію зворотного проксі. Як і Монгрель, це суто однопоточний багатопроцес.
- Тонкий використовує модель з вирівняним введенням-виведенням, використовуючи бібліотеку EventMachine. Окрім використання аналізатора HTTP Mongrel, він не заснований на Mongrel жодним чином. У його кластерному режимі немає моніторингу процесів, тому вам потрібно контролювати збої тощо. Немає спільного сокета, схожого на Єдиноріг, тому кожен процес слухає власний сокет. Теоретично модель тонкого вводу / виводу дозволяє отримати високу конкурентоспроможність, але в більшості практичних ситуацій, для яких використовується Thin, один тонкий процес може обробляти лише 1 паралельний запит, тому вам все одно потрібен кластер. Детальніше про цю своєрідну властивість у розділі "Моделі одночасності вводу / виводу".
- Пума також була роздвоєна від Mongrel, але на відміну від Єдинорога, Puma розрахована на суто багаторівневу різьбу. Тому в даний час немає вбудованої підтримки кластерів. Вам потрібно бути особливо обережним, щоб ви могли використовувати кілька ядер (Детальніше про це в розділі "Моделі одночасності вводу / виводу").
- Rainbows підтримує кілька моделей одночасності через використання різних бібліотек.
Пасажир Phusion
Пасажир Phusion працює дуже інакше, ніж усі інші. Phusion Passenger інтегрується безпосередньо в Apache або Nginx, і тому його можна порівняти з mod_php для Apache. Так само, як mod_php дозволяє Apache обслуговувати додатки PHP, майже магічно, Phusion Passenger дозволяє Apache (а також Nginx!) Обслуговувати додатки Ruby майже магічно. Мета Phusion Passenger - зробити так, щоб все просто працювало (тм) якомога менше клопотів.
Замість того, щоб запускати процес або кластер для вашої програми та конфігурувати Apache / Nginx для подачі статичних файлів та / або зворотних запитів проксі до процесу / кластеру з Phusion Passenger, вам потрібно лише:
- Ви редагуєте конфігураційний файл веб-сервера та вказуєте місце "загальнодоступного" каталогу додатка Ruby.
- Ні кроку 2 немає.
Вся конфігурація проводиться у файлі конфігурації веб-сервера. Phusion Passenger автоматизує майже все. Не потрібно запускати кластер і керувати процесами. Запуск / зупинка процесів, перезапуск їх при збої тощо - все автоматизовано. Порівняно з іншими серверами додатків, Phusion Passenger має набагато менше рухомих деталей. Така зручність використання є однією з головних причин, чому люди використовують Phusion Passenger.
Також на відміну від інших серверів додатків, Phusion Passenger написаний в основному на C ++, що робить його дуже швидким.
Існує також варіант компанії Phusion Passenger з ще більшими можливостями, такими як автоматизовані перезавантаження, багатопотокова підтримка, стійкість до помилок розгортання тощо.
З вищезазначених причин Phusion Passenger на даний момент є найпопулярнішим сервером додатків Ruby, що працює над 150 000 веб-сайтів, включаючи великі, такі як New York Times, Pixar, Airbnb тощо.
Phusion Passenger проти інших серверів додатків
Phusion Passenger надає набагато більше функцій та забезпечує багато переваг перед іншими серверами додатків, такими як:
- Динамічне регулювання кількості процесів на основі трафіку. На нашому сервері з обмеженими ресурсами ми запускаємо тону програм Rails, які не є загальнодоступними, і люди в нашій організації використовують лише максимум кілька разів на день. Такі речі, як Gitlab, Redmine тощо. Phusion Passenger може відкручувати ці процеси, коли вони не використовуються, і відкручувати їх, коли вони використовуються, дозволяючи отримати більше ресурсів для більш важливих додатків. З іншими серверами додатків усі ваші процеси постійно вмикаються.
- Деякі сервери додатків не є добрими при певних робочих навантаженнях за дизайном. Наприклад, Unicorn призначений лише для швидких запитів: Дивіться розділ веб-сайту Unicorn "Просто гірше в деяких випадках".
Навантаження, в якій Єдиноріг не годиться, є:
- Потокове навантаження (наприклад, потокова трансляція Rails 4 або потокова передача шаблонів Rails 4).
- Навантаження, у якій додаток виконує HTTP-дзвінки API.
Гібридна модель вводу-виводу в Phusion Passenger Enterprise 4 або новішої версії робить її відмінним вибором для таких видів навантажень.
- Інші сервери додатків вимагають, щоб користувач запускав принаймні один примірник на додаток. Навпаки, Phusion Passenger підтримує декілька додатків в одному екземплярі. Це значно зменшує накладні витрати.
- Автоматична комутація користувача, зручна функція безпеки.
- Phusion Passenger підтримує багато МРТ Ruby, JRuby і Rubinius. Монгрель, Єдиноріг і Худий підтримують тільки МРТ. Puma також підтримує всі 3.
- Пасажир Phusion насправді підтримує більше, ніж просто Рубі! Він також підтримує Python WSGI, тому він може, наприклад, також запускати програми Django та Flask. Насправді Phusion Passenger рухається у напрямку перетворення на сервер поліглотів. Підтримка Node.js у списку todo.
- Збір сміття поза межами групи. Пасажир Phusion може запускати колектор сміття Ruby поза звичайним циклом запиту / відповіді, потенційно скорочуючи час запиту на сотні мілісекунд. Єдиноріг також має подібну особливість, але версія Phusion Passenger є більш гнучкою, оскільки 1) вона не обмежується GC і може використовуватися для довільної роботи. 2) Версія Phusion Passenger добре працює з багатопотоковими програмами, а Unicorn - ні.
- Автоматизований прокат перезапускається. Повторний перезапуск на Unicorn та інших серверах вимагає певної роботи сценаріїв. Phusion Passenger Enterprise повністю автоматизує цей спосіб для вас.
Є більше можливостей та переваг, але список справді довгий. Ви повинні звернутися до всебічного керівництву Phusion Passenger ( версії Apache , Nginx версія ) або на веб - сайт пасажирської Phusion для інформації.
Моделі одночасності вводу / виводу
- Однопоточний багатопроцесорний процес. Це традиційно найпопулярніша модель вводу-виводу для серверів додатків Ruby, частково через те, що підтримка багатопотокової передачі в екосистемі Ruby була дуже поганою. Кожен процес може обробляти рівно 1 запит одночасно. Завантаження веб-сервера балансує між процесами. Ця модель є дуже надійною і мало шансів програмісту ввести помилки одночасності. Однак одночасність його вводу / виводу є надзвичайно обмеженою (обмежена кількістю процесів). Ця модель дуже підходить для швидких, коротких робочих навантажень. Це дуже непридатно для повільного, тривалого блокування навантажень вводу / виводу, наприклад робочих навантажень, що викликають виклики HTTP API.
- Чисто багатонитковий. В даний час екосистема Ruby має чудову підтримку багатопотокових передач, тому ця модель вводу-виводу стала дуже життєздатною. Багатопоточність дозволяє отримати високу конкурентоспроможність вводу / виводу, що робить його придатним як для короткочасних, так і для тривалих, що блокують навантаження вводу / виводу. Програміст, швидше за все, вводить помилки одночасності, але, на щастя, більшість веб-фреймворків створені таким чином, що це все ще малоймовірно. Однак слід зазначити, що інтерпретатор MRI Ruby не може використовувати декілька ядер CPU, навіть якщо є кілька потоків, завдяки використанню глобального блоку інтерпретаторів (GIL). Ви можете обійти це за допомогою декількох багатопотокових процесів, оскільки кожен процес може використовувати ядро CPU. JRuby і Rubinius не мають GIL, тому вони можуть повністю використовувати кілька ядер за один процес.
- Гібридний багатопотоковий багатопроцесорний процес. В основному реалізується Phusion Passenger Enterprise 4 та пізніших версій. Ви можете легко перемикатися між багатопотоковими багатопотоковими, чисто багатопотоковими або, можливо, навіть декількома процесами, кожен з декількома потоками. Ця модель дає найкраще з обох світів.
- Вечір. Ця модель абсолютно відрізняється від раніше згаданої моделі. Це дозволяє дуже високу одночасність вводу / виводу, а тому відмінно підходить для тривалого блокування робочих навантажень вводу / виводу. Для його використання потрібна чітка підтримка програми та рамки. Однак усі основні рамки, такі як Rails та Sinatra, не підтримують парний код. Ось чому на практиці тонкий процес все ще не може обробити більше ніж 1 запит одночасно, завдяки чому він ефективно веде себе таким же, як однопотокова багатопроцесова модель. Існують спеціалізовані рамки, які можуть скористатися вирівняними введеннями / виводами, наприклад, Cramp.
Нещодавно у блозі Phusion була опублікована стаття про оптимальне налаштування кількості процесів та потоків з урахуванням вашої завантаженості. Див. Налаштування параметрів сумісності Phusion Passenger .
Капістрано
Капістрано - це щось зовсім інше. У всіх попередніх розділах "розгортання" посилається на акт запуску програми Ruby на сервері прикладних програм, щоб він став доступним для відвідувачів, але до цього може статися звичайно потрібно виконати деякі підготовчі роботи, такі як:
- Завантаження коду та файлів програми Ruby на серверну машину.
- Встановлення бібліотек, від яких залежить ваш додаток.
- Налаштування або переміщення бази даних.
- Запуск та зупинка будь-яких демонів, на які може покластися ваш додаток, наприклад, Sidekiq / Resque працівників чи будь-чого іншого.
- Будь-які інші речі, які потрібно зробити під час налаштування програми.
У контексті Капістрано під «розгортанням» розуміється виконання всієї цієї підготовчої роботи. Capistrano не є сервером додатків. Натомість це інструмент для автоматизації всіх цих підготовчих робіт. Ви повідомляєте Capistrano, де знаходиться ваш сервер і які команди потрібно запускати щоразу, коли ви розгортаєте нову версію свого додатка, і Capistrano подбає про завантаження програми Rails на сервер для вас та запускає вказані вами команди.
Capistrano завжди використовується в поєднанні з сервером додатків. Він не замінює сервери додатків. І навпаки, сервери додатків не замінюють Capistrano, їх можна використовувати в поєднанні з Capistrano.
Звичайно, не потрібно використовувати Capistrano. Якщо ви віддаєте перевагу завантажувати додаток Ruby за допомогою FTP і вручну виконувати ті самі кроки команд кожен раз, тоді ви можете це зробити. Інші люди втомилися від цього, тому вони автоматизували ці кроки в Капістрано.