Comparer les buildpacks V2 et V3

Un buildpack (pack de compilation) convertit le code source en fichier exécutable et permet de fournir un moyen simple, fiable et reproductible de créer des conteneurs. Kf est compatible avec les buildpacks V2 et V3, et il est important de comprendre les différences entre les versions.

Buildpacks V2

La plupart des applications Cloud Foundry utilisent déjà des buildpacks V2. Lorsque vous utilisez des buildpacks V2 avec Kf, les binaires de cycle de vie et les buildpacks sont téléchargés et configurés à partir de leurs URL Git. Kf utilise ensuite la CLI lifecycle pour exécuter chaque buildpack sur le code source.

Avantages

  • Une solution prête à l'emploi sans modification du pipeline ni du code.

Inconvénients

  • Ancien buildpack remplacé par V3.
  • Performances et fiabilité réduites. Le pipeline de compilation Kf nécessite davantage d'E/S pour les buildpacks V2.
  • Moins de ressources communautaires.
  • Kf n'est compatible qu'avec les dépôts Git OSS.

Buildpacks V3

Les buildpacks V3 sont un projet de Cloud Native Computing Foundation (CNCF) avec une spécification clairement définie, une CLI (pack) et une communauté en pleine croissance qui innove autour de langages et de frameworks différents. Google Cloud dispose aussi de son propre ensemble de buildpacks Google Cloud.

Les buildpacks V3 ont deux conteneurs OCI principaux :

  • Image de compilateur
  • Image d'exécution

Image de compilateur

L'image du compilateur est utilisée pendant l'intégration du code source dans un conteneur exécutable. L'image dispose des scripts detect et autres utilitaires nécessaires pour compiler le code source.

Image d'exécution

L'image d'exécution est l'image de base sur laquelle un conteneur est construit. Cela signifie que c'est l'image de base qui sera exécutée lors de l'exécution de l'application.

Calques

Les buildpacks V3 utilisent des couches pour composer le conteneur final. Chaque buildpack inclus dans une compilation a la possibilité de manipuler le système de fichiers et les variables d'environnement de l'application. Cette approche par couches permet de créer des buildpacks plus légers et plus génériques.

Les buildpacks V3 sont construits sur des conteneurs OCI. Cela nécessite que l'image de compilateur V3 soit stockée dans un registre de conteneurs auquel le pipeline de compilation Kf a accès. Le pipeline de compilation utilise l'image de compilateur pour appliquer les scripts sous-jacents afin de compiler le code source dans un conteneur exécutable.

Avantages

Inconvénients

  • Peut nécessiter des mises à jour de code/processus. Par exemple, le pack de création Java doit être intégré au code source, tandis que le buildpack V2 utilise un fichier JAR.
  • Les buildpacks V3 sont plus récents et peuvent nécessiter une validation supplémentaire (en cas d'utilisation de buildpacks développés par la communauté).

Piles de Kf

Afficher les piles

Lors du déploiement d'une application, le pipeline de compilation détermine le buildpack en fonction de la pile sélectionnée (spécifiée via l'option --stack ou le fichier manifeste).

Pour savoir quelles piles sont disponibles dans un espace, assurez-vous d'abord qu'un espace est ciblé :

kf target -s myspace

Vous pouvez ensuite utiliser la sous-commande kf stacks pour répertorier les piles :

kf stacks

Le résultat affiche les piles V2 et V3 :

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

Configurer les piles

La configuration de la pile peut être mise à jour en modifiant la ressource personnalisée kfsystem :

kubectl edit kfsystem kfsystem

Cet exemple définit les buildpacks Google Cloud dans une pile V3 :

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

Vous pouvez désormais déployer cette nouvelle pile :

kf push myapp --stack google

Cet exemple configure le buildpack Ruby V2 et définit les valeurs par défaut du pipeline de compilation pour utiliser les piles V2 :

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 de buildpacks V2 vers V3

Kf fournit une pile V3 pour créer des applications conçues avec des buildpacks standards V2, à l'aide d'une pile nommée kf-v2-to-v3-shim. La pile kf-v2-to-v3-shim est créée conformément à l'API Buildpack V3 standard. Une image de compilateur gérée par Google est créée avec chaque version de Kf, en suivant le processus de buildpack standard. L'image du compilateur regroupe une liste de buildpacks V3 créés par le même processus que celui utilisé avec la commande kf wrap-v2-buildpack. Les images du buildpack V3 sont créées à l'aide des images standards du buildpack V2. Important : les buildpacks V3 ne contiennent pas le binaire des buildbacks V2 référencés. Les images du buildpack V2 sont référencées et les bits sont téléchargés au moment de la compilation de l'application (en exécutant kf push).

Au moment de la création de l'application, le buildpack V2 est téléchargé à partir du dépôt Git correspondant. Au moment de l'exécution de la détection de V3, il délègue le script de détection V2 téléchargé. Pour le premier groupe de buildpacks qui réussit la détection, il passe à l'étape de compilation, qui délègue l'exécution de la compilation au script de compilation V2 téléchargé.

Les buildpacks V2 suivants sont compatibles avec la pile kf-v2-to-v3-shim :

Buildpack Dépôt Git
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 : migrer les applications créées à l'aide de buildpacks standards V2

Pour compiler des applications avec la pile kf-v2-to-v3-shim, utilisez la commande suivante :

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

La pile kf-v2-to-v3-shim détecte automatiquement l'environnement d'exécution avec les buildpacks V2 encapsulés. L'image d'application obtenue est créée à l'aide du buildpack V3 standard et du pipeline de compilation, à l'exception du compilateur du buildpack V2 équivalent.

Option 2 : migrer les applications créées à l'aide de buildpacks personnalisés V2

Kf dispose d'un outil de migration de buildpacks qui peut prendre un buildpack V2 et l'encapsuler avec un buildpack V3. Le buildpack encapsulé peut ensuite être utilisé partout où les packs de création V3 sont disponibles.

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

Cela créera une image de buildpack nommée gcr.io/your-project/v2-go-buildpack. Vous pouvez ensuite l'utiliser pour créer un compilateur en suivant la documentation sur la créer un compilateur.

Cette sous-commande utilise les CLI suivantes en toute transparence :

  • go
  • git
  • pack
  • unzip

Il est recommandé d'utiliser l'éditeur Cloud Shell pour vérifier que chaque sous-commande est bien disponible sur le bon chemin d'accès et que la version installée est correcte.

Problèmes connus

Les fonctionnalités suivantes ne sont pas encore compatibles avec Kf. S'il s'agit d'une priorité importante pour votre organisation, veuillez contacter votre conseiller commercial :

  • Registres de conteneurs privés pour les images de compilateurs V3.
  • Mise en cache V3.
  • Buildpacks V2 nécessitant des identifiants Git.