Konfigurationen zu Cloud Run migrieren

Wichtig: Sie benötigen Zugriff auf die Build-Konfiguration und den Quellcode für die Anwendung, die Sie migrieren möchten.

Sie müssen den Prozess der Konfigurationsmigration für jede Cloud Foundry-Anwendung ausführen, die Sie zu Cloud Run migrieren. Die Konfigurationsmigration umfasst Folgendes:

• Konvertierung eines Cloud Foundry-manifest.yaml in einen Cloud Run-service.yaml.
• Anhängen aller Sicherungsdienste an die Anwendung für das Deployment in Cloud Run.
• Anwendung in einem Cloud Run-Dienst bereitstellen

manifest.yaml in service.yaml konvertieren

Sie müssen ein Cloud Foundry-Manifest und/oder cf-CLI-Flags in die entsprechende Cloud Run-Dienstdefinitions-YAML konvertieren.

Cloud Run erfordert, dass jede Anwendung eine eigene YAML-Dienstdatei hat. So migrieren Sie eine Anwendung in Ihrem Cloud Foundry-Manifest zu einer YAML-Dienstdatei:

1. Erfassen Sie die in der folgenden Tabelle aufgeführten Attribute für Ihre Anwendung. Attribute, die nicht auf Anwendungsebene geändert wurden, wurden möglicherweise von globalen Cloud Foundry-Plattformkonfigurationen überschrieben. Die tatsächlichen Werte finden Sie in der Dokumentation Ihrer Plattformadministratoren.

   Anwendungsattribut	V6-Flags der cf-Befehlszeile	Beschreibung
   name	NAME-Argument	Der eindeutige Name der Anwendung in Cloud Foundry.
   command	-c	Ein Befehl, der in /bin/sh oder /bin/bash ausgeführt wird
   disk_quota	-k	Die Menge des Laufwerks, das der Anwendung zugewiesen wird. Gültige Einheiten sind M, MB, G und r B. Wahrscheinlichste Standardeinstellung: 1G
   docker.image	--docker-image, -o	Das Image, das die auszuführende Anwendung enthält.
   health-check-http-endpoint	–	Der Endpunkt, der zum Ermitteln des HTTP-Status verwendet wird, wenn der Systemdiagnosetyp HTTP ist. Standard: /
   health-check-invocation-timeout	–	Zeit in Sekunden zwischen einzelnen Port- und HTTP-basierten Systemdiagnosen. Standard: 1
   health-check-type	--health-check-type, -u	Art der Systemdiagnose, die für die Anwendung durchgeführt werden soll. Gültige Werte sind port, http, none und process. Standard: port
   instances	-i	Anzahl der Instanzen der Anwendung, die von Cloud Foundry ausgeführt werden. Standard: 1
   memory	-m	Das instanzspezifische Speicherlimit für die Anwendung. Gültige Einheiten sind M, MB, G oder GB. Wahrscheinlichste Standardeinstellung: 1G
   timeout	-t	Anzahl der Sekunden, die zwischen dem Start der App und der ersten fehlerfreien Systemdiagnose erlaubt sind. Wahrscheinliche Standardeinstellung: 60

2. Erfassen Sie die folgenden Informationen für Ihr Google Cloud-Projekt und die Cloud Run-Einrichtung:

   Attribut	Beschreibung
   project_number	Die Projektnummer des Google Cloud-Projekts, für das Sie die Bereitstellung vornehmen möchten.
   region	Die Region, in der Sie die Anwendung bereitstellen möchten.
   vpc-access-connector	Der Name des VPC-Connectors, auf dem Ihr Plattformadministrator Anwendungen möchte.
   vpc-access-egress	Der Name des ausgehenden VPC-Netzwerks, in dem Ihr Plattformadministrator Anwendungen verwenden möchte.
   custom-audiences	Benutzerdefinierte Zielgruppen, die sich bei Ihrer Anwendung authentifizieren können.
   serviceAccountName	Die Identität, in der sich Ihre Anwendung in Google Cloud verhält.
   image	Das Anwendungs-Image, das Sie im vorherigen Schritt erstellt haben.

3. Füllen Sie die folgende Vorlage in eine service.yaml-Datei im Stammverzeichnis Ihres Projekts aus

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  # Set this to be the name of your app
  name: "APP_NAME"
  # Set this to be the project number of the project you're deploying to.
  namespace: "PROJECT_NUMBER"
  labels:
    # Set this to be the region you're deploying in.
    cloud.googleapis.com/location: REGION
    migrated-from: cloud-foundry
  annotations:
    run.googleapis.com/ingress: internal-and-cloud-load-balancing
