O que é fino e por que preciso

6

Esta é uma questão muito noob, e desde que eu realmente nunca entendi, gostaria de uma explicação:

  • O que é o Thin (ou passageiro ou outra alternativa)?
  • Qual é o propósito de Thin (ou outra alternativa)?
  • Por que preciso do Thin (ou outro alt.) com o Apache (ou Nginx ou outra alternativa)?
  • Pode Thin (ou outro alt.) ser usado sem o Apache (ou outro alt.)?
  • Quais são as diferenças entre Thin (ou outro alt.) e Apache (ou outro alt.)?

No momento, meu entendimento atual (limitado e possivelmente equivocado) do problema é .... O Apache é um servidor web http (que age como um proxy reverso nesse caso (?) ) e Thin é um servidor de aplicativos da web Ruby. Por que eles são o que são e como eles trabalham um pouco me evita.

A redação pode ser muito confusa (por exemplo, servidor da Web vs. servidor de aplicativos da Web, entre outros ...), como a "host" ou "hostname" pode ser muito confusa) na Internet também. Onde posso desenvolver minha "compreensão mínima do problema a ser resolvido", se todo o material de leitura que eu encontrar on-line não for muito claro para mim?

    
por agent provocateur 17.06.2014 / 22:07

1 resposta

9

Thin, ou Passenger, ou WEBrick, ou qualquer outro servidor web, tem um único propósito. Ele recebe uma solicitação HTTP da rede e a envia para o Rack e retorna a resposta do aplicativo na rede.

(Normalmente, o Rack é usado como um componente de um aplicativo Ruby completo escrito com uma estrutura como Rails ou Sinatra. Ele processa solicitações HTTP de entrada por meio de seu próprio middleware e garante que eles sejam roteados para o código correto do aplicativo.

O que acontece com o pedido depois que Thin o envia para o Rack geralmente não é uma preocupação do Thin; é a preocupação do aplicativo e do desenvolvedor do aplicativo.

A razão pela qual um servidor web Ruby é normalmente colocado atrás de um servidor web mais tradicional, como Apache ou nginx, é para desempenho. O servidor da Web Ruby é escrito em Ruby e otimizado para lidar com a pilha de aplicativos que está sendo usada. Em particular, não é necessariamente muito bom servir rapidamente a ativos estáticos. Na configuração de produção usual, um servidor da Web tradicional servirá os ativos estáticos, que O Rails pré-compila como uma tarefa de rake durante a implantação ou no primeiro acesso , e Thin (ou o seu servidor de escolha) passará todo o resto para o aplicativo. Como resultado, executar Thin alone é útil apenas em um ambiente de desenvolvimento, já que o desempenho geralmente não é um problema. Não é algo que faríamos. (E normalmente o WEBrick é usado para esse propósito, já que é o servidor web padrão para aplicações Rails.)

Como administradores de sistemas, geralmente não nos importamos com o código do aplicativo, embora em alguns casos você queira trabalhar com o desenvolvedor para avaliar qual dos vários servidores Web Ruby possíveis deve ser usado com um determinado aplicativo. Embora, como regra geral, do ponto de vista da aplicação, eles devem ser intercambiáveis.

    
por 21.06.2014 / 00:19