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 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.
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.
This buildpack will participate if all the following conditions are met
type
of ApacheSkyWalking
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use it-Dskywalking.<KEY>=<VALUE>
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
type
of AppDynamics
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use it
app-agent-config.xml
, custom-activity-correlation.xml
, and log4j2.xml
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:
$NODE_MODULES
to use itappdynamics
module, prepends the main module with require('appdynamics');
APPDYNAMICS_<KEY>=<VALUE>
The buildpack will do the following for PHP applications:
$PHP_INI_SCAN_DIR
to use itAPPDYNAMICS_<KEY>=<VALUE>
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 |
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate all the following conditions are met
<APPLICATION_ROOT>/aop.xml
existsaspectj-weaver.*.jar
existsThe buildpack will do the following:
$JAVA_TOOL_OPTIONS
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.
This buildpack will participate if all the following conditions are met
type
of Checkmarx
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use itEnvironment Variable | Description |
---|---|
$BPL_CHECKMARX_APPLICATION |
Configure the application tag |
$BPL_CHECKMARX_TEAM |
Configure the team. Defaults to CxServer . |
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
type
of AppInternals
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use it<KEY>=<VALUE>
The buildpack optionally accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
type
of ContrastSecurity
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use itAPI__<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:
The buildpack will do the following for NodeJS applications:
API__<KEY>=<VALUE>
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
$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:
$JAVA_TOOL_OPTIONS
to use itThe buildpack will do the following for Node.js applications:
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.
The buildpack optionally accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
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:
$LD_PRELOAD
to use it$DT_TENANT
, $DT_TENANTTOKEN
, and $DT_CONNECTION_POINT
at launch time.DT_<KEY>=<VALUE>
api-token
, api-url
, and environment-id
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
type
of ElasticAPM
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use itELASTIC_APM_<KEY>=<VALUE>
The buildpack will do the following for NodeJS applications:
$NODE_MODULES
to use itelastic-apm-node
module, prepends the main module with require('elastic-apm-node').start();
ELASTIC_APM_<KEY>=<VALUE>
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
type
of JaCoCo
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use it<KEY>=<VALUE>
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
$BP_JPROFILER_ENABLED
is setThe buildpack will do the following:
$JAVA_TOOL_OPTIONS
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 . |
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
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.
This buildpack will participate if all the following conditions are met
type
of NewRelic
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use it
newrelic.yml
NEW_RELIC_<KEY>=<VALUE>
The buildpack will do the following for NodeJS applications:
$NODE_MODULES
to use it
newrelic.js
newrelic
module, prepends the main module with require('newrelic');
NEW_RELIC_<KEY>=<VALUE>
The buildpack will do the following for PHP applications:
$PHP_INI_SCAN_DIR
to use itNEW_RELIC_<KEY>=<VALUE>
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 |
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
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.
This buildpack will pass detection and participate if all of the following conditions are met
type
of LunaSecurityProvider
The buildpack will do the following:
$JAVA_TOOL_OPTIONS
to use itChrystoki.conf
which are all used by the Luna Security AgentThe buildpack accepts the following bindings:
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> |
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.
Luna
block that sets CloningCommandTimeOut
, CommandTimeOutPedSet
, DefaultTimeOut
, KeypairGenTimeOut
, PEDTimeout1
, PEDTimeout2
, PEDTimeout3
to default values. See the template for default values.Misc
block that sets PE1746Enabled
. It defaults to 0
.Chrystoki2
block that sets LibUNIX64
to the path for the library file.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.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.
1792
and ServerHtl
set to 0
.VirtualToken
block which creates the following entries for each group provided through the template metadata.
1
prefixed to the first member of the group's list of members.HAConfiguration
block which sets the following to default values: HAOnly
, reconnAtt
, haLogStatus
, haLogToStdout
.HASynchronize
block that contains an entry for each group's label, specified through template metadata, and sets the value to 1
.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
.
The template metadata file should be a TOML file with the following format.
servers
groups
, each HA group has a label
property and an array of strings called members
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.
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:
.LunaPath
).Path
).Servers
).Groups
)
.Label
) and members (.Members
) which is a list of member names.Custom
) in key/value format where key and value are both stringsFor reference, see the default template.
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 -}}
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.
This buildpack will participate if all the following conditions are met
rebel-remote.xml
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use itThe buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
type
of OverOps
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use itTAKIPI_<KEY>=<VALUE>
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
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:
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 |
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.
This buildpack will participate if all the following conditions are met
type
of SynopsysSeeker
The buildpack will do the following for Java applications:
$JAVA_TOOL_OPTIONS
to use itSEEKER_<KEY>=<VALUE>
The buildpack will do the following for NodeJS applications:
$NODE_MODULES
to use it@synopsys-sig/seeker
module, prepends the main module with require('@synopsys-sig/seeker');
SEEKER_<KEY>=<VALUE>
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.
This buildpack will participate if all the following conditions are met
$BP_YOURKIT_ENABLED
is setThe buildpack will do the following:
$JAVA_TOOL_OPTIONS
to use itEnvironment 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. |
The buildpack accepts the following bindings:
dependency-mapping
Key | Value | Description |
---|---|---|
<dependency-digest> |
<uri> |
If needed, the buildpack will fetch the dependency with digest <dependency-digest> from <uri> |
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.