Personalizza il piano di migrazione per i server Tomcat
Ti consigliamo di esaminare il file del piano di migrazione risultante dalla creazione di una migrazione. Personalizza il file prima di eseguire la migrazione. I dettagli di il piano di migrazione viene utilizzato per estrarre gli artefatti dei container dei carichi 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 artefatti di deployment.
Prima di iniziare
Questo argomento presuppone che tu abbia già ha creato una migrazione e avere il file del piano di migrazione.
Modifica il piano di migrazione
Dopo aver copiato il file system e analizzato il file, puoi trovare
il piano di migrazione nella nuova directory creata nell'output specificato
percorso: ANALYSIS_OUTPUT_PATH/config.yaml
.
Modifica il piano di migrazione in base alle tue esigenze e salva le modifiche.
Esamina i dettagli del piano di migrazione e le indicazioni per aggiungere informazioni, se necessario. In particolare, prendi in considerazione le modifiche apportate alle seguenti sezioni.
Specifica l'immagine Docker
Nel piano di migrazione, generiamo un tag immagine della community Docker basato Versione Tomcat, versione Java e fornitore Java.
- Versione Tomcat: la versione Tomcat viene rilevata e convertita in una versione principale.
(le versioni secondarie non sono supportate). Se non rileviamo un tomcat
, allora
baseImage.name
contiene una stringa vuota. - Versione Java: la versione Java dipende dal parametro
java-version
. it è impostato su11
per impostazione predefinita. - 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 l'immagine Docker
utilizzato come base dell'immagine container.
Le versioni Tomcat e Java originali rilevate sulla VM di origine sono contenute in
discovery-report.yaml
generato dal rilevamento iniziale.
Se vuoi cambiare l'immagine della community Docker o fornire il tuo Docker
puoi modificare baseImage.name
nel piano di migrazione utilizzando
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 container.
Aggiorna percorso di installazione Tomcat
Durante il processo di migrazione, se l'immagine di destinazione ha un'immagine non predefinita
Percorso CATALINA_HOME
, quindi puoi specificare un percorso CATALINA_HOME
personalizzato. Modifica
il campo catalinaHome
di destinazione 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.
Personalizza utente e gruppo
Durante il processo di migrazione, se l'immagine di destinazione viene eseguita con un altro utente
e un gruppo di root:root
, puoi specificare un utente e un gruppo personalizzati
in cui vuoi eseguire l'applicazione. Modifica direttamente l'utente e il gruppo
nel tuo 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 Tomcat, un processo di rilevamento analizza il server rispetto alle diverse applicazioni scoperte.
Dopo il rilevamento, i seguenti campi vengono compilati automaticamente nella piano di migrazione:
excludeFiles
: elenca i file e le directory da escludere dalla migrazione.Per impostazione predefinita, tutti i percorsi e i certificati sensibili individuati durante il rilevamento vengono aggiunti automaticamente a questo campo ed esclusi dalla migrazione. Se rimuovi un percorso dall'elenco, il file o la directory vengono caricati all'immagine container. Per escludere un file o una directory dal container: immagine, aggiungi il percorso a questo elenco.
sensitiveDataPaths
: elenca tutti i percorsi e i certificati sensibili rilevati dal processo di rilevamento.Per caricare i certificati nel repository, imposta
includeSensitiveData
sutrue
:# 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 secret
secrets.yaml
nel repository degli artefatti.
Logging delle app web
Migrate to Containers supporta il logging con log4j v2
, logback
e
log4j v1.x
che risiedono in CATALINA_HOME
.
Migrate to Containers crea un file di archivio aggiuntivo configurazioni di log modificate e converti tutti gli appender dei tipi di file nella console appendici. Puoi utilizzare i contenuti di questo archivio come riferimento per attivare la raccolta di log e il flusso di dati 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 in singoli container. Modifica i limiti di memoria direttamente nel piano di migrazione utilizzando quanto segue formato:
tomcatServers:
- name: latest
. . .
images:
- name: tomcat-latest
. . .
resources:
memory:
limit: 2048M
requests: 1280M
Il valore consigliato per limit
è il 200% di Xmx
, che corrisponde al numero massimo di Java
heap. Il valore consigliato per requests
è il 150% di Xmx
.
Per vedere il valore di Xmx
, esegui questo comando:
ps aux | grep catalina
Se nel piano di migrazione sono stati definiti limiti di memoria, il Dockerfile che è stato generato insieme ad altri artefatti dopo che una migrazione 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>"
Definisce la dimensione iniziale e quella massima in modo che corrisponda al 50% del valore limite. Ciò consente la dimensione di allocazione heap Tomcat Java limite di memoria dei pod.
Imposta le variabili di ambiente Tomcat
Se vuoi impostare CATALINA_OPTS
nel Dockerfile che è
generati insieme ad altri artefatti dopo una migrazione riuscita,
puoi innanzitutto aggiungere al campo catalinaOpts
del piano di migrazione. La
l'esempio seguente mostra un campo catalinaOpts
aggiornato:
tomcatServers:
- name: latest
. . .
images:
- name: tomcat-latest
. . .
resources:
. . .
catalinaOpts: "-Xss10M"
Migrate to Containers analizza i dati catalinaOpts
nei tuoi
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 Tomcat utilizzando lo script setenv.sh
,
che si trova nella cartella /bin
sul server Tomcat. Per ulteriori informazioni
informazioni sulle variabili di ambiente Tomcat, consulta
Documentazione di Tomcat.
Se scegli di utilizzare setenv.sh
per configurare il tuo ambiente Tomcat
devi modificare il Dockerfile.
Imposta probe di integrità Tomcat
Puoi monitorare il tempo di inattività e lo stato di pronto dei container gestiti specificando i probe nel piano di migrazione del server web Tomcat. Probe di integrità il monitoraggio può aiutare a ridurre il tempo di inattività dei container di cui è stata eseguita la migrazione e un monitoraggio più efficace.
Gli stati di integrità sconosciuti possono causare un peggioramento della disponibilità, falsi positivi il monitoraggio della disponibilità e la potenziale perdita di dati. Senza un probe di integrità, kubelet può solo assumere l'integrità di un container e inviare traffico a un un'istanza di container non ancora pronta. Ciò può causare una perdita di traffico. kubelet potrebbe e non rilevano i container che si trovano in stato bloccato e non li riavviano.
Un probe di integrità funziona eseguendo una piccola istruzione basata su script quando
del container. Lo script verifica la presenza di condizioni riuscite, ovvero
definita dal tipo di probe utilizzato, per ogni periodo. Il periodo è definito nel
piano di migrazione in base a un campo periodSeconds
. Puoi eseguire o definire questi script
manualmente.
Per scoprire di più sui probe kubelet, consulta Configurare probe di attività, idoneità e avvio nella documentazione di Kubernetes.
Sono disponibili due tipi di probe da configurare, che vengono probe-v1-core definito nel riferimento probe-v1-core e condividono la stessa funzione dei campi corrispondenti container-v1-core
- Probe di attività: i probe di attività vengono utilizzati per sapere quando riavviarsi un container.
- Probe di idoneità: i probe di idoneità sono utilizzati per sapere quando un container sia pronto per iniziare ad accettare traffico. Per iniziare a inviare traffico a un pod solo quando se un probe ha esito positivo, specifica un probe di idoneità. Un probe di idoneità potrebbe agire 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 avvia che ricevono traffico dopo l'esito positivo del probe.
Dopo il rilevamento, la configurazione del probe viene aggiunta al piano di migrazione. La
i probe possono essere utilizzati nella loro configurazione predefinita, come illustrato di seguito
esempio. Per disattivare i probe, 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 cambiare questo piano di migrazione in modo che utilizzi 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 container con un probe. Ogni probe deve definire esattamente uno di questi quattro meccanismi:
exec
: esegue un comando specificato all'interno del container. L'esecuzione viene considerata riuscita se il codice di stato dell'uscita è 0.grpc
: esegue una chiamata di procedura remota utilizzando "gRPC". `gRPC` i probe sono una caratteristica alfa.httpGet
: esegue una richiesta GET HTTP sull'IP del pod su una porta e un percorso specificati. La richiesta viene considerata riuscita se il codice di stato è maggiore di o uguale a 200 e inferiore a 400.tcpSocket
: esegue un controllo TCP sull'IP del pod su una porta specificata. La diagnostica viene considerata riuscita se sia aperta.
Per impostazione predefinita, un piano di migrazione abilita il metodo di probe tcpSocket
. Utilizza la
configurazione manuale del piano di migrazione per utilizzare metodi di probe diversi.
Puoi anche definire comandi e script personalizzati tramite il piano di migrazione.
Aggiungere dipendenze esterne per il probe di idoneità, utilizzando al contempo il valore predefinito un probe di attività, è possibile definire un probe di idoneità exec e uno script che implementa logica.
Verifica la configurazione del clustering Tomcat
Il clustering Tomcat viene utilizzato per replicare le informazioni di sessione tra tutti i Tomcat che ti consentono di chiamare qualsiasi server delle applicazioni di backend senza perdere le informazioni sulla sessione client. Per saperne di più sulla configurazione del clustering, consulta la guida pratica sulla replica di cluster/sessione nella documentazione di Tomcat.
La classe di clustering Tomcat si chiama SimpleTcpListener
e utilizza il multicast
di messaggi cardiaci per la scoperta dei contenuti peer. Gli ambienti cloud non supportano il multicast,
devi modificare la configurazione del clustering o rimuoverla, se possibile.
Quando un bilanciatore del carico è configurato per eseguire e mantenere una sessione fissa
server Tomcat di backend, può utilizzare la proprietà jvmRoute
configurata nel
Configurazione di Engine
.
Se il tuo ambiente di origine utilizza una configurazione di clustering non supportata,
modifica il file server.xml
per disabilitare la configurazione oppure utilizza un
configurazione supportata.
- Tomcat 8.5 o versioni successive: il clustering deve essere disabilitato su Tomcat 8.5.
Per disabilitare il clustering, devi commentare la sezione
<Cluster … />
inserver.xml
. Tomcat 9 o versioni successive: in Tomcat 9 o versioni successive, puoi attivare il
Cluster
corso utilizzandoKubernetesMembershipService
.KubernetesMembershipService
è una classe specifica di Kubernetes, che utilizza le API Kubernetes per il rilevamento peer.Provider Kubernetes: di seguito è riportata una configurazione di esempio per 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: usa
DNSMembershipProvider
per utilizzare le API DNS. per la peer discovery. Di seguito è riportata una configurazione di esempio per un DNS. fornitore:<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, da statico a quello di utilizzo del nome POD. In questo modo viene configurato Tomcat per aggiungere un suffisso al cookie di sessione con il nome del pod. Questo può essere utilizzato dal bilanciatore del carico frontend per indirizzare il traffico all'infrastruttura Tomcat POD. Modifica il valore nel file
server.xml
per utilizzare il valore seguenti:<Engine name="Catalina" defaultHost="localhost" jvmRoute="${HOSTNAME}">
Verifica la configurazione del proxy Tomcat
Se Tomcat è configurato per essere eseguito dietro un proxy inverso o utilizzando diversi proxy
impostazioni di configurazione nella sezione Connector
di server.xml
, devi
verificare che le stesse configurazioni proxy siano ancora applicabili dopo la migrazione
vengono eseguite in Kubernetes.
Per eseguire un'applicazione Tomcat containerizzata funzionale, scegli una delle le seguenti modifiche alla configurazione proxy inversa:
- Disattiva configurazione proxy:se l'applicazione di cui è stata eseguita la migrazione non è più
viene eseguito dietro un proxy inverso, puoi disabilitare la configurazione del proxy rimuovendo
proxyName
eproxyPort
dalla configurazione del connettore. - Esegui la migrazione del proxy:esegui la migrazione della VM proxy e conserva tutte le impostazioni esistenti. Configurazioni Tomcat.
Configura Ingress per sostituire il proxy inverso: se non sono personalizzati o è stata implementata una logica sofisticata per il proxy inverso, configurare una risorsa Ingress per esporre l'applicazione Tomcat migrata. Questo usa lo stesso FQDN utilizzato prima della migrazione. Per configurare una risorsa Ingress, devi verificare che il tuo servizio Kubernetes Tomcat sia di
type: Nodeport
. Di seguito è riportata una configurazione di esempio di una risorsa 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 Cloud Service Mesh con Cloud Load Balancing:se utilizzi GKE Enterprise, puoi scegliere di esporre la tua applicazione utilizzando Cloud Service Mesh. Per scoprire di più sull'esposizione delle applicazioni mesh di servizi, consulta Da perimetrale al mesh: esposizione delle applicazioni mesh di servizi tramite GKE Ingress.
Verifica la configurazione del proxy Java
Durante la migrazione ai container, devi verificare la disponibilità del proxy nel nuovo ambiente. Quando il server proxy non è disponibile, scegli una delle seguenti modifiche alla configurazione del proxy:
- Disattiva proxying:se il proxy originale non è più in uso, disattivalo
la configurazione del proxy. Rimuovi tutte le impostazioni del proxy dal
setenv.sh
o dal file di configurazione in cui sono gestiti sul server Tomcat. - Modifica le impostazioni del proxy:se il tuo ambiente Kubernetes utilizza una
proxy in uscita diverso, puoi modificare le impostazioni del proxy in
setenv.sh
, o un altro file, in modo da puntare al nuovo proxy.
Passaggi successivi
- Scopri come eseguire la migrazione.