Personalizzare il piano di migrazione per i server Tomcat

Devi esaminare il file del piano di migrazione generato dalla creazione di una migrazione. Personalizza il file prima di eseguire la migrazione. I dettagli del piano di migrazione vengono utilizzati per estrarre gli artefatti del contenitore del carico di lavoro dall'origine.

Questa sezione descrive i contenuti della migrazione e i tipi di personalizzazioni che potresti prendere in considerazione prima di eseguire la migrazione e generare gli artefatti di deployment.

Prima di iniziare

Questo argomento presuppone che tu abbia già creato una migrazione e che tu abbia il file del piano di migrazione.

Modificare il piano di migrazione

Dopo aver copiato e analizzato il file system, puoi trovare il piano di migrazione nella nuova directory creata nel percorso di output specificato: ANALYSIS_OUTPUT_PATH/config.yaml.

Modifica il piano di migrazione in base alle esigenze e salva le modifiche.

Esamina i dettagli del piano di migrazione e i commenti guida per aggiungere le informazioni necessarie. Nello specifico, valuta la possibilità di apportare modifiche alle seguenti sezioni.

Specifica l'immagine Docker

Nel piano di migrazione, generiamo un tag immagine della community Docker in base alla versione di Tomcat, alla versione di Java e al fornitore di Java.

  • Versione Tomcat:la versione di Tomcat viene rilevata e convertita in una versione principale (le versioni minori non sono supportate). Se non riusciamo a rilevare una versione di Tomcat, baseImage.name contiene una stringa vuota.
  • Versione Java: la versione Java dipende dal parametro java-version. Per impostazione predefinita è impostato su 11.
  • Fornitore Java:il fornitore Java è impostato su una costante: temurin.

Ad esempio, il tag dell'immagine della community Docker generato per Tomcat versione 9.0, Java versione 11 e il fornitore Java temurin è tomcat:9.0-jre11-temurin.

Nel piano di migrazione, il campo baseImage.name rappresenta il tag dell'immagine Docker utilizzato come base dell'immagine container.

Le versioni originali di Tomcat e Java rilevate nella VM di origine sono contenute in discovery-report.yaml generato dalla scoperta iniziale.

Se vuoi modificare l'immagine della community Docker o fornire la tua immagine Docker, puoi modificare baseImage.name nel piano di migrazione utilizzando il seguente formato:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          baseImage:
            name: BASE_IMAGE_NAME

Sostituisci BASE_IMAGE_NAME con l'immagine Docker che vuoi utilizzare come base dell'immagine del contenitore.

Aggiorna il percorso di installazione di Tomcat

Durante la procedura di migrazione, se l'immagine di destinazione ha un percorso CATALINA_HOME diverso da quello predefinito, puoi specificare un percorso CATALINA_HOME personalizzato. Modifica il campo catalinaHome target direttamente nel piano di migrazione:

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        baseImage:
          name: BASE_IMAGE_NAME
          catalinaHome: PATH

Sostituisci PATH con il percorso di installazione di Tomcat.

Personalizzare utente e gruppo

Durante il processo di migrazione, se l'immagine di destinazione viene eseguita con un utente e un gruppo diversi da root:root, puoi specificare un utente e un gruppo personalizzati in cui vuoi che venga eseguita l'applicazione. Modifica l'utente e il gruppo direttamente nel piano di migrazione:

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        userName: USERNAME
        groupName: GROUP_NAME

Sostituisci quanto segue:

  • USERNAME: il nome utente che vuoi utilizzare
  • GROUP_NAME: il nome del gruppo che vuoi utilizzare

Configura SSL

Quando crei una nuova migrazione di Tomcat, un processo di rilevamento esegue la scansione del server rispetto alle diverse applicazioni rilevate.

Dopo il rilevamento, i seguenti campi vengono compilati automaticamente nel piano di migrazione:

  • excludeFiles: elenca i file e le directory da escludere dalla migrazione.

    Per impostazione predefinita, tutti i percorsi e i certificati sensibili rilevati durante il rilevamento vengono aggiunti automaticamente a questo campo e sono esclusi dalla migrazione. Se rimuovi un percorso da questo elenco, il file o la directory viene caricato nell'immagine del contenitore. Per escludere un file o una directory dall'immagine del contenitore, aggiungi il percorso a questo elenco.

  • sensitiveDataPaths: elenca tutti i percorsi e i certificati sensibili rilevati dalla procedura di rilevamento.

    Per caricare i certificati nel repository, imposta il campo includeSensitiveData su true:

    # Sensitive data which will be filtered out of the container image.
