DevOpsAnsible

Ansible

Simple, agentless IT automation. Configuration management, application deployment, task automation, and orchestration.

Agentless

No agents on managed nodes. Uses SSH and Python.

YAML Playbooks

Human-readable automation expressed in YAML.

Idempotent

Running the same playbook repeatedly gives the same result.

YAML

---
- name: Configure web servers
  hosts: webservers
  become: yes
  vars:
    app_port: 3000
    app_env: production

  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present
        update_cache: yes

    - name: Copy configuration
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx

    - name: Start Nginx service
      service:
        name: nginx
        state: started
        enabled: yes

  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted

Ad-Hoc Commands

ansible all -m pingPing all hosts

ansible all -m command -a 'uptime'Run uptime on all hosts

ansible webservers -m apt -a 'name=nginx state=latest' -bInstall Nginx with sudo

ansible db -m copy -a 'src=/tmp/config dest=/etc/config'Copy file to db hosts

ansible all -m service -a 'name=docker state=started' -bStart Docker everywhere

ansible all -m shell -a 'df -h'Check disk space on all hosts

ansible-playbook playbook.yml -i inventory.iniRun playbook against inventory

ansible-playbook play.yml --checkDry run (check mode)

ansible-galaxy role init myroleScaffold a new Ansible role

ansible all -m setupGather system facts from all hosts

Common Modules

apt / yum / dnfPackage management

copy / templateFile management with Jinja2 templates

service / systemdService lifecycle management

command / shellExecute arbitrary commands

user / groupUser and group management

fileSet permissions, ownership, create directories

docker_containerManage Docker containers

uriHTTP API requests

Roles & Handlers

Roles organize automation into reusable components with a standard directory layout.

roles/ nginx/ tasks/main.yml handlers/main.yml templates/nginx.conf.j2 vars/main.yml defaults/main.yml

Handlers run on change notification. Only execute when notified by a task, typically used for service restarts. They run once at the end of the playbook, even if notified multiple times.

Interview Questions

Q1: What is the difference between Ansible and Terraform?

Ansible is a configuration management tool — it installs software, manages configs, and ensures desired state on existing servers. Terraform is an infrastructure provisioning tool — it creates, modifies, and destroys cloud resources (VMs, networks, load balancers). They complement each other: Terraform provisions, Ansible configures.

Q2: What are Ansible roles and how do they differ from playbooks?

Roles are reusable, self-contained units of automation with a predefined directory structure (tasks, handlers, templates, vars, defaults). Playbooks orchestrate multiple roles and define the execution order. Roles promote modularity and sharing via Ansible Galaxy. A playbook can include roles, include tasks, or run inline tasks.

Q3: How does Ansible handle idempotency?

Ansible modules are designed to be idempotent — running a playbook multiple times produces the same result. Modules check the current state before making changes. For example, `apt: name=nginx state=present` only installs if Nginx is not already installed. The `--check` flag performs a dry run to preview changes.

Q4: Explain Ansible's push-based architecture vs pull-based alternatives.

Ansible uses a push model — the control node connects to managed nodes via SSH and pushes configuration. No agent is required on managed nodes. Alternatives like Chef and Puppet use a pull model where agents periodically check a central server. Ansible's push model is simpler for small-to-medium deployments but may not scale as well for thousands of nodes.