Migrazione di app da una VM tradizionale IBM WAS

Le sezioni seguenti descrivono i passaggi per la migrazione delle app da una VM tradizionale IBM WAS.

Informazioni su migctl

Migrate to Containers include lo strumento a riga di comando migctl che utilizzi per eseguire tutte le parti di una migrazione, come descritto di seguito. Il modo in cui esegui migctl dipende dal tipo di disordine di elaborazione che utilizzi per eseguire la migrazione:

• Quando utilizzi un cluster di elaborazione Google Kubernetes Engine (GKE) o Anthos in Google Cloud, esegui migctl in Cloud Shell.

• Quando utilizzi un cluster di elaborazione on-prem di GKE, devi installare ed eseguire migctl sulla tua workstation di amministrazione come descritto nelle istruzioni di installazione.

Aggiunta di un'origine di migrazione

Prima di iniziare la migrazione, crea un'origine che rappresenti la piattaforma di origine da cui eseguirai la migrazione. Questa origine verrà aggiunta al tuo piano di migrazione. Puoi utilizzare le origini di migrazione configurate in precedenza in Migrate to Containers (Migrazione ai container) per la migrazione di altre VM Linux o Windows.

Definisci l'origine della migrazione da cui esegui la migrazione utilizzando il comando migctl source create:

1. Per un cluster di elaborazione di cui è stato eseguito il deployment su Google Cloud, crea l'origine:

   1. Quando utilizzi Compute Engine come origine della migrazione:

      1. Crea un account di servizio per l'utilizzo di Compute Engine come origine della migrazione e scarica il file della chiave JSON, come descritto in Configurazione di un account di servizio.

         Nota: le seguenti istruzioni presuppongono che il nome del file della chiave JSON sia m4a-ce-src.json.

      2. Crea la sorgente utilizzando l'account di servizio:

         migctl source create ce my-was-src --project my-project --json-key m4a-ce-src.json

         Dove m4a-ce-src.json specifica l'account di servizio.

   2. Quando utilizzi AWS come origine della migrazione:

      migctl source create aws my-was-src --manager-address 1.2.3.4 --cloud-details cloud-details --cloud-extension cloud-extension

      Specifica il nome dell'estensione Migrate for Compute Engine e del nome Cloud Details, come configurato in Migrate for Compute Engine. Per maggiori dettagli su Cloud, vedi Configurare Migrate for Compute Engine.

      Ti verrà chiesta la password per il server di gestione Migrate for Compute Engine.

   3. Quando utilizzi Azure come origine della migrazione:

      migctl source create azure my-was-src --manager-address 1.2.3.4 --cloud-details cloud-details --cloud-extension cloud-extension

      Specifica il nome dell'estensione Migrate for Compute Engine e del nome Cloud Details, come configurato in Migrate for Compute Engine. Per maggiori dettagli su Cloud, vedi Configurare Migrate for Compute Engine.

      Ti verrà chiesta la password per il server di gestione Migrate for Compute Engine.

   4. Quando utilizzi VMware come origine della migrazione:

      migctl source create vmware my-was-src --manager-address 1.2.3.4 --cloud-extension cloud-extension

      Specifica il nome dell'estensione Migrate for Compute Engine, come configurato in Migrate for Compute Engine.

      Ti verrà chiesta la password per il server di gestione Migrate for Compute Engine.

2. Per un cluster di elaborazione on-prem Anthos su VMware, crea l'origine:

   migctl source create local-vmware my-was-src --vc '1.2.3.4' --username 'admin'

   Dove:

   --vc specifica il nome DNS vCenter o l'indirizzo IP vCenter.

   --username specifica il nome utente di un utente che dispone dell'autorizzazione per accedere a vCenter. Ti verrà chiesto di inserire la password per l'utente.

3. Per un cluster di elaborazione Anthos su AWS, crea l'origine:

   migctl source create local-aws local-aws-src --region my-region --access-key-id my-access-key-id

   oppure:

   migctl source create local-aws local-aws-src --region my-region --credentials-file-path=credentials.csv

   Dove:

   --region specifica l'area geografica di Google Cloud del cluster.

   --access-key-id specifica l'ID chiave di accesso AWS per un utente che dispone dell'autorizzazione per accedere ad AWS. Ti verrà chiesto di inserire il secret per l'ID chiave di accesso. Per ulteriori informazioni, consulta Gestire le chiavi di accesso per gli utenti IAM.

   --credentials-file-path specifica il percorso di un file CSV, scaricato dalla console AWS, contenente le credenziali. Per ulteriori informazioni sulla creazione del file CSV, consulta la sezione Configurare i gruppi e i ruoli di istanza AWS IAM.