spec:
  template:
    metadata:
      annotations:
        # Set to the greater of 1 or the `instances` attribute.
        autoscaling.knative.dev/minScale: '1'
        # Set to the greater of 1 or the `instances` attribute.
        autoscaling.knative.dev/maxScale: '1'
        run.googleapis.com/cpu-throttling: CPU_ALLOCATION
        run.googleapis.com/startup-cpu-boost: 'true'
        # Set to true if you rely on sticky sessions. These will be turned
        # on in Cloud Foundry if the server sends a JSESSIONID cookie back
        # on responses.
        run.googleapis.com/sessionAffinity: 'false'
        run.googleapis.com/execution-environment: gen2
        # Set the following values to match what your platform administrator recommends.
        run.googleapis.com/vpc-access-connector: ADMINISTRATOR_PROVIDED
        run.googleapis.com/vpc-access-egress: ADMINISTRATOR_PROVIDED
        run.googleapis.com/custom-audiences: ADMINISTRATOR_PROVIDED
    spec:
      # CF doesn't limit, but CR has a max of 1000.
      containerConcurrency: 1000
      # Default value for gorouter in PCF.
      timeoutSeconds: 900
      # Set the following value to match what your platform administrator recommends.
      serviceAccountName: ADMINISTRATOR_PROVIDED
      containers:
      - name: user-container
        # Set the following value to either:
        # - The image you built for your application in the last section of the guide.
        # - The docker.image attribute of your app's configuration if it's a Docker app.
        image: IMAGE
        # Set `command` based on the following rules:
        # - If your app has no `command` attribute: null.
        # - If your app has a docker.image attribute: ['/bin/sh', '-c']
        # - Otherwise: ['/bin/bash', '-c']
        command: null
        # Set `args` based on the following rules:
        # - If your app has no `command` attribute: null.
        # - If your app has a `command` attribute: ['value of command']
        args: null
        ports:
          # Set name based on the following rules:
          # - If your app is HTTP/2 or gRPC: "h2c"
          # - Else: "http1"
        - name: HTTP1_OR_H2C
          containerPort: 8080
        env:
          # For each key/value pair in your space's running environment variable groups,
          # which can be retried by running `cf running-environment-variable-group`,
          # add the following:
        - name: KEY
          value: VALUE
          # For each key/value pair in your manifest's `env` map, add the following:
        - name: KEY
          value: VALUE
          # Populate MEMORY_LIMIT with the amount of memory supplied to this instance
          # in MiB with 'M' as a suffix.
        - name: MEMORY_LIMIT
          value: '0M'
          # Set the following values in the JSON below:
          # - `application_name` and `name` to match metadata.name in this file.
          # - `application_uris` and `uris` to be the URI you want to assign the app on the
          #    load balancer.
          # - `limits.disk` to be the amount (in MiB) of disk assigned to your app.
          #   The amount will be in the `disk_quota` attribute of the CF manifest, or a
          #   default value for your cluster, typically 1GiB.
          # - `limits.mem` to be the amount (in MiB) of memory assigned to your app.
          #   The amount will be in your `memory` attribute of the CF manifest, or a
          #   default value for your cluster, typically 1GiB.
          # - `space_name` to be the value of metadata.space in this file.
        - name: VCAP_APPLICATION
          value: |-
                  {
                    "application_id": "00000000-0000-0000-0000-000000000000",
                    "application_name": "app-name",
                    "application_uris": [],
                    "limits": {
                      "disk": 1024,
                      "mem": 256
                    },
                    "name": "app-name",
                    "process_id": "00000000-0000-0000-0000-000000000000",
                    "process_type": "web",
                    "space_name": "none",
                    "uris": []
                  }
        resources:
          limits:
            # Set memory limit to be the sum of the memory and disk assigned to your app in CF.
            #
            # Disk amount will be in the `disk_quota` attribute of the CF manifest, or a
            # default value for your cluster, typically 1GiB.
            #
            # Memory will be in your `memory` attribute of the CF manifest, or a
            # default value for your cluster, typically 1GiB.
            memory: MEMORY_LIMIT
            # Set cpu according to the following calculation:
            #
            # 1. Take the amount of memory in your `memory` attribute of the CF
            #    manifest, or a default value for your cluster, typically 1GiB.
            # 2. Divide that by the total amount of memory on the underlying BOSH VM.
            # 3. Multiply that by the total number of CPUs on the BOSH VM.
            # 4. Find the nearest valid value based on the rules in:
            #    https://cloud.google.com/run/docs/configuring/cpu#setting
            cpu: CPU_LIMIT
        # If `health-check-type` is "process" or "none", delete the startupProbe section.
        startupProbe:
          # If `health-check-type` is "port" or blank, delete the httpGet section.
          httpGet:
            # Set to be the value of `health-check-http-endpoint` or / if blank.
            path: CHECK_PATH
            port: 8080
          # If `health-check-type` is "http", delete the tcpSocket section.
          tcpSocket:
            port: 8080
          # Set to the value of `health-check-invocation-timeout` or 1
          timeoutSeconds: 1
          # Set failure threshold to be the following calculation:
          #
          # 1. Take the `timeout` from the CF manifest, use 60 if unset.
          # 2. Divide by 2.
          # 3. Round up to the nearest integer.
          failureThreshold: 1
          successThreshold: 1
          periodSeconds: 2
        # If `health-check-type` is "process" or "none", delete the livenessProbe section.
        livenessProbe:
          # If `health-check-type` is "port" or blank, delete the httpGet section.
          httpGet:
            # Set to be the value of `health-check-http-endpoint` or / if blank.
            path: CHECK_PATH
            port: 8080
          # If `health-check-type` is "http", delete the tcpSocket section.
          tcpSocket:
            port: 8080
          # Set to the value of `health-check-invocation-timeout` or 1.
          timeoutSeconds: 1
          failureThreshold: 1
          successThreshold: 1
          periodSeconds: 30
  traffic:
  - percent: 100
    latestRevision: true

