Confronta i buildpack V2 e V3

Un buildpack converte il codice sorgente in un eseguibile e viene utilizzato per fornire un modo semplice, affidabile e ripetibile per creare container. Kf supporta sia i buildpack V2 che V3 ed è importante comprendere le differenze tra loro.

Buildpack V2

La maggior parte delle applicazioni Cloud Foundry utilizza già i buildpack V2. Quando utilizzi i buildpack V2 con Kf, i binari del ciclo di vita e i buildpack vengono scaricati e configurati dai relativi URL di Git. Kf utilizza quindi l'interfaccia a riga di comando lifecycle per eseguire ogni buildpack sul codice sorgente.

Vantaggi

• Pronto all'uso senza modifiche alla pipeline o al codice.

Svantaggi

• Buildpack legacy sostituito dalla versione 3.
• Prestazioni e affidabilità inferiori. La pipeline di compilazione di Kf richiede più I/O per i buildpack V2.
• Meno risorse della community.
• Kf supporta solo i repository git OSS.

Buildpack V3

I buildpack V3 sono un progetto della Cloud Native Computing Foundation (CNCF) con uno spec ben definito, un'interfaccia a riga di comando (pack) e una community in crescita che innova in base a diversi linguaggi e framework. Google Cloud ha anche un proprio insieme di buildpack di Google Cloud.

I buildpack V3 hanno due container OCI generali:

• Immagine builder
• Esegui immagine

Immagine builder

L'immagine del generatore viene utilizzata durante la compilazione del codice sorgente in un contenitore eseguibile. L'immagine contiene gli script detect e altre utilità necessari per compilare il codice sorgente.

Nota :la maggior parte dei buildpack non pacchettizza i compilatori con l'immagine del generatore. In alternativa, possono fare in modo che le pipeline di compilazione scarichino le dipendenze necessarie per la compilazione.

Esegui immagine

L'immagine di esecuzione è l'immagine di base su cui viene creato un container. Ciò significa che è l'immagine di base che verrà eseguita quando l'app viene eseguita.

Base

I buildpack della versione 3 utilizzano i livelli per comporre il contenitore finale. A ogni buildpack incluso in una build viene data la possibilità di manipolare il file system e le variabili di ambiente dell'app. Questo approccio a più livelli consente ai buildpack di essere più sottili e generici.

I buildpack della versione 3 vengono creati su container OCI. Ciò richiede che l'immagine del generatore V3 venga archiviata in un registry dei container a cui ha accesso la pipeline di compilazione di Kf. La pipeline di compilazione utilizza l'immagine del generatore per applicare gli script sottostanti per compilare il codice sorgente in un container eseguibile.

Vantaggi

• Google supportava l'immagine del builder e dell'esecuzione.
• È compatibile con vari Google Cloud prodotti come Cloud Build.
• Una community in crescita e un registry di buildpack.

Svantaggi

• Potrebbe essere necessario aggiornare il codice/il processo. Ad esempio, il buildpack Java richiede il codice sorgente, mentre il buildpack V2 richiede un file jar.
• I buildpack V3 sono più recenti e potrebbero richiedere una convalida aggiuntiva (se utilizzi buildpack sviluppati dalla community).

Kf Stacks

Visualizza stack

Quando esegui il push di un'app, la pipeline di compilazione determina il buildpack in base allo stack selezionato (specificato tramite il flag --stack o il manifest).

Per vedere quali stack sono disponibili in uno spazio, assicurati innanzitutto che uno spazio sia scelto come target:

kf target -s myspace

Il sottocomando kf stacks può essere utilizzato per elencare gli stack:

kf stacks

L'output mostra gli stack V2 e V3:

Getting stacks in Space: myspace
Version  Name                                Build Image                                                                                          Run Image
V2       cflinuxfs3                          cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5      cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
V3       kf-v2-to-v3-shim                    gcr.io/kf-releases/v2-to-v3:v2.7.0                                                                   gcr.io/buildpacks/gcp/run:v1                                                                       This is a stack added by the integration tests to assert that v2->v3 shim works
V3       google                              gcr.io/buildpacks/builder:v1                                                                         gcr.io/buildpacks/gcp/run:v1                                                                       Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
V3       org.cloudfoundry.stacks.cflinuxfs3  cloudfoundry/cnb:cflinuxfs3@sha256:f96b6e3528185368dd6af1d9657527437cefdaa5fa135338462f68f9c9db3022  cloudfoundry/run:full-cnb@sha256:dbe17be507b1cc6ffae1e9edf02806fe0e28ffbbb89a6c7ef41f37b69156c3c2  A large Cloud Foundry stack based on Ubuntu 18.04

