Migrer des configurations vers Cloud Run

Vous devez terminer le processus de migration de la configuration pour chaque application Cloud Foundry que vous migrez vers Cloud Run. La migration de la configuration comprend les opérations suivantes :

Convertir un manifest.yaml Cloud Foundry en un service.yaml Cloud Run.
Rattacher tous les services externes à l'application pour le déploiement sur Cloud Run.
Déployer votre application sur un service Cloud Run.

Convertir le fichier `manifest.yaml` en `service.yaml`

Vous devez convertir un fichier manifeste Cloud Foundry et/ou les options de CLI cf en fichier YAML de définition de service Cloud Run équivalent.

Cloud Run exige que chaque application dispose de son propre fichier YAML de service. Pour migrer une application dans votre fichier manifeste Cloud Foundry vers un fichier YAML de service, procédez comme suit :

Rassemblez les propriétés indiquées dans le tableau suivant pour votre application. Les propriétés qui ne sont pas modifiées au niveau de l'application peuvent avoir été remplacées par des configurations globales de la plate-forme Cloud Foundry. Reportez-vous à la documentation fournie par vos administrateurs de plate-forme pour obtenir les valeurs réelles.

Propriété d'application	Option(s) de CLI v6 `cf`	Description
`name`	Argument `NAME`	Nom unique de l'application dans Cloud Foundry.
`command`	`-c`	Commande qui sera exécutée dans `/bin/sh` ou `/bin/bash`
`disk_quota`	`-k`	Quantité d'espace disque qui sera attribuée à l'application. Les unités valides sont : `M`, `MB`, `G`, `r B` Valeur probable par défaut : 1G
`docker.image`	`--docker-image`, `-o`	Image contenant l'application à exécuter.
`health-check-http-endpoint`	N/A	Point de terminaison utilisé pour déterminer l'état HTTP si le type de vérification d'état est HTTP. Par défaut : `/`
`health-check-invocation-timeout`	N/A	Délai en secondes entre les contrôles d'état des ports individuels et les contrôles d'état basés sur le protocole HTTP. Par défaut : 1
`health-check-type`	`--health-check-type`, `-u`	Type de vérification d'état à effectuer sur l'application. Les valeurs valides sont : `port`, `http`, `none`, `process`. Par défaut : `port`
`instances`	`-i`	Nombre d'instances de l'application qui sera exécutée par Cloud Foundry. Par défaut : 1
`memory`	`-m`	Limite de mémoire par instance pour l'application. Les unités valides sont : `M`, `MB`, `G` ou `GB`. Valeur probable par défaut : 1G
`timeout`	`-t`	Nombre de secondes autorisées entre le démarrage de l'application et la première vérification d'état opérationnelle. Valeur probable par défaut : 60

Rassemblez les informations suivantes pour votre projet Google Cloud et votre configuration Cloud Run :

Propriété	Description
`project_number`	Numéro du projet Google Cloud sur lequel vous souhaitez effectuer le déploiement.
`region`	Région dans laquelle vous souhaitez déployer votre application.
`vpc-access-connector`	Nom du connecteur VPC sur lequel l'administrateur de la plate-forme veut que les applications soient déployées.
`vpc-access-egress`	Nom de la sortie VPC sur laquelle l'administrateur de la plate-forme veut que les applications soient déployées.
`custom-audiences`	Audiences personnalisées pouvant s'authentifier auprès de votre application.
`serviceAccountName`	Identité sous laquelle votre application agira dans Google Cloud.
`image`	Image de l'application que vous avez générée à l'étape précédente.

Remplissez le modèle suivant dans un fichier service.yaml à la racine de votre projet

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

Associer des services externes

Vous devez créer une variable d'environnement VCAP_SERVICES pour autoriser l'injection et la découverte de services par votre application Cloud Foundry, telle que Spring ou Steeltoe. Vous devez effectuer cette opération pour chaque application que vous migrez. Pour en savoir plus, consultez la documentation de Cloud Foundry VCAP_SERVICES.

Si votre application s'exécute déjà dans Cloud Foundry et que vous souhaitez l'associer aux mêmes services dans Cloud Run, vous pouvez utiliser votre variable d'environnement existante. Sinon, vous devrez créer un nouveau VCAP_SERVICES.

Pour configurer la variable d'environnement VCAP_SERVICES, procédez comme suit :

Pour un VCAP_SERVICES existant :
1. Essayez d'obtenir la variable d'environnement VCAP_SERVICES en exécutant cf env APP_NAME.
2. En cas d'échec :
  1. Connectez-vous à votre application dans Cloud Foundry : cf ssh APP_NAME
  2. Exécutez la commande env et obtenez le résultat de VCAP_SERVICES.
  3. Quittez la session SSH en exécutant exit.
