AppDynamics Smart Agent Management with GitHub Actions Automated deployment and lifecycle management of AppDynamics Smart Agent across multiple EC2 hosts using GitHub Actions with a self-hosted runner. https://github.com/chambear2809/github-actions-lab/tree/main 🎯 Overview This lab demonstrates how to use GitHub Actions to manage AppDynamics Smart Agent and various AppDynamics agents (Node, Machine, DB, Java) across multiple Ubuntu EC2 instances within a single AWS VPC. The project includes 11 automated workflows covering the complete agent lifecycle. Key Features: 🚀 Parallel Deployment - Deploy to multiple hosts simultaneously 🔄 Complete Lifecycle Management - Install, uninstall, stop, and clean agents 🏗️ Infrastructure as Code - All workflows version-controlled 🔐 Secure - SSH key-based authentication, private VPC networking 📈 Massively Scalable - Deploy to thousands of hosts with automatic batching 🎛️ Self-hosted Runner - Executes within your AWS VPC 📊 Architecture All infrastructure runs in a single AWS VPC with a shared security group. The self-hosted runner communicates with target hosts via private IPs. View detailed architecture diagrams → 🚀 Quick Start Prerequisites AWS VPC with EC2 instances (Ubuntu) Self-hosted GitHub Actions runner in the same VPC SSH key pair for authentication AppDynamics Smart Agent package and config 1️⃣ Clone and Configure git clone https://github.com/chambear2809/github-actions-lab.git cd github-actions-lab   2️⃣ Set Up GitHub Secrets Navigate to: Settings → Secrets and variables → Actions Required Secret: SSH_PRIVATE_KEY - Your SSH private key (PEM format) 3️⃣ Set Up GitHub Variables Navigate to: Settings → Secrets and variables → Actions → Variables Required Variable: DEPLOYMENT_HOSTS - Target host IPs (one per line) 172.31.1.243 172.31.1.48 172.31.1.5   Optional Variables: SMARTAGENT_USER - User for Smart Agent service (e.g., appdynamics) SMARTAGENT_GROUP - Group for Smart Agent service (e.g., appdynamics) 4️⃣ Deploy! Via GitHub UI: Go to Actions tab Select "Deploy Smart Agent" Click "Run workflow" Optionally adjust batch size (default: 256) Click "Run workflow" Via GitHub CLI: gh workflow run "Deploy Smart Agent" --repo chambear2809/github-actions-lab # With custom batch size gh workflow run "Deploy Smart Agent" --repo chambear2809/github-actions-lab -f batch_size=128   📋 Available Workflows Deployment (1 workflow) Workflow Description Scale Trigger Deploy Smart Agent (Batched) Installs Smart Agent and starts service Any Manual only Agent Installation (4 batched workflows) Workflow Command Scale Trigger Install Node Agent (Batched) smartagentctl install node Any Manual only Install Machine Agent (Batched) smartagentctl install machine Any Manual only Install DB Agent (Batched) smartagentctl install db Any Manual only Install Java Agent (Batched) smartagentctl install java Any Manual only Agent Uninstallation (4 batched workflows) Workflow Command Scale Trigger Uninstall Node Agent (Batched) smartagentctl uninstall node Any Manual only Uninstall Machine Agent (Batched) smartagentctl uninstall machine Any Manual only Uninstall DB Agent (Batched) smartagentctl uninstall db Any Manual only Uninstall Java Agent (Batched) smartagentctl uninstall java Any Manual only Smart Agent Management (2 batched workflows) Workflow Description Scale Trigger Stop and Clean Smart Agent (Batched) Stops service and purges data Any Manual only Cleanup All Agents (Batched) Deletes /opt/appdynamics directory Any Manual only Total: 11 workflows - All batched workflows support configurable batch sizes (default: 256) 📚 Documentation Deployment Guide - Complete setup and configuration instructions Architecture Diagrams - Visual infrastructure and workflow diagrams 🛠️ How It Works Developer pushes code or manually triggers a workflow GitHub Actions receives the event and assigns job to self-hosted runner Runner loads target hosts from GitHub variables Parallel Execution - Runner SSHs into each target host simultaneously Commands Execute - Install/uninstall/stop/clean operations run on each host Results Reported - Success/failure status sent back to GitHub 🔐 Security Private Network - All communication via VPC private IPs SSH Keys - Stored securely as GitHub secrets No Public Access - Target hosts don't need public IPs Security Group - Restricts SSH access to runner only 📈 Scaling All workflows use automatic batching to support any number of hosts: How It Works Automatic batching - Splits hosts into groups of 256 (configurable) Sequential batch processing - Avoids overwhelming runner resources Parallel within batch - Each batch processes all hosts simultaneously Works at any scale - 1 host to thousands Batching Strategy Splits your host list into manageable batches Processes each batch as a separate job sequentially Deploys to all hosts within each batch in parallel using background processes Examples: 10 hosts = 1 batch, all deploy in parallel 500 hosts = 2 batches × 256 hosts 1,000 hosts = 4 batches × 256 hosts 5,000 hosts = 20 batches × 256 hosts 🤝 Contributing This is a lab/demo project. Feel free to fork and adapt for your own use cases! 🔗 Links GitHub Actions Documentation AppDynamics Documentation Self-hosted Runners ... View more

