Pregunta Apache + Tomcat VS Stand Alone Tomcat o GlassFish


Estoy configurando un servidor Debian para servir aplicaciones web Java. He hecho un poco de investigación durante varias semanas ahora. El sitio web de Tomcat dice que es mejor usar Tomcat autónomo para la velocidad si no está agrupado. Sin embargo, he visto a muchas personas sugerir que el uso de Apache + Tomcat le brinda mayor seguridad y protección contra los ataques.

Supongamos que el proceso se ejecutará en el puerto 80 como un usuario sin privilegios. Supongo que si está ejecutando un firewall frente al servidor, Tomcat debería estar bien. Sin embargo, si solo desea ejecutar un servidor web expuesto utilizando un firewall de Linux, ¿cuál es la mejor opción?

O tal vez alguien pueda recomendar otro servidor web de código abierto. Estoy tratando de mantener la solución lo más liviana posible ya que estas aplicaciones web se ejecutarán en contenedores.

Todas las opiniones son bienvenidas y valoradas.


6
2018-03-31 14:23


origen




Respuestas:


Desde mi propia experiencia, es sabio mantener algo frente a Tomcat para protegerlo un poco del mundo exterior. Si ejecuta Tomcat con la extensión nativa de Tomcat, IO es muy rápido y Tomcat se comportará muy bien.

Además, Tomcat puede ejecutarse en el puerto 80 sin ejecutarse en la raíz mediante el uso de jsvc que, si no se proporciona con su distribución, es muy fácil de compilar y usar.

Sin embargo, mantener un frontend web simple por si acaso también es útil: porque este frontend puede darle el pequeño toque de flexibilidad que nunca tendrá con Tomcat (gzip sobre la marcha, reglas de reescritura, manejar más de un tomcat en la misma IP: Puerto usando un host virtual simple y un mapeo de proxy, ...)

Apache2 puede ser este frontend usando mod_proxy + AJP. AJP maneja los encabezados y el reenvío de IP de origen a Tomcat y nunca será mucho más feliz cuando tenga que agregar RewriteRules en su dominio porque Apache lo proporciona de una manera muy simple.

Sin embargo, AJP es muy lento para elegir el cambio de estado de la aplicación web y tener que esperar 30 segundos cuando la aplicación se reinicia para verla nuevamente disponible en Internet es MUY frustrante. También hay algunos problemas no tan agradables en la última combinación AJP + Tomcat que conduce a páginas vacías y tipos de contenido rotos (aunque se puede corregir, pero al renunciar a las mejoras nativas de Tomcat ...).

Lo simple HTTP Mod_proxy También se puede usar, pero al no ser un proxy real (Apache cambia el encabezado Host:, la dirección IP de origen se convierte en la dirección proxy, ...) es algo que realmente no me gusta.

Otras alternativas agradables incluyen:

  • HAProxy: Proxy muy inteligente y simple, muy bueno en el manejo de la carga, bastante simple de configurar, sólido y un Proxy HTTP real, puede reenviar la IP de origen a través del encabezado habitual de X-Forwarded-For. Uso esto en producción y estoy muy feliz por eso. Puede escalar hasta miles de conexiones en vivo a la vez que restringe la cantidad de conexiones activas a su servidor y tiene muchas características interesantes integradas. Sin embargo, probablemente no sea adecuado hacer algo mucho más inteligente que el enrutamiento HTTP (como RewriteRules, por ejemplo).

  • Nginx: He oído que este servidor realmente soporta AJP. Siendo más ligero que Apache y más completo que HAProxy, probablemente lo intentaré hoy si tuviera la oportunidad.

Conclusión

  • Si tienes algo de tiempo para probar, prueba Nginx,
  • Si prefieres tener un frontend simple y sólido, opta por HAProxy,
  • Si prefieres la ruta "tradicional", ve a Apache2 + AJP,
  • Si cree que Tomcat será lo suficientemente fuerte y le brindará todas las funciones que necesita, use jsvc y ponga Tomcat en el puerto 80

