Where Ansible's defaults come from, the connection and plugin layers underneath every task, and the SSH-overhead math that decides how long a deploy takes. Tuning the Larkspur prod web tier from a CI runner — config precedence, pipelining, the plugin types, and the debugging ladder that locates a failure.
6 topics
Because Ansible has no agent doing local work, almost everything that shapes a run happens on the control node and over the wire: which config file won, which transport reaches the host, which plugins format the output and pull the data, and how much SSH overhead each task pays. This chapter is the layer beneath the playbooks you have been writing — the settings and pluggable parts that decide behavior and speed.
The running example is Layer B, the Larkspur prod fleet: six web hosts driven from a GitHub Actions runner. You will set the repo's defaults in ansible.cfg, see the connection plugin that reaches each host and the wider plugin ecosystem around it, do the overhead math that turns a slow deploy into a fast one with pipelining and forks, weigh a third-party accelerator against the supported in-tree path, and walk the debugging ladder from a one-line summary down to the exact SSH command Ansible ran.