🔒 Note personnelle Apache Tomcat Oracle Linux

Apache / Tomcat / Oracle

Architecture, déploiement, datasources, logs et commandes Linux - l'essentiel pour administrer une stack Java en environnement Linux.

🔴 Architecture 🔵 Tomcat 🟢 Datasources Oracle 🟣 Déploiement 🟡 Commandes Linux ↗ Synthèse

🌐

Apache HTTP

Reverse proxy, SSL, sécurité en frontal.

☕

Tomcat

Conteneur Java, déploiement de WAR.

🗄️

Oracle / Datasources

Pool de connexions, configuration JDBC.

🚀

Déploiement

WAR, scripts SQL, recette avant prod.

🐧

Linux

Services, logs, surveillance système.

Architecture

Apache + Tomcat + Oracle

Le flux d'une requête de l'utilisateur à la base de données

Apache et Tomcat sont deux serveurs distincts qui collaborent. Apache HTTP Server reçoit les requêtes utilisateurs, gère le HTTPS et la sécurité en frontal, puis les transmet à Tomcat qui exécute les applications Java. Tomcat accède aux données via Oracle grâce à un pool de connexions JDBC.

Rôle de chaque composant

→ Apache – reçoit les requêtes HTTP/S, gère les certificats SSL, redirige vers Tomcat via mod_proxy ou AJP.
→ Tomcat – exécute les applications Java packagées en fichiers WAR, gère le pool de connexions vers Oracle.
→ Oracle – stocke toutes les données applicatives, accessible sur le port 1521 via JDBC.

Tomcat

Apache Tomcat

Conteneur de servlets Java - WAR, mémoire, logs