Alle Sicherungsdienste anhängen

Sie müssen eine VCAP_SERVICES-Umgebungsvariable erstellen, um die Diensteinfügung und -erkennung durch Ihre Cloud Foundry-Anwendung wie Spring oder Steeltoe zu ermöglichen. Sie müssen dies für jede Anwendung tun, die Sie migrieren. Weitere Informationen finden Sie in der Dokumentation zu Cloud Foundry VCAP_SERVICES.

Wenn Ihre Anwendung bereits in Cloud Foundry ausgeführt wird und Sie dieselben Dienste in Cloud Run anhängen möchten, können Sie Ihre vorhandene Umgebungsvariable verwenden. Andernfalls müssen Sie einen neue VCAP_SERVICES-Variable erstellen.

So konfigurieren Sie die Umgebungsvariable VCAP_SERVICES:

1. Für eine vorhandene VCAP_SERVICES:

   1. Versuchen Sie, die Umgebungsvariable VCAP_SERVICES durch Ausführen von cf env APP_NAME abzurufen.
   2. Hilft das nicht weiter, gehen Sie so vor:
      1. Stellen Sie eine Verbindung zu Ihrer Anwendung in Cloud Foundry her: cf ssh APP_NAME
      2. Führen Sie den Befehl env aus und rufen Sie die Ausgabe von VCAP_SERVICES ab.
      3. Beenden Sie die SSH-Sitzung mit dem Befehl exit.
   3. Speichern Sie den Wert VCAP_SERVICES in einer neuen Datei mit dem Namen vcap.json.

2. Wenn Sie Dienste hinzufügen oder eine Verbindung zu anderen Diensten als in Cloud Foundry herstellen möchten, erstellen Sie einen neuen VCAP_SERVICES:

   1. Erstellen Sie in einem Texteditor eine leere JSON-Zuordnung {}
   2. Gehen Sie für jeden Dienst, den Sie hinzufügen möchten, so vor:
   3. In der Dokumentation der Bibliothek, die Ihre Anwendung zum Parsen von VCAP_SERVICES verwendet, finden Sie den Typ, den Sie hinzufügen möchten. Darin erfahren Sie, wie die Bindung erkannt wird.
   4. Fügen Sie der Zuordnung einen Schlüssel mit dem Namen des Dienstanbieters hinzu, falls noch keiner vorhanden ist. Dies ist in der Regel mysql, postgresql oder elasticsearch. Legen Sie den Wert als leeres Array fest:

   5. Fügen Sie dem Array ein Objekt mit den folgenden Attributen hinzu:

      1. Metadaten, die in der Regel nicht zum Erkennen/Binden von Diensten verwendet werden:

         • binding_name: Ein String, der die Ressource darstellt, die Ihrer Anwendung Berechtigungen für den Dienst gewährt. Dies kann ein Nutzername für eine Datenbank, eine Firewallregel, ein Dienstkontoname oder etwas anderes sein.
         • instance_name: Ein String, der den Namen des Sicherungsdienstes darstellt. Dies kann der Name einer Datenbank, ein zufälliger Wert oder ein Sentinel-Wert für einen globalen Dienst sein.
         • name: Der binding_name falls vorhanden, andernfalls instance_name. Dieser Wert ist in der Regel nicht wichtig.
         • label: Der Wert des Schlüssels in der VCAP_SERVICES-Zuordnung, unter der diese Bindung verschachtelt ist.
         • plan: Der Name des Dienstplans. Beispiele sind "vom Nutzer bereitgestellt", "Hochverfügbarkeit".

      2. Werte, die häufig zum Erkennen/Binden von Diensten verwendet werden:

         • tags: Eine Liste von Tags, die bei der Suche nach kompatiblen Diensten helfen. Dies ist häufig der allgemeine Name für den Dienst, z. B. mysql für MySQL und MariaDB, redis für Redis oder Cloud Memorystore oder postgres für Datenbanken, die mit Postgres kompatibel sind.
         • credentials: Ein Objekt, das die von der Clientbibliothek verwendeten Anmeldedaten zur Durchführung der Verbindung enthält. Die meisten Clientbibliotheken basieren auf dem Feld uri, das den Standard-URI oder das JDBC-Format des Dienstes enthält.

   6. Speichern Sie den Inhalt als vcap.json.

