Ansible Interview Questions for Experienced

Ansible is an open-source automation tool that works by connecting to remote hosts over SSH or WinRM (Windows Remote Management) and using YAML scripts called playbooks to define automation tasks. Here’s a basic overview of how Ansible works:

Agentless Architecture: Ansible follows an agentless architecture, meaning it doesn’t require any agent to be installed on managed nodes. It communicates with remote nodes over SSH, which simplifies the setup and maintenance.

Playbooks: Automation tasks are defined in YAML-based playbooks. Playbooks describe a set of steps or tasks to be executed on remote hosts.

Modules: Ansible uses modules to abstract system operations, such as managing packages, services, or files. Modules are executed on remote hosts to perform specific actions.

Inventory: Host information is defined in an inventory file, specifying which hosts Ansible should manage. Can be static or dynamic, allowing for flexibility in managing hosts.

Tasks and Handlers: Playbook tasks define what needs to be done on the managed nodes. Handlers are tasks that respond to specific triggers within the playbook.

Idempotence: Ansible is idempotent, ensuring that running a playbook multiple times has the same result as running it once.

Automation: Ansible automates repetitive tasks, allowing for consistent and reliable execution of configuration management, application deployment, and infrastructure provisioning.

Infrastructure as Code (IaC): Ansible facilitates IaC practices by defining infrastructure configurations in code, promoting version control and reproducibility.

Agentless and Simplicity: Ansible’s agentless architecture simplifies setup and maintenance, making it easy to deploy and manage.

Integration with Existing Tools: Ansible integrates seamlessly with existing DevOps tools, enabling collaboration and interoperability in a toolchain.

Scalability: Ansible scales well for managing large and complex infrastructures, making it suitable for dynamic and evolving DevOps environments.

Auditability and Compliance: Playbooks and configurations are easily auditable, supporting compliance requirements and providing transparency into infrastructure changes.

Community and Support: Ansible has a vibrant community and extensive documentation, ensuring continuous support, updates, and sharing of best practices within the DevOps community.

Ansible can be installed using the package manager of the operating system. For example, on Ubuntu, you can use sudo apt-get install ansible, and on Red Hat-based systems, you can use sudo yum install ansible.

Ansible playbooks are written in YAML. They consist of plays, tasks, and roles. A basic playbook structure includes specifying the hosts, tasks to be executed, and any required variables. Here’s a simple example:

y- name: My First Playbook
hosts: servers
tasks:
- name: Install Nginx
apt:
name: nginx
state: present

Dynamic inventories in Ansible allow us to dynamically discover and manage hosts. For example, if we are using a cloud provider like AWS, we can use the AWS dynamic inventory script to automatically populate our inventory with instances from AWS. This is beneficial because it eliminates the need to manually maintain static inventory files, ensuring that our Ansible playbooks can scale seamlessly with the infrastructure. It also facilitates the automation of tasks in dynamic environments where hosts may come and go.

Ansible roles are a way to organize playbooks and reuse code. Roles have a predefined structure with directories for tasks, handlers, variables, and templates. To use a role in a playbook, you can include it using the roles directive. Here’s an example:

- name: My Playbook with Role

hosts: servers

roles:

- common

In this example, the playbook installs the “nginx” package on a group of servers defined in the —

- name: Install Nginx on Servers

hosts: your_server_group

become: yes  # To execute tasks with sudo privileges

tasks:

- name: Update package cache

apt:

update_cache: yes

when: ansible_os_family == 'Debian'  # Adjust for other package managers

- name: Install Nginx package

apt:

name: nginx

state: present  # Ensure that the package is installed

when: ansible_os_family == 'Debian‘  # Adjust for other package managers Ansible inventory.

Explanation of the playbook:

name: A description of the playbook.

hosts: Specifies the group of servers on which the playbook should be executed. Replace “your_server_group” with the appropriate group from your Ansible inventory.

become: Enables sudo privileges for executing tasks.

tasks: A list of tasks to be executed.

The first task updates the package cache. Note that the “apt” module is used here, which is specific to Debian-based systems. Adjust this based on the package manager used by your servers (e.g., “yum” for Red Hat-based systems).

The second task installs the “nginx” package. Adjust the package name and state according to your requirements.

To run this playbook, save it in a file, e.g., install_nginx.yml, and execute the following command in the terminal:

ansible-playbook -i your_inventory_file install_nginx.yml

Ansible operates as an agentless system that utilizes SSH for communication, contrasting with Puppet and Chef, which necessitate the installation of agents. Playbooks in Ansible are composed in YAML, ensuring human readability, while Puppet and Chef employ their own domain-specific languages. The execution model of Ansible is push-based, originating from a central control machine, whereas Puppet and Chef adopt a pull-based approach. Ansible’s simplicity and ease of setup often make it preferable for some environments.

Ansible Vault is used to encrypt sensitive data such as passwords, API keys, and other secrets. In a scenario where I need to include a database password in an Ansible playbook, I would use Ansible Vault to encrypt that password. This ensures that the sensitive information is secure and can only be decrypted by authorized users with the appropriate vault password. It adds an extra layer of security to automation tasks, especially when dealing with production environments or sharing playbooks in version control systems.

Below is a basic Ansible role for installing and configuring a web server, specifically using Nginx. This role assumes a Debian-based system, so it uses the “apt” package manager. Modify it accordingly for other package managers.

Create Role Structure:

Use the command ansible-galaxy init web_server_role to generate the role structure.

Define Tasks:

Edit tasks/main.yml to include tasks for installing the web server, e.g., apt for Debian systems or yum for Red Hat.

