V2- und V3-Buildpacks vergleichen

Ein Buildpack konvertiert Quellcode in eine ausführbare Datei und ist eine einfache, zuverlässige und wiederholbare Methode zum Erstellen von Containern. Kf unterstützt sowohl V2-Buildpacks als auch V3-Buildpacks. Es ist wichtig, die Unterschiede zwischen ihnen zu kennen.

V2-Buildpacks

Die meisten Cloud Foundry-Anwendungen verwenden bereits V2-Buildpacks. Bei der Verwendung von V2-Buildpacks mit Kf werden die Binärdateien des Lebenszyklus und die Buildpacks über ihre Git-URLs heruntergeladen und konfiguriert. Kf verwendet dann die lifecycle-Befehlszeile, um jedes Buildpack mit dem Quellcode auszuführen.

Vorteile

• Sofort einsatzbereit, also ohne Pipeline- oder Codeänderungen.

Nachteile

• Das Legacy-Buildpack wurde durch V3 ersetzt.
• Schwächere Leistung und Zuverlässigkeit. Die Kf-Build-Pipeline erfordert für V2-Buildpacks mehr E/A-Prozesse.
• Weniger Community-Ressourcen.
• Kf unterstützt nur Open-Source-Software-Git-Repositories.

V3-Buildpacks

V3-Buildpacks sind ein Cloud Native Computing Foundation-Projekt (CNCF) mit einer klar definierten Spezifikation, einer Befehlszeile (pack) und einer wachsenden Community, die Innovationen hinsichtlich verschiedener Sprachen und Frameworks schafft. Google Cloud verfügt außerdem über eigene Buildpacks von Google Cloud.

V3-Buildpacks haben zwei übergreifende OCI-Container:

• Builder-Image
• Ausführungs-Image

Builder-Image

Das Builder-Image wird verwendet, während Ihr Quellcode in einem ausführbaren Container erstellt wird. Das Image hat die erforderlichen detect-Scripts sowie Dienstprogramme zum Kompilieren des Quellcodes.

Hinweis: Die meisten Buildpacks gruppieren die Compiler nicht zusammen mit dem Builder-Image. Stattdessen kann es sein, dass die Build-Pipelines alle Abhängigkeiten herunterladen, die zum Kompilieren erforderlich sind.

Ausführungs-Image

Das Ausführungs-Image ist das Basis-Image, auf dem ein Container aufbaut. Dies bedeutet, dass es bei Ausführung der Anwendung ausgeführt wird.

Ebenen

V3-Buildpacks verwenden Ebenen, um den endgültigen Container zu erstellen. Jedes in einem Build enthaltene Buildpack hat die Möglichkeit, das Dateisystem und die Umgebungsvariablen der Anwendung zu bearbeiten. Dieser geschichtete Ansatz ermöglicht es, Buildpacks schlanker und generischer zu machen.

V3-Buildpacks basieren auf OCI-Containern. Dies erfordert, dass das V3-Builder-Image in einer Container-Registry gespeichert wird, auf die die Kf-Build-Pipeline Zugriff hat. Die Build-Pipeline verwendet das Builder-Image, um die zugrunde liegenden Scripts anzuwenden, um aus dem Quellcode einen ausführbaren Container zu erstellen.

Vorteile

• Von Google unterstütztes Builder- und Ausführungs-Image.
• Funktioniert mit verschiedenen Google Cloud -Produkten wie Cloud Build.
• Wachsende Community und Buildpack-Registry.

Nachteile

• Erfordert möglicherweise Code-/Prozessaktualisierungen. Beispielsweise benötigt das Java-Buildpack Quellcode, während für das V2-Buildpack eine JAR-Datei erforderlich ist.
• V3-Buildpacks sind neuer und erfordern möglicherweise eine zusätzliche Validierung (verwendet von der Community entwickelte Buildpacks).

Kf-Stacks

Stacks ansehen

Beim Übertragen einer Anwendung per Push bestimmt die Build-Pipeline das Buildpack auf Basis des ausgewählten Stacks (über das Flag --stack oder das Manifest angegeben).

Damit Sie sehen können, welche Stacks in einem Gruppenbereich verfügbar sind, stellen Sie erst einmal sicher, dass auf einen Gruppenbereich abgezielt wird:

kf target -s myspace

Mit dem Unterbefehl kf stacks können dann die Stacks aufgelistet werden:

kf stacks

Die Ausgabe zeigt sowohl V2- als auch V3-Stacks:

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

Stacks konfigurieren

Die Stack-Konfiguration kann durch Bearbeiten der benutzerdefinierten Ressource kfsystem aktualisiert werden:

