Check: Ansible

Ansible works without an agent (agentless). No Ansible daemon runs on a managed node. What you do need is an SSH server, a user to log in as, and Python, which runs most modules. That's what sets Ansible apart from Puppet and Chef with their agents on every server.

You run a playbook on the control node, and it connects to the managed nodes over SSH itself. Pull is handled by a separate utility, ansible-pull: it clones a repository of playbooks onto the node itself and runs them there. That's not the default mode.

The ping module in Ansible has nothing to do with ICMP. It logs in over SSH, runs a tiny Python module and waits for a pong reply. If SSH works but Python doesn't, there's no reply. How to read an UNREACHABLE error is covered in the inventory lesson's lab.

command and shell run an arbitrary command. Ansible has no way to tell whether it changed the system's state, so it honestly reports changed. Running the same playbook again never gives changed=0. That's why files, packages and services use dedicated modules (copy, template, service, apt), and command gets a creates, removes or changed_when.

creates: takes a path. If a file at that path already exists, the command doesn't run, and the task gets status ok. The opposite parameter is removes:: the command only runs if the file exists. You'll need this trick in the mini-project to start nginx only once.

With the check on, Ansible compares the host key's fingerprint against known_hosts and breaks the connection on a mismatch. Without it, Ansible will connect to any server that answers at that address, and hand it its tasks and secrets. This is convenient in training environments and with disposable VMs. In production, the check stays on.

raw sends the command straight over SSH, it doesn't need Python on the host. The script module also works without Python: it copies a local script to the host and runs it there. Fact gathering (gather_facts) runs through Python, so you disable it explicitly. A common pattern: the first step uses raw to install Python, then regular modules take over. The apt module doesn't work for this, since it needs Python on the host itself.

Role defaults sit at the very bottom of the variable priority list. They're overridden by inventory, group_vars, host_vars, play vars and -e. Role vars sit much higher: group_vars and host_vars no longer override them. Above role vars sit, for example, block and task vars, set_fact, role parameters and -e. The rule is simple: anything the role's user is supposed to configure goes in defaults. In the mini-project, the default port lives in the role's defaults, and the web group overrides it through group_vars.

With serial: 2, Ansible runs the whole play on the first two hosts, then the next two, and so on. This is how you do a rolling update: the change reaches servers gradually, and a broken release doesn't take everything down at once. You can give a number, a percentage (25%), or a list with growing batches ([1, 5, "30%"]). How many hosts are processed in parallel inside a batch is set by forks.

keyed_groups in an inventory plugin's config builds groups from attribute values. For example, key: tags.role with prefix: role turns the tag role=web into the group role_web. A new instance with that tag lands in the right group right away, nobody adds it by hand. compose often sits next to it, computing host variables, for example ansible_host from a private IP.