Comando CLI di esempio

ibmcloud resource service-instance-update "Event Streams resource instance name" -p '{"mirroring":{"source_crn":"<source_crn>", "source_alias":"<source_alias>", "target_alias":"<target_alias>"}}'

Selezionare gli argomenti da rispecchiare

Una volta completato l'aggiornamento dell'istanza di servizio, è necessario selezionare quali argomenti saranno sottoposti a mirroring dall'origine al cluster di destinazione. Questo viene fatto con la CLI usando il comando 'ibmcloud es mirroring-topic-selection-set'. Tutti i gruppi di consumatori utilizzati per consumare da questi argomenti selezionati verranno riprodotti in mirroring dal cluster di origine a quello di destinazione. La selezione dell'argomento è sotto forma di un modello regex o di un elenco separato da virgole di tali modelli.

Il seguente comando seleziona tutti gli argomenti da sottoporre a mirroring:

ibmcloud es mirroring-topic-selection-set --select '.*'

È possibile selezionare gli argomenti elencando gli argomenti che si desidera rispecchiare come segue:

ibmcloud es mirroring-topic-selection-set --select topic1,topic2,topic3

Per ulteriori informazioni su come effettuare la selezione, consultare Mirroring dei controlli utente.

Una volta completata la selezione dell'argomento, il cluster di destinazione mostra gli argomenti selezionati per il mirroring mediante i controlli utente di mirroring con suffisso dell'alias del cluster di origine.

Passo 3.1: Specificare come vengono trasformati i nomi degli argomenti e dei gruppi

È possibile specificare regole di trasformazione che consentono di eseguire il mirroring dei dati in argomenti con nomi diversi nel cluster di destinazione. I tre scenari seguenti descrivono le possibili trasformazioni e spiegano i casi d'uso per ciascuna di esse.

È possibile specificare quali argomenti o gruppi di consumatori vengono sottoposti a mirroring in qualsiasi momento una volta che il mirroring è stato attivato, tuttavia la trasformazione di argomenti o gruppi è possibile solo nel momento in cui il mirroring viene attivato. Se il mirroring è già abilitato, dovrà essere disabilitato prima di effettuare una successiva richiesta di abilitazione per specificare la trasformazione dell'argomento o del gruppo.

Scenario 1: trasformazione degli argomenti rimuovendo il vecchio prefisso o suffisso e aggiungendo un nuovo prefisso o suffisso

Configurare i seguenti quattro parametri aggiuntivi.

Il comando ibmcloud resource service-instance-update deve essere specificato tramite l'argomento della riga di comando -p. Quando si specificano queste opzioni, solo gli argomenti con i prefissi o i suffissi corrispondenti saranno ammessi al mirroring. Ad esempio, se si dispone di un remove_prefix di app1- e si specifica una selezione di argomenti di abc.*, verranno rispecchiati solo gli argomenti che iniziano per app1-abc.

Se si specifica il tipo di trasformazione "rinomina" e non si specificano i parametri per add_prefix o add_suffix, l'argomento specchiato nel cluster di destinazione avrà questi parametri rimossi. I modelli di argomento vengono applicati al nome dell'argomento dopo la rimozione di qualsiasi prefisso o suffisso di origine e prima dell'aggiunta di qualsiasi prefisso o suffisso.

Vedere il seguente esempio di comando CLI:

{
  "mirroring": {
    "source_crn": "crn:v1:...",
    "source_alias": "source",
    "target_alias": "target",
    "options": {
      "topic_name_transform": {
        "type": "rename",
        "rename": {
          "add_prefix": "newprefix-",
          "remove_prefix": "oldprefix-",
          "add_suffix": "-newsuffix",
          "remove_suffix": "-oldsuffix"
        }
      }
    }
  }
}

Scenario 2: Aggiunta dell'alias di origine come suffisso agli argomenti in mirroring

