Managing Buildpacks

Helion Stackato has a number of built-in buildpacks installed by default. Administrators can install additional buildpacks required by applications.

Understanding Buildpack Types

Buildpacks are typically hosted in Git repositories with a standard structure described in Heroku's Buildpack API documentation. These repositories can be packaged into zip archives and uploaded to Helion Stackato.

There are two types of build-in buildpacks:

  • Online buildpacks retrieve dependencies and artifacts from the Internet during application staging.

  • Offline buildpacks include all of the software dependencies the application requires. The buildpack zip files of these buildpacks are typically large. However, offline buildpacks can stage and run applications on DEA nodes without Internet access.

    Tip

    To reduce the size of the VM, Helion Stackato includes only online buildpacks. After you configure Helion Stackato, changing these buildpacks to offline versions can substantially improve the speed of staging. The following are sample buildpacks with offline versions:

    When run with offline options, the bin/package script or package build target for these buildpacks fetches the external assets and bundles them in a zip file. For more information, see the README.md files of the individual buildpacks.

To Install a Packaged Buildpack (.NET)

In the following example, the .NET Buildpack is installed. You can install any number of additional buildpacks using a similar process.

  1. Target your API endpoint, and log in with your credentials.

  2. Run the stackato create-buildpack command to upload and install a buildpack zip archive:

    $ stackato create-buildpack dotnet https://github.com/hpcloud/cf-iis8-buildpack/archive/1.3.0.16.zip
    Downloading https://github.com/hpcloud/cf-iis8-buildpack/archive/1.3.0.16.zip
    Retrieving ... (536708/??) OK
    Strip path prefix "cf-iis8-buildpack-1.3.0.16" ... OK
    Creating new buildpack dotnet ... OK
    Uploading buildpack bits (1.3.0.16.zip) ... 100% (538091/538091) OK
    OK
    

    Note

    To allow developers to push .NET application code, remember to attach a Windows DEA node to your cluster and to install the win2012r2 stack.

  3. To display the installed buildpacks, run the stackato buildpacks command. The most recent buildpack appears at the top of the list:

    Buildpacks: https://api.198.51.100.1.xip.io
    +----+---------+------------------------------+---------+--------+
    | #  | Name    | Filename                     | Enabled | Locked |
    +----+---------+------------------------------+---------+--------+
    | 1  | dotnet  | 1.3.0.16.zip                 | yes     | no     |
    | 2  | java    | java-buildpack-v3.0.zip      | yes     | no     |
    | 3  | ruby    | ruby_buildpack-v1.3.0.zip    | yes     | no     |
    | 4  | nodejs  | nodejs_buildpack-v1.2.1.zip  | yes     | no     |
    | 5  | python  | python-buildpack-v2.90.2.zip | yes     | no     |
    | 6  | go      | go_buildpack-v1.2.0.zip      | yes     | no     |
    | 7  | clojure | clojure-buildpack-v66.zip    | yes     | no     |
    | 8  | scala   | scala-buildpack-v55.zip      | yes     | no     |
    | 9  | perl    | perl-buildpack-v1.0.0.zip    | yes     | no     |
    | 10 | php     | php_buildpack-v3.1.0.zip     | yes     | no     |
    +----+---------+------------------------------+---------+--------+
    

To Reorder, Disable, and Enable Buildpacks

If a developer pushes an application without specifying an external buildpack, Helion Stackato cycles through the detect scripts of the installed, attempting to match a buildpack to the type of the pushed application. The first buildpack to match the application detection heuristics will stage and run the pushed application.

  1. To display the current buildpack detection order, run the stackato buildpacks command. The following buildpacks are installed by default:

    +---+---------+------------------------------+---------+--------+
    | # | Name    | Filename                     | Enabled | Locked |
    +---+---------+------------------------------+---------+--------+
    | 1 | java    | java-buildpack-v3.0.zip      | yes     | no     |
    | 2 | ruby    | ruby_buildpack-v1.3.0.zip    | yes     | no     |
    | 3 | nodejs  | nodejs_buildpack-v1.2.1.zip  | yes     | no     |
    | 4 | python  | python-buildpack-v2.90.2.zip | yes     | no     |
    | 5 | go      | go_buildpack-v1.2.0.zip      | yes     | no     |
    | 6 | clojure | clojure-buildpack-v66.zip    | yes     | no     |
    | 7 | scala   | scala-buildpack-v55.zip      | yes     | no     |
    | 8 | perl    | perl-buildpack-v1.0.0.zip    | yes     | no     |
    | 9 | php     | php_buildpack-v3.1.0.zip     | yes     | no     |
    +---+---------+------------------------------+---------+--------+
    
  2. To change the order, run the stackato update-buildpack command with the --position option, for example:

    $ stackato update-buildpack --position 1 python
    Updating buildpack [python] ...
      Position ... Changed to 1
      Enabled  ... Unchanged
      Locked   ... Unchanged
    OK
    
  3. To disable or enable buildpacks, use --disable or --enable options, for example:

    stackato update-buildpack --disable java
    Updating buildpack [java] ...
      Position ... Unchanged
      Enabled  ... Changed to 0
      Locked   ... Unchanged
    OK
    

Disabling Custom Buildpacks

You can disable custom buildpacks defined using the --buildpacks CLI option or in the buildpacks: key in manifest.yml and limit users to built-in buildpacks.

  1. Disable custom buildpacks:

    $ kato config set cloud_controller_ng disable_custom_buildpacks true
    
  2. Restart the controller:

    $ kato restart controller
    

When this setting is active, users who attempt to deploy an application with a defined external buildpack URL will receive the Custom buildpacks are disabled (400) error message and the application will not be deployed.