0

Guests: Ram Iyengar (LinkedIn) | Timothy Hitchener (LinkedIn)
Organization/Company: Cloud Foundry Foundation (CFF) (Twitter) | VMware (Twitter)
Show: Let’s See

The Paketo open-source project provides production-ready buildpacks for the most popular languages and frameworks. These buildpacks transform source code into container images. In this episode of TFiR: Let’s See, Cloud Foundry Foundation (CFF) Chief Evangelist Ram Iyengar and VMware Technical Staff 3 Timothy Hitchener talk about the Paketo project and demonstrate how to use buildpacks within a developer workflow.

Highlights of this video demo:

  • Buildpacks are scripts that help build containers. The cloud native aspect of it has been something that the Cloud Foundry community has been working on for about five years now. It’s an evolution of buildpacks from the days of Heroku and Pivotal and bringing it into this new era of containers and Kubernetes.
  • The experience is inspired heavily by the developer workflow of “Come with your source code and leave with like an immutable artifact.”
  • The Cloud-Native Buildpack (CNB) specification lays out how a buildpack should behave.
  • The Paketo Buildpack Project serves as an implementation of that CNB specification. Anyone who wants to conform to the CNB spec can use the suite of scripts and trust that it will function exactly as outlined.
  • Paketo essentially outputs an Open Container Initiative (OCI)-compatible container image, which can piggyback onto any existing Docker-based workflow. There are some parts of the entire CNB specification that make use of Docker in order to create things like sacks, meaning, there is a good amount of Interplay happening between Paketo, Cloud Native Buildpacks, and Docker.
  • With buildpacks, there is no need to mess around with Docker files or redo existing infrastructure.
  • The list of Paketo adopters includes Bloomberg, fly.io, railway.app, and DigitalOcean.
  • Smaller teams and startups get the benefit of quick iteration. Paketo buildpacks detect what’s needed from your source code. Security is baked in during the development process, not an afterthought.
  • Iyengar started the demo by kicking off a build with the pack command, a CLI that consumes the cloud native buildpacks. The CLI is going to make use of the Paketo buildpacks in order to create a container image of a Node.js.
  • What gets initiated is a buildpack lifecycle with different phases (detect, analyze, export).
  • Hitchener walked through the details of the build process. During the detect phase, the detect binary tries to figure out what the application image will need, given the source code, and decides which buildpacks are going to participate in the build process. The output includes a build plan, a description of why a buildpack is not participating in the process, a software bill of materials (SBOM), which complies with the executive order from the current administration and with all the talk about supply chain security.  
  • It also shows the configurations for what the run command is like. No need to specify an entrypoint.sh and keep those maintained because buildpacks are fully capable of detecting all of these based on the files that are a part of the source itself. The image that has been built, i.e., an OCI container with the name that was specified has been actually exported from this process.
  • In the next part of the demo, Iyengar explained the pack inspect command, the pack CLI way of showcasing what’s inside the actual image. It contains the buildpacks used, the processes that were used, and information about the base image. At this point, a docker inspect command or a docker run command will work.
  • Hitchener then proceeded to do a pack sbom download, which downloads a layer containing the structured software bill of materials from specified image.
  • Paketo, being an open-source project, borrows from the upstream Cloud Native Buildpack, which is also a CNCF-owned open-source project. It is always looking for more contributors, adopters, and maintainers. Folks who want to enable a great platform for their developers and software engineering teams are most welcome to do so.

This summary was written by Camille Gregory.

You may also like