Core CLI Commands
The two commands you'll type most often are ansible for one-off ad-hoc commands against an inventory, and ansible-playbook for running a full YAML playbook. Ad-hoc commands are ideal for quick checks like 'is this service running on every host' without writing a file, while playbooks are for anything you want to be repeatable, version-controlled, and reviewed. Both commands accept -i to specify an inventory file, -l to limit execution to a subset of hosts, and -u to set the remote SSH user, and both respect the same ansible.cfg configuration file for defaults.
Cricket analogy: Ad-hoc commands are like a quick single run taken to keep the strike rotating, while a full playbook run is like executing a pre-planned batting strategy for the entire innings — both matter, but one is a one-off decision and the other is a rehearsed plan.
# Ad-hoc: ping every host to check connectivity
ansible all -i inventory.ini -m ping
# Ad-hoc: check uptime on webservers group only
ansible webservers -i inventory.ini -m command -a "uptime"
# Run a full playbook
ansible-playbook -i inventory.ini site.yml
# Limit to one host, dry-run, show diffs
ansible-playbook -i inventory.ini site.yml -l web01 --check --diff
# Run only tasks tagged 'deploy'
ansible-playbook -i inventory.ini site.yml --tags deploy
# Prompt for vault password
ansible-playbook -i inventory.ini site.yml --ask-vault-passPlaybook Keywords and Common Modules
Every playbook is built from a small set of recurring keywords: hosts (target group), become (privilege escalation), vars (inline variables), tasks (the list of actions), and handlers (notified, deferred actions). On the module side, a handful cover the vast majority of real work: apt/yum/package for package management, service/systemd for process control, copy/template for file management, file for permissions and directories, user/group for account management, git for source checkout, and uri/get_url for HTTP interactions. Knowing these by name (rather than reaching for shell every time) is what separates idiomatic Ansible from a script wrapped in YAML.
Cricket analogy: Knowing core modules by name is like a captain knowing exactly which specialist bowler to bring on for a given situation — a death-overs specialist here, a spinner there — rather than throwing the ball to whoever's nearest, the way a captain like Eoin Morgan meticulously matched bowlers to match-ups.
- hosts: webservers
become: true
vars:
app_port: 8080
tasks:
- name: Install package
ansible.builtin.package:
name: nginx
state: present
- name: Copy static file
ansible.builtin.copy:
src: files/index.html
dest: /var/www/html/index.html
- name: Render templated config
ansible.builtin.template:
src: app.conf.j2
dest: /etc/app/app.conf
notify: Restart nginx
- name: Ensure service is running
ansible.builtin.service:
name: nginx
state: started
enabled: true
handlers:
- name: Restart nginx
ansible.builtin.service:
name: nginx
state: restartedUse ansible-doc <module_name> (e.g. ansible-doc ansible.builtin.template) to pull up the exact parameter list and examples for any module directly in your terminal, without needing to search online docs.
Variables, Facts, and Loops
Variables can be set at many levels — inline in a play with vars, per-host or per-group in host_vars/group_vars, or passed at runtime with -e key=value on the command line, and Ansible resolves precedence in a well-defined order where command-line -e wins over nearly everything else. ansible_facts (gathered automatically at the start of a play via the setup module, unless gather_facts: false) exposes system details like OS family, IP addresses, and memory, referenced with {{ ansible_facts.os_family }} or the older {{ ansible_os_family }} shorthand. Looping over a list of items is done with the loop keyword (the modern replacement for the older with_items), letting one task install a whole list of packages or create multiple users without duplicating the task block.
Cricket analogy: Variable precedence is like team selection rules where a direct instruction from the captain on the field overrides the pre-match team meeting plan, which itself overrides the standing selection policy — the most immediate, specific input always wins.
# Override a variable at runtime (highest precedence)
ansible-playbook site.yml -e "app_port=9090"
# Check facts for a host
ansible web01 -m setup -a "filter=ansible_os_family"- name: Install a list of packages
ansible.builtin.package:
name: "{{ item }}"
state: present
loop:
- nginx
- git
- curlwith_items still works but is considered legacy syntax; new playbooks should use loop (or loop_control for more advanced looping needs like custom loop variable names) for consistency with current Ansible documentation and community examples.
ansibleruns ad-hoc one-off commands;ansible-playbookruns full, repeatable YAML playbooks.- Common flags:
-i(inventory),-l(limit hosts),-e(extra vars),--check --diff(dry run),--tags(subset of tasks). - Core modules to know by name: package, service, copy, template, file, user, git, uri — prefer these over shell/command.
ansible-doc <module>gives instant offline reference for any module's parameters and examples.- Variable precedence flows from defaults up through group_vars/host_vars/play vars to command-line
-e, which wins. ansible_facts(via the automaticsetupmodule) exposes system details like OS family and network interfaces.- Use
loop(not the legacywith_items) to iterate a task over a list of items.
Practice what you learned
1. What is the main difference between the `ansible` and `ansible-playbook` commands?
2. Which flag performs a dry run and shows exactly what would change without applying it?
3. What command gives instant offline documentation for a specific module's parameters?
4. In Ansible's variable precedence, which of these typically wins over the others?
5. What is the modern, preferred keyword for iterating a task over a list of items?
Was this page helpful?
You May Also Like
Ansible Best Practices
Field-tested conventions for structuring playbooks, roles, and inventories so Ansible automation stays maintainable, secure, and idempotent as it scales.
Ansible Interview Questions
Common Ansible interview questions and detailed answers spanning core concepts, playbook mechanics, and real-world troubleshooting scenarios.
Deploying a Web App with Ansible
A hands-on walkthrough of provisioning a server, installing dependencies, and deploying a web application with an Ansible playbook, including zero-downtime rollout patterns.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics