The Tanzu Buildpacks supply a number of buildpacks that make integrating with VMware Partners significantly easier.

All of the Tanzu Partner buildpacks are configured as optional in the order groups for the Tanzu composite buildpacks that include them, like the Java Buildpack. This means that by default, partner buildpacks do not run. They only when specific criteria are met, such as the presence of a specific binding. The Behavior section for each buildpack below documents what critiera need to be met and when met, what that buildpack will do.

Please keep in mind that Tanzu Partner Buildpacks will never write credentials or other sensitive information into the generated image. This generally requires bindings that provide sensitive information to exist both at build and runtime. When present at build time, the buildpack will install all required software. The binding also needs to be present at runtime, so that the proper credentials can be passed along to the installed software. The only exception would be for a partner integration that only executes at build time such as a security scanner.

Please see the descriptions below for information on specific partner integration buildpacks.

Apache Skywalking

Image: registry.tanzu.vmware.com/tanzu-apache-skywalking-buildpack/apache-skywalking:<version>

The Tanzu Apache SkyWalking Buildpack is a Cloud Native Buildpack that contributes the Apache SkyWalking Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of ApacheSkyWalking

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to system properties with the pattern -Dskywalking.<KEY>=<VALUE>

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

AppDynamics

Image: registry.tanzu.vmware.com/tanzu-appdynamics-buildpack/appdynamics:<version>

The Tanzu AppDynamics Buildpack is a Cloud Native Buildpack that contributes the AppDynamics Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of AppDynamics

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
    • Contributes a default app-agent-config.xml, custom-activity-correlation.xml, and log4j2.xml
  • Contribute external configuration if available
  • Transforms the contents of the binding secret to environment variables with the pattern APPDYNAMICS_<KEY>=<VALUE>

Note: The default logs directory is <agent_runtime_dir>/version*/logs. From version 3.8.0 of the tanzu-appdynamics-buildpack, this directory is group writable, which conforms to the buildpack spec where the group is always 'cnb' regardless of the user.

The buildpack will do the following for NodeJS applications:

  • Contributes a NodeJS agent to a layer and configures $NODE_MODULES to use it
  • If main module does not already require appdynamics module, prepends the main module with require('appdynamics');
  • Transforms the contents of the binding secret to environment variables with the pattern APPDYNAMICS_<KEY>=<VALUE>

The buildpack will do the following for PHP applications:

  • Contributes a PHP agent to a layer and configures $PHP_INI_SCAN_DIR to use it
  • Transforms the contents of the binding secret to environment variables with the pattern APPDYNAMICS_<KEY>=<VALUE>

Configuration

Environment Variable Description
$APPDYNAMICS_AGENT_APPLICATION_NAME Configure the AppDynamics application name
$APPDYNAMICS_AGENT_NODE_NAME Configure the AppDynamics node name
$APPDYNAMICS_AGENT_TIER_NAME Configure the AppDynamics tier name
$BP_APPD_EXT_CONF_SHA256 Configure the SHA256 hash of the external AppDynamics configuration archive
$BP_APPD_EXT_CONF_STRIP Configure the number of directory components to strip from the external AppDynamics configuration archive. Defaults to 0.
$BP_APPD_EXT_CONF_URI Configure the download location of the external AppDynamics configuration
$BP_APPD_EXT_CONF_VERSION Configure the version of the external AppDynamics configuration

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

AspectJ

Image: registry.tanzu.vmware.com/tanzu-aspectj-buildpack/aspectj:<version>

The Tanzu AspectJ Buildpack is a Cloud Native Buildpack that contributes the AspectJ Weaver agent and configuration to applications.

Behavior

This buildpack will participate all the following conditions are met

  • <APPLICATION_ROOT>/aop.xml exists
  • aspectj-weaver.*.jar exists

The buildpack will do the following:

  • Contributes AspectJ load time weaving configuration to $JAVA_TOOL_OPTIONS

Checkmarx

Image: registry.tanzu.vmware.com/tanzu-checkmarx-buildpack/checkmarx:<version>