Creazione di una migrazione

Inizi la migrazione delle applicazioni creando una migrazione, che determina la creazione di un oggetto piano di migrazione. Di solito sono necessari ulteriori controlli e personalizzazione del piano generato prima di procedere con la migrazione, come descritto nella sezione Personalizzazione di un piano di migrazione.

Un oggetto di migrazione, implementato come una definizione di risorsa personalizzata (CRD) di Kubernetes, viene utilizzato per configurare e monitorare il processo di migrazione. Per ulteriori informazioni, consulta il riferimento CRD.

Quando crei una migrazione, devi specificare il flag intent in base alla natura del tuo carico di lavoro. IBM consiglia che le app WAS non contengano informazioni sullo stato, ma devono invece utilizzare repository di dati esterni per contenere le informazioni sullo stato. Il valore Image indica che stai eseguendo la migrazione dei programmi binari e della configurazione delle app stateless ed è l'unico intent supportato per le app WAS tradizionali. Per saperne di più, consulta Impostare l'intent di migrazione.

Per creare una migrazione:

1. Se utilizzi Compute Engine come origine della migrazione, interrompi la VM di origine prima di creare una migrazione. Dopo aver creato l'oggetto migrazione, puoi riavviare la VM.

2. Crea la migrazione:

   migctl migration create my-migration --source my-was-src --vm-id my-id --intent Image --os-type Linux --app-type websphere-traditional

   Dove my-was-src specifica l'origine della migrazione che hai creato in precedenza e --vm-id specifica il nome della VM tradizionale WAS.

3. Conoscere lo stato della migrazione:

   migctl migration status my-migration -v

   Nota: se viene visualizzato un messaggio di errore contenente il messaggio "WAS_HOME not found", vedi Gestire un errore con la variabile di ambiente WAS_HOME.

   Quando lo stato indica che l'operazione è stata completata, puoi procedere al passaggio successivo.

   Nota: il completamento dell'operazione può richiedere diversi minuti.

Personalizzazione di un piano di migrazione

Prima di procedere, devi esaminare il file del piano di migrazione creato durante la migrazione e personalizzarlo. Per saperne di più, vedi Personalizzare un piano di migrazione.

Puoi anche esaminare il rapporto sulla migrazione delle applicazioni generato dal toolkit di migrazione del server delle applicazioni di WebSphere IBM per le applicazioni binarie. Il toolkit genera un report HTML per ogni app nella VM di origine. Visualizza il file HTML per valutare la migrazione delle app.

Per esaminare il rapporto sulla migrazione delle applicazioni:

1. Apri il browser Cloud Storage in Google Cloud Console:

   Apri il browser Cloud Storage

2. Vai alla cartella /discovery nel bucket di artefatti di migrazione su Google Cloud Storage.

3. Per ogni app rilevata nella VM, vedrai un file HTML denominato:

   app-name.ear_MigrationReport.html

4. Seleziona il file HTML per visualizzarlo o scaricarlo localmente per valutare la migrazione.

Per personalizzare il piano di migrazione:

Per personalizzare il piano di migrazione, scaricalo, modificalo, quindi aggiornalo utilizzando migctl. Il piano di migrazione è rappresentato dal CRD di WebSphereGenerateArtifactsFlow:

1. Scarica il piano di migrazione. Il piano di migrazione è rappresentato da un oggetto WebSphereGenerateArtifactsFlow:

   migctl migration get my-migration

