est-il vraiment nécessaire d'exécuter Apache en tant que frontal pour Glassfish / JBoss / Tomcat?

Je suis principalement un développeur Java, et je viens à vous avec une question qui chevauche le fossé entre les développeurs et les administrateurs système.

Il y a des années, lorsque c'était une nouveauté d'exécuter Tomcat en tant que serveur d'applications, il était habituel de le gérer avec Apache. Si je comprends bien, cela a été fait parce que:

1. Java était considéré comme "lent" et il était utile qu'Apache serve directement le contenu statique.
2. Tomcat ne pouvait pas écouter les ports 80/443 à moins d'être exécuté en tant que root, ce qui était dangereux.

Java n'est plus considéré comme lent, et je doute que l'ajout d'Apache au mixage aidera réellement à accélérer les choses.

En ce qui concerne le problème des ports, il existe probablement des moyens plus simples de connecter les serveurs d'applications aux ports 80/443 de nos jours.

Donc ma question est- est-il vraiment avantageux de faire face à Java Webapps avec Apache ces jours-ci? Si oui, Apache est-il toujours le chemin à parcourir? Dois-je regarder Nginx? Au lieu de Tomcat, j'utilise Glassfish, si cela importe.

La plupart des gens vont dire que vous avez besoin de quelque chose à l'avant en raison de fichiers statiques.

C'est un peu stupide car:

• Vous pouvez configurer Tomcat pour utiliser le même IO qu'apache avec APR
• Vous devez de toute façon utiliser un CDN (Content delivery network).

La vraie raison pour laquelle vous avez besoin de quelque chose devant tomcat / jetty / jboss pour charger l'équilibre et gérer le basculement.

Je vous recommande de ne pas écouter " ... Le moteur Tomcat est le talon d'Achille de toute l'écosphère ... " car nous savons tous que ce n'est pas vrai ... votre base de données et son pool de connexions seront les mêmes.

Cela dépend de l'écosystème autour de votre application. Dans un environnement intranet - vous n'avez probablement besoin de rien devant Tomcat.

S'il est seul sur Internet en tant que service public, cela dépend. Apache est agréable à cause des modules qu'il fournit comme mod_security. Mais si vous ne connaissez pas la configuration d'apache (ou ngix) - vous pourriez vous exposer à encore PLUS d'attaques ou de points d'échec en raison d'une mauvaise configuration.

Apache en face est pratique pour servir les pages de panne dans les cas où vous devez mettre à niveau la webapp et attendre un redémarrage. Mais si les redémarrages sont rares ou s'ils sont chronométrés correctement - c'est une autre raison de devenir Tomcat autonome.

La FAQ Tomcat en parle également, qui aborde certains points supplémentaires: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

Apache n'est pas un bon candidat pour diffuser du contenu statique en raison de sa nature multi-processus. Nginx convient mieux car il utilise des E / S asynchrones pour traiter les demandes. Les Tomcats modernes peuvent également utiliser des E / S asynchrones (NIO dans la terminologie Java). Par exemple, vous devez installer le tomcat-nativepackage dans Fedora pour que Tomcat utilise les E / S asynchrones.

Étonnantes, certaines de ces réponses - certains d'entre vous exécutent-ils réellement des sites Web multiniveaux et multi-serveurs Tomcat à hautes performances? OP, votre supposition originale que Tomcat n'est pas "lent" ... wow. Le moteur Tomcat est le talon d'Achille de toute l'écosphère.

Oui, vous voulez qu'Apache soit en tête - il fournit d'abord et avant tout mod_rewrite (avez-vous déjà implémenté UrlRewriteFilter dans votre Tomcat?) Ainsi que les fichiers htaccess qui rendent la protection d'un serveur Web si importante. Apache peut vous permettre d'équilibrer la charge des nœuds Tomcat derrière lui, de servir votre contenu statique beaucoup plus rapidement et d'obtenir de meilleures performances de Tomcat car vous ne surchargez pas son canal de demande avec des composants non Java (js / css / html / jpg / etc.) des choses. Vous pouvez décharger votre SSL sur Apache (si ce n'est pas sur un LB matériel) avec facilité et ne pas même avoir à faire face à cette parodie appelée Java Keystore. Il y a tellement de victoires - vous pouvez régler mod_jk sur vos nœuds principaux pour éviter de surcharger le pauvre petit cerveau de Java car il ne peut généralement pas gérer un trafic massif avec le codeur Java moyen ''

Méfiez-vous de toute personne qui vous dit qu'Apache (ou nginx, etc. - mais les performances d'Apache surclasseront Tomcat de toute façon, peu importe) n'est pas une bonne idée devant Tomcat.

S'il s'agit simplement de lier des privilèges au port sans être root lorsque vous utilisez Tomcat, vous n'avez pas besoin de le gérer avec Apache httpd. Tomcat est livré par défaut avec ce jsvcque vous devez compiler.

jsvcest un wrapper de service java pour lancer Tomcat en tant que service. Ce service démarre en tant que root mais démarre Tomcat en tant qu'utilisateur normal. Vous pouvez donc lier votre Tomcat à des ports privilégiés.

Je ne connais pas Glassfish, mais assurez-vous qu'il existe des solutions et sinon vous pouvez sûrement utiliser des techniques de redirection de port (iptables, etc ...)

Je pense que le choix de faire face à un serveur d'applications avec un serveur Web (Apache httpd par exemple) est pour l'équilibrage de charge, le clustering ou pour servir des ressources statiques uniquement avec un serveur Web et des ressources dynamiques avec un serveur d'applications.