DOCSEARCHbyAlgolia
Submit Docs

Paketo Buildpacks

website·Indexed 35 days ago

https://paketo.io/docs/

Documentation for Paketo Buildpacks, providing guides and references for building cloud-native applications in Java, Node.js, Python, Go, .NET Core, PHP, and Ruby. Includes technical details on builders, stacks, Software Bill of Materials (SBOM), and custom buildpack creation using the Packit library.

Tokens
32.3K
Snippets
177
Records
284
Agent score
70%

What's inside Paketo

  1. Overview of Paketo Buildpacks

    Paketo Buildpacks are open-source tools that transform application source code into OCI-compliant container images. They automatically detect the application language, gather required dependencies, and build the image. They are designed to run on any platform supporting container images, such as Docker and Kubernetes, and integrate with CI/CD tools like CircleCI, GitLab, and Tekton. They are also utilized by tools such as the Pack CLI, Spring Boot, Hashicorp Waypoint, and Tilt.

  2. Overview of Paketo PHP Buildpack components

    The Paketo PHP buildpack is composed of multiple specialized components. Some are required for a basic PHP runtime, while others are optional for specific server or session requirements:

    Required Components:

    • PHP Dist Buildpack: Installs the PHP distribution and adds it to the $PATH.
    • PHP FPM Buildpack: Configures the php-fpm.conf file.

    Optional Components:

    • Composer/Composer Install: Installs the Composer tool and runs composer install.
    • Web Servers: Includes httpd (Apache), nginx, and php-builtin-server for serving applications.
    • Server Integration: php-httpd and php-nginx configure the respective servers to serve PHP apps; php-start sets the start command for NGINX or HTTPD with FPM.
    • Session Handlers: Specialized buildpacks for Redis and Memcached session handling.
    • General Utilities: procfile (custom start commands), environment-variables (launch-time vars), image-labels (image metadata), and ca-certificates (custom CA certs).

  3. Understand the components of a Paketo builder

    A builder is a specialized image used by the pack CLI to create a runnable application image. It consists of three primary components:

    1. Buildpacks: A set of tools that provide the necessary dependencies for the application.
    2. Stack: The operating system (OS) layer that serves as the foundation for the app image.
    3. CNB Lifecycle: The mechanism that orchestrates the buildpacks and stack to produce the final application image.

  4. Understand the Paketo Buildpack lifecycle

    Paketo Buildpacks transform application source code into OCI-compliant images using a two-phase process:

    1. Detect Phase: The buildpack scans the source code for specific indicators (e.g., the presence of a package.json file for the NPM Install Buildpack) to determine if it is required for the build. If detection passes, the buildpack defines a contract of what it requires and what it will provide.
    2. Build Phase: The buildpack fulfills its contract by contributing to the final image. This may involve adding a layer containing a binary (like a language runtime) or executing a command (like npm install).

  5. Understand Paketo NGINX Buildpack behavior

    The NGINX Buildpack contributes to a build in three ways depending on the source code and configuration:

    1. Custom Config: If an nginx.conf file is present in the app's source code, the buildpack sets up an NGINX server using that configuration.
    2. Dependency Only: If nginx.conf is absent and BP_WEB_SERVER is not set to nginx, the buildpack installs the NGINX binary distribution onto the $PATH for use by subsequent buildpacks but does not set up a server.
    3. Default Config: If the environment variable BP_WEB_SERVER is set to nginx, the buildpack sets up an NGINX server using a default configuration.

  6. Compare Paketo Buildpacks with Cloud Foundry Buildpacks

    Paketo Buildpacks differ from Cloud Foundry (CF) Buildpacks in three primary ways:

    • Portability: Paketo produces OCI images that can be deployed anywhere, whereas CF produces droplets that require the CF environment.
    • Architecture: Paketo uses small, composable components; CF uses monolithic codebases for each language.
    • Extensibility: Paketo allows users to add features by writing new buildpacks, while CF typically requires forking the existing buildpack.

  7. Retrieve Software Bill of Materials (SBOM) for PHP apps

    The PHP buildpack generates a full SBOM including PHP versions, Composer versions, and all packages installed via Composer. Supported formats include Syft (JSON), CycloneDX, SPDX, and Paketo-specific formats.

  8. Paketo Java Native Image Buildpack components overview

    The Paketo Java Native Image Buildpack is composed of several component buildpacks. The core requirements for creating a native image are the Paketo GraalVM Buildpack (providing the JDK and Substrate VM) and the Paketo Native Image Buildpack (which handles the conversion from JVM application to native image). Other optional components support specific build tools (Maven, Gradle, SBT, Leiningen), Spring Boot configuration, and image metadata (labels, environment variables, CA certificates).

  9. Deploy .NET Core applications using different artifact types

    The buildpack supports three primary deployment types:

    1. Source Applications: Built using dotnet publish into FDD or FDE.
    2. Framework-Dependent Deployments (FDD) / Executables (FDE): The buildpack includes required .NET Core Framework dependencies and sets the start command.
    3. Self-Contained Deployments (SCD): The buildpack sets the start command; no additional .NET Core Framework dependencies are included as they are bundled in the SCD artifact.

  10. Understand Paketo Software Bill of Materials (SBOM) concepts

    A Software Bill of Materials (SBOM) in Paketo is a mechanism to surface metadata about dependencies within an app image. This metadata is used for secure software supply chain management, specifically for vulnerability scanning (using CPEs and pURLs) and legal compliance checking (via SPDX license information).

    Key metadata fields include:

    • version: Dependency version
    • uri: URI to the compiled dependency
    • checksum: CycloneDX-supported hash (e.g., SHA-256)
    • licenses: Dependency licenses in SPDX format
    • deprecation-date: Date the dependency was deprecated
    • source uri and source checksum: Details of the upstream source
    • CPE: Common Platform Enumeration for NIST NVD lookups
    • pURL: Package URL for universal package representation

  11. Understand Paketo Stack architecture

    A Paketo stack provides the build-time and run-time environments for the buildpack lifecycle. It consists of two distinct images:

    • Build Image: The environment where the application is compiled and built.
    • Run Image: The OS layer on which the application actually executes.

    This separation ensures that the runtime environment is curated to exclude compilers and other tools that could pose security risks.

  12. Understand Paketo HTTPD Buildpack behavior

    The HTTPD Buildpack installs the Apache HTTP Server binary distribution onto the $PATH inside a container. Its behavior during a build depends on the following conditions:

    1. If httpd.conf is present in the app's source code: The buildpack sets up an Apache HTTP server using that specific configuration.
    2. If httpd.conf is absent: The buildpack provides the Apache HTTP Server dependency to subsequent buildpacks but does not set up a server.
    3. If the environment variable BP_WEB_SERVER is set to httpd: The buildpack sets up an Apache HTTP server using a default configuration.