# If includeSensitiveData is set to true the sensitive data will be mounted on the container.

includeSensitiveData: true
tomcatServers:
- name: latest
  catalinaBase: /opt/tomcat/latest
  catalinaHome: /opt/tomcat/latest
  # Exclude files from migration.
  excludeFiles:
  - /usr/local/ssl/server.pem
  - /usr/home/tomcat/keystore
  - /usr/home/tomcat/truststore
  images:
  - name: tomcat-latest
    ...
    # If set to true, sensitive data specified in sensitiveDataPaths will be uploaded to the artifacts repository.
    sensitiveDataPaths:
    - /usr/local/ssl/server.pem
    - /usr/home/tomcat/keystore
    - /usr/home/tomcat/truststore

    Al termine della migrazione, i secret vengono aggiunti al file secretssecrets.yaml nel repository degli elementi.

Logging delle app web

Migrate to Containers supporta il logging con log4j v2, logback e log4j v1.x che si trovano in CATALINA_HOME.

Migrate to Containers crea un file di archivio aggiuntivo con configurazioni dei log modificate e converte tutti gli aggiunti di tipo di file in aggiunti della console. Puoi utilizzare i contenuti di questo archivio come riferimento per attivare la raccolta e lo streaming dei log in una soluzione di raccolta dei log (come Google Cloud Logging).

Allocazione della memoria

Durante il processo di migrazione, puoi specificare i limiti di memoria delle applicazioni migrate a singoli container. Modifica i limiti di memoria direttamente nel piano di migrazione utilizzando il seguente formato:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limit: 2048M
              requests: 1280M

Il valore consigliato per limit è il 200% di Xmx, ovvero la dimensione massima dell'heap di Java. Il valore consigliato per requests è il 150% di Xmx.

Per visualizzare il valore di Xmx, esegui il seguente comando:

ps aux | grep catalina

Se nel piano di migrazione sono stati definiti limiti di memoria, il Dockerfile che è stato generato insieme ad altri elementi dopo una migrazione riuscita riflette la tua dichiarazione:

FROM tomcat:8.5-jdk11-openjdk

# Add JVM environment variables for tomcat
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50.0 -XX:InitialRAMPercentage=50.0 -XX:+UseContainerSupport <additional variables>"

Questo definisce le dimensioni iniziali e massime come pari al 50% del valore limite. In questo modo, la dimensione dell'allocazione heap Java di Tomcat può cambiare in base a qualsiasi modifica del limite di memoria del pod.

Imposta le variabili di ambiente Tomcat

Se vuoi impostare CATALINA_OPTS nel file Dockerfile generato insieme ad altri elementi dopo una migrazione riuscita, puoi prima aggiungere il campo catalinaOpts al piano di migrazione. Nell'esempio seguente è riportato un campo catalinaOpts aggiornato:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xss10M"

Migrate to Containers analizza i dati catalinaOpts nel Dockerfile. L'esempio seguente mostra l'output dell'analisi:

FROM 8.5-jdk11-openjdk-slim

## setenv.sh script detected.
## Modify env variables on the script and add definitions to the migrated
## tomcat server, if needed (less recommended than adding env variables directly
## to CATALINA_OPTS) by uncomment the line below
#ADD --chown=root:root setenv.sh /usr/local/tomcat/bin/setenv.sh

# Add JVM environment variables for the tomcat server
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50.0 -XX:InitialRAMPercentage=50.0 -Xss10M"

Puoi anche impostare le variabili di ambiente di Tomcat utilizzando lo script setenv.sh, che si trova nella cartella /bin sul server Tomcat. Per ulteriori informazioni sulle variabili di ambiente Tomcat, consulta la documentazione di Tomcat.

Se scegli di utilizzare setenv.sh per impostare le variabili di ambiente Tomcat, devi modificare il Dockerfile.

Imposta i probe di integrità di Tomcat

Puoi monitorare il tempo di riposo e lo stato di disponibilità dei contenitori gestiti specificando le sonde nel piano di migrazione del server web Tomcat. Il monitoraggio delle sonde di salute può contribuire a ridurre i tempi di inattività dei container di cui è stata eseguita la migrazione e a fornire un monitoraggio migliore.

