Cloud Foundry Advisory Board Call, Jan 2022: Feedback Around Buildpacks
The first Cloud Foundry Community Advisory Board (CAB) meeting for 2022 centered around developer experience regarding buildpacks and a summary of updates from the working groups. The call was moderated by Ram Iyengar from the CF Foundation.
Community experience with buildpacks
Buildpacks provide framework and runtime support for applications. By identifying dependencies, buildpacks determine how to configure apps, so they can communicate with bound services. In 2018, Pivotal (now, part of VMware) and Heroku began the Cloud Native Buildpacks project, to create a public, cross-platform build tool serving major modern programming language ecosystems. (You can read more about Cloud Native Buildpacks in this series.)
During the call, various community members expressed how the project has made it easier to develop applications and how helpful the Paketo Slack community have been. They also shared some of the issues they faced while using Cloud Native Buildpacks and inquired about possible features that can be implemented in the future. Lakshmi Narasimhan Parthasarathy, Principal Engineer at Platformatory, raised an issue that was specific to Drupal.
“Buildpacks aggressively cache your image layers, and the way a Drupal project is structured is [that] composer packages [are] installed alongside the source code in the same directory scaffold. So, whenever you’re building a new image from a cache layer, all your composer packages go away.” —Lakshmi Narasimhan Parthasarathy, Platformatory
Lakshmi also shared a limitation in Python when installing dependencies. “The buildpack expects
requirements.txt, which is a catalog of all the library dependencies for Python applications, to be present at the top-level directory,” he explained. “There is no way to configure that to be anywhere else. In a typical Django project, [the requirements are] in different folders. For example, you might have the dev version of the requirements in
dev.txt and the production version in
production.txt. There is no way to specify an alternative name or folder structure for the requirements.
With Paketo buildpacks being built around Ubuntu, Jerico Pena, Senior Software Engineer at Rapid7, asked whether or not there were any plans to create a version for Red Hat. In response, Sophie Wigmore, Software Engineer at VMware and Core Engineer of the Paketo team, acknowledged that Paketo buildpacks currently support only the Ubuntu stack image, but supporting universal base images (UBIs) is a direction the team is considering. She also suggested that Paketo buildpacks might still work with different operating systems, and there are methods that can be used to make custom stacks.
“The main issue is that we compile all of our dependencies from source against Ubuntu. There’s a pretty high chance that some of those dependencies will just work depending on what the stack is, and you may not actually have to recompile them. You could support you own custom stack…you could use all the different boiler plates that we have and sub in whatever base image you want. Use our tooling that exists within Paketo to bundle up that stack and use it inside a builder, and that should take you very far depending on which operating system you’re trying it for.” —Sophie Wigmore, VMware
- Will there be a Cloud Foundry shim for Paketo buldpacks in the staging process?
- Are there plans to integrate DockerSlim or similar tools to make containers smaller, and, more importantly, a lot more secure by default?
Most of the concerns raised by the community are already being discussed within the Paketo team. Sophie and Timothy Hitchener, Member of Technical Staff 2 at VMware and also Core Engineer of the Paketo team, recommended bringing up and discussing existing issues in the Paketo Slack channel to further increase awareness and possibly shift development priorities.
The Paketo working group regularly meets on Tuesday at 2 a.m. ET. Sophie and Timothy encouraged community members to join the weekly working group meetings to add to the discussion.
During the call, Ram noted that some of the working groups, such as Application Runtime Platform and Foundational Infrastructure, have already adopted an open roadmap to make developments more transparent to the community.
“Folks can now see what different people are working on. We can get an idea of where the contributors’ heads are at. This also helps us to understand where any of the new issues and pull requests line up.” —Ram Iyengar, Cloud Foundry Foundation
The next CAB call is tentatively scheduled on February 16, 2022, at 11 a.m. ET / 8 a.m. PT. Anyone interested in participating can join the Cloud Foundry’s CAB Slack channel.
Want details? Watch the video!
Below, you can also find the recording of the latest Technical Oversight Committee meeting.