Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

27 Buildpacks

Buildpacks are used to construct the environment needed to run your applications, including any required runtimes or frameworks as well as other dependencies. When you deploy an application, a buildpack can be specified or automatically detected by cycling through all available buildpacks to find one that is applicable. When there is a suitable buildpack for your application, the buildpack will then download any necessary dependencies during the staging process.

27.1 System Buildpacks

SUSE Cloud Application Platform releases include a set of system, or built-in, buildpacks for common languages and frameworks. These system buildpacks are based on the upstream versions of the buildpack, but are made compatible with the SLE-based stack(s) found in SUSE Cloud Application Platform.

The following table lists the default system buildpacks and their associated versions included as part of the SUSE Cloud Application Platform 1.5.2 release.

27.2 Using Buildpacks

When deploying an application, a buildpack can be selected through one of the following methods:

  • Using the -b option during the cf push command, for example:

    tux > cf push 12factor -b ruby_buildpack
  • Using the buildpacks attribute in your application's manifest.yml. For more information, see https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html#buildpack.

    ---
    applications:
    - name: 12factor
      buildpacks:
        - ruby_buildpack
  • Using buildpack detection.

    Buildpack detection occurs when an application is pushed and a buildpack has not been specified using any of the other methods. The application is checked aginst the detection criteria of a buildpack to verify whether its compatible. Each buildpack has its own detection criteria, defined in the /bin/detect file. The Ruby buildpack, for example, considers an application compatible if it contains a Gemfile file and Gemfile.lock file in its root directory.

    The detection process begins with the first buildpack in the detection priority list. If the buildpack is compatible with the application, the staging process continues. If the buildpack is not compatible with the application, the buildpack in the next position is checked. To see the detection priority list, run cf buildpacks and examine the position field. If there are no compatible buildpacks, the cf push command will fail.

    For more information, see https://docs.cloudfoundry.org/buildpacks/understand-buildpacks.html#buildpack-detection.

In the above, ruby_buildpack can be replaced with:

  • The name of a buildpack. To list the currently available buildpacks, including any that were created or updated, examine the buildpack field after running:

    tux > cf buildpacks
  • The Git URL of a buildpack. For example, https://github.com/SUSE/cf-ruby-buildpack.

  • The Git URL of a buildpack with a specific branch or tag. For example, https://github.com/SUSE/cf-ruby-buildpack#1.7.40.

For more information about using buildpacks, see https://docs.cloudfoundry.org/buildpacks/#using-buildpacks.

27.3 Adding Buildpacks

Additional buildpacks can be added to your SUSE Cloud Application Platform deployment to complement the ones already installed.

  1. List the currently installed buildpacks.

    tux > cf buildpacks
    Getting buildpacks...
    
    buildpack               position   enabled   locked   filename                                           stack
    staticfile_buildpack    1          true      false    staticfile-buildpack-v1.4.43.1-1.1-53227ab3.zip
    nginx_buildpack         2          true      false    nginx-buildpack-v1.0.15.1-1.1-868e3dbf.zip
    java_buildpack          3          true      false    java-buildpack-v4.20.0.1-7b3efeee.zip
    ruby_buildpack          4          true      false    ruby-buildpack-v1.7.42.1-1.1-897dec18.zip
    nodejs_buildpack        5          true      false    nodejs-buildpack-v1.6.53.1-1.1-ca7738ac.zip
    go_buildpack            6          true      false    go-buildpack-v1.8.42.1-1.1-c93d1f83.zip
    python_buildpack        7          true      false    python-buildpack-v1.6.36.1-1.1-4c0057b7.zip
    php_buildpack           8          true      false    php-buildpack-v4.3.80.1-6.1-613615bf.zip
    binary_buildpack        9          true      false    binary-buildpack-v1.0.33.1-1.1-a53fa79d.zip
    dotnet-core_buildpack   10         true      false    dotnet-core-buildpack-v2.2.13.1-1.1-cf41131a.zip
  2. Add a new buildpack using the cf create-buildpack command.

    tux > cf create-buildpack another_ruby_buildpack https://cf-buildpacks.suse.com/ruby-buildpack-v1.7.41.1-1.1-c4cd5fed.zip 10

    Where:

    • another_ruby_buildpack is the name of the buildpack.

    • https://cf-buildpacks.suse.com/ruby-buildpack-v1.7.41.1-1.1-c4cd5fed.zip is the path to the buildpack release. It should be a zip file, a URL to a zip file, or a local directory.

    • 10 is the position of the buildpack and used to determine priority. A lower value indicates a higher priority.

    To see all available options, run:

    tux > cf create-buildpack -h
  3. Verify the new buildpack has been added.

    tux > cf buildpacks
    Getting buildpacks...
    
    buildpack                position   enabled   locked   filename                                           stack
    staticfile_buildpack     1          true      false    staticfile-buildpack-v1.4.43.1-1.1-53227ab3.zip
    nginx_buildpack          2          true      false    nginx-buildpack-v1.0.15.1-1.1-868e3dbf.zip
    java_buildpack           3          true      false    java-buildpack-v4.20.0.1-7b3efeee.zip
    ruby_buildpack           4          true      false    ruby-buildpack-v1.7.42.1-1.1-897dec18.zip
    nodejs_buildpack         5          true      false    nodejs-buildpack-v1.6.53.1-1.1-ca7738ac.zip
    go_buildpack             6          true      false    go-buildpack-v1.8.42.1-1.1-c93d1f83.zip
    python_buildpack         7          true      false    python-buildpack-v1.6.36.1-1.1-4c0057b7.zip
    php_buildpack            8          true      false    php-buildpack-v4.3.80.1-6.1-613615bf.zip
    binary_buildpack         9          true      false    binary-buildpack-v1.0.33.1-1.1-a53fa79d.zip
    another_ruby_buildpack   10         true      false    ruby-buildpack-v1.7.41.1-1.1-c4cd5fed.zip
    dotnet-core_buildpack    11         true      false    dotnet-core-buildpack-v2.2.13.1-1.1-cf41131a.zip

