Shulou(Shulou.com)06/01 Report--

This article introduces how to achieve network automation in Ansible. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Network automation

With the technological changes in the IT industry, from server virtualization to public and private clouds, as well as self-service capabilities, containerized applications, and platform as a service (PaaS) delivery, one area that has been lagging behind is the network.

In the past five years, there seem to be a lot of new trends in the network industry, many of which are classified as software-defined network software-defined networking (SDN).

Note:

SDN is an emerging way to build, manage, operate, and deploy networks. SDN was originally defined as the need to physically separate the control layer from the data layer (packet forwarding), and the uncoupled control layer must manage its own devices.

Today, there are many technologies in SDN, including controller-based network controller-based networks, network device API, network automation, white-box switch whitebox switche, policy networking, network function virtualization Network Functions Virtualization (NFV) and so on.

For the purposes of this report, we refer to SDN's solution as our solution, which includes a network controller as part of the solution and improves the manageability of the network, but there is no need to decouple the control layer from the data layer.

One of these trends is that the API of network devices has emerged as a way to manage and operate these devices, truly providing machine-to-machine communication. API simplifies the development process when it comes to automating and building web applications, providing more structure for how data is modeled. For example, when an API-enabled device returns data as JSON/XML, it is structured and easier to use than returning native text information-- a command-line-only device that needs to be parsed manually.

Prior to API, the two main mechanisms for configuring and managing network devices were the command line interface (CLI) and simple Network Management Protocol (SNMP). Let's take a look at them. CLI is the man-machine interface of a device, while SNMP is not a real-time programming interface for the device.

Fortunately, because many vendors are scrambling to add API to devices, sometimes just because it is included in the request proposal (RFP), this has a very good side effect of supporting network automation. When a real API is released, the process of accessing data within the device, as well as administrative configuration, is greatly simplified, so we will evaluate this in this report. Although automation can be achieved using many traditional methods, such as CLI/SNMP.

Note:

As network devices are updated in the coming months or years, there is no doubt that vendors' API should be tested and used as a key decision criterion for purchasing network equipment (virtual and physical). If the vendor provides some libraries or integrates into automation tools, or if it is used in an open standard or protocol, users should know how the data is modeled through the device and what type of transport is used by API.

All in all, network automation, like most types of automation, is designed to work faster. Working faster is a good thing, and reducing the time for deployment and configuration changes is not always a problem that many IT organizations need to solve.

Including speed, let's now look at several reasons why these various types of IT organizations are gradually adopting network automation. You should note that the same principle applies to other types of automation.

Simplify Architectur

Today, every network is a unique "snowflake", and network engineers are proud to be able to solve transmission and application problems through one-off network changes, which ultimately makes the network not only difficult to maintain and manage. and it's hard to automate.

Network automation and management need to be included in the new architecture and design from the beginning, not as a second-or third-tier project. Which feature works across different vendors? Which extension can work across different platforms? What is the API type or automation project when using a specific network equipment platform? When these questions are answered before the design process, the final architecture will become simple, repeatable, and easy to maintain and automate, and vendor-specific extensions will rarely be enabled throughout the network.

Determined result

In an enterprise organization, the change Review Conference change review meeting assesses the network changes faced, their impact on external systems, and rollback plans. In a world where people use CLI to implement the changes they are facing, the impact of typing the wrong commands can be catastrophic. Imagine a team of three, four, five, or 50 engineers. Each engineer has his or her own unique way to deal with the changes they face. And, during the period of managing these changes, a person's ability to use CLI or GUI does not eliminate or reduce the probability of errors.

Using validated and tested network automation can help achieve more predictable behavior. it also makes the execution team more likely to achieve definitive results, and goes one step further on the road to ensuring that the task is completed correctly without human error.

Business agility

Needless to say, network automation not only provides speed and flexibility for deployment changes, but also makes it faster to retrieve data from network devices according to business needs. Since the advent of server virtualization, servers and virtualization have enabled administrators to deploy a new application in an instant. And as applications can be deployed faster, the question that arises is why it takes so long to configure a VLAN (virtual local area network), router, FW ACL (access control list for firewalls), or load balancing policy.

By understanding the most common workflows in an organization and why there is a real need to change the network, deploying modern automation tools such as Ansible will make this very easy.

This chapter introduces some advanced knowledge points about why network automation should be considered. In the next section, we will take you to understand what Ansible is and continue to learn more about the different types of network automation of IT organizations of different sizes.

What is Ansible?

Ansible is an IT automation and configuration management platform that exists in the open source world. It is often compared with other tools such as Puppet, Chef and SaltStack. Ansible emerged in 2012 as an open source project created by Michael DeHaan, and Michael DeHaan also created Cobbler and cocreated Func, which are very popular in the open source community. Less than 18 months after the creation of the Ansible open source project, Ansilbe was founded and received $6 million in round A funding. The company has always been a contributor and supporter of the Ansible open source project. In October 2015, Red Hat acquired Ansible.

But what exactly is Ansible?

