Use the Tanzu Partner Buildpacks

This topic tells you how to use the Tanzu Partner Buildpacks.

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 criteria need to be met and when met, what that buildpack will do.

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 is 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of ApacheSkyWalking

The buildpack does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of AppDynamics

The buildpack does 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. In the tanzu-appdynamics-buildpack v3.8.0 and later, this directory is group writable. This conforms to the buildpack spec where the group is always cnb regardless of the user.

The buildpack does 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 does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

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

The buildpack does the following:

• Contributes AspectJ load time weaving configuration to $JAVA_TOOL_OPTIONS

Checkmarx

Image: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of Checkmarx

The buildpack does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of AppInternals

The buildpack does 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: tanzu-build.packages.broadcom.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 to connect to the service.

Behavior

This buildpack participates if all of the following conditions are met:

• A binding exists with type of ContrastSecurity

The buildpack does 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 v3.10.0, all Contrast Security agent logs are written to STDOUT by default. This ensures visibility of the agent logs and ensures that running the container as a custom user, instead of the cnb user, does not fail due to file permissions.

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

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

The buildpack does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• The $BP_DATADOG_ENABLED is set to a truthy value such as true, t, or 1 ignoring case

The buildpack does the following for Java applications:

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

The buildpack does the following for Node.js applications:

• Contributes the Datadog Node.js trace agent to a layer
• Requires 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. For the full list, see the Datadog documentation.

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

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. You can use the standard Datadog instructions for your container orchestrator of choice to install this agent. For more information see the Datadog documentation. The Paketo documentation also has instructions for various runtimes. See the paketo-buildpacks repository in GitHub.

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: tanzu-build.packages.broadcom.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 participates if all of 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 does 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>. This Excludes 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of ElasticAPM

The buildpack does 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 does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of JaCoCo

The buildpack does 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: tanzu-build.packages.broadcom.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 participates if all of 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, run:

docker run --publish LOCAL-PORT:REMOTE-PORT ...

Where:

• REMOTE-PORT must match the port configuration for the application. The default is 8849.
• LOCAL-PORT can be any open port on your computer, but it typically matches the REMOTE-PORT where possible.

After the port has been published, your JProfiler Profiler will connect to localhost:LOCAL-PORT for profiling.

New Relic

Image: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of NewRelic

The buildpack does 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 does 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 does 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 tanzu-build.packages.broadcom.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 you can use 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 Client → ClientCertFile 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 Client → ClientPrivKeyFile 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 Client → ServerCAFile 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. You can customize it 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 labeled 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 must 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

For example:

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 template used. For a description of how the default template uses these values, see Default Chrystoki Template earlier.

Custom Templates

You can generate a custom Chrystoki template. The template uses the Go text/template format. In addition, most of the Go strings methods, such as Join, Split, Trim, are exposed for use in the template.

Your custom Chrystoki template also has access to the metadata file that you can use 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 the 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 can copy and modify the following template 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• The application contains a rebel-remote.xml

The buildpack does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of OverOps

The buildpack does 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: tanzu-build.packages.broadcom.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 participates if all of 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 does 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: tanzu-build.packages.broadcom.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 participates if all of the following conditions are met:

• A binding exists with type of SynopsysSeeker

The buildpack does 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 does 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: tanzu-build.packages.broadcom.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 participates if all of 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, run:

docker run --publish LOCAL-PORT:REMOTE-PORT ...

Where:

• REMOTE-PORT must match the port configuration for the application. The default is 10001.
• LOCAL-PORT can be any open port on your computer, but it typically matches the REMOTE-PORT where possible.

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