torero

3 steps to turn your ansible playbooks into services with >_torero

Wyatt Sullivan

Technical Marketing Engineer ‐ Itential

3 steps to turn your ansible playbooks into services with >_torero
Share this:
Posted on July 10, 2024

Last month, we built our first python service with torero. This month we’ll build our first ansible service. First though, let’s do a bit of backstory on why torero.

torero is a simple to use, single binary tool to create, manage, deploy, maintain, and serve automation scripts as services — whatever scripts you choose.

Using torero helps the network or DevOps engineer move scripting from a single-user experience to a team-usable framework. You can do this with python, ansible, opentofu or whatever combination you choose so that anyone on the team can assist in the automation bullfight.

This, in turn, lets the engineer focus on writing scripts and quickly publishing automation services instead of managing and maintaining servers, environments, and creating tooling for others to use the automations. It essentially eliminates all the bull**** that surrounds sharing your automations.

It looks a bit like this:

At its base, torero:

>_pulls code from a git repository
>_prepares a virtual environment for the code
>_packages that as a service to be run by users
>_serves the code as a service

This way, you can spend more time writing code and less time managing and training other teams on how to use your scripts.

>_ how to execute an ansible playbook

step 1: link the repository

Let’s do an ansible “hello, world”. Nothing special with ansible, but you’ll see torero in action.

We’ll pull the hello, world from github. For this example, we just do a quick localhost ping and a debug message for hello world.

- name: Hello World 
  hosts: 127.0.0.1 
  tasks: 
   - name: Ping my hosts 
     ansible.builtin.ping: 
 
   - name: Print message 
     ansible.builtin.debug: 
      msg: Hello world 

torero requires a git repository to obtain the script to be used in a service. The git repo that we’ll use will be https://github.com/torerodev/example-scripts, and specifically we are looking at the hello-ansible.yml file.

First let’s link this repository in torero. Since this is a public repo, we don’t need to setup any authentication or setup keys.

torero create repository hello-scripts --url git@github.com:torerodev/example-scripts.git 
Successfully created the repository 

Name:             hello-scripts 
Description:      
Url:              git@github.com:torerodev/example-scripts.git 
Reference:        
Tags:
Private Key Name:

(Optional) Verify the repo

torero get repositories 
NAME            DESCRIPTION   URL                                             REFERENCE   TAGS    PRIVATE KEY NAME 
hello-scripts                 git@github.com:torerodev/example-scripts.git 
 

For more information on repositories, see the repository command line documents.

step 2: define service from an ansible playbook 

Next, we create the service and point it to the playbook file in the repo. In our example, the file is in the root folder of the repo, so no working directory is needed, just the pointer to the playbook that we want to run and the repo that we’re running it from.

torero create ansible-playbook hello-ansible --repository hello-scripts --playbook hello-ansible.yml 
Successfully created the Ansible playbook(s) 
Name:        hello-ansible 
Repo Name:   hello-scripts 
Working Dir: 
Playbook(s): hello-ansible.yml 
Decorator: 
Description: 
Tags: 
Runtime Arguments: 

step 3: run the service

torero now has everything it needs to run the ansible service. We just need to call it. Here we’re calling it locally on the box, but torero can also be run as a server and the service can be run remotely.

torero run ansible-playbook hello-ansible 
Start Time:   2024-06-27T15:38:24Z 
End Time:     2024-06-27T15:39:21Z 
Elapsed Time: 56.763206s 
Return Code:  0 
Stdout: 
 
PLAY [Hello World] ************************************************************* 
 
TASK [Gathering Facts] ********************************************************* 
ok: [127.0.0.1] 
 
TASK [Ping my hosts] *********************************************************** 
ok: [127.0.0.1] 
 
TASK [Print message] *********************************************************** 
ok: [127.0.0.1] => { 
    "msg": "Hello world" 
} 
 
PLAY RECAP ********************************************************************* 
127.0.0.1                  : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 
 
 
Stderr: 
[WARNING]: No inventory was parsed, only implicit localhost is available 
[WARNING]: provided hosts list is empty, only localhost is available. Note that 
the implicit localhost does not match 'all' 
 

NOTE: As you can see, ansible took almost a minute to complete it’s first run. This was due to downloading all the files and requirements. Subsequent runs took less than 4s on the same box.

torero run ansible-playbook hello-ansible 
Start Time:   2024-06-27T15:45:24Z 
End Time:     2024-06-27T15:45:28Z 
Elapsed Time: 3.726063s 
Return Code:  0  

And that’s it! Ansible playbooks can now be run locally, remotely, and uniformly across environments without the all the bull****!

Prefer to see a visual? You can see how to turn your ansible playbooks into services with torero step-by-step in this demo video.

Wyatt Sullivan

Technical Marketing Engineer ‐ Itential

Wyatt Sullivan, CCIE 18027, has been pushing packets for nearly 25 years. Yes, he’s old. He has accidentally taken down an entire datacenter, bricked network devices, created a loop in a network that caused a 120 minute brownout well outside of the local domain, cleared an entire VTP domain by adding a new device, and once requested a raise. Due to sheer laziness, his first automations were designed in 2000s with excel spreadsheets and bash scripts. By the time he was a Chief Network Architect, he was building scalable web portals for the ops teams to locate devices on the network because he was sick of finding those devices for them. Once he realized he was no longer valuable to real companies, he moved into the vendor space where he has been shilling, automating, and helping network engineers blame other departments for the past decade.

More from Wyatt Sullivan