https://github.com/Cisco-Observability-TME/ansible-smartagent-install   Introduction Welcome, intrepid tech explorer, to the ultimate guide on deploying the Cisco AppDynamics Smart Agent across multiple hosts! In this adventure, we'll blend the magic of automation with the precision of Ansible, ensuring your monitoring infrastructure is both robust and elegant. So, buckle up, fire up your terminal, and let's dive into a journey that will turn your deployment woes into a seamless orchestration symphony. Steps to Deploy Cisco AppDynamics Smart Agent Step 1: Install Ansible on macOS Before we embark on this deployment journey, we need our trusty automation tool, Ansible. Follow these steps to install Ansible on your macOS system using Homebrew: Install Homebrew (if not already installed): /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Install Ansible: brew install ansible Verify the Installation: ansible --version You should see output indicating the installed version of Ansible. Step 2: Prepare Your Files and Directory Structure The project directory should contain the following files: ├── appdsmartagent_64_linux_24.6.0.2143.deb ├── appdsmartagent_64_linux_24.6.0.2143.rpm ├── inventory-cloud.yaml ├── inventory-local.yaml ├── inventory-multiple.yaml ├── smartagent.yaml └── variables.yaml Step 3: Understanding the Files 1. inventory-cloud.yaml, inventory-local.yaml, inventory-multiple.yaml These inventory files list the hosts where the Smart Agent will be deployed. Each file is structured similarly: all: hosts: smartagent-hosts: ansible_host: <IP_ADDRESS> ansible_username: <USERNAME> ansible_password: <PASSWORD> ansible_become: yes ansible_become_method: sudo ansible_become_password: <BECOME_PASSWORD> ansible_ssh_common_args: '-o StrictHostKeyChecking=no' Update these placeholders with your actual host details. Explanation of smartagent.yaml This Ansible playbook is designed to deploy the Cisco AppDynamics Smart Agent on multiple hosts. Let's break down each section and task in detail. Playbook Header --- name: Deploy Cisco AppDynamics SmartAgent hosts: all become: yes vars_files: - variables.yaml # Include the variable file name: Describes the playbook. hosts: Specifies that the playbook should run on all hosts defined in the inventory. become: Indicates that the tasks should be run with elevated privileges (sudo). vars_files: Includes external variables from the variables.yaml file. Tasks Ensure required packages are installed (RedHat) - name: Ensure required packages are installed (RedHat) yum: name: - yum-utils state: present update_cache: yes when: ansible_os_family == "RedHat" Uses the yum module to install the yum-utils package on RedHat-based systems. The task runs only if the operating system family is RedHat (when: ansible_os_family == "RedHat"). Ensure required packages are installed (Debian) - name: Ensure required packages are installed (Debian) apt: name: - curl - debian-archive-keyring - apt-transport-https - software-properties-common state: present update_cache: yes when: ansible_os_family == "Debian" Uses the apt module to install necessary packages on Debian-based systems. This task is conditional based on the operating system family being Debian. Ensure the directory exists - name: Ensure the directory exists file: path: /opt/appdynamics/appdsmartagent state: directory mode: '0755' Uses the file module to create the directory /opt/appdynamics/appdsmartagent with the specified permissions. Check if config.ini exists - name: Check if config.ini exists stat: path: /opt/appdynamics/appdsmartagent/config.ini register: stat_config Uses the stat module to check for the existence of config.ini and registers the result in stat_config. Create default config.ini file if it doesn't exist - name: Create default config.ini file if it doesn't exist copy: dest: /opt/appdynamics/appdsmartagent/config.ini mode: '0644' content: | [default] AccountAccessKey="{{ smart_agent.account_access_key }}" ControllerURL="{{ smart_agent.controller_url }}" ControllerPort=443 AccountName="{{ smart_agent.account_name }}" FMServicePort={{ smart_agent.fm_service_port }} EnableSSL={{ smart_agent.ssl | ternary('true', 'false') }} when: not stat_config.stat.exists Uses the copy module to create a default config.ini file if it doesn't exist. The content field uses Jinja2 templating to populate the configuration with variables from variables.yaml. Configure Smart Agent - name: Configure Smart Agent lineinfile: path: /opt/appdynamics/appdsmartagent/config.ini regexp: '^{{ item.key }}=' line: "{{ item.key }}={{ item.value }}" loop: - { key: 'AccountAccessKey', value: "{{ smart_agent.account_access_key }}" } - { key: 'ControllerURL', value: "{{ smart_agent.controller_url }}" } - { key: 'AccountName', value: "{{ smart_agent.account_name }}" } - { key: 'FMServicePort', value: "{{ smart_agent.fm_service_port }}" } - { key: 'EnableSSL', value: "{{ smart_agent.ssl | ternary('true', 'false') }}" } Uses the lineinfile module to ensure specific lines in config.ini are present and correctly configured. Set the Smart Agent package path (Debian) - name: Set the Smart Agent package path (Debian) set_fact: smart_agent_package: "{{ playbook_dir }}/appdsmartagent_64_linux_24.6.0.2143.deb" when: ansible_os_family == "Debian" Uses the set_fact module to define the path to the Smart Agent package for Debian systems. Set the Smart Agent package path (RedHat) - name: Set the Smart Agent package path (RedHat) set_fact: smart_agent_package: "{{ playbook_dir }}/appdsmartagent_64_linux_24.6.0.2143.rpm" when: ansible_os_family == "RedHat" Defines the path to the Smart Agent package for RedHat systems. Fail if Smart Agent package not found (Debian) - name: Fail if Smart Agent package not found (Debian) fail: msg: "Smart Agent package not found for Debian." when: ansible_os_family == "Debian" and not (smart_agent_package is defined and smart_agent_package is file) Uses the fail module to halt execution if the Smart Agent package is not found for Debian systems. Fail if Smart Agent package not found (RedHat) - name: Fail if Smart Agent package not found (RedHat) fail: msg: "Smart Agent package not found for RedHat." when: ansible_os_family == "RedHat" and not (smart_agent_package is defined and smart_agent_package is file) Halts execution if the Smart Agent package is not found for RedHat systems. Copy Smart Agent package to target (Debian) - name: Copy Smart Agent package to target (Debian) copy: src: "{{ smart_agent_package }}" dest: "/tmp/{{ smart_agent_package | basename }}" when: ansible_os_family == "Debian" Uses the copy module to transfer the Smart Agent package to the target host for Debian systems. Install Smart Agent package (Debian) - name: Install Smart Agent package (Debian) command: dpkg -i /tmp/{{ smart_agent_package | basename }} when: ansible_os_family == "Debian" Uses the command module to install the Smart Agent package on Debian systems. Copy Smart Agent package to target (RedHat) - name: Copy Smart Agent package to target (RedHat) copy: src: "{{ smart_agent_package }}" dest: "/tmp/{{ smart_agent_package | basename }}" when: ansible_os_family == "RedHat" Transfers the Smart Agent package to the target host for RedHat systems. Install Smart Agent package (RedHat) - name: Install Smart Agent package (RedHat) yum: name: "/tmp/{{ smart_agent_package | basename }}" state: present disable_gpg_check: yes when: ansible_os_family == "RedHat" Uses the yum module to install the Smart Agent package on RedHat systems. Restart Smart Agent service - name: Restart Smart Agent service service: name: smartagent state: restarted Uses the service module to restart the Smart Agent service to apply the new configuration. Clean up temporary files - name: Clean up temporary files file: path: "/tmp/{{ smart_agent_package | basename }}" state: absent Uses the file module to remove the temporary Smart Agent package files from the target hosts. 3. variables.yaml This file contains the variables used in the playbook: smart_agent: controller_url: 'tme.saas.appdynamics.com' account_name: 'ACCOUNT NAME' account_access_key: 'ACCESS KEY' fm_service_port: '443' ssl: true smart_agent_package_debian: 'appdsmartagent_64_linux_24.6.0.2143.deb' smart_agent_package_redhat: 'appdsmartagent_64_linux_24.6.0.2143.rpm' Explaining the Variables File In Ansible, variables are used to store values that can be reused throughout your playbooks, roles, and tasks. They help make your playbooks more flexible and easier to maintain by allowing you to define values in one place and reference them wherever needed. Variables can be defined in several places, including: Playbooks: Directly within the playbook file. Inventory files: Associated with hosts or groups of hosts. Variable files: Separate YAML files that are included in playbooks. Roles: Within the defaults and vars directories of a role. Command line: Passed as extra variables when running the playbook. Variables can be referenced using the Jinja2 templating syntax, which is denoted by double curly braces {{ }}. The provided variables file is a YAML file that contains a set of variables used in an Ansible playbook. Here is a breakdown of the variables defined in the file: smart_agent: controller_url: 'tme.saas.appdynamics.com' account_name: 'ACCOUNT NAME' account_access_key: 'ACCESS CODE HERE' fm_service_port: '443' ssl: true smart_agent_package_debian: 'appdsmartagent_64_linux_24.6.0.2143.deb' smart_agent_package_redhat: 'appdsmartagent_64_linux_24.6.0.2143.rpm' smart_agent: This is a dictionary (or hash) containing several key-value pairs related to the configuration of a "smart agent". controller_url: The URL of the controller. account_name: The name of the account. account_access_key: The access key for the account. fm_service_port: The port number for the service. ssl: A boolean indicating whether SSL is used. smart_agent_package_debian: The filename of the Debian package for the smart agent. smart_agent_package_redhat: The filename of the Red Hat package for the smart agent. Step 4: Execute the Playbook To deploy the Smart Agent, run the following command from your project directory: ansible-playbook -i inventory-cloud.yaml smartagent.yaml Replace inventory-cloud.yaml with the appropriate inventory file for your setup. And there you have it! With these steps, you're now equipped to deploy the Cisco AppDynamics Smart Agent to multiple hosts with ease. Happy deploying! ... View more