3. Enregistrez la valeur VCAP_SERVICES dans un nouveau fichier nommé vcap.json.
Si vous souhaitez ajouter des services ou vous connecter à des services différents de ceux de Cloud Foundry, créez un nouveau VCAP_SERVICES :
1. Dans un éditeur de texte, créez un mappage JSON vide {}.
2. Pour chaque service que vous souhaitez ajouter, procédez comme suit :
3. Consultez la documentation de la bibliothèque que votre application utilise pour analyser VCAP_SERVICES pour le type que vous souhaitez ajouter afin de comprendre comment elle détecte la liaison.
4. Ajoutez une clé au mappage avec le nom du fournisseur de services s'il n'en existe pas déjà un. Il se présente généralement sous la forme mysql, postgresql ou elasticsearch. Définissez la valeur comme étant un tableau vide :
5. Ajoutez un objet au tableau avec les propriétés suivantes :
  1. Métadonnées qui ne sont généralement pas utilisées pour découvrir/lier des services :
    - binding_name, une chaîne représentant la ressource qui accorde à votre application des autorisations sur le service. Il peut s'agir d'un nom d'utilisateur pour une base de données, d'une règle de pare-feu, d'un nom de compte de service ou autre.
    - instance_name, une chaîne représentant le nom du service externe. Il peut s'agir du nom de votre base de données, d'une valeur aléatoire ou d'une valeur sentinelle pour un service global.
    - name, le binding_name s'il existe, ou bien le instance_name. Cette valeur n'est généralement pas importante.
    - label, la valeur de la clé dans le mappage VCAP_SERVICES sous lequel cette liaison est imbriquée.
    - plan, nom du forfait. Par exemple : "fourni par l'utilisateur", "haute disponibilité".
  2. Valeurs souvent utilisées pour découvrir/lier des services :
    - tags Liste de tags pour aider les bibliothèques à trouver des services compatibles. Inclut souvent le nom commun du service, par exemple mysql pour MySQL et MariaDB, redis pour Redis ou Cloud Memorystore, ou postgres pour les bases de données compatibles avec Postgres.
    - credentials Objet contenant les identifiants utilisés par la bibliothèque cliente pour établir la connexion. La plupart des bibliothèques clientes reposent sur un champ uri contenant l'URI standard ou le format JDBC du service.
6. Enregistrez le contenu en tant que vcap.json.

Associer des identifiants à votre ressource Cloud Run

Pour associer des identifiants, procédez comme suit :

Créez un secret pour conserver le contenu de votre variable d'environnement VCAP_SERVICES et notez la version renvoyée par la commande :
```
gcloud secrets create APP_NAME-vcap \
  --replication-policy="automatic" \
  --data-file=vcap.json
```

Accordez au compte de service de votre application l'autorisation de lire le secret :

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

Ajoutez la variable d'environnement suivante à votre application service.yaml dans spec.template.spec.containers[0].env array :

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

Modèles de services externes courants

Les sections suivantes fournissent des informations sur les services externes couramment utilisés.

MySQL

Les bibliothèques MySQL attendent généralement le tag mysql. Il est courant d'inclure les clés suivantes dans credentials :

Modèle d'uri : mysql://username:password@host:port/dbname. La documentation de MySQL peut vous aider à créer une chaîne URI. Le port est généralement 3306.
username : nom d'utilisateur de la connexion, requis par certaines bibliothèques même s'il est inclus dans uri
password : mot de passe de connexion, requis par certaines bibliothèques même s'il est inclus dans uri

Redis

Les bibliothèques Redis attendent généralement le tag redis. Il est courant d'inclure les clés suivantes dans credentials :

Modèle d'uri : redis://:password@host:port/dbunumber.

La documentation sur les URI Redis IANA peut vous aider à créer une chaîne URI. Le port est généralement 6379.

RabbitMQ

Les bibliothèques RabbitMQ attendent généralement le tag rabbitmq et les clés suivantes dans credentials :

Modèle d'uri : amqp://username:password@host:port/vhost?query.

La documentation de RabbitMQ peut vous aider à créer une chaîne URI. Le port est généralement 5672.

Services fournis par l'utilisateur

Les services fournis par l'utilisateur sont un type spécial de service dans Cloud Foundry qui vous permet d'injecter des identifiants. Le libellé est toujours user-provided. Les tags sont les valeurs transmises à cf create-user-provided-service via l'option -t et les identifiants sont le contenu de l'option -p.

Déployer l'application

Pour déployer l'application Cloud Foundry entièrement migrée vers un service Cloud Run, procédez comme suit :

Si ce n'est pas déjà fait, configurez votre environnement Cloud Run.
Exécutez la commande
```
gcloud run services replace service.yaml
```
Patientez quelques instants jusqu'à la fin du déploiement. En cas de réussite, la ligne de commande affiche l'URL du service.
Accédez à votre service déployé en ouvrant l'URL du service dans un navigateur Web.

Félicitations ! Vous venez de migrer votre application Cloud Foundry vers Cloud Run.