Cloud Foundry Foundation a récemment annoncé le lancement de Paketo Buildpacks pour les développeurs et opérateurs natifs du cloud. Mais quelle est la différence entre Cloud Foundry’s Packet et les Buildpacks annoncés par CNCF? Qu’est-ce que cela signifie pour les développeurs qui utilisent déjà des buildpacks? Quel type de communauté Cloud Foundry envisage-t-il de construire autour de Paketo? À quoi ressemble la feuille de route?
Pour obtenir des réponses à ces questions et plonger dans Paketo Buildpacks, Swapnil Bhartiya , fondateur de TFiR.io, s’est entretenu avec Chip Childers, directeur exécutif, Cloud Foundry Foundation et Kashyap Vedurmudi, chef de produit chez VMware.
Voici une transcription légèrement révisée de l’interview:
Swapnil Bhartiya: Aujourd’hui, nous avons deux invités, Kashyap Vidurmudi, chef de produit chez VMware, et Chip Childers, directeur exécutif de Cloud Foundry. Aujourd’hui, nous allons parler des Paketo Buildpacks récemment annoncés. Je ne veux pas entrer dans ce vieux débat sur les fichiers Docker contre Buildpacks, mais il y a deux choses dont je veux parler avant de parler de Paketo en particulier – la conformité et la sécurité. Comment Paketo Buildpacks résout-il ces deux problèmes?
Kashyap Vidurmudi: Donc, nous avons deux ou trois choses. Nous expédions constamment des Buildpacks chaque fois qu’une vulnérabilité de sécurité en amont se manifeste, une nouvelle version de la famille de langues, des choses comme ça. Ainsi, les Buildpacks facilitent la tâche, en particulier pour les utilisateurs d’entreprise, pour s’assurer en permanence que leurs applications restent à jour, sécurisées et conformes. Donc, je pense que c’est une proposition de valeur énorme de ce que Buildpacks offre par rapport à l’utilisation de fichiers Docker pour exécuter vos applications et pour créer vos applications et votre production.
Chip Childers: L’histoire du projet Cloud Foundry est, il utilise Buildpack depuis presque le début de sa création, à l’origine chez VMware, juste avant qu’il ne prenne le chemin du pivot puis du CFF. Les Buildpacks ont donc démontré leur valeur lorsqu’ils sont utilisés avec une plate-forme capable de les mettre en œuvre efficacement, à plusieurs reprises, non? En particulier, je pense à la vulnérabilité OpenSSL Heartbleed. J’ai trouvé que c’était un excellent exemple de cas où les langages et les temps d’exécution n’intègrent pas trop de choses dans leur distribution de manière statique, alors vous pouvez utiliser le processus Buildpack pour déployer très rapidement des correctifs de sécurité dans ces bibliothèques sous-jacentes vraiment importantes.
Chip Childers: À titre d’exemple, Kashyap a déclaré que le projet buildpack avec Paketo Buildpacks, ils ont toujours été à jour avec toutes leurs vulnérabilités critiques ou vulnérabilités élevées de tous les langages et cadres qui sont rassemblés. La mise à jour d’OpenSSL a été déployée dans l’ensemble de l’écosystème et elle a réussi à s’infiltrer sur toutes les plateformes sur lesquelles les CF Buildpacks étaient intégrés très rapidement, comme en quelques jours. Et c’était vraiment fluide. Le seul hic à l’époque était qu’aucun JS n’incluait réellement la bibliothèque OpenSSL dans sa propre distribution. Je pense donc que c’était environ un mois après Heartbleed qu’ils ont divisé cela, puis Buildpacks pourrait être plus efficace pour aider à prendre en charge certaines de ces bibliothèques sous-jacentes.
Swapnil Bhartiya: Merci d’avoir expliqué cela. Si je ne me trompe pas, l’année dernière, la CNCF a également annoncé un projet Buildpack. Quelle est la différence entre ce que la CNCF fait là-bas et ce que vous essayez de faire?
Kashyap Vidurmudi: C’est une excellente question et probablement la plus grande question que nous ayons posée avec tout ce lancement. Le projet CNCF Cloud Native Buildpacks a donc construit les spécifications et les outils sous-jacents nécessaires pour construire un Buildpack compatible Cloud Native. Ou le projet Paketo Buildpacks n’est qu’un ensemble d’implémentations de familles de langues en plus de ces spécifications Cloud Native Buildpack. Donc, nous construisons des implémentations lorsque nous avons lancé l’autre jour, nous avons Java, node.js, PHP, .NET Core, et probablement quelques autres qui me manquent, les implémentations Buildpack en plus de cette spécification.
Swapnil Bhartiya: Et pourquoi appelez-vous cela Paketo Buildpacks, les raisons spécifiques de cette dénomination?
Kashyap Vidurmudi: C’est aussi une excellente question. Pour être complètement honnête avec vous, toute notre équipe d’ingénieurs a effectué environ deux exercices de dénomination différents juste pour générer des noms différents pour Buildpacks. Lors d’un déjeuner d’équipe, il y a quelques mois, quelqu’un est venu avec le Paketo, qui se traduit en grec et… Désolé, cela se traduit en paquet en grec. Ce que nous avons vraiment aimé, c’est que Kubernetes traduit en pilote et en grec, et nous avons aimé cela avec Paketo traduisant un paquet en grec. Nous pouvons conclure avec l’association que Paketo conditionne vos applications sous forme d’images de conteneur que toutes les plateformes Cloud Native similaires à Kubernetes peuvent fonctionner aussi directement. Donc, le nom est resté à la fin.
Swapnil Bhartiya: Parlez un peu de la collaboration entre Cloud Foundry et VMware pour ce projet.
Chip Childers: Je veux probablement commencer par dire que le type de projet Buildpack est un projet de la Cloud Foundry Foundation, non? Et donc cela signifie que ce sont les mêmes ingénieurs et contributeurs qui travaillent sur la fonderie de cloud traditionnelle. Buildpacks construit la collection Paketo Buildpacks, non? Ainsi, vous obtenez toute leur expérience passée en tant que création et maintenance de communauté, et mise à jour de ces nouvelles choses compatibles avec Cloud Native Buildpack. L’un des objectifs de l’équipe de projet, que Kashyap pourrait également partager un peu plus, est que la collection Cloud Foundry Buildpack a traditionnellement vu l’essentiel des efforts déployés pour la maintenir provenir de pivots.
Il y avait certainement beaucoup de contributeurs occasionnels, mais c’était quelque chose sur lequel le pivot portait tout le fardeau. Et nous pensons qu’il est extrêmement important que maintenant que la spécification Cloud Native Buildpacks puisse être utilisée dans de nombreuses plates-formes différentes. Que beaucoup de participants se rallient à cela parce que c’est l’occasion d’obtenir du code Buildpack de très haute qualité dans la plate-forme que vous utilisez, que ce soit Tecton, ou Google Cloud run, ou que ce soit le CF [inaudible 00:07: 06] distribution de Cloud Foundry. Il y aura beaucoup d’utilisateurs finaux qui devraient être en mesure d’amplifier la boucle de rétroaction à l’équipe de projet. Et nous sommes très ouverts aux nouveaux contributeurs là-bas.
Swapnil Bhartiya: Quel type de communauté prévoyez-vous de construire autour de ces Buildpacks Paketo et quelles seront les ressources disponibles pour la communauté pour construire et consommer ces Buildpacks?
Kashyap Vidurmudi: Je pense que pour ajouter un peu à ce que Chip a dit, la communauté est super importante pour nous avec tout ce lancement de Paketo Buildpacks. Je pense que ce que nous recherchons idéalement, c’est un mélange de fournisseurs qui nous aident de la même façon que Cloud Foundry Foundation dans le passé, ainsi que des contributeurs individuels. Et ce qui est super excitant à voir, c’est que nous venons de lancer il y a quelques jours et nous voyons déjà un tas de personnes tendre la main et essayer Paketo Buildpacks, et intéressées à contribuer. Nous voyons que peut-être les gens pourraient être intéressés à nous aider à développer un Python, Paketo Buildpacks, ce qui est vraiment cool à voir. Pour répondre à la deuxième partie de votre question concernant un marché ou un écosystème, je pense qu’à l’avenir, ce serait super cool d’avoir quelque chose comme ça. À court terme, ce que nous faisons, c’est que nous avons avec ce concept d’images de générateur où un constructeur est en fait un ensemble de Buildpacks, Paketo Buildpacks qui y sont emballés. Nous expédions donc nos générateurs sur un registre GCR que les utilisateurs peuvent ensuite utiliser pour consommer nos Buildpacks.
Swapnil Bhartiya: Y a-t-il des Buildpacks spécifiques qui seront disponibles ou sur lesquels vous vous concentrerez pour commencer?
Kashyap Vidurmudi: Ouais. Lorsque nous avons lancé l’autre jour, nous avons officiellement Java, node.js, .NET Core, PHP et Nginx Paketo Buildpacks disponibles pour le moment. Nous commençons actuellement à créer un pack de développement Ruby Paketo et nous envisageons de publier à l’avenir une feuille de route officielle à l’échelle du projet pour montrer ce qui va suivre.
Chip Childers: Je pense que c’est une autre très bonne occasion pour les gens de s’impliquer. Comme vous l’avez dit, il y avait un intérêt organique à aider à ajouter Python en tant que Buildpack. Il y a une très longue queue de différents langages et cadres qui sont utilisés dans le contexte de l’entreprise. Et donc Paketo Buildpacks sortait la porte avec un ensemble de Buildpacks qui a essentiellement résolu la majorité des cas d’utilisation de développement d’entreprise, non? Python est très utilisé, mais c’est un peu moins que Java, non? Et donc la queue commence à baisser un peu. Mais il y a beaucoup d’opportunités dans ces langages et frameworks que l’équipe de projet Paketo Buildpacks n’a pas créés par eux-mêmes. Mais ces mêmes modèles peuvent être suivis pour les langues qui pourraient être peut-être moins utilisées.
Au fur et à mesure que la communauté se développe, pas seulement la spécification Cloud Native Buildpacks, non, car tout le monde peut créer un Buildpack selon cette spécification. Mais je pense que les pratiques du projet Paketo Buildpacks se prêtent à la distribution de qualité d’un Buildpack, non? Si vous recherchez des Buildpacks et vous levez, même si vous ne regardez que la version antérieure du fonctionnement des Buildpacks, vous en trouvez des milliers, non? Mais certains d’entre eux sont périmés, certains le sont, ils ont du travail. Et je pense que le plus important qu’exactement les Buildpacks sont proposés aujourd’hui, c’est que le projet Paketo Buildpacks est une opportunité pour les gens de se rassembler autour de la discipline de la construction de Buildpacks de qualité, puis de les maintenir au fil du temps.
Kashyap Vidurmudi: Oui, exactement. C’est vraiment un bon point. Et je pense qu’au cours des prochaines semaines ou mois à venir, nous nous concentrerons vraiment sur l’amélioration de beaucoup de notre documentation pour permettre des choses comme ça. Nous avons quelques tutoriels en ce moment juste pour aider les utilisateurs à créer un pack de construction de style Paketo et beaucoup d’outils et de choses comme ça là-bas. Donc, mon objectif final et juste sûr que Chip est d’accord avec cela, c’est-à-dire que j’aimerais voir un utilisateur venir avec très peu d’expérience Buildpack et être capable de construire, disons, un Buildpack Native Cloud Rust ou quelque chose comme ça très simplement et facilement et soutenir cela. Et c’est le but ultime où nous voulons aller en termes de permettre à la communauté de créer facilement des Buildpacks.
Swapnil Bhartiya: Qu’advient-il des Buildpacks existants que les gens utilisent déjà?
Kashyap Vidurmudi: Pour les buildpacks Cloud Foundry, nous allons continuer à fournir un support pour les charges de travail des FC dans un avenir prévisible. Donc, ce que nous avons fait, c’est que nous avons construit un concept de couche de compatibilité au-dessus de chacun de nos Paketo Buildpacks, qui nous permet d’expédier un Cloud Native Buildpack compatible Cloud Foundry. Et cela permet à vos flux de travail CF de continuer à fonctionner avec Paketo Buildpacks.
Chip Childers: Je pense que l’une des choses à comprendre, et c’est là que ça devient un peu déroutant, non? Les buildpacks en tant que concept ont une histoire assez longue. Cela a donc commencé à Heroku. CF émulait Heroku, non? C’était l’alternative open source à Heroku et il a implémenté Buildpacks afin d’avoir ce support. Et pendant un certain temps, ils étaient largement compatibles, non? Vous pouvez prendre un Heroku Buildpack et vous pouvez l’utiliser dans un contexte Cloud Foundry ou vous pouvez faire l’inverse. Et donc cela a fonctionné pendant un certain temps. Les deux plateformes, à droite, Cloud Foundry et la communauté opensource. Et puis Heroku en tant que produit ou plate-forme en tant que service, tout cela est propriétaire, ils ont commencé à diverger, non? La compatibilité au sein de l’écosystème a donc commencé à s’effondrer.
Lorsque le projet CNCF Cloud Native Buildpacks a démarré, pour moi, c’était en fait l’un des moments les plus importants de la plateforme en tant qu’espace de service depuis plusieurs années. Parce que cela représentait une reconvergence de flux de travail et d’ensembles d’expériences avec différents utilisateurs finaux qui avaient du sens pour tout le monde. Mais ce que cela signifie, c’est que la spécification CMB est, c’est une nouvelle façon de construire des Buildpacks, non? Donc, tout ce travail historique pour la construction de la communauté CF qui est important est important, mais il est vraiment essentiel de comprendre qu’un Buildpack conforme à Cloud Native Buildpack est différent d’un traditionnel Heroku ou Cloud Foundry, une ancienne version Buildpack. Ils sont mis en œuvre différemment. Et c’est donc une nouvelle génération d’entre eux. Et c’est là qu’un nouvel écosystème, car il existe plusieurs plates-formes qui ne prennent pas en charge leur utilisation,
Swapnil Bhartiya: Kashyap, vous avez mentionné qu’il y aurait beaucoup de documentation sur les ressources à venir. Quelles sont les ressources disponibles en ce moment que les gens peuvent lire ou consulter pour en savoir plus sur le projet en même temps, comment s’impliquer dans le projet?
Kashyap Vidurmudi: Ouais. Donc, en ce moment, nous avons quelques tutoriels sur la façon de démarrer avec Paketo Buildpacks ainsi que sur la façon de créer vos propres Paketo Buildpacks. En termes de démarrage et d’aide et d’implication, je pense que la meilleure façon de commencer en ce moment est de nous rejoindre sur Slack, notre Slack est Slack.paketo, PAKETO.io, ou de visiter notre site Web et de parcourir le contenu. Le site Web est PAKETO.io.
Swapnil Bhartiya: Chip et Kashyap, merci beaucoup d’avoir pris du temps sur votre emploi du temps et de nous parler aujourd’hui de ce projet. Bonne chance avec ce projet et merci encore.