27.4 Updating Buildpacks

Currently installed buildpacks can be updated using the cf update-buildpack command. To see all values that can be updated, run cf update-buildpack -h.

Important
Important

Before updating a built-in buildpack, take note of the scenarios that could lead to the api-group pod not being in a ready state as described in Section 31.7, “api-group Pod Not Ready after Buildpack Update”.

  1. List the currently installed buildpacks that can be updated.

    tux > cf buildpacks
    Getting buildpacks...
    
    buildpack                position   enabled   locked   filename                                           stack
    staticfile_buildpack     1          true      false    staticfile-buildpack-v1.4.43.1-1.1-53227ab3.zip
    nginx_buildpack          2          true      false    nginx-buildpack-v1.0.15.1-1.1-868e3dbf.zip
    java_buildpack           3          true      false    java-buildpack-v4.20.0.1-7b3efeee.zip
    ruby_buildpack           4          true      false    ruby-buildpack-v1.7.42.1-1.1-897dec18.zip
    nodejs_buildpack         5          true      false    nodejs-buildpack-v1.6.53.1-1.1-ca7738ac.zip
    go_buildpack             6          true      false    go-buildpack-v1.8.42.1-1.1-c93d1f83.zip
    python_buildpack         7          true      false    python-buildpack-v1.6.36.1-1.1-4c0057b7.zip
    php_buildpack            8          true      false    php-buildpack-v4.3.80.1-6.1-613615bf.zip
    binary_buildpack         9          true      false    binary-buildpack-v1.0.33.1-1.1-a53fa79d.zip
    another_ruby_buildpack   10         true      false    ruby-buildpack-v1.7.41.1-1.1-c4cd5fed.zip
    dotnet-core_buildpack    11         true      false    dotnet-core-buildpack-v2.2.13.1-1.1-cf41131a.zip
  2. Use the cf update-buildpack command to update a buildpack.

    tux > cf update-buildpack another_ruby_buildpack -i 11

    To see all available options, run:

    tux > cf update-buildpack -h
  3. Verify the new buildpack has been updated.

    tux > cf buildpacks
    Getting buildpacks...
    
    buildpack                position   enabled   locked   filename                                           stack
    staticfile_buildpack     1          true      false    staticfile-buildpack-v1.4.43.1-1.1-53227ab3.zip
    nginx_buildpack          2          true      false    nginx-buildpack-v1.0.15.1-1.1-868e3dbf.zip
    java_buildpack           3          true      false    java-buildpack-v4.20.0.1-7b3efeee.zip
    ruby_buildpack           4          true      false    ruby-buildpack-v1.7.42.1-1.1-897dec18.zip
    nodejs_buildpack         5          true      false    nodejs-buildpack-v1.6.53.1-1.1-ca7738ac.zip
    go_buildpack             6          true      false    go-buildpack-v1.8.42.1-1.1-c93d1f83.zip
    python_buildpack         7          true      false    python-buildpack-v1.6.36.1-1.1-4c0057b7.zip
    php_buildpack            8          true      false    php-buildpack-v4.3.80.1-6.1-613615bf.zip
    binary_buildpack         9          true      false    binary-buildpack-v1.0.33.1-1.1-a53fa79d.zip
    dotnet-core_buildpack    10         true      false    dotnet-core-buildpack-v2.2.13.1-1.1-cf41131a.zip
    another_ruby_buildpack   11         true      false    ruby-buildpack-v1.7.41.1-1.1-c4cd5fed.zip

