Migrar configuraciones de Cloud Foundry a Cloud Run

Debe completar el proceso de migración de la configuración de cada aplicación de Cloud Foundry que quiera migrar a Cloud Run. La migración de la configuración consta de lo siguiente:

  • Convertir un manifest.yaml de Cloud Foundry en un service.yaml de Cloud Run.
  • Adjuntar servicios de respaldo a la aplicación para desplegarla en Cloud Run.
  • Desplegar la aplicación en un servicio de Cloud Run.

Convertir manifest.yaml a service.yaml

Debes convertir un manifiesto de Cloud Foundry o las cf marcas de la CLI en el archivo YAML de definición de servicio de Cloud Run equivalente.

Cloud Run requiere que cada aplicación tenga su propio archivo YAML de servicio independiente. Para migrar una aplicación de tu manifiesto de Cloud Foundry a un archivo YAML de servicio, sigue estos pasos:

  1. Recoge las propiedades que se indican en la siguiente tabla para tu aplicación. Es posible que las propiedades que no se hayan modificado a nivel de aplicación se hayan anulado mediante configuraciones globales de la plataforma Cloud Foundry. Consulta la documentación proporcionada por los administradores de tu plataforma para obtener los valores reales.

    Propiedad de la aplicación cf Marcas de la CLI v6 Descripción
    name NAME argumento Nombre único de la aplicación en Cloud Foundry.
    command -c Un comando que se ejecutará en /bin/sh o /bin/bash
    disk_quota -k Cantidad de espacio en disco que se asignará a la aplicación.

    Las unidades válidas son M, MB, G y r B.

    Valor predeterminado probable: 1 G

    docker.image --docker-image, -o La imagen que contiene la aplicación que se va a ejecutar.
    health-check-http-endpoint N/A Endpoint que se usa para determinar el estado de HTTP si el tipo de comprobación del estado es HTTP.

    Predeterminado: /

    health-check-invocation-timeout N/A Tiempo en segundos entre las comprobaciones del estado basadas en puertos y en HTTP.

    Valor predeterminado: 1

    health-check-type --health-check-type, -u Tipo de comprobación del estado que se va a realizar en la aplicación. Los valores válidos son port, http, none y process.

    Predeterminado: port

    instances -i Número de instancias de la aplicación que ejecutará Cloud Foundry.

    Valor predeterminado: 1

    memory -m Límite de memoria por instancia de la aplicación.

    Las unidades válidas son M, MB, G o GB.

    Valor predeterminado probable: 1 G

    timeout -t Número de segundos permitidos entre el inicio de la aplicación y la primera comprobación del estado correcta.

    Valor predeterminado probable: 60

  2. Recoge la siguiente información sobre tu proyecto de Google Cloud y la configuración de Cloud Run:

    Propiedad Descripción
    project_number El número de proyecto de Google Cloud en el que quieras hacer el despliegue.
    region La región en la que quieras implementar tu aplicación.
    vpc-access-connector El nombre del conector de VPC en el que el administrador de tu plataforma quiere que estén las aplicaciones.
    vpc-access-egress El nombre de salida de VPC que el administrador de tu plataforma quiere que tengan las aplicaciones.
    custom-audiences Audiencias personalizadas que pueden autenticarse en tu aplicación.
    serviceAccountName La identidad que usará tu aplicación en Google Cloud.
    image La imagen de la aplicación que has creado en el paso anterior.
  3. Rellena la siguiente plantilla en un archivo service.yaml en la raíz de tu proyecto.

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

Adjunta los servicios de copia de seguridad

Debes crear una variable de entorno VCAP_SERVICES para permitir la inyección y la detección de servicios por parte de tu aplicación de Cloud Foundry, como Spring o Steeltoe. Debes hacerlo con cada aplicación que migres. Consulta la documentación de VCAP_SERVICES de Cloud Foundry para obtener más información.

Si tu aplicación ya se está ejecutando en Cloud Foundry y quieres conectarla a los mismos servicios en Cloud Run, puedes usar tu variable de entorno. De lo contrario, tendrás que crear un nuevo VCAP_SERVICES.

