Building network automation solutions

9 module online course

Start now!

Turn Your Ansible Playbook into a Bash Command

In one of the previous blog posts I described the playbook I use to collect SSH keys from network devices. As I use it quite often, it became tedious to write ansible-playbook path-to-playbook every time I wanted to run the collection process.

Ansible playbooks are YAML documents, and YAML documents use # to start comments, so I thought “what if I’d use a YAML comment to add shebang and turn my YAML document into a script

TL&DR: It works. Now for the longer story…

Bash (or any other shell) will try to execute a file that has execute bit set. Use chmod +x playbook to make the playbook executable.

Text files with execute bit set are assumed to be shell scripts unless the first line in the file starts with #! sequence which specifies the absolute path to the script interpreter to use.

You can use which ansible-playbook to find path to ansible-playbook command on your system and add that as the first line of your playbook:


It’s even better to use env command. It’s always (I hope) in /usr/bin directory and uses PATH variable to find the command you want executed. The first line of your Ansible playbook should therefore be:

#!/usr/bin/env ansible-playbook

Cherry on the cake: add a symbolic link to your playbook into one of the directories in your search path. For example:

$ ln –s /vagrant/tools/ssh-keys/get-keys.yml ~/bin/get-ssh-keys

Now you can execute your Ansible playbook like any other Linux command.

Supposedly, you can add environment variables to env command line. I tried to do that to change Ansible STDOUT callback to dense but it didn’t work. A solution to this challenge would be highly appreciated ;)

No idea what I’m talking about? Check out the Ansible for Networking Engineers webinar and online course.


  1. export ANSIBLE_STDOUT_CALLBACK=dense; ansible-playbook [options]
    1. Yeah, sure... have you tried adding that to the #! line? Did it work? If it did, under which shell?
  2. I'd actually preffer making aliases in bashrc. Makes it easier to manage and move around instead of creating loads of symlinks.
    Just add this:
    alias get-ssh-keys="/vagrant/tools/ssh-keys/get-keys.yml"
    inside ~./bashrc
    Reload bash by typing source ~./bashrc

    You could also be creative and make a functions and such
  3. Ivan - aren't we now moving the "CLI"[-like] approach, upstream (the one we are just trying to depart, via the more structured and robust approach of RESTAPI), to the Bash shell, by maintaining more complex scripts?

    Who is / how are we going to fix the portability of Bash vs other shells (e.g. ksh, zsh) when taking scripts and move them across *nix platforms, or with diff path(s) and env, troubleshoot shell exit codes, etc.? Or am I misunderstanding the intent here?
    1. I would recommend anyone believing in the magic of whatever replacing CLI to read this (in particular #2):

      As for portability of shells, sysadmins might be yammering about many things, but the good ones seem to be doing a decent job:

      Obviously people who meet the requirements of RFC 1925 Rule #4 will tell you CLI is dead. Let's revisit this in 10 years ;)

    2. Didn't mean to deviate from the main topic too much, but when looking at some of the CLIs just front-ending RESTAPIs, I wonder if "survival" of CLI isn't just in the eyes of the beholder.
  4. This link explains the reason why the environment variable doesn't work in the shebang:

    Anyway, you can add that variable permanently to your shell


    or run the script with the env variable in the same line:

    $ ANSIBLE_STDOUT_CALLBACK=dense ~/bin/get-ssh-keys
    1. Thanks a million! Your Google-Fu is stronger than mine ;)
Add comment