27.5 Offline Buildpacks

An offline, or cached, buildpack packages the runtimes, frameworks, and dependencies needed to run your applications into an archive that is then uploaded to your Cloud Application Platform deployment. When an application is deployed using an offline buildpack, access to the Internet to download dependencies is no longer required. This has the benefit of providing improved staging performance and allows for staging to take place on air-gapped environments.

27.5.1 Creating an Offline Buildpack

Offline buildpacks can be created using the cf-buildpack-packager-docker tool, which is available as a Docker image. The only requirement to use this tool is a system with Docker support.

Important
Important: Disclaimer

Some Cloud Foundry buildpacks can reference binaries with proprietary or mutually incompatible open source licenses which cannot be distributed together as offline/cached buildpack archives. Operators who wish to package and maintain offline buildpacks will be responsible for any required licensing or export compliance obligations.

For automation purposes, you can use the --accept-external-binaries option to accept this disclaimer without the interactive prompt.

Usage of the tool is as follows:

package [--accept-external-binaries] org [all [stack] | language [tag] [stack]]

Where:

  • org is the Github organization hosting the buildpack repositories, such as "cloudfoundry" or "SUSE"

  • A tag cannot be specified when using all as the language because the tag is different for each language

  • tag is not optional if a stack is specified. To specify the latest release, use "" as the tag

  • A maximum of one stack can be specified

The following example demonstrates packaging an offline Ruby buildpack and uploading it to your Cloud Application Platform deployment to use. The packaged buildpack will be a Zip file placed in the current working directory, $PWD.

  1. Build the latest released SUSE Ruby buildpack for the SUSE Linux Enterprise 15 stack:

    tux > docker run --interactive --tty --rm -v $PWD:/out splatform/cf-buildpack-packager SUSE ruby "" sle15
  2. Verify the archive has been created in your current working directory:

    tux > ls
    ruby_buildpack-cached-sle15-v1.7.30.1.zip
  3. Log into your Cloud Application Platform deployment. Select an organization and space to work with, creating them if needed:

    tux > cf api --skip-ssl-validation https://api.example.com
    tux > cf login -u admin -p password
    tux > cf create-org org
    tux > cf create-space space -o org
    tux > cf target -o org -s space
  4. List the currently available buildpacks:

    tux > cf buildpacks
    Getting buildpacks...
    
    buildpack               position   enabled   locked   filename
    staticfile_buildpack    1          true      false    staticfile_buildpack-v1.4.34.1-1.1-1dd6386a.zip
    java_buildpack          2          true      false    java-buildpack-v4.16.1-e638145.zip
    ruby_buildpack          3          true      false    ruby_buildpack-v1.7.26.1-1.1-c2218d66.zip
    nodejs_buildpack        4          true      false    nodejs_buildpack-v1.6.34.1-3.1-c794e433.zip
    go_buildpack            5          true      false    go_buildpack-v1.8.28.1-1.1-7508400b.zip
    python_buildpack        6          true      false    python_buildpack-v1.6.23.1-1.1-99388428.zip
    php_buildpack           7          true      false    php_buildpack-v4.3.63.1-1.1-2515c4f4.zip
    binary_buildpack        8          true      false    binary_buildpack-v1.0.27.1-3.1-dc23dfe2.zip
    dotnet-core_buildpack   9          true      false    dotnet-core-buildpack-v2.0.3.zip
  5. Upload your packaged offline buildpack to your Cloud Application Platform deployment:

    tux > cf create-buildpack ruby_buildpack_cached /tmp/ruby_buildpack-cached-sle15-v1.7.30.1.zip 1 --enable
    Creating buildpack ruby_buildpack_cached...
    OK
    
    Uploading buildpack ruby_buildpack_cached...
    Done uploading
    OK
  6. Verify your buildpack is available:

    tux > cf buildpacks
    Getting buildpacks...
    
    buildpack               position   enabled   locked   filename
    ruby_buildpack_cached   1          true      false    ruby_buildpack-cached-sle15-v1.7.30.1.zip
    staticfile_buildpack    2          true      false    staticfile_buildpack-v1.4.34.1-1.1-1dd6386a.zip
    java_buildpack          3          true      false    java-buildpack-v4.16.1-e638145.zip
    ruby_buildpack          4          true      false    ruby_buildpack-v1.7.26.1-1.1-c2218d66.zip
    nodejs_buildpack        5          true      false    nodejs_buildpack-v1.6.34.1-3.1-c794e433.zip
    go_buildpack            6          true      false    go_buildpack-v1.8.28.1-1.1-7508400b.zip
    python_buildpack        7          true      false    python_buildpack-v1.6.23.1-1.1-99388428.zip
    php_buildpack           8          true      false    php_buildpack-v4.3.63.1-1.1-2515c4f4.zip
    binary_buildpack        9          true      false    binary_buildpack-v1.0.27.1-3.1-dc23dfe2.zip
    dotnet-core_buildpack   10         true      false    dotnet-core-buildpack-v2.0.3.zip
  7. Deploy a sample Rails app using the new buildpack:

    tux > git clone https://github.com/scf-samples/12factor
    tux > cd 12factor
    tux > cf push 12factor -b ruby_buildpack_cached