The Tanzu Checkmarx Buildpack is a Cloud Native Buildpack that contributes the Checkmarx CxIAST agent and configuration to applications.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of Checkmarx

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it

Configuration

Environment Variable Description
$BPL_CHECKMARX_APPLICATION Configure the application tag
$BPL_CHECKMARX_TEAM Configure the team. Defaults to CxServer.

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Aternity

Image: registry.tanzu.vmware.com/tanzu-aternity-buildpack/aternity:<version>

The Tanzu Aternity Buildpack is a Cloud Native Buildpack that contributes the AppInternals Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of AppInternals

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to environment variables with the pattern <KEY>=<VALUE>

Bindings

The buildpack optionally accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Contrast Security

Image: registry.tanzu.vmware.com/tanzu-contrast-security-buildpack/contrast-security:<version>

The Tanzu Contrast Security Buildpack is a Cloud Native Buildpack that contributes the Contrast Security Agent and configures it toconnect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of ContrastSecurity

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to environment variables with the pattern API__<KEY>=<VALUE>

Note: Starting with version 3.10.0, all Contrast Security agent logs are written to STDOUT by default. This ensures visibility of the agent logs and also ensures that running the container as a custom user (i.e. not the cnb user) does not fail due to file permissions.

To revert this behavior, if a file is necessary, the container can be run with:

To override, if a file is necessary, the container can be run with:

  • --env CONTRAST__AGENT__LOGGER__STDOUT=false
  • --env CONTRAST__AGENT__LOGGER__PATH=/path/writable/by/user

The buildpack will do the following for NodeJS applications:

  • Transforms the contents of the binding secret to environment variables with the pattern API__<KEY>=<VALUE>

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Datadog

Image: registry.tanzu.vmware.com/tanzu-datadog-buildpack/datadog:<version>

The Tanzu Datadog Buildpack is a Cloud Native Buildpack that contributes and configures the Datadog Agent.

Behavior

This buildpack will participate if all the following conditions are met

  • The $BP_DATADOG_ENABLED is set to a truthy value (i.e. true, t, 1 ignoring case)

The buildpack will do the following for Java applications:

  • Contributes the Datadog Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it

The buildpack will do the following for Node.js applications:

  • Contributes the Datadog Node.js trace agent to a layer
  • Require the trace agent, if it's not present

Usage

The Datadog APM integration is enabled with an environment variable. If the environment variable is set then the corresponding Java agent will be contributed to the application image. Configuration will be read from standard Datadog environment variables set at runtime. You can find the full list in the Datadog documentation available here.

Example: Connecting to Datadog

The following command builds an image with the Datadog Java Agent

pack build samples/java -e BP_DATADOG_ENABLED=true

Configuration of the Datadog agent is done through environment variables at runtime:

docker run --rm --tty samples/java -e DD_SERVICE=foo-service -e DD_ENV=foo-env -e DD_VERSION=1.1.1

Note that the Datadog agent requires a side-car agent to be running in addition to the Java agent. This agent runs outside of the buildpack generated image. The standard Datadog instructions for your container orchestrator of choice can be used to install this agent. The Paketo team also has detailed instructions for various runtimes available here.

Bindings

The buildpack optionally accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Dynatrace

Image: registry.tanzu.vmware.com/tanzu-dynatrace-buildpack/dynatrace:<version>

The Tanzu Dynatrace Buildpack is a Cloud Native Buildpack that contributes the Dynatrace OneAgent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of Dynatrace

Note: The binding must include the following required Secret values to successfully contribute Dynatrace

Key Value Description
api-url
or
environment-id
The base URL of the Dynatrace API. If not set, environment-id must be set.
---
If api-url is not set, a URL is configured in the form: https://<environment-id>.live.dynatrace.com/api
api-token (Required) The token for communicating with the Dynatrace service.

The buildpack will do the following for .NET, Go, Apache HTTPd, Java, Nginx, NodeJS, and PHP applications:

  • Contributes a OneAgent including the appropriate libraries to a layer and configures $LD_PRELOAD to use it
  • Sets $DT_TENANT, $DT_TENANTTOKEN, and $DT_CONNECTION_POINT at launch time.
  • Transforms the contents of the binding secret to environment variables with the pattern DT_<KEY>=<VALUE>
    • Excluding api-token, api-url, and environment-id

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Elastic APM

