Внедрение веб-приложения Ruby в производство - запутанный процесс и т. Д.

Question

Я готовлюсь толкнуть веб-приложение, которое частично реализовано с помощью инфраструктуры Camping, но в основном взломано вместе, в производство.

Я, вероятно, оставлю его позади nginx, но это единственная веб-разработка, которую яВ прошлом уже работал Apache с PHP и node.js. Я не совсем понимаю, что происходит в памяти и с процессами, когда вы запускаете веб-приложение Ruby в производство.

Camping предоставляет сервер разработки, который по умолчанию работает на порте 3301.Мне пришло в голову, что с Nginx я могу просто перенаправить прокси к процессу, запущенному на этом порту, для любых запросов к приложению для кемпинга.Это ужасная идея?

Если я сделаю это другим способом - с WSGI или обратным прокси-сервером Unicorn / Thin - что именно произойдет с параллелизмом?Буду ли я создавать новый процесс Ruby для каждого запроса, где все настройки для моего веб-приложения, а также все определения и генерации классов и все остальное должны быть выполнены с нуля?Есть ли какое-то волшебство на каком-то уровне стека, где кешируется состояние моего приложения?

Извините за хаос моего вопроса - я действительно понятия не имею, как это работает, когда оно где-то между абсолютами путиApache использует PHP и способ, которым HTTP-сервер node.js имеет один процесс (обычно), который просто прослушивает порт.

Answer 1

Для всего, что основано на стойке (Rails, Camping, Sinatra ...), Passenger - это, как правило, путьЕго очень легко настроить (не нужно возиться с прокси-серверами) и он работает с Nginx и Apache.

Answer 2

Запуск вашего приложения под Unicorn или thin абсолютно нормален, поэтому меня это не беспокоит.Я не уверен, что вы имеете в виду о параллелизме?

Unicorn / thin загрузит вашу конфигурацию / классы и т. Д. Только один раз.Unicorn будет обрабатывать процесс для каждого запроса, но это не перезагрузит ваше приложение.