Introduction
Working with servers and automation? Then you need to know Ansible commands. This tool helps you manage many servers at once. You write simple instructions, and Ansible does the work on all your servers—no more logging into each machine one by one.
Think of Ansible like a remote control for your servers. You press one button, and the same action happens everywhere. Need to install software on 50 servers? One command does it all. Want to update configuration files? Ansible handles it in seconds. Ansible stands out because it’s agentless. Unlike other tools, you don’t install special software on each server. It uses SSH, which every Linux server already has. This makes it simple to start using right away. Windows servers work too, using PowerShell remoting.
If you’re getting started or want to deepen your skills, enrolling in an Ansible and Terraform course can be a great way to learn automation best practices and manage infrastructure more efficiently.
This Ansible cheat sheet helps you with the commands you will use every day. Both new users and experts will find it helpful. We’ll discuss real examples and explain what each command does.
Before moving onto the Ansible cheat sheet, let us first understand what Ansible CLI is.
What Is Ansible Command Line Interface (CLI)?
The Ansible CLI is how you talk to your servers. You type commands in your terminal, and Ansible carries out your instructions. It connects to your machines, runs tasks, and reports back what happened.
The CLI reads your playbooks (instruction files) and inventory (list of servers). Then it figures out what needs to be done and does it. No agents or special software required on your servers—just SSH access and Python.
Learning Ansible commands helps you work faster. You’ll fix problems quicker and keep your systems running smoothly. The CLI offers different tools for different jobs. Some run quick commands, others execute complex playbooks. Each tool has its purpose in your automation toolkit.
There are a bunch of things that occur behind the scenes when you type an Ansible command. Ansible reads your inventory at first to understand which hosts to target. Thereafter, it accesses those hosts via SSH. Then it transfers Python modules to the remote computers. Lastly, it executes those modules and gathers the outcomes. All this takes place within seconds, which makes automation quick and effective.
Let us now move on to our main section where we will discuss about Ansible commands i.e., Ansible cheat sheet.
Commands For Ansible Cheat Sheet
Here are the Ansible commands you will use most often and are part of Ansible cheat sheet. Each one serves a specific purpose in your automation workflow.
Check Your Ansible Version
| ansible -version | Shows your current Ansible version and configuration details |
| ansible -version -v | Displays version with verbose configuration information |
Get Help with Commands
| ansible -h | Lists all available commands and options |
| ansible-playbook -h | Shows help for the playbook command specifically |
| ansible-doc -h | Displays help for the documentation command |
| man ansible | Opens the manual page with detailed information |
Managing Your Inventory
| ansible all –list-hosts | Shows all hosts in your inventory |
| ansible webservers –list-hosts | Lists hosts in the ‘webservers’ group |
| ansible-inventory –list | Displays your entire inventory in JSON format |
| ansible-inventory –graph | Shows your inventory as a tree structure |
| ansible-inventory -i custom_inventory –list | Uses a custom inventory file |
| ansible-inventory –vars | Shows all variables for each host |
Testing Connections
| ansible all -m ping | Tests SSH connectivity to all hosts |
| ansible webservers -m ping | Pings only the webservers group |
| ansible host1 -m ping | Tests connection to a specific host |
| ansible all -m ping -u username | Connects as a different user |
| ansible all -m ping -k | Prompts for SSH password |
| ansible all -m ping –private-key=~/.ssh/id_rsa | Uses specific SSH key |
Running Ad-Hoc Commands
| ansible all -a “uptime” | Runs the uptime command on all hosts |
| ansible all -m shell -a “df -h” | Checks disk space on all servers |
| ansible webservers -m service -a “name=nginx state=started” | Starts nginx on web servers |
| ansible all -m copy -a “src=/etc/hosts dest=/tmp/hosts” | Copies a file to all servers |
| ansible all -m yum -a “name=httpd state=present” | Installs Apache on RedHat systems |
| ansible all -m apt -a “name=apache2 state=present” | Installs Apache on Debian systems |
| ansible all -m user -a “name=john state=present” | Creates a user account |
| ansible all -m file -a “path=/tmp/test state=directory” | Creates a directory |
Working with Playbooks
| ansible-playbook site.yml | Runs a playbook |
| ansible-playbook site.yml -C | Does a dry run without making changes |
| ansible-playbook site.yml –diff | Shows what will change |
| ansible-playbook site.yml -v | Runs with verbose output |
| ansible-playbook site.yml -vvv | Maximum verbosity for debugging |
| ansible-playbook site.yml -f 10 | Uses 10 parallel processes |
| ansible-playbook site.yml –syntax-check | Checks playbook syntax |
| ansible-playbook site.yml –list-tasks | Lists all tasks in playbook |
| ansible-playbook site.yml –list-hosts | Shows which hosts would be affected |
Using Variables
| ansible-playbook site.yml -e “version=1.5” | Passes extra variables |
| ansible-playbook site.yml -e “@vars.yml” | Loads variables from a file |
| ansible-playbook site.yml –extra-vars “env=production” | Another way to pass variables |
| ansible-playbook site.yml -e ‘{“version”:”1.5″,”env”:”prod”}’ | Passes JSON variables |
| ansible all -m debug -a “var=hostvars[inventory_hostname]” | Shows host variables |
Limiting Execution
| ansible-playbook site.yml -l webservers | Runs only on webservers group |
| ansible-playbook site.yml -l host1 | Runs on a single host |
| ansible-playbook site.yml -l ‘all:!dbservers’ | Runs on all except dbservers |
| ansible-playbook site.yml -l host1,host2 | Runs on multiple specific hosts |
| ansible-playbook site.yml -l ~web.* | Uses regex patterns |
Managing Tasks
| ansible-playbook site.yml -t “configuration” | Runs only tagged tasks |
| ansible-playbook site.yml –skip-tags “packages” | Skips specific tags |
| ansible-playbook site.yml –start-at-task “Install nginx” | Starts from a specific task |
| ansible-playbook site.yml –step | Confirms each task before running |
| ansible-playbook site.yml -t config,deploy | Runs multiple tags |
Gathering Information
| ansible all -m setup | Collects facts about all hosts |
| ansible host1 -m setup -a “filter=ansible_os_family” | Gets specific facts |
| ansible all -m setup -a “gather_subset=network” | Gathers only network facts |
| ansible all -m setup -a “gather_subset=!all,!min,network” | Custom fact gathering |
| ansible windows -m setup | Gathers facts from Windows hosts |
Vault Operations
| ansible-vault create secrets.yml | Creates an encrypted file |
| ansible-vault edit secrets.yml | Edits an encrypted file |
| ansible-vault encrypt existing.yml | Encrypts an existing file |
| ansible-vault decrypt secrets.yml | Decrypts a file |
| ansible-vault view secrets.yml | Views encrypted file without editing |
| ansible-vault rekey secrets.yml | Changes the vault password |
| ansible-playbook site.yml –ask-vault-pass | Prompts for vault password |
| ansible-playbook site.yml –vault-password-file ~/.vault_pass | Uses password file |
Galaxy Commands
| ansible-galaxy init role_name | Creates a new role structure |
| ansible-galaxy install geerlingguy.nginx | Installs a role from Galaxy |
| ansible-galaxy list | Shows installed roles |
| ansible-galaxy remove role_name | Removes an installed role |
| ansible-galaxy search nginx | Searches for roles |
| ansible-galaxy info geerlingguy.nginx | Shows role information |
| ansible-galaxy install -r requirements.yml | Installs from requirements file |
Configuration Management
| ansible-config view | Shows current configuration |
| ansible-config dump | Displays all configuration options |
| ansible-config list | Lists all available settings |
| ansible-config dump –only-changed | Shows only modified settings |
Advanced Execution Options
| ansible-playbook site.yml -D | Shows diff when changing files |
| ansible-playbook site.yml –flush-cache | Clears fact cache |
| ansible-playbook site.yml -b | Runs with become (sudo) |
| ansible-playbook site.yml -K | Prompts for become password |
| ansible-playbook site.yml -u deploy | Runs as specific user |
| ansible-playbook site.yml -c local | Uses local connection |
| ansible-playbook site.yml -i staging | Uses staging inventory |
Debugging and Testing
| ansible-playbook site.yml –list-tags | Shows all available tags |
| ansible -m debug -a “msg={{ ansible_version }}” localhost | Tests variable expansion |
| ansible all -m ping -o | One-line output format |
| ansible-lint playbook.yml | Checks for best practices |
| ansible-playbook site.yml -e “ansible_python_interpreter=/usr/bin/python3” | Sets Python interpreter |
Best Practices for Ansible Command Usage
Always test Ansible commands on a small group first. Use the limit flag to target specific hosts. Run playbooks with check mode before applying changes. This prevents mistakes from affecting production systems.
Keep your Ansible commands in scripts for complex operations. Document what each command does. Use meaningful variable names. This helps team members understand your automation.
Version control your playbooks and inventory. Track changes over time. Review modifications before running them. Good practices prevent problems and make debugging easier.
Let us now move on to next section where we will discuss ansible cheat sheet for AWS.
Ansible Cheat Sheet for AWS
Ansible simplifies cloud operations because it is easy to manage AWS resources using it. You write playbooks that provision EC2 instances, manipulate S3 buckets, and set up security groups. It all remains the same throughout your infrastructure.
For EC2 instances, your playbook defines the AMI, instance type, and region. Add tags to organize resources. Set up security groups in the same playbook. This keeps your infrastructure code together and easy to understand.
Common AWS modules include ec2_instance for managing instances, s3_bucket for storage, and elb_application_lb for load balancers. Each module has specific parameters. The ansible-doc command shows examples for each one.
S3 bucket management works the same way. Create buckets, set permissions, and configure lifecycle policies all through simple YAML files. Your team can review changes before they happen.
Remember to install the boto3 Python library first. Store your AWS credentials safely. Use IAM roles when running from EC2 instances. This keeps your automation secure and reliable.
Let us now discuss ansible cheat sheet for Azure.
Ansible Cheat Sheet for Azure
Azure and Ansible work great together. Create virtual machines, manage storage accounts, and configure networks. All from your command line. No clicking through portals needed.
Start by installing the Azure collection with ansible-galaxy collection install azure.azcollection. Use service principals for authentication. Store credentials in Ansible Vault for security. Your playbooks can then create any Azure resource.
Virtual machine playbooks define size, image, and location. Add data disks and network interfaces. Configure auto-shutdown to save costs. Everything happens automatically.
The azure_rm_virtualmachine module creates VMs. Use azure_rm_storageaccount for storage. Network security groups use azure_rm_securitygroup. Each module follows similar patterns, making them easy to learn.
Storage accounts, databases, and app services follow the same pattern. Write what you want in YAML. Ansible makes it happen. Changes are tracked and repeatable.
Troubleshooting Common Issues
Connection problems happen often. Check SSH keys first. Verify hostnames resolve correctly. Test with the ping module. Most issues come from authentication or network problems.
Syntax errors in playbooks cause failures. Use ansible-playbook –syntax-check to find them. YAML formatting matters. Spaces, not tabs. Consistent indentation throughout.
Module errors usually mean missing dependencies. Read error messages carefully. They tell you what’s wrong. Install required Python libraries. Check module documentation for requirements.
Frequently Asked Questions
Q1. What is the first Ansible command to run?
Start with ansible -version to check your installation. Then run ansible all -m ping to test connections to your hosts. This confirms Ansible can reach your servers.
Q2. How do I run Ansible playbooks?
Use ansible-playbook playbook.yml to run your playbook. Add -C for a dry run first. This shows what would change without actually doing it.
Q3. Can Ansible work without SSH?
Yes, Ansible supports other connection methods. You can use WinRM for Windows hosts. Local connections work for the control machine. But SSH remains the most common method.
Q4. How do I see all available modules?
Run ansible-doc -l to list all modules. Use ansible-doc module_name to see details about a specific module. The documentation includes examples too.
Q5. What’s the difference between -k and -K flags?
The -k flag prompts for SSH password. The -K flag asks for sudo password. Use both when you need different passwords for connection and privilege escalation.
Conclusion
This Ansible cheat sheet covers the commands you need for daily automation work. These commands create your automation toolbox, including simple connection tests all the way up to complex playbook execution.
Start small with ad-hoc commands. Move to simple playbooks. Then build complex automation as you learn. Each Ansible command you master saves time and reduce errors. Your infrastructure becomes more reliable and easier to manage.
Remember the basics: test before applying, use version control, and document your work. These habits make you a better automation engineer.
