Use Init Containers to Instrument Applications

This page describes how to use the init containers option to copy agent files into a Kubernetes® application container at deploy time.

Note: When the Cluster Agent is installed in a cluster, Splunk AppDynamics recommends Cluster Agent auto-instrumentation. See Auto-Instrument Applications with the Cluster Agent.

The init containers option is available in Kubernetes environments used to run additional containers at startup that helps initialize an application. Once the init containers have completed their initialization tasks, they terminate but leave the application container(s) running. For the App Server Agent installation, init containers are used as a delivery mechanism to copy the agent files into the application container at deploy time. See Init Containers Option in Kubernetes.

Copying the agent files at deploy time (instead of at build time) provides advantages over explicitly copying the agent files and dependencies into the application image. The init containers option simplifies the image build process because:

  • You do not need to update each application's Dockerfile to copy the agent files.
  • You do not need to rebuild the application image for agent upgrades.

See the language-specific container installation page for how to use an init container:

Kubernetes Init Container Deployment Spec Example

In the Kubernetes deployment spec example for a Java application, the init container is a second Docker image that contains the App Server Agent files. Because this Docker image is built separately from the application image, you do not need to rebuild the application image when you add or upgrade the App Server Agent.

Scratch-based Java Agent images contain only the cp utility. Use cp -r to copy the agent files. Do not use shell commands, chown, ls, cp -a, or cp -ra. The destination directory must already exist and be writable. For non-root applications, configure a writable runtime directory such as APPDYNAMICS_AGENT_BASE_DIR.

JSON 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-app
spec:
  template:
    spec:
      securityContext:
        runAsUser: 1001
        runAsGroup: 1001
        fsGroup: 1001

      containers:
        - name: java-app
          image: myrepo/java-app:v1
          env:
            - name: APPDYNAMICS_AGENT_BASE_DIR
              value: /opt/jalogs
          volumeMounts:
            - name: appd-agent-repo
              mountPath: /opt/appdynamics-java
            - name: appd-agent-runtime
              mountPath: /opt/jalogs

      initContainers:
        - name: appd-agent
          image: docker.io/appdynamics/java-agent:26.2.0
          command:
            - cp
            - -r
            - /opt/appdynamics/.
            - /opt/appdynamics-java
          volumeMounts:
            - name: appd-agent-repo
              mountPath: /opt/appdynamics-java

      volumes:
        - name: appd-agent-repo
          emptyDir: {}
        - name: appd-agent-runtime
          emptyDir: {}

Dockerfile Example

In this example for a Java application, the Java Agent files in the AppServerAgent folder are copied to the application image and the application JAR file. The agent environment variables are set before the start script runs.

CODE 
FROM openjdk:8-jre-slim

COPY myapp.jar /app
COPY AppServerAgent/ /opt/appdynamics

ENV APPDYNAMICS_AGENT_APPLICATION_NAME=<value>
ENV APPDYNAMICS_AGENT_TIER_NAME=<value>
ENV APPDYNAMICS_AGENT_ACCOUNT_NAME=<value>
ENV APPDYNAMICS_AGENT_ACCOUNT_ACCESS_KEY=<value>
ENV APPDYNAMICS_CONTROLLER_HOST_NAME=<value>
ENV APPDYNAMICS_CONTROLLER_PORT=<value>
ENV APPDYNAMICS_CONTROLLER_SSL_ENABLED=<value>
ENV APPDYNAMICS_JAVA_AGENT_REUSE_NODE_NAME=true
ENV APPDYNAMICS_JAVA_AGENT_REUSE_NODE_NAME_PREFIX=<value>

COPY ./startup.sh /startup.sh
RUN chmod +x /startup.sh
ENTRYPOINT ["/bin/bash", "/startup.sh"]
Note: Kubernetes® is a trademark of The Linux Foundation®.