Buildpacks werden von Kf verwendet, um den Quellcode einer Anwendung in ein ausführbares Image umzuwandeln. Cloud Native Buildpacks verwenden die neueste Buildpack API v3. Unternehmen und VMware und Heroku nutzen aktiv v3-Support für vorhandene Buildpacks.
Kf unterstützt Buildpacks, die sowohl V2 als auch V3 der Buildpack API-Spezifikation entsprechen.
Vergleich zwischen Buildpacks V2 und V3
V2-Build-Pakete | V3-Build-Pakete | |
---|---|---|
Alternative Namen | Cloud Foundry-Build-Pakete | Cloudnative Build-Pakete (CNB), Builder-Images |
Status | Wird ersetzt | Aktuell |
Eigentümer | Cloud Foundry | Buildpacks.io |
Stapel | Von Builder und Laufzeit gemeinsam genutzt | Optional für Builder und Laufzeit |
Lokale Entwicklung | Nicht möglich | Ja, mit der Befehlszeile pack |
Kundenspezifische Build-Pakete | Zur Laufzeit verfügbar | Muss in den Builder integriert sein |
Buildpack-Lebenszyklus
Schritt | Cloud Foundry | Kf mit Buildpacks V2 | Kf mit Buildpacks V3 |
---|---|---|---|
Quellort | BITS-Dienst | Container Registry | Container Registry |
Speicherort des Buildpacks | BOSH/HTTP | HTTP | Container Registry |
Stack-Speicherort | BOSH | Container Registry | Container Registry |
Ergebnis | Droplet (Anwendungsbinärdatei ohne Stack) | Image (Droplet auf einem Stack) | Image |
Laufzeit | Droplet auf Stack zusammengefügt und ausführen | Generiertes Image ausführen | Generiertes Image ausführen |
Kf erzeugt immer aufgrund seines Build-Prozesses ein vollständiges, ausführbares Image. Cloud Foundry erzeugt hingegen Teile eines ausführbaren Image zur Build-Zeit und der Rest wird zur Laufzeit hinzugefügt.
Kf hat sich aus folgenden Gründen für das Modell entschieden, das immer ein vollständiges Image produziert:
- Images können exportiert, lokal ausgeführt und statisch geprüft werden
- Mehr Sicherheit und Prüfung mit Tools wie der Binärautorisierung
- Anwendungsbereitstellungen sind reproduzierbar
Kf- und Build-Packs
Kf speichert die globale Liste der Buildpacks und Stacks in der ConfigMap config-defaults
im Namespace kf
.
Die einzelnen Pakete werden durch das Leerzeichen im Statusfeld angegeben.
Bei einem Space mit dem Namen buildpack-docs
könntest du den folgenden Space ausführen, um die gesamte Space-Konfiguration aufzurufen:
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
Im Abschnitt Build Config
gibt es drei Felder, die Sie sich ansehen sollten:
- Buildpacks V2 enthält eine Liste der V2-kompatiblen Buildpacks in der Reihenfolge, in der sie ausgeführt werden.
- Stacks V2 gibt die Stacks an, die zum Auslösen eines Build von Buildpack V2 ausgewählt werden können.
- Stacks V3 gibt die Stacks an, die zum Auslösen eines Build von Buildpack V3 ausgewählt werden können.
Sie können die Stacks auch mit kf stacks
auflisten:
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
Da die V3-Build-Images bereits integriert sind, müssen Sie kf buildpacks
zum Abrufen der Liste verwenden:
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 ...
V3-Build-Pakete anpassen
Sie können die für Ihre Entwickler verfügbaren Buildpacks anpassen. Dazu erstellen Sie Ihr eigenes Builder-Image genau mit den Build-Paketen, auf die sie Zugriff haben sollen. Sie können auch Builder-Images verwenden, die von anderen Autoren veröffentlicht wurden.
Drittanbieter-Builder-Image verwenden
Eine Liste der veröffentlichten CNB-Stacks finden Sie in der Buildpack-Befehlszeile pack
. Zum Zeitpunkt der Erstellung dieses Dokuments gibt pack suggest-stacks
Folgendes aus:
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
Bearbeiten Sie die config-defaults
-ConfigMap im kf
-Namespace, um Kf so zu verwenden, dass der von Heroku veröffentlichte Stack verwendet wird.
Fügen Sie dem Schlüssel spaceStacksV3
einen Eintrag wie diesen hinzu:
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
Führen Sie dann stacks
noch einmal aus:
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
Eigenes Builder-Image erstellen
Mit der Buildpack-Befehlszeile pack
können Sie ein eigenes Builder-Image erstellen. Du kannst der pack
-Dokumentation Mit create-builder
mit Buildern arbeiten folgen, um ein eigenes Builder-Image zu erstellen. Wenn es erstellt ist, laden Sie es in eine Container Registry hoch und fügen es der ConfigMap config-defaults
hinzu.
Standard-Stack festlegen
Anwendungen werden ein Standardstapel zugewiesen, wenn im Manifest keine Anwendung angegeben ist. Der Standard-Stack ist der erste in der Liste der V2- oder V3-Stacks. Sofern nicht überschrieben, wird ein V2-Stack zur Kompatibilität mit Cloud Foundry ausgewählt.
Sie können erzwingen, dass Kf einen V3-Stack anstelle von V2 verwendet, indem Sie das Feld spaceDefaultToV3Stack
in der ConfigMap config-defaults
im Namespace kf
auf "true"
setzen:
kubectl edit configmap config-defaults -n kf
spaceDefaultToV3Stack: "true"
Sie können diese Option auch für jeden Raum ändern. Dazu ändern Sie das Feld spec.buildConfig.defaultToV3Stack
auf true
oder false
. Wenn kein Wert festgelegt ist, wird der Wert der ConfigMap config-defaults
verwendet.
config-defaults -Wert für spaceDefaultToV3Stack |
spec.buildConfig.defaultToV3Stack des Bereichs |
Standard-Stack |
---|---|---|
unset | unset | V2 |
"false" |
unset | V2 |
"true" |
unset | V3 |
Beliebig | false |
V2 |
Beliebig | true |
V3 |