4
2018-04-02 15:58



Gracias por la respuesta completa. Tendré que investigar Nginx. Decidí usar lighttpd por su pequeña huella frente a Tomcat o Winstone, pero Nginx lo hace muy interesante con sus módulos de correo también. He visto HAProxy, pero pensé que si usaba un servidor web con webdav, tendré más opciones de contenedores. ¡Gracias! - TonyZ
lighttpd tiene una reputación de fugas como un tamiz. Creo que Nginx es mejor. - Draemon


El problema que encontré con Tomcat y Glassfish en UNIX es que (debido a que son aplicaciones Java, supongo) no pueden enlazarse al puerto 80 y luego abandonar los privilegios de root. Ejecutar estos tipos de cosas como root no es una buena práctica, por lo que deja dos opciones:

(1) Ejecute el servidor de aplicaciones como un usuario regular vinculado a un puerto alto (por ejemplo, 8080) y use algo como una regla de iptables para redirigir el tráfico del puerto 80 al puerto 8080. He hecho esto con algunos servidores Glassfish en Linux y funcionó muy bien.

(2) Ejecute el servidor de aplicaciones como un usuario regular detrás de Apache. Apache puede unirse al puerto 80, quitar privilegios y luego enviar las solicitudes a su servidor de aplicaciones en un puerto alto.

Prefiero lo último, pero sobre todo porque he trabajado con Apache durante mucho tiempo y me resulta cómodo de configurar y administrar. Por lo tanto, si conoce bien el uso de Apache, se alegrará de haberlo hecho cuando necesite volver a escribir algunas URL al vuelo o ajustar los encabezados de caducidad. Por otro lado, si no tiene experiencia con Apache (o en este caso, ya que necesita que las cosas sean lo más ligeras posible), podría ser más fácil limitarse a Tomcat y usar iptables.


1
2018-03-31 21:42



Gracias. Estoy en Debian, así que puedo usar authbind. No tengo mucha experiencia con Apache, pero estaba buscando la solución más eficiente y más pequeña. Sé que Jetty probablemente haría el trabajo, pero también necesito webdav, lo cual se puede lograr con cualquiera de las combinaciones anteriores. Sin embargo, estos serán servidores públicos y algunos han dicho que Apache puede reducir su superficie de ataque. En el pasado, he usado Sun Web Server, pero es realmente excesivo para una sola aplicación. - TonyZ
@TonyZ: No tuve mucha suerte al usar authbind (o privbind) con GlassFish serverfault.com/questions/124537/… - Chris Lercher


Siguiendo la respuesta de @ deutsch, Tomcat NO tiene que ejecutarse como root en UNIX. Si lo instala desde un paquete, por ejemplo. El RPM de Tomcat6 para Fedora / CentOS / Red Hat, se ejecutará como usuario Tomcat con un conjunto restringido de privilegios.

Dicho esto, estoy de acuerdo con el último párrafo de @ Deutsch; use Apache como una interfaz para Tomcat a menos que tenga una fecha límite muy restrictiva para implementarse. Incluso si todavía no está familiarizado con él, es fácil lograr una implementación básica con mod_proxy frente a Tomcat, y es casi seguro que se beneficiará del aumento de la flexibilidad y la seguridad en el futuro.


1
2018-04-01 01:16



Si instala Tomcat desde un archivo tar oficial, ejecútelo como un usuario no root y si cambia manualmente su puerto a 80, no podrá vincularlo como cabría esperar. Esto también es cierto para los paquetes de Debian que espero que esté usando el OP. ¿Hay algo especial acerca de los RPM que mencionas? ¿Quizás están utilizando las capacidades de Linux? Soy curioso - Deutsch
@Deutsch, no estoy seguro de la respuesta a su pregunta, ya que no he intentado cambiar manualmente el puerto Tomcat a 80; si quiero ejecutarme en el puerto 80 siempre pongo un proxy Apache frente a Tomcat. - gareth_bowles