Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud Foundry-Konfigurationen zu Cloud Run migrieren

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:

Konvertieren einer Cloud Foundry-manifest.yaml in eine Cloud Run-service.yaml.
Sicherungsdienste an die Anwendung anhängen, um sie in Cloud Run bereitzustellen.
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.

In Cloud Run muss jede Anwendung eine eigene YAML-Datei für den Dienst haben. So migrieren Sie eine Anwendung in Ihrem Cloud Foundry-Manifest zu einer YAML-Datei für Dienste:

Erfassen Sie die in der folgenden Tabelle aufgeführten Attribute für Ihre Anwendung. Attribute, die nicht auf Anwendungsebene geändert werden, wurden möglicherweise durch globale 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`	Der Speicherplatz, der der Anwendung zugewiesen wird. Gültige Einheiten sind `M`, `MB`, `G` und `r B`. Wahrscheinliche Standardeinstellung: 1 G
`docker.image`	`--docker-image`, `-o`	Das Image, das die auszuführende Anwendung enthält.
`health-check-http-endpoint`	–	Der Endpunkt, der verwendet wird, um den HTTP-Status zu ermitteln, 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`	Typ der Systemdiagnose, die für die Anwendung ausgefü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 Speicherlimit pro Instanz für die Anwendung. Gültige Einheiten sind `M`, `MB`, `G` und `GB`. Wahrscheinliche Standardeinstellung: 1 G
`timeout`	`-t`	Die Anzahl der Sekunden, die zwischen dem Start der App und der ersten erfolgreichen Systemdiagnose zulässig sind. Wahrscheinliche Standardeinstellung: 60

Sammeln 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 die Bereitstellung erfolgen soll.
`region`	Die Region, in der Sie Ihre App 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-Traffics, auf dem Ihr Plattformadministrator Anwendungen möchte.
`custom-audiences`	Benutzerdefinierte Zielgruppen, die sich für Ihre Anwendung authentifizieren können.
`serviceAccountName`	Die Identität, in der sich Ihre Anwendung in Google Cloud verhält.
`image`	Das Anwendungsbild, das Sie im vorherigen Schritt erstellt haben.

Fügen Sie die folgende Vorlage in eine service.yaml-Datei im Stammverzeichnis Ihres Projekts ein.

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

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:

Für ein vorhandenes VCAP_SERVICES:
1. Versuchen Sie, die Umgebungsvariable VCAP_SERVICES abzurufen, indem Sie cf env APP_NAME ausführen.
2. Hilft das nicht weiter, gehen Sie so vor:
  1. Verbinden Sie sich mit Ihrer Anwendung in Cloud Foundry: 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 exit.
3. Speichern Sie den Wert VCAP_SERVICES in einer neuen Datei mit dem Namen vcap.json.
Wenn Sie Dienste hinzufügen oder eine Verbindung zu anderen Diensten als in Cloud Foundry herstellen möchten, erstellen Sie eine neue 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 auf ein leeres Array fest:
5. Fügen Sie dem Array ein Objekt mit den folgenden Attributen hinzu:
  1. Metadaten, die normalerweise 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. Das 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: "vom-Nutzer-bereitgestellt", "hohe-Verfü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:

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
```

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"

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 gängige Backing-Dienste

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

MySQL

MySQL-Bibliotheken erwarten in der Regel 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

In Redis-Bibliotheken wird in der Regel das Tag redis erwartet. Häufig werden die folgenden Schlüssel in credentials verwendet:

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

In der IANA-Dokumentation zu Redis-URIs erfahren Sie, wie Sie einen URI-String erstellen. Der Port ist normalerweise 6379.

RabbitMQ

RabbitMQ-Bibliotheken erwarten normalerweise 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:

Richten Sie Ihre Cloud Run-Umgebung ein, falls noch nicht geschehen.
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.
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.