Migrer vers des conteneurs OCI

Cette page décrit l'infrastructure de compilation requise pour reproduire le processus de compilation Cloud Foundry lors de la génération d'images d'application compatibles OCI. Si vous avez déjà terminé le guide de migration Spring Music, vous pouvez utiliser ce guide détaillé sur la configuration de migration spécifique de votre application.

Diagramme illustrant la création d'images OCI à l'aide d'outils modernes

Avant de commencer

Assurez-vous d'avoir configuré un nouveau projet pour Cloud Run, comme décrit sur la page de configuration Cloud Run.
Assurez-vous de disposer d'un REGISTRY_URI pour le stockage de conteneurs. Cloud Run recommande d'utiliser Artifact Registry. Docker est utilisé pour créer des images intermédiaires pour créer le projet.

Configurer un processus de compilation compatible avec Cloud Foundry

Vous devez créer deux conteneurs OCI de base pour prendre en charge ce nouveau processus:

Une image de compilateur qui reflète le processus de compilation de Cloud Foundry et est capable de compiler le code source de l'application dans les Droplets Cloud Foundry.
Une image d'exécution qui reflète l'environnement d'exécution de l'application Cloud Foundry.

Ce processus doit être effectué au moins une fois par les administrateurs de la plate-forme. Une fois le processus établi, les images de build et d'exécution peuvent être partagées par toutes les applications Cloud Foundry devant migrer vers Cloud Run.

Créer l'image du compilateur

Dans cette section, vous allez créer une image de build en utilisant cflinux3 comme image de base. L'image de build est utilisée comme environnement de compilation pour créer l'image d'application.

Créez un répertoire appelé build/ et utilisez cd pour y accéder :
```
mkdir build && cd build
```

Dans le dossier build/, créez un fichier appelé Dockerfile et collez-y le code suivant:

ARG CF_LINUX_FS=cloudfoundry/cflinuxfs3

FROM golang:1.20-bullseye AS builder_build
WORKDIR /build
RUN ["git", "clone", "--depth=1", "https://github.com/cloudfoundry/buildpackapplifecycle.git"]
WORKDIR /build/buildpackapplifecycle
RUN ["go", "mod", "init", "code.cloudfoundry.org/buildpackapplifecycle"]
RUN ["go", "mod", "tidy"]
RUN CGO_ENABLD=0 go build -o /builder ./builder/

FROM $CF_LINUX_FS
# Set up container tools related to building applications
WORKDIR /lifecycle
COPY --from=builder_build /builder /lifecycle/builder

# Set up environment to match Cloud Foundry's build.
# https://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#app-system-env
WORKDIR /staging/app
WORKDIR /tmp
ENV CF_INSTANCE_ADDR=127.0.0.1:8080 \
CF_INSTANCE_IP=127.0.0.1 \
CF_INSTANCE_INTERNAL_IP=127.0.0.1 \
VCAP_APP_HOST=127.0.0.1 \
CF_INSTANCE_PORT=8080 \
LANG=en_US.UTF-8 \
INSTANCE_GUID=00000000-0000-0000-0000-000000000000 \
VCAP_APPLICATION={} \
VCAP_SERVICES={} \
CF_STACK=cflinuxfs3

Utiliser Cloud Build pour compiler et publier l'image builder
```
gcloud builds \
    submit --tag "REGISTRY_URI/builder:stable"
```
Remplacez REGISTRY_URI par l'adresse du registre Artifact Registry dans lequel vous souhaitez publier l'image de compilation. Exemple : REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/builder:stable.

Créer l'image de l'environnement d'exécution

Dans cette section, vous allez créer une image d'exécution en utilisant cflinux3 comme image de base. L'image d'exécution est utilisée comme image de base lorsque vous créez l'image d'application finale.

Créez un répertoire appelé run/ et utilisez cd pour y accéder :
```
mkdir run && cd run
```

Dans le dossier run/, créez un script shell nommé entrypoint.bash avec le code suivant:

#!/usr/bin/env bash
set -e

if [[ "$@" == "" ]]; then
exec /lifecycle/launcher "/home/vcap/app" "" ""
else
exec /lifecycle/launcher "/home/vcap/app" "$@" ""
fi

Dans le dossier run/, créez un fichier appelé Dockerfile et collez-y le code suivant:

ARG CF_LINUX_FS=cloudfoundry/cflinuxfs3

FROM golang:1.20-bullseye AS launcher_build
WORKDIR /build
RUN ["git", "clone", "--depth=1", "https://github.com/cloudfoundry/buildpackapplifecycle.git"]
WORKDIR /build/buildpackapplifecycle
RUN ["go", "mod", "init", "code.cloudfoundry.org/buildpackapplifecycle"]
RUN ["go", "mod", "tidy"]
RUN CGO_ENABLD=0 go build -o /launcher ./launcher/

