I buildpack vengono utilizzati da Kf per trasformare il codice sorgente di un'applicazione in un'immagine eseguibile. I buildpack cloud-native utilizzano l'API Buildpack v3 più recente e aziende come VMware ed Heroku stanno aggiungendo attivamente il supporto v3 ai buildpack esistenti.
Kf supporta Buildpack conformi sia a V2 sia a V3 della specifica dell'API Buildpack.
Confronto tra buildpack V2 e V3
Buildpack V2 | Buildpack V3 | |
---|---|---|
Nomi alternativi | Buildpack Cloud Foundry | Buildpack cloud-native (CNB), immagini Builder |
Stato | In fase di sostituzione | Attuale |
Proprietà | Cloud Foundry | Buildpacks.io |
Foto simili | Condiviso da builder e runtime | Facoltativamente, diverso per builder e runtime |
Sviluppo locale | Impossibile | Sì, con l'interfaccia a riga di comando pack |
Buildpack personalizzati | Disponibile al runtime | Deve essere integrato nello strumento di creazione |
Ciclo di vita di Buildpack
Passaggio | Cloud Foundry | Kf con Buildpacks V2 | Kf con Buildpacks V3 |
---|---|---|---|
Posizione di origine | Servizio BITS | Container Registry | Container Registry |
Località Buildpack | BOSH/HTTP | HTTP | Container Registry |
Posizione stack | BOSH | Container Registry | Container Registry |
Risultato | Droplet (programma binario dell'app senza stack) | Immagine (goccia su una pila) | Immagine |
Runtime | Goccia incollata sulla pila e corsa | Esegui immagine prodotta | Esegui immagine prodotta |
Kf produce sempre un'immagine eseguibile completa come risultato del suo processo di compilazione. Cloud Foundry, invece, produce parti di un'immagine eseguibile al momento della compilazione e il resto viene aggiunto in fase di runtime.
Kf ha scelto di seguire il modello di produrre sempre un'immagine completa per i seguenti motivi:
- Le immagini possono essere esportate, eseguite localmente e ispezionate in modo statico
- Maggior sicurezza e controllo con strumenti come l'autorizzazione binaria
- I deployment delle app sono riproducibili
Kf e Buildpacks
Kf archivia il suo elenco globale di buildpack e stack nel ConfigMap config-defaults
nello spazio dei nomi kf
.
Ogni spazio riflette questi buildpack nel relativo campo di stato.
Per uno spazio denominato buildpack-docs
, puoi eseguire quanto segue per visualizzare la configurazione completa dello spazio:
kf space buildpack-docs
Getting Space buildpack-docs API Version: kf.dev/v1alpha1 Kind: Space Metadata: Creation Timestamp: 2020-02-14T15:09:52Z Name: buildpack-docs Self Link: /apis/kf.dev/v1alpha1/spaces/buildpack-docs UID: 0cf1e196-4f3c-11ea-91a4-42010a80008d Status: Build Config: Buildpacks V2: - Name: staticfile_buildpack URL: https://github.com/cloudfoundry/staticfile-buildpack Disabled: false - Name: java_buildpack URL: https://github.com/cloudfoundry/java-buildpack Disabled: false Stacks V2: - Image: cloudfoundry/cflinuxfs3 Name: cflinuxfs3 Stacks V3: - Build Image: cloudfoundry/cnb:cflinuxfs3 Description: A large Cloud Foundry stack based on Ubuntu 18.04 Name: org.cloudfoundry.stacks.cflinuxfs3 Run Image: cloudfoundry/run:full-cnb
Nella sezione Build Config
ci sono tre campi da esaminare:
- Buildpacks V2 contiene un elenco di buildpack compatibili V2 nell'ordine di esecuzione
- Stack V2 indica quali stack possono essere scelti per attivare una build Pack V2
- Stack V3 indica quali stack possono essere scelti per attivare una build Pack V3
Puoi anche elencare gli stack con kf stacks
:
kf stacks
Getting stacks in Space: buildpack-docs Version Name Build Image Run Image Description V2 cflinuxfs3 cloudfoundry/cflinuxfs3 cloudfoundry/cflinuxfs3 V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3 cloudfoundry/run:full-cnb A large Cloud Foundry stack based on Ubuntu 18.04
Poiché i buildpack sono già integrati nelle immagini build V3, devi usare kf buildpacks
per ottenere l'elenco:
kf buildpacks
Getting buildpacks in Space: buildpack-docs Buildpacks for V2 stacks: Name Position URL staticfile_buildpack 0 https://github.com/cloudfoundry/staticfile-buildpack java_buildpack 1 https://github.com/cloudfoundry/java-buildpack V3 Stack: org.cloudfoundry.stacks.cflinuxfs3: Name Position Version Latest org.cloudfoundry.jdbc 0 v1.0.179 true org.cloudfoundry.jmx 1 v1.0.180 true org.cloudfoundry.go 2 v0.0.2 true org.cloudfoundry.tomcat 3 v1.1.102 true org.cloudfoundry.distzip 4 v1.0.171 true org.cloudfoundry.springboot 5 v1.1.2 true ...
Personalizzazione dei buildpack V3
Puoi personalizzare i buildpack disponibili per i tuoi sviluppatori creando la tua immagine del builder con esattamente i buildpack a cui dovrebbero avere accesso. Puoi anche utilizzare immagini del builder pubblicate da altri autori.
Utilizza l'immagine di uno strumento per la creazione di terze parti
Un elenco degli stack CNB pubblicati è disponibile nell'interfaccia a riga di comando Buildpack pack
. Al momento della stesura di questo articolo, pack suggest-stacks
restituisce:
pack suggest-stacks
Stacks maintained by the community:
Stack ID: heroku-18 Description: The official Heroku stack based on Ubuntu 18.04 Maintainer: Heroku Build Image: heroku/pack:18-build Run Image: heroku/pack:18
Stack ID: io.buildpacks.stacks.bionic Description: A minimal Cloud Foundry stack based on Ubuntu 18.04 Maintainer: Cloud Foundry Build Image: cloudfoundry/build:base-cnb Run Image: cloudfoundry/run:base-cnb
Stack ID: org.cloudfoundry.stacks.cflinuxfs3 Description: A large Cloud Foundry stack based on Ubuntu 18.04 Maintainer: Cloud Foundry Build Image: cloudfoundry/build:full-cnb Run Image: cloudfoundry/run:full-cnb
Stack ID: org.cloudfoundry.stacks.tiny Description: A tiny Cloud Foundry stack based on Ubuntu 18.04, similar to distroless Maintainer: Cloud Foundry Build Image: cloudfoundry/build:tiny-cnb Run Image: cloudfoundry/run:tiny-cnb
Per modificare Kf in modo da utilizzare lo stack pubblicato da Heroku, modifica il ConfigMap config-defaults
nello spazio dei nomi kf
.
Aggiungi una voce alla chiave spaceStacksV3
come segue:
kubectl edit kfsystem kfsystem
spaceStacksV3: | - name: org.cloudfoundry.stacks.cflinuxfs3 description: A large Cloud Foundry stack based on Ubuntu 18.04 buildImage: cloudfoundry/cnb:cflinuxfs3 runImage: cloudfoundry/run:full-cnb - name: heroku-18 description: The official Heroku stack based on Ubuntu 18.04 buildImage: heroku/pack:18-build runImage: heroku/pack:18
Quindi, esegui di nuovo stacks
:
kf stacks
Getting stacks in Space: buildpack-docs Version Name Build Image Run Image Description V2 cflinuxfs3 cloudfoundry/cflinuxfs3 cloudfoundry/cflinuxfs3 V3 org.cloudfoundry.stacks.cflinuxfs3 cloudfoundry/cnb:cflinuxfs3 cloudfoundry/run:full-cnb A large Cloud Foundry stack based on Ubuntu 18.04 V3 heroku-18 heroku/pack:18-build heroku/pack:18 The official Heroku stack based on Ubuntu 18.04
Crea la tua immagine del builder
L'interfaccia a riga di comando Buildpack pack
viene utilizzata per creare la tua immagine del builder. Puoi seguire la documentazione di pack
relativa all'utilizzo dei builder con create-builder
per creare la tua immagine del builder. Una volta creato, eseguine il push a un Container Registry e aggiungilo al ConfigMap config-defaults
.
Impostazione di uno stack predefinito
Alle app verrà assegnato uno stack predefinito se non ne è specificato uno nel file manifest. Lo stack predefinito è il primo nell'elenco di stack V2 o V3. Se non viene eseguito l'override, viene scelto uno stack V2 per garantire la compatibilità con Cloud Foundry.
Puoi forzare Kf a utilizzare uno stack V3 anziché V2 impostando il campo spaceDefaultToV3Stack
nel ConfigMap config-defaults
nello spazio dei nomi kf
su "true"
:
kubectl edit configmap config-defaults -n kf
spaceDefaultToV3Stack: "true"
Questa opzione può anche essere modificata in base allo spazio cambiando l'impostazione del campo spec.buildConfig.defaultToV3Stack
in true
o false
. Se non viene configurato, viene utilizzato il valore del ConfigMap config-defaults
.
Valore config-defaults per spaceDefaultToV3Stack |
spec.buildConfig.defaultToV3Stack dello spazio |
Stack predefinito |
---|---|---|
non impostato | non impostato | V2 |
"false" |
non impostato | V2 |
"true" |
non impostato | V3 |
qualsiasi | false |
V2 |
qualsiasi | true |
V3 |