Three months ago, we debuted torero 1.0 to the network automation community as a key enabling tool to help teams and organizations operationalize automation in a more team-oriented way. Today, I’m excited to announce the next release of torero, release 1.1, is now available at torero.dev.
The initial release focused mainly on delivering the base automation execution functionality. This gave us a foundation to build upon to deliver an automation gateway that can be easily used to transform the way teams automate: from individuals developing and delivering automation scripts, playbooks and plans to a more team oriented model. The response has been fantastic as teams have started to absorb torero into their development and operational stacks.
The new release of torero represents a big step forward in helping teams and organizations leverage torero in their environments. The torero 1.1 release focuses on being a more scalable and distributed architecture.
>_ what’s new in torero 1.1
With today’s release, torero introduces a new distributed deployment architecture that’s purpose-built to allow teams to scale up and scale out their torero deployments. I first talked about this with Ethan Banks when we announced torero at AutoCon 1 here and subsequently with Eric Chou on Packet Pushers’ Network Automation Nerds podcast here.
The new capabilities of torero allow teams to build out a more resilient deployment beyond just a single server. The torero 1.1 release introduces the idea of clusters composed of controller and runner nodes that can be deployed to deliver a truly production-tested architecture.
clusters
A cluster is simply a logical grouping of controllers and runners that all work together to deliver on the features and capabilities provided by torero. In fact, the current release of torero (both local mode and server mode) is essentially a cluster comprised of a single, all-in-one deployment.
controller nodes
Controller nodes effectively are the brains of the operation. Much like the control plane of a network, controllers are designed to have a pulse on everything going on in a torero cluster. Operators can deploy one or more controllers responsible for receiving client requests, assigning jobs to runner nodes, and keeping abreast of all configured and running services for a given cluster.
Controller nodes are designed to be deployed centrally with a primary and one (or more) secondary controller nodes. To facilitate this deployment architecture, the database that’s embedded to torero 1.0 has been externalized using etcd. While using an external database for a single server deployment is optional, using an external database for building out a distributed architecture is required.
And before the flood of questions come flying on and blow up my channels, yes, the embedded database and external database are fully compatible. In fact, they both use the exact same database engine. By using the same engine for local, server mode and now in the distributed architecture, torero can easily share configuration and data between different deployments. Stay tuned to the torero community for more goodness to come from this architectural decision.
runner nodes
The counterpoint to controller nodes in the cluster are runner nodes. Runner nodes are effectively the workhorses of torero. Runner nodes are designed to be horizontally scalable and responsible for handling the execution of services. Given the nature of the torero architecture, runner nodes can be deployed throughout the infrastructure, placing them as close to the assets being automated as possible to reduce latency when communicating with network devices.
>_ start scaling automation with torero 1.1 today
With today’s release torero is now well positioned as a foundation to grow and innovate as a robust (and now) scalable automation gateway. However, we aren’t stopping here. In fact, we are only just getting going. We’re working hard and moving fast to make torero the best, most useful tool it can be for teams to operationalize network automation.
If you haven’t yet had a chance to play with torero, I would encourage you to hop over to torero.dev and download it. It has been and will continue to be completely free to try out and completely free to use in your infrastructure.
Additionally, I invite you to stop back here at the Itential blog from time to time, as we will be posting more details on interesting use cases and different ways to leverage torero in your infrastructure. Make sure to follow torero on LinkedIn, X and YouTube, and engage with the torero community on the NAF Slack space at #tools-torero to get alerted when these new resources go live!
Peter Sprygada
Vice President, Product Management ‐ Itential
Peter Sprygada serves as the Vice President, Product Management at Itential after serving as the Chief Technology Officer at Pureport where he was responsible for their multi-cloud network as a service interconnect platform. Prior to Pureport, Sprygada was a Distinguished Engineer for Red Hat, where he played the role of Chief Architect for the Ansible Automation Platform. Sprygada also held senior technical and leadership positions at Arista and Cisco, as well as several networking startups.