Ansible is a super simple automation platform that does not need agents and is extensible.

Let's take a closer look at the details and take a look at the attributes that make Ansible widely recognized in the industry.

simple

One of the attractive properties of Ansible is that you don't need specific programming skills to use it. All instructions, or tasks, are automated, documented in a standard human-readable data format that anyone can understand. It is not uncommon to complete installation and automation tasks within 30 minutes!

For example, the following tasks from an Ansible script playbook are used to ensure that a VLAN exists in a Cisco Nexus switch:

-nxos_vlan: vlan_id=100 name=web_vlan

You don't need to be familiar with or write any code to see exactly what it's going to do!

Note:

The second half of this report deals with the details of Ansible terminology (script playbook, episode play, task task, module module, etc.). When we use Ansible for network automation, we will have some short examples when referring to these key concepts.

No agent

If you look at other tools on the market, such as Puppet and Chef, you will find that, in general, they require that every automated device must install specific software. This situation is not needed on Ansible, which is the main reason why Ansible is the choice to automate the network.

It is understandable that those IT automation tools, including Puppet, Chef, CFEngine, SaltStack, and Ansible, were originally built to manage and automate the configuration of Linux hosts to keep up with the growth of deployed applications. Because the Linux system is configured to be automated, it is not a technical challenge to install agents. If so, it will only delay the installation process, because there are now more than N hosts (which you want to automate) that need to deploy software on them.

In addition, when using agents, they require more complex DNS and NTP configurations. These are services that are already configured in most environments, but when you want to get something quickly or simply want to test what it can do, it will greatly delay the entire setup and installation process.

Since this report is only intended to introduce the use of Ansible for network automation, we would like to point out that Ansible, as an agentless platform, is more attractive to network administrators than to system administrators. Why is that?

