Ansible

Ansible is an open-source automation tool that simplifies tasks like configuration management, application deployment, and task automation across a large number of servers or devices. It is designed to be simple, agentless, and efficient, allowing administrators to manage infrastructure through code.

Key Features

1. Agentless: Ansible doesn't require any software (agents) to be installed on the remote systems it manages. It uses SSH (Secure Shell) for communication.
2. Declarative Language: Ansible uses YAML (Yet Another Markup Language) for its playbooks, making the automation easy to read and understand.
3. Idempotency: Tasks executed through Ansible are idempotent, meaning they can be run multiple times without changing the system if it's already in the desired state.
4. Modules: Ansible provides a wide range of pre-built modules for managing different systems (Linux, Windows, networking devices) and services (databases, cloud providers, etc.).
5. Inventory: It maintains a list of systems it manages, which can be static (defined in a file) or dynamic (fetched from external sources like cloud APIs).
6. Playbooks: These are sets of instructions written in YAML that define what tasks Ansible should perform on the managed systems.

Basic Terminology

• Playbook: A YAML file containing instructions (plays) to be executed on managed hosts.
• Task: A single operation within a playbook, such as installing a package or starting a service.
• Role: A way to organize playbooks and tasks by function or responsibility, improving code reusability.
• Inventory: A list of hosts that Ansible manages, which can be grouped for easier management.
• Ad-hoc Commands: One-off commands that can be executed without creating a playbook.

Typical Use Cases

• Configuration Management: Keeping servers in a consistent state (e.g., installing software packages, managing configuration files).
• Application Deployment: Automating the deployment of applications across environments.
• Cloud Provisioning: Managing cloud infrastructure (e.g., provisioning instances on AWS, Azure, or GCP).
• Orchestration: Coordinating multiple tasks across different systems in a specific order (e.g., managing a multi-tier application stack).

Example: Setting up Java, Maven, Git, and MySQL on two EC2 instances using Ansible.

Prerequisites: Ansible, AWS CLI, AWS Access and Secret Keys

First, login to AWS account from AWS CLI with 'aws configure' command

mkdir ansible_workspace

cd ansible_workspace

Step 1: Create an inventory file name hosts

- The inventory file lists the hosts (EC2 instances in this case) which will be managed by ansible.

- You must have your pem file of your AWS account to SSH to remote EC2 instances

[my_aws_ec2_instances]

65.0.215.170 ansible_ssh_user=ubuntu ansible_ssh_private_key_file=./keypair.pem

13.234.131.54 ansible_ssh_user=ubuntu ansible_ssh_private_key_file=./keypair.pem

This file defines a group called my_aws_ec2_instances that includes two servers.

Step 2: Create a playbook setup.yaml

- A playbook is a YAML file containing a series of tasks.

- This playbook do setup (installation) on various EC2 operating systems such as Ubuntu, CentOS and Redhat.

- hosts: my_aws_ec2_instances

  become: yes  # 👉 Gain root privileges for installation

  tasks:

    # Install Java

    - name: Install Java

      apt:

        name: openjdk-11-jdk

        state: present

      when: ansible_distribution == "Ubuntu"

    - name: Install Java on CentOS/RedHat

      yum:

        name: java-11-openjdk

        state: present

      when: ansible_distribution == "CentOS" or ansible_distribution == "RedHat"

    # Install Maven

    - name: Install Maven

      apt:

        name: maven

        state: present

      when: ansible_distribution == "Ubuntu"

    - name: Install Maven on CentOS/RedHat

      yum:

        name: maven

        state: present

      when: ansible_distribution == "CentOS" or ansible_distribution == "RedHat"

    # Install Git

    - name: Install Git

      apt:

        name: git

        state: present

      when: ansible_distribution == "Ubuntu"

    - name: Install Git on CentOS/RedHat

      yum:

        name: git

        state: present

      when: ansible_distribution == "CentOS" or ansible_distribution == "RedHat"

    # Install MySQL

    - name: Install MySQL

      apt:

        name: mysql-server

        state: present

      when: ansible_distribution == "Ubuntu"

    - name: Install MySQL on CentOS/RedHat

      yum:

        name: mysql-server

        state: present

      when: ansible_distribution == "CentOS" or ansible_distribution == "RedHat"

    # Start and enable MySQL service

    - name: Start and enable MySQL service

      service:

        name: mysql

        state: started

        enabled: yes

      when: ansible_distribution == "Ubuntu"

    - name: Start and enable MySQL service on CentOS/RedHat

      service:

        name: mysqld

        state: started

        enabled: yes

      when: ansible_distribution == "CentOS" or ansible_distribution == "RedHat"

