Esegui la migrazione delle configurazioni a Cloud Run

Devi completare la procedura di migrazione della configurazione per ogni applicazione Cloud Foundry di cui stai eseguendo la migrazione a Cloud Run. La migrazione della configurazione è composta seguenti:

  • Conversione di un servizio Cloud Foundry manifest.yaml in un servizio Cloud Runservice.yaml.
  • Collega eventuali servizi di supporto all'applicazione per il deployment su Cloud Run.
  • Deployment dell'applicazione in un servizio Cloud Run.

Converti manifest.yaml in service.yaml

Devi convertire un manifest Cloud Foundry e/o i flag della CLI cf nel file YAML della definizione del servizio Cloud Run equivalente.

Cloud Run richiede che ogni applicazione abbia il proprio file YAML del servizio separato. Per eseguire la migrazione di un'applicazione del tuo manifest di Cloud Foundry a un YAML del servizio:

  1. Raccogliere le proprietà elencate nella tabella seguente per la tua applicazione. Le proprietà che non vengono modificate a livello di applicazione potrebbero essere state sostituite dalle configurazioni globali della piattaforma Cloud Foundry. Per conoscere i valori effettivi, consulta la documentazione fornita dagli amministratori della piattaforma.

    Proprietà applicazione Flag cf CLI v6 Descrizione
    name argomento NAME Il nome univoco dell'applicazione in Cloud Foundry.
    command -c Un comando che verrà eseguito in /bin/sh o /bin/bash
    disk_quota -k La quantità di spazio su disco che verrà assegnata all'applicazione.

    Le unità valide sono: M, MB, G e r B

    Valore predefinito probabile: 1 G

    docker.image --docker-image, -o L'immagine che contiene l'applicazione da eseguire.
    health-check-http-endpoint N/D L'endpoint utilizzato per determinare l'integrità HTTP se il tipo di controllo di integrità è HTTP.

    Predefinita: /

    health-check-invocation-timeout N/D Tempo in secondi tra una singola porta e i controlli di integrità basati su HTTP.

    Valore predefinito: 1

    health-check-type --health-check-type, -u Tipo di controllo di integrità da eseguire sull'applicazione. I valori validi sono: port, http, none, process.

    Predefinita: port

    instances -i Numero di istanze dell'app che verranno eseguite da Cloud Foundry.

    Valore predefinito: 1

    memory -m Il limite di memoria per istanza dell'applicazione.

    Le unità valide sono: M, MB, G o GB

    Possibile impostazione predefinita: 1G

    timeout -t Numero di secondi consentiti tra l'avvio dell'app e il primo controllo di integrità.

    Possibile impostazione predefinita: 60

  2. Raccogli le seguenti informazioni per il tuo progetto Google Cloud e la configurazione di Cloud Run:

    Proprietà Descrizione
    project_number Il numero del progetto Google Cloud in cui vuoi eseguire il deployment.
    region La regione in cui vuoi eseguire il deployment dell'app.
    vpc-access-connector Il nome del connettore VPC su cui l'amministratore della piattaforma vuole installare le applicazioni.
    vpc-access-egress Il nome dell'egress VPC su cui l'amministratore della piattaforma vuole installare le applicazioni.
    custom-audiences Segmenti di pubblico personalizzati che possono autenticarsi nella tua applicazione.
    serviceAccountName L'identità con cui la tua applicazione opererà in Google Cloud.
    image L'immagine dell'applicazione creata nel passaggio precedente.
  3. Compila il seguente modello in un file service.yaml alla radice di il tuo progetto

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

Collega eventuali servizi di supporto

Devi creare una variabile di ambiente VCAP_SERVICES per consentire l'iniezione e il rilevamento dei servizi da parte dell'applicazione Cloud Foundry, ad esempio Spring o Steeltoe. Devi eseguire questa operazione per ogni applicazione di cui esegui la migrazione. Consulta la documentazione per VCAP_Services di Cloud Foundry per ulteriori informazioni.

Se la tua applicazione è già in esecuzione in Cloud Foundry e vuoi collegarti agli stessi servizi in Cloud Run, puoi utilizzare la variabile di ambiente esistente. In caso contrario, dovrai creare un nuovo VCAP_SERVICES.