As mentioned earlier, it is very attractive to network administrators, the Linux operating system is open source, and anything can be installed on it. This is not the case for the network, although it is gradually changing. If we deploy network operating systems such as Cisco IOS more widely, it is such an example and ask the question, "can third-party software be deployed on IOS-based platforms?" (IOS here refers to Cisco's network operating system IOS)? Without a doubt, its answer is NO.

In the past two decades, almost all network operating systems are closed-source and vertically integrated into the underlying network hardware. Without vendor support, it is not easy to load an agent in a network device (router, switch, load balancing, firewall, etc.). There is an automation platform like Ansible that builds an agentless, extensible automation platform from scratch, as if it were tailor-made for the network industry. We will eventually begin to reduce and eliminate human interaction with the network.

Scalable

The scalability of Ansible is also very good. From the beginning of open source and code to play an important role in the network industry, it is necessary to have an extensible platform. This means that if a vendor or community does not provide a specific feature or functionality, the open source community, end user, consumer, consultant, or anyone can extend Ansible to enable a given feature set. In the past, Internet vendors or tool vendors provided new plug-ins and integrations through a hook. Imagine using an automation platform like Ansible, and the network provider of your choice has released a new feature of automation that you really need. In theory, an Internet provider or Ansible can release a new plug-in to automate this unique feature, which is a very good thing, from your in-house engineer to your value-added distributor (VAR) or any of your consultants, can provide this integration.

As mentioned earlier, Ansible is actually * extensible, and Ansible was originally built for automated applications and systems. This is because the scalability of Ansible comes from its integration written for network vendors, including but not limited to Cisco, Arista, Juniper, F5, HP, A10, Cumulus, and Palo Alto Networks.

For network automation, why use Ansible?

We already have a brief understanding of what Ansible is and some of the benefits of network automation, but why should we use Ansible for network automation?

It is clear that many of the reasons that make Ansible such a great automated application deployment platform have been mentioned. However, we need to go deeper now, focus more on the network, and continue to summarize some other key points that require more attention.

No agent

When realizing network automation, the importance of agentless architecture is not emphasized, especially when it is suitable for existing automation equipment. If we look at the various devices that have been installed in the current network, from DMZ and campus to branch offices and data centers, * share of devices do not have * API devices. From an automation perspective, API makes it easy to do things, and agentless platforms like Ansible have the potential to automate and manage old (traditional) devices. For example, CLI-based devices, whose tools can be used in any network environment.

Note:

If devices that only support CLI have been integrated into Ansible, its mechanism is like how to do read-only access and read-write operations on the device through protocols such as telnet, SSH, and SNMP.

As a stand-alone network device such as routers, switches, and firewalls are continuing to increase API support, SDN solutions are also emerging. One of the common themes of SDN solutions is that they all provide a single point of integration and policy management, usually in the form of a SDN controller. This is a real solution for Cisco ACI, VMware NSX, Big Switch Big Cloud Fabric, and Juniper Contrail, as well as other SDN providers, such as Nuage, Plexxi, Plumgrid, Midokura, and Viptela. This even includes open source controllers such as OpenDaylight.

All of these solutions simplify network management, just as they allow an administrator to start migrating from "box-by-box" management to network-wide management. This is a big step in the right direction, and these solutions do not eliminate the chances of human mistakes during change. For example, instead of configuring N switches, you may need to configure a single GUI, which takes a long time to implement the required configuration changes-it may be even more complex, after all, they prefer GUI to a CLI! In addition, you may have different types of SDN solutions deployed in each application, network, region, or data center.

In networks that require automation, these requirements do not disappear when the industry begins to migrate to a controller-based network architecture for configuration management, monitoring, and data collection.

Controllers are deployed in a large number of software-defined networks, and almost all controllers provide expose with a * REST API. And, because Ansible is an agentless architecture, it is very easy to automate, not just for traditional devices without API, but also for software-defined networking solutions through REST API, which do not require additional software on all terminals. The end result is that with Ansible, with or without API, any type of device can be automated.

Free open source software (FOSS)

Ansible is an open source software, all of its code is publicly accessible on GitHub, using Ansible is completely free. It can complete the installation in a few minutes and provide useful value to network engineers. Ansible, an open source project, or Ansible, you won't meet a sales representative until they deliver the software. That's an obvious fact, because it's a true open source project, but the use of open source, community-driven software projects in the web industry is very small, but it's also increasing. We want to make this clear.

It is also important to point out that Ansible, Inc. It's also a company, and it needs to make money, right? Although Ansible is open source, it also has an enterprise product called Ansible Tower, which adds some features, such as rule-based access control (RBAC), reporting, web UI, REST API, multi-tenancy, etc., which is more suitable for enterprise deployment than Ansible. And, more importantly, Ansible Tower can even be used for free on up to 10 devices, at the very least, you can experience whether it will benefit your organization without spending a penny and without having to deal with countless sales representatives.

Expandability

As we said earlier, Ansible is primarily an automated platform built for deploying Linux applications, although it has been extended to Windows since the early days. It should be noted that the Ansible open source project does not have the goal of "automating network infrastructure". In fact, the Ansible community knows better how to be more flexible and extensible on the underlying Ansible architecture, making it easier to become an extended Ansible for their automation needs, including the network. In the past two years, many Ansible integrations have been deployed, many of which have been carried out by industry independents, such as Matt Oswalt, Jason Edelman, Kirk Byers, Elisa Jasinska, David Barroso, Michael Ben-Ami, Patrick Ogenstad and Gabriele Gerbino, as well as network system vendors such as Arista, Juniper, Cumulus, Cisco, F5, and Palo Alto Networks.

Integrate into existing DevOps workflows

Ansible is used for application deployment in the IT organization. It is used in operations teams that need to manage deployment, monitoring, and management of various types of applications. By integrating Ansible into the network infrastructure, it expands the possible scope when new applications arrive or migrate. Instead of waiting for a new TOR, adding a VLAN, or checking the speed / duplex of the interface, all of these network-centric tasks can be automated and integrated into existing workflows within the IT organization.

Idempotency

The term idempotent idempotency (pronounced item-potency) is often used in the field of software development, especially when working with REST API, as well as in the field of DevOps automation and configuration management frameworks, including Ansible. One of Ansible's beliefs is that all Ansible modules (integrated) should be idempotent. So, what does idempotent mean for a module? After all, this is a new term for most network engineers.

The answer is simple. The essence of idempotency is to allow defined tasks to be run once or thousands of times without adversely affecting the target system, just an one-time change. In other words, if there is a change to bring the system into its desired state, after the change is completed, and if the device has reached this state, it will not change again. This is not like most traditional custom scripts and CLI commands that copy and paste into those terminal windows. Errors occur when the same command or script is run repeatedly on the same system. Even if you paste a set of commands into a router, you may encounter errors that invalidate the rest of your configuration. Isn't it fun?

Another example is that if you have a file or script that configures 10 VLAN, the same command will be entered 10 times each time the script is run. If you use an idempotent Ansible module, the existing configuration is first collected from the network device, and each new VLAN is configured and the current configuration is checked again. The command is actually pushed to the device only if the new VLAN needs to be added (or, say, change the VLAN name) is a change.

As a technology becomes more complex, the more idempotent it becomes, and when you modify it, you don't notice the status of existing network devices, but just try to achieve the desired state from a network configuration and policy perspective.

Network-wide and temporary (Ad Hoc) changes

One of the problems solved with configuration management tools is configuration "drift" (when the desired configuration of the device gradually drifts, or changes, over time, manual changes and / or multiple different tools are used in an environment), in fact, this is where Puppet and Chef are used. The agent telephoned phone home to the front-end server to verify its configuration and, if necessary, to change it. This method is very simple. What if something goes wrong and needs to be eliminated? You usually need to skip the management system, connect directly to the device, find and fix it, and then leave right away. Sure enough, the next time Li Dian comes back, the change to the fix problem will be overwritten (based on how the master / front-end server is configured). In a highly automated environment, one-time changes should be limited, but tools that still allow them to be used are very valuable. As you can imagine, one of these tools is Ansible.

Because Ansible is agentless, there is no default push or pull to prevent configuration drift. Automation tasks are defined in Ansible

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.