FROM $CF_LINUX_FS
# Set up container tools related to launching the application
WORKDIR /lifecycle
COPY entrypoint.bash /lifecycle/entrypoint.bash
RUN ["chmod", "+rx", "/lifecycle/entrypoint.bash"]
COPY --from=launcher_build /launcher /lifecycle/launcher

# Set up environment to match Cloud Foundry
WORKDIR /home/vcap
USER vcap:vcap
ENTRYPOINT ["/lifecycle/entrypoint.bash"]

# Expose 8080 to allow app to be run on Cloud Foundry,
# and PORT so the container can be run locally.
# These do nothing on Cloud Run.
EXPOSE 8080/tcp
# Set up environment variables similar to Cloud Foundry.
ENV CF_INSTANCE_ADDR=127.0.0.1:8080 \
CF_INSTANCE_IP=127.0.0.1 \
INSTANCE_IP=127.0.0.1 \
CF_INSTANCE_INTERNAL_IP=127.0.0.1 \
VCAP_APP_HOST=127.0.0.1 \
CF_INSTANCE_PORT=80 \
LANG=en_US.UTF-8 \
CF_INSTANCE_GUID=00000000-0000-0000-0000-000000000000 \
INSTANCE_GUID=00000000-0000-0000-0000-000000000000 \
CF_INSTANCE_INDEX=0 \
INSTANCE_INDEX=0 \
PORT=8080 \
VCAP_APP_PORT=8080 \
VCAP_APPLICATION={} \
VCAP_SERVICES={}

Utilisez Cloud Build pour créer et publier l'image runtime:
```
gcloud builds submit \
    --tag "REGISTRY_URI/runtime:stable"
```
Remplacez REGISTRY_URI par l'adresse du registre Artifact Registry dans lequel vous souhaitez publier l'image de compilation. Exemple : REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/runtime:stable..

Créer des applications Cloud Foundry en tant qu'images OCI

Chaque application migrée dans Cloud Run a besoin de son propre fichier Dockerfile qui correspond à la manière dont Cloud Foundry exécute les applications. Le fichier Dockerfile effectue les opérations suivantes:

Charge l'image du compilateur.
Exécute le cycle de vie du buildpack v2 pour créer un Droplet.
Extrait le contenu de la goutte.
Il charge le contenu du Droplet sur l'image d'exécution pour créer l'image d'application exécutable.

L'image d'application finale est compatible avec Cloud Foundry et Cloud Run, ce qui vous permet d'exécuter un test A/B sur votre migration pour déboguer tout comportement inattendu.

Ce processus doit être effectué par l'équipe de développement pour chaque application à migrer.

Collecter des informations de compilation à partir d'une application Cloud Foundry déployée

Examinez la pile d'applications. La pile est fournie via l'option -s dans cf push ou le champ stack du fichier manifeste de l'application.
1. Si la pile est Windows, l'application est probablement incompatible avec Cloud Run. Vous devez transférer l'application vers Linux avant de continuer.
2. Si la pile est vide, cflinuxfs3 ou cflinuxfs4, l'application peut être migrée vers Cloud Run.

Rassemblez la liste des packs de création d'applications. Les packs de création sont fournis via l'option -b dans cf push, le champ buildpack dans le fichier manifeste de l'application ou le champ buildpacks du fichier manifeste d'application.

Si aucun buildpack n'est spécifié, cela signifie qu'ils sont détectés automatiquement. Consultez la liste des buildpacks détectés dans votre dernier déploiement d'application dans Cloud Foundry ou spécifiez-les explicitement si vous connaissez les chemins d'accès.
Si les buildpacks sont des URL, notez-les et passez à l'étape suivante.

Pour tous les buildpacks qui utilisent un nom court, utilisez le tableau suivant pour les mapper aux URL:

Nom court	URL
`staticfile_buildpack`	https://github.com/cloudfoundry/staticfile-buildpack
`java_buildpack`	https://github.com/cloudfoundry/java-buildpack
`ruby_buildpack`	https://github.com/cloudfoundry/ruby-buildpack
`dotnet_core_buildpack`	https://github.com/cloudfoundry/dotnet-core-buildpack
`nodejs_buildpack`	https://github.com/cloudfoundry/nodejs-buildpack
`go_buildpack`	https://github.com/cloudfoundry/go-buildpack
`python_buildpack`	https://github.com/cloudfoundry/python-buildpack
`php_buildpack`	https://github.com/cloudfoundry/php-buildpack
`binary_buildpack`	https://github.com/cloudfoundry/binary-buildpack
`nginx_buildpack`	https://github.com/cloudfoundry/nginx-buildpack