Image: registry.tanzu.vmware.com/tanzu-elastic-apm-buildpack/elastic-apm:<version>

The Tanzu Elastic APM Buildpack is a Cloud Native Buildpack that contributes the Elastic APM Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of ElasticAPM

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to environment variables with the pattern ELASTIC_APM_<KEY>=<VALUE>

The buildpack will do the following for NodeJS applications:

  • Contributes a NodeJS agent to a layer and configures $NODE_MODULES to use it
  • If main module does not already require elastic-apm-node module, prepends the main module with require('elastic-apm-node').start();
  • Transforms the contents of the binding secret to environment variables with the pattern ELASTIC_APM_<KEY>=<VALUE>

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

JaCoCo

Image: registry.tanzu.vmware.com/tanzu-jacoco-buildpack/jacoco:<version>

The Tanzu JaCoCo Buildpack is a Cloud Native Buildpack that contributes the JaCoCo Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of JaCoCo

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to agent properties with the pattern <KEY>=<VALUE>

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

JProfiler

Image: registry.tanzu.vmware.com/tanzu-jprofiler-buildpack/jprofiler:<version>

The Tanzu JProfiler Buildpack is a Cloud Native Buildpack that contributes the JProfiler agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • $BP_JPROFILER_ENABLED is set

The buildpack will do the following:

  • Contribute debug configuration to $JAVA_TOOL_OPTIONS

Configuration

Environment Variable Description
$BP_JPROFILER_ENABLED Whether to contribute JProfiler support
$BPL_JPROFILER_ENABLED Whether to enable JProfiler support
$BPL_JPROFILER_PORT What port the JProfiler agent will listen on. Defaults to 8849.
$BPL_JPROFILER_NOWAIT Whether the JVM will execute before JProfiler has attached. Defaults to true.

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Publishing the Port

When starting an application with debugging enabled, a port must be published. To publish the port in Docker, use the following command:

$ docker run --publish <LOCAL_PORT>:<REMOTE_PORT> ...

The REMOTE_PORT should match the port configuration for the application (8849 by default). The LOCAL_PORT can be any open port on your computer, but typically matches the REMOTE_PORT where possible.

Once the port has been published, your JProfiler Profiler should connect to localhost:<LOCAL_PORT> for profiling.

JProfiler Configuration

New Relic

Image: registry.tanzu.vmware.com/tanzu-new-relic-buildpack/new-relic:<version>

The Tanzu New Relic Buildpack is a Cloud Native Buildpack that contributes the New Relic Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of NewRelic

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
    • Contributes a default newrelic.yml
  • Contribute extensions if available
  • Transforms the contents of the binding secret to environment variables with the pattern NEW_RELIC_<KEY>=<VALUE>

The buildpack will do the following for NodeJS applications:

  • Contributes a NodeJS agent to a layer and configures $NODE_MODULES to use it
    • Contributes a default newrelic.js
  • If main module does not already require newrelic module, prepends the main module with require('newrelic');
  • Transforms the contents of the binding secret to environment variables with the pattern NEW_RELIC_<KEY>=<VALUE>

The buildpack will do the following for PHP applications:

  • Contributes a PHP agent to a layer and configures $PHP_INI_SCAN_DIR to use it
  • Transforms the contents of the binding secret to environment variables with the pattern NEW_RELIC_<KEY>=<VALUE>

Configuration

Environment Variable Description
$BP_NEW_RELIC_EXT_SHA256 Configure the SHA256 hash of the New Relic extensions archive
$BP_NEW_RELIC_EXT_STRIP Configure the number of directory components to strip from the New Relic extensions archive. Defaults to 0.
$BP_NEW_RELIC_EXT_URI Configure the download location of the New Relic extensions
$BP_NEW_RELIC_EXT_VERSION Configure the version of the New Relic extensions

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Luna Security Provider

Image: docker pull registry.tanzu.vmware.com/tanzu-luna-security-provider-buildpack/luna-security-provider:<version>

