Migrar configurações para o Cloud Run

Conclua o processo de migração da configuração de cada aplicativo do Cloud Foundry que estiver migrando para o Cloud Run. A migração da configuração consiste no seguinte:

Converter um manifest.yaml do Cloud Foundry em um service.yaml do Cloud Run.
Anexar quaisquer serviços de apoio ao aplicativo para implantação no Cloud Run.
Implantar o aplicativo em um serviço do Cloud Run.

Converta de `manifest.yaml` a `service.yaml`.

É preciso converter um manifesto do Cloud Foundry e/ou flags da CLI cf no YAML equivalente do serviço do Cloud Run.

O Cloud Run exige que cada aplicativo tenha o próprio arquivo YAML de serviço separado. Para migrar um aplicativo no manifesto do Cloud Foundry para um arquivo YAML de serviço:

Reúna as propriedades listadas na tabela a seguir para seu aplicativo. As propriedades que não são modificadas no nível do aplicativo podem ter sido substituídas pelas configurações globais da plataforma do Cloud Foundry. Consulte a documentação fornecida pelos administradores da plataforma para ver os valores reais.

Propriedade do aplicativo	Sinalizações da CLI v6 `cf`	Descrição
`name`	argumento `NAME`	O nome exclusivo do aplicativo no Cloud Foundry.
`command`	`-c`	Um comando que vai ser executado em `/bin/sh` ou `/bin/bash`
`disk_quota`	`-k`	A quantidade de disco que será atribuída ao aplicativo. As unidades válidas são: `M`, `MB`, `G` , `r B` Provavelmente padrão: 1G
`docker.image`	`--docker-image`, `-o`	A imagem que contém o aplicativo a ser executado.
`health-check-http-endpoint`	N/A	O endpoint usado para determinar a integridade HTTP se o tipo de verificação de integridade for HTTP. Padrão: `/`
`health-check-invocation-timeout`	N/A	Tempo em segundos entre as verificações de integridade de porta individual e em HTTP. Padrão: 1
`health-check-type`	`--health-check-type`, `-u`	Tipo de verificação de integridade a ser executada no aplicativo. Valores válidos: `port`, `http`, `none`, `process`. Padrão: `port`
`instances`	`-i`	Número de instâncias do app que o Cloud Foundry executará. Padrão: 1
`memory`	`-m`	O limite de memória por instância para o aplicativo. As unidades válidas são: `M`, `MB`, `G` ou `GB` Provavelmente padrão: 1G
`timeout`	`-t`	Número de segundos permitidos entre a inicialização do app e a primeira verificação de integridade. Provavelmente padrão: 60

Reúna as seguintes informações para o projeto do Google Cloud e a configuração do Cloud Run:

Propriedade	Descrição
`project_number`	O número do projeto do Google Cloud em que você quer fazer a implantação.
`region`	A região em que você quer implantar o app.
`vpc-access-connector`	O nome do conector de VPC em que o administrador da plataforma quer aplicativos.
`vpc-access-egress`	O nome de saída da VPC em que o administrador da plataforma quer aplicativos.
`custom-audiences`	Públicos-alvo personalizados que podem ser autenticados no seu aplicativo.
`serviceAccountName`	A identidade que seu aplicativo vai ter no Google Cloud.
`image`	A imagem do aplicativo que você produziu na etapa anterior.

Preencha o seguinte modelo em um arquivo service.yaml na raiz do seu projeto

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

Anexar qualquer serviço de apoio

Você precisa construir uma variável de ambiente VCAP_SERVICES para permitir a injeção e a descoberta de serviços pelo aplicativo do Cloud Foundry, como Spring ou Steeltoe. Você precisa fazer isso para cada aplicativo que estiver migrando. Consulte a documentação de VCAP_SERVICES do Cloud Foundry para mais informações.

Se o aplicativo já estiver em execução no Cloud Foundry e você quiser anexar aos mesmos serviços no Cloud Run, use sua variável de ambiente atual. Caso contrário, você vai precisar criar um novo VCAP_SERVICES.

Para configurar a variável de ambiente VCAP_SERVICES:

Para um VCAP_SERVICES que já existe:
1. Execute cf env APP_NAME para tentar receber a variável de ambiente VCAP_SERVICES.
2. Caso não funcione:
  1. Conecte-se ao seu aplicativo no Cloud Foundry: cf ssh APP_NAME
  2. Execute o comando env e receba a saída de VCAP_SERVICES.
  3. Saia da sessão SSH executando exit.