Per configurare la variabile di ambiente VCAP_SERVICES:

  1. Per un VCAP_SERVICES esistente:

    1. Prova a recuperare la variabile di ambiente VCAP_SERVICES eseguendo cf env APP_NAME.
    2. Se il problema persiste:
      1. Connettiti all'applicazione in Cloud Foundry: cf ssh APP_NAME
      2. Esegui il comando env e ottieni l'output di VCAP_SERVICES.
      3. Esci dalla sessione SSH eseguendo exit.
    3. Salva il valore VCAP_SERVICES in un nuovo file denominato vcap.json.
  2. Se vuoi aggiungere servizi o connetterti a servizi diversi da quelli di Cloud Foundry, crea un nuovo VCAP_SERVICES:

    1. In un editor di testo, crea una mappa JSON vuota {}
    2. Per ogni servizio che vuoi aggiungere:
    3. Consulta la documentazione relativa alla libreria utilizzata dalla tua app per analizzare VCAP_SERVICES per il tipo che vuoi aggiungere per capire come rileva l'associazione.
    4. Aggiungi alla mappa una chiave con il nome del fornitore di servizi, se non è presente esistono già, di solito sono simili a mysql, postgresql o elasticsearch. Imposta il valore su un array vuoto:
    5. Aggiungi un oggetto all'array con le seguenti proprietà:

      1. Metadati che in genere non vengono utilizzati per rilevare/legare i servizi:

        • binding_name, una stringa che rappresenta la risorsa che concede le autorizzazioni dell'applicazione nel servizio. Può essere un nome utente per un database, una regola del firewall, un nome di account di servizio o qualcos'altro.
        • instance_name, una stringa che rappresenta il nome del servizio di supporto. Potrebbe essere il nome del database, un valore casuale o un valore sentinella per un servizio globale.
        • name, binding_name se esistente, altrimenti instance_name. In genere questo valore non è importante.
        • label, il valore della chiave nella mappa VCAP_SERVICES in cui è nidificata questa associazione.
        • plan, il nome del piano di servizio. Alcuni esempi sono: "fornito dall'utente", "alta disponibilità".
      2. Valori spesso utilizzati per rilevare/legare i servizi:

        • tags Un elenco di tag per aiutare le biblioteche a trovare servizi compatibili. Spesso include il nome comune del servizio, ad esempio mysql per MySQL e MariaDB, redis per Redis o Cloud Memorystore o postgres per i database compatibili con Postgres.
        • credentials Un oggetto contenente le credenziali utilizzate dalla libreria client per eseguire la connessione. La maggior parte delle librerie client si basa su un campouri che contiene il formato JDBC o URI standard del servizio.
    6. Salva i contenuti come vcap.json.

Collega le credenziali alla risorsa Cloud Run

Per allegare le credenziali:

  1. Crea un segreto per contenere i contenuti della variabile di ambienteVCAP_SERVICES e prendi nota della versione indicata dal comando:

    gcloud secrets create APP_NAME-vcap \
      --replication-policy="automatic" \
      --data-file=vcap.json
    
  2. Concedi all'account di servizio della tua applicazione l'autorizzazione a leggere il secret:

    gcloud secrets add-iam-policy-binding APP_NAME-vcap \
      --member="serviceaccount:app-service-account" \
      --role="roles/secretmanager.secretAccessor"
    
  3. Aggiungi la seguente variabile di ambiente all'applicazione service.yaml nel spec.template.spec.containers[0].env array :

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

Modelli per i servizi di supporto più comuni

Le seguenti sezioni forniscono informazioni sui servizi di supporto di uso comune

MySQL

In genere, le librerie MySQL prevedono il tag mysql. È comune includere le seguenti chiavi in credentials:

  • uri modello: mysql://username:password@host:port/dbname. La documentazione di MySQL può aiutarti a creare una stringa URI. In genere la porta è 3306.
  • username Il nome utente della connessione, obbligatorio per alcune librerie anche se incluso in uri
  • password La password di connessione, richiesta da alcune librerie anche se inclusa in uri

Redis

In genere, le librerie Redis prevedono il tag redis. È comune includere le seguenti chiavi in credentials:

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

La documentazione degli URI IANA Redis può aiutarti a creare una stringa URI. In genere la porta è 6379.

RabbitMQ

In genere le librerie RabbitMQ prevedono il tag rabbitmq e le seguenti chiavi in credentials:

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

La documentazione di RabbitMQ può aiutarti a creare una stringa URI. In genere la porta è 5672.

Servizi forniti dall'utente

I servizi forniti dall'utente sono un tipo speciale di servizio in Cloud Foundry che consente di inserire qualsiasi credenziale. L'etichetta è sempre user-provided. I tag sono i valori passati a cf create-user-provided-service tramite il flag -t e le credenziali sono i contenuti del flag -p.

Deployment dell'applicazione

Per eseguire il deployment dell'applicazione Cloud Foundry completamente migrata in un ambiente Cloud Run servizio:

  1. Se non l'hai ancora fatto, configura il tuo ambiente Cloud Run.

  2. Esegui il comando

    gcloud run services replace service.yaml
    

    Attendi qualche istante fino al completamento del deployment. Se l'operazione riesce, il comando mostra l'URL del servizio.

  3. Visita il servizio di cui hai eseguito il deployment aprendo l'URL del servizio in un browser web.

Complimenti! Hai appena eseguito la migrazione dell'applicazione Cloud Foundry a Cloud Run