- The playbook will install Java, Maven, Git, and MySQL on EC2 instances.

Step 3: Running the playbook 

sudo ansible-playbook -i hosts setup.yml

Step 4: Verify software installed on remote EC2 instances

 

👉 Difference between ansible, puppet and chef

Ansible, Puppet, and Chef are all popular configuration management tools, but they have key differences in terms of architecture, ease of use, language, and more. Here's a comparison across several aspects:

1. Architecture:

• Ansible:
  • Agentless: Ansible does not require any agent to be installed on the managed nodes. It uses SSH (or WinRM for Windows) to connect to systems.
  • Push Model: Ansible works by pushing configurations from the central machine (the control node) to the target nodes.
• Puppet:
  • Agent-Based: Puppet requires an agent to be installed on each managed node, which communicates with a central Puppet Master.
  • Pull Model: Nodes pull their configurations from the Puppet Master at regular intervals.
• Chef:
  • Agent-Based: Chef also requires an agent (the Chef Client) to be installed on each managed node, which communicates with a Chef Server.
  • Pull Model: Similar to Puppet, the Chef Client pulls its configurations from the Chef Server.

2. Ease of Use:

• Ansible:
  • Considered to be the easiest to learn and use due to its simple, human-readable YAML syntax. No need for complex infrastructure, and its agentless nature simplifies setup.
• Puppet:
  • More complex than Ansible. It uses its own declarative language called Puppet DSL, which requires more learning.
• Chef:
  • More complex and has a steeper learning curve due to the use of Ruby for writing configurations, known as recipes. Chef is often favored by developers familiar with Ruby.

3. Configuration Language:

• Ansible:
  • Uses YAML for its playbooks, which are easy to read and write. It’s declarative in nature.
• Puppet:
  • Uses Puppet DSL, a domain-specific language, to define configurations. It’s also declarative, meaning you define the desired state, and Puppet ensures that the system is configured accordingly.
• Chef:
  • Uses Ruby, a full-fledged programming language. This gives Chef more flexibility (imperative approach), but also makes it more complex for beginners.

4. Community and Ecosystem:

• Ansible:
  • Strong and growing community. Ansible Galaxy provides many reusable roles, and it integrates well with DevOps tools like Jenkins and Kubernetes.
• Puppet:
  • Puppet has a mature ecosystem and has been around for a longer time, resulting in a large collection of modules available in Puppet Forge.
• Chef:
  • Chef has a strong community and offers Chef Supermarket for cookbooks (reusable configurations). It also integrates well with the Chef ecosystem like Chef InSpec for security and compliance.

5. Performance:

• Ansible:
  • Ansible's performance can vary depending on the scale. For very large environments, the fact that it’s agentless (and uses SSH) might result in slower performance compared to agent-based systems.
• Puppet:
  • Being agent-based, Puppet is generally faster for large-scale environments since agents pull configurations periodically.
• Chef:
  • Similar to Puppet in performance for large-scale environments due to its agent-based model.

6. Flexibility:

• Ansible:
  • Ansible’s modularity allows for good flexibility, but it’s less programmatic than Chef since it’s mostly declarative.
• Puppet:
  • Puppet is declarative, which means it’s more suited for defining "what" the system should look like, not "how" to get there.
• Chef:
  • Chef is highly flexible and programmable due to its Ruby-based nature. You can define both the "what" and "how" with more precision, which is great for complex, dynamic infrastructures.

7. Use Cases:

• Ansible:
  • Suitable for smaller to medium-sized environments, DevOps automation, and continuous deployment. It’s often chosen for its simplicity.
• Puppet:
  • Suited for larger, more complex environments where scalability and frequent state enforcement are necessary.
• Chef:
  • Also suited for large environments, but more preferred in environments where developers are comfortable with Ruby and want more control over the configuration logic.

8. Learning Curve:

• Ansible: Low (easy to pick up for beginners, especially those with little programming experience).
• Puppet: Medium (requires learning Puppet DSL).
• Chef: High (requires knowledge of Ruby).

Summary Table:

Feature	Ansible	Puppet	Chef
Architecture	Agentless, Push	Agent-based, Pull	Agent-based, Pull
Language	YAML	Puppet DSL	Ruby
Ease of Use	Easy	Medium	Complex
Performance	Slower on large scale	Good for large scale	Good for large scale
Learning Curve	Low	Medium	High
Best For	Small/medium environments	Large environments	Large environments

In general:

• Ansible is a great starting point for those new to configuration management.
• Puppet is more mature and suitable for enterprises with complex needs.
• Chef is a good choice for developers looking for a more programmable, flexible tool.