Effective immediately, we are announcing the deprecation of the Windows Container feature in Cloud Native Buildpacks. This feature will no longer be supported and will be removed from future lifecycle versions starting in 2025.

This change does not impact Windows distributions of the Pack CLI, which will continue to be supported. The project is committed to ensuring a great experience for Windows users.

This decision was made to focus our efforts on maintaining and enhancing features that provide the most value to the Buildpacks community and ecosystem. The removal of the Windows Container feature will allow us to prioritize investments in areas that better align with the current and future needs of our users.

Key Dates

• Immediate Deprecation: Effective today, the Windows Container feature is officially deprecated.
• Removal Timeline: The feature will be completely removed in lifecycle versions released in 2025 and beyond.

Recommended Actions

For teams relying on the Windows Container feature, we recommend:

1. Evaluating alternative strategies for building and running applications within the Cloud Native Buildpacks ecosystem.
2. Exploring container solutions and platforms that align with your operating system requirements.
3. Reaching out to the community or support channels for guidance and migration assistance.

For more information, please see the Remove Windows Containers support RFC.

We appreciate your understanding as we make this transition to better support the community. For any questions, concerns, or feedback, please reach out via our GitHub repository or community forums.

Thank you,
The Cloud Native Buildpacks Team

Deprecation Announcement: Windows Container Feature in Cloud Native Buildpacks was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post discusses the high severity vulnerabilities identified in the review and provides links to the full list of vulnerabilities and their remediations. Findings and recommendations from the review are also discussed on Quarkslab’s blog and OSTIF’s blog.

Spotlight: high severity issues

Many of the vulnerabilities, especially the high severity ones, relate to the use of pack and the lifecycle in CI/CD systems, such as multi-tenant build environments using a shared Docker host.

(High 1) Host compromise by overwriting trusted container images — this can occur when a shared Docker host is used as both a source and a sink for build input and output images. A malicious pack user could build an application image with the same image name as a build input (such as builder, lifecycle, or run images), causing future builds by other users of the build system to pull in the malicious input. We address this problem by:

• Forbidding application names that match trusted build inputs (pack issue)
• Warning pack users to pull build inputs from a registry when we detect that pack is running in a container (a common scenario for a shared Docker host) (pack issue)

A registry is a safer source for build inputs as user permissions prevent unauthorized writes

• Informing our end users that using ​​a shared Docker host as a source for build inputs is insecure

(High 2) Cache poisoning by accessing other applications’ caches — this can occur when volumes managed by a shared Docker host are used as build and launch caches. We address this problem by:

• Introducing the concept of a pack “volume key” that will make volume names difficult to determine without the key (pack issue)
• Informing our end users that cache images (stored in a registry) are safer repositories for build caches (see above re: user permissions)

In total

The full list of vulnerabilities identified and their remediations are shown below:

(High 1) Host compromise by overwriting trusted container images

• See work to validate application names and warn if NOT — pull-policy=always in container, released in pack 0.35.0

(High 2) Cache poisoning by accessing other applications’ caches

• See work to ensure ownership of build and launch caches, released in pack 0.35.0

(Med 1) Docker in-container privilege escalation

• See work to set security-opt field to no-new-privileges:true, released in pack 0.35.0

(Med 2) Docker permissive inter-container connectivity

• See work to launch build containers in a separate ephemeral Docker bridge network, released in pack 0.35.0

(Low 1) Denial-of-Service (DoS) provoked by race condition

• Partially mitigated by work to recover corrupt caches, released in lifecycle 0.20.0; see also a strategy considered to prevent simultaneous builds of applications having the same name that we chose not to implement at this time

(Low 2) Denial-of-Service (DoS) provoked by removing build cache tarballs or altering the OCI image manifest

• Partially resolved (for volume caches) by work to recover corrupt caches, released in lifecycle 0.20.0

(Low 3) Denial-of-Service (DoS) provoked by an unbound execution time

• We chose not to address this one at this time, leaving management up to the platform or end user; see issue to bound buildpack execution time

(Low 4) Data leak by accessing other applications’ caches

• See work to ensure ownership of build and launch caches, released in pack 0.35.0

(Info 1) Specification violation using Docker and user namespaces

• See work to run build containers with userns=host, released in pack 0.35.0

(Info 2) Excessive Docker container capabilities

• We are leaving this one open for further investigation, see issue to investigate which container capabilities are truly needed for build

Feedback welcome

The CNB project is constantly striving to make our software the most secure and reliable for platforms and developers everywhere.

Found a security issue? We appreciate your help! Follow the instructions in our security policy to report it responsibly.

Got feedback or want to join the conversation? Head over to our community page. We’d love to hear from you!

Announcing findings from security audit was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a maintainer and team lead for the Implementation Team, Natalie has overseen a period of great innovation in the Buildpacks project. Her team is responsible for delivering Extensions and Dockerfile support, while ensuring the overall health of the buildpack lifecycle. She’s now the all-time leading committer to the lifecycle. Natalie has also been able to help grow the project’s community as a mentor for programs including Google Summer of Code and the Linux Foundation Mentorships.

Natalie’s passion for all aspects of the project, from documentation to low-level engineering, help to ensure the high quality of experience we deliver. Even more importantly though, her kindness, fairness, and leadership help to make our community strong.

Congratulations Natalie!

Natalie Arellano joins the Buildpack TOC was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

