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 spec, 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.

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

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                                                                                          Description
V2       cflinuxfs3                          cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5      cloudfoundry/cflinuxfs3@sha256:5219e9e30000e43e5da17906581127b38fa6417f297f522e332a801e737928f5
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

Hinweis: Diese Funktion befindet sich derzeit in der Entwicklungsphase und kann sich jederzeit ändern.

Kf hat ein Migrationstool, mit dem ein V2-Buildpack umwickelt werden kann. Das Ergebnis ist ein V3-Buildpack, das in einem V3-Builder verwendet 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

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.