The Tanzu Luna Security Provider Buildpack is a Cloud Native Buildpack that causes an application to be automatically configured to work with a bound Luna Security Service.

Sample Application

To make using the Tanzu Luna Security Provider buildpack easier, we have put together a sample application that can be used to configure and test connectivity with your Luna HSM.

Behavior

This buildpack will pass detection and participate if all of the following conditions are met

  • A binding exists with type of LunaSecurityProvider

The buildpack will do the following:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • At runtime, transform the contents of the binding secret to configuration files including client certificates, server certificates and Chrystoki.conf which are all used by the Luna Security Agent

Bindings

The buildpack accepts the following bindings:

Type: LunaSecurityProvider

Key Value Description
client-certificate.pem <certificate> The PEM encoded client certificate to be used for the LunaSA ClientClientCertFile property in Chrystoki.conf. This binding entry is required.
client-private-key.pem <certificate> The PEM encoded client private key to be used for the LunaSA ClientClientPrivKeyFile property in Chrystoki.conf. This binding entry is required.
server-certificates.pem <certificate> The PEM encoded bundle of CA or server certificates the client should trust. This is mapped to the LunaSA ClientServerCAFile property in Chrystoki.conf.
chrystoki.template <template> A template to be used by the buildpack to generate the Chrystoki.conf. The template syntax should follow Go text/template. See default template as an example.
template-metadata.toml <toml-data> An arbitrary set of TOML metadata that can be accessed by your template. This binding entry is required.
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>
Default Chrystoki Template

The default Chrystoki template that ships with the buildpack is intended to be flexible and may be customized by setting values in the bound template metadata file.

This is a description of how the file is generated based on values present in the metadata file.

  • A Luna block that sets CloningCommandTimeOut, CommandTimeOutPedSet, DefaultTimeOut, KeypairGenTimeOut, PEDTimeout1, PEDTimeout2, PEDTimeout3 to default values. See the template for default values.
  • A Misc block that sets PE1746Enabled. It defaults to 0.
  • A Chrystoki2 block that sets LibUNIX64 to the path for the library file.
  • A CkLog2 block is added if a custom metadata value LoggingEnabled is set to true. If enabled, it emits a config block that logs to STDOUT using a default LoggingMask of ALL_FUNC. Logging is not enabled by default.
  • A LunaSA Client block that sets TCPKeepAlive and NetClient to default values. It also configures client certificate and key paths to the bound files, server CA certificates to the bound file, and a list of servers based on the servers provided through the template metadata.
    • Each server has its name set to the value provided through metadata, a port of 1792 and ServerHtl set to 0.
  • A VirtualToken block which creates the following entries for each group provided through the template metadata.
    • VirtualToken label which corresponds to the group labed in metadata
    • VirtualToken SN which is has the static string 1 prefixed to the first member of the group's list of members.
    • VirtualToken Members which is a comma separated list of all the group's members.
  • An HAConfiguration block which sets the following to default values: HAOnly, reconnAtt, haLogStatus, haLogToStdout.
  • An HASynchronize block that contains an entry for each group's label, specified through template metadata, and sets the value to 1.
  • The VirtualToken, HAConfiguration and HASynchronize blocks are only emitted if an HA group has been specified.

Additionally, for any block that is setting a property to a fixed default value, you may override that default value by adding a corresponding entry into the custom metadata table.

For example, setting custom = {CloningCommandTimeOut="100"} would result in the generated Chrystoki.conf file containing CloningCommandTimeOut = 100.

Template Metadata Schema

The template metadata file should be a TOML file with the following format.

  • an array of strings called servers
  • an array of HA groups called groups, each HA group has a label property and an array of strings called members
  • a table of string keys with string values called custom

Ex:

servers = [
    "test-server-a",
    "test-server-b",
]

[[groups]]
label = "group-1"
members = [
    "member-1",
    "member-2",
]

[[groups]]
label = "group-2"
members = [
    "member-3",
    "member-4",
]

[custom]
key1 = "val1"
key2 = "val2"
key3 = "val3"

How these values are interpreted depends on the templated used. See the previous section for a description of how the default template utilizes these values.

