Getting started with ANSIBLE (PART - 1)

“Manually configuring multiple servers for a microservice web application using shell scripts is inefficient and error-prone due to challenges like lack of idempotency, poor scalability, and inconsistent setups. Configuration management tools, such as Ansible, automate this process by using remote access protocols (e.g., SSH for Ansible’s) to apply consistent, idempotent configurations across servers. These tools define the desired state in structured formats (e.g., YAML playbooks in Ansible) and execute tasks like installing packages, deploying code, and managing services, ensuring reliability and scalability for distributed microservices.”

What is Configuration Management?

Configuration Management (CM) is the process of systematically handling changes to ensure a system's integrity over time. It involves managing and maintaining the state of infrastructure, software, services, and settings consistently and reliably—especially as systems scale or change.

Key Objectives of Configuration Management:

1. Ensure Consistency: All servers, environments (dev, test, prod), and applications are configured the same way.

2. Automate Repetitive Tasks: Installing packages, setting up users, and managing services without manual effort.

3. Track and Version Changes: Know what changed, when, and why. This supports rollback and auditing.

4. Support Scalability: Quickly configure 1 server or 1000 servers the same way.

5. Improve Reliability and Stability: Reduce human errors, misconfigurations, and downtime.

Tools for Configuration Management

• Ansible (push model)

• Puppet (pull model)

• Chef (pull model)

• SaltStack (pull model)

Push Model vs Pull Model

These are two approaches for how configuration changes (like installing software or setting up services) are delivered and applied to servers.

1. Push Model: In the Push model, the central server or control node initiates the connection and "pushes" configuration changes to the target machines (also called managed nodes). Eg: Ansible

2. Pull Model: In the Pull model, the target machines pull (fetch) configuration changes from a central repository on their own schedule. Eg: Chef

Point to note is that in pull model is an agentless architecture and push model is an agent architecture which means that in pull model for a fixed amount of time the agent monitors the central server for changes where as in push model it is an agentless architecture whenever there are changes in the configuration the central server pushes the changes to the nodes.

What is Ansible?

Ansible lets you automate all the boring and repetitive tasks you'd otherwise do manually on servers — like installing software, creating users, setting permissions, configuring services, deploying code, etc.

Some features of Ansible

1. Agentless — No need to install anything on managed nodes. Uses SSH.

2. YAML-based Playbooks — Simple, readable files that describe tasks in a structured format.

3. Idempotent — Running the same playbook multiple times gives the same result — safe and predictable.

4. Modules — Comes with 100s of built-in modules to perform common tasks (e.g., apt, yum, copy, service, user, etc.)

5. Inventory — List of servers (targets) Ansible should manage, stored in a simple text file or dynamic script.

6. Declarative — You define the desired state (e.g., "nginx should be installed"), not the step-by-step logic.

How Ansible Works (Push Model)

1. You write your playbook in YAML format.

2. You define your target servers in an inventory file.

3. From the control node, you run ansible-playbook.

4. Ansible connects to the remote machines using SSH.

5. It executes the defined tasks using its modules.

6. Tasks are executed in order, and Ansible reports the output.

Example Playbook (Installs NGINX)

- name: Install and start NGINX
  hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

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

Then in your inventory file:

[node1]
192.168.0.100 ansible_user=ec2-user ansible_ssh_private_key_file=~/.ssh/id_rsa

When you run:

ansible-playbook -i inventory nginx-install.yml

This says that →

→ Ansible connects to 192.168.0.100 over SSH
→ Installs NGINX
→ Reports the result

— THE END —