Apache + Tomcat VS Tomcat sozinho ou GlassFish

Question

Estou configurando um servidor Debian para servir aplicações web Java. Eu fiz um pouco de pesquisa por várias semanas agora. O site do Tomcat diz que é melhor usar o Tomcat independente para velocidade se você não estiver em cluster. No entanto, tenho visto muitas pessoas sugerirem que o uso do Apache + Tomcat oferece melhor segurança e proteção contra ataques.

Por favor, assuma que o processo será executado na porta 80 como um usuário não privilegiado. Eu diria que se você estiver executando um firewall na frente do servidor, o Tomcat deve estar bem. Se, no entanto, você quiser apenas executar um servidor da Web exposto usando o firewall do Linux, qual é a melhor opção?

Ou talvez alguém possa recomendar outro servidor da Web de código aberto. Estou tentando manter a solução o mais leve possível, pois esses aplicativos da web estarão sendo executados em contêineres.

Todas as opiniões são bem-vindas e valorizadas.

    

Answer 1

Da minha própria experiência, é sensato manter algo na frente do Tomcat para protegê-lo um pouco do mundo exterior. Se você executar o tomcat com a extensão nativa do Tomcat, o IO será muito rápido e o Tomcat se comportará muito bem.

O Tomcat também pode ser executado na porta 80 sem executar o root, usando o jsvc, que, se não for fornecido com sua distro, é muito simples de criar e usar.

No entanto, manter um simples front-end na web também é útil: porque este frontend pode dar a você o pequeno toque de flexibilidade que você nunca terá com o Tomcat (gzip on the fly, reescrever regras, manipular mais de um tomcat no mesmo IP: Porta usando virtualhost simples e mapeamento de proxy, ...)

O Apache2 pode ser esse frontend usando mod_proxy + AJP . A AJP lida com cabeçalhos e encaminhamento de IP de origem para o Tomcat e você nunca será muito mais feliz quando precisar adicionar RewriteRules em seu domínio, pois o Apache fornece isso de uma maneira muito simples.

No entanto, o AJP é muito lento para escolher a mudança de status do webapp e ter que esperar 30 segundos quando o seu webapp reinicia para vê-lo disponível novamente na internet é MUITO frustrante. Existem também alguns problemas não tão bons na mais recente combinação de AJP + Tomcat que leva a páginas vazias e a um tipo de conteúdo quebrado (pode ser corrigido, mas desistindo dos aprimoramentos nativos do tomcat ...).

O HTTP Mod_proxy simples também pode ser usado, mas por não ser um proxy real (o Apache altera o cabeçalho Host: o IP de origem se torna o endereço de proxy, ...) é algo que eu não faço realmente gosto.

Outras boas alternativas incluem:

• HAProxy : Proxy muito inteligente e simples, muito bom em lidar com carga, muito simples de configurar, robusto e um proxy HTTP real, pode encaminhar o IP de origem através do usual X- Encaminhado para o cabeçalho. Eu uso isso na produção e estou muito feliz com isso. Ele pode escalonar até milhares de conexões ao vivo, enquanto restringe o número de conexões ativas ao seu back-end e possui muitos recursos interessantes integrados. No entanto, provavelmente não é adequado fazer algo muito mais inteligente do que o roteamento HTTP (como RewriteRules, por exemplo).

• Nginx : Eu ouvi que este servidor realmente suporta o AJP. Sendo mais leve que o Apache e com mais recursos que o HAProxy, provavelmente tentarei isso hoje se eu tivesse a oportunidade.

Conclusão

• Se você tiver algum tempo para testar, tente o Nginx,
• Se você preferir ter um frontend simples e sólido, vá para o HAProxy,
• Se você preferir a rota "tradicional", vá para Apache2 + AJP,
• Se você acha que o Tomcat será strong o suficiente e fornecerá todos os recursos necessários, use o jsvc e coloque o Tomcat na porta 80

Answer 2

O problema que eu tive com o Tomcat e o Glassfish no UNIX é que (porque eles são aplicativos Java, eu suponho) eles não podem se ligar à porta 80 e então soltar privilégios de root. A execução desses tipos de coisas como raiz não é uma prática recomendada, o que deixa duas opções:

(1) Execute o servidor de aplicativos como um usuário comum ligado a uma porta alta (por exemplo, 8080) e use algo como uma regra iptables para redirecionar o tráfego da porta 80 para a porta 8080. Fiz isso com alguns servidores Glassfish no Linux e funcionou muito bem.

(2) Execute o servidor de aplicativos como um usuário comum por trás do Apache. O Apache pode ligar-se à porta 80, descartar privilégios e, em seguida, fazer proxy dos pedidos para o seu servidor de aplicativos em uma porta alta.

Eu prefiro o último, mas principalmente porque eu trabalhei com o Apache por um longo tempo e achei conveniente configurar e gerenciar. Portanto, se você sabe que o Apache o utiliza, ficará feliz quando precisar reescrever algumas URLs ou ajustar os cabeçalhos de expiração. Por outro lado, se você não tiver experiência com o Apache (ou, neste caso, já que você precisa que as coisas sejam tão leves quanto possível), pode ser mais fácil manter apenas o Tomcat e usar o iptables.

    

Answer 3

Seguindo a resposta do @deutsch, o Tomcat NÃO precisa ser executado como root no UNIX. Se você instalá-lo de um pacote, por exemplo o tomcat6 RPM para Fedora / CentOS / Red Hat, ele será executado como usuário tomcat com um conjunto restrito de privilégios.

Dito isto, concordo com o último parágrafo do @ Deutsch; use o Apache como um front end para o Tomcat, a menos que você esteja sob um prazo muito restritivo para ser implantado. Mesmo que você não esteja familiarizado com isso ainda, é fácil obter uma implementação básica com o mod_proxy na frente do Tomcat, e você certamente se beneficiará da maior capacidade de flixibilidade e segurança.