Custom Templates

You may generate a custom Chrystoki template. The template uses the Go text/template format. In addition, we expose most of the Go strings methods for use in the template (ex: Join, Split, Trim, etc...).

Your custom Chrystoki template also has access to the metadata file which can be used to adjust the configuration generated.

The file has access to the following information:

  • Location of the Luna install (.LunaPath)
  • Location of the generated Luna configuration (.Path)
  • List of servers (.Servers)
  • List of groups (.Groups)
    • Each group has a label (.Label) and members (.Members) which is a list of member names
  • Custom metadata (.Custom) in key/value format where key and value are both strings

For reference, see the default template.

Default Chrystoki Template Contents

The following is the default Chrystoki template that ships with the buildpack. If you need to customize the template, you may opt to copy and modify the template below to fit your needs.

Luna = {
  CloningCommandTimeOut = {{ or (index .Metadata.Custom "CloningCommandTimeOut") 300000 }};
  CommandTimeOutPedSet  = {{ or (index .Metadata.Custom "CommandTimeOutPedSet") 720000 }};
  DefaultTimeOut        = {{ or (index .Metadata.Custom "DefaultTimeOut") 500000 }};
  KeypairGenTimeOut     = {{ or (index .Metadata.Custom "KeypairGenTimeOut") 2700000 }};
  PEDTimeout1           = {{ or (index .Metadata.Custom "PEDTimeout1") 100000 }};
  PEDTimeout2           = {{ or (index .Metadata.Custom "PEDTimeout2") 200000 }};
  PEDTimeout3           = {{ or (index .Metadata.Custom "PEDTimeout3") 10000 }};
}

Misc = {
  PE1746Enabled = {{ or (index .Metadata.Custom "PE1746Enabled") 0 }};
}

Chrystoki2 = {
  LibUNIX64 = {{ .LunaPath }}/libs/64/libCryptoki2.so;
}

{{- if eq (ToLower (index .Metadata.Custom "LoggingEnabled")) "true" }}
CkLog2 = {
  Enabled      = 1;
  LibUNIX64    = {{ .LunaPath }}/libs/64/libcklog2.so;
  LoggingMask  = {{ or (index .Metadata.Custom "LoggingMask") "ALL_FUNC" }};
  LogToStreams = 1;
  NewFormat    = 1;
}
{{ end }}

LunaSA Client = {
  TCPKeepAlive = {{ or (index .Metadata.Custom "TCPKeepAlive") 0 }};
  NetClient    = {{ or (index .Metadata.Custom "NetClient") 1 }};

  ClientCertFile    = {{ .Path }}/client-certificate.pem;
  ClientPrivKeyFile = {{ .Path }}/client-private-key.pem;
  ServerCAFile      = {{ .Path }}/server-certificates.pem;
  HtlDir            = {{ .LunaPath }}/htl;
{{ range $i, $server := .Metadata.Servers }}
  ServerName{{ $i | printf "%02d" }} = {{ $server }};
  ServerPort{{ $i | printf "%02d" }} = 1792;
  ServerHtl{{ $i | printf "%02d" }}  = 0;
{{ end -}}
}

{{- if .Metadata.Groups }}
VirtualToken = {
{{- range $i, $group := .Metadata.Groups }}
  VirtualToken{{ $i | printf "%02d" }}Label   = {{ $group.Label }};
  VirtualToken{{ $i | printf "%02d" }}SN      = 1{{ index $group.Members 0 }};
  VirtualToken{{ $i | printf "%02d" }}Members = {{ Join $group.Members "," }};
{{ end -}}
}
{{ end -}}

{{- if .Metadata.Groups }}
HAConfiguration = {
  AutoReconnectInterval = {{ or (index .Metadata.Custom "AutoReconnectInterval") 60 }};
  HAOnly                = {{ or (index .Metadata.Custom "HAOnly") 1 }};
  reconnAtt             = {{ or (index .Metadata.Custom "reconnAtt") -1 }};
  haLogStatus           = {{ or (index .Metadata.Custom "haLogStatus") "enabled" }};
  haLogToStdout         = {{ or (index .Metadata.Custom "haLogToStdout") "enabled" }};
}
{{ end -}}

