Schedule Meeting


Running Ansible on a dedicated host

by | Nov 24, 2020 | Database Automation

Need Help?  Click Here for Expert Support

Many teams run Ansible plays from their laptops. In practice this just works, but this doesn’t mean that it’s an ideal way of using Ansible. Instead, we suggest to run it inside a dedicated host. In this article you’ll find some good reason for that.

The doors of Sirnione looks like the entrance of a castle
The entrance of Sirnione, a town on the Gard Lake, Italy

Security implications

ansible-playbook usually applies a playbook to remote hosts by running commands via SSH. In order to run it from your laptop, you need SSH access to all those hosts. The reason why we don’t think this is ideal depends wether you use a VPN or not.

If you use a VPN, you probably should not blindly trust all your VPN users, for several reasons:

  • Social engineering is the most effective way to attack organisation systems. It consists in convincing a person to give the attacker a regular access to sensible resources. Expert social engineers gain access to VPNs as a normal part of their job.
  • Cyberattacks sometimes come from organisation members. They could be paid by a competitor or they may be angry with their boss.
  • Former members of an organisation could still have their accesses. The reason could be the lack of proper processes, a human mistake or an automation bug. But what matters here is that this problem is quite common.
  • Laptops can be stolen, and accesses can be used before proper action is taken to avoid an attack.

If you don’t use a VPN, your bastions are exposed to the world. Hopefully they are properly protected, but this doesn’t mean in any way that an attacker can’t break into them.

In all cases, running Ansible from each laptop implies to give each laptop a dedicated SSH access on all target servers. If Ansible only runs from a dedicated host, it is possible to only have one access. In practice having at least two hosts is better, in case a disaster destroys the first Ansible host and we urgently need to deploy. Still, a small, fixed number of accesses is much manageable.


Auditing is a security matter, and can also be required by applicable law or company policy.

Auditing some components of an infrastructure is fairly common. For example, the queries to databases are often logged. But from a practical perspective, it may be hard to find our why a specific query was run or an API call was made. Logging high level actions can help investigate what happened.

For this reason, it may be a good idea to log ansible-playbook invocations. This can be done by adding some simple audit code to a wrapper script (see next paragraph).

Concurrent runs

What happens if two persons run playbooks against the same target servers at the same time? It greatly depends on which task those playbooks run, and in which order. Hopefully, nothing bad will happen. But target servers could also be left down, in an inconsistent state. You may have to fix the problem manually.

Running Ansible from a dedicated host makes it easy to implement a lock. You will make a script that looks like the following pseudocode:

foreach $target_host_list as $host:
        touch "$host.LOCK"
        foreach $locked:
            rm -f "$locker.LOCK"

-- pass all arguments to ansible-playbook
ansible-playbook $@

foreach $target_host_list as $host:
    rm -f "$host.LOCK"

Less environments to manage

If you run Ansible from one host, or from a small number of hosts, you will have just a few environments to manage. The most competent person will take care of upgrading Ansible when needed, or the system it runs on. Leaving this to each member of the team means to increase the chances that problems arise, making them unable to deploy.

Also people could forget to pull from the playbooks repository. Or they could remember it, but still choose not to do so for many reasons: laziness, avoiding a specific problem… but this is hardly a good idea, and you want to avoid it. If you run Ansible from a single host, you can somehow automatically trigger a git pull every time a commit is made on the master branch. Or you can add git pull to the above script.


We discussed some reasons why Ansible should run from a dedicated host, rather than all devops laptops.

Federico Razzoli

Did you like this article?

Photo credit

All content in this blog is distributed under the CreativeCommons Attribution-ShareAlike 4.0 International license. You can use it for your needs and even modify it, but please refer to Vettabase and the author of the original post. Read more about the terms and conditions:

About Federico Razzoli
Federico Razzoli is a database professional, with a preference for open source databases, who has been working with DBMSs since year 2000. In the past 20+ years, he served in a number of companies as a DBA, Database Engineer, Database Consultant and Software Developer. In 2016, Federico summarized his extensive experience with MariaDB in the “Mastering MariaDB” book published by Packt. Being an experienced database events speaker, Federico speaks at professional conferences and meetups and conducts database trainings. He is also a supporter and advocate of open source software. As the Director of Vettabase, Federico does business worldwide but prefers to do it from Scotland where he lives.

Recent Posts

How to fix git mistakes

How to fix git mistakes

Code or configuration versioning comes with a potential problem: fixing mistakes can be tricky. Here are some solutions for the most common problems.


Need Help?  Click Here for Expert Support


Submit a Comment

Your email address will not be published. Required fields are marked *