3. Salve o valor VCAP_SERVICES em um novo arquivo com o nome vcap.json.
Se você quiser adicionar serviços ou se conectar a serviços diferentes do Cloud Foundry, crie um novo VCAP_SERVICES:
1. Em um editor de texto, crie um mapa JSON vazio {}.
2. Para cada serviço que você quer adicionar, faça o seguinte:
3. Consulte a documentação da biblioteca que seu app usa para analisar VCAP_SERVICES para o tipo que você quer adicionar para entender como ele descobre a vinculação.
4. Adicione uma chave ao mapa com o nome do provedor de serviços, se ainda não tiver um. Geralmente, é algo como mysql, postgresql ou elasticsearch. Defina o valor como uma matriz vazia:
5. Adicione um objeto à matriz com as seguintes propriedades:
  1. Metadados que geralmente não são usados para descobrir/vincular serviços:
    - binding_name, uma string que representa o recurso que concede permissões ao aplicativo no serviço. Pode ser um nome de usuário para um banco de dados, uma regra de firewall, um nome de conta de serviço ou algo diferente.
    - instance_name, uma string que representa o nome do serviço de backup. Pode ser o nome do banco de dados, um valor aleatório ou um valor de sentinela de um serviço global.
    - name, o binding_name se houver. Caso contrário, instance_name. Normalmente, esse valor não é importante.
    - label, o valor da chave no mapa VCAP_SERVICES em que essa vinculação está aninhada.
    - plan é o nome do plano de serviços. Por exemplo: "fornecido pelo usuário", "alta disponibilidade".
  2. Valores usados com frequência para descobrir/vincular serviços:
    - tags Lista de tags para ajudar as bibliotecas a encontrar serviços compatíveis. Geralmente, inclui o nome comum do serviço, por exemplo, mysql para MySQL e MariaDB, redis para Redis ou Cloud Memorystore ou postgres para bancos de dados compatíveis com Postgres.
    - credentials Um objeto que contém credenciais usadas pela biblioteca de cliente para realizar a conexão. A maioria das bibliotecas de cliente depende de um campo uri que contém o formato JDBC ou URI padrão do serviço.
6. Salve o conteúdo como vcap.json.

Anexar credenciais ao recurso do Cloud Run

Para anexar credenciais:

Crie um secret para armazenar o conteúdo da variável de ambiente VCAP_SERVICES e anote a saída da versão com o comando:
```
gcloud secrets create APP_NAME-vcap \
  --replication-policy="automatic" \
  --data-file=vcap.json
```

Conceda permissão à conta de serviço do seu aplicativo para ler o secret:

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

Adicione a seguinte variável de ambiente ao aplicativo service.yaml no spec.template.spec.containers[0].env array :

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

Modelos para serviços de apoio comuns

As seções a seguir fornecem informações sobre os serviços de apoio usados com frequência

MySQL

As bibliotecas do MySQL geralmente esperam a tag mysql. É comum incluir as seguintes chaves em credentials:

uri modelo: mysql://username:password@host:port/dbname. A documentação do MySQL pode ajudar na criação de uma string de URI. A porta geralmente é 3306.
username O nome de usuário da conexão, exigido por algumas bibliotecas, mesmo se incluído em uri
password A senha de conexão, exigida por algumas bibliotecas, mesmo que incluída em uri

Redis

As bibliotecas Redis geralmente esperam a tag redis. É comum incluir as chaves abaixo em credentials:

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

A documentação do URI do Redis da IANA pode ajudar a criar uma string de URI. A porta geralmente é 6379.

RabbitMQ

As bibliotecas RabbitMQ geralmente esperam a tag rabbitmq e as seguintes chaves em credentials:

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

A documentação do RabbitMQ pode ajudar na criação de uma string de URI. A porta geralmente é 5672.

Serviços fornecidos pelo usuário

Os serviços fornecidos pelo usuário são um tipo especial no Cloud Foundry que permite injetar qualquer credencial. O rótulo é sempre user-provided. As tags são os valores transmitidos para cf create-user-provided-service por meio da sinalização -t, e as credenciais são o conteúdo da sinalização -p.

Implantar o aplicativo

Para implantar o aplicativo Cloud Foundry totalmente migrado em um serviço do Cloud Run:

Configure o ambiente do Cloud Run se ainda não tiver feito isso.
Execute o comando
```
gcloud run services replace service.yaml
```
Aguarde alguns instantes até a implantação terminar. Em caso de sucesso, a linha de comando exibe o URL de serviço.
Consulte o contêiner implantado abrindo o URL de serviço em um navegador da Web.

Parabéns! Você acabou de migrar o aplicativo do Cloud Foundry para o Cloud Run