{{- if .Metadata.Groups }}
HASynchronize = {
{{- range $i, $group := .Metadata.Groups }}
  {{ $group.Label }} = 1;
{{ end -}}
}
{{ end -}}

JRebel

Image: registry.tanzu.vmware.com/tanzu-jrebel-buildpack/jrebel:<version>

The Tanzu JRebel Buildpack is a Cloud Native Buildpack that contributes the JRebel agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • The application contains a rebel-remote.xml

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

OverOps

Image: registry.tanzu.vmware.com/tanzu-overops-buildpack/overops:<version>

The Tanzu OverOps Buildpack is a Cloud Native Buildpack that contributes the OverOps Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of OverOps

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to environment variables with the pattern TAKIPI_<KEY>=<VALUE>

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Snyk

Image: registry.tanzu.vmware.com/tanzu-snyk-buildpack/snyk:<version>

The Tanzu Snyk Buildpack is a Cloud Native Buildpack that contributes Snyk scanning and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of Snyk

Note: The binding must include the following required Secret values to successfully contribute Snyk

Key Value Description
api-url (Required) The url of the snyk api endpoint.
api-token (Required) The snyk api token used to authenticate against the api endpoint.
org-name (Required) The organization for the snyk service to use.

The buildpack will do the following for Java, NodeJS, Python, Ruby, and Scala applications:

  • Scan the application using Snyk

Configuration

Environment Variable Description
$BP_SNYK_BREAK_BUILD Whether to fail build when issues are found. Defaults to true
$BP_SNYK_SEVERITY_THRESHOLD Configure the lowest severity of issues to display and use to determine build breakage. Defaults to low

Synopsys

Image: registry.tanzu.vmware.com/tanzu-synopsys-buildpack/synopsys:<version>

The Tanzu Synopsys Buildpack is a Cloud Native Buildpack that contributes Synopsys scanning and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • A binding exists with type of SynopsysSeeker

The buildpack will do the following for Java applications:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it
  • Transforms the contents of the binding secret to environment variables with the pattern SEEKER_<KEY>=<VALUE>

The buildpack will do the following for NodeJS applications:

  • Contributes a NodeJS agent to a layer and configures $NODE_MODULES to use it
  • If main module does not already require @synopsys-sig/seeker module, prepends the main module with require('@synopsys-sig/seeker');
  • Transforms the contents of the binding secret to environment variables with the pattern SEEKER_<KEY>=<VALUE>

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

YourKit

Image: registry.tanzu.vmware.com/tanzu-yourkit-buildpack/yourkit:<version>

The Tanzu YourKit Buildpack is a Cloud Native Buildpack that contributes the YourKit Agent and configures it to connect to the service.

Behavior

This buildpack will participate if all the following conditions are met

  • $BP_YOURKIT_ENABLED is set

The buildpack will do the following:

  • Contributes a Java agent to a layer and configures $JAVA_TOOL_OPTIONS to use it

Configuration

Environment Variable Description
$BP_YOURKIT_ENABLED Whether to contribute YourKit support
$BPL_YOURKIT_ENABLED Whether to enable YourKit support
$BPL_YOURKIT_PORT Configure the port the YourKit agent will listen on. Defaults to 10001.
$BPL_YOURKIT_SESSION_NAME Configure the session's name.

Bindings

The buildpack accepts the following bindings:

Type: dependency-mapping

Key Value Description
<dependency-digest> <uri> If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri>

Publishing the Port

When starting an application with the YourKit Profiler enabled, a port must be published. To publish the port in Docker, use the following command:

$ docker run --publish <LOCAL_PORT>:<REMOTE_PORT> ...

The REMOTE_PORT should match the port configuration for the application (10001 by default). The LOCAL_PORT can be any open port on your computer, but typically matches the REMOTE_PORT where possible.

Once the port has been published, your YourKit Profiler should connect to localhost:<LOCAL_PORT> for profiling.

YourKit Configuration

check-circle-line exclamation-circle-line close-line
Scroll to top icon