Configure Files:

Adjust configuration files in templates/ or files/ as needed, such as the default web server configuration.

Handle Variables:

Set variables in defaults/main.yml for customization.

Test:

Create a playbook using the role, applying it to target hosts to verify installation and configuration.

Execute Playbook:

Run the playbook with ansible-playbook -i inventory_file web_server_playbook.yml.

Error handling in Ansible is crucial for robust automation. I would use the ignore_errors directive to continue executing tasks even if one fails, and I would use the failed_when directive to customize the conditions under which a task is considered failed. Additionally, I would make use of Ansible’s logging and debugging features. For example, I would use the debug module to print variable values during playbook execution, and I would enable verbose mode (-vvv) to get detailed information about the playbook run.

Ansible Tower is a web-based UI and management tool for Ansible. It provides a centralized platform for managing automation workflows, scheduling jobs, and tracking job results. I would recommend using Ansible Tower in scenarios where there is a need for role-based access control, job scheduling, and a graphical interface for managing and monitoring Ansible playbooks. It becomes particularly useful in large-scale deployments where coordination, visibility, and security are essential.

In a blue-green deployment, we maintain two identical environments, allowing for seamless switching between them. I would use Ansible to create and configure both the blue and green environments. Playbooks would handle tasks such as deploying application updates, updating the load balancer configurations, and ensuring database schema consistency. Ansible variables and conditionals could be employed to differentiate between the blue and green environments. Additionally, health checks and monitoring should be in place to validate the successful deployment of updates before directing traffic to the updated environment.

Utilizing Ansible, I would implement dynamic inventories to automatically discover and manage servers across different data centers. Through Ansible playbooks, I’d define tasks and roles tailored for different operating systems, ensuring a unified approach to configuration management, updates, and automation across the entire server fleet. This modular and agentless solution facilitates seamless control and coordination, allowing for efficient management of the heterogeneous server environment.

To create a custom Ansible module, you need to write a script in Python following the Ansible module development guidelines. This script should handle argument parsing, execution, and return results in JSON format. Once the module is created, you can use it in your playbooks like any other built-in module.

Ansible is designed to be idempotent by default. However, you can explicitly ensure idempotency by using modules with idempotent behavior, such as the ansible.builtin.file module with state=present to ensure a file exists, or by properly using when clauses.

If Cowsay is installed then executing your playbooks within Ansible is very smooth.

Even if you think that you want to work in a professional cow free environment, then you will have two options:

Uninstall cowsay

Setting up value for the environment variable, like below

• Export ANSIBLE_NOCOWS=1

Ansible Vault is used to encrypt sensitive data. You can create an encrypted file using the ansible-vault create command. To edit an existing encrypted file, you can use ansible-vault edit. The decryption process is handled automatically when executing playbooks.

Callback plugins in Ansible allow you to hook into Ansible events and execute custom code. They can be used for logging, notifications, or custom reporting. To use a callback plugin, configure it in the ansible.cfg file.

Ansible allows you to define task dependencies using the notify keyword. A task with a notify directive will trigger handlers, which are defined separately and can be associated with multiple tasks. Handlers are then notified to run at the end of a play.

Dynamic Inventory Script in Python:

Understand the External Source: Identify the external source from which you want to retrieve hosts dynamically. This could be a cloud provider, a database, a configuration management system, etc.

Choose the Python Libraries: Based on the external source, choose the appropriate Python libraries or modules. For example, you might use the requests library for API calls or a specific SDK for cloud providers.

Define the Dynamic Inventory Script Structure: Structure your script to output JSON in the required format for Ansible’s dynamic inventory. At a minimum, it should include groups and hosts.

Retrieve Host Information: Write code to retrieve host information from the external source. This may involve making API calls, querying a database, or any other method specific to your chosen external source.

Format Output as JSON: Format the retrieved information as a JSON object. Ensure that the JSON includes hostnames, IP addresses, groups, and any other relevant information.

Test the Script: Test your dynamic inventory script by running it and examining the generated JSON output. Make sure it adheres to Ansible’s dynamic inventory format.

Configure Ansible to Use the Dynamic Inventory: Update your Ansible configuration to use the dynamic inventory script. This typically involves specifying the path to your script in the ansible.cfg file or using the -i option when running Ansible commands.

Ansible Playbook Handling Errors:

Understand Error Handling in Ansible: Familiarize yourself with Ansible’s error handling mechanisms, such as ignore_errors, failed_when, and the use of blocks for grouping tasks.

Identify Potential Failure Points: Review your playbook and identify tasks or scenarios where errors might occur. This could be due to network issues, missing dependencies, or other reasons.

Use ignore_errors for Non-Critical Tasks:For tasks that are non-critical or where failure is acceptable, use the ignore_errors attribute. This allows Ansible to continue executing subsequent tasks even if a particular task fails.

Use failed_when for Conditional Failure Handling: For tasks where failure should be conditionally handled, use the failed_when attribute to specify conditions under which a task is considered failed.

Group Tasks in a block: Use Ansible blocks to group related tasks. This allows you to apply error handling to a set of tasks collectively.

Implement Rescue Sections: Within a block, use a rescue section to define tasks that should be executed in case of an error. This provides a way to gracefully handle failures and take corrective actions.

Test the Playbook: Test your playbook by intentionally causing errors at identified failure points. Ensure that the playbook behaves as expected, and errors are handled gracefully according to your defined conditions.

Refine and Iterate: Review the playbook and error-handling strategy. Iterate and refine your approach based on feedback and additional testing. Ensure that the playbook is resilient to unexpected issues.