AppDynamics Extension Buildpack (Multi-Buildpack Approach)
Starting with version v4.6.x of AppDynamics Application Performance Monitoring for VMware Tanzu tile we will be shipping an AppDynamics extension buildpack appdbuildpack that can be used in tandem with standard buildpacks using Cloud Foundry’s multiple buildpack workflow. The buildpack serves as a single point for AppDynamics APM support.
Note: The Java buildpack does not support the multi-buildpack approach. As a result AppDynamics APM support is implemented directly in the Java buildpack and the multi-buildpack approach is not used for Java applications.
Sample Applications
You can find sample applications demonstrating the multi-buildpack approach in this GitHub repository
Prerequisites
- Cloud Foundry Command Line Interface (cf CLI) v6.38 or later is required to use multiple buildpacks. See Installing the cf CLI.
Workflow
Install or upgrade AppDynamics Application Performance Monitoring for VMware Tanzu tile version v4.6.x or later.
Once the AppDynamics APM for VMware Tanzu tile is installed, a buildpack with the name appdbuildpack appears in your list of cf environment buildpacks:
$ cf buildpacks Getting buildpacks...
buildpack position enabled locked filename stack meta_buildpack 1 true false meta_buildpack-v1.1.0.zip ... appdbuildpack 25 true false AppDynamics_buildpack-v4.6.10.zip
Edit the following sections of your application’s
manifest.yml
- Include the
appdbuildpack
extension buildpack in thebuildpacks
section.
buildpacks: - appdbuildpack - <language specific buildpack>
- In the
env
section, set theAPPD_AGENT
environment variable corresponding to the language of the application.
env: APPD_AGENT: dotnet
- Bind the application to the AppDynamics service instance, by including it in
services
section.
services: - appd
- Include the
To push your application use the use the cf CLI command,
cf push
.$ cf push
APPD_AGENT values
Language | Standard BuildPack | APPD_AGENT value |
---|---|---|
.NET Framework (Windows) | hwc_buildpack | dotnet |
.NET Core (Linux) | dotnet_core_buildpack | dotnet-linux |
.NET Core (Windows) | binary_buildpack | dotnet-windows |
Python | python_buidpack | python |
GoLang | go_buildpack | golang |
NodeJS | nodejs-buildpack | nodejs |
Advanced Features
The AppDynamics extension buildpack supports configurable environment variables. This allows you to customize how you fetch agent binaries and override agent configuration.
Overriding Agent Binary Downloads
By default appdbuildpack
fetches the corresponding AppDynamics agent from standard language-specific repositories (NuGet for .NET, PyPI for Python and NPM for Node.js). For .NET Framework, .NET Core Windows and Node.js applications, it’s possible to override the repository where appdbuildpack
fetches the agents. If you set the environment variable APPD_AGENT_HTTP_URL
to a custom http url where the agent files are hosted, appdbuildpack
then downloads the agent from that url and installs the agent.
For example, for a .NET Framework application, set APPD_AGENT_HTTP_URL in the env
section of manifest.yaml as shown, and redeploy the application.
env:
APPD_AGENT: dotnet
APPD_AGENT_HTTP_URL: http://<path to custom NuGet package binaries>
Overriding Agent Configuration
By default appdbuildpack
creates the basic configuration needed by the AppDynamics agent to instrument the application. This includes the application AppDynamics name, tier, node and controller information.
Note: The APPD_CONF_HTTP_URL feature has been integrated in the Java buildpack and uses ‘java’ as the APPD_AGENT value. See the Java Applications workflow documentation for more information.
For .NET Framework, .NET Core Windows, .NET Core for Linux and Python applications, appdbuildpack
facilitates adding additional configuration to the agents or overriding the existing default configuration. To acheive this, set the APPD_CONF_HTTP_URL
environment variable to a custom http url where advanced agent configuration files are hosted. The extension buildpack downloads the relevant files related to the AppDynamics agent and extends the agent configuration.
env:
APPD_AGENT: dotnet
APPD_CONF_HTTP_URL: http://custom-http-server.com
appdbuildpack
will look for configuration files under a subfolder relative to APPD_CONF_HTTP_URL
according to the APPD_AGENT
value. So for a .Net Core Linux application, for example, it would look for relevant configuration files such as AppDynamicsConfig.json
under APPD_CONF_HTTP_URL/dotnet-linux
, and for a Python application it would look under APPD_CONF_HTTP_URL/python
. In the example above, it would look under http://custom-http-server.com/dotnet
.
This supports the ability to assign a single value for APPD_CONF_HTTP_URL
for all buildpack types in a foundation using a staging environment variable group
and avoids the need to set it for each application.
$ cf set-staging-environment-variable-group '{"APPD_CONF_HTTP_URL":"http://custom-http.server.com"}'
Notes:
When using
APPD_CONF_HTTP_URL
,appdbuildpack
will only fetch the files with relevant names that are applicable to the agent. In the example above, because it is a dotnet agent, only the filesAppDynamicsAgentLog.config
andAppDynamicsConfig.json
are downloaded fromAPPD_CONF_HTTP_URL/dotnet
. All other files are ignored.When using
APPD_AGENT_HTTP_URL
, the full path including the agent package must be specified, for examplehttp://custom-http.server.com/dotnet-linux/agent/AppDynamics-DotNetCore-linux-x64-4.5.7.0.zip
Refer to the AppDynamics documentation for the names and formats of the advanced configuration files applicable to each of the AppDynamics agents.
Sample manifest.yml
---
applications:
- name: cf-net-linux
random-route: true
memory: 1G
buildpacks:
- appdbuildpack
- dotnet_core_buildpack
env:
APPD_AGENT: dotnetcore
APPD_AGENT_HTTP_URL: http://custom-http-server.com/dotnet-linux/agent/AppDynamics-DotNetCore-linux-x64-4.5.7.0.zip
APPD_CONF_HTTP_URL: http://custom-http-server.com
DOTNET_CLI_TELEMETRY_OPTOUT: 1
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
services:
- appd
Advantages to Using this Approach
Clear separation of responsibilities between
appdbuildpack
and the standard system buildpacks.appdbuildpack
is now solely responsible for anything related to AppDynamics intrumentation.Any new features related to AppDynamics will be shipped through
appdbuildpack
. This significantly reduces the new feature turnaround time compared to shipping AppDynamics bits through standard buildpacks.A single unified workflow to instrument a variety of applications, regardless of the language or framework of the application. Any new feature added to
appdbuildpack
, if applicable, is available across all langauge agents sinceappdbuildpack
is the sole source of AppDynamics instrumentation logic.