kubectl edit kfsystem kfsystem

In diesem Beispiel wird für die Google Cloud -Buildpacks ein V3-Stack festgelegt:

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

Dieser neue Stack kann jetzt per Push übertragen werden:

kf push myapp --stack google

In diesem Beispiel wird das Ruby V2-Buildpack konfiguriert und die Standardeinstellungen für die Build-Pipeline werden so festgelegt, dass V2-Stacks verwendet werden:

spec:
  kf:
    config:
      spaceDefaultToV3Stack: false
      spaceBuildpacksV2:
      - name: ruby_buildpack
        url: https://github.com/cloudfoundry/ruby-buildpack
      spaceStacksV2:
      - name: cflinuxfs3
        image: cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5

Migration von V2- zu V3-Buildpack

Hinweis: Dieses Feature befindet sich derzeit in der Entwicklungsphase und kann sich jederzeit ändern.

Kf stellt einen V3-Stack zum Erstellen von Anwendungen bereit, die mit Standard-V2-Buildpacks mit einem Stack namens kf-v2-to-v3-shim erstellt wurden. Der Stack kf-v2-to-v3-shim wird mit der Standard V3 Buildpacks API erstellt. Mit jedem Kf-Release wird gemäß dem Standard-Buildpack-Prozess ein von Google verwaltetes Builder-Image erstellt. Das Builder-Image aggregiert eine Liste von V3-Buildpacks, die durch denselben Prozess erstellt wurden, der auch bei dem Befehl kf wrap-v2-buildpack verwendet wird. Die V3-Buildpack-Images werden mit den Standard-V2-Buildpack-Images erstellt. Die V3-Buildpacks enthalten nicht die Binärdatei der referenzierten V2-Buildpacks. Stattdessen wird auf die V2-Buildpack-Images verwiesen und die Bits werden zum Zeitpunkt der Anwendungserstellung heruntergeladen (durch Ausführen von kf push).

Zum Zeitpunkt der Anwendungserstellung wird das V2-Buildpack aus dem entsprechenden Git-Repository heruntergeladen. Wenn die V3-Erkennung ausgeführt wird, wird an das heruntergeladene V2-Erkennungsscript delegiert. Für die erste Buildpack-Gruppe, die den Erkennungsprozess besteht, wird dann der Build-Schritt ausgeführt, wodurch die Build-Ausführung an das heruntergeladene V2-Builder-Script delegiert wird.

Die folgenden V2-Buildpacks werden im Stack kf-v2-to-v3-shim unterstützt:

Buildpack	Git-Repository
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

Option 1: Anwendungen migrieren, die mit Standard-V2-Buildpacks erstellt wurden

Verwenden Sie den folgenden Befehl, um Anwendungen mit dem Stack kf-v2-to-v3-shim zu erstellen:

kf push myapp --stack kf-v2-to-v3-shim

Der Stack kf-v2-to-v3-shim erkennt automatisch die Laufzeit mit den verpackten V2-Buildpacks. Das sich ergebende Anwendungs-Image wird zwar mit dem V3-Standard und der Build-Pipeline erstellt, aber es wird der Builder des entsprechenden V2-Buildpacks verwendet.

Option 2: Anwendungen migrieren, die mit benutzerdefinierten V2-Buildpacks erstellt wurden

Kf hat ein Buildpack-Migrationstool, mit dem ein V2-Buildpack mit einem V3-Buildpack umschlossen werden kann. Das umschlossene Buildpack kann dann überall verwendet werden, wo V3-Buildpacks verfügbar sind.

kf wrap-v2-buildpack gcr.io/your-project/v2-go-buildpack https://github.com/cloudfoundry/go-buildpack --publish

Dadurch wird ein Buildpack-Image mit dem Namen gcr.io/your-project/v2-go-buildpack erstellt. Sie können damit einen Builder erstellen, indem Sie der Anleitung zum Erstellen eines Builders folgen.

Dieser Unterbefehl verwendet die folgenden Befehlszeilen auf transparente Weise:

• go
• git
• pack
• unzip

Es wird empfohlen, mit dem Cloud Shell-Editor sicherzustellen, dass jeder Unterbefehl unter dem richtigen Pfad verfügbar ist und die richtige Version hat.

Bekannte Probleme

Die folgenden Funktionen funktionieren noch nicht mit Kf. Wenn eine der Funktionen für Ihre Organisation hohe Priorität hat, wenden Sie sich bitte an Ihren Vertriebsmitarbeiter:

• Private Container Registries für V3-Builder-Images
• V3-Caching
• V2-Buildpacks, für die Git-Anmeldedaten erforderlich sind