Ansible Interview Questions and Answers

Ansible is an open source software platform for managing and combining multi node software deployment, as well as ad-hoc changes in the execution and configuration management of a system. Ansible is a new DevOps tools that enter after puppet and chef were already established in the IT market. It has a different approach to solving the IT infrastructure and automation issues.

The original author of Ansible created it, with the intention that to deploy infrastructure, you shouldn’t be required to learn programming. To connect to remote servers that needs to be managed, ansible either uses ssh for *nix based system and winrm(windows remote management) for windows based systems.

Ansible is written in Python and PowerShell

We have many automation tools used in the market namely Chef, Puppet, Salt stack and Maven etc. Each tool has own functionality and features. Ansible can be used in many different ways too. I have mentioned some of them below:

• Configuration Management
• Application deployment
• Security and Compliance
• Provisioning
• Orchestration

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. Ansible categorize into two types of server: controlling machines and nodes.

The controlling machine, where Ansible is installed and Nodes are managed by this controlling machine over SSH. The location of nodes are specified by controlling machine through its inventory. The controlling machine (Ansible) deploys modules to nodes using SSH protocol and these modules are stored temporarily on remote nodes and communicate with the Ansible machine through a JSON connection over the standard output.

Process of Ansible:

• Setting up the Architecture
• SSH keys and their role
• Managing Inventory in simple text files
• Using Ansible

• Ansible is a free and open source software
• Easier and faster to deploy as it doesn’t rely on agents or additional custom security infrastructure.
• Ansible has the flexibility to allow user-made modules that can be written in any programming language such as Ruby, Python. It also allows adding new server-side behaviors extending Ansible’s connection types through Python APIs.
• System requirement is very low in Ansible
• Ansible using YAML Syntax in Configuration files

Playbooks are a completely different way to use ansible than in adhoc task execution mode and are particularly powerful. Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process. Ansible is a configuration management tool that automates the configuration of multiple servers by the use of Ansible playbooks.  The playbook is the core component of any Ansible configuration.

An Ansible playbook contains one or multiple plays, each of which define the work to be done for a configuration on a managed server. Ansible plays are written in YAML. Every play is created by an administrator with environment-specific parameters for the target machines; there are no standard plays.

Yes, Ansible Inc makes a great efficient tool. It is easy to use

Ansible Tower (AWX) is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds. It is considered to be or acts like a hub for all of your automation tasks. The tower is free for usage till 10 nodes.

Ad-hoc commands are a powerful yet simple feature of Ansible. Ad-hoc commands are commands that we use only for quick purposes that we don’t want to save for later, such as checking the status of a server or copying a file to the server tasks we just want to do quickly by typing only few commands.

Syntax:-

ansible <hosts> [-m <module_name>] -a <"arguments"> -u <username> [--become]

Hosts: It can be any entry in the inventory file. For specifying all hosts in inventory, use all or ‘*’. Wild card patterns are also accepted.

Module name: It’s an optional parameter. There are hundreds of modules available in Ansible. By default, it is command. For example, shell, copy, yum, apt, file.

Arguments: We should pass values that are required by the module. It may change according to the module used.

Username: It specifies the user account in which Ansible can execute commands. User account, SSH.

Become: It’s an optional parameter specified when we want to execute operations that need sudo privilege. By default, become is false.

If you put a -c option, then Ansible will do a dry run of the command. It will not actually be applied on the nodes.

Documentation for Ansible is kept in the main project git repository, and complete instructions for contributing can be found in the docs.

If you are just looking to access the existing variables then you can use “env” lookup plugin.

For example: Accessing the value of Home environment variable on management machine:

local_home:”{{lookup(‘env’,’HOME’)}}”

 In Ansible, The copy module has a recursive parameter. However, take a look at the “synchronize” module if you want to do something more efficient for a large number of files. The “synchronize” module wraps resync.

In Ansible, if cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide that you would like to work in a professional cow-free environment, you can either uninstall cowsay, or set the ANSIBLE_NOCOWS environment variable: export ANSIBLE_NOCOWS=1(ref ansible doc)

The mkpasswd utility that is available on most Linux systems is a great option:

mkpasswd --method=sha-512

If this utility is not installed on your system (e.g. you are using OS X) then you can still easily generate these passwords using Python. First, ensure that the Passlib password hashing library is installed:

Pip install passlib

Once the library is ready, SHA512 password values can then be generated as follows:

python -c “from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.using(rounds=5000).hash (getpass.getpass())”

Use the integrated Hashing filters to generate a hashed version of a password. You shouldn’t put plaintext passwords in your playbook or host_vars; instead, use Using Vault in playbooks to encrypt sensitive data. (Ref ansible doc)

You can see the resulting vars you define in inventory running the following command:

ansible -m debug -a “var=hostvars[‘hostname’]” localhost.

If you have not done so already, read all about “Roles” in the playbooks documentation. This helps you make playbook content self-contained and works well with things like git submodules for sharing content with others.

If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended.

It is not advised to manage a group of EC2 machines from your laptop. The best way is to connect to a management node inside Ec2 first and then execute Ansible from there.

This control is very similar to ask_pass

The ask_sudo_pass controls the Ansible Playbook to prompt a sudo password. Usually, the default behavior is no:

ask_sudo_pass= True

One has to make sure and change this setting where the sudo passwords are enabled most of the time.

Using this control, we can determine whether Ansible Playbook should prompt a password for the vault password by default. As usual, the default behavior is no

ask_vault_pass= True

Creating a new directory on a node is done like this:

- name: Create a new directory

  file:

      path: "/tmp/interviewgig"

      state: directory

Ansible automation is consist of the following elements:

• Inventories
• APIs
• Host
• Plays
• Tasks
• Playbooks
• Cloud
• Roles
• Users
• Handlers
• Templates
• Networking

The Ansible is the web-based center which is used for all kinds of automation tasks. There is no requirement to install the daemons to connect with other controlling machines as it is an agentless model. The Ansible tower allows you free usage till ten nodes.

Continuous integration is a coding philosophy and set of practices that drive development teams to implement small changes and check in code to version control repositories frequently. It is a component of the continuous delivery process that enables developers to integrate their updates into the master branch on a regular basis. With CI, automated tests run before and after each change is merged, validating that no bugs have been introduced.

Continuous delivery or CD is the process that development teams use to prepare code for release to production. It relies on automation and usually involves testing, configuration and sometimes database migrations. It extends CI to incorporate automated software release within the SDLC pipeline.

we can use Roles. Roles ensure that they can be distributed or redistributed with the updated content. This contains a document which says how to use the roles.

Ask_pass default value is actually no, if you want it to enable explicitly you can set it as True. This enables the option to ask for a password whereas ask_sudo_pass will be prompted when the sudo password is required to be entered by the user.

Ansible Playbooks are sets of “directives” (or plays) that a user can send to a single target server or multiple servers. They are at the heart of Ansible itself and enable automating infrastructure management. Ansible Playbooks offer excellent repeatability and re-usability in managing and deploying simple or complex applications, often on a significant number of machines.

Ansible is not written in YAML, it is written in python programming and PowerShell. So, YAML is getting converted to it that’s how it works.

If you want to view the contents of a file that was previously encrypted with ansible-vault and you don’t need to change its contents, you can use:

ansible-vault view credentials.yml

 This will prompt you to provide the password you selected when you first encrypted the file with ansible-vault.

To edit the contents of a file that was previously encrypted with Ansible Vault, run:

ansible-vault edit credentials.yml 

ansible    -m service  -a “name= httpd state=stopped” –become

/etc/ansible/hosts file called as inventory. It contains the group of the server name or IP’s.

To set up an SSH connection, follow the steps mentioned below:

• Setting Up SSH Command
• Generating SSH Key
• Copy the SSH Key on the Hosts
• Check the SSH Connection

Action  Example usage

All hosts           all

All hosts           *

Union               dev:staging

Intersection     staging:&database

Exclusion         dev:!queue

Wildcard         *.example.com

Range of numbered servers   web[5:10]

Regular expression     ~web\d+\.example\.(com|org)

First, we need to install epel repo and then install ansible

• Yum install epel-repo
• Yum install ansible

Role default variables allow you to set the default variables for included or dependencies

Dependencies:

• Role: tire
• Role: brake

 by using  import_tasks:

command to run a playbook

1. $ ansible-playbook -i hosts main4.yml

• -i- This is an option to specify an ability to override the default inventory file and the inventory file specified.
• main.yml: This is the playbook file

As Ansible facilitates bundling automation content. This makes it reusable. The Ansible galleries are needed here to share such Ansible roles. In simple words, the Ansible gallery is the tool which is merged with the Ansible. This integration creates the base directory structure.

Yes. If any task that you want to keep secret in the playbook when using -v (verbose) mode, the following playbook attribute will be helpful:

            - name: secret task

  shell: /usr/bin/do_something --value={{ secret_value }}

  no_log: True

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:

1. Uninstall cowsay
2. Setting up value for the environment variable, like below

1          Export ANSIBLE_NOCOWS=1

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 is agentless, relying on SSH for communication, while Puppet & Chef require agent installation.
• Ansible uses YAML for playbooks, making them human-readable, while Puppet and Chef use their own domain-specific languages.
• Ansible is push-based, executing tasks from a central control machine, whereas there are pull-based. Ansibles’ 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.

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.