Personalizzazione di un piano di migrazione

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Dovresti esaminare il file del piano di migrazione risultante dalla creazione di una migrazione. Personalizza il file prima di eseguire la migrazione. I dettagli del tuo piano di migrazione vengono utilizzati per estrarre gli artefatti dei container 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 il file del piano di migrazione sia stato creato.

Modifica il piano di migrazione

Puoi modificare il piano di migrazione utilizzando lo strumento migctl o Google Cloud Console.

mgctl

Devi scaricare il piano di migrazione prima di poterlo modificare:

1. Scarica il piano di migrazione. Il piano è rappresentato da GenerateArtifactsFlow:

   migctl migration get my-migration
   

2. Modifica il piano di migrazione scaricato, my-migration.yaml, in un editor di testo.

3. Una volta apportate le modifiche, salva e carica il piano di migrazione rivisto:

   migctl migration update my-migration --file my-migration.yaml
   

4. Ripeti questa procedura se sono necessarie ulteriori modifiche.

Console

Modifica il piano di migrazione in Google Cloud Console utilizzando l'editor YAML. Il piano di migrazione è rappresentato dal CRD GenerateArtifactsFlow:

1. Apri la pagina Esegui la migrazione ai container in Cloud Console.

   Vai alla pagina Esegui la migrazione ai contenitori.

2. Fai clic sulla scheda Migrazioni per visualizzare una tabella contenente le migrazioni disponibili.

3. Nella riga relativa alla migrazione che ti interessa, seleziona il Nome della migrazione per aprire la scheda Dettagli.

4. Seleziona la scheda YAML.

   Nota: puoi anche selezionare Download Migration Plan (Scarica piano di migrazione) per scaricare una copia locale.

5. Modifica il piano di migrazione in base alle esigenze.

6. Una volta completata la modifica, puoi:

   1. Salva il piano di migrazione. Dovrai quindi eseguire la migrazione manualmente per generare gli artefatti di migrazione. Segui la procedura descritta in Esecuzione di una migrazione.

   2. Salva e genera gli artefatti. Esegui la migrazione utilizzando le modifiche per generare gli artefatti di migrazione. La procedura è la stessa descritta in Esecuzione di una migrazione. Puoi quindi monitorare la migrazione come descritto in Monitoraggio di una migrazione.

CRD

Devi scaricare il piano di migrazione, modificarlo e quindi applicarlo. Il piano di migrazione è rappresentato dal CRD GenerateArtifactsFlow:

1. Trova il nome di GenerateArtifactsFlow:

   kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration -o jsonpath={.status.resources.generateArtifacts.name}

   Il pattern di denominazione viene restituito nel formato generate-artifacts-flow-id.

2. Recupera il nome GenerateArtifactsFlow per nome e scrivi in un file denominato my-plan.yaml:

   kubectl get generateartifactsflows.anthos-migrate.cloud.google.com -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml

3. Modifica il piano di migrazione in base alle esigenze.

4. Applica il file:

   kubectl apply -f my-plan.yaml

Rivedi i dettagli del tuo piano di migrazione e guida i commenti per aggiungere informazioni in base alle necessità. In particolare, prendi in considerazione la modifica di queste 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 Java.

• Versione Tomcat: la versione Tomcat viene rilevata e convertita in una versione principale (le versioni secondarie non sono supportate). Se non riusciamo a rilevare una versione di Tomcat, fromImage conterrà una stringa vuota.
• Versione Java: la versione Java viene impostata utilizzando le informazioni della raccolta di valutazione di idoneità. Se CATALINA_BASE o CATALINA_HOME vengono inseriti manualmente o se la valutazione di idoneità non riesce a raccogliere la versione Java, la versione Java è impostata su 11 per impostazione predefinita.
• Fornitore Java: il fornitore Java è impostato su una costante: openjdk.

Nel piano di migrazione, il campo fromImage rappresenta il tag 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, che viene generato dal rilevamento iniziale.

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

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          fromImage: tomcat:9.0-jdk11-openjdk

Configura SSL

Quando crei una nuova migrazione di Tomcat, un processo di rilevamento analizza le configurazioni del server per rilevare l'utilizzo di tutti i certificati. I percorsi dei certificati vengono mappati alle diverse applicazioni rilevate.