Gone are the days of point-and-click monotony – we're going full CLI commando! Whether you're managing a lone server or herding a flock of hosts, this guide will transform you from a nervous newbie to a confident commander of the AppDynamics realm. So grab your favorite caffeinated beverage, fire up that terminal, and let's turn those command-line frowns upside down! Installing the Smart Agent CLI Before we can conquer the world of application monitoring, we need to arm ourselves with the right tools. Let's start by installing the AppDynamics Smart Agent CLI with Python 3.11, our trusty sidekick in this adventure. Hosting the Smart Agent Package on a Local Web Server Before we start spreading the Smart Agent love to multiple hosts, let's set up a local web server to host our package. We'll use Python's built-in HTTP server because, let's face it, who doesn't love a bit of Python magic? Navigate to your Smart Agent package directory: cd /path/to/smartagent/package/ Start the Python HTTP server: python3 -m http.server 8000 Your package is now available at http://your-control-node-ip:8000/smartagent-package-name.rpm Verify with: curl http://your-control-node-ip:8000/smartagent-package-name.rpm --output /dev/null Keep this terminal window open – it's the lifeline for our installation process! 1. Verify Python 3.11 Installation First, let's make sure Python 3.11 is ready and waiting: which python3.11 You should see something like: /usr/bin/python3.11 If Python 3.11 is playing hide and seek, you'll need to find and install it before proceeding. 2. Install the Smart Agent CLI Now, let's summon the Smart Agent CLI using the magical incantation below (adjust the RPM filename to match your version): sudo APPD_SMARTAGENT_PYTHON3=/usr/bin/python3.11 yum install appdsmartagent_cli_64_linux_24.6.0.2143.rpm 3. Verify the Installation Let's make sure our new CLI friend is ready to party: appd --version If you see the version number, congratulations! You've just leveled up your AppDynamics game. Installing Smart Agent on a Single Host Let's start small and install the Smart Agent on a single host. Baby steps, right? Prepare your configuration file (config.ini): [default] controller_url: "your-controller-url.saas.appdynamics.com" controller_port: 443 controller_account_name: "your-account-name" access_key: "your-access-key" enable_ssl: true Installing Smart Agent on Multiple Hosts or Locl Feeling confident? Let's scale up and install the Smart Agent across multiple hosts like a boss! Preparing Your Inventory Before we unleash our Smart Agent army, we need to create an inventory of our target hosts. Here are a couple of examples to get you started: For a simple target with additional ansible variables: [targets] 54.221.141.103 ansible_user=ec2-user ansible_ssh_pass=ins3965! ansible_python_interpreter=/usr/bin/python3.11 ansible_ssh_common_args='-o StrictHostKeyChecking=no' Let's break down the provided hosts.ini file: [targets] 54.221.141.103 ansible_user=ec2-user ansible_ssh_pass=ins3965! ansible_python_interpreter=/usr/bin/python3.11 ansible_ssh_common_args='-o StrictHostKeyChecking=no' Group [targets]: This is a group name. In this case, the group is named targets. You can use this group name in your playbooks to refer to all the hosts listed under it. Host 54.221.141.103: This is the IP address of the host that belongs to the targets group. Host Variables Several variables are defined for the host 54.221.141.103: ansible_user=ec2-user: This specifies the SSH user to connect as. In this case, the user is ec2-user. ansible_ssh_pass=ins3965!: This specifies the SSH password to use for authentication. The password is ins3965!. Note that using plain text passwords in inventory files is generally not recommended for security reasons. It's better to use SSH keys or Ansible Vault to encrypt sensitive data. ansible_python_interpreter=/usr/bin/python3.11: This specifies the path to the Python interpreter on the remote host. Ansible needs Python to be installed on the remote host to execute its modules. Here, it is set to use Python 3.11 located at /usr/bin/python3.11. ansible_ssh_common_args='-o StrictHostKeyChecking=no': This specifies additional SSH arguments. In this case, -o StrictHostKeyChecking=no is used to disable strict host key checking. This means that SSH will automatically add new host keys to the known hosts file and will not prompt the user to confirm the host key. This can be useful in automated environments but can pose a security risk as it makes it easier for man-in-the-middle attacks. This hosts.ini file defines a single host (54.221.141.103) in the targets group with specific SSH and Python interpreter settings. Here's a summary of what each setting does: Connect to the host using the ec2-user account. Use the password ins3965! for SSH authentication. Use Python 3.11 located at /usr/bin/python3.11 on the remote host. Disable strict host key checking for SSH connections. For multiple managed nodes: [managed_nodes] managed1 ansible_host=192.168.33.20 ansible_python_interpreter=/usr/bin/python3 managed2 ansible_host=192.168.33.30 ansible_python_interpreter=/usr/bin/python3 Save your file named hosts respectively. You can adjust the hostnames, IP addresses, and other parameters to match your environment. Executing a Local or Multi-Host Installation We can install on our local host by using the following command. sudo ./appd install smartagent -c config.ini -u http://your-control-node-ip:8000/smartagent-package-name.xxx --auto-start -vvvv Now that we have our targets lined up, let's fire away: sudo ./appd install smartagent -c config.ini -u http://your-control-node-ip:8000/smartagent-package-name.xxx -i hosts -q ssh --auto-start -vvvv Replace with hosts if you're using the multiple managed nodes setup. Verifying Installation Let's make sure our Smart Agents are alive and kicking: Check the service status: sudo systemctl status appdynamics-smartagent Look for new nodes in your AppDynamics controller UI under Infrastructure Visibility. Troubleshooting If things go sideways, don't panic! Check the verbose output, verify SSH connectivity, double-check your config file, and peek at those Smart Agent logs. Remember, every IT pro was once a beginner – persistence is key! There you have it, intrepid AppDynamics adventurer! You've now got the knowledge to install, host, and deploy Smart Agents like a true CLI warrior. Go forth and monitor with confidence, knowing that you've mastered the art of the AppDynamics Smart Agent CLI. May your applications be forever performant and your alerts be always actionable! ... View more