Firebase Extensions zu einem selbst erstellten Funktions-Kit migrieren

Migrationspfad auswählen: Zu Funktionskits auf npm migrieren Zu selbst erstelltem Funktionskit migrieren

Wenn ein Publisher kein offizielles Ersatz-Kit erstellt hat, das auf npm verteilt wird, erfahren Sie in dieser Anleitung, wie Sie die Erweiterung forken und als lokales Funktions-Kit einrichten.

Bekannte Einschränkungen bei der Migration prüfen

Bevor Sie mit der Migration einer Erweiterungsinstanz beginnen, prüfen Sie, ob in Ihrer Einrichtung eine der folgenden Funktionen verwendet wird, für die eine Problemumgehung erforderlich ist oder die in Funktionskits noch nicht unterstützt werden:

  • Für benutzerdefinierte Docker-Repositories und KMS-Schlüssel ist eine manuelle Umgehung erforderlich Cloud Functions for Firebase unterstützt keine Ersatzsystemparameter zum Konfigurieren eines benutzerdefinierten Docker-Repositorys oder eines kundenverwalteten Verschlüsselungsschlüssels (KMS-Schlüssel). Wenn Ihre Erweiterung einen dieser Parameter konfiguriert, lesen Sie den FAQ-Workaround.

Hinweis

Sie müssen die Firebase-Befehlszeile einrichten und ein Firebase-Projekt initialisieren. Wenn Sie die CLI verwenden, achten Sie darauf, dass Sie die firebase-tools-Version >= 15.32.0 verwenden, die die neuen Migrations- und Funktionskit-Befehle enthält.

Erforderliche Kontoberechtigungen und ‑rollen

Je nachdem, was während der Migration von der Firebase-Befehlszeile erstellt und konfiguriert werden muss, muss das Konto, mit dem Sie sich bei Firebase und Google Cloud authentifizieren, die folgenden Rollen haben:

  • roles/firebaseextensions.editor
  • roles/cloudbuild.builds.editor
  • roles/artifactregistry.writer
  • roles/run.developer
  • roles/iam.serviceAccountUser
  • roles/iam.serviceAccountCreator
  • roles/cloudfunctions.admin (wenn Sie setIamPermissions für öffentliche Endpunkte ausführen müssen)
  • roles/secretmanager.admin (bei Verwendung von Secrets)
  • roles/serviceusage.serviceUsageAdmin (wenn Sie neue APIs aktivieren müssen)

Wir empfehlen, ein Konto zu verwenden, in dem bereits Erweiterungen installiert und Funktionen bereitgestellt wurden, da die meisten dieser Berechtigungen dann bereits erteilt wurden. Wenn für Ihr Migrationskonto weitere Rollen erforderlich sind, folgen Sie der Google Cloud-IAM-Anleitung, um sie hinzuzufügen.

Upgrade Ihrer Erweiterungsinstanz auf die neueste Version

Sie müssen Ihre Erweiterung auf die neueste Version aktualisieren, um den Unterschied zwischen Ihrer Erweiterungsinstanz und dem Ersatzkit zu minimieren. Wenn Ihre Erweiterung nicht aktualisiert wird, kann es zu erheblichen, schwerwiegenden Änderungen zwischen Ihrer Erweiterungsinstanz und dem Ersatzkit kommen. Die exportierte Konfiguration stimmt möglicherweise nicht mit den Erwartungen des Kits überein, da sich die Parameter zwischen den Versionen geändert haben.

Verwenden Sie eine der folgenden Optionen, um Ihre Erweiterung zu aktualisieren, je nachdem, wo sie installiert wurde:

  • Über die Firebase-Konsole
  • Über die Firebase-Befehlszeile mit:
    • firebase ext:update <extension-instance-id> --project <project-id> firebase deploy --only extensions --project <project-id>

Wenn Sie diesen Schritt überspringen, werden Sie von der CLI aufgefordert, die Konfiguration zu aktualisieren, wenn Sie sie exportieren und Ihre Erweiterung nicht die neueste Version hat.

Erweiterung in ein lokales Funktionskit forken