Warning
Warning: Deprecation of cflinuxfs2 and sle12 Stacks

As of SUSE Cloud Foundry 2.18.0, since our cf-deployment version is 9.5 , the cflinuxfs2 stack is no longer supported, as was advised in SUSE Cloud Foundry 2.17.1 or Cloud Application Platform 1.4.1. The cflinuxfs2 buildpack is no longer shipped, but if you are upgrading from an earlier version, cflinuxfs2 will not be removed. However, for migration purposes, we encourage all admins to move to cflinuxfs3 or sle15 as newer buildpacks will not work with the deprecated cflinuxfs2. If you still want to use the older stack, you will need to build an older version of a buildpack to continue for the application to work, but you will be unsupported. (If you are running on sle12, we will be retiring that stack in a future version so start planning your migration to sle15. The procedure is described below.)

  • Migrate applications to the new stack using one of the methods listed. Note that both methods will cause application downtime. Downtime can be avoided by following a Blue-Green Deployment strategy. See https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html for details.

    Note that stack association support is available as of cf CLI v6.39.0.

    • Option 1 - Migrating applications using the Stack Auditor plugin.

      Stack Auditor rebuilds the application onto the new stack without a change in the application source code. If you want to move to a new stack with updated code, please follow Option 2 below. For additional information about the Stack Auditor plugin, see https://docs.cloudfoundry.org/adminguide/stack-auditor.html.

      1. Install the Stack Auditor plugin for the cf CLI. For instructions, see https://docs.cloudfoundry.org/adminguide/stack-auditor.html#install.

      2. Identify the stack applications are using. The audit lists all applications in orgs you have access to. To list all applications in your Cloud Application Platform deployment, ensure you are logged in as a user with access to all orgs.

        tux > cf audit-stack

        For each application requiring migration, perform the steps below.

      3. If necessary, switch to the org and space the application is deployed to.

        tux > cf target ORG SPACE
      4. Change the stack to sle15.

        tux > cf change-stack APP_NAME sle15
      5. Identify all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf buildpacks
      6. Remove all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf delete-buildpack BUILDPACK -s sle12
        
        tux > cf delete-buildpack BUILDPACK -s cflinuxfs2
      7. Remove the sle12 and cflinuxfs2 stacks.

        tux > cf delete-stack sle12
        
        tux > cf delete-stack cflinuxfs2
    • Option 2 - Migrating applications using the cf CLI.

      Perform the following for all orgs and spaces in your Cloud Application Platform deployment. Ensure you are logged in as a user with access to all orgs.

      1. Target an org and space.

        tux > cf target ORG SPACE
      2. Identify the stack an applications in the org and space is using.

        tux > cf app APP_NAME
      3. Re-push the app with the sle15 stack using one of the following methods.

      4. Identify all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf buildpacks
      5. Remove all buildpacks associated with the sle12 and cflinuxfs2 stacks.

        tux > cf delete-buildpack BUILDPACK -s sle12
        
        tux > cf delete-buildpack BUILDPACK -s cflinuxfs2
      6. Remove the sle12 and cflinuxfs2 stacks using the CF API. See https://apidocs.cloudfoundry.org/7.11.0/#stacks for details.

        List all stacks then find the GUID of the sle12 cflinuxfs2 stacks.

        tux > cf curl /v2/stacks

        Delete the sle12 and cflinuxfs2 stacks.

        tux > cf curl -X DELETE /v2/stacks/SLE12_STACK_GUID
        
        tux > cf curl -X DELETE /v2/stacks/CFLINUXFS2_STACK_GUID
Print this page