Autres versions

Vous êtes ici : Installer et exploiterInstallationServeur applicatifTomcat

Procédure d'installation du serveur Tomcat

Cette page décrit les étapes d'installation et de configuration de Tomcat, à installer sur le serveur applicatif.

Pré-requis

Installation

  • La procédure ci-dessous décrit une installation manuelle du serveur Tomcat. Vous pouvez modifier les répertoires d'installation si besoin. Il faudra dans ce cas reporter ces chemins dans les étapes suivantes d'installation (voir ci-après).
    #Créer un groupe tomcat
    groupadd tomcat
    
    #Créer un user tomcat
    useradd -g tomcat -d /opt/tomcat -s /usr/sbin/nologin tomcat
    
    #Télécharger la dernière version de tomcat 8.5
    cd /tmp
    export CURRENT_VERSION="$(wget -qO- http://www-us.apache.org/dist/tomcat/tomcat-8/ | grep -o "href=\"v8\.5\.[^/]*/" | grep -oP "8.5.[^/]*")"
    wget http://www-us.apache.org/dist/tomcat/tomcat-8/v${CURRENT_VERSION}/bin/apache-tomcat-${CURRENT_VERSION}.tar.gz
    
    #Télécharger le md5 correspondant
    wget --no-check-certificate https://www.apache.org/dist/tomcat/tomcat-8/v${CURRENT_VERSION}/bin/apache-tomcat-${CURRENT_VERSION}.tar.gz.sha512
    
    #Calculer le sha512sum du targz téléchargé
    sha512sum apache-tomcat-${CURRENT_VERSION}.tar.gz
    
    #Le comparer à celui attendu:
    cat apache-tomcat-${CURRENT_VERSION}.tar.gz.sha512
    
    #Installer le targz
    tar -zxvf apache-tomcat-${CURRENT_VERSION}.tar.gz
    mkdir /opt/tomcat/
    mv apache-tomcat-${CURRENT_VERSION}/* /opt/tomcat/
    
    #Déplacer le répertoire des logs dans /var/log
    mkdir /var/log/tomcat
    rmdir /opt/tomcat/logs
    ln -s /var/log/tomcat /opt/tomcat/logs
    
    #Positionner les droits
    chown -R tomcat:tomcat /var/log/tomcat/
    chown -R tomcat:tomcat /opt/tomcat/
    
    #Nettoyer les fichiers temporaires et la variable d'env
    rm -Rf /tmp/apache-tomcat-${CURRENT_VERSION}
    unset ${CURRENT_VERSION}

Configuration du contrôle des ressources

Le fonctionnement du logiciel nécessite l'utilisation de ressources, notamment des fichiers. La limite du nombre de fichiers ouverts par l'utilisateur tomcat doit être augmentée.
Si possible, passer la limite à "unlimited", sinon passer la limite à 65536.
Il suffit d'éditer le fichier /etc/security/limits.conf :

...
#<domain>      <type>  <item>         <value>
...
tomcat         -       nofile         unlimited
...

Script de lancement

Avec systemd

Dans le répertoire, /etc/systemd/system, créer un fichier tomcat.service (vérifiez les chemins indiqués dans le fichier exemple, et modifiez-les si besoin, pour qu'ils correspondent à votre environnement).

Le lancement s'effectue alors avec la commande

systemctl start|stop|restart|status|enable|disable tomcat

Avec un script de démarrage

Dans le dossier /etc/init.d, créer un fichier tomcat avec les droits d'exécution (vérifiez les chemins indiqués dans le fichier exemple, et modifiez-les si besoin, pour qu'ils correspondent à votre environnement).

Le lancement s'effectue alors avec la commande

/etc/init.d/tomcat stop|start|restart|status|kill

Déclaration de l'application

Le fichier à éditer est /opt/tomcat/conf/server.xml

Connecteur AJP (à vérifier)

Modifier ou créer la balise XML Connector correspondant au protocole AJP et ainsi permettre à Tomcat d'être interrogé via le protocole AJP 1.3.
Cette balise doit se trouver dans la déclaration XML du Service se nommant "Catalina" (ce service existe déjà dans Tomcat).
<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
    <Listener className="org.apache.catalina.startup.VersionLoggerListener"/>
    <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on"/>
    <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
    <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
    <Service name="Catalina">
        <Connector port="8009" protocol="AJP/1.3" connectionTimeout="60000" maxThreads="150" URIEncoding="UTF-8"/>
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" autoDeploy="false" unpackWARs="false" deployOnStartup="false">
                <Context docBase="%WEBAPP_HOME%" path="" crossContext="true" allowLinking="false"/>
                <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
                       prefix="localhost_access_log" suffix=".txt"
                       pattern="%h %l %u %t %S "%r" %s %D %b"/>
            </Host>
        </Engine>
    </Service>
</Server>

avec

  • %WEBAPP_HOME% : chemin absolu où est installée l'application K-Sup/K-Portal (voir ici).

En fonction de votre environnement et des usages de votre application, il peut être nécessaire d'adapter les paramètres suivants :

  • port : port d'écoute du connecteur AJP de Tomcat, par défaut 8009.Cette valeur est utilisée dans la déclaration du worker d'Apache.
  • connectionTimeout : temps durant lequel une connexion acceptée par Tomcat peut être mise en attente (milliseconde)
  • maxThreads : nombre maximum de "thread" Java que pourra exécuter Tomcat en même temps
Remarque : il est fortement recommandé de désactiver tous les autres "Connector" présents dans le fichier "server.xml".

En fonction de votre environnement il peut être nécessaire d'adapter le paramètre allowLinking :

  • allowLinking : changer la valeur à "true" si vous utilisez des liens symboliques pour certains dossiers de l'application
Remarque : il est fortement recommandé de désactiver tous les autres "Host" présents dans le fichier "server.xml".

Options de démarrage

Le fonctionnement et l'exploitation des sites gérés par ksup nécessitent l'ajout de différents paramètres dans la chaîne de démarrage de la JVM.
Ces options peuvent être renseignées dans un fichier setenv.sh situé dans le répertoire d'installation du tomcat /opt/tomcat/bin.
  • Créer un fichier setenv.sh
    cd /opt/tomcat/bin
    vi setenv.sh
  • Ajouter le contenu suivant:
    #Positionnement du répertoire de configuration externe
    JAVA_OPTS="${JAVA_OPTS} -Dconf.dir=%WEBAPP_STORAGE%/conf"
    
    #Gestion de la mémoire de la JVM
    JAVA_OPTS="${JAVA_OPTS} -Xms4G -Xmx4G"
    
    #Gestion du mode de libération de la mémoire
    JAVA_OPTS="${JAVA_OPTS} -XX:+UseG1GC"
    
    #Activation de la journalisation des libération mémoire
    JAVA_OPTS="${JAVA_OPTS} -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:${CATALINA_BASE}/logs/ksup-$(hostname)-gc-$(date +%s).log"
    
    #Désactivation de la tentative de rattachement à un display
    JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true"
  • Avec %WEBAPP_STORAGE% : le chemin absolu vers le dossier "storage" de l'application
  • Positionner les droits
    chown tomcat: setenv.sh

Au démarrage du serveur tomcat, le fichier setenv.sh sera automatiquement intégré dans le processus de démarrage.

Configuration d'une session multi-domaine

Si les urls des sites virtuels sont construits suivant la même forme, par exemple, *.mon-site.fr, il est recommandé d'utiliser une configuration de cookie de session  multi-domaine.
Cette configuration présente l'avantage de n'utiliser qu'une seule session tomcat pour gérer l'authentification sur tout un ensemble de domaines, et réduit donc les ressources utilisées.
La mise en oeuvre de cette configuration s'appuie sur l'utilisation de 2 attributs de la balise <Context /> du fichier server.xml de tomcat. 
L'attribut sessionCookieName permet de modifier le nom du cookie de session. Par défaut, cet attribut prend la valeur "JSESSIONID".
L'attribut sessionCookieDomain permet d'indiquer la portée du cookie de session. Par défaut, le cookie de session n'est valable que pour le domaine sur lequel il a été créé.
<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
   ...
            <Host name="localhost" autoDeploy="false" unpackWARs="false" deployOnStartup="false" sessionCookieName="JSESSIONID" sessionCookieDomain="mon-site.fr">
                <Context docBase="%WEBAPP_HOME%" path="" crossContext="true" allowLinking="false"/>
                <Valve className="org.apache...
   ...
</Server>
Avec cette configuration, il arrive que le cookie de session utilisé pour l'environnement de production interfère avec le cookie utilisé pour l'environnement de préproduction.
C'est le cas lorsque le domaine de préproduction, par exemple "preprod.mon-site.fr" est lui-même un sous-domaine de la production, par exemple "mon-site.fr"
Pour configurer un environnement de préproduction pour lequel le domaine est un sous domaine de la production, il suffit de spécifier un nom de cookie de session différent :
<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
   ...
            <Host name="localhost" autoDeploy="false" unpackWARs="false" deployOnStartup="false" sessionCookieName="JSESSIONIDPP" sessionCookieDomain="preprod.mon-site.fr">
                <Context docBase="%WEBAPP_HOME%" path="" crossContext="true" allowLinking="false"/>
                <Valve className="org.apache...
   ...
</Server>

  Mis à jour le 24 juin 2019