Configura stack

La configurazione dello stack può essere aggiornata modificando la kfsystem risorsa personalizzata:

kubectl edit kfsystem kfsystem

Questo esempio imposta i Google Cloud buildpack per uno stack V3:

spec:
  kf:
    config:
      spaceStacksV3:
      - name: google
        description: Google buildpacks (https://github.com/GoogleCloudPlatform/buildpacks)
        buildImage: gcr.io/buildpacks/builder:v1
        runImage: gcr.io/buildpacks/gcp/run:v1

Ora puoi eseguire il push di questo nuovo stack:

kf push myapp --stack google

Questo esempio configura il buildpack Ruby V2 e imposta i valori predefiniti della pipeline di compilazione in modo da utilizzare gli stack V2:

spec:
  kf:
    config:
      spaceDefaultToV3Stack: false
      spaceBuildpacksV2:
      - name: ruby_buildpack
        url: https://github.com/cloudfoundry/ruby-buildpack
      spaceStacksV2:
      - name: cflinuxfs3
        image: cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5

Migrazione del buildpack da V2 a V3

Nota: questa funzionalità è attualmente sperimentale e soggetta a modifiche.

Kf fornisce uno stack V3 per creare applicazioni create con buildpack V2 standard, utilizzando uno stack denominato kf-v2-to-v3-shim. Lo stack kf-v2-to-v3-shim viene creato seguendo l'API standard dei buildpack V3. Con ogni release di Kf viene creata un'immagine del builder gestita da Google, seguendo la procedura standard del buildpack. L'immagine del builder aggrega un elenco di buildpack V3 creati con la stessa procedura utilizzata con il comando kf wrap-v2-buildpack. Le immagini del buildpack V3 vengono create utilizzando le immagini del buildpack V2 standard. È importante notare che i buildpack V3 non contengono il file binario dei buildpack V2 a cui si fa riferimento. Viene fatto invece riferimento alle immagini del buildpack V2 e i bit vengono scaricati al momento della compilazione dell'app (eseguendo kf push).

Al momento della compilazione dell'app, il buildpack V2 viene scaricato dal repository Git corrispondente. Quando viene eseguito il rilevamento V3, viene delegato allo script di rilevamento V2 scaricato. Per il primo gruppo di buildpack che supera il rilevamento, si passa al passaggio di compilazione, che delega l'esecuzione della compilazione allo script del generatore V2 scaricato.

Nello stack kf-v2-to-v3-shim sono supportati i seguenti buildpack V2:

Buildpack	Repository Git
java_buildpack	https://github.com/cloudfoundry/java-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
binary_buildpack	https://github.com/cloudfoundry/binary-buildpack
nginx_buildpack	https://github.com/cloudfoundry/nginx-buildpack

Opzione 1: esegui la migrazione delle app create con i buildpack V2 standard

Per creare app con lo stack kf-v2-to-v3-shim, utilizza il seguente comando:

kf push myapp --stack kf-v2-to-v3-shim

Lo stack kf-v2-to-v3-shim rileverà automaticamente il runtime con i buildpack V2 con wrapping. L'immagine dell'app risultante viene creata utilizzando lo standard V3 e la pipeline di compilazione, ma il builder del buildpack V2 equivalente.

Opzione 2: esegui la migrazione delle app create con buildpack V2 personalizzati

Kf dispone di uno strumento di migrazione dei buildpack che può prendere un buildpack V2 e racchiuderlo in un buildpack V3. Il buildpack incapsulato può quindi essere utilizzato ovunque siano disponibili i buildpack V3.

kf wrap-v2-buildpack gcr.io/your-project/v2-go-buildpack https://github.com/cloudfoundry/go-buildpack --publish

Verrà creata un'immagine del buildpack denominata gcr.io/your-project/v2-go-buildpack. Può quindi essere utilizzato per creare un generatore seguendo la documentazione sulla creazione di un generatore.

Questo sottocomando utilizza in modo trasparente le seguenti interfacce a riga di comando:

• go
• git
• pack
• unzip

Ti consigliamo di utilizzare l'editor di Cloud Shell per assicurarti che ogni sottocomando sia disponibile nel percorso corretto e nella versione corretta.

Problemi noti

Di seguito sono riportate le funzionalità che non funzionano ancora con Kf. Se una di queste funzionalità è una priorità per la tua organizzazione, contatta il tuo rappresentante di vendita:

• Container Registry privati per le immagini del generatore V3.
• Memorizzazione nella cache V3.
• Buildpack V2 che richiedono credenziali git.