Anmeldedaten an Ihre Cloud Run-Ressource anhängen

So hängen Sie Anmeldedaten an:

1. Erstellen Sie ein Secret für den Inhalt der Umgebungsvariable VCAP_SERVICES und notieren Sie sich die Versionsausgabe des Befehls:

   gcloud secrets create APP_NAME-vcap \
     --replication-policy="automatic" \
     --data-file=vcap.json
   

2. Gewähren Sie dem Dienstkonto Ihrer Anwendung die Berechtigung zum Lesen des Secrets:

   gcloud secrets add-iam-policy-binding APP_NAME-vcap \
     --member="serviceaccount:app-service-account" \
     --role="roles/secretmanager.secretAccessor"
   

3. Fügen Sie der service.yaml Ihrer Anwendung die folgende Umgebungsvariable in spec.template.spec.containers[0].env array hinzu:

   - name: VCAP_SERVICES
     valueFrom:
       secretKeyRef:
         key: Version output by step 1
         name: APP_NAME-vcap
   

Vorlagen für allgemeine Sicherungsdienste

In den folgenden Abschnitten finden Sie Informationen zu häufig verwendeten Sicherungsdiensten.

MySQL

MySQL-Bibliotheken erwarten normalerweise das Tag mysql. Es ist üblich, die folgenden Schlüssel in credentials aufzunehmen:

• uri Vorlage: mysql://username:password@host:port/dbname. In der MySQL-Dokumentation erfahren Sie, wie Sie einen URI-String erstellen. Der Port ist normalerweise 3306.
• username: Der Verbindungsnutzername, der von einigen Bibliotheken benötigt wird, auch wenn er in uri enthalten ist.
• password: Das Verbindungspasswort, das für einige Bibliotheken benötigt wird, auch wenn es in uri enthalten ist

Redis

Redis-Bibliotheken erwarten normalerweise das Tag redis. Es ist üblich, die folgenden Schlüssel in credentials aufzunehmen:

• uri Vorlage: redis://:password@host:port/dbunumber.

In der IANA Redis-URI-Dokumentation können Sie einen URI-String erstellen. Der Port ist normalerweise 6379.

RabbitMQ

RabbitMQ-Bibliotheken erwarten in der Regel das Tag rabbitmq und die folgenden Schlüssel in credentials:

• uri Vorlage: amqp://username:password@host:port/vhost?query.

In der RabbitMQ-Dokumentation erfahren Sie, wie Sie einen URI-String erstellen. Der Port ist normalerweise 5672.

Von Nutzern bereitgestellte Dienste

Von Nutzern bereitgestellte Dienste sind eine spezielle Art von Diensten in Cloud Foundry, mit denen Sie alle Anmeldedaten einfügen können. Das Label ist immer user-provided. Die Tags sind die Werte, die über das Flag -t an cf create-user-provided-service übergeben werden, und die Anmeldedaten sind der Inhalt des Flags -p.

Anwendung bereitstellen

So stellen Sie die vollständig migrierte Cloud Foundry-Anwendung für einen Cloud Run-Dienst bereit:

1. Richten Sie Ihre Cloud Run-Umgebung ein, falls Sie dies noch nicht getan haben.

2. Führen Sie diesen Befehl aus:

   gcloud run services replace service.yaml
   

   Warten Sie dann einige Sekunden, bis die Bereitstellung abgeschlossen ist. Wenn die Bereitstellung erfolgreich war, wird in der Befehlszeile die Dienst-URL angezeigt.

3. Rufen Sie den bereitgestellten Service auf. Dazu öffnen Sie in einem Webbrowser die Dienst-URL.

Glückwunsch! Sie haben Ihre Cloud Foundry-Anwendung erfolgreich zu Cloud Run migriert.