AppDynamics Extension Buildpack (Multiple Buildpack Approach)
Starting with version v4.6.x of AppDynamics Application Performance Monitoring for PCF tile we will be shipping an AppDynamics extension buildpack appdbuildpack that can be used in tandem with standard build packs using Cloud Foundry’s multiple buildpack workflow. The buildpack serves as a single point for AppDynamics APM support.
- Cloud Foundry Command Line Interface (cf CLI) v6.38 or later is required to use multiple buildpacks. See Installing the cf CLI.
Install or Upgrade AppDynamics Application Performance Monitoring for PCF tile version v4.6.x or later. No additional configuration is needed!
Once the AppDynamics APM for PCF 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
- Include the
appdbuildpackextension buildpack in the
buildpacks: - appdbuildpack - <language specific buildpack>
- In the
envsection, set the
APPD_AGENTenvironment 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: - appd
- Include the
To push your application use the use the cf CLI command,
$ cf push
|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|
The AppDynamics extension buildpack supports configurable environment variables. This allows you to customize how you fetch agent binaries and override agent configuration.
appdbuildpack tries to fetch the corresponding AppDynamics agent from standard language-specific repositories, for example: NuGet for .NET, PyPI for Python, npm for node.js etc.
To override this behavior, you can set the environment variable
APPD_AGENT_HTTP_URL to a custom http url where the binaries are hosted.
appdbuildpack then downloads the agent bits from that url and installs the agent.
env: APPD_AGENT: dotnet APPD_AGENT_HTTP_URL: http://custom-http.server.com/dotnet/4_5_7_0/AppDynamics-DotNetCore-linux-x64-126.96.36.199.zip
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.
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/dotnet/conf/v1
APPD_CONF_HTTP_URLmust point to the location of the folder, not the file location. In the above example, advanced configuration files of AppDynamics DotNet Agent (e.g:
AppDynamicsAgentLog.config) are hosted under
appdbuildpackwill 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 files
AppDynamicsConfig.jsonare downloaded, if located at
http://custom-http.server.com/dotnet/conf/v1. All other files are ignored.
Refer to the AppDynamics documentation for the names and formats of the advanced configuration files applicable to each of the AppDynamics agents.
--- applications: - name: cf-net-linux random-route: true memory: 1G buildpacks: - appdbuildpack - dotnet_core_buildpack env: APPD_AGENT: dotnetcore APPD_AGENT_HTTP_URL: http://cf-app.com/dotnetcore/1/AppDynamics-DotNetCore-linux-x64-188.8.131.52.zip APPD_CONF_HTTP_URL: http://custom-http.server.com/dotnet/conf/v1 DOTNET_CLI_TELEMETRY_OPTOUT: 1 DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true services: - appd
Clear separation of responsibilities between
appdbuildpackand the standard system buildpacks.
appdbuildpackis 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 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 since
appdbuildpackis the sole source of AppDynamics instrumentation logic.
As always, you can find sample applications demostrating multi buildpack approach in our GitHub space. https://github.com/AppDynamics/cloudfoundry-apps