Building scripts to make your life easier is the first step in network automation. The second step is to serve those scripts to your team.
As you move from the ‘me’ stage of automation to the ‘we’ stage, things get more complicated. In the first stage, you may have your scripts, you may even have some CI/CD pipeline setup to run tests against them. Then, being the amazing NetDevOps engineer that you are, you commit them to a git repo somewhere to let others access and use the scripts.
The problem, however, is that now you must come up with a method to share those scripts to your teams, both internally and externally. Those teams will need to know domain specific knowledge like what server the scripts are on, what inventory to apply the scripts to, what the scripts do, how they work, and heck, they’ll even need to know what local environment is needed to run the scripts. Now, you, the NetDevOps engineer, are an escalation point for managing the scripting environment and must trust external teams with domain knowledge and scripts that may have more rights than the end user should have. A real bullfight is starting to ensue as you’re trying to reign in the chaos of managing that script.
This is where torero enters the arena.
>_what is 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 can participate in your bullfight.
This, in turn, lets the engineer focus on writing scripts and managing automations 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 a python script
Let’s look through a ‘hello, world’ example because it’s MUCH easier to get what torero is doing by seeing it in action. For this example, we’ll focus on python (stay tuned, all you ansible and opentofu automators).
step 1: define the repository
All the code that we write and that we want to be executed with torero must be placed somewhere. Git allows operators to easily share, revision and collaboratively work on different services.
torero requires a git repository to obtain the script to be used in a service. In this example we will use: https://github.com/torerodev/example-scripts
It is important that you use a real git repository for this to work.
To create the repository in torero, we will use torero create repository command.
torero create repository example-scripts-repo --description "Simple repository for quick start" --url https://github.com/torerodev/example-scripts.git --reference main
torero should return results that show that a repository has been created.
Successfully created the repository Name: example-scripts-repo Description: Simple repository for quick start Url: https://github.com/torerodev/example-scripts.git Reference: main Tags: Private Key Name:
(Optional) Verify that the repository has been created
>_torero get repositories NAME DESCRIPTION URL REFERENCE TAGS PRIVATE KEY NAME example-script-repo Simple repository for quick start https://github.com/torerodev/example-scripts.git >_torero describe repository example-scripts-repo Name: example-scripts-repo Description: Simple repository for quick start Url: https://github.com/torerodev/example-scripts.git Reference: main Tags: Private Key Name:
For more information on repositories, see the repository command line documents.
step 2: define service from a python script
Once torero knows where the repository is that stores the automation scripts, a service can be created. First create the service and give the service the name of the repository and filename (if applicable) for the automation. Since we will be creating a python script we should write our script which we will call hello-torero.py. We can reference python service to understand more about the service.
>_torero create python-script hello-torero --repository example-scripts-repo --filename hello-torero.py --description "Quick Start Example" Successfully created the Python script Name: hello-torero Repo Name: example-scripts-repo Decorator: Working Dir: File Name: hello-torero.py Args: Description: Quick start example Tags:
step 3: run service
Now that torero has a registered service to run, any user with proper access rights may now run the service. It is important to pass inputs through the service you will need to use the –set command that takes in a key=value syntax. In our example we are passing the key and value of name and world to the python script.
>_torero run python-script hello-torero
Start Time: 2024-05-23T18:03:18Z End Time: 2024-05-23T18:03:21Z Elapsed Time: 3.109347s Return Code:0 Stdout: [Hello, torero] Stderr:
Note
The first time running a service will take longer than subsequent runs due to downloading and creating the proper environment.
Congrats, you just grabbed the bull by the horns and created your first automation service from a python script. Yes, it’s really that simple.
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.