Questi certificati vengono visualizzati nel piano di migrazione a livello di server e di immagine:

• Ambito del server: i secret che includi nell'ambito del server saranno esclusi dagli artefatti di immagine risultanti. Uno script dedicato per gli artefatti chiamato secrets.sh automatizza la creazione di oggetti secret Kubernetes dai loro percorsi locali.

• Ambito dell'immagine: i nomi dei secret che includi nell'ambito dell'immagine causeranno un montaggio automatico dei secret corrispondenti nei container di cui è stato eseguito il deployment. Se hai impostato un percorso segreto come relativo nel piano di migrazione, il percorso di montaggio verrà fissato rispetto alla directory di installazione delle immagini della community Tomcat.

Puoi creare oggetti secret Kubernetes utilizzando l'artefatto secrets.sh con la migrazione ai container eseguendo questo comando:

bash ./secrets.sh namespace of deployments secret file secret file … 

Nota: l'ordine in cui elenchi gli oggetti segreti quando esegui secrets.sh deve corrispondere all'ordine degli oggetti segreti nel tuo piano di migrazione.

Logging delle app web

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

Importante: i percorsi esterni a CATALINA_HOME non sono supportati.

Migrate to Containers creerà un file di archivio aggiuntivo con le configurazioni dei log modificate e convertirà tutti gli strumenti di aggiunta dei tipi di file in append-console. Puoi utilizzare i contenuti di questo archivio come riferimento per abilitare la raccolta di log e trasmetterli in streaming a una soluzione di raccolta dei log, ad esempio Google Cloud Logging.

Nota: quando esegui la migrazione a un'immagine container, Migrate to Containers filtra la directory logs dal server Tomcat per omettere i log precedenti.

Allocazione memoria

Durante il processo di migrazione, Migrate to Containers tenta di individuare i limiti della memoria per lo heap massimo di Tomcat Java Heap sulle VM di origine. Se vengono rilevati limiti di memoria su una VM di origine, Migrate to Containers imposta requests su initial e limits su high per il container di cui è stata eseguita la migrazione.

Questi valori si basano sul valore massimo della dimensione heap di Java (-Xmx/-XX:MaxHeapSize), che viene raccolto dall'istanza di origine utilizzando la valutazione di idoneità (mfit). I valori saranno i seguenti: limit=200%Xmx, request=125%Xmx.

Nota: Migrate to Containers supporta solo gli argomenti JVM Xmx,MaxHeapSize.

Se vuoi specificare i limiti della memoria delle applicazioni di cui è stata eseguita la migrazione in singoli container o se non sono stati rilevati limiti di memoria nelle VM di origine, puoi modificare i limiti della memoria direttamente nel piano di migrazione utilizzando il formato seguente:

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

Se nel piano di migrazione sono stati definiti limiti di memoria, il Dockerfile generato insieme ad altri artefatti dopo una migrazione riuscita rispecchierà 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 valore indica la dimensione iniziale e massima per il 50% del valore limite. In questo modo, le dimensioni dell'allocazione heap di Tomcat Java possono cambiare in base a qualsiasi modifica relativa al limite di memoria dei pod.

Nota: se il campo ccatalinaOpts contiene una variabile -Xms/InitialRAMPrecentage/InitialRAMFraction/InitialHeapSize, la variabile di ambiente InitialRAMPercentage=50 non verrà impostata.

Imposta le variabili di ambiente Tomcat

Se vuoi impostare CATLINA_OPTS nel Dockerfile generato insieme ad altri artefatti dopo una migrazione riuscita, puoi innanzitutto aggiungere al campo catalinaOpts il tuo piano di migrazione. L'esempio seguente mostra un campo catalineOpts aggiornato:

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

Migrate to Containers analizza i dati catalinaOpts nel tuo 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 tuo 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, dovrai modificare il Dockerfile.

Nota: se imposti -Xmx, questa sovrascrive -XX:MaxRAMPercentage. Se imposti -Xms, sovrascriverà -XX:InitialRAMPercentage.

Nota: Migrate to Containers e GKE non valutano i contenuti setenv.sh. Di conseguenza, è consigliabile aggiungere le variabili di ambiente Tomcat direttamente a CATALINA_OPTS.

Passaggi successivi

• (Facoltativo) Configura la migrazione dei dati.
• Eseguire una migrazione