AppDynamics Extension Buildpack

From v4.6.x onwards, AppDynamics provides 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.

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.

Before You Begin

Cloud Foundry Command Line Interface (cf CLI) v6.38 or later is required to use multiple buildpacks. See Installing the cf CLI.

WorkFlow

1. Install or upgrade AppDynamics Application Performance Monitoring for VMware Tanzu tile version v4.6.x or later.

2. Once the AppDynamics APM for VMware Tanzu tile is installed, a buildpack with the name appdbuildpackappears 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

   CODE

3. Edit the following sections of your application’s manifest.yml.

   1. Include the appdbuildpack extension buildpack in the buildpacks section.

      buildpacks: - appdbuildpack - <language specific buildpack>

      CODE

   2. In the env section, set the APPD_AGENT environment variable corresponding to the language of the application.

      env:
        APPD_AGENT: dotnet

      CODE

   3. Bind the application to the AppDynamics service instance, by including it in services section.

      services:
       - appd

      CODE

4. To push your application use the use the cf CLI command, cf push. $ cf push

APPD_AGENT values

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.

If the custom download location requires basic authentication, then you can provide the credentials by specifying the APPD_BASIC_AUTH_USERNAME and APPD_BASIC_AUTH_PASS environment variables.

For example, for a .NET Framework application, set APPD_AGENT_HTTP_URL and basic authentication credential variables (if required) in the env section of the manifest.yaml file, and redeploy the application.

  env:
    APPD_AGENT: dotnet
    APPD_AGENT_HTTP_URL: http://<path to custom NuGet package binaries>
    APPD_BASIC_AUTH_USERNAME: <username> # basic auth username (optional)
    APPD_BASIC_AUTH_PASS: <password> # basic auth password (optional)

Overriding Agent Configuration

By default appdbuildpack creates the basic configuration required by the AppDynamics Agent to instrument the application. This includes the application AppDynamics name, tier, node and Controller information.

The APPD_CONF_HTTP_URL feature has been integrated in the Java buildpack and uses java as the APPD_AGENT value. See Java Applications workflow documentation.

For .NET Framework, .NET Core Windows, .NET Core for Linux and Python applications, appdbuildpack facilitates 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
    APPD_BASIC_AUTH_USERNAME: <username> # basic auth username (optional)
    APPD_BASIC_AUTH_PASS: <password> # basic auth password (optional)

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 preceeding example, 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"}'

• 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 files AppDynamicsAgentLog.config and AppDynamicsConfig.json are downloaded from APPD_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 example—http://custom-http.server.com/dotnet-linux/agent/AppDynamics-DotNetCore-linux-x64-4.5.7.0.zip

• Refer to the Install App Server Agents 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 since appdbuildpack is the sole source of AppDynamics instrumentation logic.