This is a draft document that was built and uploaded automatically. It may document beta software and be incomplete or even incorrect. Use this document at your own risk.

Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Deployment, Administration, and User Guides › SUSE Cloud Application Platform Administration › Buildpacks
ContentsContents
Deployment, Administration, and User Guides
  1. About This Guide
  2. I Overview of SUSE Cloud Application Platform
    1. 1 About SUSE Cloud Application Platform
    2. 2 Other Kubernetes Systems
  3. II Deploying SUSE Cloud Application Platform
    1. 3 Deployment and Administration Notes
    2. 4 Deploying SUSE Cloud Application Platform on SUSE CaaS Platform
    3. 5 Deploying SUSE Cloud Application Platform on Microsoft Azure Kubernetes Service (AKS)
    4. 6 Deploying SUSE Cloud Application Platform on Amazon Elastic Kubernetes Service (EKS)
    5. 7 Deploying SUSE Cloud Application Platform on Google Kubernetes Engine (GKE)
    6. 8 Installing the Stratos Web Console
    7. 9 Eirini
    8. 10 Deploying SUSE Cloud Application Platform Using Terraform
    9. 11 Setting Up a Registry for an Air Gapped Environment
    10. 12 SUSE Private Registry
  4. III SUSE Cloud Application Platform Administration
    1. 13 Upgrading SUSE Cloud Application Platform
    2. 14 Configuration Changes
    3. 15 Creating Admin Users
    4. 16 Managing Passwords
    5. 17 Accessing the UAA User Interface
    6. 18 Container Memory Limits and Requests
    7. 19 Cloud Controller Database Secret Rotation
    8. 20 Rotating Automatically Generated Secrets
    9. 21 Backup and Restore
    10. 22 Service Brokers
    11. 23 App-AutoScaler
    12. 24 Integrating CredHub with SUSE Cloud Application Platform
    13. 25 Buildpacks
  5. IV SUSE Cloud Application Platform User Guide
    1. 26 Deploying and Managing Applications with the Cloud Foundry Client
  6. V Troubleshooting
    1. 27 Troubleshooting
  7. A Appendix
  8. B GNU Licenses
Navigation←→
Deployment, Administration, and User Guides › SUSE Cloud Application Platform Administration › Buildpacks
Top
←→
Applies to SUSE Cloud Application Platform 2.1.1

25 Buildpacks

  • File Name: cap_admin_buildpacks.xml
  • ID: no ID found
25.1 System Buildpacks
25.2 Using Buildpacks
25.3 Adding Buildpacks
25.4 Updating Buildpacks
25.5 Offline 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.

25.1 System Buildpacks

  • File Name: cap_admin_buildpacks.xml
  • ID: sec-cap-cap-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 2.1.1 release.

BuildpackVersionGithub Repository
Staticfile1.5.5https://github.com/SUSE/cf-staticfile-buildpack
NGINX1.1.7https://github.com/SUSE/cf-nginx-buildpack
Java4.29.1https://github.com/SUSE/cf-java-buildpack
Ruby1.8.15https://github.com/SUSE/cf-ruby-buildpack
Node.js1.7.17https://github.com/SUSE/cf-nodejs-buildpack
Go1.9.11https://github.com/SUSE/cf-go-buildpack
Python1.7.12https://github.com/SUSE/cf-python-buildpack
PHP4.4.12https://github.com/SUSE/cf-php-buildpack
Binary1.0.36https://github.com/SUSE/cf-binary-builder
.NET Core2.3.9https://github.com/SUSE/cf-dotnet-core-buildpack

25.2 Using Buildpacks

  • File Name: cap_admin_buildpacks.xml
  • ID: sec-cap-using-buildpacks

When deploying an application, a buildpack can be selected by passing the buildpack's name 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.

25.3 Adding Buildpacks

  • File Name: cap_admin_buildpacks.xml
  • ID: sec-cap-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

25.4 Updating Buildpacks

  • File Name: cap_admin_buildpacks.xml
  • ID: sec-cap-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.

  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

25.5 Offline Buildpacks

  • File Name: cap_admin_buildpacks.xml
  • ID: sec-cap-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.

25.5.1 Creating an Offline Buildpack

  • File Name: cap_admin_buildpacks.xml
  • ID: sec-cap-create-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 MY_ORG
tux > cf create-space MY_SPACE -o MY_ORG
tux > cf target -o MY_ORG -s MY_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
→Part IV SUSE Cloud Application Platform User Guide←Chapter 24 Integrating CredHub with SUSE Cloud Application Platform
Print this page

© 2022 SUSE