V2- und V3-Buildpacks vergleichen

Ein Buildpack konvertiert Quellcode in eine ausführbare Datei und wird zum Bereitstellen einer einfachen, zuverlässigen und wiederholbaren Methode zum Erstellen von Containern verwendet. Kf unterstützt sowohl Build-Pakete V2 als auch V3 und es ist wichtig, die Unterschiede zwischen ihnen zu verstehen.

V2-Buildpacks

Die meisten Cloud Foundry-Anwendungen verwenden bereits V2-Buildpacks. Bei 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 und ohne Pipeline- oder Codeänderungen.

Nachteile

• Das Legacy-Buildpack wird durch V3 ersetzt.
• Schwächere Leistung und Zuverlässigkeit. Die Kf-Build-Pipeline erfordert mehr E/A für V2-Buildpacks.
• 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 durch verschiedene Sprachen und Frameworks durchführt. Google Cloud verfügt auch über eigene Buildpacks von Google Cloud.

V3-Buildpacks haben zwei zentrale OCI-Container:

• Builder-Image
• Image ausführen

Builder-Image

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

Hinweis: Die meisten Buildpacks packen 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.

Image ausführen

Das Ausführungs-Image ist das Basis-Image, auf dem ein Container erstellt wird. Dies bedeutet, dass es sich um das Basis-Image handelt, das 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 Layer-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 zugrundeliegenden Skripte anzuwenden und den Quellcode in einen lauffähigen Container zu bauen.

Vorteile

• Von Google unterstützter 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 basierend auf dem ausgewählten Stack (angegeben über das Flag --stack oder das Manifest).

Um zu sehen, welche Stacks in einem Space verfügbar sind, stellen Sie erst einmal sicher, dass ein Space ausgewählt ist:

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 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: Diese Funktion 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 gemäß der Standard-V3-Buildpacks API erstellt. Jedes von Google verwaltete Builder-Image wird mit jedem Kf-Release gemäß dem Standard-Buildpack-Prozess erstellt. Das Builder-Image aggregiert eine Liste von V3-Build-Paketen, die durch denselben Prozess erstellt wurden, der auch mit dem Befehl kf wrap-v2-buildpack verwendet wird. Die V3-Buildpack-Images werden mit den Standard-V2-Buildpack-Images erstellt. Sie sollten beachten, dass die V3-Build-Pakete die Binärdatei der referenzierten V2-Build-Pakete nicht enthalten. Stattdessen werden auf die V2-Buildpack-Images verwiesen und die Bits zum Zeitpunkt der App-Erstellung heruntergeladen (durch Ausführen von kf push).

Zum Zeitpunkt der App-Erstellung wird das V2-Buildpack aus dem entsprechenden Git-Repository heruntergeladen. Wenn die V3-Erkennung ausgeführt wird, wird sie an das heruntergeladene V2-Erkennungsskript delegiert. Für die erste Buildpack-Gruppe, die die Erkennung übergibt, wird der Build-Schritt fortgesetzt, wodurch die Build-Ausführung an das heruntergeladene V2-Builder-Skript delegiert wird.

Die folgenden V2-buildpacks werden im kf-v2-to-v3-shim-Stack 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 kf-v2-to-v3-shim-Stack erkennt automatisch die Laufzeit mit den umwickelten V2-buildpacks. Das resultierende Anwendungs-Image wird mit dem V3-Standard und der Build-Pipeline erstellt, aber mit dem Builder des entsprechenden V2-buildpack.

Option 2: Mit benutzerdefinierten V2-buildpacks erstellte Anwendungen migrieren

Kf hat ein Buildpack-Migrationstool, mit dem ein V2-Buildpack mit einem V3-Buildpack umwickelt werden kann. Das umwickelte 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 den Dokumenten Builder erstellen folgen.

Dieser Unterbefehl verwendet die folgenden Befehlszeilen transparent:

• go
• git
• pack
• unzip

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

Bekannte Probleme

Die folgenden Funktionen funktionieren noch nicht mit Kf. Wenn eine Ihrer Instanzen 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.