Applica una trasformazione del nome dell'argomento con il tipo topic_name_transform impostato su use_alias. Con questa configurazione, un argomento chiamato app1-topic nel cluster di origine sarà riflesso in un argomento chiamato app1-topic.source nel cluster di destinazione, perché l'alias di origine specificato nella configurazione è source.

Vedere il seguente esempio di comando CLI:

{
  "mirroring": {
    "source_crn": "crn:v1:...",
    "source_alias": "source",
    "target_alias": "target",
    "options": {
        "topic_name_transform": {
            "type": "use_alias"
      }
    }
  }
}

Scenario 3: Gli argomenti vengono rispecchiati con i loro nomi invariati

In questo scenario, si applica anche il sito topic_name_transform con il tipo impostato su none. Con questa configurazione, un argomento chiamato app1-topic nel cluster di origine sarà riflesso in un argomento chiamato app1-topic nel cluster di destinazione.

Vedere il seguente esempio di comando CLI:

{
  "mirroring": {
    "source_crn": "crn:v1:...",
    "source_alias": "source",
    "target_alias": "target",
    "options": {
        "topic_name_transform": {
            "type": "none"
      }
    }
  }
}

Passo 3.2: Trasformazione degli ID del gruppo di consumatori corrispondenti

Per impostazione predefinita, Mirror Maker non modifica gli ID dei gruppi di consumatori durante il mirroring sul cluster di destinazione. Tuttavia, Event Streams consente di modificare i dati degli ID gruppo, come illustrato nei due scenari seguenti. Analogamente agli argomenti, i modelli di ID gruppo vengono applicati dopo aver rimosso qualsiasi prefisso o suffisso di origine e prima di aggiungere qualsiasi prefisso o suffisso. Se si specifica il tipo di trasformazione "rinomina" e non si specificano i parametri per add_prefix o add_suffix, l'ID del gruppo in mirroring nel cluster di destinazione verrà rimosso con questi parametri.

Il comando ibmcloud resource service-instance-update deve essere specificato tramite l'argomento della riga di comando -p.

Scenario 1: Trasformare l'ID del gruppo rimuovendo il vecchio prefisso o suffisso e aggiungendo un nuovo prefisso o suffisso

Configurare i seguenti quattro parametri aggiuntivi.

Quando si specificano queste opzioni, solo gli ID di gruppo con i prefissi o i suffissi corrispondenti saranno idonei per il mirroring. Ad esempio, se si ha un remove_prefix di aaa e un add_prefix di bbb, i gruppi di consumatori che iniziano con aaa-group-id nel cluster di origine saranno rispecchiati in bbb-group-id nel cluster di destinazione.

Vedere il seguente esempio di comando CLI:

{
  "group_id_transform": {
    "type": "rename",
    "rename": {
       "add_prefix": "newprefix-",
       "remove_prefix": "oldprefix-",
       "add_suffix": "-newsuffix",
       "remove_suffix": "-oldsuffix"
    }
  }
}

Scenario 2: Gli ID dei gruppi di consumatori vengono rispecchiati con i loro nomi invariati

In questo scenario, si applica anche il sito topic_name_transform con il tipo impostato su none. Con questa configurazione, un argomento chiamato aaa-group-id nel cluster di origine sarà riflesso in un argomento chiamato aaa-group-id nel cluster di destinazione.

Vedere il seguente esempio di comando CLI:

"group_id_transform": {
  "type": "none"
}

Attenzione

Prima di sincronizzare gli schemi utilizzando il mirroring, è necessario prendere in considerazione le seguenti precauzioni:

1. È necessaria una finestra di manutenzione mentre gli schemi vengono esportati/importati in blocco tra i due registri: si tratta di un periodo di poche ore o meno.
2. Affinché la rinominazione degli argomenti funzioni, gli schemi devono utilizzare Confluent Avro Serdes, in modo che l'argomento possa essere derivato dal nome dell'argomento. Confluent Avro Serdes perché l'argomento associato a uno schema può essere derivato dal nome dell'argomento (ad esempio, per le strategie di denominazione degli argomenti e degli argomenti/registro).
3. Il mirroring dell'autorizzazione S2S deve essere ininterrotto; la disabilitazione dell'autorizzazione s2s o del mirroring impedirà l'inoltro delle richieste del registro dello schema.
4. Se è richiesta la trasformazione, il registro degli schemi dell'istanza di destinazione deve essere configurato con regole di ridenominazione degli argomenti prima di effettuare la migrazione.
5. Le regole di ridenominazione non possono essere modificate fino al completamento della migrazione. Le modifiche apportate durante la migrazione causano incoerenze tra i registri.

Istruzioni

Le seguenti istruzioni illustrano come utilizzare il mirroring del registro degli schemi per spostare gli schemi tra due istanze.

L'utilità di esportazione non è ancora stata aggiunta alla CLI.

ibmcloud resource service-instance-update \
"trgt-instance-name" \
-p '{
"mirroring": {
"source_crn": "<src instance crn>",
"source_alias": "source",
"target_alias": "target",
"schemas": "proxied"
}
}'

Trasformazione del nome dell'argomento

I nomi degli argomenti possono essere trasformati durante l'inoltro. Ad esempio, con le giuste regole,old-my-topic potrebbe diventare new-my-topic. Quando è abilitata, l'istanza di origine riconosce solo il nome originale, mentre l'istanza di destinazione riconosce solo il nuovo nome dell'argomento (trasformato). Tutti i risultati restituiti vengono trasformati di conseguenza.

Se non vengono fornite regole di trasformazione, viene utilizzato use_alias, in linea con il comportamento di mirroring esistente in Event Streams. Per inoltrare senza cambiare i nomi degli argomenti, usare topic_name_transform tipo none. La trasformazione viene configurata utilizzando i campi di trasformazione esistenti della CLI.

Flusso migratorio

Quando si esegue la migrazione tra due istanze di Event Streams, si suggerisce il seguente flusso.

1. Abilitare il mirroring tra due istanze, specificando schemas: proxied.
2. Aggiornare le applicazioni per utilizzare il registro dello schema di destinazione.
3. Bloccare qualsiasi scrittura nel registro di destinazione passando a schemas: read-only. Prima di effettuare questa modifica, il mirroring deve essere momentaneamente disattivato.
4. Esporta tutti gli schemi dell'istanza di origine.
5. Importa tutti gli schemi esportati dall'istanza di origine in quella di destinazione. Questo può essere fatto utilizzando la CLI di IBM Cloud®: ibmcloud [...].
6. Disattivare il mirroring.

Esportazione di schemi

Per informazioni più dettagliate, consultare il sito Confluent documentazione.

La CLI di Event Streams richiede che le importazioni di schemi abbiano un valore v1 exportVersion.

1. Scaricate il codice sorgente più recente di v2.x.x, ad esempio https://github.com/Apicurio/apicurio-registry/archive/refs/tags/2.6.13.Final.zip.

2. Creare il client di esportazione: mvn -pl utils/exportConfluent -am -DskipTests -Pprod package.

3. Eseguire l'esportatore (salva l'output su confluent-schema-registry-export.zip ):

   java -jar utils/exportConfluent/target/apicurio-registry-utils-exportConfluent-2.6.13.Final.jar \
   "https://token:<password>@<my-event-streams-instance.com>/confluent" \
   --client-props basic.auth.credentials.source=URL
   

Importazione di schemi

Gli schemi possono essere importati tramite la CLI di Event Streams.

1. Assicurarsi di aver installato il plugin event-streams[es]: ibmcloud plugin list.

2. Accedi a IBM Cloud®: ibmcloud login [...].

3. Inizializzare l'istanza di Event Streams in cui si desidera importare: ibmcloud es init.

4. Importare lo schema:

   ibmcloud es schema-import \
   -f confluent-schema-registry-export.zip