Scegli una strategia conforme all'OCI

Questa pagina fornisce una panoramica del processo di compilazione di Cloud Foundry da cui eseguire la migrazione e fornisce una descrizione dei vari modi da cui è possibile eseguire la migrazione da tale processo a un processo che crea container conformi OCI.

Panoramica del processo di compilazione di Cloud Foundry

Quando un'applicazione viene inviata a Cloud Foundry, passa attraverso una fase di build in cui il codice sorgente viene compilato dai buildpack Cloud Foundry v2.

L'output di un processo di compilazione di Cloud Foundry crea un archivio eseguibile chiamato droplet. I droplet non sono direttamente compatibili con la specifica Open Container Initiative (OCI) per l'esecuzione dei container su Cloud Run.

Quando esegui la migrazione di applicazioni da Cloud Foundry a Cloud Run, devi modificare il processo di compilazione dell'applicazione per generare immagini OCI standard di settore (a volte chiamate immagini Docker).

Diagramma che descrive come vengono create le goccioline Cloud Foundry

Strategie per ottenere immagini conformi all'OCI

Puoi scegliere tra tre strategie di migrazione per creare container conformi all'OCI:

Modifica di un'applicazione Cloud Foundry (lift and shift)

I componenti principali dell'ecosistema Cloud Foundry (v2 Buildpack, Stemcells e così via) sono open source. Ciò significa che puoi ricreare il processo di containerizzazione delle applicazioni seguendo la nostra guida su come "dockerizzare" i componenti principali della build per creare una nuova immagine conforme allo standard OCI.

Vantaggi:

  • Richiede il refactoring e la personalizzazione dell'applicazione minime.
  • Il processo è ripetibile per tutte le istanze dell'applicazione.

Svantaggi:

  • La pipeline per la creazione di container di applicazioni è autogestita.
  • I componenti di Cloud Foundry meno recenti hanno una minore manutenzione e assistenza.
  • Sono previsti costi continui di manutenzione della sicurezza, tra cui:
    • Ricreando regolarmente i componenti della build per assicurarti di ricevere patch di sicurezza.
    • Ricreando regolarmente le applicazioni "dockerizzate" per gestire gli aggiornamenti della sicurezza dai componenti della build rigenerati.

Utilizzo di Buildpack cloud-native

La specifica Cloud Native Buildpacks (CNB) è stata creata per modernizzare e unificare l'ecosistema di buildpack. I builder compatibili con la specifica CNB seguono standard aperti e creano immagini conformi a OCI. I tre fornitori CNB più comuni sono:

Vantaggi:

  • I gestori di Buildpack e i provider di piattaforme sono responsabili della manutenzione del buildpack.
  • I buildpack supportano il ribasing dei container su nuove immagini per aggiornamenti di sicurezza rapidi senza ricreare i container delle applicazioni.
  • I buildpack generano immagini OCI portabili.
  • Il progetto del CNB è in fase di incubazione nell'ambito della Cloud Native Computing Foundation (CNCF) e ha una community attiva di manutentori e collaboratori.

Svantaggi:

  • Lacune di funzionalità e configurazione tra i buildpack v2 e v3.
  • I framework e le integrazioni installati per tuo conto nei buildpack Java v2 potrebbero non essere disponibili nel buildpack Java CNB.

Utilizzo di Dockerfile autogestiti

Puoi creare Dockerfile completamente nuovi per containerizzare la tua applicazione. Consulta la sezione Creazione di container per scoprire di più sulle immagini container accettate da Cloud Run.

Vantaggi:

  • Offre la massima flessibilità nella progettazione delle applicazioni.
  • Sfrutta gli strumenti per i container e le strategie di creazione esistenti della tua azienda.

Svantaggi:

  • Devi eseguire la Dockerizzazione e la configurazione personalizzata per ogni applicazione, portando a debug e riscritture potenzialmente dispendiose in termini di tempo.
  • È difficile standardizzare le implementazioni tra più team.
  • L'applicazione di patch alle immagini richiede una rigenerazione completa e un nuovo deployment.

Suggerimenti

I team con risorse limitate e che vogliono spostare il maggior numero possibile di applicazioni devono prima prendere in considerazione la strategia Lift and Shift per modificare Cloud Foundry. Una volta che le applicazioni sono state modernizzate per diventare immagini conformi OCI, ti consigliamo di considerare l'utilizzo di buildpack Cloud Native o Dockerfile autogestiti.

I team pronti per la migrazione immediata dovrebbero provare i buildpack Cloud-native e passare ai Dockerfile autogestiti se hanno bisogno di un elevato livello di controllo sul proprio ambiente.

Passaggi successivi