# Ansible Satellite Overview
The CMDB-360 Ansible Satellite provides the ability to run Ansible playbooks against your CMDB-360 assets.
# Ansible
Ansible is an open-source IT automation tool developed by Red Hat that simplifies configuration management, application deployment, and task orchestration across infrastructure. Ansible uses a agentless architecture, meaning it doesn’t require any software installed on the machines it manages. It controls cloud deployments through available collections and may also connect to remote hosts over SSH (or WinRM for Windows) and executes tasks, all defined in human-readable YAML files called playbooks.
Why people use it:
- Simple to learn — YAML is readable even for non-developers
- No agents to install or maintain on managed nodes
- Idempotent by design — running a playbook multiple times produces the same result
- Large ecosystem of community modules via Ansible Galaxy
- Works well for both small setups and large-scale enterprise environments
Ansible is commonly used for provisioning servers, deploying applications, managing cloud infrastructure, and enforcing consistent system configurations across environments.
CMDB-360 leverages the power and utility of Ansible to allow you to manage the running of Ansible playbooks on your assets directly from CMDB-360.
# Deployment / Installation
The Ansible Satellite may be installed or deployed in a number of different ways:
- From a cloud marketplace as a “cloud appliance”
- On a CMDB-360 LaunchPad
- On a virtual machine
Please see https://docs.cmdb360.com/docs/Satellites/Ansible-satellite/Deployment-Topologies/DeploymentTopologies for more details about Azure Satellite Deployment Options.
# Ansible Satellite Configuration
The Ansible Satellite can be configured to access a Git repository containing your playbooks. In this way, you can share your playbooks to with other users and CMDB-360 Ansible Satellites. These playbooks can be customized to fit your needs
# Ansible Satellite Concepts
The Ansible Satellite allows you to run playbooks against CMDB-360 assets. These playbooks can leverage extensive collections of work provided by Red Hat, the Ansible community and the Cloud providers. Ansible was originally designed to manage servers and workstations by connecting via ssh and key pairs to execute commands on them. However, today each cloud provider supplies a collection of ansible modules to manage and control those assets using REST APIs.
Authentication Data for access via ssh or to the cloud provider is stored in a cloud vault and accessed by CMDB-360 when the playbooks are run. See the following document for more information about vaults. https://docs.cmdb360.com/docs/Satellites/Ansible-satellite/Vault/VaultOverview
# Cloud level access
Cloud level access requires some sort of authentication. Typically some account identifier along with a client id and password. Once this access is set up, the Ansible Satellite can manage cloud assets. Things like stop and start a VM or create, destroy and modify VMs or network assets. Permissions can be managed with the cloud authentication to control users access to modify and control assets.
# Machine level access
To make modifications on a server or workstation, Ansible connects via ssh, winrm or AWS SSM. This allows you to make changes or updates to the system. For instance to update the OS, or add/delete a user account on the device. Red Hat and Ansible community provide collections through Ansible Galaxy to cover almost any scenario. The credentials needed for this connection is stored in a file managed by your Automation Credentials Vault, that is accessed through CMDB-360. The Ansible Satellite uses these credentials to create the connection to the device at the device’s private IP address. As such, the Ansible Satellite must have network connectivity to the devices private IP.
For more info on Ansible Satellite authentication see: https://docs.cmdb360.com/docs/Satellites/Ansible-satellite/Satellite-Authentication/Satellite-Authentication