Ansible is a powerful tool that can be used to automate tasks in your organization. However, if you’re not familiar with it, it can be difficult to execute Ansible playbooks locally. In this article, we’ll cover the basics of Ansible and how to execute them locally. We’ll also cover some tips on how to improve your Ansible experience. What is Ansible? Ansible is a powerful tool that allows you to automate tasks in your organization. It’s a free and open source software that can be used on both Linux and Windows platforms. You can use it for everything from managing servers to automating tasks in your development process. How do I use Ansible? To use Ansible, you first need to install it on your system. You can find the installation instructions here: https://ansible-playbook.org/en/latest/. Once you’ve installed it, you can start using it by running the following command: ansible-playbook -i my_module -v my_version


The first two seem great for their different contexts, and the third is not as necessary but worth considering perhaps. Being able to do this can be very useful for setting up your own machines or workstations (dotfiles anyone?) at least in the event that you don’t want to use traditional scripting.

Also when creating playbooks that involve interacting with developer API’s this is an important component – see the “more information” section at the end, for a link to an example of this.

1 – Local Play Directives

This is the easiest way I found and probably most suited for when writing one or two individual playbooks.

1 – Local Play Directives2 – Repository Config and Hosts File3 – Global Inventory Hosts Group

Simply put, using both 127.0.0.1 for the hosts: directive and setting connection: to local in a playbook ensures any tasks carried out are executed on your local machine.

This is an example playbook that prints “localhost” during execution to show local playback, then updates and upgrades Apt system packages; so it’s intended for Debian and or Ubuntu.

[alert-announce]

playbook.yml

— – name: run the playbook tasks on the localhost hosts: 127. 0. 0. 1 connection: local become: yes tasks: – name: print out the hostname of target command: hostname – name: ensure aptitude is installed command: apt-get -y install aptitude – name: update the apt package index i. e. apt-get update apt: update_cache=yes – name: upgrade system packages i. e. apt-get upgrade apt: upgrade=yes

[/alert-announce]

Run it as usual like any standard playbook – inclusive of -K as it’ll need sudo privileges to complete.

[alert-announce]

$ ansible-playbook -K playbook. yml

[/alert-announce]

2 – Repository Config and Hosts File

This second method works best in the context of a version control repository, which features multiple local playbook files and is intended to be passed around from person to person or host to host. It works by forcing Ansible to use a custom config file and in turn local hosts file.

Here are the step you’d need to carry out in order to set this up in a Git repository, after setting up the repo itself. There’s also no commands for checking in, writing and pushing files to the remote.

In the Git repository, create the custom ansible.cfg file.

[alert-announce]

$ vim ansible. cfg

[/alert-announce]

Add these contents to the file as they’re shown:

[alert-announce]

ansible.cfg

[defaults] hostfile = hosts

[/alert-announce]

Save and exit the new file.

Then create another file, this time the custom hosts one.

[alert-announce]

$ vim hosts

[/alert-announce]

The contents here consist of a group named [local] and a host entry listed as localhost. The host variable for local host ansible_connection=local as expected forces a local connection whenever it is targeted in a playbook.

[alert-announce]

hosts

[local] localhost ansible_connection=local

[/alert-announce]

Again on a Debian/Ubuntu host you could use an adapted version of the earlier playbook as a test example, to ensure everything is working as intended. The difference here is the localhost value for hosts: and no requirement to mention the connection: local directive.

[alert-announce]

playbook.yml

— – name: run the playbook tasks on the localhost hosts: localhost become: yes tasks: – name: print out the hostname of target command: hostname – name: ensure aptitude is installed command: apt-get -y install aptitude – name: update the apt package index i. e. apt-get update apt: update_cache=yes – name: upgrade system packages i. e. apt-get upgrade apt: upgrade=yes

[/alert-announce]

You’ll need to provide your sudo password with this again, to run the playbook.

[alert-announce]

$ ansible-playbook -K playbook. yml

[/alert-announce]

3 – Global Inventory Hosts Group

One further alternative solution (in a non-version control scenario where there’s no need for portability) is to instead add the [local] host group to your global /etc/ansible/hosts file.

These would be the commands:

[alert-announce]

$ sudo vim /etc/ansible/hosts

[/alert-announce]

Append this new host group to the file.

[alert-announce]

/etc/ansible/hosts

[local] localhost ansible_connection=local

[/alert-announce]

Write your opening lines of playbooks with the hosts: all definition. Here’s the example from before, adapted to this:

[alert-announce]

/etc/ansible/hosts

— – name: run the playbook tasks on the localhost hosts: all become: yes tasks: – name: print out the hostname of target command: hostname – name: ensure aptitude is installed command: apt-get -y install aptitude – name: update the apt package index i. e. apt-get update apt: update_cache=yes – name: upgrade system packages i. e. apt-get upgrade apt: upgrade=yes

[/alert-announce]

Then afterwards when you want to run a playbook locally, use the -l switch and provide the local group or localhost as the target host.

[alert-announce]

$ ansible-playbook -K -l localhost playbook. yml

[/alert-announce]

It’s still wise and maybe more convenient to keep local playbook execution isolated to one directory or Git repository, however (using the method in the former step). I would probably not recommend this method over the other two, but whatever works best for your particular needs I guess.

Thanks for reading, and I hope this has helped you out with local playbook execution in some way or another.

Read More On Ansible For Developers

Now that you’ve learned how to run Ansible playbooks locally, what’s next? Here are some additional resources.

Ansible – Installing and Running Ansible – Inventory Concepts (2) Ansible – Ad Hoc Commands and Modules (3) Ansible – Playbook Concepts

Docker For Developers

We have a number of resources for folks looking to learn how to utilize docker for app development, take a look at the free resources:

Docker – Installing and Running (1) Docker – Administration and Container Applications (2) Docker – Daemon Administration and Networking (3) Docker – Data Volumes and Data Containers (4)

More From TricksOfTheTrades

Here are some of the posts in the same category with running ansible playbooks locally people are reading:

Debian 7 Mumble (Murmur) Server Installation Vim Plugins and Pathogen (The Complete Guide) BASH Environment and Shell Variables (Complete Guide) Ubuntu 14. 04 Z Shell (zsh) Installation and Basic Configuration Installing Minecraft Server on Debian 8 Installing and Using UFW (Uncomplicated Firewall) How to Install and Get Started with Vagrant

A list of recently published articles on the main site people are also reading:

Do Posture Correctors Work? Samsung Pay vs Google Pay: Which Is Better? 7 Best Budget Noise Cancelling Bluetooth Earbuds Under $50 10 Best Gacha Games For RPG Action Lovers Roblox Alternatives:10 Free Games Like Roblox 2020 Treblab xFit Review: 2 Months After, One of The Best Earbuds Terraria Alternatives: 10 Games Like Terraria For Classic Action Games Lovers 14 Best Subreddits For Android And Tech Lovers 10 Best Posture Correctors (Cheap Options Under $50)