Questa pagina fornisce una panoramica del processo di compilazione di Cloud Foundry da cui devi eseguire la migrazione e descrive i vari modi in cui puoi eseguire la migrazione a un processo che crea container conformi a OCI.
Panoramica 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 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 del settore (a volte chiamate immagini Docker).
Strategie per ottenere immagini conformi a OCI
Esistono tre strategie di migrazione tra cui scegliere per creare container conformi all'OCI:
- Modifica l'applicazione Cloud Foundry esistente (a volte chiamata "lift and shift")
- Utilizzare i buildpack Cloud Native
- Utilizzare Dockerfile autogestiti
Modifica di un'applicazione Cloud Foundry (lift and shift)
I componenti principali dell'ecosistema Cloud Foundry (v2 Buildpacks, Stemcells, ecc.) 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.
- La procedura è ripetibile per tutte le istanze dell'applicazione.
Svantaggi:
- La pipeline per la creazione di container di applicazioni è autogestita.
- La manutenzione e l'assistenza per i componenti Cloud Foundry meno recenti sono ridotte.
- Sono previsti costi di manutenzione della sicurezza continui, tra cui:
- Ricostruendo regolarmente i componenti della build per assicurarti di ricevere le patch di sicurezza.
- Ricostruendo regolarmente le applicazioni "dockerizzate" per incorporare gli aggiornamenti di sicurezza dei componenti di build ricompilati.
Utilizzo di Cloud Native Buildpacks
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 fornitori comuni di CNB 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 rapidi della sicurezza senza ricompilare i container delle applicazioni.
- I buildpack generano immagini OCI portatili.
- Il progetto CNB è in incubazione presso la 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 CNB Java.
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:
- Ti offre la massima flessibilità nella progettazione delle applicazioni.
- Sfrutta gli strumenti e le strategie di creazione di container esistenti della tua azienda.
Svantaggi:
- La dockerizzazione e la configurazione personalizzata devono essere eseguite per ogni applicazione, il che comporta potenzialmente debug e riscritture che richiedono molto tempo.
- Difficoltà di standardizzare le implementazioni in più team.
- L'applicazione di patch alle immagini richiede una ricompilazione e un nuovo deployment completi.
Consigli
I team con risorse limitate che vogliono spostare il maggior numero possibile di applicazioni devono innanzitutto prendere in considerazione la strategia Lift and Shift per modificare Cloud Foundry. Una volta che le applicazioni sono state modernizzate per diventare immagini conformi a OCI, ti consigliamo di prendere in considerazione l'utilizzo di Cloud Native Buildpacks o di Dockerfile autogestiti.
I team pronti per la migrazione immediata devono provare Cloud Native Buildpacks e poi passare ai Dockerfile autogestiti se hanno bisogno di un elevato livello di controllo sul proprio ambiente.
Passaggi successivi
- Segui l'esempio di migrazione di Spring Music che utilizza la strategia lift and shift.
- Esegui la migrazione ai container OCI