APACHE TOMCAT

18 928 vues

Publié le

APACHE TOMCAT

Publié dans : Sciences
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
18 928
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
169
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

APACHE TOMCAT

  1. 1. 03/04/2014 1 APACHE TOMCAT Rachid NID SAID rachid.nidsaid@gmail.com
  2. 2. 03/04/2014 2 Plan  Déploiement d’application  Cluster  Instances Multiples  APR  JMX Monitoring  Introduction  Installation  Configuration  Class Loader  Journalisation  Sécurité
  3. 3. Introduction Moteur JSP/Servlet  Servlet est une classe Java qui permet de générer dynamiquement du contenu (HTML, XML, TEXT, …) au sein d'un serveur HTTP dit conteneur de servlets.  Les servlets utilisent l'API Java Servlet (javax.servlet).  L’API Servlet fournit un mécanisme pour communiquer avec le serveur et de réagir aux requêtes HTTP.  JavaServer Pages ou JSP est une technologie Java qui permet de créer dynamiquement du contenu web en ajoutant de la logique dynamique (tags JSP, scriplet JAVA) au sein d’un contenu statique.  Lors de la 1er utilisation de la page JSP, elle transformé en servlet.  Un conteneur de servlet est une plateforme qui fournit un environnement JAVA pour gérer le cycle de vie d’une servlet
  4. 4. Introduction Moteur JSP/Servlet
  5. 5. Introduction Historique  Apache TOMCAT est le conteneur de servlet fourni par la communauté open source Apache Foundation Software.  TOMCAT est le produit de la fusion du projet Java Web Server de Sun et du projet JServ de la communauté Apache.  La 1er version produite est la version 3, en 1999.  En 2001, la version 4 est sorti sous le nom de code Catalina et qui représentait une refonte total du produit.  Catalina : Le noyau de TOMCAT, Servlet API, Administration, Sécurité, …  Coyote : Le connecteur HTTP qui permet à TOMCAT de servir comme serveur HTTP  Jasper : Le compilateur qui traduit la JSP en Servlet
  6. 6. Introduction Versions  Versions en cours :  6.0.x : en mode maintenance, pas de nouveaux développement  7.0.x : version actuelle  8.0.x : la nouvelle version en cours de développement  Disponible sur le site http://tomcat.apache.org/
  7. 7. Introduction Versions Version Tomcat Version Servlet Version JSP Version Java 6.0 2.5 2.1 1.5 7.0 3.0 2.2 1.6 8.0 3.1 2.3 1.7
  8. 8. Installation  Apache TOMCAT peut être téléchargé à partir d’un des liens suivants :  http://tomcat.apache.org/download-60.cgi  http://tomcat.apache.org/download-70.cgi  http://tomcat.apache.org/download-80.cgi La version 7.0 sera notre version de référence pour le reste des slides.
  9. 9. Installation  Le site propose plusieurs types de ressources :  Core :  Des archives zip ou tar, décompressés fournissent un dossier qui constitue le serveur TOMCAT  Des exécutables d’installation pour la plateforme Windows  Deployer : Module ANT pour automatiser le déploiement d’application  Embedded : Ensemble de composants nécessaire pour créer des application WEB avec un TOMCAT Embedded
  10. 10. Installation Pré requis  TOMCAT est une application JAVA et nécessite donc la disponibilité d’un JDK dans la machine cible.  TOMCAT nécessite la disponibilité non pas d’un simple JRE, mais de l’ensemble du JDK. Il a besoin du compilateur javac pour compiler les servlets résultantes des JSP.  La version 7.0 nécessite un JDK 1.6 et supérieure  La variable d’environnement JAVA_HOME doit pointer sur le dossier racine du JDK  La valeur JAVA_HOME/bin doit exister au niveau de la variable d’environnement PATH
  11. 11. Installation Windows  En utilisant l’archive téléchargé  Déployer l’archive dans un dossier cible  Ajouter la variable d’environnement CATALINA_HOME qui pointe sur le dossier d’installation de TOMCAT  Utiliser l’exécutable d’installation  Plus simple  Se charge de la configuration des variables d’environnement  Installe TOMCAT en tant que service Windows
  12. 12. Installation Unix Like  Déployer l’archive téléchargé dans un dossier cible  Ajouter la variable d’environnement CATALINA_HOME qui pointe sur le dossier d’installation de TOMCAT  Pour éviter des problèmes de stabilité sur les plateformes linux :  Linux kernel 2.4 et GLIBC 2.2 : définir la variable d’environnement LD_ASSUME_KERNEL=2.2.5  Redhat Linux 9.0 : définir la variable d’environnement LD_ASSUME_KERNEL=2.4.1 uname -r : identifier la version du kernel linux /lib/libc.so.6 : identifier la version du GLIBC
  13. 13. Installation Unix Like  La plupart des distributions Linux modernes offre un package tomcat prêt pour installation :  Debian et Ubuntu :  Installation : apt-get install tomcat7  CentOS, Fedora, Red Hat :  Installation : yum install tomcat7
  14. 14. Installation Démarrage  Le démarrage de TOMCAT :  Windows : %CATALINA_HOME%/bin/startup.bat  Linux : $CATALINA_HOME/bin/startup.sh
  15. 15. Installation Structure  conf : Fichiers de configuration  catalina.policy : les paramètres de sécurité JAVA appliqués en remplacement du paramétrage java.policy  catalina.properties : Définition des différents classLoader  context.xml : indique l’emplacement par défaut du fichier web.xml au niveau des application WEB  logging.properties : configuration par défaut de la journalisation TOMCAT  server.xml : Fichier de configuration principale de TOMCAT  tomcat-users.xml : fichiers de configuration des droits d’accés aux applications d’administration  web.xml : web.xml par défaut utilisé par toutes les applications déployés  Identifie la servlet pour récupérer les documents statiques  Identifie la servlet responsable de la transformation de la JSP en servlet  Identifie le timeout session  Installe les mime types pour les extensions standards
  16. 16. Installation Structure  bin : scripts et exécutables pour différentes tâches : démarrage, arrêt, etc.  lib : l’ensemble des jars utilisés  logs : journaux  temp : répertoire utilisé pour des fichiers temporaires, fichier de crash, fichier en cours d’upload, …  work : répertoire utilisé lors de transformation des JSP en servlet  webapps : répertoire de déploiement des applications WEB
  17. 17. Installation Structure  Le répertoire webapps par défaut contient les applications suivantes :  ROOT : application par défaut  docs : documentation tomcat  examples : des exemples de JSP et de servlet  host-manager : application qui permet de gérer le serveur hôte. Accessible à partir de l’url /host- manager/html  manager : application qui permet de gérer le cycle de vie des applications WEB déployés au sein du serveur. Accessible à partir de l’url /manager/html
  18. 18. Configuration Concepts
  19. 19. Configuration Concepts  Server : encapsule le conteneur web. Il ne peut s'exécuter qu'un seul Server dans une JVM  Connector : gère et intercepte les communications avec le client.  http Connector : responsable de gérer les appels HTTP  AJP Connector : plus performant que le connecteur HTTP et permet de faire communiquer TOMCAT avec un serveur Apache HTTP dans une architecture reverse proxy.  Engine : composant responsable de traiter les requêtes HTTP, il examine l’entête HTTP de la requête pour identifier le hôte virtuel et le tomcat (application) responsable de traiter la requête.
  20. 20. Configuration Concepts  Service : composant logique qui associe un connecteur ou plus avec l’Engine responsable de traiter les requêtes reçues.  Host : concept qui ressemble à son équivalent hôte virtuel coté apache, permet de configurer plusieurs nom de domaine dans une même machine.  Context : représente l’application WEB déployé et permet l'association de cette application à une url.
  21. 21. Configuration Concepts  Valve : Composant capable d’implémenter un traitement qui est exécuté avant la prise en compte de la requête par l’Engine responsable.  org.apache.catalina.valves.ValveBase  Realm : Une source de données qui fournit une liste d’utilisateurs et leurs rôles associés. Permet de définir les droits d’accès pour les applications WEB
  22. 22. Configuration Server.xml  Le fichier Server.xml représente le point central pour la configuration du serveur TOMCAT  Le fichier ou est configuré l’ensemble des composants TOMCAT  Server, Service, Connector, Host, Engine, …  Server.xml, comme son nom l’indique est un fichier XML, et comme tout document XML il a une balise racine, <Server>, elle représente le serveur.  port : port TCP sur lequel écoute TOMCAT pour la commande d’arrêt.  shutdown : chaîne texte qui représente la commande d’arrêt
  23. 23. Configuration Server.xml : <Server>
  24. 24. Configuration Server.xml : <Server>  <Listener> : Listener pour intercepter les événements du cycle de vie du serveur (démarrage, arrêt, avant démarrage, avant arrêt, …)  className : nom de la classe du listener et qui doit implémenté l’interface org.apache.catalina.LifecycleListener  <GlobalNamingResources> : ressources JNDI accessible de façon global au niveau du serveur
  25. 25. Configuration Server.xml : <Service>  <Service> : regroupe un ou plusieurs connecteurs et un Engine responsable de traiter les requêtes interceptés par ces connecteurs  <Connector> : un ou plusieurs, responsable de l’interception de requêtes HTTP.  <Engine> : composant responsable du traitement des requêtes interceptés par les connecteurs du même service.
  26. 26. Configuration Server.xml : <Connector>  port : port TCP sur lequel écoute le connecteur, c’est le port associé à l’hôte définie au sein du service et c’est lui qui devra être ciblé par les requêtes clientes  Protocol : type du connecteur, 2 valeurs possibles  HTTP/1.1 : à utiliser si le connecteur est ciblé par des requêtes HTTP et que TOMCAT joue le rôle d’un serveur HTTP  AJP/1.3 : à utiliser TOMCAT joue le rôle d’un serveur d’application dernier une passerelle HTTP  maxThreads : nombre max de threads crées simultanément pour traiter les requêtes reçus, identifie le nombre de requêtes traités en parallèles.  200 si vide  connectionTimeOut : temps d’attente de la requête pour être traité  redirectPort : le port sur lequel doit être redirigé les requêtes avec SSL si le connecteur ne supporte pas SSL
  27. 27. Configuration Server.xml : <Engine>  defaultHost : hôte par défaut, utilisé si plusieurs hôtes sont déclarés et que le hôte cible de la requête traité n’est pas identifié  <Host> : un ou plusieurs, identifie un hôte virtuel  <Context> : ensemble de paramétrage pour configurer une application WEB  <Realm> : configure les droits d’accès au niveau de l’Engine  <Valve> : logique de pré traitement de la requête reçu avant son interception par l’application cible  <Listener> : Listener pour intercepter les événements de cycle de vie de l’Engine (démarrage et arrêt)
  28. 28. Configuration Server.xml : <Host>  name : le nom utilisé par le hôte virtuel  Doit être disponible au niveau du DNS et qui doit pointer sur l’adresse IP de la machine.  appBase : répertoire contenant les applications à déployé, part défaut c’est CATALINA_HOME/webapp  Si le chemin commence par un « / », il pointe sur un chemin absolu, sinon il pointe sur un sous répertoire du CATALIBA_HOME  autoDeploy : si Oui, les applications disponible dans le répertoire appBase seront déployé automatiquement et si le source d’une application est changé elle sera redéployé
  29. 29. Configuration Server.xml : <Host>  deployOnStartup : si Oui, les applications disponible dans le répertoire appBase seront déployé automatiquement au démarrage.  deployXML : si Oui, le processus de déploiement se basera sur le fichier /META-INF/context.xml au sein de l’application pour configurer le tomcat de l’application, si Non une balise <context> devra être ajouté directement dans le fichier Server.xml  unpackWARs : si Non, l’application sera déployé sans désarchiver le ficher WAR, par défaut c’est Oui  workdir : répertoire temporaire pour transformer les JSP en Servlet, par défaut c’est CATALINA_HOME/workdir
  30. 30. Configuration Server.xml : <Host>  <Alias> : permet d’associer ce hôte à d’autres nom au sein du DNS, autre que le nom de l’hôte  <Context> : un ou plusieurs, ensemble de paramétrages pour configurer une application WEB  <DefaultContext> : ensemble de paramétrage utilisé par défaut par les applications n’ayant pas de tomcat propre identifié  <Realm> : configure les droits d’accès au niveau de l’Hôte
  31. 31. Configuration Server.xml : <Context>  docBase : le répertoire ou sont stockés les fichiers de l’application  Si l’application est déployé avec un WAR, le répértoire est webapps/nom_fichier_war  path : le chemin de tomcat à utiliser dans l’URL pour invoquer à l’application  Utiliser chaîne vide pour que ce soit l’application par défaut du hôte, « / » sera le tomcat de l’application  Par défaut c’est le non fourni par docBase
  32. 32. Configuration Server.xml : <Context>  cookies : si Oui, utiliser les cookies pour gérer la session, par défaut c’est oui  useNaming : indique que l’application effectue des accès à des ressources JNDI  crossContext : si Oui, permet d’accéder à des informations dans d’autres tomcats du même hôte, par défaut c’est Non  override : si Oui, indique que la configuration proposé par le fichier META-INF/context.xml de l’application écrase celle définie au niveau du fichier server.xml
  33. 33. Configuration Server.xml : <Context>  caseSensitive : indique si la prise de la case est active, par défaut c’est Oui  reloadable : si Oui, indique que si un fichier de l’application change, redéployer l’application automatiquement, permet d’écraser le paramétre autoDeploy du hôte  unpackWAR : si Non, l’application sera déployé sans désarchiver le ficher WAR, par défaut c’est Oui
  34. 34. Configuration Server.xml : <Context>  cachingAllowed : si Oui, avtive la mise en cache des ressources statiques  cacheMaxSize : taille maximum en KO du cache, par défaut 10240.  cacheTTL : temps de latence d’un objet dans le cache, par défaut 5000 ms
  35. 35. Configuration Server.xml : <Context>  <Loader> : Configuration du classLoader à utiliser pour les classes de l’application  <Manager> : gestionnaire de session à utiliser  Ne pas changer sauf en cas de mise en place de session persistante (application transactionnel, cluster, …)  <Realm> : gestion d’accés au niveau de l’application  <Resources> : le gestionnaire de resource à utiliser pour les ressources JNDI  org.apache.naming.resources.FileDirContext  <WatchedResource> : redéployer l’application si une des ressources spécifiés change
  36. 36. Configuration Context.xml  Le fichier Context.xml permet de fournir un paramétrage par défaut pour l’ensemble des applications déployés au sein de TOMCAT  La balise racine est <Context>
  37. 37. Configuration web.xml  Le fichier web.xml permet de configurer des paramètres par défaut pour l’ensemble des applications déployés dans TOMCAT  Comme tout fichier de déploiement web.xml, la balise racine est <web-app>
  38. 38. Configuration web.xml : Servlet par défaut  Configurer la Servlet par défaut responsable de gérer les ressources statiques au sein des applications déployés
  39. 39. Configuration web.xml : Servlet par défaut  listings : indique si le contenu du dossier est affiché si l’url se termine par « / », par défaut c’est Non  readonly : indique si les méthodes post et put sont permis pour accéder à des sources statiques, par défaut c’est Oui  sendfileSize : permet de gérer la taille du tampon avant appel d’un sendFile() lors du traitement d’un contenu volumineux, par défaut c’est 48ko
  40. 40. Configuration web.xml : Configurer JSPServlet  La JSPServlet est le composant responsable d’intercepter les requêtes .jsp et de les traiter.  Elle prend en charge la conversion des jsp en servlet et leurs compilation
  41. 41. Configuration web.xml : Configurer JSPServlet  developement : indique à Jasper de surveiller les jsp et si une modification est détecté de la recompilé, par défaut Oui  checkInterval : intervalle de vérification du changement des JSP, par défaut 0  modificatioTestInterval : indique le délai de latence après une recompilation pour revérifier la JSP, 4s par défaut
  42. 42. Configuration web.xml : Configurer JSPServlet  fork : indique d’utiliser une autre JVM pour compiler la JSP autre que la JVM par défaut. Oui par défaut  compilerTargetVM : version java cible de la compilation, par défaut garde la version de la JVM TOMCAT  compilerSourceVM : version java à utilisé pour générer le code source de la Servlet généré, par défaut garde la version de la JVM TOMCAT
  43. 43. Configuration web.xml : Session Timeout  Spécifier la durée d’inactivité d’une session HTTP, après laquelle la session est désactivé.  La valeur est en minute
  44. 44. Configuration web.xml : Les fichiers d’accueil  Liste des fichiers d’accueil que la Servlet par défaut essaie d’afficher si elle reçoit une requête qui se termine par un /  Cette liste peut être surchargé par le web.xml de l’application déployé
  45. 45. ClassLoader  TOMCAT utilise plusieurs ClassLoader pour charger les classes utilisés au sein de la JVM  Chaque ClassLoader (java.lang.classLoader) est responsable du chargement des classe et des ressources d’un contenu spécifique  Ce mécanisme permet aux applications, déployés au sein de TOMCAT, de pouvoir utiliser l’ensemble des classes fournies.
  46. 46. ClassLoader  Comme dans toute application JAVA, les classLoader au sein de TOMCAT sont organisés en arbre  Ce mécanisme permet de réaliser une isolation entre les class path des différents application
  47. 47. ClassLoader  Bootstrap : contient les classes de base de la JDK.  System : contient les classes qui gére le cycle de vie du serveur TOMCAT  $CATALINA_HOME/bin/bootstrap.jar  $CATALINA_HOME/bin/tomcat-juli.jar  $CATALINA_HOME/bin/commons-daemon.jar  Common : contient les autres classes fournies par TOMCAT  $CATALINA_HOME/lib  WebappX : un ClassLoader est crée pour chaque application web déployé au sein de TOMCAT  /WEB-INF/classes  /WEB-INF/lib
  48. 48. ClassLoader Endorsed Standards Override Mechanism  Endorsed Standards Override Mechanism est un mécanisme JAVA qui permet aux applications de fournir une implémentation de certaines API JAVA autre que l’implémentation fourni par le JDK.  org.xml.sax  org.xml.sax.ext  org.xml.sax.helpers  TOMCAT permet d’implémenter ce mécanisme par le biais du paramètre -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS au niveau de la commande de démarrage.  $JAVA_ENDORSED_DIRS : par défaut est $CATALINA_HOME/endorsed
  49. 49. ClassLoader catalina.policy  Fichier utilisé par le gestionnaire de sécurité JAVA pour identifier les permissions autorisés pour les accès aux ressources systèmes par TOMCAT  respecte le format JAVA pour spécifier les permissions  n’est utilisé que si TOMCAT est démarré en mode sécurisé. $CATALINA_HOME/bin/startup.sh –security  Remplace complètement le fichier standard JAVA java.policy présent dans le JDK  Il peut être édité manuellement ou via l’outil policytool offert par le JDK
  50. 50. ClassLoader catalina.policy  La tentative d’exécution par TOMCAT d’une opération non autorisé par le gestionnaire de sécurité JAVA, déclenche une violation qui peut générer deux types d’exceptions  java.security.AccessControLException  java.security.SecurityException  Le débogage de ce type de problème peut parfois être assez complexe, TOMCAT offre la possibilité de générer des informations de débogage supplémentaires lors de la violation  export CATALINA_OPTS=-Djava.security.debug=all (Unix)  set CATALINA_OPTS=-Djava.security.debug=all (Windows)
  51. 51. JNDI Ressources  JNDI pour Java Naming and Directory Interface  JNDI est une interface Java unique pour accéder à des services distribués et des données en leurs associant un nom unique, et définit une API standard pour permettre l'accès à ces services.  Il existe plusieurs types de services de nommage parmi lesquels :  DNS (Domain Name System)  LDAP(Lightweight Directory Access Protocol)  NIS (Network Information System)  COS Naming (Common Object Services)  Etc …
  52. 52. JNDI Ressources  TOMCAT fournit une prise en charge du JNDI compatible JEE  TOMCAT fournit une instance du JNDI InitialContext pour chaque application web déployé, et permet de définir et d’exploiter des ressource JNDI en utilisant les balises standard JEE au niveau des fichier web.xml, context.xml et server.xml.
  53. 53. JNDI Ressources Configuration  L’identification et la configuration d’une ressource JNDI se fait au sein de la balise <Context> dans l’un des fichiers suivants :  server.xml : au sein d’une balise <Context>  context.xml : propre à chaque application déployé.  <Environment> : permet de configurer des variables d’environnement dont la valeur peut être exploité par l’application WEB grâce au JNDI Context.  <Resource> : permet de configurer une ressource JNDI
  54. 54. JNDI Ressources Configuration : <Environnement>  name : nom de la variable  description : description textuelle de la variable  override : booléen, indique si cette variable peut être redéfinie au sein du fichier web.xml via la balise <env-entry>  type : classe java qui représente le type de variable  value : la valeur de la variable <Environment name="simpleValue" type="java.lang.Integer" value="30"/> Context initCtx = new InitialContext(); Context ctx = (Context) initCtx.lookup("java:/comp/env"); Integer o = (Integer) ctx.lookup("simpleValue");
  55. 55. JNDI Ressources Configuration : <Resource>  auth : application / container, indique qui est responsable de la gestion du cycle de vie de la ressource.  type : classe java qui représente le type de la ressource  singleton : booléen, indique si TOMCAT gère la ressource en tant que singleton  closeMethod : méthode à utiliser par TOMCAT pour libérer la ressource quand elle n’est plus utilisé.  Ce paramètre est ignoré si singleton est true.  description : description textuelle de la ressource  name : nom de la ressource  scope : Shareable / Unshareable, indique si les connections obtenues via la ressource peuvent être partagé
  56. 56. JNDI Ressources Configuration : <Resource>  La balise <Resource> peut accepter d’autres attributs que les attributs déjà vu, ils seront utilisé par le JNDI Context lors de la création de la ressource <Resource name="jdbc/TestDataSource" auth="Container" type="javax.sql.DataSource" driverClassName="com.mysql.jdbc.Driver" maxActive="100" maxIdle="30" maxWait="10000" url="jdbc:mysql://localhost:3306/test_db" username="root" password="root" />
  57. 57. JNDI Ressources Ressource Global  La balise <GlobalNamingResources> permet d’identifier des ressources JNDI globaux et qui sont accessibles par l’ensemble des applications déployés au sein du serveur  La balise <GlobalNamingResources> englobe des balises <Resource> et <Environnement> comme sous éléments qui configurent des ressources JNDI  Les ressource configurés de façon globales sont réutilisés au sein d’une application par l’utilisation de la balise <ResourceLink> au sein du tomcat de l’application.
  58. 58. JNDI Ressources Ressource Global : <ResourceLink>  name : nom de la ressource à utilisé par l’application pour accéder à la ressource  type : classe java qui représente le type de la ressource  global : nom de la ressource globale identifié <GlobalNamingResources> <Environment name="serverType" type="java.lang.String" value="DEV"/> </GlobalNamingResources> <Context> <ResourceLink name="serverType" global="serverType" type="java.lang.String"/> </Context>
  59. 59. JNDI Ressources Utilisation  L’utilisation d’une ressource JNDI au sein d’une application nécessite l’identification de la ressource au sein du web.xml  <env-entry> : permet de référencer une variable d’environnement <Environnement>. <env-entry> <env-entry-name>MaxValue<env-entry-name> <env-entry-type>java.lang.Float</env-entry-type> <env-entry-value>45.4</env-entry-value> </env-entry>  <resource-ref> et <resource-env-ref> : permet de référencer une ressource JNDI.
  60. 60. JNDI Ressources Utilisation
  61. 61. JNDI Ressources Resource Factory  Lors de la récupération de la ressource, le JNDI Context a besoin de savoir comment initialiser cette ressource.  L’interface javax.naming.spi.ObjectFactory fournit par JAVA permet de concevoir des fabriques que le JNDI Context va utiliser lors de l’opération de récupération.  Fournit la méthode getObjectInstance() qui est appelé lors de l’initialisation de la ressource  Object obj : objet of type javax.naming.Reference, contient les informations de configuration de la ressource  Name name : nom de la factory.  Context nameCtx : Context JNDI en cours  Hashtable environment : généralement ignoré par TOMCAT.
  62. 62. JNDI Ressources Resource Factory
  63. 63. JNDI Ressources JDBC Datasources <Context> ... <Resource name="jdbc/EmployeeDB" auth="Container" type="javax.sql.DataSource" username="dbusername" password="dbpassword" driverClassName="org.hsql.jdbcDriver" url="jdbc:HypersonicSQL:database" maxActive="8" maxIdle="4" defaultAutoCommit ="false" defaultTransactionIsolation = "READ_COMMITTED" initialSize="5" /> ... </Context> <resource-ref> <res-ref-name> jdbc/EmployeeDB </res-ref-name> <res-type> javax.sql.DataSource </res-type> <res-auth> Container </res-auth> </resource-ref>
  64. 64. JNDI Ressources JAVA Mail Sessions
  65. 65. Journalisation  La journalisation au sein de TOMCAT est implémenté grâce à l’API Apache Commons Logging.  Cette API permet à TOMCAT d’être indépendant du framework de journalisation utilisé et de pouvoir utilisé n’importe lequel du marché  Chaque application déployé au sein de TOMCAT peut utilisé son propre framework de journalisation indépendamment de ce que utilise TOMCAT  Sauf pour le framework utilisé par TOMCAT.
  66. 66. Journalisation logging.properties  Le fichier logging.properties est organisé en deux sections 1. Les gestionnaires (handlers) : ils permettent de spécifier la configuration du journal, destination, niveau de détail, chemin du fichier journal, …  vers un fichier : org.apache.juli.FileHandler  Vers la console : java.util.logging.ConsoleHandler 2. Les loggers : ils identifient le contenu à journaliser et le niveau de détail du journal pour ce contenu
  67. 67. Journalisation logging.properties  La propriété handlers identifie tous les gestionnaires de journaux utilisés.  La propriété .handlers identifie le gestionnaire principale du serveur  Le nom du handler est constitué de deux parties 1. un préfixe construit à partir d’un chiffre et d’un nom, exemple : 1catalina 2. le nom de la classe du gestionnaire 1catalina.org.apache.juli.FileHandler.level = FINE 1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 1catalina.org.apache.juli.FileHandler.prefix = catalina.
  68. 68. Journalisation logging.properties  level : niveau de journalisation.  SEVERE, CONFIG, INFO, WARN, FINE, FINEST, ALL  formatter : classe java pour formater le contenu du fichier.  java.util.logging.SimpleFormater (par défaut)  java.util.logging.XmlFormater pour générer sortie format XML  Les attributs spécifiques à org.apache.juli.FileHandler sont :  prefix : spécifie le préfixe du fichier. La valeur par défaut est ’juli.’  suffix : spécifie le suffixe du fichier. La valeur par défaut est ’.log’  directory : spécifie répertoire dans lequel sera créé le fichier. Par défaut TOMCAT_HOMEbinlogs
  69. 69. Journalisation logging.properties  Pour spécifier le contenu d’un journal il faut respecter l’une des syntaxes suivantes  org.apache.catalina.core.ContainerBase.[engine]  org.apache.catalina.core.ContainerBase.[engine].[host]  org.apache.catalina.core.ContainerBase.[engine].[host].[context] org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handl ers = 3manager.org.apache.juli.FileHandler  Il est aussi possible de spécifier le nom d’une classe comme contenu d’un journal  la rotation des fichiers journaux s’effectue toutes les nuits à minuit
  70. 70. Journalisation Journalisation des accès  En tant que serveur HTTP TOMCAT fournit un autre mécanisme pour suivre les statistiques des accés aux ressources publiés que ce soit des ressources statiques ou dynamiques (JSP)  La valve AccessLog crée des fichiers journaux dans le même format que ceux créés par les serveurs Web standard. Ces journaux peuvent ensuite être analysés par des outils d'analyse de log pour suivre les statistiques d’accés, l'activité de la session de l'utilisateur, et ainsi de suite.  La valve AccessLog peut être associé à n'importe quel conteneur TOMCAT (tomcat, hôte, Engine), et enregistre toutes les demandes traitées par ce conteneur
  71. 71. Journalisation Journalisation des accès <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log. " suffix=".log" pattern="%h %l %u %t &quot;%r&quot; %s %b" />  Si la valve AccessLog est utilisé à des endroits différents, il faut faire attention à utiliser des fichiers de journal différents
  72. 72. Journalisation en Production  Ne pas utiliser de ConsoleHandler.  Nettoyer le propriété .handlers et ne garder que le FileHandler  Supprimer les handlers et les journaux des applications non utilisés  Faite attention lors de l’utilisation de la valve Access log.  Configurer les journaux vers un disque autre que celui de TOMCAT
  73. 73. Journalisation Atelier  Configurer des journaux pour les hosts crées dans l’atelier 1  Configurer un journal pour l’application « example »  Configurer un journal d’accès pour l’application «example »  Configurer un journal d’accès pour le 2éme hôte
  74. 74. Sécurité  TOMCAT offre un mécanisme de gestion d’authentification et de contrôle d’accès, ce mécanisme offre les garanties suivantes :  Authentification : garantir que l’utilisateur connecté est bien celui qu’il prétend.  Autorisation : définir pour chaque utilisateur le périmètre auquel il peut accéder.  Protection des données : garantir que les données en circulation ne sont pas altérés par une tierce partie.
  75. 75. Sécurité Authentification  L’authentification au sein de TOMCAT et comme dans beaucoup de moteur de Servlet, peut être implémenté de deux façons  HTTP basic authentication : c’est le navigateur WEB qui se charge de réclamer le nom d’utilisateur et le mot de passe à l’utilisateur et puis de les envoyer au serveur pour être validé.  Form-based authentication : c’est l’application qui fournit un formulaire web pour réclamer le nom d’utilisateur et le mot de passe  Il est important de noter qu’en mode HTTP basic authentication le mot de passe et le nom d’utilisateur est envoyé crypté alors qu’en mode Form-based authentication ils sont envoyés en clair et dans ce cas il est necessaire de passer par du SSL
  76. 76. Sécurité Identification des utilisateurs : <Realm>  Un <Realm> est un dispositif servant à identifier des utilisateurs et leurs rôles.  Il permet de faire l'association login/mot de passe de l’utilisateur  le <Realm> identifie la liste des rôles associés à chaque utilisateur. Les rôles sont les responsabilités attribuées à un utilisateur donné.  La protection des ressources se fait par rôle, c'est-à- dire que l'on indique le rôle dont doit disposer un utilisateur pour accéder à la ressource.
  77. 77. Sécurité Identification des utilisateurs : <Realm>  Un <Realm> peut exploiter des données stockées sous différentes formes :  annuaire LDAP accessible via JNDI,  fichier XML (par exemple le fichier tomcat- users.xml qui sert à configurer l'accès aux applications admin et manager de Tomcat)  une DataSource JNDI  …  L'interface org.apache.catalina.Realm permet d’implémenter un <Realm> propriétaire
  78. 78. Sécurité Identification des utilisateurs : <Realm>  Un <Realm> peut se déclarer en plusieurs niveaux  Engine : partagé par toutes les applications de tous les hôtes virtuels  Host : (partagé par toutes les applications de l'hôte virtuel)  Context : valable pour l'application dans lequel il est défini.  Un <Realm> défini à un niveau donné masque ceux de niveau supérieur.
  79. 79. Sécurité Identification des utilisateurs : <Realm>  JDBCRealm : permet d’accéder à des informations utilisateurs stockés au niveau d’une BD via JDBC <Realm className="org.apache.catalina.realm.JDBCRealm" driverName="org.gjt.mm.mysql.Driver" connectionURL="jdbc:mysql://localhost/authority?us er=dbuser&amp;password=dbpass" userTable="users" userNameCol="user_name" userCredCol="user_pass" userRoleTable="user_roles" roleNameCol="role_name"/>
  80. 80. Sécurité Identification des utilisateurs : <Realm>  DataSourceRealm : permet d’accéder à des informations utilisateurs stockés au niveau d’une BD via une datasource JNDI <Realm className="org.apache.catalina.realm.DataSourceR ealm" dataSourceName="jdbc/authority" userTable="users" userNameCol="user_name" userCredCol="user_pass" userRoleTable="user_roles" roleNameCol="role_name"/>
  81. 81. Sécurité Identification des utilisateurs : <Realm>  UserDatabaseRealm : permet d’accéder à des informations utilisateurs stockés au niveau d’une ressource JNDI UserDatabase. <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" factory="org.apache.catalina.users.MemoryUserDatabaseFactory « pathname="conf/tomcat-users.xml" /> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
  82. 82. Sécurité Identification des utilisateurs : <Realm>  JNDIRealm : permet d’accéder à des informations utilisateurs stockés au niveau d’un annuaire LDAP via une ressource JNDI. <Realm className="org.apache.catalina.realm.JNDIRealm" connectionName="cn=Manager,dc=mycompany,dc=com" connectionPassword="secret" connectionURL="ldap://localhost:389" userPassword="userPassword" userPattern="uid={0},ou=people,dc=mycompany,dc=co m" roleBase="ou=groups,dc=mycompany,dc=com" roleName="cn" roleSearch="(uniqueMember={0})" />
  83. 83. Sécurité Identification des utilisateurs : <Realm>  JAASRealm : permet d’accéder à des informations utilisateurs via le framework Java Authentication & Authorization Service (JAAS) <Realm className="org.apache.catalina.realm.JAASRealm" appName="MyFooRealm" userClassNames="org.foobar.realm.FooUser" roleClassNames="org.foobar.realm.FooRole"/>
  84. 84. Sécurité Identification des utilisateurs : <Realm>  LockOutRealm : permet de mettre en place un mécanisme de protection contre les tentatives brute-force attack pour accéder au systéme de façon illégale, il est utilisé en combinaison avec d’autres Realm <Realm className="org.apache.catalina.realm.LockOutRealm" failureCount="3" lockOutTime="300" > <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> </Realm>
  85. 85. Sécurité Identification des utilisateurs : <Realm>  CombinedRealm : permet de combiner plusieurs sources d’utilisateurs en un seul Realm <Realm className="org.apache.catalina.realm.CombinedRealm" > <Realm className="org.apache.catalina.realm.UserDatabaseRealm " resourceName="UserDatabase"/> <Realm className="org.apache.catalina.realm.DataSourceRealm" dataSourceName="jdbc/authority" userTable="users" userNameCol="user_name" userCredCol="user_pass" userRoleTable="user_roles" roleNameCol="role_name"/> </Realm>
  86. 86. Sécurité Mode d’Authentification  La balise <Login-config> au niveau du web.xml, permet de spécifier le mode d’authentification de l’application  <auth-methode> : None / Basic / Form /DIGEST / CLIENT-CERT, identifie le mode d’authentification de l’utilisateur  <realm_name> : le Message d’invite utilisé par l’application.
  87. 87. Sécurité Mise en place du formulaire d’authentification  Créer un formulaire HTML  Le champ correspondant au login doit s'appeler j_username;  Le champ du mot de passe doit s'appeler j_password;  L'action du formulaire doit être j_security_check.  Créer une page d’erreur pour répondre au cas ou l’authentification ne s’est pas bien passé
  88. 88. Sécurité Autorisation  Les autorisations sont définies pour une application au sein du fichier web.xml par la balise <security- constraint>.  <security-constraint> : permet de définir des droits d’accés sur un ensemble de ressource en utilisant le principe du mapping d’URL :  <web-resource-collection> : liste de pattern d’URL qui identifinet les ressources à protéger  <auth-constraint> : identifie qui a droit d’accès à ces ressource via le sous élément <role-name>.  <user-data-constraint> : spécifie si les données sont cryptés lors du transfert des données entre le serveur et le client
  89. 89. Sécurité Autorisation  <web-resource-collection> contient les sous éléments suivant :  <web-resource-name> : (optionel) un nom.  <url-pattern> : le pattern URL des ressources à protéger.  <http-method> : (optionnel) spécifie quelle méthode HTTP est protégé.  <auth-constraint> : contient le sous élément suivant :  <role-name> : (plusieurs) rôle qui a accès à la ressource.
  90. 90. Sécurité Autorisation
  91. 91. Sécurité Single Sign On  TOMCAT offre un mécanisme qui permet à plusieurs applications d’un Host de partager l’authentification <Host name="localhost" ...> ... <Valve className="org.apache.catalina.authenticator.SingleSignOn"/> ... </Host>  L’utilisation de ce mécanisme nécessite quelques règles :  Les applications partagent le même Realm  Si une des application ne nécessite pas d’authentification, l’utilisateur n’accède qu’aux ressources non protégés des autres applications  Single Sign On utilise les cookies pour partager les informations d’authentifications entre les applications.
  92. 92. Sécurité SSL  La balise <Connector> est la responsable de l’activation et de la prise en charge du SSL au niveau de TOMCAT  SSLEnabled : true, active la prise en compte du SSL  Secure : true, active la prise en compte du HTTPS  sslProtocole : indique le protocole SSL à utilisé  keystoreFile : indique l’emplacement du fichier de certificats  Keystoretype : indqiue le type de clés contenues dans le fichier de certificats  keystorePass : le mot de passe nécessaire à TOMCAT pour pouvoir lire le fichier de certificat  clientAuth : indqiue si le serveur authentifie le client grace à un certificat client hébergé par le client
  93. 93. Sécurité SSL  La balise <user-data-constraint> au niveau du web.xml permet d’indiquer que les donnés transférés par cette application doivent être cryptés
  94. 94. Sécurité Atelier  Activer la sécurité au niveau d l’application « example » en utilisant le Realm UserDataSource  Ne permettre l’accés à «/examples/servlets/ » qu’au nouveau rôle « servlet »  Activer le SSO au niveau de votre Host
  95. 95. Déploiement d’application Application standard  TOMCAT propose plusieurs façons pour déployer des applications. En plus du déploiement lors du démarrage, il propose plusieurs possibilités de déploiement à chaud.  Le déploiement à chaud permet d’ajouter des applications, de les mettre à jour ou de les retirer sans avoir besoin d’effectuer un redémarrage de TOMCAT.
  96. 96. Déploiement d’application Application standard : déploiement au démarrage  Au démarrage TOMCAT effectue le déploiement de l’ensemble des application disponible dans le dossier appBase de chaque Host définie.  Il suffit de déposer l’application dans le dossier appBase du Host cible, que ce soit sous la forme d’un fichier war ou bien d’un dossier  La structure de l’application doit respecter le standard JAVA WEB  Le déploiement se fait dans l’ordre suivant : 1. Les applications configurés par un Context que ce soit dans le fichier server.xml ou un fichier context.xml 2. Les dossiers décompressés au sein du dossier appBase. 3. Les war contenues dans le dossier appBase, même les war associés à une application décompressé. Ça permet d’effectuer une mise à jour d’une application déjà déployé
  97. 97. Déploiement d’application Application standard : déploiement à chaud  Pour éviter d’être obligé de redémarrer le serveur à chaque qu’on veut déployer une nouvelle application ou la mettre à jour TOMCAT propose plusieurs mécanisme pour déclencher le redéploiement d’une application  Le flag autoDeploy au niveau du Host,  L’application Tomcat Manager  L’utilitaire ant, Tomcat Client Deployer.
  98. 98. Déploiement d’application Application standard : déploiement à chaud  Le flag autoDeploy au niveau du Host s’il est positionné à true, permet de déclencher un déploiement à chaud des applications qui sont dans le scope du Host  Il suffit de déposer un nouveau war dans le dossier appBase pour déclencher le déploiement de la nouvelle application  Il suffit de déposer une nouvelle version du war de l’application pour en déclencher le redéploiement  Supprimer le dossier correspondant à l’application dans le appBase suffit à la désinstaller  Utiliser la balise WatchedResource au niveau du Context pour identifier les fichiers qui peuvent déclencher un redéploiement de l’application même si un nouveau war n’est pas fournie (par défaut web.xml)
  99. 99. Déploiement d’application Application standard : déploiement à chaud  TOMCAT Manager est une application WEB fournit avec TOMCAT qui permet d’effectuer des opération de déploiement et de mise à jour de façon assez simple et à distance  Chaque Host a son propre manager accessible via l’URL http://[host]:[port]/manager  TOMCAT Manager permet d’effectuer un certain nombre d’opérations autre que le déploiement, le redéploiement ou la désinstallation des applications  Arrêter une application  Redémarrer une application  Vider les sessions actives
  100. 100. Déploiement d’application Application standard : déploiement à chaud  Tomcat Client Deployer (TCD) est un utilitaire JAVA et des tâches ant, qui permet de gérer le cycle de vie d’une application web  compile (default) : Compile et valide une application web.  deploy : Déploie l’application vers le serveur cible  undeploy : désinstalle une application web  start : démarre une application web  reload : recharge une application web  stop : arrête une application web
  101. 101. Déploiement d’application TOMCAT embarqué (Embededd) Démonstration
  102. 102. Cluster & Load balancer  En production utiliser un seul serveur comporte des risques élevés d’indisponibilité de notre application à chaque fois que notre serveur rencontre des problèmes.
  103. 103. Cluster & Load balancer  La solution est de mettre en place un groupe de serveurs (cluster) qui se comporte alors en tant que serveur de production,  chaque machine exécute la même application,  N’importe quel machine peut traiter les requêtes clients  Si une machine tombe, une autre prends le relais.
  104. 104. Cluster & Load balancer  La solution est de mettre en place un groupe de serveurs Cluster qui se comporte alors en tant que serveur de production,  Chaque machine du groupe exécute la même application,  N’importe quel machine peut traiter les requêtes clients  Si une machine tombe, une autre du groupe prends le relais.
  105. 105. Cluster & Load balancer  Se pose alors quelques problèmes :  Chaque machine du groupe possède sa propre adresse IP  Chaque instance TOMCAT écoute sur son propre port  Quelle instance le client doit invoquer ?
  106. 106. Cluster & Load balancer  La solution consiste à mettre en place une machine frontale  Elle est responsable de recevoir les requêtes client  Elle se charge de redistribuer les requêtes vers les membres du cluster  Cette machine s’appelle un Load Balancer
  107. 107. Cluster & Load balancer Load Balancer (Apache HTTPD + mod_jk connector)  TOMCAT propose deux types de connecteurs HTTP et AJP  Le connecteur HTTP est celui utilisé lorsque TOMCAT est configuré en tant que serveur HTTP  Le connecteur AJP (Apache JSERV Protocole) est celui utilisé lorsque TOMCAT est derrière un frontal, AJP est un connecteur binaire et donc plus performant que le protocole HTTP
  108. 108. Cluster & Load balancer Load Balancer (Apache HTTPD + mod_jk connector)  Installer et configurer Apache pour utiliser le protocole AJP en communication avec TOMCAT.  Configurer le module jk_module au niveau du fichier httpd.conf LoadModule jk_module modules/mod_jk.so JkWorkersFile conf/workers.properties JkLogFile logs/mod_jk.log JkLogLevel emerg JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkOptions +ForwardKeySize +ForwardURICompat - ForwardDirectories JkRequestLogFormat "%w %V %T"
  109. 109. Cluster & Load balancer Load Balancer (Apache HTTPD + mod_jk connector)  Définir le fichier de configuration du mod_jk  Créer un fichier de propriétés workers.properties worker.list=balancer,stat worker.tomcat1.type=ajp13 worker.tomcat1.port=8080 worker.tomcat1.host=192.168.5.10 worker.tomcat2.type=ajp13 worker.tomcat2.port=8090 worker.tomcat2.host=192.168.6.10 worker.tomcat3.type=ajp13 worker.tomcat3.port=8080 worker.tomcat3.host=192.168.7.10 worker.balancer.type=lb worker.balancer.balance_workers=tomcat1,tomcat2,tomcat3 worker.stat.type=status
  110. 110. Cluster & Load balancer Load Balancer (Apache HTTPD + mod_jk connector)  Demander à Apache de déléguer les requêtes vers le Load Balancer définie JkMount /status stat JkMount /* balancer
  111. 111. Cluster & Load balancer Load Balancer (Apache HTTPD + mod_proxy_ajp connector)  À partir de la version 2.1 de Apache HTTPD une autre configuration est possible LoadModule mod_proxy modules/ mod_proxy.so LoadModule mod_proxy_ajp modules/ mod_proxy_ajp.so <Proxy balancer://cluster> BalancerMember ajp://app1.example.com:8009 loadfactor=1 BalancerMember ajp://app2.example.com:8009 loadfactor=2 ProxySet lbmethod=bytraffic </Proxy> ProxyPass /app balancer://cluster/app
  112. 112. Cluster & Load balancer Cluster TOMCAT  Déclarer un cluster au sein de chaque serveur membre, il se fait en ajoutant la balise <cluster> au sein du server.xml  <Manager> : identifie le type de gestionnaire de session utilisé pour gérer la réplication des sessions,  org.apache.catalina.ha.session.DeltaManager (par défaut)  org.apache.catalina.ha.session.BackupManage  <Channel> : la canal de communication des membres du groupe en utilisant du multiCast  <Deployer> : permet de gérer le déploiement des applications au sein des membres du groupe, il suffit de déployer l’application dans un membre et le cluster se charge de la diffuser
  113. 113. Cluster & Load balancer Cluster TOMCAT  <Valve> :  ReplicationValve : notifie le Cluster de la fin du traitement d’une requête HTTP pour optimiser l’opération de réplication des données  JvmRouteBinderValve : ajoute le jvmRoute au niveau de l’id session pour que les requêtes suivantes de la même session soient traités par le même membre.  <ClusterListner> :  ClusterSessionListener : utilisé si le gestionnaire de session est DeltaManager.  JvmRouteSessionIDBinderListener : se charge de redéfinir le jvmRoute de la requête si le serveur responsable est KO.
  114. 114. Cluster & Load balancer Cluster TOMCAT
  115. 115. Cluster & Load balancer Cluster TOMCAT  Ajouter la balise <distributable/> au sein du fichier web.xml de chaque application qui doit être géré par le cluster  Les objets déposés par les applications dans les sessions HTTP doivent être sérialisable
  116. 116. Cluster & Load balancer jvmRoute  Imaginons le scénario suivant :  Une application avec un besoin d’utilisation de la session, par exemple un caddie.  Mon application me permet de naviguer en son sein et de remplir mon caddie  Le load balancer intercepte chaque requête et décide de l’envoyer à un autre membre du groupe  Ce membre reçoit la requête avec un ID session qu’il ne gère pas encore, il créer une nouvelle session avec cette ID et traite la requête  PB : mon caddie est géré en session, Le caddie est vide.
  117. 117. Cluster & Load balancer jvmRoute  Obliger le load balancer de diriger toues les requêtes vers le membre qui a traité la 1er  Ajouter l’attribut jvmRoute au niveau de la balise <Engine>, la valeur de l’attribut doit correspondre au nom attribué au membre lors de la définition du load balancer
  118. 118. Cluster & Load balancer jvmRoute  au sein du fichier workers.properties worker.tomcat1.type=ajp13 worker.tomcat1.port=8080 worker.tomcat1.host=192.168.5.10 <Engine name="Catalina" defaultHost="localhost“ jvmRoute=“tomcat1” >
  119. 119. Cluster & Load balancer jvmRoute  Pour Apache HTTPD 2 avec le module mod_proxy_ajp ProxyPass /app balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On <Proxy balancer://mycluster> BalancerMember ajp://192.168.1.50:80 route=node1 BalancerMember ajp://192.168.1.51:80 route=node2 </Proxy> <Engine name="Catalina" defaultHost="localhost“ jvmRoute=“node1” >
  120. 120. Cluster & Load balancer jvmRoute  Après cette opération TOMCAT génère l’id session en y intégrant le jvmRoute  Avant : Cookie: JSESSIONID=40025608F7B50E42DFA2785329079227  Après : Cookie:JSESSIONID=40025608F7B50E42DFA2785329079227.tomcat1
  121. 121. Cluster & Load balancer jvmRoute  Au niveau de la définition du Cluster au sein de TOMCAT :  <Manager> : utiliser le org.apache.catalina.ha.session.DeltaManager  <Valve> : intégrer la valve JvmRouteBinderValve  <ClusterListner> : intégrer les valves ClusterSessionListener et JvmRouteSessionIDBinderListener
  122. 122. Cluster & Load balancer jvmRoute  Après cette opération TOMCAT génère l’id session en y intégrant le jvmRoute  Avant : Cookie: JSESSIONID=40025608F7B50E42DFA2785329079227  Après : Cookie:JSESSIONID=40025608F7B50E42DFA2785329079227.tomcat1
  123. 123. Multiple instances Préparer les environnements  CATALINA_HOME : variable d’environnement qui pointe sur le répertoire d’installation de TOMCAT, permet de localiser les dossier bin et lib  CATALINA_BASE : variable d’environnement qui pointe sur le répertoire contenant les dossier de configuration TOMCAT, conf, logs, temp, webapps, et work  Si ce variable n’est pas positionné, il est automatiquement remplacé par CATALINA_HOME
  124. 124. Multiple instances Préparer les environnements  Pour chaque instance souhaité, préparer un répertoire, et y copier les dossiers conf, temp, webapps, logs à partir de la copie d’origine  Mettre à jour le fichier de configuration server.xml  Changer le port SHUTDOWN de la balise <Server>  Changer les ports d’écoutes des différents connecteurs configurés HTTP ou AJP  Changer toute autre configuration souhaité
  125. 125. Multiple instances Démarrer  Préparer un script de démarrage pour les différentes instances :  Linux : export CATALINA_BASE= /path/tomcat-instance1 cd $CATALINA_HOME/bin ./startup.sh  Windows : set CATALINA_BASE= /path/tomcat-instance1 cd $CATALINA_HOME/bin ./startup.bat
  126. 126. APR INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path  Avec ce message TOMCAT vous propose d’installer le module APR (Apache Portable Runtime) pour plus de performance et de stabilité.  Le module APR fournit à TOMCAT un accès native aux ressources systèmes sans passer par le JDK.  permet d'améliorer les performances globales du serveur WEB (meilleure génération des identifiants de session, entrées/sorties fichier, SSL, …).
  127. 127. APR APR pour Linux  Installation : get-app install libapr1-dev libssl-dev cp $TOMCAT_HOME/bin/tomcat-native.tar.gz /usr/local/src cd /usr/local/src tar -xvzf tomcat-native.tar.gz cd tomcat-native-1.1.16-src/jni/native ./configure --with-apr=/usr/bin/apr-1-config --with-java-home=$JAVA_HOME --with-ssl=yes --prefix=$CATALINA_HOME make make install  Démarrage : Ajouter la variable d’environnement suivante au niveau du catalina.sh export LD_LIBRARY_PATH='$LD_LIBRARY_PATH:/usr/local/apr/lib'
  128. 128. APR APR pour Windows  Télécharger la DLL tcnative-1.dll  Déposer la DLL dans le dossier bin de TOMCAT  Redémarrer TOMCAT
  129. 129. APR Utiliser les connecteurs  Intégrer le connecteur APR  HTTP <Connector port="8080" protocol="org.apache.coyote.http11.Http11AprProtocol" connectionTimeout="20000" redirectPort="8443" acceptCount="100" maxKeepAliveRequests="15"/>  HTTPS <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /> <Connector port="443" maxHttpHeaderSize="8192" maxThreads="150" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" SSLEnabled="true" SSLCertificateFile="${catalina.base}/conf/localhost.crt" SSLCertificateKeyFile="${catalina.base}/conf/localhost.key" />
  130. 130. JMX Monitoring  TOMCAT est une application JAVA est par conséquent il peut être surveillé (Monitoring) a distance ou en local grâce à son support de JMX en utilisant les outils de monitoring JAVA standard du marché.  Notamment l’utilitaire JDK jVisualVM, il se trouve dans le dossier bin du JDK
  131. 131. JMX Monitoring  Créer un fichier setenv.sh et y ajouter la ligne suivante : export JAVA_OPTS="-Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=adressIPVotreServeur"  Démarrer l’utilitaire jVisualVM.  Utiliser le menu file->Add JMX Connection  Saisir l’adresse IP de votre TOMCAT et le port d’écoute JMX
  132. 132. JMX Monitoring  Il est possible de sécuriser l’accès JMX à votre serveur export JAVA_OPTS="-Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Djava.rmi.server.hostname=adressIPVotreServeur -Dcom.sun.management.jmxremote.password.file=/path/jmx.password -Dcom.sun.management.jmxremote.access.file=/path/jmx.access"
  133. 133. JMX Monitoring  Le fichier jmx.password contient les couples login/mot de passe autorisés à accéder en JMX sous la forme user1 password1 user2 password2  Le fichier jmx.access contient les autorisations de chaque utilisateur user1 readonly user2 readwrite  L’accès au fichier jmx.password doit être limité à l’utilisateur JAVA sudo chown tomcat7:tomcat7 /path/jmx.* sudo chmod 0600 /path/jmx.* pour la plate forme Windows suivre le document suivant : http://docs.oracle.com/javase/6/docs/technotes/guides/mana gement/security-windows.html
  134. 134. JMX Monitoring  Si TOMCAT est dernière un firewall, il se peut qu’un problème de communication advienne.  JMX utilise le port configuré pour la phase de connexion, mais après il ouvre un autre port de façon aléatoire pour la communication des données  Il est possible de contrôler ce port de communication en ajoutant l’écouteur JmxRemoteLifecycleListener au niveau du server.xml <Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" rmiRegistryPortPlatform="9090" rmiServerPortPlatform="9091" />

×