Un buildpack converte il codice sorgente in un eseguibile e viene utilizzato per creare un container semplice, affidabile e ripetibile. 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 buildpack V2 con Kf, i file binari del ciclo di vita e i buildpack vengono scaricati e configurati dai rispettivi URL Git. Kf quindi utilizza 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 sostituita da V3.
- Affidabilità e prestazioni più deboli. La pipeline di build 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 spec 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 proprio set di buildpack di Google Cloud.
I buildpack V3 hanno due container OCI generali:
- Immagine builder
- Esegui immagine
Immagine builder
L'immagine del builder viene utilizzata durante la creazione del codice sorgente in un container eseguibile. L'immagine ha gli script detect necessari e altre utilità 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 durante l'esecuzione dell'app.
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 livelli consente ai buildpack di essere più sottili e più generiche.
I buildpack V3 sono basati 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
- Immagine di builder ed esegui supportata da Google.
- Funziona con vari prodotti Google Cloud come Cloud Build.
- Community in crescita e registro buildpack.
Svantaggi
- Potrebbero richiedere aggiornamenti del codice/della procedura. 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 un'ulteriore convalida (ovvero l'utilizzo di buildpack sviluppati dalla community).
Stack Kf
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
Per elencare gli stack, puoi quindi utilizzare il sottocomando kf stacks:
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
In questo esempio viene impostato uno stack V3 per i buildpack di Google Cloud:
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 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 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 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. Vengono invece indicati alle immagini buildpack V2 e i bit vengono scaricati al momento della build dell'app (eseguendo il comando 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 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 aggregato 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 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:
gogitpackunzip
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 alcune funzioni non ancora supportate da Kf. Se una è una delle priorità per la tua organizzazione, contatta il tuo rappresentante di vendita:
- Registri di container privati per le immagini del builder V3.
- Memorizzazione nella cache V3.
- Buildpack V2 che richiedono credenziali git.