Bevor Sie eine Erweiterung in ein lokales Funktionskit konvertieren, muss sich der Quellcode der Erweiterung in Ihrem Firebase-Projekt befinden. Klonen Sie dazu das Erweiterungs-Repository von GitHub, erstellen Sie ein Verzeichnis im Stammverzeichnis Ihres Firebase-Projekts und kopieren Sie den functions/-Ordner und extension.yaml der Erweiterung hinein:

mkdir -p path/to/kit
cp -r /path/to/extension-source/functions/* path/to/kit/
cp /path/to/extension-source/extension.yaml path/to/kit/.

Folgen Sie Schritt 1 bis 8 aus dem Leitfaden zur Publisher-Migration, um den Quellcode Ihrer Erweiterung zu einer Funktion der 2. Generation zu migrieren. Fahren Sie dann mit den folgenden Schritten fort.

Lokales Kit für exportierte Funktionsregion und erweiterte Parameter unterstützen

In einem lokalen Funktionskit generiert die Firebase-Befehlszeile keine index.ts-Datei, um das Paket einzurichten und für die Verwendung migrierter Systemparameter zu konfigurieren. Wenn Sie die für Ihre Erweiterung konfigurierte Funktionsregion und erweiterte Parameter verwenden möchten, richten Sie Ihre index.ts-Datei so ein, dass das von firebase ext:export --mode functions exportierte Format in eine Umgebungsvariablen-Datei gelesen wird.

Definieren Sie in der index.ts-Datei der obersten Ebene, in der Ihre Funktionen exportiert werden, einen Parameter für FUNCTION_DEFAULT_REGION und rufen Sie setGlobalOptions mit Umgebungsvariablen der Form EXT_MIGRATED_SYSTEM_<GLOBAL_OPTION> auf, ähnlich der Vorlage index-kit-migration.ts, die von der CLI verwendet wird:

import { setGlobalOptions } from "firebase-functions";
import { MemoryOption, VpcEgressSetting, IngressSetting } from "firebase-functions/v2/options";
import { defineString } from "firebase-functions/params";

export const regionParam = defineString("FUNCTION_DEFAULT_REGION", {
  input: { text: { nonEmpty: true } },
  description: "Global default region where functions should be deployed. Can be overridden per-function.",
});

setGlobalOptions({
  region: regionParam,
  memory: (process.env.EXT_MIGRATED_SYSTEM_MEMORY as MemoryOption) ?? undefined,
  timeoutSeconds: process.env.EXT_MIGRATED_SYSTEM_TIMEOUTSECONDS
    ? Number(process.env.EXT_MIGRATED_SYSTEM_TIMEOUTSECONDS)
    : undefined,
  vpcConnectorEgressSettings:
    process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOREGRESSSETTINGS &&
    process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOREGRESSSETTINGS !== "VPC_CONNECTOR_EGRESS_SETTINGS_UNSPECIFIED"
      ? (process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOREGRESSSETTINGS as VpcEgressSetting)
      : undefined,
  vpcConnector: process.env.EXT_MIGRATED_SYSTEM_VPCCONNECTOR ?? undefined,
  maxInstances: process.env.EXT_MIGRATED_SYSTEM_MAXINSTANCES
    ? Number(process.env.EXT_MIGRATED_SYSTEM_MAXINSTANCES)
    : undefined,
  minInstances: process.env.EXT_MIGRATED_SYSTEM_MININSTANCES
    ? Number(process.env.EXT_MIGRATED_SYSTEM_MININSTANCES)
    : undefined,
  ingressSettings: (process.env.EXT_MIGRATED_SYSTEM_INGRESSSETTINGS as IngressSetting) ?? undefined,
  // Parses a comma-separated string of key:value pairs into a key-value object
  // (for example, "key1:value1,key2:value2" -> { key1: "value1", key2: "value2" }).
  labels: process.env.EXT_MIGRATED_SYSTEM_LABELS
    ? process.env.EXT_MIGRATED_SYSTEM_LABELS.split(",").reduce<Record<string, string> | undefined>(
        (acc, curr) => {
          const [key, value] = curr.split(":");
          const trimmedKey = key?.trim();
          const trimmedValue = value?.trim();
          if (!trimmedKey || !trimmedValue) {
            return acc;
          }
          acc = acc ?? {};
          acc[trimmedKey] = trimmedValue;
          return acc;
        },
        undefined,
      )
    : undefined,
});

// Re-export all functions so the Firebase CLI can deploy them
export * from "./your-functions";

Kit vor der Migration testen

Sie haben jetzt ein lokales Funktionskit, das sich bei der Bereitstellung genauso verhält wie eine Neuinstallation Ihrer Erweiterung. Im nächsten Schritt müssen Sie alle Probleme beheben, die versehentlich aufgetreten sind, bevor Sie Ihre Produktionsinstanzen der Erweiterung migrieren.

Fügen Sie Ihren Fork zuerst als lokales Kit hinzu, konfigurieren Sie ihn und stellen Sie ihn in einem Testprojekt bereit. Lokale Funktionskits müssen sich in Ihrem Firebase-Projekt befinden. Wenn sich das geklonte Erweiterungs-Repository also außerhalb Ihres Firebase-Projekts befindet, verschieben Sie es in das Projektverzeichnis. Führen Sie dann den folgenden Befehl zur Kit-Installation aus, um es als lokales Kit zu installieren:

firebase functions:kits:install --directory <path-to-your-fork> --project <test-project-id>

Dieser Befehl führt Sie durch die Auswahl einer Kit-ID, einer Instanz-ID und einer Konfiguration für Ihre erste Testinstanz. Anschließend wird Ihre firebase.json-Datei geändert, um ein lokales Kit zu registrieren, das auf Ihr geforktes Verzeichnis verweist. Die Konfigurationen für jede Instanz werden in einer .env-Datei unter function-kits/<kit-id>/config-<instance-id> gespeichert.

Stellen Sie Ihr lokales Kit in einem Testprojekt mit den entsprechenden Ressourcen bereit, um sein Verhalten zu testen. Wenn Sie bereits ein Testprojekt zum Testen Ihrer Erweiterung eingerichtet haben, führen Sie den folgenden Befehl aus:

firebase deploy --only functions:<kit-instance-id> --project <test-project-id>

Beispiel:Streamen von Cloud Firestore zu BigQuery (firestore-bigquery-export)

So prüfen Sie die Ende-zu-Ende-Synchronisierung von Cloud Firestore zu BigQuery:

  1. Erstellen Sie auf der Seite Cloud Firestore der Firebase-Konsole die Sammlung, die Sie als COLLECTION_PATH (users) festgelegt haben, falls sie noch nicht vorhanden ist.
  2. Erstellen Sie ein Dokument mit dem Namen bigquery-mirror-test, das beliebige Felder mit beliebigen Werten enthält.

  3. Fragen Sie auf der Seite BigQuery der Google Cloud-Console die Rohdaten-Changelog-Tabelle ab. Es sollte eine einzelne Zeile mit dem Protokoll der Dokumenterstellung enthalten:

    SELECT * FROM `PROJECT_ID.analytics.users_raw_changelog`

  4. Fragen Sie die letzte Ansicht ab. Diese sollte das letzte Änderungsereignis für das einzige vorhandene Dokument (bigquery-mirror-test) zurückgeben:

    SELECT * FROM `PROJECT_ID.analytics.users_raw_latest`

  5. Löschen Sie das Dokument bigquery-mirror-test in Cloud Firestore. Sie verschwindet aus der Ansicht „Letzte Änderungen“ und der Rohdaten-Changelog-Tabelle wird ein DELETE-Ereignis hinzugefügt.

    Mit dem folgenden Befehl können Sie den vollständigen Verlauf eines einzelnen Dokuments aufrufen:

    SELECT *
   FROM `PROJECT_ID.analytics.users_raw_changelog`
   WHERE document_name = "bigquery-mirror-test"
   ORDER BY timestamp ASC

Unterschiede zum Testen der Erweiterung:

  • Der Trigger wird als kit-<kit-instance-id>-fsexportbigquery und nicht als ext-<instanceId>-fsexportbigquery bereitgestellt. Suchen Sie im Dashboard und in den Logs von Cloud Functions nach diesem Namen.
  • Ihr Code wird in Firebase Local Emulator Suite als Standardfunktionen ausgeführt. Mit .env.local können Sie Parameterwerte festlegen, die im Emulator verwendet werden sollen. Sie können Ihren Code auch mit dem firebase-functions-test SDK testen, wie in Unittests für Cloud Functions beschrieben.
  • Die Bereitstellung wird nicht mehr von der Extensions-Laufzeit gesteuert. Wenn die Changelog-Tabelle nach der Bereitstellung fehlt, führen Sie die Einrichtungsaufgabe manuell noch einmal aus: firebase functions:lifecycle:run afterFirstDeploy <kit-instance-id>. Der Task ist idempotent. Wenn Sie ihn also noch einmal ausführen, werden das Dataset, die Tabelle und die Ansichten abgeglichen.
  • Parameterwerte stammen aus .env und nicht aus dem Installationsformular. Daher sind Wiederholungen von firebase deploy nicht interaktiv, sobald .env abgeschlossen ist.

(Optional) Testbereinigung

Wenn Sie diese Testinstanz nach dem Testen entfernen möchten, deinstallieren Sie sie:

firebase functions:kits:uninstall --instance <kit-instance-id> --project <test-project-id>

Dadurch werden alle Cloud-Ressourcen gelöscht, die durch die Bereitstellung des Kits erstellt wurden, und die zugehörige Instanzkonfiguration wird entfernt. Wenn Sie nur ein Exemplar des Kits haben, wird der Kit-Eintrag auch aus firebase.json entfernt. Ihr lokales Quellcodeverzeichnis wird dadurch nicht gelöscht. Wenn Sie das Kit für die Produktionsmigration installieren, können Sie noch einmal eine Kit-ID auswählen.

Von Erweiterungen zum lokalen Kit migrieren

Nachdem Sie Ihr lokales Kit getestet haben, können Sie Ihre live bereitgestellte Erweiterungsinstanz migrieren.

1. Ersatz-Funktions-Kit-Instanz installieren

Installieren Sie Ihr lokales Funktionskit und übergeben Sie --no-configure, um die manuelle Konfiguration zu überspringen. So kann im nächsten Schritt Ihre vorhandene Erweiterungskonfiguration direkt in diese Kit-Instanz exportiert werden:

firebase functions:kits:install --no-configure --directory <path-to-your-fork> --project <project-id>

2. Funktionskit-Instanz identisch mit der Erweiterung konfigurieren

Sie müssen diese Kit-Instanz mit einer Konfiguration anpassen, die mit der Erweiterung identisch ist, die sie ersetzt. Sie können die Konfiguration Ihrer Erweiterungsinstanz in eine .env-Datei exportieren, in der Konfigurationsdaten für Parameter, Umgebungsvariablen und geheime Verweise für alle Cloud Functions, einschließlich Kits, gespeichert werden. So exportieren Sie sie direkt in die Konfigurationsdatei Ihres Kits:

firebase ext:export --mode functions --instance <extension-instance-id> --kit-instance <kit-instance-id> --project <project-id>

Am Ende dieses Schritts werden die Konfigurationsinformationen für diese Instanz in einer projektspezifischen .env-Datei in Ihrem Instanzkonfigurationsverzeichnis gespeichert, z. B.: function-kits/<kit-name>/config-<instance-id>/.env.<project-id>

3. Kit-Ersatz bereitstellen und überprüfen

Nachdem das Kit installiert und als Funktionssatz verfügbar ist, können Sie den Kit-Ersatz bereitstellen. Funktionskits funktionieren wie Standardfunktionen. Jede Kit-Instanz dient als separate Codebasis zum Organisieren Ihrer Funktionen. Sie können alle Ihre Funktionen oder nur eine bestimmte Kit-Instanz bereitstellen. Wenn Sie eine einzelne Erweiterungsinstanz migrieren, stellen Sie nur diese Kit-Instanz bereit.

Wenn in Ihrem Kit neue Parameter verwendet werden, die in der migrierten Erweiterungsinstanz nicht vorhanden waren, werden Sie von der Firebase CLI zu Beginn des Bereitstellungsprozesses dazu aufgefordert. Das ist in diesem Beispiel mit einer aktuellen firestore-bigquery-export-Erweiterung nicht zu erwarten. Bei vielen Kits wird jedoch ein neuer Parameter für jede Ereignistriggerquelle angefordert, die vom Kit verwendet wird. Im Rahmen dieser Migration werden in aktualisierten Kits Funktionen der 2. Generation verwendet, während in Erweiterungen zuvor Funktionen der 1. Generation verwendet wurden. In der 2. Generation befinden sich Funktionen in der Nähe ihrer Ereignisquellen und werden als zusätzlicher Parameter hinzugefügt. Wenn in zukünftigen Updates neue Parameter hinzugefügt werden, werden Sie bei der nächsten Bereitstellung von der CLI dazu aufgefordert.

Beispiel:

firebase deploy --only functions:firestore-bigquery-export --project my-project

Ausgabe:

=== Deploying to 'my-project'...
i  deploying functions
i  functions: Loaded environment variables from function-kits/firestore-bigquery-export/config-firestore-bigquery-export/.env.my-project
i  functions: ensuring required API bigquery.googleapis.com is enabled...
i  functions: ensuring required API cloudtasks.googleapis.com is enabled...
✔  functions: required APIs are enabled
i  functions: granting declarative IAM roles to managed service account:
   - BigQuery Data Editor
   - BigQuery User
   - Cloud Datastore User
   - Eventarc Event Receiver
   - roles/run.invoker
✔  functions: successfully granted IAM roles
i  functions: creating Node.js 22 (2nd Gen) function kit-firestore-bigquery-export-fsexportbigquery(us-central1)...
i  functions: creating Node.js 22 (2nd Gen) function kit-firestore-bigquery-export-initBigQuerySync(us-central1)...
i  functions: creating Node.js 22 (2nd Gen) function kit-firestore-bigquery-export-setupBigQuerySync(us-central1)...
✔  functions[kit-firestore-bigquery-export-fsexportbigquery(us-central1)] Successful create operation.
✔  functions[kit-firestore-bigquery-export-initBigQuerySync(us-central1)] Successful create operation.
✔  functions[kit-firestore-bigquery-export-setupBigQuerySync(us-central1)] Successful create operation.
i  functions: Executing afterFirstDeploy lifecycle hook targeting: kit-firestore-bigquery-export-initBigQuerySync...
✔  functions: Successfully queued task for lifecycle hook kit-firestore-bigquery-export-initBigQuerySync in queue projects/my-project/locations/us-central1/queues/kit-firestore-bigquery-export-initBigQuerySync.
✔  Deploy complete!

Prüfen Sie die Bereitstellungsprotokolle, um festzustellen, ob Lebenszyklus-Hooks ausgelöst wurden und ob die firebase deploy des Kits fehlerfrei war. Beliebte Erweiterungen wie „Stream Cloud Firestore to BigQuery“ verwenden Lebenszyklus-Hooks. Das folgende Beispiel zeigt, wie ein Lebenszyklus-Hook aussieht, wenn er ausgelöst wird:

i  functions: Executing afterFirstDeploy lifecycle hook targeting: kit-firestore-bigquery-export-initBigQuerySync...
✔  functions: Successfully queued task for lifecycle hook kit-firestore-bigquery-export-initBigQuerySync in queue projects/my-project/locations/europe-west1/queues/kit-firestore-bigquery-export-initBigQuerySync.
i  functions: View logs for afterFirstDeploy at: https://console.cloud.google.com/logs/query;query=resource.type%3D%22cloud_run_revision%22%0Aresource.labels.service_name%3D%22kit-firestore-bigquery-export--initbigquerysync%22%0Aresource.labels.location%3D%22europe-west1%22;project=my-project

Diese Logmeldungen bestätigen Folgendes:

  • Ein Lifecycle-Hook wurde gefunden und ausgeführt.
  • Eine Aufgabe wurde in die zugehörige Aufgabenwarteschlange des Lebenszyklus-Hooks eingereiht.
  • Es wurde ein Link zu Cloud Logging bereitgestellt, damit Sie prüfen können, ob die Aufgabe ohne Fehler abgeschlossen wurde.

Klicken Sie auf den Link zu den Logs in der Google Cloud-Konsole, um zu prüfen, ob die Logs Fehler enthalten und ob das Ereignis in der Aufgabenwarteschlange erfolgreich verarbeitet wurde. Wenn das Lifecycle-Event nicht erfolgreich ausgeführt wurde, können Sie es mit dem folgenden Befehl noch einmal auslösen:

firebase functions:lifecycle:run <hook-name> <codebase>

Wenn Sie eine Function Kit-Instanz zum ersten Mal bereitstellen, führen Sie Folgendes aus:

firebase functions:lifecycle:run afterFirstDeploy <kit-instance-id>

Wenn Sie die Migration während der Validierung beenden oder rückgängig machen möchten, können Sie das Kit gemäß der Anleitung unter Erweiterung deinstallieren deinstallieren.

4. Erweiterung deinstallieren

Nachdem Sie Ihr bereitgestelltes Funktionskit überprüft haben, können Sie Ihre Erweiterung deinstallieren, damit das Verhalten nicht einmal für das Kit und einmal für die Erweiterung dupliziert wird. Sie können alle Erweiterungen mit der Firebase-CLI deinstallieren, unabhängig davon, wie Sie sie installiert haben, wenn Sie das Flag --immediate übergeben:

firebase ext:uninstall <extension-instance-id> --project <project-id> --immediate

Beispiel:

firebase ext:uninstall firestore-bigquery-export --project my-project --immediate

Ausgabe:

i  extensions: uninstalling firestore-bigquery-export...
i  extensions: deleting extension instance resources in project my-project...
✔  extensions: successfully uninstalled firestore-bigquery-export

Erweiterte Migrationen

Sie können Erweiterungen in mehreren Firebase-Projekten haben, die Sie mit einer einzigen Codebasis verwalten möchten. Wenn Sie beispielsweise dieselbe Infrastruktur in einer testing-Umgebung und einer production-Umgebung bereitstellen, die jeweils eine documents-Cloud Firestore-Instanz haben, die Sie nach BigQuery exportieren, haben Sie möglicherweise zwei Instanzen der Erweiterung firestore-bigquery-export installiert:

  • export-documents-testing
  • export-documents-production

Wenn Sie diese beiden Erweiterungsinstanzen in einem einzigen Codebestand in zwei Funktionskit-Instanzen migriert haben, während Sie mit der Firebase CLI gearbeitet und die Bereitstellung mit firebase deploy --project testing und firebase deploy --project production vorgenommen haben, werden bei jeder Bereitstellung zwei Instanzen in den Umgebungen testing und production erstellt.

Ersetzen Sie die beiden Erweiterungsinstanzen stattdessen durch eine Funktionskit-Instanz von firestore-bigquery-export, die in mehreren Projekten bereitgestellt wird. Jedes Projekt hat dabei seine eigene Konfiguration. Das Konfigurationsverzeichnis für die Instanz sollte so aussehen:

  • config-export-documents/
    • .env.testing
    • .env.production

Bei jeder Bereitstellung in testing und production wird eine Instanz Ihres Kits mit der entsprechenden Konfiguration erstellt. Die vorhandenen CLI-Befehle erstellen diese Einrichtung, sofern Sie das Flag --project bei jedem Aufruf von ext:migrate oder functions:kits:install übergeben.

Beispiel:

firebase functions:kits:install --package @firebase-function-kits/firestore-bigquery-export --project testing --no-configure --template migration

✔ What would you like to name this kit? firestore-bigquery-export
✔ What would you like to name this instance? export-documents
✔  Wrote function-kits/firestore-bigquery-export/source/package.json
✔  Wrote function-kits/firestore-bigquery-export/source/tsconfig.json
✔  Wrote function-kits/firestore-bigquery-export/source/.gitignore
✔  Wrote function-kits/firestore-bigquery-export/source/src/index.ts
i  functions: Running npm install
✔  Wrote configuration info to firebase.json
✔  functions: Function kit firestore-bigquery-export successfully installed.

# This creates the export-documents instance with an empty .env.testing file
# for the testing project. Now populate it via export:
firebase ext:export --mode functions --instance export-documents-testing \
  --kit-instance export-documents --project testing

# Repeat the export for production into the same kit instance to create
# .env.production from the export-documents-prod instance:
firebase ext:export --mode functions --instance export-documents-prod \
  --kit-instance export-documents --project production

Sie haben jetzt eine einzelne Kit-Instanz konfiguriert, die mit den jeweiligen Konfigurationen in Ihren Projekten testing und production bereitgestellt werden kann. Wenn Sie eine Instanz im Projekt testing erstellen und den Befehl functions:kits:install für dasselbe Paket im Projekt production ausführen, werden Sie aufgefordert, die für testing konfigurierte Instanz wiederzuverwenden oder eine zweite Instanz zu installieren.