Comparer les buildpacks V2 et V3

Un buildpack convertit le code source en fichier exécutable et fournit un moyen simple, fiable et reproductible de créer des conteneurs. Kf est compatible avec les buildpacks V2 et V3. Il est important de comprendre les différences entre ces deux 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

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

Inconvénients

  • Ancien buildpack remplacé par la 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 ne prend en charge que les dépôts Git OSS.

Buildpacks V3

Les buildpacks V3 sont un projet de la Cloud Native Computing Foundation (CNCF) avec une spécification clairement définie, une CLI (pack) et une communauté en pleine expansion qui innove autour de langages et de frameworks divers. 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 de 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 utilisée pour l'exécution de l'application.

Couches

Les buildpacks V3 utilisent des couches pour composer le conteneur final. Chaque buildpack inclus dans un build 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 buildpack Java nécessite du code source, tandis que le buildpack V2 nécessite 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 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 le flag --stack ou le fichier manifeste).

Pour connaître les piles disponibles dans un espace, vérifiez d'abord qu'un espace est ciblé :

kf target -s myspace

Vous pouvez ensuite utiliser la sous-commande kf stacks pour lister 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

Il est possible de mettre à jour la configuration d'une pile en modifiant la ressource personnalisée kfsystem :

kubectl edit kfsystem kfsystem

Cet exemple définit les buildpacks Google Cloud sur 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 alors 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 V2 standards, à 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 de compilateur agrège 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 du buildpack V2 standard. Notez que les buildpacks V3 ne contiennent pas le binaire des buildpacks 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 compilation de l'application, le buildpack V2 est téléchargé depuis le dépôt Git correspondant. Lorsque la détection V3 s'exécute, il y a délégation au script de détection V2 téléchargé. Le premier groupe de buildpacks qui réussit la détection passe alors à 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 pris en charge par 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 V2 standards

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 V2 personnalisés

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 buildpacks V3 sont disponibles.

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

Cela permet de créer 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 de création d'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. Si l'une d'elles est une priorité majeure pour votre organisation, veuillez contacter votre conseiller commercial :

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