Gli stati di integrità sconosciuti possono causare un degrado della disponibilità, monitoraggio della disponibilità con falsi positivi e potenziale perdita di dati. Senza un probe di integrità, kubelet può solo assumere l'integrità di un contenitore e potrebbe inviare traffico a un'istanza di contenitore non pronta. Ciò può causare una perdita di traffico. Kubelet potrebbe anche non rilevare i contenitori in stato di blocco e non riavviarli.

Una sonda di stato funziona eseguendo una piccola istruzione basata su script all'avvio del container. Lo script controlla la presenza di condizioni di successo, che sono definite dal tipo di sonda utilizzata, in ogni periodo. Il periodo è definito nel piano di migrazione da un campo periodSeconds. Puoi eseguire o definire questi script manualmente.

Per scoprire di più sui probe kubelet, consulta Configurare i probe di attività, di idoneità e di avvio nella documentazione di Kubernetes.

Esistono due tipi di sonde disponibili per la configurazione, entrambe sono probe-v1-core definite in documentazione di riferimento di probe-v1-core e condividono la stessa funzione dei campi corrispondenti di container-v1-core

  • Probe di attività:i probe di attività vengono utilizzati per sapere quando riavviare un container.

  • Probe di idoneità:i probe di idoneità vengono utilizzati per sapere quando un container è pronto per iniziare ad accettare il traffico. Per iniziare a inviare traffico a un pod solo quando un probe ha esito positivo, specifica un probe di idoneità. Un probe di idoneità potrebbe funzionare in modo simile a un probe di attività, ma un probe di idoneità nelle specifiche indica che un pod si avvia senza ricevere traffico e inizia a ricevere traffico solo dopo il completamento del probe.

Dopo la scoperta, la configurazione della sonda viene aggiunta al piano di migrazione. I probe possono essere utilizzati nella configurazione predefinita, come mostrato nell'esempio seguente. Per disattivare i controlli, rimuovi la sezione probes dal file YAML.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
        tcpSocket:
          port: 8080
      readinessProbe:
        tcpSocket:
          port: 8080

Puoi modificare questo piano di migrazione in modo da utilizzare un endpoint HTTP Tomcat esistente.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
       httpGet:
          path: /healthz
          port: 8080
          httpHeaders:
          - name: Custom-Header
            value: Awesome
        initialDelaySeconds: 3
        periodSeconds: 3
      readinessProbe:
        httpGet:
        tcpSocket:
          port: 8080

Esistono quattro modi predefiniti per controllare un contenitore utilizzando una sonda. Ogni sonda deve definire esattamente uno di questi quattro meccanismi:

  • exec: esegue un comando specificato all'interno del container. L'esecuzione è considerata riuscita se il codice di stato di uscita è 0.
  • grpc: esegue una chiamata di procedura remota utilizzando "gRPC". I controlli "gRPC" sono una funzionalità alpha.
  • httpGet: esegue una richiesta GET HTTP all'indirizzo IP del pod su una porta e un percorso specificati. La richiesta è considerata riuscita se il codice di stato è maggiore o uguale a 200 e minore di 400.
  • tcpSocket: esegue un controllo TCP sull'indirizzo IP del pod su una porta specificata. La diagnostica viene considerata riuscita se la porta è aperta.

Per impostazione predefinita, un piano di migrazione attiva il metodo di tcpSocketscansione. Utilizza la configurazione manuale del piano di migrazione per utilizzare metodi di sondaggio diversi. Puoi anche definire comandi e script personalizzati tramite il piano di migrazione.

Per aggiungere dipendenze esterne per il controllo di idoneità, utilizzando al contempo il controllo di attività predefinito, definisci un controllo di idoneità all'esecuzione e uno script che implementi la logica.

Verifica la configurazione del clustering di Tomcat

Il clustering di Tomcat viene utilizzato per replicare le informazioni sulla sessione su tutti i nodi Tomcat, il che ti consente di chiamare uno qualsiasi dei server di applicazioni di backend e di non perdere le informazioni sulla sessione del client. Per scoprire di più sulla configurazione del clustering, consulta la sezione Clustering/Session Replication How-To (Istruzioni per la replica di sessioni/clustering) nella documentazione di Tomcat.

La classe di clustering di Tomcat si chiama SimpleTcpListener e utilizza messaggi di heartbeat multicast per la rilevamento dei peer. Gli ambienti cloud non supportano il multicast, quindi devi modificare la configurazione del clustering o rimuoverla, se possibile.