2. Poiché stai per modificare questo file, prima crea una copia in modo da poterla recuperare:

   cp my-migration.yaml my-migration-original.yaml

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

   1. Assicurati di avere una sola proprietà path.

      L'oggetto WebSphereGenerateArtifactsFlow contiene una proprietà path per ogni app che esegue la migrazione ai container rilevata nella VM tradizionale di WAS. Elimina tutte le definizioni path tranne una e le specifiche di sharedLibraries, in modo che venga specificata un'unica app. Questa modifica assicura che ogni app abbia la propria immagine container.

      Nota: assicurati di salvare prima una copia dell'oggetto WebSphereGenerateArtifactsFlow originale per poter eseguire la migrazione di tutte le altre app nella VM in un secondo momento.

      L'oggetto WebSphereGenerateArtifactsFlow elenca tutte le app nel formato:

      spec:
      appBinariesMigrationToolkit:
        applications:
        -  path: "PATH_TO_APP1"
          sharedLibraries:
          - sharedLibrary1
            sharedLibrary2
        -  path: "PATH_TO_APP2"
          sharedLibraries:
          - sharedLibrary1
        -  path: "PATH_TO_APP3" 

   2. Assicurati che il valore app_name sia univoco per ogni app.

      Il campo deployment specifica il nome dell'applicazione utilizzata nel file deployment_spec.yaml. Imposta questo campo su un valore univoco per ogni app nel CRD. Devi assicurarti di eseguire il deployment di ogni container di app con un proprio nome app univoco.

      deployment:
       appName: app-name

   3. Imposta il nome tag dell'immagine.

      Il valore del campo image definisce il nome e la posizione delle immagini create da una VM di cui è stata eseguita la migrazione. Per impostazione predefinita, al valore "image_name" viene applicato automaticamente un tag corrispondente al timestamp della migrazione. Il formato di questo tag è:

      MM-DD-YYYY--hh:mm:ss

      Puoi utilizzare il timestamp per differenziare le migrazioni. In alternativa, puoi applicare il tuo tag. Ad esempio, modifica il CRD e aggiungi il tag rev1 come mostrato di seguito:

      name: "image_name:rev1"

      Nota: poiché il tag viene utilizzato per memorizzare i valori nella cache, assicurati che sia unico per tutti gli CRD.

   4. Imposta eventuali altre proprietà da personalizzare.

   5. Salva il file.

4. Al termine delle modifiche, carica il piano di migrazione modificato:

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

Ora puoi eseguire la migrazione dell'app. Dopo aver completato la migrazione di un'app, modifica l'oggetto WebSphereGenerateArtifactsFlow per ogni app aggiuntiva nella VM di cui vuoi eseguire la migrazione.

Generazione ed revisione degli artefatti di migrazione in corso...

Inizia la migrazione delle VM con un comando che genera artefatti di migrazione utilizzando il cluster di elaborazione creato in Installazione di Migrate to Containers.

Per eseguire una migrazione e generare gli artefatti di migrazione:

1. Esegui la migrazione:

   migctl migration generate-artifacts my-migration

2. Conoscere lo stato della migrazione:

   migctl migration status my-migration

Quando lo stato indica che l'operazione è stata completata, esamina gli artefatti generati.

La migrazione di un'app da una VM di origine crea un insieme di file, chiamati artefatti di migrazione, utilizzati per eseguire il deployment del carico di lavoro migrato. Dopo aver completato la migrazione di un carico di lavoro, esamina gli artefatti di migrazione utilizzati per il deployment.

Gli artefatti di migrazione si trovano in un bucket Cloud Storage. Il bucket include i seguenti file:

• Dockerfile: il Dockerfile utilizzato per creare l'immagine per l'app di cui è stata eseguita la migrazione.

• build.sh: lo script per creare il carico di lavoro di deployment utilizzando gcloud builds.

• deployment_spec.yaml: il file YAML utilizzato per eseguire il deployment del carico di lavoro creato da build.sh. Puoi utilizzare kubectl apply con questo file per eseguire il deployment del carico di lavoro in un cluster, ad esempio un cluster di produzione o di test. Questo file include anche eventuali mappature delle porte richieste dall'app.

• Per ogni app nella VM:

  • Un file .ear contenente il programma binario dell'applicazione.

  • Script Python .py utilizzato per creare il container dell'app.

Per visualizzare l'artefatto generato:

1. Utilizza il comando seguente per scaricare i file dell'elemento generati:

   migctl migration get-artifacts my-migration

   Questo comando scarica i seguenti file che utilizzi per il deployment dell'app di cui hai eseguito la migrazione: Dockerfile, build.sh,edeployment_spec.yaml.

   La sezione seguente, Creazione di un'immagine container dell'app, descrive come creare il container dell'app.

2. Puoi anche visualizzare e scaricare questi file da Google Cloud Console:

   1. Apri il browser Cloud Storage in Google Cloud Console:

      Apri il browser Cloud Storage

   2. Seleziona il bucket utilizzato per la migrazione.

   3. Per l'applicazione sottoposta a migrazione, vedi i file .ear e .py.

   4. Puoi anche visualizzare i file Dockerfile, build.sh e deployment_spec.yaml, insieme a tutti gli altri artefatti.

   5. Seleziona un file per visualizzarne i contenuti o scarica il file.

Crea un'immagine container dell'app

Utilizzando gli artefatti di migrazione, crea un'immagine container per l'app di cui puoi eseguire la migrazione nel cluster di destinazione. Utilizza build.sh per creare il container che viene creato come parte degli artefatti di migrazione:

