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.

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

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                                                                                          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 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

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

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

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