Это вопрос для новичков, и, поскольку я никогда не понимал его, мне хотелось бы получить объяснение:
В данный момент, мое текущее (ограниченное и, возможно, ошибочное) понимание проблемы это .... Apache - это веб-сервер http (который в данном случае действует как обратный прокси (?)), а Thin - это сервер веб-приложений на ruby. Почему они такие, какие они есть, и как они работают, меня несколько ускользает.
Формулировка может быть очень запутанной (например, веб-сервер или сервер веб-приложений, среди прочего ... (вроде того, как «хост» или «имя хоста» могут быть очень запутанными)) также в Интернете. Куда мне обратиться, чтобы развить «минимальное понимание решаемой проблемы», если все материалы для чтения, которые я нахожу в Интернете, мне не очень понятны?
Тонкий, или Пассажирский, или WEBrick, или любой другой подобный веб-сервер имеет единственную цель. Он принимает HTTP-запрос из сети и передает его Стойка, и возвращает ответ приложения в сеть.
(Обычно Rack используется как один из компонентов полного приложения Ruby, написанного на такой платформе, как Rails или Sinatra. Он обрабатывает входящие HTTP-запросы через собственный промежуточное ПО и гарантирует, что они будут перенаправлены на правильный код приложения.)
Что происходит с запросом после того, как Thin отправляет его в Rack, обычно Thin не касается; это забота приложения и разработчика приложения.
Причина, по которой веб-сервер Ruby обычно размещается за более традиционным веб-сервером, таким как Apache или nginx, связана с производительностью. Веб-сервер Ruby написан на Ruby и оптимизирован для работы со стеком приложений, который он обслуживает. В частности, это не обязательно очень хорошо для быстрого обслуживания статических активов. В обычной производственной установке традиционный веб-сервер будет обслуживать статические ресурсы, которые Rails предварительно компилируется либо как задача при развертывании, либо при первом доступе, а Thin (или выбранный вами сервер) передаст все остальное приложению. В результате запуск только Thin полезен только в среде разработки, поскольку производительность обычно не является проблемой. Мы не стали бы этого делать. (И обычно для этой цели используется WEBrick, поскольку это веб-сервер по умолчанию для приложений Rails.)
Как системные администраторы, мы, как правило, не заботимся о коде приложения, хотя в некоторых случаях вы захотите поработать с разработчиком, чтобы оценить, какой из нескольких возможных веб-серверов Ruby следует использовать с данным приложением. Хотя, как правило, с точки зрения приложения они должны быть взаимозаменяемыми.