Local automation execution using Ansible

The easiest way to leverage Ansible is to instruct it to manage a local system. This means there is no need for SSH connections or port openings or SSH key sharing to be done. This implementation simply involves one user, a set of playbooks (or one), and a local system. Local automation execution is the scenario in which Ansible is leveraged to execute a playbook (a series of automation tasks) against a local machine. This specific architecture type means that Ansible does not need an available network connection or internet connection for it to perform its work.

This architecture type is diagrammed next:

As we can see from the diagram, Ansible can be used for local provisioning. This architecture may seem a bit unscalable, but with a bit of creativity, there is a significant amount of power behind this specific architecture. Let's take a look at some of the various ways in which this specific architecture can be applied:

• To locally provision a development environment and configure it to be a single click setup: ideally with this approach, Ansible playbooks will be written and stored in the local development source control system and then leveraged by new developers to setup and configure their development environments. This will save a significant amount of time on-boarding and getting an employee started.
• To enforce local infrastructure-provisioning rules and revert changes made to the system that were done out of band: this solution would be ideal for enforcing infrastructure that gets tampered with or altered accidentally.
• To execute a set of timed automations that could be leveraged to perform automated routines.

As we can see from the architecture, Ansible's local execution gives us the ability to execute a playbook against a localized system without any fuss or complexity. Let's take a quick look at how to run an Ansible playbook against a local system using the command line. To begin though, let's learn how to run an ad hoc command against a local system. The example is provided as follows:

Example: Ad hoc Linux echo command against a local system
#> ansible all -i "localhost," -c local -m shell -a 'echo hello DevOps World'

The command simply tells Ansible to target all systems in the ad hoc inventory implementation (which in our simple use case is only localhost), then execute the command echo "hello DevOps world" against this system. Simple, right? Now let's take a look at how this same implementation might look if it were in Ansible playbook form. An example of this in playbook form is provided as follows:

# File name: hellodevopsworld.yml
---
- hosts: all
 tasks:
 - shell: echo "hello DevOps world"

This example represents a very simple Ansible playbook. Ansible playbooks are written in Yet Another Markup Language (YAML). They are intended to be easy to read, easy to write, highly structured, and without complexity. The idea of a playbook in the Ansible world comes from the playbook one might receive when attending a broadway show. Playbooks describe in brief the upcoming scenes and actors. As such, Ansible playbooks also contain a list of upcoming events (defined as tasks, and the details of those events). In our simple example, we are telling Ansible to instruct the Linux shell (on the target system(s)) to display a simple introductory message: hello DevOps world.

At this point, you may be wondering, how does one run such a playbook? I'm glad you asked. Playbooks can be run from the command line by specifying the playbook name. An example of this is provided here:

# Running a Playbook from the command line:
#> ansible-playbook -i 'localhost,' -c local hellodevopsworld.yml

Next let's take a look at remote automation execution. This methodology is significantly different from local execution as it allows for much larger scalability support.