A push model is an automation pattern in which a central management system initiates connections to managed systems and sends configuration changes. It provides centralized control and immediate updates instead of waiting for devices to check in. section 25.2.1 section 25.2
Ansible demonstrates the pattern: an agentless control node connects to managed devices through SSH, normally using TCP port 22, and pushes configuration. It can also use NETCONF. Ansible commonly expresses ordered actions procedurally through playbooks, tasks, inventory, templates, and variables. section 25.2.1 section 25.3
Distinguish the push model from related automation choices:
- Push sends configuration from the server to the client; pull has each client request configuration from the server. section 25.2
- Agentless tools connect without special software on managed devices; agent-based tools require installed agents. section 25.2
- Ansible and Terraform use push and agentless designs, whereas Puppet and Chef primarily use pull and agent-based designs. section 25.2.3 section 25.2.2
- Terraform applies the pattern declaratively to provision infrastructure, while Ansible primarily uses procedural configuration-management tasks. section 25.2.1 section 25.2.2
Centralized configuration update
An administrator places a critical configuration change on the control node, which immediately connects to managed devices and applies the update. This avoids waiting for each device to poll a server, but requires the management system to reach the devices when the change is sent. section 25.2.1
Figure 25.5 Basic Ansible operations. Inventory, template, and variable files define configurations, and playbooks define actions. The control node uses SSH to connect and push configurations to managed devices.
Trace the push workflow from inventory, template, and variable files through playbooks on the control node to SSH connections and managed-device configuration. section 25.2.1
