What's changed: Initial version (topic 2.04, subtopics 2.04.1–2.04.6)
4.6System Configuration Tools (Ansible)
Learn the value automation brings—standardization, efficiency, scalability, and idempotency—along with the core concepts of Ansible (inventory, modules, Playbooks, YAML), the ansible and ansible-playbook commands, and typical use cases (provisioning VMs/containers, application releases, and network device configuration changes).
As server counts grow, manual configuration becomes a breeding ground for inconsistent results and human error. Configuration management tools solve this by letting you declare the desired state and applying it automatically—and within LinuC's scope, Ansible is the representative example.
4.6.1The value automation brings
- Standardization: defining configuration as code (a Playbook) instead of a manual runbook means the same result regardless of who runs it. Efficiency: automating repetitive work reduces human cost.
- Scalability: a procedure written for one host applies unchanged to hundreds. Idempotency: running the same Playbook repeatedly makes no change once the target is already in the desired state—the outcome converges.
4.6.2Core Ansible concepts and commands
- The inventory is a file listing managed hosts (which can be grouped). A module is an executable unit for a single operation like placing a file or installing a package. A Playbook is the configuration definition that sequences modules as tasks, written in YAML.
- Execution commands: ansible (runs a single ad-hoc command, e.g.
ansible all -m ping) and ansible-playbook (runs an entire Playbook file, e.g.ansible-playbook site.yml). - Typical use cases: provisioning virtual servers/containers, application release work, and retrieving/changing network device configuration. Notably agentless, using existing channels such as SSH.
The most common point: the definition of idempotency—running repeatedly makes no change once the target is already in the desired state. Also standard: the contrast ansible = one command run immediately vs. ansible-playbook = runs a whole Playbook, that Playbooks are written in YAML, and the term hierarchy—inventory = list of target hosts, module = execution unit for an operation, Playbook = the task definition.
In practice, idempotency means "the Playbook can be safely re-run any number of times". A task declaring package installation with state=present will install it if missing, and do nothing if it is already installed. Contrast this with a shell script that unconditionally runs apt install every time—the latter may change something on every run and so is not idempotent. Idempotency is precisely what makes periodic runs (e.g., via cron) and recovering by re-running a Playbook that failed partway safe. A typical workflow: first define target hosts in the inventory (e.g., grouping web servers as [web]), then describe the desired state for each host as a combination of modules (package, copy, service, etc.) inside a Playbook written in YAML. A one-off connectivity check or emergency single action is handled with the ansible command (e.g., ansible web -m ping), while applying configuration on an ongoing basis runs the whole thing with ansible-playbook (e.g., ansible-playbook site.yml). Typical uses include rolling out identical initial configuration across newly provisioned virtual servers, releasing a new application version across many servers in sequence, and retrieving current configuration state from network devices to apply changes in a planned way.
| Concept | Role | Example |
|---|---|---|
| Inventory | List and group target hosts | [web] group |
| Module | Execution unit for one operation | package, copy, service |
| Playbook | Task definition (YAML) | site.yml |
| ansible-playbook | Runs an entire Playbook | ansible-playbook site.yml |
Trap: "the ansible command runs an entire Playbook file" is wrong—running a whole Playbook is ansible-playbook's job, while the ansible command is for ad-hoc single-command execution. Also, "idempotency means every run always makes some change" is wrong—idempotency means no change is made once the target is already in the desired state.
4.6.3Section summary
- Automation's value: standardization, efficiency, scalability, idempotency (no change if already in the desired state)
- Inventory = target hosts / module = operation unit / Playbook = YAML definition. Single command via ansible; full run via ansible-playbook
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A Playbook was accidentally run twice in a row against the same target hosts. Given Ansible's idempotency, what happens on the second run?
Q2. You want to run a one-off connectivity check across several servers right now, without executing the whole site.yml Playbook. What should you use?
Q3. For a batch of newly provisioned virtual servers, you want to apply the same initial setup—package installation, config file placement, service startup—in a way that scales to more target hosts unchanged. What is the appropriate configuration management approach?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.