Using Ansible to modernize telcos’ infrastructure through automation

As telecommunications companies continue to modernize their networks and IT systems, they have to navigate the challenges that come with legacy systems, including legacy virtualized network functions (VNFs) that rely on local filesystem storage, single server implementations on which all the services run, and manually-intensive installations and upgrades. What telcos need are tools like Ansible, a general-purpose, open-source automation engine that automates software provisioning, configuration management, and application deployment.

Earlier this month, at AnsibleFest 2017 in San Francisco, Red Hat added new products and updated existing ones that expand its automation portfolio. It added the ability to automate network management and updated Ansible Tower, which enables the automation of IT functions at enterprise scale, so it can now be used to automate the management of Arista, Cisco and Juniper networking software as well as instances of Open vSwitch and VyOS. Red Hat acquired the company behind Ansible in 2015, and today the technology is one of the world’s most popular open source IT automation technologies, with nearly 3,000 unique contributors, more than 32,000 commits to the upstream Ansible open source project, and a user base that spans industries and the globe. Read the press release on Red Hat’s Ansible announcement. And for all things Ansible, check out our Red Hat Ansible blog, The Inside Playbook.

Ansible’s power as a configuration management tool can go a long way in helping telcos automate the deployment of legacy virtual network functions (VNFs) as they shift more of their networks and infrastructure to network functions virtualization (NFV) and the cloud. At the recent OPNFV Summit in Beijing, China, Red Hat’s Yolanda Robla, principal software engineer, and Ricardo Noriega de Soto, telecommunications engineer, talked about this very topic in a presentation, “Automating the Deployment of Legacy VNFs with Ansible.”

Robla started the presentation with a close look at the challenging characteristics of legacy VNFs – their designed for single servers, have local file system storage, all the services run on one server, and upgrades and installations are not well defined and manually intensive. In a legacy VNF environment, it’s very difficult to automate the apps, the VNFs don’t scale well, monitoring is manual, there’s no high-availability and if a server goes down it has to be replaced manually and it’s difficult to test and upgrade.

Adding automated configuration management will help ease those challenges. According to Robla, configuration management enables the process of systematically handling changes to a system in a way that it maintains integration over time, and when you add in automation, you have access to mechanisms to make the server reach a desirable state, previously defined by provisioning scripts using the specific language and features of a tool like Ansible. That means you can:

• More quickly provision new servers.
• More quickly recover from events.
• Apply version control of your server environment by tracking all changes.
• Easily replicate the server environment.
• Eliminate snowflake servers. “With automation, you exactly know what a server contains,” Robla said.

“There are key technologies that we think will help you succeed in NFV deployment and Ansible can be part of it and a good enabler,” De Soto told OPNFV Summit attendees. Traditionally, whenever telcos want to deploy a new service, it can be a long process that can take several weeks. “When you virtualize the applications and use commodity hardware, you can accelerate things but there are still manual interventions.”

By describing a service in code-based templates using standard description languages, and defining how many VNFs the service will have, how many components in each VNF and how they are interconnected, “you can use a tool like Ansible to do an automatic deployment without any manual intervention.”

The second key technology is DevOps, which can further streamline the process, by applying continuous delivery and continuous integration (CD/CI) during deployment, testing and monitoring. And the third key technology is whenever possible, to use cloud-native VNFs. Why? They are scalable, self-healing, support the DevOps approach and allow for microservices.

Of course, as Robla pointed out, most telcos will have to deal with legacy VNF for some time, and Ansible can be used for configuration management, de Soto said. As an example, some of the physical network functions still need a specific PCI address to identify the network that the interface is going to be connected. While this can be handled in a pure virtualization environment, it’s more difficult in an OpenStack cloud. That’s because with Nova, the OpenStack project that provides a way to provision virtual servers, there’s not a consistent ordering of interfaces.

So, the OpenStack community came up with a solution – a specification for Virtual Device Role Tagging that provides a mechanism to communicate to the guest operating system the intended usage of virtual network interfaces and disks. The tag will be matched to the hardware address of the device, and this mapping is exposed to the guest operating system via a metadata file to determine which devices need to be used for particular application services running in the instance. The spec does not define how the guest operating system does this, but Ansible does.

To see the specification in action, with live demos of two Ansible playbooks, including one of a cloud provider using OpenStack modules from Ansible to spin up virtual machines and another using Ansible for VNF configuration, watch the “Automating the Deployment of Legacy VNFs with Ansible” presentation.

Your VNFs have to live somewhere. Whether you’re managing a private cloud or deploying instances from templates, Red Hat Ansible Automation helps streamline the process, check out all available resources and get started with Ansible.