La source des buildpacks moins courants est disponible dans l'organisation GitHub Cloud Foundry.

Rassemblez l'emplacement du code source de l'image. La source est fournie via l'attribut path du fichier manifeste de l'application ou l'option -p de la commande cf push. Si la source n'est pas définie, elle fait référence au répertoire actuel.
Déterminez s'il existe un fichier .cfignore dans le répertoire du code source. Le cas échéant, déplacez-le vers un fichier nommé .gcloudignore..

Créer l'application Cloud Foundry

Au cours de cette étape, vous allez organiser les éléments de compilation dans la structure de dossiers suivante:

.
├── cloudbuild.yaml
├── Dockerfile
├── .gcloudignore
└── src
    ├── go.mod
    └── main.go

cloudbuild.yaml fournit à Cloud Build des instructions de compilation spécifiques.
Dockerfile utilise les images de compilation et d'exécution des étapes précédentes pour créer l'image de l'application.
src/ contient le code source de votre application.

Créez un fichier nommé Dockerfile dans le répertoire avec le contenu suivant :

ARG BUILD_IMAGE
ARG RUN_IMAGE
FROM $BUILD_IMAGE as build

COPY src /staging/app
COPY src /tmp/app

ARG BUILDPACKS
RUN /lifecycle/builder \
-buildArtifactsCacheDir=/tmp/cache \
-buildDir=/tmp/app \
-buildpacksDir=/tmp/buildpacks \
-outputBuildArtifactsCache=/tmp/output-cache \
-outputDroplet=/tmp/droplet \
-outputMetadata=/tmp/result.json \
"-buildpackOrder=${BUILDPACKS}" \
"-skipDetect=true"

FROM $RUN_IMAGE
COPY --from=build /tmp/droplet droplet
RUN tar -xzf droplet && rm droplet

Créez un fichier nommé cloudbuild.yaml dans le répertoire avec le contenu suivant :

steps:
- name: gcr.io/cloud-builders/docker
  args:
  - 'build'
  - '--network'
  - 'cloudbuild'
  - '--tag'
  - '${_TAG}'
  - '--build-arg'
  - 'BUILD_IMAGE=${_BUILD_IMAGE}'
  - '--build-arg'
  - 'RUN_IMAGE=${_RUN_IMAGE}'
  - '--build-arg'
  - 'BUILDPACKS=${_BUILDPACKS}'
  - '.'
images:
- "${_TAG}"
options:
  # Substitute build environment variables as an array of KEY=VALUE formatted strings here.
  env: []
substitutions:
  _BUILD_IMAGE: BUILD_IMAGE_URI
  _RUN_IMAGE:  RUN_IMAGE_URI
  _BUILDPACKS: BUILDPACK_URL
  _TAG: APP_ARTIFACT_REGISTRY/APP_NAME:latest

Remplacez BUILD_IMAGE_URI par l'URI de l'image de build créée lors des étapes précédentes.
Remplacez RUN_IMAGE_URI par l'URI de l'image d'exécution créée lors des étapes précédentes.
Remplacez BUILDPACK_URL par les URL des packs de création utilisés par votre application. Il peut s'agir d'une liste d'éléments séparés par une virgule avec plusieurs buildpacks.

Si vous disposez d'un fichier .cfignore, copiez-le dans le répertoire nommé .gcloudignore.
Créez un répertoire nommé src dans ce répertoire.
Copiez le contenu de votre application dans src:.
1. Si la source est un fichier ZIP (y compris les fichiers .jar), décompressez le contenu dans src.
2. Si le code source est un répertoire, copiez son contenu dans src.
Exécutez gcloud builds submit . pour compiler votre application.

Incompatibilités connues

Les packs de création qui reposent sur des variables d'environnement injectées Cloud Foundry telles que VCAP_SERVICES, ne fonctionnent pas. À la place, vous devez déclarer explicitement une dépendance sur ce qu'ils injectent à l'aide du système de gestion de votre langage.
Pour corriger les images générées de cette manière, vous devez recréer l'image à l'aide d'une version plus récente de l'image de compilation et d'exécution. Les images d'application ne seront pas automatiquement corrigées en mettant à jour les cellules souches BOSH si vous les exécutez sur Cloud Foundry.
Les compilations s'effectuent dans un environnement réseau différent de votre cluster Cloud Foundry, vous devrez peut-être configurer des pools Cloud Build personnalisés avec accès à vos miroirs de packages internes.

Étape suivante

Migrer les configurations d'application