Para configurar la variable de entorno VCAP_SERVICES, sigue estos pasos:

  1. En el caso de un VCAP_SERVICES ya creado:

    1. Prueba a obtener la variable de entorno VCAP_SERVICES ejecutando cf env APP_NAME.
    2. Si eso no funciona:
      1. Conéctate a tu aplicación en Cloud Foundry: cf ssh APP_NAME
      2. Ejecuta el comando env y obtén el resultado de VCAP_SERVICES.
      3. Cierra la sesión SSH ejecutando exit.
    3. Guarda el valor VCAP_SERVICES en un archivo nuevo llamado vcap.json.
  2. Si quieres añadir servicios o conectarte a servicios diferentes a los de Cloud Foundry, crea un nuevo VCAP_SERVICES:

    1. En un editor de texto, crea un mapa JSON vacío {}.
    2. Para cada servicio que quieras añadir, haz lo siguiente:
    3. Consulta la documentación de la biblioteca que usa tu aplicación para analizar VCAP_SERVICES y el tipo que quieres añadir para saber cómo descubre el enlace.
    4. Añade una clave al mapa con el nombre del proveedor de servicios si aún no existe. Normalmente, se trata de algo como mysql, postgresql o elasticsearch. Define el valor como una matriz vacía:
    5. Añade un objeto a la matriz con las siguientes propiedades:

      1. Metadatos que no se suelen usar para descubrir o vincular servicios:

        • binding_name, una cadena que representa el recurso que concede permisos a tu aplicación en el servicio. Puede ser un nombre de usuario de una base de datos, una regla de cortafuegos, un nombre de cuenta de servicio o cualquier otra cosa.
        • instance_name, una cadena que representa el nombre del servicio de respaldo. Puede ser el nombre de tu base de datos, un valor aleatorio o un valor de centinela de un servicio global.
        • name, binding_name si existe; de lo contrario, instance_name. Este valor no suele ser importante.
        • label, el valor de la clave del mapa VCAP_SERVICES en el que se anida este enlace.
        • plan, el nombre del plan de servicio. Por ejemplo, "user-provided" o "high-availability".
      2. Valores que se suelen usar para descubrir o enlazar servicios:

        • tags Una lista de etiquetas para ayudar a las bibliotecas a encontrar servicios compatibles. Esto suele incluir el nombre común del servicio, por ejemplo, mysql para MySQL y MariaDB, redis para Redis o Cloud Memorystore, o postgres para bases de datos compatibles con PostgreSQL.
        • credentials Objeto que contiene las credenciales que usa la biblioteca del cliente para realizar la conexión. La mayoría de las bibliotecas de cliente usan un campo uri que contiene el URI estándar o el formato JDBC del servicio.
    6. Guarda el contenido como vcap.json.

Adjuntar credenciales a un recurso de Cloud Run

Para adjuntar credenciales, sigue estos pasos:

  1. Crea un secreto para almacenar el contenido de tu variable de entorno VCAP_SERVICES y anota la versión que devuelve el comando:

    gcloud secrets create APP_NAME-vcap \
      --replication-policy="automatic" \
      --data-file=vcap.json
    
  2. Concede a la cuenta de servicio de tu aplicación permiso para leer el secreto:

    gcloud secrets add-iam-policy-binding APP_NAME-vcap \
      --member="serviceaccount:app-service-account" \
      --role="roles/secretmanager.secretAccessor"
    
  3. Añade la siguiente variable de entorno a tu aplicación service.yaml en spec.template.spec.containers[0].env array :

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

Plantillas para servicios de asistencia comunes

En las siguientes secciones se ofrece información sobre los servicios de respaldo que se suelen usar.

MySQL

Las bibliotecas de MySQL suelen esperar la etiqueta mysql. Es habitual incluir las siguientes claves en credentials:

  • Plantilla uri: mysql://username:password@host:port/dbname. La documentación de MySQL puede ayudarte a crear una cadena URI. El puerto suele ser 3306.
  • username Nombre de usuario de la conexión, necesario para algunas bibliotecas aunque se incluya en uri
  • password La contraseña de conexión, que algunas bibliotecas requieren aunque se incluya en uri

Redis

Las bibliotecas de Redis suelen esperar la etiqueta redis. Es habitual incluir las siguientes claves en credentials:

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

La documentación de URIs de Redis de IANA puede ayudarte a crear una cadena de URI. El puerto suele ser 6379.

RabbitMQ

Las bibliotecas de RabbitMQ suelen esperar la etiqueta rabbitmq y las siguientes claves en credentials:

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

La documentación de RabbitMQ puede ayudarte a crear una cadena URI. El puerto suele ser 5672.

Servicios proporcionados por los usuarios

Los servicios proporcionados por el usuario son un tipo especial de servicio en Cloud Foundry que te permite insertar cualquier credencial. La etiqueta siempre es user-provided. Las etiquetas son los valores que se transfieren a cf create-user-provided-service mediante la marca -t, y las credenciales son el contenido de la marca -p.

Desplegar una aplicación

Para desplegar la aplicación de Cloud Foundry totalmente migrada en un servicio de Cloud Run, sigue estos pasos:

  1. Si aún no lo has hecho, configura tu entorno de Cloud Run.

  2. Ejecuta el comando

    gcloud run services replace service.yaml
    

    Espera unos instantes hasta que se complete el despliegue. Si la acción se realiza correctamente, la línea de comandos mostrará la URL del servicio.

  3. Visita el servicio implementado abriendo la URL del servicio en un navegador web.

¡Enhorabuena! Acabas de migrar tu aplicación de Cloud Foundry a Cloud Run