Ansible

Ansible is one of the most practical automation tools for infrastructure teams because it is agentless, YAML-based, and easy to adopt for configuration management, patching, and repeatable operational tasks.

Part of my Infrastructure learning notes.

Why Ansible fits infrastructure work

No agent required on managed nodes
Playbooks are readable and version-controlled
Works well across Linux, network devices, and cloud APIs
Integrates naturally with Git-based change workflows

Core concepts

Concept	What it means
Inventory	List of hosts and groups to manage
Playbook	Ordered set of tasks to execute
Task	Single action such as install package or copy file
Role	Reusable bundle of tasks, vars, and templates
Module	Built-in unit of work like `yum`, `copy`, or `service`

Example playbook shape

- hosts: webservers
  become: true
  tasks:
    - name: Ensure package is installed
      ansible.builtin.package:
        name: httpd
        state: present

    - name: Start and enable service
      ansible.builtin.service:
        name: httpd
        state: started
        enabled: true

Common use cases

Baseline server hardening
Package and patch workflows
Application configuration deployment
User and sudo policy management
Repeated troubleshooting remediation steps

Good practices

Keep playbooks idempotent — reruns should be safe
Use roles for reusable patterns
Store automation in Git with review before production use
Test in lower environments first
Limit privilege escalation carefully with become

Ansible in hybrid environments

Ansible is useful across on-premises and cloud systems. The same automation mindset that configures Linux VMs can often extend to cloud instances, load balancers, and DNS records through collections and modules.