KubeCon + CloudNativeCon Europe 2024 is NEXT WEEK and we’re so excited to see everyone in Paris! Below are the opportunities you have to attend talks covering Buildpacks to learn more about the project and engage with us and other members of the community. It’s a great way to ask questions, meet the team in person, provide feedback, and connect with others in the community. We look forward to seeing you there!

Note: All times mentioned below are in Central European Time (CET), UTC +1

Pre-Event Content — Tuesday, March 19

Sponsored Keynote at AppDeveloperCon

10:20–10:25, Pavilion 7 | Level 7.3 | Room S04: Streamlining Your Application Builds with Cloud Native Buildpacks — Vish Abrams, Heroku

Note: You need an all-access pass to attend AppDeveloperCon, a co-located event.

Project Lightning Talk

11:30–11:37, Pavilion 7 | Level 7.1 | Room D: Container Builds at Scale with Buildpacks — Joe Kutner, Salesforce

Note: You DO NOT need an all-access pass to attend the project lightning talks. A regular in-person registration (KubeCon + CloudNativeCon Only Pass) is all that is required.

Talks and Interactive Sessions — Main Conference

Wednesday, March 20

• Keynote: Platform Building Blocks: How to Build ML Infrastructure with CNCF Projects — Yuzhui Liu, Team Lead & Leon Zhou, Software Engineer, Bloomberg
   — 10:15–10:30
   — Pavilion 7 | Level 7.3 | Paris Room
• Contribfest: Diving Into Buildpacks: Improving the Pack CLI — Natalie Arellano, Broadcom & Aidan Delaney, Bloomberg
   — 14:30–16:00
   — Pavilion 7 | Level 7.3 | W01
• Building AI-Ready Platforms — Symphony for Developer and Platform Engineer — Thomas Vitale, Systematic & Lize Raes, LangChain4
   — 15:25–16:00
   — Pavilion 7 | Level 7.1 | Room B

Thursday, March 21

• Maintainer Track Session: Container Image Workflows at Scale with Buildpacks — Juan Bustamante, Broadcom & Aidan Delaney, Bloomberg
   — 17:25–18:00
   — Pavilion 7 | Level 7.3 | E01–02

Friday, March 22

• Building Container Images the Modern Way — Adrian Mouat, Chainguard
   — 11:00–11:35
   — Pavilion 7 | Level 7.3 | S05

Buildpacks Kiosk in the Project Pavilion

The Buildpacks project will have a kiosk in the Project Pavilion, located in the Solutions Showcase, during the afternoon times each day of the conference, starting on March 20. See below for more information on these staffed times and the kiosk location to know when to learn more about the project, ask questions, provide feedback, and meet the team.

The kiosk will be staffed by Buildpacks TOC members, maintainers, contributors, and community volunteers at the following times:

• Wednesday, March 20
   — 15:00–18:00
   — 18:00–20:00 (during KubeCrawl +CloudNativeFest)
• Thursday, March 21
   — 13:30–17:00
• Friday, March 22
   — 12:30–14:30

Join the Buildpacks Community

We are excited to hear from you and learn with you! Here are several ways you can get involved:

• Join Buildpacks’ slack channel, #buildpacks in CNCF workspace, and connect with Buildpacks’ users.
• Find us on GitHub. Suggest how we can improve the project, the docs, or share any other feedback.
• Attend our Community Meetings! Check out the Community page for full details on how to attend.

Buildpacks in Paris for KubeCon + CloudNativeCon Europe was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you are attending KubeCon + CloudNativeCon North America we’d love to meet you! Below are the opportunities you have to come engage with us and other members of the Buildpacks community. It’s a great way to ask questions, meet the team in person, provide feedback, and connect with others in the community. We look forward to seeing you there!

In-Person Project Meeting

Monday, November 6 • 1:00–3:00PM, Room Stutz (Hilton, level 3), Hilton Garden Inn McCormick Place (Connected to McCormick Place by skybridge. The skybridge at McCormick Place is on level 3.)

Join us for general welcome and introduction to Buildpacks. We’ll give an overview of the project and what the team is working on next. Then, we’ll open it up for anything folks wish to bring up: demo requests, feedback, feature requests, general discussions/questions.

Note: You DO NOT need an all-access pass to attend a project meeting. A regular in-person registration is all that is required.

Project Pavilion

