Confronto tra 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 i buildpack V2 e V3 ed è importante comprenderne le differenze.

Buildpack V2

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

Vantaggi

  • Pronto subito 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 una specifica ben definita, un'interfaccia a riga di comando (pack) e una community in crescita che innova in base a diversi linguaggi e framework. Google Cloud dispone inoltre di un 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.

Esegui immagine

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

Base

I buildpack V3 utilizzano i livelli per comporre il container finale. A ogni buildpack incluso in una build viene data l'opportunità di manipolare le variabili del file system e di ambiente dell'app. Questo approccio a strati consente ai buildpack di essere più sottili e più generici.

I buildpack della versione 3 vengono creati su container OCI. Ciò richiede l'archiviazione dell'immagine del builder V3 in un Container Registry a cui ha accesso la pipeline di build Kf. La pipeline di build utilizza l'immagine del builder per applicare gli script sottostanti e creare il codice sorgente in un container eseguibile.

Vantaggi

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 gli stack

Quando viene eseguito il push di un'app, la pipeline di build 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 venga scelto come target uno spazio:

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 risorsa personalizzata kfsystem:

kubectl edit kfsystem kfsystem

Questo esempio imposta i buildpack di Google Cloud su 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 è possibile eseguire il push di questo nuovo stack:

kf push myapp --stack google

Questo esempio configura il buildpack Ruby V2 e imposta le impostazioni predefinite della pipeline di build in modo che utilizzino 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

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. A ogni release Kf viene creata un'immagine del builder gestita da Google, seguendo il processo buildpack standard. L'immagine del builder aggrega un elenco di buildpack V3 creati dallo stesso processo utilizzato con il comando kf wrap-v2-buildpack. Le immagini buildpack V3 vengono create utilizzando le immagini buildpack V2 standard. È importante notare che i buildpack V3 non contengono il file binario dei buildpack V2 a cui viene fatto 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 creazione dell'app, il buildpack V2 viene scaricato dal repository Git corrispondente. Quando viene eseguito il rilevamento V3, delega lo script di rilevamento V2 scaricato. Per il primo gruppo buildpack che supera il rilevamento, passa al passaggio della build, che delega l'esecuzione della build allo script del builder V2 scaricato.

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

Pacchetto build 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 build, 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 del buildpack che può prendere un buildpack V2 e includerlo 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 builder, seguendo la documentazione relativa alla creazione di un builder.

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

  • 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 è una delle 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.