Ansible Guide
What is Ansible?
Ansible is an open-source automation tool that simplifies configuration management, application deployment, and task automation. It uses a simple language called YAML to write playbooks, which are scripts that define tasks. Ansible is known for being agentless, meaning it does not require any software to be installed on managed nodes.
Use Cases of Ansible
Ansible has a broad range of applications, making it a key tool in DevOps, IT automation, and software deployment. Below are some primary use cases, including specific real-time applications and practical examples for each scenario.
| Use Case | Description | Real-Time Applications |
|---|---|---|
| Configuration Management | Ansible helps maintain a desired state of system configurations across multiple servers, making it easy to keep environments consistent and compliant. |
|
| Application Deployment | Ansible simplifies the deployment process, allowing for consistent and rapid delivery of applications to multiple environments or servers with minimal manual intervention. |
|
| Orchestration | Ansible coordinates complex workflows across different services and systems, ensuring tasks are executed in a specific sequence when dependencies are involved. |
|
| Provisioning Infrastructure | Ansible can create and configure infrastructure in cloud environments or on-premise data centers, enabling infrastructure-as-code (IaC) and repeatable setups. |
|
| Security and Compliance | Ensure that all servers meet security standards and compliance requirements, making it easy to apply patches and manage permissions consistently. |
|
| Monitoring and Incident Response | Set up monitoring tools across servers and automate responses to incidents such as failed services or low resource availability. |
|
Ansible is widely adopted by various roles within an organization due to its flexibility, simplicity, and agentless architecture. The primary users of Ansible include:
- System Administrators: Use Ansible to manage configurations, apply updates, and maintain server consistency across various environments.
- DevOps Engineers: Leverage Ansible for CI/CD automation, infrastructure provisioning, and orchestration to streamline deployment pipelines.
- Cloud Engineers: Utilize Ansible to automate cloud infrastructure setup, including provisioning, network configuration, and resource management.
- Network Engineers: Apply Ansible for automating configuration on network devices, managing firewalls, and ensuring network compliance.
- Security Teams: Rely on Ansible for enforcing security policies, managing access controls, patching vulnerabilities, and ensuring compliance.
- Developers: Often use Ansible for setting up development environments, deploying code to test servers, and managing dependencies.
Ansible is used across various industries, including **technology, finance, healthcare, telecommunications**, and **government** sectors, for its robustness and ability to handle complex automation scenarios effectively.
Setting Up Ansible
To install Ansible, use the commands below based on your operating system:
For Ubuntu/Debian:
sudo apt update
sudo apt install ansible -y
For CentOS/RHEL:
sudo yum install epel-release -y
sudo yum install ansible -y
For macOS:
brew install ansible
After installation, verify the version:
ansible --version
Configuring SSH Access
SSH access allows Ansible to communicate with managed nodes. First, generate an SSH key if you don’t already have one:
ssh-keygen
Then, copy the key to the managed nodes:
ssh-copy-id username@managed_node_ip
Creating and Testing an Inventory
Ansible’s inventory file lists all the servers you want to manage. Define groups and specify variables in this file. Here’s an example:
[web]
192.168.1.10
192.168.1.11
Testing Connection with the Ping Module:
ansible web -m ping -i inventory
You should see output indicating whether Ansible can connect to each managed node successfully.
Questions & Answers
Q: What is the command to install Ansible on Ubuntu?
A: sudo apt update && sudo apt install ansible -y
Q: What is the purpose of the inventory file in Ansible?
A: The inventory file lists all managed nodes, defining which groups they belong to and any associated variables.
Q: How can you test if Ansible can connect to a managed node?
A: Use the ansible command to test connectivity.
Understanding Ansible
Ansible is a powerful automation tool that helps IT teams automate their infrastructure and application deployments. It is simple to use, has no agents or daemons to install on managed nodes, and uses a declarative approach to managing infrastructure.
Ansible uses YAML (Yet Another Markup Language) for its configuration files, which are referred to as “playbooks.” Playbooks contain a series of tasks that describe the steps for configuring a system or deploying an application.
Installing Ansible
Before starting with Ansible, you need to install it on your control node (the machine from which you will manage other systems). Below are the instructions for different operating systems:
For Ubuntu/Debian-based systems:
sudo apt update
sudo apt install ansible -y
For CentOS/RHEL-based systems:
sudo yum install epel-release -y
sudo yum install ansible -y
For macOS using Homebrew:
brew install ansible
Setting Up Ansible on Different Systems
Once Ansible is installed, you will need to configure it to manage your remote systems (managed nodes). By default, Ansible uses SSH to communicate with the managed nodes.
Setting up Passwordless SSH
To enable passwordless SSH access, generate an SSH key on your control node and copy it to the remote system:
ssh-keygen
ssh-copy-id user@remote_host
Configuring Ansible’s Inventory
Ansible requires an inventory file to manage hosts. You can define your servers in this file, either statically or dynamically. Here is an example of a static inventory file:
[web]
192.168.1.10
192.168.1.11
Verifying Ansible Installation
After installing Ansible, verify the installation by running the following command to check the version:
ansible --version
Ensure that Ansible is installed correctly by running a simple ping command to your remote systems:
ansible all -m ping -i inventory
If you get a successful response, Ansible is working properly.
Troubleshooting Installation Issues
If you encounter any issues during the installation, here are a few common problems and solutions:
Problem 1: Permission Denied
If you encounter a “Permission Denied” error while connecting to a remote host, it is usually due to missing SSH keys. Ensure that you’ve copied your SSH key using the ssh-copy-id command and check the permissions.
Problem 2: Unable to Find Ansible Command
If the terminal says that the Ansible command is not found, ensure that Ansible is installed correctly. If you’re using macOS, verify your Homebrew installation with brew list ansible.
Questions & Answers
Q: How do I check if Ansible is installed correctly?
A: Use the command ansible --version to check the installed version of Ansible. You can also verify it with a simple ping to remote hosts using ansible all -m ping.
Q: How do I troubleshoot a permission denied error while using Ansible?
A: Ensure that your SSH keys are properly set up and copied to the remote hosts. You can check permissions on the remote host or re-run ssh-copy-id to copy the key again.
Q: How do I install Ansible on macOS?
A: Install Ansible using Homebrew with the following command: brew install ansible.
Understanding Playbooks
An Ansible playbook is a YAML file that defines a series of tasks to be executed on one or more managed nodes. Playbooks are used to automate tasks such as configuring a system, installing software, or deploying applications. They allow you to define the desired state of your infrastructure in a human-readable format.
Each playbook consists of one or more “plays,” where each play targets a group of hosts and specifies the tasks to be executed. A playbook can contain other elements such as variables, templates, and handlers, making it highly customizable and reusable.
Creating Your First Playbook
Let’s create a simple playbook that installs the NGINX web server on your managed nodes. Create a file named nginx_playbook.yml in your preferred directory:
---
- name: Install NGINX on web servers
hosts: web
become: yes
tasks:
- name: Install NGINX package
apt:
name: nginx
state: present
- name: Start NGINX service
service:
name: nginx
state: started
enabled: yes
This playbook will:
- Install the NGINX package on the nodes in the “web” group.
- Start the NGINX service and enable it to start on boot.
Playbook Structure
A playbook has a very specific structure. Here’s a breakdown of the key elements:
1. Name
The name of the playbook describes what the playbook does (e.g., installing software, configuring services).
2. Hosts
Defines the group of hosts that the tasks will be executed on. The hosts are defined in your inventory file.
3. Tasks
Defines the list of tasks to be executed. Each task uses an Ansible module, such as apt, yum, or service, to perform an action on the managed nodes.
4. Become
The become: yes directive is used to run tasks as a privileged user (e.g., root). This is necessary for installing packages or managing system services.
Running the Playbook
Once the playbook is created, you can run it using the following command:
ansible-playbook -i inventory nginx_playbook.yml
In this command:
-i inventory: Specifies the inventory file that lists your managed nodes.nginx_playbook.yml: The playbook file to execute.
After running the playbook, Ansible will connect to the nodes defined in your inventory file and execute the tasks defined in the playbook.
Verifying the Playbook Execution
After the playbook has run, you should verify that NGINX is installed and running on the target nodes. You can do this by running the following command on your managed node:
sudo systemctl status nginx
If NGINX is installed and running, you should see output indicating that the NGINX service is active.
Questions & Answers
Q: What is the command to run a playbook in Ansible?
A: Use the following command: ansible-playbook -i inventory playbook.yml
Q: How do I specify which group of hosts to target in a playbook?
A: Use the hosts: directive in your playbook to define the group of hosts, such as hosts: web.
Q: How can I run a task with elevated privileges?
A: Use the become: yes directive in your playbook to run tasks as a privileged user (e.g., root).
Q: What happens if the task fails during playbook execution?
A: If a task fails, Ansible will stop executing further tasks by default. You can configure it to continue on failures using the ignore_errors: yes directive.
Understanding Variables in Ansible
In Ansible, variables are used to store values that can be used later in playbooks. These variables can be defined in several places, such as directly in the playbook, in an external file, or as host or group variables in your inventory.
Variables allow you to create flexible and reusable playbooks. For example, you can define a variable for a server’s IP address or a package’s name, making it easy to update the value in one place rather than changing it throughout the playbook.
Defining and Using Variables
Variables can be defined in several places:
- Directly in the Playbook: You can define variables directly within a playbook using the
vars:section. - In Inventory Files: Host and group variables can be defined in your inventory files.
- External Variable Files: Variables can also be defined in external YAML files and included in the playbook.
Example 1: Defining Variables in a Playbook
---
- name: Install a package
hosts: web
vars:
package_name: nginx
tasks:
- name: Install {{ package_name }}
apt:
name: "{{ package_name }}"
state: present
This example defines a variable package_name and uses it in the task to install the specified package.
Using Facts in Ansible
Facts are variables that are automatically gathered by Ansible when it connects to managed nodes. These facts contain information about the system, such as its IP address, operating system, and available memory.
You can access facts in your playbook to make decisions or use them in tasks. For example, you might check the system’s operating system before installing a package.
Example: Using Facts to Check the Operating System
---
- name: Check OS
hosts: web
tasks:
- name: Display the OS
debug:
msg: "The operating system is {{ ansible_os_family }}"
This example uses the fact ansible_os_family to display the operating system family (e.g., Debian, RedHat).
Variable Scope and Precedence
Ansible variables have a scope and precedence, meaning some variables override others depending on where they are defined. For example, variables defined in the playbook will override those defined in the inventory file or external variable files.
Here’s a brief overview of variable precedence from lowest to highest:
- Inventory variables
- Playbook variables
- Extra vars (
-eflag during playbook execution)
It’s important to be aware of variable precedence to avoid unexpected results when defining and using variables in different places.
Questions & Answers
Q: How do I define a variable in a playbook?
A: You can define a variable under the vars: section within a playbook, like this:
vars:
my_variable: value
Q: What are Ansible facts, and how are they gathered?
A: Facts are automatically gathered information about a system, such as IP addresses, OS family, memory, etc. Ansible collects facts at the beginning of a playbook run by default. You can access facts like this: {{ ansible_facts['key'] }}.
Q: What happens if I define the same variable in multiple places?
A: Ansible follows a hierarchy of variable precedence. Variables defined in the playbook will override those in the inventory file, and extra-vars will take the highest precedence.
Q: How do I access a fact in my playbook?
A: Facts are accessed using the {{ ansible_facts['fact_name'] }} syntax, where fact_name is the name of the fact (e.g., ansible_fqdn, ansible_memory_mb). Example: {{ ansible_os_family }}.
Conditionals in Ansible
Conditionals allow tasks to execute only when certain conditions are met. This is useful in scenarios where you only want to run tasks on specific systems, environments, or configurations.
Using the when Statement
The when statement enables you to define conditions for a task. This is typically done using Jinja2 expressions.
---
- name: Install Package Conditionally
hosts: all
become: true
tasks:
- name: Install curl on Debian-based systems
apt:
name: curl
state: present
when: ansible_os_family == "Debian"
when statement is one of the most common ways to conditionally execute tasks in Ansible.Using Multiple Conditions
Combine multiple conditions with and, or, and parentheses for complex scenarios.
---
- name: Conditional Installation for RedHat 8+
hosts: all
become: true
tasks:
- name: Install httpd on RedHat 8+
yum:
name: httpd
state: present
when: ansible_os_family == "RedHat" and ansible_distribution_major_version | int >= 8
This task will only execute on RedHat systems version 8 or above.
Loops in Ansible
Loops allow you to perform a task repeatedly across multiple items, such as installing several packages.
Using Loops with loop
Loops let you iterate over lists in Ansible. Use loop or with_items to specify the list.
---
- name: Install Multiple Packages
hosts: all
become: true
tasks:
- name: Install packages
apt:
name: "{{ item }}"
state: present
loop:
- curl
- git
- htop
when: ansible_os_family == "Debian"
Looping Over Dictionaries
Looping over dictionaries allows you to use complex structures, such as user attributes for creating accounts.
---
- name: Create Users
hosts: all
become: true
tasks:
- name: Create user accounts
user:
name: "{{ item.name }}"
state: present
groups: "{{ item.groups }}"
shell: "{{ item.shell }}"
loop:
- { name: "alice", groups: "admin", shell: "/bin/bash" }
- { name: "bob", groups: "users", shell: "/bin/sh" }
Advanced Loops with loop_control
The loop_control directive customizes loop behavior. For instance, you can name each iteration for better output.
---
- name: Copy Files with Custom Loop Control
hosts: all
become: true
tasks:
- name: Copy files
copy:
src: "{{ item }}"
dest: "/destination/path/{{ item | basename }}"
loop:
- /path/to/file1.conf
- /path/to/file2.conf
loop_control:
label: "{{ item | basename }}"
Questions & Answers
Q: How do you use the when statement in Ansible?
A: The when statement is used to apply conditions to tasks. For example: when: ansible_os_family == "Debian".
Q: How can you run a task only on RedHat systems version 8 or higher?
A: Use when: ansible_os_family == "RedHat" and ansible_distribution_major_version | int >= 8.
Q: How do you iterate over a list of items in Ansible?
A: Use loop with a list. Example:
- name: Install packages
apt:
name: "{{ item }}"
loop:
- curl
- git
Q: What is loop_control used for?
A: loop_control customizes loop iterations, such as setting unique labels with label.
What Are Templates?
Templates in Ansible are files that use Jinja2 syntax, allowing placeholders for variables, loops, and conditionals. They are especially useful for configuration files that need to adapt to different environments.
Creating a Basic Template
To create an NGINX configuration template with variables, create a file named nginx.conf.j2 in the templates directory.
server {{ '{' }}
listen {{ '{{ nginx_port }}' }};
server_name {{ '{{ server_name }}' }};
location / {{ '{' }}
root {{ '{{ web_root }}' }};
index index.html index.htm;
{{ '}' }}
{{ '}' }}
Here, {{ '{{ nginx_port }}' }}, {{ '{{ server_name }}' }}, and {{ '{{ web_root }}' }} are placeholders for variables.
Using the Template in a Playbook
To deploy the template to a managed node, create a playbook named deploy_nginx.yml with the following content:
---
- name: Deploy NGINX Configuration
hosts: web
become: true
vars:
nginx_port: 80
server_name: example.com
web_root: /var/www/html
tasks:
- name: Copy NGINX config
template:
src: templates/nginx.conf.j2
dest: /etc/nginx/sites-available/example.com.conf
owner: root
group: root
mode: '0644'
- name: Enable NGINX site
file:
src: /etc/nginx/sites-available/example.com.conf
dest: /etc/nginx/sites-enabled/example.com.conf
state: link
- name: Restart NGINX
service:
name: nginx
state: restarted
Running the Playbook
To deploy the template, run:
ansible-playbook -i inventory deploy_nginx.yml
Check the deployed file on the server at /etc/nginx/sites-available/example.com.conf to confirm the variables were replaced.
Advanced Jinja2 Features
Jinja2 templates allow for complex logic with loops and conditionals.
server {{ '{' }}
listen {{ '{{ nginx_port }}' }};
server_name {% for name in server_names %}{{ name }} {% endfor %};
location / {{ '{' }}
root {{ '{{ web_root }}' }};
index index.html index.htm;
{{ '}' }}
{{ '}' }}
Using Filters in Templates
Jinja2 filters let you modify data in templates, like converting text to lowercase.
server {{ '{' }}
listen {{ '{{ nginx_port }}' }};
server_name {% for name in server_names %}{{ name | lower }} {% endfor %};
location / {{ '{' }}
root {{ '{{ web_root }}' }};
index index.html index.htm;
{{ '}' }}
{{ '}' }}
Questions & Answers
Q: What are Jinja2 templates in Ansible?
A: Jinja2 templates are text-based files with placeholders for variables, allowing flexible configuration management.
Q: How do I use a template in an Ansible playbook?
A: Use the template module with src for the template file and dest for the destination path.
Q: How can I loop over a list in a Jinja2 template?
A: Use {% for item in list %} and {% endfor %} to iterate through a list of items.
Q: What is a Jinja2 filter, and how can I use it?
A: Filters modify variables within templates, like {{ variable | lower }} to convert text to lowercase.
What Are Roles in Ansible?
Roles are a structured way to organize playbooks, tasks, and configuration files in Ansible. They make it easy to reuse and share configuration across projects.
Creating a Role Structure
Use ansible-galaxy init role_name to create a standard directory structure for a role.
ansible-galaxy init nginx
This will generate a directory structure like:
nginx/
├── defaults
│ └── main.yml
├── files
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── tasks
│ └── main.yml
├── templates
└── vars
└── main.yml
Defining Tasks in the Role
Edit tasks/main.yml to define actions for the role. For example, install and start NGINX:
---
- name: Install NGINX
apt:
name: nginx
state: present
- name: Ensure NGINX is running
service:
name: nginx
state: started
Using Templates and Variables in the Role
Place configuration templates in templates/ and define variables in defaults/main.yml:
nginx_port: 80
server_name: example.com
Adding Handlers to the Role
Create a handler for restarting NGINX in handlers/main.yml:
---
- name: Restart NGINX
service:
name: nginx
state: restarted
Using the Role in a Playbook
Use the defined role in a playbook. Create site.yml:
---
- hosts: web
become: true
roles:
- nginx
What is Ansible Vault?
Vault is Ansible’s tool for encrypting sensitive data. You can use it for variables or whole files.
Creating an Encrypted Vault File
Create a new Vault-encrypted file with:
ansible-vault create secrets.yml
Using Encrypted Files in Playbooks
Include the encrypted file in a playbook using vars_files:
---
- name: Deploy App
vars_files:
- secrets.yml
Accessing Encrypted Variables in Templates
Use variables from Vault-encrypted files in templates:
[database]
password = {{ '{{ db_password }}' }}
Editing Encrypted Vault Files
Edit an encrypted file with:
ansible-vault edit secrets.yml
Questions & Answers
Q: How do you create a role in Ansible?
A: Use ansible-galaxy init role_name to create the directory structure for a role.
Q: How do I include an encrypted file in a playbook?
A: Use vars_files in the playbook to include the encrypted file.
Q: How do you edit an encrypted Vault file?
A: Use ansible-vault edit filename to make changes.
Using Blocks in Playbooks
Blocks group related tasks, enabling conditions, loops, or error-handling mechanisms to apply to all tasks within the block.
---
- name: Install and Start Web Server
hosts: web_servers
tasks:
- block:
- name: Install NGINX
apt:
name: nginx
state: present
- name: Start NGINX service
service:
name: nginx
state: started
rescue:
- name: Report failure
debug:
msg: "Failed to install or start NGINX"
Error Handling with rescue and always
rescue runs only if a task in the block fails, while always executes regardless of success or failure, useful for cleanup actions.
Reusing Tasks with include_tasks and import_tasks
Use include_tasks to add modular task files within playbooks. Example: Create setup_tasks.yml for NGINX setup.
---
- name: Deploy Application with Included Tasks
hosts: web_servers
tasks:
- include_tasks: setup_tasks.yml
Organizing Playbooks with import_playbook
Use import_playbook to include multiple playbooks in a master playbook, useful for environmental configurations.
---
- import_playbook: webserver_setup.yml
- import_playbook: database_setup.yml
Conditional Imports
Apply conditions to imports, allowing selective playbook execution based on variables or facts.
---
- name: Conditional Import
tasks:
- import_playbook: prod_setup.yml
when: env == "production"
Delegating Tasks to Other Hosts
Delegation allows you to run a task on a different host. Useful for updating DNS or load balancers.
---
- name: Register DNS entry
command: nsupdate -k /etc/nsupdate.key dns-update
delegate_to: dns_server
Practice and Next Steps
Experiment with blocks, delegation, and tags. Try creating playbooks with error handling, include modular tasks, and use tags selectively.
Questions & Answers
Q: What is the purpose of blocks in Ansible playbooks?
A: Blocks allow you to group tasks and apply conditions or error-handling to the entire group.
Q: How can you reuse tasks across different playbooks?
A: Use include_tasks or import_tasks to reuse modular task files in playbooks.
Q: How do you conditionally import a playbook based on the environment?
A: Use when with import_playbook, such as when: env == "production".
Q: How can tags be beneficial in playbooks?
A: Tags allow running specific tasks without executing the entire playbook.
What is a Dynamic Inventory?
A dynamic inventory in Ansible generates an up-to-date list of hosts based on your infrastructure. It is particularly useful for environments with dynamic scaling, such as cloud-based servers on AWS or Azure.
Configuring a Dynamic Inventory with AWS
Ansible includes an AWS inventory plugin, allowing you to automatically retrieve EC2 instance details.
pip install boto3: Install AWS SDK for Python (required for AWS inventory).aws configure: Set up AWS credentials via AWS CLI.
Using the AWS EC2 Inventory Plugin
To set up the aws_ec2 inventory plugin, create an inventory file (e.g., aws_ec2.yml):
---
plugin: aws_ec2
regions:
- us-east-1
filters:
instance-state-name: running
keyed_groups:
- key: tags.Name
prefix: "tag_"
Running Playbooks with the Dynamic Inventory
Specify the dynamic inventory with the -i flag:
ansible -i aws_ec2.yml all -m ping
Using Variables with Dynamic Inventories
Dynamic inventories can assign host variables, such as tags and IP addresses, to use in playbooks.
---
- name: Deploy Web Server
hosts: tag_WebServer
tasks:
- name: Install NGINX
yum:
name: nginx
state: present
Creating a Custom Dynamic Inventory Script
If unsupported by a plugin, create a custom script to generate an inventory:
#!/usr/bin/env python3
import json
inventory = {
"web_servers": {
"hosts": ["192.168.1.1", "192.168.1.2"],
"vars": {"ansible_user": "ubuntu"}
}
}
print(json.dumps(inventory))
Combining Static and Dynamic Inventories
Combine static and dynamic inventories by placing multiple files in an inventory directory:
ansible-playbook -i inventory/ deploy_web.yml
Questions & Answers
Q: What is a dynamic inventory in Ansible?
A: A dynamic inventory is a real-time list of hosts generated by a script or plugin, useful in cloud environments.
Q: How do you set up a dynamic inventory for AWS?
A: Use Ansible’s aws_ec2 plugin, set up AWS credentials, and configure the inventory file (e.g., aws_ec2.yml).
Q: Can you combine static and dynamic inventories?
A: Yes, place both static and dynamic inventory files in a directory and specify the directory as the inventory.
Q: How can you create a custom dynamic inventory script?
A: Write a Python script that outputs JSON formatted as an Ansible inventory, making sure it’s executable.
Project Overview: Web Application Deployment Pipeline
Objective: Build an automated deployment pipeline for a web application on AWS using Ansible.
This project includes:
- Dynamic Inventory: Automatically discover AWS EC2 instances based on tags.
- Role-based Configuration: Separate roles for web and database servers.
- Secure Variables: Use Ansible Vault for sensitive information (e.g., database credentials).
- Templates: Dynamic configuration for web and database servers using Jinja2 templates.
- Advanced Playbook Design: Modular and organized playbook structure for reusability.
Step 1: Set Up AWS Dynamic Inventory
Use AWS EC2 inventory plugin to dynamically pull in EC2 instances based on tags.
---
plugin: aws_ec2
regions:
- us-east-1
filters:
instance-state-name: running
keyed_groups:
- key: tags.Role
prefix: "role_"
Tagging Instances
Tag your EC2 instances with Role=web and Role=db for easy grouping.
Verify Inventory Setup:
ansible-inventory -i aws_ec2.yml --graph
Step 2: Create Ansible Roles for Web and Database Servers
Initialize Roles
Create roles for web and database servers:
ansible-galaxy init web
ansible-galaxy init db
Configure Web Role
Add tasks to web/tasks/main.yml to install and configure NGINX:
---
- name: Install NGINX
apt:
name: nginx
state: present
- name: Deploy NGINX Configuration
template:
src: nginx.conf.j2
dest: /etc/nginx/sites-available/app.conf
Configure Database Role
Add tasks to db/tasks/main.yml for MySQL setup and database creation:
---
- name: Install MySQL
apt:
name: mysql-server
state: present
- name: Create Database
mysql_db:
name: app_db
state: present
login_user: root
login_password: "{{ mysql_root_password }}"
Step 3: Secure Sensitive Information with Ansible Vault
Create Vault File
Use Ansible Vault to secure sensitive variables (e.g., mysql_root_password):
ansible-vault create vault.yml
Add sensitive data, such as database credentials, to vault.yml.
mysql_root_password: "SuperSecurePassword123"
api_key: "abc123xyz"
Step 4: Create a Master Playbook
Organize your playbook to manage roles and load vault-protected variables:
---
- name: Configure Web Server
hosts: role_web
become: true
roles:
- web
- name: Configure Database Server
hosts: role_db
become: true
roles:
- db
vars_files:
- vault.yml
Step 5: Configure NGINX and Database with Templates
NGINX Template
Create an nginx.conf.j2 file in web/templates:
server {
listen 80;
server_name {{ server_name }};
location / {
proxy_pass http://localhost:5000;
}
}
Step 6: Run the Playbook
Deploy your application using the dynamic inventory and Ansible Vault:
ansible-playbook -i aws_ec2.yml site.yml --ask-vault-pass
Verify NGINX and MySQL configurations on the target EC2 instances.
Project Summary
This final project integrates various Ansible skills:
- Dynamic Inventory
- Role-based Task Organization
- Secure Variable Storage
- Template Configuration
- Modular Playbook Structure
With these components, you now have a complete pipeline to deploy web applications on AWS.
Best Practices for Ansible
Follow these best practices to maintain a reliable, scalable, and efficient Ansible setup:
1. Structure Your Playbooks and Roles
Organize playbooks into roles for scalability and reusability. Use ansible-galaxy init to create a standard role structure and place each role-specific task, handler, template, and variable in its respective directory.
2. Use Variables and Vault Wisely
Define variables in defaults or vars for each role and keep them organized. Store sensitive information securely with Ansible Vault.
3. Leverage Dynamic Inventory for Cloud Environments
Dynamic inventory plugins (e.g., aws_ec2 for AWS) allow Ansible to pull up-to-date host lists directly from cloud providers, ensuring your inventory reflects real-time infrastructure changes.
4. Use Handlers and Notifications Appropriately
Use handlers to perform tasks like service restarts when configuration changes. Handlers are only run when notified, reducing unnecessary service interruptions.
5. Test Playbooks in a Safe Environment First
Before deploying playbooks in production, test in a staging or testing environment to avoid unexpected issues.
6. Use Tags for Flexibility
Apply tags to tasks and roles for selective execution, which is helpful when only specific tasks need to be run.
7. Document Your Playbooks and Roles
Add comments to explain complex tasks and use clear naming conventions to enhance readability and maintainability for team collaboration.
Expanded Q&A
Q: How can I ensure my playbooks are idempotent?
A: Ansible playbooks should be written in a way that running them multiple times does not cause unintended side effects. Use Ansible modules that are idempotent (e.g., apt, yum, service), as they check the current state before making changes.
Q: How do I handle different environments (development, staging, production) in Ansible?
A: Use inventory files for each environment (e.g., development, staging, production) and configure environment-specific variables in separate files. You can specify the inventory file when running a playbook with -i.
Q: What’s the best way to manage Ansible Vault passwords?
A: Use environment variables to pass Vault passwords securely or use the --vault-password-file option with a script that provides the password. Avoid hardcoding Vault passwords in playbooks or scripts.
Q: How can I speed up Ansible playbook execution?
A: Use strategies such as async for parallel task execution, limit execution to specific hosts or tags, and use Ansible’s smart transport (instead of ssh) for faster communication. Setting up persistent SSH connections can also improve speed.
Q: When should I use include_tasks vs. import_tasks?
A: Use include_tasks for dynamically loaded tasks at runtime and import_tasks for tasks that should be loaded at parse time. This distinction is important for conditionals that need to evaluate dynamically.
Troubleshooting Common Issues in Ansible
Issue: SSH connection issues with “Permission denied” or “Host key verification failed”
Solution: Ensure the correct SSH keys are being used. Check permissions and verify the known_hosts file if “Host key verification” fails. Use the -vvv option to enable verbose logging for debugging.
Issue: “Variable is undefined” error during playbook execution
Solution: Verify that the variable is defined in the correct scope (e.g., playbook, role, or inventory). Check for typos, and if using Vault, ensure that the encrypted file is included with vars_files.
Issue: “Failed to connect to the host via ssh: Shared connection to host closed” error
Solution: This can occur due to network issues or stale SSH connections. Use ControlPersist in your SSH configuration or try disabling SSH pipelining by setting pipelining = False in your ansible.cfg file.
Issue: “No hosts matched” error when running a playbook
Solution: This usually means that the inventory file does not contain any hosts matching the specified group. Verify the group names in your inventory file, and if using a dynamic inventory, confirm the plugin and filters are correctly set.
Issue: “Module not found” error for custom or third-party modules
Solution: Ensure that custom modules are located in the correct directory (library/ within your project) and check module permissions. For third-party modules, ensure they are installed and available in your Ansible environment.
Issue: “ansible-playbook command not found”
Solution: This occurs if Ansible is not installed or not in the system’s PATH. Verify the installation with ansible --version and ensure the PATH includes the directory where Ansible is installed.
Issue: Playbook runs slowly, especially with cloud instances
Solution: Reduce playbook execution time by enabling SSH multiplexing in the SSH configuration and limiting task execution to specific hosts or tags.
Ansible Command Reference
| Command | Description | Explanation |
|---|---|---|
ansible all -m ping |
Tests connection to all hosts by sending a ping. | Sends a basic ping module to check connectivity to hosts defined in the inventory file, confirming if they’re reachable. |
ansible-playbook playbook.yml |
Runs a playbook file (YAML) to perform tasks on hosts. | Executes a sequence of tasks defined in a playbook YAML file, allowing complex automation tasks across multiple hosts. |
ansible-inventory --list |
Displays a list of all hosts in the inventory file. | Shows detailed inventory, including all hosts and groups, as defined in the inventory file for the current Ansible environment. |
ansible-doc -l |
Lists all available Ansible modules with brief descriptions. | Provides a list of Ansible modules available to execute, along with a short description for each module’s purpose. |
ansible-doc -s module_name |
Shows detailed information about a specific Ansible module. | Displays syntax and options for a specified Ansible module, helping users understand how to utilize the module properly. |
ansible-vault create filename.yml |
Creates a new file encrypted with Ansible Vault for sensitive data. | Generates a new encrypted file to securely store sensitive data, like passwords or keys, which only Ansible can read with a password. |
ansible-vault edit filename.yml |
Opens an encrypted file for editing with Ansible Vault. | Allows editing of an encrypted Vault file, maintaining security for sensitive content during modification. |
ansible-vault decrypt filename.yml |
Decrypts an encrypted Ansible Vault file. | Decrypts an Ansible Vault file, turning it back into plain text for easier readability or processing. |
ansible-galaxy install role_name |
Installs a role from Ansible Galaxy (the community repository). | Downloads and installs community roles from Ansible Galaxy to extend functionality in projects with pre-built modules. |
ansible-playbook --check playbook.yml |
Runs a playbook in dry-run mode to see the changes without making any. | Executes a playbook in “check” mode to simulate changes without applying them, useful for testing effects before actual deployment. |
ansible all -m shell -a "command" |
Executes a shell command on all hosts in the inventory. | Runs a shell command (e.g., ls, uptime) on all hosts, allowing quick administration tasks without a playbook. |
ansible-playbook -l hostname playbook.yml |
Limits playbook execution to a specific host or group in the inventory. | Restricts execution of a playbook to a particular host or group, useful for testing changes on a single machine before wider deployment. |
ansible all -m apt -a "name=package_name state=latest" |
Installs or updates a package on all hosts using the apt module. |
Uses the apt module to install or update a package (e.g., nginx) on all hosts in the inventory to the latest version. |
ansible-playbook --syntax-check playbook.yml |
Checks for syntax errors in the playbook without executing it. | Performs a syntax-only validation, helping identify issues in YAML formatting or playbook structure before actual execution. |
Configuration Management Tool Comparison
| Feature / Tool | Ansible | Chef | Puppet | SaltStack |
|---|---|---|---|---|
| Language | YAML (declarative); uses modules written in Python. | Ruby (declarative and imperative) | Puppet DSL (Domain-Specific Language), primarily declarative | Python (declarative); highly flexible |
| Architecture | Agentless; uses SSH or WinRM to communicate with nodes. | Agent-based; requires a Chef client on nodes. | Agent-based; requires Puppet agents installed on nodes. | Flexible; can be agent-based or agentless, using SSH. |
| Ease of Use | Simple and beginner-friendly with YAML syntax. | Steeper learning curve due to Ruby syntax and ecosystem complexity. | Moderate learning curve; Puppet DSL requires some time to learn. | Easy to set up, especially with YAML; Python modules offer more flexibility. |
| Tool | Pros | Cons |
|---|---|---|
| Ansible | – Agentless, easy to set up. – Simple YAML syntax, beginner-friendly. – Extensive community modules. – Ansible Tower/AWX for advanced management. |
– Slower with large configurations; requires parallel setup for improved speed. – Limited error handling and event-driven capabilities. |
| Chef | – Good for complex, large-scale deployments. – Chef Automate offers strong workflow automation. – Mature tool with many integrations. |
– Steeper learning curve due to Ruby. – Requires agents on all nodes. – Expensive for enterprise features. |
| Puppet | – Strong for consistent state management. – Ideal for large enterprises with complex environments. – Role-based access and security features. |
– Requires agents on nodes, leading to overhead. – Puppet DSL can be difficult to learn initially. – High resource usage. |
| SaltStack | – High performance and scalability for large environments. – Event-driven capabilities for real-time response. – Flexible (agent and agentless options). |
– May be more complex to set up initially. – Smaller community compared to Ansible and Puppet. – Paid version needed for enterprise features and GUI. |
Ansible: Great for teams looking for an easy-to-use, agentless tool with a minimal learning curve. Best suited for small to medium environments or teams that need rapid configuration with minimal complexity.
Chef: Preferred for organizations needing strong workflow automation and high customization. Suitable for larger, complex infrastructures that benefit from Chef Automate’s additional functionality.
Puppet: Best for large enterprises where scalability, security, and consistent state enforcement are critical. It’s a top choice for companies needing strong infrastructure as code (IaC) practices with extensive reporting.
SaltStack: Ideal for teams needing high scalability and event-driven orchestration. It’s a solid option for environments requiring real-time responses and management of thousands of nodes, especially when using Python for extensions.
YAML Guide
From Beginner to Advanced
| Concept | Explanation | Example |
|---|---|---|
| Key-Value Pair | Basic unit of YAML, like variables in programming. | name: John Doe |
| Nested Key-Value Pair | Indentation creates nested structures, useful for grouping data. | address: |
| Lists | Hyphens create lists, each item on a new line. | fruits: |
| Boolean | Booleans are true or false without quotes. |
is_active: true |
| Null Value | Represent null values with null or ~. |
middle_name: null |
| Comment | Use # for comments; ignored by YAML parser. |
# This is a comment |
Here are some basic examples of Ansible playbooks to get you started.
---
- name: Install Apache on all hosts
hosts: all
become: yes
tasks:
- name: Install Apache
apt:
name: apache2
state: present
These intermediate examples introduce more advanced Ansible features.
---
- name: Install multiple packages
hosts: all
become: yes
tasks:
- name: Install packages
apt:
name: "{{ item }}"
state: present
loop:
- git
- curl
- vim
---
- name: Manage Apache config
hosts: web_servers
become: yes
tasks:
- name: Update Apache config
copy:
src: /path/to/apache.conf
dest: /etc/apache2/apache.conf
notify: Restart Apache
handlers:
- name: Restart Apache
service:
name: apache2
state: restarted
These advanced examples demonstrate using roles, conditional tasks, and templating.
---
- name: Deploy Web Server
hosts: web_servers
roles:
- apache
- php
Here’s the file structure:
my-playbook/
├── roles/
│ ├── apache/
│ │ ├── tasks/main.yml
│ │ ├── templates/
│ │ └── files/
│ └── php/
│ ├── tasks/main.yml
│ ├── templates/
│ └── files/
---
- name: Install Apache only on Ubuntu
hosts: all
become: yes
tasks:
- name: Install Apache on Ubuntu
apt:
name: apache2
state: present
when: ansible_facts['os_family'] == "Debian"
---
- name: Deploy Nginx with custom config
hosts: web_servers
become: yes
tasks:
- name: Deploy nginx config from template
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
The `nginx.conf.j2` file might look like this:
server {{ server_name }} {
listen 80;
server_name {{ domain }};
root {{ document_root }};
}
External References and Resources
For further reading and to deepen your knowledge of Ansible, consider these reputable resources:
- Ansible Documentation – The official Ansible documentation is an essential resource for all users, covering every module, configuration, and command in depth. Visit Ansible Documentation
- Ansible Galaxy – Ansible Galaxy is a repository where users can share and download roles for automation tasks, making it a valuable resource for reusable configurations. Visit Ansible Galaxy
- Red Hat’s Ansible Blog – This blog offers insights, updates, and tutorials on Ansible from the Red Hat team, helping users stay current with new features and best practices. Visit Red Hat’s Ansible Blog
- A Cloud Guru’s Ansible Course – A structured, beginner-friendly course on Ansible covering key concepts and real-world applications, ideal for new users. Visit A Cloud Guru
- GitHub – Ansible Project – Follow the latest updates and contributions to Ansible on GitHub, where you can explore code, submit issues, and see community contributions. Visit Ansible on GitHub
These resources provide valuable insights, updates, and community-contributed tools to enhance your Ansible experience.