1. Crea il container dell'app utilizzando lo script di build:

   chmod +x ./build.sh
   ./build.sh`

2. (Facoltativo) Imposta il tipo di servizio in deployment_spec.yaml.

   Per impostazione predefinita, Migrate to Containers imposta il tipo di servizio su ClusterIP, rendendolo disponibile solo per i pod nel cluster di deployment.

   Se vuoi poter accedere al servizio esternamente, imposta il tipo di servizio su LoadBalancer o qualsiasi altro tipo richiesto dal tuo deployment. Ad esempio:

   apiVersion: v1
   kind: Service
   …
   spec:
     …
     type: LoadBalancer

Ora puoi eseguire il deployment del container dell'app.

Deployment di un container dell'app in un cluster di destinazione

Dopo aver creato l'immagine del container dell'app, esegui il deployment dell'immagine nel cluster di destinazione.

Nota: prima di eseguire il deployment del carico di lavoro, assicurati che il cluster di destinazione abbia accesso in lettura al registro Docker. Consulta Deployment di un carico di lavoro Linux in un cluster di destinazione per ulteriori informazioni.

1. Assicurati che il cluster di destinazione soddisfi i prerequisiti descritti in Requisiti di sistema di migrazione.

2. Esegui il deployment dell'immagine container utilizzando il file deployment_spec.yaml:

   kubectl apply -f deployment_spec.yaml

3. Se hai modificato il file deployment_spec.yaml per consentire l'accesso esterno al servizio, come descritto sopra, determina l'indirizzo IP pubblico e la porta del servizio:

   kubectl get service

   Le colonne IP esterno mostrano l'indirizzo IP e la porta.

4. Apri l'indirizzo IP esterno e la porta del servizio in un browser:

   http://IP:PORT

Monitoraggio dei carichi di lavoro migrati

Per impostazione predefinita, le informazioni di log per le app di cui è stato eseguito il deployment vengono scritte in stdout dai processi avviati da init.

Puoi anche esaminare i contenuti di /var/log/syslog per informazioni sui log.

Gestire un errore con la variabile di ambiente WAS_HOME

La variabile di ambiente WAS_HOME specifica dove è installata la versione WAS tradizionale, ad esempio /opt/IBM/WebSphere/AppServer/. Migrate to Containers utilizza questo valore quando crei una migrazione per eseguire script che recuperano informazioni su un'app e per determinare il percorso di un profilo dell'app.

Migrate to Containers tenta automaticamente di individuare la cartella di installazione di WebSphere cercando i percorsi comuni in cui sono installati i programmi binari di Linux. Se Migrate to Containers non riesce a individuare la cartella di installazione o a eseguire l'override della cartella determinata dalla ricerca automatica, puoi impostare il valore WAS_HOME.

Se Migrate to Containers utilizza un valore WAS_HOME errato quando crei una migrazione, Migrate to Containers registra un errore. Questo errore viene visualizzato quando controlli lo stato della migrazione:

migctl migration status MIGRATION_NAME -v

L'errore viene visualizzato nel seguente formato:

Warning  PodFailure 2m55s (x49 over 123m) WebSphereDiscoveryTask MIGRATION_NAME
Pod reached error state. Retrying by recreating pod. Details: Container `lister` terminated: (no termination message provided).
Container `aggregator` terminated: (no termination message provided).
Container `websphere-discoverer` terminated:
{"code": "DIS-11", "reason": "WAS_HOME not found", "description": "WAS_HOME installation directory was not found"}.

Per impostare esplicitamente il valore di WAS_HOME:

• Se utilizzi migctl per creare la migrazione, trasmetti il valore WAS_HOME durante la creazione della migrazione:

  migctl  migration create  MIGRATION_NAME \
   --source SOURCE_NAME --vm-id VM_ID --app-type websphere-traditional \
   --parameters WAS_HOME_paths=/FOLDER_PATH/

• Se utilizzi file CRD per eseguire la migrazione, modifica il file yaml di migrazione per impostare il percorso:

  apiVersion: anthos-migrate.cloud.google.com/v1beta2
  kind: Migration
  metadata:
  name: my-migration
  namespace: v2k-system
  annotations:
    anthos-migrate.cloud.google.com/initial-intent: Image
  spec:
  osType: Linux
  parameters:
  - name: WAS_HOME_paths
    value: /FOLDER_PATH/
  sourceSnapshot:
  sourceProvider: my-ce-src
  sourceId: my-id

  Quindi, esegui di nuovo l'operazione di creazione della migrazione.