🧠 Oracle WebLogic – Guide complet (Admin, DevOps, Kubernetes)

Services WebLogic qu’on rencontre tout le temps

Ports & flux : checklist rapide

AdminServer : 7001 (HTTP) / 7002 (HTTPS)
Managed ms1 : 8001 (HTTP) / 8002 (HTTPS)
Managed ms2 : 8011 (HTTP) / 8012 (HTTPS)
NodeManager : 5556 (SSL) ou 5558 selon conf
DB          : 1521 (Oracle) / 5432 (PostgreSQL)
LB/Ingress  : 443 (TLS)

Silent install (pattern)

Objectif : reproductible, non interactif, compatible CI/CD.

# 1) Préparer un JDK (ex: 17) et JAVA_HOME
export JAVA_HOME=/usr/lib/jvm/java-17
export PATH=$JAVA_HOME/bin:$PATH

# 2) Lancer l'installer (exemple générique)
java -jar fmw_14.1.2.0.0_wls.jar -silent -responseFile /tmp/wls.rsp -invPtrLoc /tmp/oraInst.loc

# 3) Vérifier l'inventaire / logs
cat /u01/app/oracle/inventory/logs/*.log

Boot identity (start sans mot de passe en clair)

Pattern : stocker les credentials chiffrés par WebLogic dans boot.properties (puis ils sont “encrypted” au premier start).

# Exemple (à placer dans DOMAIN_HOME/servers/AdminServer/security/boot.properties)
username=weblogic
password=SuperSecret123

# Premier démarrage : WebLogic chiffre le password

Checklist “go‑live”

Change Center : comprendre le verrou

WebLogic peut exiger un “lock & edit” avant d’appliquer certaines modifications. En prod, impose une gouvernance :

• Fenêtres de changement, traçabilité, qui a locké, pourquoi
• Validation (preprod) avant activation prod
• Automatisation WLST/Ansible préférée

Anti‑patterns (à éviter en prod)

• Modifier la config à la main, sans PR, puis oublier → drift garanti
• Mettre AdminServer sur le même LB que le trafic client
• Utiliser un user admin partout (pas de séparation des rôles)
• Absence de rotation logs → disque plein → outage “bête”
• Pas de runbook incident/patched → temps de MTTR explose

Exemples WLST (à adapter)

connect('weblogic','***','t3s://admin:7002')
edit(); startEdit()

cd('/')
create('AppDS','JDBCSystemResource')
cd('JDBCSystemResources/AppDS/JdbcResource/AppDS')
create('myJdbcDataSourceParams','JDBCDataSourceParams')
cd('JDBCDataSourceParams/NO_NAME_0')
set('JNDINames', jarray.array([String('jdbc/AppDS')], String))

# driver params
cd('../JDBCDriverParams/NO_NAME_0')
set('Url','jdbc:oracle:thin:@//dbhost:1521/ORCLPDB1')
set('DriverName','oracle.jdbc.OracleDriver')
set('PasswordEncrypted','***')

save(); activate()

connect('weblogic','***','t3s://admin:7002')

app='/artifacts/myapp-1.2.3.ear'

deploy(appName='myapp', path=app, targets='ClusterA', stageMode='stage')

# redeploy contrôlé
# redeploy('myapp', path=app, targets='ClusterA')

Idempotence : le nerf de la guerre

• Avant create() : vérifier si l’objet existe (ls + try/except)
• Comparer la config actuelle vs désirée (desired state)
• Ne pas stocker de secrets en clair dans Git
• Garder des scripts “petits” : 1 script = 1 domaine logique

# pattern simple
try:
  cd('/JDBCSystemResources/AppDS')
  print('AppDS exists')
except:
  cd('/')
  create('AppDS','JDBCSystemResource')
  print('AppDS created')

WLST en CI (Jenkins)

stage('Deploy WebLogic') {
  steps {
    sh '''
      export JAVA_HOME=/usr/lib/jvm/java-17
      export ORACLE_HOME=/u01/app/oracle/middleware
      $ORACLE_HOME/oracle_common/common/bin/wlst.sh wlst/40-deploy.py \
        -DappVersion=${GIT_COMMIT}
    '''
  }
}

Deployment Plan : séparer code et config

Le plan permet de surcharger des paramètres (ex: URLs, JNDI) sans rebuild l’EAR.

# Exemple :
myapp.ear
myapp-plan.xml

# Déploiement
# (console ou wlst deploy(..., planPath='myapp-plan.xml'))

Rolling update (cluster)

1. Drain ms1 (LB) → redeploy sur ms1 → warmup
2. Re-enable ms1
3. Drain ms2 → redeploy sur ms2 → warmup
4. Re-enable ms2

Artefacts & repo

• Nexus/Artifactory/S3 : stocker myapp-1.2.3.ear
• Taguer : version + git sha + build id
• Conserver N versions (N=20) pour rollback rapide

# Naming robuste
myapp-1.2.3+sha.4f2c1a7.ear
myapp-plan-prod.xml
myapp-plan-preprod.xml

XA vs non‑XA (résumé)

• Non‑XA : plus simple, plus rapide, pas de transaction distribuée.
• XA : transactions distribuées (JTA) → plus complexe, logs, timeouts, heuristics.

Tests & monitoring

• Utiliser “Test Data Source” en console (pré-prod/prod)
• Surveiller : Active connections, waiting, failures, leaks
• Alertes : “reserve timeout” et “pool exhausted”

# Runbook incident JDBC
1) Vérifier DB (latence, sessions)
2) Vérifier pool (max, waiting)
3) Réduire load (LB) / scale cluster
4) Identifier leak (threads/stack)
5) Fix app + redeploy

Secrets & mots de passe

• Éviter de committer des passwords dans des scripts
• Utiliser un coffre (Vault/ASM/Secret Manager) + injection runtime
• Permissions FS strictes sur DOMAIN_HOME et keystores

Distributed Queue/Topic

Pour HA/scalabilité : distribuer les destinations sur plusieurs JMS Servers.

ClusterA
  JMS Server on ms1 -> member1
  JMS Server on ms2 -> member2
Distributed Queue -> member1 + member2

SAF (Store‑and‑Forward)

SAF sert à bufferiser/relayer des messages quand une destination distante n’est pas disponible.

• Utile pour inter‑domain / inter‑DC, tolérance réseau
• Surveiller la taille des stores et les backlogs

Runbook JMS incident (exemple)

Symptôme: producers bloqués / queue qui grossit
1) Vérifier quotas / pause / production rate
2) Vérifier consumers (alive? backlog?)
3) Vérifier transactions / timeouts
4) Vérifier store (disk full?)
5) Mitigation: scale consumers, augmenter quotas, purge contrôlée (si validée)
6) Post-mortem: cause racine (bug consumer, slow DB, etc.)

Sessions HTTP : sticky vs replication

Migrations / failover

• Planifier : quelles ressources migrent (JMS, etc.)
• Tester : “kill -9 ms1”, observer bascule
• Documenter : temps de RTO, RPO

Rolling restart (procédure)

Pour chaque managed server:
1) Drain au LB
2) Stop via WLST/Console (graceful)
3) Start via Node Manager
4) Vérifier health + logs
5) Réintégrer au LB

Logs utiles (où regarder)

Rotation : éviter l’outage “disque plein”

• Activer rotation native + logrotate OS si besoin
• Centraliser (ELK/Opensearch/Loki) : plus simple pour incident
• Mettre des alertes : disk usage > 80%

Runbook minimal (1 page)

- URL Admin (VPN) : https://adminhost:7002/console
- URL App (LB)     : https://app.example.com

- Start: nodemanager -> admin -> managed
- Stop : drain LB -> managed -> admin -> nodemanager

- Logs: DOMAIN_HOME/servers//logs
- Incident stuck: thread dumps x3 + vérifier JDBC + GC
- Rollback: redeploy version N-1 + restart node (si requis)

TLS : points clés

• Choisir : terminaison TLS au LB ou end‑to‑end (LB → managed en TLS)
• Keystore/truststore : rotation planifiée
• Désactiver suites obsolètes, forcer TLS 1.2+ (selon politique)

# JVM opts (exemples)
-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2
-Dhttps.protocols=TLSv1.2,TLSv1.3

SSO : SAML / OIDC (selon intégration)

• Centraliser l’identité (IdP) : Azure AD / Okta / Keycloak…
• Définir les claims/groupes → rôles WebLogic
• Tester la révocation / rotation certificats / clock skew

Hardening (quick wins)

• Admin derrière VPN/ZTNA, ACL strictes
• Patch cycle : CPU/PSU planifié (voir modal patching)
• Désactiver services inutiles, samples en prod = NON
• Secrets hors Git, permissions FS minimales
• Audit log activé + SIEM si possible

Exporter & K8s operator

Sur Kubernetes, l’Operator aide à déployer/manager des domains WLS. citeturn0search3turn0search13

Dashboards Grafana : sections suggérées

• Vue “service” : latences / erreurs / saturation
• Vue “cluster” : état nodes, restarts, readiness
• Vue “JVM” : heap/GC/threads
• Vue “JDBC/JMS” : pools + queues

SLO/SLI (simple)

• SLI : % requêtes réussies (2xx/3xx) sur 30j
• SLO : 99.9% de succès + p95 < 300ms (exemple)
• Error budget : pilote la fréquence de changements

OPatch : pattern générique

# 0) Backup ORACLE_HOME + DOMAIN_HOME (ou snapshot)

# 1) Stop servers (managed -> admin)

# 2) OPatch inventory
$ORACLE_HOME/OPatch/opatch lsinventory

# 3) Apply patch
$ORACLE_HOME/OPatch/opatch apply

# 4) Start + validation
# - logs clean
# - smoke tests
# - dashboards OK

Rollback : plan B

• Préparer la commande / procédure avant de patcher
• Conserver les artefacts patchs et l’état d’inventaire
• Tester rollback en pré-prod au moins une fois

Compatibilité / interop

Vérifier les scénarios d’interop entre versions (clients, protocoles). citeturn0search8

GC : lire les logs

• Suivre p95/p99 des pauses
• Corréler : pics latence HTTP ↔ GC pauses
• Surveiller allocation rate

Threads : stuck/hogging

• Thread dumps + identification des verrous (locks)
• Souvent cause : DB lente, appel externe lent, deadlock app

Méthodologie tuning

1. Définir SLO (latence/erreurs)
2. Mesurer baseline
3. Changer 1 paramètre à la fois
4. Rejouer charge
5. Documenter décisions

Images : pattern

# 1) Base image WebLogic (selon recommandations Oracle)
# 2) Copier l'app (EAR/WAR) + plan
# 3) Injecter scripts init / config
# 4) Secrets via K8s Secret (pas dans l'image)

# Tag immuable
registry/myweblogic:app-1.2.3-sha4f2c1a7

Domain CRD (très simplifié)

apiVersion: "weblogic.oracle/v9"
kind: Domain
metadata:
  name: prod-domain
spec:
  domainHomeSourceType: Image
  image: registry/myweblogic:app-1.2.3
  replicas: 2
  serverPod:
    env:
      - name: JAVA_OPTIONS
        value: "-Xms4g -Xmx4g"
  adminServer:
    adminService:
      channels:
        - channelName: default
  clusters:
    - clusterName: ClusterA
      replicas: 2

Day‑2 Ops : checklist

• Rolling upgrade : image tag → apply → observe
• Backups : artefacts + config + secrets rotation
• Observabilité : exporter + dashboards
• Incident : kubectl logs / describe / events + thread dumps si nécessaire

Jenkinsfile (squelette)

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { sh 'mvn -q -DskipTests=false test package' }
    }
    stage('Publish') {
      steps { sh 'cp target/myapp.ear artifacts/' }
    }
    stage('Deploy Preprod') {
      steps { sh 'wlst.sh wlst/40-deploy.py --env preprod' }
    }
    stage('Smoke') {
      steps { sh 'curl -fsS https://preprod/app/health' }
    }
    stage('Deploy Prod') {
      when { branch 'main' }
      steps { sh 'wlst.sh wlst/40-deploy.py --env prod --rolling' }
    }
  }
}

Tests indispensables

• Smoke HTTP (health endpoints)
• Validation JDBC (connectivité)
• Sanity JMS (producer/consumer minimal)
• Temps de réponse p95 sous seuil

Rollback (simple & rapide)

# si prod KO post-deploy
1) redeploy artefact N-1
2) rolling restart si besoin
3) post-mortem + blocage du déploiement

Thread dumps : méthode

1) Prendre 3 dumps à 10s d’intervalle
2) Chercher : mêmes threads bloqués ? mêmes locks ? mêmes stacks ?
3) Identifier la dépendance : DB / HTTP externe / lock applicatif
4) Mitigation : drain + restart d’un node si nécessaire

Heap dumps : quand

• OOMError
• Heap monte sans redescendre (leak probable)
• Analyse avec MAT/YourKit (selon politique)

Cas fréquents → actions