Esegui la migrazione ai container OCI

Questa pagina descrive l'infrastruttura di build necessaria per riprodurre il processo di compilazione di Cloud Foundry durante la generazione di immagini dell'applicazione compatibili con OCI. Se hai già completato la guida alla migrazione di Spring Music, puoi utilizzarla per approfondire le configurazioni di migrazione specifiche per la tua applicazione.

Diagramma che descrive come creare immagini OCI utilizzando strumenti moderni

Prima di iniziare

  1. Assicurati di aver configurato un nuovo progetto per Cloud Run come descritto nella pagina Configurazione di Cloud Run.
  2. Assicurati di avere un REGISTRY_URI per archiviare i contenitori. Cloud Run consiglia di utilizzare Artifact Registry. Docker viene utilizzato per creare immagini intermedie per creare il progetto.

Configurazione di un processo di compilazione compatibile con Cloud Foundry

Per supportare questa nuova procedura, devi creare due contenitori OCI di base:

  • Un'immagine del builder che rispecchia il processo di compilazione di Cloud Foundry ed è in grado di creare il codice sorgente dell'applicazione in droplet Cloud Foundry.
  • Un'immagine runtime che rispecchia il runtime dell'applicazione Cloud Foundry.

Questa procedura deve essere eseguita almeno una volta dagli amministratori della piattaforma. Una volta stabilito il processo, le immagini di build ed esecuzione possono essere condivise da tutte le applicazioni Cloud Foundry che devono essere migrate a Cloud Run.

Crea l'immagine del builder

Questa sezione crea un'immagine di build utilizzando cflinux3 come immagine di base. L'immagine di build viene utilizzata come ambiente di build per creare l'immagine dell'applicazione.

  1. Crea una directory denominata build/ e cd:

    mkdir build && cd build
    
  2. Nella cartella build/, crea un nuovo file denominato Dockerfile e incolla il seguente codice:

    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
    
  3. Utilizzare Cloud Build per creare e pubblicare l'immagine builder

    gcloud builds \
        submit --tag "REGISTRY_URI/builder:stable"
    

    Sostituisci REGISTRY_URI con l'indirizzo di Artifact Registry in cui vuoi pubblicare l'immagine di build. Ad esempio: REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/builder:stable.

Crea l'immagine di runtime

Questa sezione crea un'immagine di esecuzione utilizzando cflinux3 come immagine di base. L'immagine di esecuzione viene utilizzata come immagine di base quando crei l'immagine dell'applicazione finale.

  1. Crea una directory denominata run/ e cd:

    mkdir run && cd run
    
  2. Nella cartella run/, crea un nuovo script shell denominato entrypoint.bash con il seguente codice:

    #!/usr/bin/env bash
    set -e
    
    if [[ "$@" == "" ]]; then
    exec /lifecycle/launcher "/home/vcap/app" "" ""
    else
    exec /lifecycle/launcher "/home/vcap/app" "$@" ""
    fi
    
  3. Nella cartella run/, crea un nuovo file denominato Dockerfile e incolla il seguente codice:

    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={}
    
  4. Utilizza Cloud Build per creare e pubblicare l'immagine runtime:

    gcloud builds submit \
        --tag "REGISTRY_URI/runtime:stable"
    

    Sostituisci REGISTRY_URI con l'indirizzo di Artifact Registry in cui vuoi pubblicare l'immagine di build. Ad esempio: REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/runtime:stable.

Creazione di applicazioni Cloud Foundry come immagini OCI

Ogni applicazione di cui è stata eseguita la migrazione in Cloud Run ha bisogno del proprio Dockerfile che corrisponda al modo in cui Cloud Foundry esegue le applicazioni. Il Dockerfile esegue le seguenti operazioni:

  • Carica l'immagine del builder.
  • Esegue il ciclo di vita di buildpack v2 per creare un droplet.
  • Estrae i contenuti del droplet.
  • Carica i contenuti del droplet nell'immagine di esecuzione per creare l'immagine dell'applicazione eseguibile.

L'immagine dell'applicazione finale è compatibile sia con Cloud Foundry sia con Cloud Run, in modo da poter eseguire test A/B della migrazione per eseguire il debug di eventuali comportamenti imprevisti.

