Scegli una strategia conforme a OCI

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

Panoramica del processo di compilazione di Cloud Foundry

Quando un'applicazione viene eseguita con push in 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 noto come droplet. I droplet non sono direttamente compatibili con la specifica Open Container Initiative (OCI) per l'esecuzione di container su Cloud Run.

Quando esegui la migrazione delle 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 creati i droplet Cloud Foundry

Strategie per ottenere immagini conformi a OCI

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

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

I componenti principali dell'ecosistema Cloud Foundry (buildpack v2, stemcell e così via) sono open source. Ciò significa che puoi ricreare il processo di containerizzazione dell'applicazione seguendo la nostra guida per "dockerizzare" i componenti di build principali per creare una nuova immagine conforme a OCI.

Vantaggi:

  • Richiede la minima quantità di refactoring e personalizzazione dell'applicazione.
  • Il processo è ripetibile per tutte le istanze dell'applicazione.

Svantaggi:

  • La pipeline per la creazione di container di applicazioni è autogestita.
  • I componenti Cloud Foundry precedenti hanno una manutenzione e un supporto ridotti.
  • Sono previsti costi di manutenzione della sicurezza continui, tra cui:
    • Ricreazione periodica dei componenti di build per assicurarti di ricevere le patch di sicurezza.
    • Ricreazione periodica delle applicazioni "dockerizzate" per applicare gli aggiornamenti di sicurezza dai componenti di build ricreati.

Utilizzo dei buildpack Cloud Native

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

Vantaggi:

  • I responsabili della manutenzione dei buildpack e i fornitori di piattaforme sono responsabili della manutenzione del buildpack.
  • I buildpack supportano il rebase dei container su nuove immagini per aggiornamenti di sicurezza rapidi senza ricreare i container delle applicazioni.
  • I buildpack generano immagini OCI portatili.
  • Il progetto CNB è in fase di incubazione presso la Cloud Native Computing Foundation (CNCF) e ha una community attiva di responsabili della manutenzione 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 dei Dockerfile autogestiti

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

Vantaggi:

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

Svantaggi:

  • La dockerizzazione e la configurazione personalizzata devono essere eseguite per ogni applicazione, il che può comportare il debug e la riscrittura che richiedono molto tempo.
  • È difficile standardizzare le implementazioni tra più team.
  • L'applicazione di patch alle immagini richiede una ricreazione e un nuovo deployment completi.

Consigli

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

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

Passaggi successivi