Tomcat est un conteneur de servlets Java. Il prend un fichier WAR (Web Application Archive - un zip de l'application), le déploie dans son répertoire /webapps/ et rend l'application accessible. C'est le moteur d'exécution de toutes les applications Java de la stack.

Les fichiers de logs Tomcat Chemin : /opt/tomcat/logs/

catalina.out - le journal principal ★ - tout ce que fait Tomcat
localhost.log - erreurs applicatives
localhost_access_log.* - accès HTTP (qui fait quoi, quand)

Niveaux de log - gravité croissante

IINFO - tout va bien, informatif. Ex : Server startup in 5432 ms
WWARNING - attention, non bloquant - souvent signe avant-coureur d'un ERROR
EERROR - problème sérieux à investiguer immédiatement
FFATAL - Tomcat ne peut pas démarrer

Messages d'erreur fréquents

!Cannot create JDBC driver... URL 'null' → datasource mal configurée, vérifier context.xml
!OutOfMemoryError: Java heap space → mémoire insuffisante, augmenter -Xmx
!Cannot get a connection, pool timeout → pool épuisé, augmenter maxTotal ou investiguer Oracle
!ORA-12541: TNS no listener → Oracle injoignable, vérifier URL, port, état du service
!WARNING: No web application found → WAR absent ou mal placé dans /webapps/

Datasources Oracle

Connexion Tomcat → Oracle

Pool de connexions JDBC - configuration context.xml

Une datasource est la configuration qui permet à Tomcat de se connecter à Oracle. Elle définit les paramètres de connexion et gère un pool de connexions - des connexions Oracle maintenues ouvertes en permanence pour éviter d'en ouvrir une nouvelle à chaque requête utilisateur. Même principe qu'une connexion DBeaver, mais automatique et mutualisée.

<!-- /opt/tomcat/conf/context.xml -->
<Resource
  name="jdbc/maBase"
  type="javax.sql.DataSource"
  driverClassName="oracle.jdbc.OracleDriver"
  url="jdbc:oracle:thin:@serveur:1521:SID"
  username="monuser"
  password="monpassword"
  maxTotal="20"    <!-- nb max de connexions dans le pool -->
  maxIdle="5"     <!-- connexions inactives maintenues -->
  maxWaitMillis="10000"/>

Interventions courantes sur les datasources

✓ Modifier l'URL si le serveur Oracle change d'adresse ou de SID.
✓ Changer le mot de passe lors des rotations de sécurité.
✓ Augmenter maxTotal si l'application rame sous charge, le diminuer si Oracle est saturé.
✓ Vérifier le SID lors d'une migration de base de données.

Déploiement

Procédure de déploiement

WAR + scripts SQL + config - toujours recette avant production

Règle absolue Toujours déployer en environnement de recette et valider avec les utilisateurs métier avant toute mise en production. Lire les notes de version de l'éditeur avant chaque déploiement - elles indiquent les scripts SQL à exécuter et les fichiers de config à modifier.

Préparer

Lire les notes de version. Identifier les scripts SQL fournis, les fichiers de config à modifier, la compatibilité avec la version Tomcat en place.

Sauvegarder

Export Oracle de la base (expdp) · Copie de l'ancien WAR · Copie des fichiers de config actuels. En cas d'échec, le rollback doit être possible rapidement.

Déployer en recette

Exécuter les scripts SQL → mettre à jour les fichiers de config → copier le nouveau WAR dans /webapps/ → redémarrer Tomcat → surveiller catalina.out immédiatement.

Valider

Tests fonctionnels avec les utilisateurs métier référents. Valider les fonctions critiques. Vérifier les échanges de données si des webservices sont concernés.

Déployer en production

Même séquence exacte qu'en recette, sans improvisation. Communiquer aux utilisateurs avant et après. Intervenir de préférence hors heures ouvrées.

Surveiller et documenter

Surveiller catalina.out dans les heures suivant le déploiement. Rester disponible pour les retours utilisateurs. Documenter l'intervention.

Commandes Linux

Commandes essentielles

Services, logs, fichiers, surveillance - au quotidien

Gestion des services

sudo systemctl start tomcat10	Démarrer Tomcat
sudo systemctl stop tomcat10	Arrêter Tomcat
sudo systemctl restart tomcat10	Redémarrer Tomcat
sudo systemctl status tomcat10	État du service (running / failed)
sudo systemctl restart apache2	Redémarrer Apache

Lecture des logs - commande star ★

tail -f /opt/tomcat/logs/catalina.out	Suivre les logs en temps réel - lancer avant tout redémarrage
tail -n 100 catalina.out	Afficher les 100 dernières lignes
grep "ERROR" catalina.out	Filtrer uniquement les erreurs
grep "2026-05-01" catalina.out	Filtrer par date
grep -i "exception" catalina.out \| tail -50	Dernières exceptions Java

Déploiement de fichiers

cp monapp.war /opt/tomcat/webapps/	Déployer un WAR (Tomcat détecte automatiquement)
ls -lh /opt/tomcat/webapps/	Lister les applications déployées
nano /opt/tomcat/conf/context.xml	Éditer la configuration des datasources
cp -r monapp monapp.bak	Sauvegarder avant modification
diff config.xml config.xml.bak	Comparer deux fichiers de config

Surveillance système

df -h	Espace disque disponible - les logs peuvent saturer un volume
du -sh /opt/tomcat/logs/	Taille occupée par les logs Tomcat
free -h	Mémoire RAM disponible
ps aux \| grep tomcat	Vérifier que le processus Tomcat tourne
netstat -tlnp \| grep 8080	Vérifier que Tomcat écoute sur le port 8080

Réseau et connectivité

ping serveur-oracle	Tester que le serveur Oracle est joignable
telnet serveur-oracle 1521	Tester que le port Oracle 1521 est ouvert
curl -I http://localhost:8080	Tester que Tomcat répond en HTTP

Le réflexe en cas de problème

Dès qu'un utilisateur signale une anomalie : lancer tail -f catalina.out, faire reproduire l'erreur, lire le message. 90% des diagnostics commencent là. Le reste dans la datasource ou dans les scripts SQL d'une mise à jour oubliée.

La règle d'or : jamais en production sans recette, jamais sans sauvegarde, toujours documenter.

Apache - frontal Tomcat - WAR et logs Oracle - datasources Déploiement - 6 étapes Linux - commandes clés