Questa procedura deve essere eseguita dal team dell'applicazione per ogni applicazione che deve essere migrata.

Raccogli informazioni sulla build da un'applicazione Cloud Foundry di cui è stato eseguito il deployment

  1. Esamina lo stack dell'applicazione. Lo stack viene fornito tramite il flag -s in cf push o il campo stack del manifest dell'applicazione.

    1. Se lo stack è Windows, l'applicazione è probabilmente incompatibile con Cloud Run. Prima di continuare, devi eseguire il porting dell'applicazione su Linux.
    2. Se lo stack è vuoto, cflinuxfs3 o cflinuxfs4, l'applicazione può essere migrata a Cloud Run.
  2. Raccogli l'elenco dei buildpack dell'applicazione. I buildpack vengono forniti tramite il flag -b in cf push, il campo buildpack nel manifest dell'applicazione o il campo buildpacks del manifest dell'applicazione.

    1. Se non vengono specificati buildpack, significa che vengono rilevati automaticamente. Esamina l'elenco dei buildpack rilevati nell'ultimo deployment dell'applicazione in Cloud Foundry o specificali in modo esplicito se conosci i percorsi.
    2. Se i buildpack sono URL, prendi nota degli URL e vai al passaggio successivo.
    3. Per qualsiasi buildpack che utilizza un nome breve, utilizza la seguente tabella per associarli agli URL:

      Nome breve 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

      L'origine dei buildpack meno comuni si trova nell'organizzazione GitHub Cloud Foundry.

  3. Raccogli la posizione del codice sorgente dell'immagine. L'origine viene fornita tramite l'attributo path del manifest dell'applicazione o il flag -p del comando cf push. Se l'origine non è definita, si riferisce alla directory corrente.

  4. Determina se esiste un file .cfignore nella directory del codice sorgente. Se è presente, spostalo in un file denominato .gcloudignore..

Crea l'applicazione Cloud Foundry

In questo passaggio, organizza gli elementi di build nella seguente struttura di cartelle:

.
├── cloudbuild.yaml
├── Dockerfile
├── .gcloudignore
└── src
    ├── go.mod
    └── main.go
  • cloudbuild.yaml fornisce a Cloud Build istruzioni di build specifiche
  • Dockerfile utilizzerà le immagini di build ed esecuzione dei passaggi precedenti per creare l'immagine dell'applicazione
  • src/ contiene il codice sorgente dell'applicazione
  1. Crea un file denominato Dockerfile nella directory con il seguente contenuto:

    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
    
  2. Crea un file denominato cloudbuild.yaml nella directory con il seguente contenuto:

    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
    
    • Sostituisci BUILD_IMAGE_URI con l'URI dell'immagine di build creata nei passaggi precedenti.
    • Sostituisci RUN_IMAGE_URI con l'URI dell'immagine di esecuzione creata nei passaggi precedenti.
    • Sostituisci BUILDPACK_URL con gli URL dei buildpack utilizzati dalla tua applicazione. Può trattarsi di un elenco separato da virgole con più buildpack.
  3. Se hai un file .cfignore, copialo nella directory con il nome .gcloudignore.

  4. Crea una directory denominata src nella directory.

  5. Copia i contenuti della tua richiesta in src:

    1. Se l'origine è un file ZIP (inclusi i file .jar), decomprimi i contenuti in src.
    2. Se il codice sorgente è una directory, copia i contenuti in src.
  6. Esegui gcloud builds submit . per creare l'applicazione.

Incompatibilità note

  • I buildpack che si basano su variabili di ambiente inserite da Cloud Foundry come VCAP_SERVICES non funzioneranno. Dovresti invece dichiarare esplicitamente una dipendenza da ciò che inseriscono utilizzando il sistema di gestione della lingua.
  • Per applicare patch alle immagini prodotte in questo modo, devi ricompilare l'immagine utilizzando una versione più recente dell'immagine di build ed esecuzione. Le immagini delle applicazioni non verranno patchate automaticamente aggiornando le stemcell BOSH se le esegui su Cloud Foundry.
  • Le build verranno eseguite in un ambiente di rete diverso dal cluster Cloud Foundry. Potresti dover configurare pool Cloud Build personalizzati con accesso ai mirror dei pacchetti interni.

Passaggi successivi