Stop by our kiosk (#F11) in the project pavilion to say hello and grab some new swag! The pavilion will be staffed by TOC members, maintainers, contributors, and community volunteers at the following times:

• Tuesday, November 7
   — 10:30AM–8:00PM (includes KubeCrawl +CloudNativeFest from 6:00–8:00 PM)
• Wednesday, November 8
   — 10:30AM–5:00PM
• Thursday, November 9
   — 10:30AM–2:30PM

Maintainer Track Breakout Session

Thursday, November 9 • 2:00–2:35PM, Room W187 (McCormick Place)

Getting Buildpacks Ready for the Multi-Architecture Future with Terence Lee, Heroku (Salesforce) & Juan Bustamante, VMware

We will start with the basics of Buildpacks, Buildpack Platforms, and how one can easily distribute Buildpacks with Builder Images. ARM64 is known for being energy efficient and has gained popularity between Apples’ M1/2 chips and Amazon Web Services’ Graviton Processor. Supporting multi-architecture images is one of the top asks from the community. In this talk, we’ll discuss the challenges of supporting multi-architecture application images and how Buildpacks help solve this problem. We will show how this is possible with multi-architecture Buildpacks and Builder Images.

Join the Buildpacks Community

We are excited to hear from you and learn with you! Here are several ways you can get involved:

• Join Buildpack’s slack channel, #buildpacks in CNCF workspace, and connect with Buildpack’s users.
• Find us on GitHub. Suggest how we can improve the project, the docs, or share any other feedback.
• Attend our Community Meetings! Check out the Community page for full details on how to attend.

Buildpacks in Chicago for KubeCon + CloudNativeCon North America was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s take a look at an example of how this might be valuable. After following the steps to export the sample java application to OCI layout format on disk, we end up with something similar to:

sample-app
├── blobs
│ └── sha256
│     ├── 141bfb0cd434d425bc70edb9e56ea11d07aed76450eb0e73e6110645f251a8d3
│     ├── 2fa192256ce255c6ea6c1296eadfe2feba8094f40e6aa85e699645caca2e85d8
│     ├── 5a44e4f7b58d74fe6f92dd7028075c91191128d1e2e7f39846fe061a9a98836e
│     ├── 72d9f18d70f395ff9bfae4d193077ccea3ca583e3da3dd66f5c84520c0100727
│     ├── 827746ec7ba80f4e4811b6c9195b6f810fbc2d58a6c9cc337bf0305791f24e97
│     ├── ad13830c92258c952f25d561d8bf7d9eb58b8a3003960db1502cbda8239130b5
│     ├── b97b58b190d5f731c879b0f7446a2bd554863b51851e03757199c74dd922ce61
│     ├── c44222730efa142cd5bedc0babf82a9a07d325494be7f5c3cfde56f43166b65f
│     ├── e1048fb89c3194a1f0542c0847aa086a7034dd7867c48fe8c93675cf36f90610
│     ├── f0a30c5bc44742065b1b4ffa95271a39994f05ba7a03dd7e7143d1d3e45fa0b1
│     └── f9d6350d0c44c0e7165a522155f53181ce8c163a6b8ead1f6baea22d1a8d8a78
├── index.json
└── oci-layout  

3 directories, 13 files

Now we can use a tool like grype to scan a Java Application image and detect any vulnerabilities before pushing it to the registry or promoting it to a next step in our CI/CD pipeline.

> grype oci-dir:sample-app/
 ✔ Vulnerability DB        [no update available]
New version of grype is available: 0.66.0 (currently running: 0.57.1)
 ✔ Parsed image
 ✔ Cataloged packages      [228 packages]
 ✔ Scanned image           [87 vulnerabilities]

NAME               INSTALLED                 FIXED-IN        TYPE          VULNERABILITY        SEVERITY
bash               5.1-6ubuntu1                              deb           CVE-2022-3715        Low
coreutils          8.32-4.1ubuntu1                           deb           CVE-2016-2781        Low
gcc-12-base        12.3.0-1ubuntu1~22.04                     deb           CVE-2022-27943       Low
gpgv               2.2.27-3ubuntu2.1                         deb           CVE-2022-3219        Low
jackson-databind   2.9.10.6                                  java-archive  CVE-2020-25649       High
jackson-databind   2.9.10.6                                  java-archive  CVE-2020-35490       High

In this way, we avoid needing to remove the vulnerable image after it’s already been stored in a registry (and potentially has been pulled by other systems).

Please join our slack channel if you’d like to share comments about this feature, or if you’d like to discuss other interesting use cases that you have for a local OCI image.

If you want to know more, you can find all the details in Pack documentation.

Join the Buildpack community

We are excited to hear from you and learn with you! Here are several ways you can get involved:

• Join Buildpack’s slack channel, #buildpacks in CNCF workspace, and connect with Buildpack’s users.
• Find us on GitHub. Suggest how we can improve the project, the docs, or share any other feedback.
• Attend our Community Meetings! Check out the Community page for full details on how to attend.

Use Pack to export your image to disk in OCI layout format was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The goal of this tutorial is to build a Bash application without using platform tools like pack or kpack. We will leverage the individual phases of the buildpack lifecycle to produce the application-run image.

Note: Depending on your computer architecture, the tutorial will have slightly different instructions.

Let’s get started! 📚

Getting started

To begin this tutorial, we’ll need a local copy of the lifecycle and the official Buildpack.io samples:

git clone https://github.com/buildpacks/lifecycle
git clone https://github.com/buildpacks/samples

The lifecycle orchestrates buildpack execution and then assembles the resulting artifacts into a final app image. It is composed of multiple phases that need to be executed to have the final image built and exported.

Of course, we need to build the lifecycle in order to use all its phases. You can do it by going into the lifecycle directory and executing

For AMD64 architectures

make build

For ARM64 architectures

 make build-darwin-arm64

Important Environment Variables

In order to execute the various phases correctly, we need to first set these environment variables:

CNB_USER_ID
CNB_GROUP_ID
CNB_PLATFORM_API
CNB_SAMPLES_PATH
CNB_LIFECYCLE_PATH

• CNB_USER_ID,CNB_GROUP_ID: The user and group ID are arbitrary values that need to be consistent. The usual value for both is 1000, which we can use through this tutorial.
• CNB_PLATFORM_API: Platform API version will vary depending on your use case. This tutorial makes use of v0.12, which is the most recent at the time of writing this post.
• CNB_SAMPLES_PATH: The path of our local samples directory
• CNB_LIFECYCLE_PATH: The path of our local compiled lifecycle dir

Run the following commands in the terminal to set these values:

export CNB_USER_ID=1000 CNB_GROUP_ID=1000 CNB_PLATFORM_API=0.12
export CNB_SAMPLES_PATH="/<your-path>/samples"
export CNB_LIFECYCLE_PATH="/<your-path/lifecycle/out/<your-arch>/lifecycle"`

Phases

We are going to go through each of the lifecycle’s phases except for the Creator which combines all of them in one go:

1. Analyze
2. Detect
3. Restore
4. Build
5. Export

Analyze

The analyze phase runs before the detect phase in order to validate registry access for all images that are used during the build as early as possible. In this way it provides faster failures for end users

We need to create some directories

mkdir -p apps/bash-script
mkdir -p layers

Those commands will create two directories in the root called apps, which contains a bash-script directory, and layers. The layers directory contains subdirectories representing each layer created by the buildpack in the final image or build cache. Essentially it's our working directory

Then we need to copy the bash-script samples into our apps/bash-script directory. Here is where our app's source code will stay for simplicity.

cp -r "$CNB_SAMPLES_PATH/apps/bash-script/" ./apps/bash-script

Let’s call the analyzer:

For AMD64 architectures

$CNB_LIFECYCLE_PATH/analyzer -log-level debug -daemon -layers="./layers" -run-image cnbs/sample-stack-run:bionic apps/bash-script

For ARM64 architectures — the one I’m using in this tutorial

$CNB_LIFECYCLE_PATH/analyzer -log-level debug -daemon -layers="./layers" -run-image arm64v8/ubuntu:latest apps/bash-script

This command will run the analyzer with:

• a debug level of logging
• pointing to our local docker daemon
• pointing to our layers directory, which is the main lifecycle working dir
• running the specified image
• with the path to the app that we are analyzing

Output

The output we will see looks like this one:

❯ $CNB_LIFECYCLE_PATH/analyzer -log-level debug -daemon -layers="./layers" -run-image cnbs/sample-stack-run:bionic apps/bash-script
Starting analyzer...
Parsing inputs...
Ensuring privileges...
Executing command...
Timer: Analyzer started at 2023-08-29T11:22:26+02:00
Image with name "apps/bash-script" not found
Found image with identifier "96f1071770b9f69d475d73d2b033ac869e76fcf6f944116df94f1ffa4cb33e36"
Timer: Analyzer ran for 216.833µs and ended at 2023-08-29T11:22:26+02:00
Run image info in analyzed metadata is:
{"Reference":"96f1071770b9f69d475d73d2b033ac869e76fcf6f944116df94f1ffa4cb33e36","Image":"cnbs/sample-stack-run:bionic","Extend":false,"target":{"os":"linux","arch":"amd64"}}

Since we are using the Platform API v0.12, it is going to check if it has the right privileges, and now inside our layers directory we should have a analyzer.toml file with a bunch of null entries.

Detector

The detector looks for an ordered group of buildpacks that will be used during the build phase

The detector requires an order.toml being present in the root dir, let's craft a new one from samples builder.toml removing the stack section:

cat "$CNB_SAMPLES_PATH/builders/jammy/builder.toml" | grep -v -i "stack" | sed 's/\.\.\/\.\./\./' > order.toml

An order.toml file contains a list of groups, and each group itself contains a list of buildpacks. The detector reads order.toml and looks for the first group that passes the detection process.

Set buildpacks layout directory

Let’s create a buildpacks dir in the root:

mkdir -p buildpacks

Then we need to populate it with the buildpacks we want or need. We have to follow the directory layout defined in the buildpack spec, where each top-level directory is a buildpack ID and each second-level directory is a buildpack version.

For example, the samples/java-maven buildpack:

mkdir -p buildpacks/samples_java-maven/0.0.1
cp -r $CNB_SAMPLES_PATH/buildpacks/java-maven/* buildpacks/samples_java-maven/0.0.1/

Let’s do that for every buildpack in the samples/buildpacks directory:

for f in `ls --color=no $CNB_SAMPLES_PATH/buildpacks | grep -v README`
do
    mkdir -p ./buildpacks/samples_"$f"/0.0.1
    cp -r "$CNB_SAMPLES_PATH/buildpacks/$f/" ./buildpacks/samples_"$f"/0.0.1/
done

Run the Detector

$CNB_LIFECYCLE_PATH/detector -log-level debug -layers="./layers" -order="./order.toml" -buildpacks="./buildpacks" -app apps/bash-script

Output

We should get something like this:

$CNB_LIFECYCLE_PATH/detector -log-level debug -layers="./layers" -order="./order.toml" -buildpacks="./buildpacks" -app apps/bash-script
Starting detector...
Parsing inputs...
Ensuring privileges...
Executing command...
Timer: Detector started at 2023-08-29T12:27:19+02:00
======== Results ========
fail: samples/java-maven@0.0.1
======== Results ========
fail: samples/kotlin-gradle@0.0.1
======== Results ========
fail: samples/ruby-bundler@0.0.1
======== Results ========
pass: samples/hello-world@0.0.1
pass: samples/hello-moon@0.0.1
Resolving plan... (try #1)
samples/hello-world 0.0.1
samples/hello-moon  0.0.1
Timer: Detector ran for 974.819292ms and ended at 2023-08-29T12:27:20+02:00

Between the output files, we should have a group.toml and a plan.toml file

The groups that have passed the detection have been written into the group.tomlfile writing its build plan into the plan.tomlfile.

Here if you want to read more about the group and plan toml files.

Restorer

This phase is mostly about bringing things out of the cache if anything is in there.

Let’s create the cache directory

mkdir cache

and then let’s run the restorer:

$CNB_LIFECYCLE_PATH/restorer -log-level debug -layers="./layers" -group="./layers/group.toml" -cache-dir="./cache" -analyzed="./layers/analyzed.toml"

Output

Getting back something like this:

Starting restorer...
Parsing inputs...
Ensuring privileges...
Executing command...
Timer: Restorer started at 2023-08-30T17:10:54+02:00
Restoring Layer Metadata
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon
Reading Buildpack Layers directory <REDACTED>/github.com/dlion/unpackingCNB/layers
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world
Reading Buildpack Layers directory <REDACTED>/github.com/dlion/unpackingCNB/layers
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon
Timer: Restorer ran for 832.458µs and ended at 2023-08-30T17:10:54+02:00

The cache directory should now be populated by 2 sub-dirs:committed and staging.

Builder

The builder transforms application source code into runnable artifacts that can be packaged into a container.

As a pre-request to run the builder, we first need to create two directories:

mkdir -p platform
mkdir -p workspace

• platform is where we store configurations and env variables
• workspace is where we store our app source code and where we build it

Let’s copy the source code from the app directory to the workspace dir:

cp -r apps/bash-script/* ./workspace

Let’s create a launcher file with the instructions to run our application:

cat << EOF > ./layers/samples_hello-moon/launch.toml
[[processes]]
  type = "shell"
  command = ["./app.sh"]
EOF

Let’s run the builder:

$CNB_LIFECYCLE_PATH/builder -log-level debug -layers="./layers" -group="./layers/group.toml" -analyzed="./layers/analyzed.toml" -plan="./layers/plan.toml" -buildpacks="./buildpacks" -app="./workspace" -platform="./platform"

Output

Starting builder...
Parsing inputs...
Ensuring privileges...
Executing command...
Timer: Builder started at 2023-08-30T17:16:43+02:00
Running build for buildpack samples/hello-world@0.0.1
Looking up buildpack
Finding plan
Creating plan directory
Preparing paths
Running build command
---> Hello World buildpack
     platform_dir files:
       total 0
       drwxr-xr-x  2 dluciani  staff   64 Aug 30 17:14 .
       drwxr-xr-x  9 dluciani  staff  288 Aug 30 17:14 ..
     env_dir: <REDACTED>/github.com/dlion/unpackingCNB/platform/env
     env vars:
       declare -x CNB_BP_PLAN_PATH="/var/folders/y5/tcnd_s55369g9v5crnmg2t040000gp/T/samples_hello-world-3790526309/samples_hello-world/plan.toml"
       declare -x CNB_BUILDPACK_DIR="<REDACTED>/github.com/dlion/unpackingCNB/buildpacks/samples_hello-world/0.0.1"
       declare -x CNB_LAYERS_DIR="<REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world"
       declare -x CNB_PLATFORM_DIR="<REDACTED>/github.com/dlion/unpackingCNB/platform"
       declare -x CNB_TARGET_ARCH="amd64"
       declare -x CNB_TARGET_ARCH_VARIANT=""
       declare -x CNB_TARGET_DISTRO_NAME=""
       declare -x CNB_TARGET_DISTRO_VERSION=""
       declare -x CNB_TARGET_OS="linux"
       declare -x HOME="<REDACTED>"
       declare -x OLDPWD
       declare -x PATH="<REDACTED>"
       declare -x PWD="<REDACTED>/github.com/dlion/unpackingCNB/workspace"
       declare -x SHLVL="1"
     layers_dir: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world
     plan_path: /var/folders/y5/tcnd_s55369g9v5crnmg2t040000gp/T/samples_hello-world-3790526309/samples_hello-world/plan.toml
     plan contents:
       [[entries]]
         name = "some-world"       [[entries]]
         name = "some-world"
         [entries.metadata]
           world = "Earth-616"
---> Done
Processing layers
Updating environment
Reading output files
Updating buildpack processes
Updating process list
Finished running build for buildpack samples/hello-world@0.0.1
Running build for buildpack samples/hello-moon@0.0.1
Looking up buildpack
Finding plan
Creating plan directory
Preparing paths
Running build command
---> Hello Moon buildpack
     env_dir: <REDACTED>/github.com/dlion/unpackingCNB/platform/env
     env vars:
       declare -x CNB_BP_PLAN_PATH="/var/folders/y5/tcnd_s55369g9v5crnmg2t040000gp/T/samples_hello-moon-3263588455/samples_hello-moon/plan.toml"
       declare -x CNB_BUILDPACK_DIR="<REDACTED>/github.com/dlion/unpackingCNB/buildpacks/samples_hello-moon/0.0.1"
       declare -x CNB_LAYERS_DIR="<REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon"
       declare -x CNB_PLATFORM_DIR="<REDACTED>/github.com/dlion/unpackingCNB/platform"
       declare -x CNB_TARGET_ARCH="amd64"
       declare -x CNB_TARGET_ARCH_VARIANT=""
       declare -x CNB_TARGET_DISTRO_NAME=""
       declare -x CNB_TARGET_DISTRO_VERSION=""
       declare -x CNB_TARGET_OS="linux"
       declare -x HOME="<REDACTED>"
       declare -x OLDPWD
       declare -x PATH="<REDACTED>"
       declare -x PWD="<REDACTED>/github.com/dlion/unpackingCNB/workspace"
       declare -x SHLVL="1"
     layers_dir: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon
     plan_path: /var/folders/y5/tcnd_s55369g9v5crnmg2t040000gp/T/samples_hello-moon-3263588455/samples_hello-moon/plan.toml
     plan contents:
---> Done
Processing layers
Updating environment
Reading output files
Updating buildpack processes
Updating process list
Finished running build for buildpack samples/hello-moon@0.0.1
Copying SBOM files
Creating SBOM files for legacy BOM
Listing processes
Timer: Builder ran for 2.304770458s and ended at 2023-08-30T17:16:45+02:00

As you can read from the output we have built the two buildpacks that we need in order to run our bash-script application. And now in our layers directory we should find other directories like the two from our buildpacks, a config and a sbom ones.

Export

We need to export the artifacts built by the builder, but first, we need to specify the path of the launcher that our image is going to run:

For AMD64 architectures

export CNB_LINUX_LAUNCHER_PATH=/<your-path>/lifecycle/out/linux-amd64/lifecycle/launcher

For ARM64 Architectures

export CNB_LINUX_LAUNCHER_PATH=/<your-path>/lifecycle/out/linux-arm64/lifecycle/launcher

And then let’s run the exporter:

$CNB_LIFECYCLE_PATH/exporter --log-level debug -launch-cache "./cache" -daemon -cache-dir "./cache" -analyzed "./layers/analyzed.toml" -group "./layers/group.toml" -layers="./layers" -app "./workspace" -launcher="$CNB_LINUX_LAUNCHER_PATH" -process-type="shell" apps/bash-script

The output should be something like this one:

Starting exporter...
Parsing inputs...
Ensuring privileges...
Executing command...
no project metadata found at path './layers/project-metadata.toml', project metadata will not be exported
no run metadata found at path '/cnb/run.toml'
Timer: Exporter started at 2023-08-30T17:28:46+02:00
Warning: Did not find SBOM lifecycle.sbom.cdx.json in /cnb/lifecycle
Warning: Did not find SBOM lifecycle.sbom.spdx.json in /cnb/lifecycle
Warning: Did not find SBOM lifecycle.sbom.syft.json in /cnb/lifecycle
Warning: Did not find SBOM launcher.sbom.cdx.json in /cnb/lifecycle
Warning: Did not find SBOM launcher.sbom.spdx.json in /cnb/lifecycle
Warning: Did not find SBOM launcher.sbom.syft.json in /cnb/lifecycle
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world
Processing buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon
Processing buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon
Found SBOM of type launch for at <REDACTED>/github.com/dlion/unpackingCNB/layers/sbom/launch
Reusing tarball for layer "buildpacksio/lifecycle:launch.sbom" with SHA: sha256:1ad83289f52becaf87159706f663d11b0871e0889d14b6f9fcff7938bb7d7a18
Adding layer 'buildpacksio/lifecycle:launch.sbom'
Layer 'buildpacksio/lifecycle:launch.sbom' SHA: sha256:1ad83289f52becaf87159706f663d11b0871e0889d14b6f9fcff7938bb7d7a18
Layer 'slice-1' SHA: sha256:fff5756b235cc98a7c89c9d059e26847773151a60f0ef269ef9721606ac16f8a
Adding 1/1 app layer(s)
Reusing tarball for layer "buildpacksio/lifecycle:launcher" with SHA: sha256:ef23d3a8631f2cc87faf9fadca65fcb1bcea64ab217c614f28d52c54bfffbbbd
Adding layer 'buildpacksio/lifecycle:launcher'
Layer 'buildpacksio/lifecycle:launcher' SHA: sha256:ef23d3a8631f2cc87faf9fadca65fcb1bcea64ab217c614f28d52c54bfffbbbd
Reusing tarball for layer "buildpacksio/lifecycle:config" with SHA: sha256:87f8a5a44bf99c09d22f06e7a0cede09dfefb3abd057071c150687bf01e0e645
Adding layer 'buildpacksio/lifecycle:config'
Layer 'buildpacksio/lifecycle:config' SHA: sha256:87f8a5a44bf99c09d22f06e7a0cede09dfefb3abd057071c150687bf01e0e645
Adding label 'io.buildpacks.lifecycle.metadata'
Adding label 'io.buildpacks.build.metadata'
Adding label 'io.buildpacks.project.metadata'
Setting CNB_LAYERS_DIR=<REDACTED>/github.com/dlion/unpackingCNB/layers
Setting CNB_APP_DIR=<REDACTED>/github.com/dlion/unpackingCNB/workspace
Setting CNB_PLATFORM_API=0.12
Setting CNB_DEPRECATION_MODE=quiet
Prepending /cnb/process and /cnb/lifecycle to PATH
Setting WORKDIR: '<REDACTED>/github.com/dlion/unpackingCNB/workspace'
no default process type
Setting ENTRYPOINT: '/cnb/lifecycle/launcher'
Timer: Saving apps/bash-script... started at 2023-08-30T17:28:46+02:00
*** Images (adaa8f978697):
      apps/bash-script*** Image ID: adaa8f9786976dabc271ab280daabf11d3fa55c667e36c0b7d05c9977a6c8365
Timer: Saving apps/bash-script... ran for 66.341292ms and ended at 2023-08-30T17:28:46+02:00
Timer: Exporter ran for 92.022541ms and ended at 2023-08-30T17:28:46+02:00
Timer: Cache started at 2023-08-30T17:28:46+02:00
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-world
Reading buildpack directory: <REDACTED>/github.com/dlion/unpackingCNB/layers/samples_hello-moon
Timer: Cache ran for 1.154042ms and ended at 2023-08-30T17:28:46+02:00
Warning: Failed to export cache: setting cache metadata: creating metadata file '<REDACTED>/github.com/dlion/unpackingCNB/cache/staging/io.buildpacks.lifecycle.cache.metadata': open <REDACTED>/github.com/dlion/unpackingCNB/cache/staging/io.buildpacks.lifecycle.cache.metadata: no such file or directory

Finally, our image has been exported correctly, which we can verify by running the docker images command.

Let’s run our image:

❯ docker run -it apps/bash-script ./app.sh

    |'-_ _-'|       ____          _  _      _                      _             _
    |   |   |      |  _ \        (_)| |    | |                    | |           (_)
     '-_|_-'       | |_) | _   _  _ | |  __| | _ __    __ _   ___ | | __ ___     _   ___
|'-_ _-'|'-_ _-'|  |  _ < | | | || || | / _` ||'_ \  / _\ | / __|| |/ // __|   | | / _ \
|   |   |   |   |  | |_) || |_| || || || (_| || |_) || (_| || (__ |   < \__ \ _ | || (_) |
 '-_|_-' '-_|_-'   |____/  \__,_||_||_| \__,_|| .__/  \__,_| \___||_|\_\|___/(_)|_| \___/
                                              | |
                                              |_|

Here are the contents of the current working directory:
.:
total 24
drwxr-xr-x 3 1000    1000 4096 Jan  1  1980 .
drwxr-xr-x 1  502 dialout 4096 Jan  1  1980 ..
-rw-r--r-- 1 1000    1000  692 Jan  1  1980 README.md
-rwxr-xr-x 1 1000    1000  736 Jan  1  1980 app.sh
drwxr-xr-x 3 1000    1000 4096 Jan  1  1980 bash-script-buildpack
-rw-r--r-- 1 1000    1000  202 Jan  1  1980 project.toml

./bash-script-buildpack:
total 16
drwxr-xr-x 3 1000 1000 4096 Jan  1  1980 .
drwxr-xr-x 3 1000 1000 4096 Jan  1  1980 ..
drwxr-xr-x 2 1000 1000 4096 Jan  1  1980 bin
-rw-r--r-- 1 1000 1000  350 Jan  1  1980 buildpack.toml

./bash-script-buildpack/bin:
total 16
drwxr-xr-x 2 1000 1000 4096 Jan  1  1980 .
drwxr-xr-x 3 1000 1000 4096 Jan  1  1980 ..
-rwxr-xr-x 1 1000 1000  330 Jan  1  1980 build
-rwxr-xr-x 1 1000 1000  242 Jan  1  1980 detect

This tutorial should have provided you with a comprehensive overview of the process of using Buildpacks to create container images. You are now ready to explore this technology further and adapt it to your application development and deployment needs. 🚀

Thank you

I’d like to mention Joe Kimmel who drafted the first version of this tutorial. Navdeep Pama, Natalie Arellano, Joe Kutner, and Juan Bustamante who reviewed and contributed to this tutorial, their insights and expertise were invaluable in bringing this tutorial to fruition.

If you have any questions or feedback, please don’t hesitate to reach out. Your engagement is what keeps our community vibrant and thriving. Thank you for joining us on this educational adventure, and we look forward to sharing more insights with you in the future. 👋🏻

Domenico Luciani, Sr. Software Engineer @ VMware

Unpacking Cloud Native Buildpacks was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Buildpacks project is thrilled to announce the donation of kpack, a Kubernetes-based Buildpacks platform that has been part of the Buildpacks community for years, to the Buildpacks Community GitHub organization. This is a big milestone for the Buildpacks project, as it is our first major community project.

Why this is exciting

The donation of kpack to the Buildpacks Community org is an exciting prospect for multiple reasons.

An out-of-the-box Kubernetes integration: As a Cloud Native Computing Foundation (CNCF) incubating project, having a first-class Kubernetes integration has been on our roadmap for a while now. Kpack allows you to truly scale the capabilities that Buildpacks provides and makes it a breeze to manage a large fleet of applications — whether it is building a multi-tenant zero-privilege container building solution or mitigating vulnerabilities through our powerful rebase operation for thousands of images in a matter of minutes.

A vendor-neutral project: kpack is an open source software project that originated at Pivotal, a company that was acquired by VMware in December 2019. By donating kpack to the Buildpacks Community Organization, VMware hopes to ensure the project will remain vendor-neutral. This is important to the Buildpacks community, as we believe that Cloud Native Buildpacks should be accessible and open to contributions by everyone, regardless of their vendor preferences or affiliations. This is evidenced by the fact that the maintainer pool for kpack is already growing and diversifying (one of the key indicators of a mature project according to CNCF) with the recent addition of Bloomberg, an end-user organization that is an active contributor to the project.

Opportunities for the Community

The inclusion of kpack under the Buildpacks (CNCF) umbrella will provide a number of opportunities for the community, including:

Increased adoption: The donation of kpack to CNCF will make it more likely that users will adopt kpack and, in-turn, Cloud Native Buildpacks on Kubernetes.

Improved efficiency: The donation of kpack will help ensure that the roadmaps of both kpack and Cloud Native Buildpacks are closely aligned. This will make it easier to coordinate efforts between the two communities and improve the overall user experience.

New features and capabilities: The donation of kpack gives the Buildpacks community an opportunity to add new features and capabilities to the project. This will help make kpack even more powerful and versatile.

Conclusion

Buildpacks is excited to welcome kpack to our community organization. We believe this donation is a major milestone for the Cloud Native Buildpacks project, and we are grateful to VMware for its support. We look forward to working with the kpack community to make this project a success.

Get involved

We are excited to hear from you and learn with you! Here are several ways you can engage with us and the rest of the Buildpacks community:

• Join the Buildpacks slack channel, #buildpacks in the CNCF workspace.
• Join the kpack slack channel, #buildpacks-kpack in the CNCF workspace
• Find us on GitHub. Suggest how we can improve the project, the docs, or share any other feedback.
• Attend our Community Meetings! Check out the Community page for full details on how to attend.

kpack joins the Buildpacks Community Organization was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Buildpacks Community organization is a vendor-neutral Github organization where the community provides trusted Cloud Native Buildpacks tooling, platforms, and integrations.

The community org will provide a staging area to incubate new technologies and projects that solve common yet still relatively niche problems that are not suitable to be added to the core Buildpacks organization.

For a project to be admitted to the Buildpacks community organization, it must meet several criteria, but the first step is to create a Github issue in the Buildpacks Community repository. Once it is mature enough to be part of the core Buildpacks organization, the project maintainers can request for the project to be graduated into the core Buildpacks organization.

If you want to know more, you can find all the details in the RFC.

Join the Buildpack community

We are excited to hear from you and learn with you! Here are several ways you can get involved:

• Join Buildpack’s slack channel, #buildpacks in CNCF workspace, and connect with Buildpack’s users.
• Find us on GitHub. Suggest how we can improve the project, the docs, or share any other feedback.
• Attend our Community Meetings! Check out the Community page for full details on how to attend.

Introducing the Buildpack Community organization was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Are you ready for KubeCon + CloudNativeCon Europe?! This year’s European flagship event is especially meaningful because in March 2020, we were all set to head to Amsterdam for that year’s KubeCon Europe, but like many other events it had to be canceled. We are finally making the trek to The Netherlands next week to engage with the cloud native community and we couldn’t be more excited to see everyone!

See below for all the opportunities to engage with us and the rest of the Cloud Native Buildpacks community in Amsterdam.

Note: All times mentioned below are in Central European Summer Time (CEST), UTC +2

In-Person Project Meeting

Tuesday, April 18 • 10:30–12:30 CEST, Room D303, Congress Center

Join us for general welcome and introduction to Buildpacks. We’ll give an overview of the project and review our roadmap for the first half of the year. Then we’ll discuss some special topics including Dockerfile Extensions, Stack Removal, and Execution Environments + Testing. Finally, we’ll leave some time for Q&A.

Note: You DO NOT need an all-access pass to attend a project meeting. A regular in-person registration is all that is required.

Project Pavilion

Stop by our kiosk (#K16) in the project pavilion to say hello and grab some new swag! The pavilion will be staffed by TOC members, maintainers, contributors, and community volunteers at the following times:

• Wednesday, April 19
   — 16:00–18:00
   — 18:00–21:00 (during KubeCrawl +CloudNativeFest)
• Thursday, April 20
   — 14:30–17:30
• Friday, April 21
   — 12:30–14:30

Maintainer Track and Breakout Sessions

Our team and community will deliver three talks covering Buildpacks and its applications:

• Choose Your Own Adventure: The Treacherous Trek to Development with Whitney Lee, VMware & Viktor Farcic, Upbound
   — Wednesday, April 19 @ 14:30–15:05
• Customizing Your Buildpacks Build — Yes You Can! with Natalie Arellano, VMware & Aidan Delaney, Bloomberg
   — Wednesday, April 19 @ 16:30–17:05
• Processing of Amsterdam City Data with Vendor Agnostic Serverless Functions with Mohit Suman & Zbynek Roubalik, Red Hat
  - Thursday, April 20 @ 15:25–16:00

Solutions Showcase

VMware Booth Theater Demos
Thursday, April 20, 16:30–17:00 — From Source Code to Container: Exploring Cloud Native Buildpacks with Natalie Arellano, Buildpacks Maintainer

Join the Buildpacks Community

We are excited to hear from you and learn with you! Here are several ways you can get involved:

• Join Buildpack’s slack channel, #buildpacks in CNCF workspace, and connect with Buildpack’s users.
• Find us on GitHub. Suggest how we can improve the project, the docs, or share any other feedback.
• Attend our Community Meetings! Check out the Community page for full details on how to attend.

Buildpacks in Amsterdam for KubeCon + CloudNativeCon Europe was originally published in Buildpacks on Medium, where people are continuing the conversation by highlighting and responding to this story.