Quando un bilanciatore del carico è configurato per eseguire e gestire una sessione fissa sul server Tomcat di backend, può utilizzare la proprietà jvmRoute configurata nella configurazione Engine server.xml.

Se l'ambiente di origine utilizza una configurazione di clustering non supportata, modifica il file server.xml per disattivare la configurazione o utilizza una configurazione supportata.

  • Tomcat 8.5 o versioni successive:il clustering deve essere disattivato in Tomcat 8.5. Per disattivare il clustering, devi commentare la sezione <Cluster … /> in server.xml.

  • Tomcat 9 o versioni successive: in Tomcat 9 o versioni successive, puoi attivare la classe Cluster utilizzando KubernetesMembershipService. KubernetesMembershipService è una classe specifica di Kubernetes, che utilizza le API Kubernetes per il rilevamento dei peer.

    • Provider Kubernetes:di seguito è riportata una configurazione di esempio per un provider Kubernetes:

      <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider"/>
</Channel>
</Cluster>

    • Provider DNS: utilizza DNSMembershipProvider per utilizzare le API DNS per il rilevamento dei peer. Di seguito è riportata una configurazione di esempio per un fornitore DNS:

      <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.DNSMembershipProvider"/>
</Channel>
</Cluster>

    • jvmRoute: quando il bilanciatore del carico si basa su un valore jvmRoute, il valore deve essere modificato da statico in modo da utilizzare il nome del pod. In questo modo, Tomcat viene configurato per aggiungere un suffisso al cookie della sessione con il nome del pod. Questo può essere utilizzato dal bilanciatore del carico frontend per indirizzare il traffico al pod Tomcat corretto. Modifica il valore nel file server.xml in modo da utilizzare quanto segue:

      <Engine name="Catalina" defaultHost="localhost" jvmRoute="${HOSTNAME}">

Verifica la configurazione del proxy Tomcat

Se Tomcat è configurato per funzionare dietro un proxy inverso o utilizza diverse impostazioni di configurazione del proxy nella sezione Connector di server.xml, devi verificare che le stesse configurazioni del proxy siano ancora applicabili dopo la migrazione per l'esecuzione in Kubernetes.

Per eseguire un'applicazione Tomcat containerizzata funzionale, scegli una delle seguenti modifiche alla configurazione del proxy inverso:

  • Disattiva la configurazione del proxy:se l'applicazione di cui è stata eseguita la migrazione non viene più eseguita dietro un proxy inverso, puoi disattivare la configurazione del proxy rimuovendo proxyName e proxyPort dalla configurazione del connettore.
  • Esegui la migrazione del proxy:esegui la migrazione della VM proxy e mantieni tutte le configurazioni Tomcat esistenti.

  • Configura Ingress per sostituire il proxy inverso: se non è stata implementata alcuna logica personalizzata o sofisticata per il proxy inverso, puoi configurare una risorsa Ingress per esporre l'applicazione Tomcat di cui è stata eseguita la migrazione. Questo procedura utilizza lo stesso FQDN utilizzato prima della migrazione. Per configurare un Ingress, devi verificare che il servizio Kubernetes Tomcat sia di type: Nodeport. Di seguito è riportata una configurazione di esempio di un Ingress:

    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-tomcat-ingress
spec:
  rules:
  - host: APP_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-tomcat-service
            port:
              name: my-tomcat-port

  • Configura un Cloud Service Mesh con Cloud Load Balancing Cloud:se utilizzi GKE Enterprise, puoi scegliere di esporre la tua applicazione utilizzando Cloud Service Mesh. Per scoprire di più sull'esposizione delle applicazioni di mesh di servizi, consulta Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi mediante GKE Ingress.

Verificare la configurazione del proxy Java

Quando esegui la migrazione ai contenitori, devi verificare la disponibilità dei server proxy nel nuovo ambiente. Quando il server proxy non è disponibile, scegli una delle seguenti modifiche di configurazione del proxy:

  • Disattiva il proxy:se il proxy originale non è più in uso, disattiva la configurazione del proxy. Rimuovi tutte le impostazioni proxy dallo scriptsetenv.sh o dal file di configurazione in cui vengono gestite sul server Tomcat.
  • Modifica le impostazioni del proxy: se il tuo ambiente Kubernetes utilizza un proxy di uscita diverso, puoi modificare le impostazioni del proxy in setenv.sh o in un altro file in modo che indirizzino al nuovo proxy.

Passaggi successivi