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

Buildpack V2

La maggior parte delle applicazioni Cloud Foundry utilizza già 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 subito senza modifiche alla pipeline o al codice.

Svantaggi

• Buildpack legacy sostituito da V3.
• 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 Cloud Native Computing Foundation (CNCF) con una specifica ben definita, un'interfaccia a riga di comando (pack) e una community in crescita che si sta innovando attorno a linguaggi e framework diversi. 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.

Nota: la maggior parte dei buildpack non pacchettizza i compilatori con l'immagine del builder. Possono invece chiedere alle pipeline di build di scaricare eventuali dipendenze richieste per la compilazione.

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 V3 sono basati 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 build utilizza l'immagine del builder per applicare gli script sottostanti e creare il codice sorgente in un container eseguibile.

Vantaggi

• Google supportava l'immagine di compilazione ed esecuzione.
• Funziona con vari prodotti Google Cloud come Cloud Build.
• Community in crescita e registro 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 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 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 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 del nuovo stack:

kf push myapp --stack google

Questo esempio configura il buildpack Ruby V2 e imposta le impostazioni predefinite 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 in fase 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 buildpacks V3 standard. 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 con la stessa procedura utilizzata 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 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, delega lo 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 buildpack standard V2

Per creare app con lo stack kf-v2-to-v3-shim, usa questo 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 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 che sia la 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.