Author Archives: Sean Cavanaugh
Author Archives: Sean Cavanaugh
The Red Hat Ansible Network Automation engineering team is continually adding new resource modules to its supported network platforms. Ansible Network Automation resource modules are opinionated network modules that make network automation easier to manage and more consistent for those automating various network platforms in production. The goal for resource modules is to avoid creating and maintaining overly complex jinja2 templates for rendering and pushing network configuration, as well as having to maintain complex fact gathering and parsing methodologies. For this blog post, we will cover standard return values that are the same across all supported network platforms (e.g. Arista EOS, Cisco IOS, NXOS, IOS-XR, and Juniper Junos) and all resource modules.
Before we get started, I wanted to call out three previous blog posts covering resource modules. If you are unfamiliar with resource modules, check any of these out:
Red Hat Ansible Automation Platform 1.2 is now generally available with increased focus on improving efficiency, increasing productivity and controlling risk and expenses. While many IT infrastructure engineers are familiar with automating compute platforms, Ansible Automation Platform is the first holistic automation platform to help manage, automate and orchestrate everything in your IT infrastructure from edge to datacenter. To download the newest release or get a trial license, please sign up on http://red.ht/try_ansible.
The Ansible project is a remarkable open source project with hundreds of thousands of users encompassing a large community. Red Hat extends this community and open source developer model to innovate, experiment and incorporate feedback to satisfy our customer challenges and use cases. Red Hat Ansible Automation Platform transforms Ansible and many related open source projects into an enterprise grade, multi-organizational automation platform for mission-critical workloads. In modern IT infrastructure, automation is no longer a nice-to-have; it’s often now a requirement to run, operate and scale how everything is managed: including network, security, Linux, Windows, cloud and more.
Ansible Automation Platform includes a RESTful API for seamless integration with existing IT tools Continue reading
Private Automation Hub is now available as part of Red Hat Ansible Automation Platform release 1.2, providing an easier way for our customers to manage their Ansible content. Whether they produce private content, access trusted and supported content from Red Hat or obtain content from third party or other community sources, an internally controlled capability is essential to support the continued growth of automation. As automation becomes critical to managing IT activities, so too becomes the need to have a focal point where collaboration can be encouraged, content shared and trust reinforced.
Private Automation Hub is a self-hosted Ansible content management system. Organizations can host private hubs on their own infrastructure and manage it themselves. Similar to how Red Hat Satellite enables Red Hat Enterprise Linux customers to manage operating system content, private Automation Hub enables automation teams to manage Ansible automation content. Private Automation Hub allows curation and distribution of Ansible content as close as possible to Ansible Automation Platform clusters. Private Automation Hub is included in the Red Hat Ansible Automation Platform subscription.
Ansible content can be broken up into three main categories:
The Red Hat Ansible Automation Platform is continually offering enhancements through its hosted services on cloud.redhat.com. At Red Hat Summit 2020 the new automation services catalog took the spotlight, which provides lifecycle management, provisioning, retirement and cataloging of automation resources to your business. However I wanted to also talk about the additional new enhancements coming to Automation Analytics! Specifically I have two big things I want to talk about:
If you are unfamiliar with Automation Analytics it is included as part of a Red Hat Ansible Automation Platform subscription and allows customers to analyze, aggregate, and report on data for their Red Hat Ansible Automation Platform deployments. Check out the previous blog I wrote about Getting Started with Automation Analytics, or if you have concerns around what type of data is being shared with Red Hat check out my blog Automation Analytics: Part 2 - Looking at Data Collection.
I am super excited about this new feature of Automation Analytics. A lot of customers I get to meet with are trying to figure out how to Continue reading
The world is currently a very different place than it was only a few months ago and we have come up with some ideas on how we can help our community in dealing with this new reality. The Ansible team has started a “Here to Help” webinar series where myself and other Ansible engineers are spending time with smaller groups of people to try and help them with technical challenges: https://www.ansible.com/here-to-help-webinar-series. The goal of these webinars is strictly to help! Regardless of if folks are only using open source technologies and not Red Hat products, we want to use this time to help them solve automation challenges, and help us brainstorm use-cases that can help others.
Another idea we recently implemented is integrating IBM’s World Community Grid into our workshops. World Community Grid enables anyone with a Linux, Windows or Mac computer (or an Android smartphone for some projects) to donate their unused computing power to advance scientific research on topics related to health and sustainability. In fact, one of their projects is specifically going to help combat COVID-19. This blog post will cover what our workshops are and how we can use idle CPU time to help Continue reading
Red Hat Ansible Automation Platform now includes hosted service offerings, one of which is Automation Analytics. This application provides a visual dashboard, health notifications and organization statistics for your Ansible Automation. If you are new to Automation Analytics and want more background information please refer to my previous blog Getting Started with Automation Analytics.
On the Automation Analytics dashboard there is the ability to filter by Red Hat Ansible Tower cluster and by date. Red Hat recommends having a cluster local to where the automation is happening, for example if you had a data center in Japan, Germany and the United States you would most likely have an Ansible Tower Cluster in each geographic region. This allows users to perform drill down filtering to individual clusters to get data relevant for a specific physical site or group. This is helpful if, for example, a company's team in Japan only cared about data relevant to them in the drop down menu.
Previously, this only affected the top graph, but not sub cards such as Top Templates or Top Modules. In the following video you can now see that all cards are updated simultaneously.
In October of 2019, as part of Red Hat Ansible Engine 2.9, the Ansible Network Automation team introduced the concept of resource modules. These opinionated network modules make network automation easier and more consistent for those automating various network platforms in production. The goal for resource modules was to avoid creating overly complex jinja2 templates for rendering network configuration. This blog post goes through the eos_vlans module for the Arista EOS network platform. I walk through several examples and describe the use cases for each state parameter and how we envision these being used in real world scenarios.
Before starting let’s quickly explain the rationale behind naming of the network resource modules. Notice for resource modules that configure VLANs there is a singular form (eos_vlan, ios_vlan, junos_vlan, etc) and a plural form (eos_vlans, ios_vlans, junos_vlans). The new resource modules are the plural form that we are covering today. We have deprecated the singular form. This was done so that those using existing network modules would not have their Ansible Playbooks stop working and have sufficient time to migrate to the new network automation modules.
On February 10th, The NRE Labs project launched four Ansible Network Automation exercises, made possible by Red Hat and Juniper Networks. This blog post covers job responsibilities of an NRE, the goal of Juniper’s NRE Labs, and a quick overview of new exercises and the concepts Red Hat and Juniper are jointly demonstrating. The intended audience for these initial exercises is someone new to Ansible Network Automation with limited experience with Ansible and network automation. The initial network topology for these exercises covers Ansible automating Juniper Junos OS and Cumulus VX virtual network instances.
Juniper has defined an NRE or network reliability engineer, as someone that can help an organization with modern network automation. This concept has many different names including DevOps for networks, NetDevOps, or simply just network automation. Juniper and Red Hat realized that this skill set is new to many traditional network engineers and worked together to create online exercises to help folks get started with Ansible Network Automation. Specifically, Juniper worked with us through NRE Labs, a project they started and co-sponsor that offers a no-strings-attached, community-centered initiative to bring the skills of automation within reach Continue reading
With the Red Hat Ansible Automation Platform release in November, we released over 50 network resource modules to help make automating network devices easier and more turn-key for network engineers. In addition to the new resource modules, Andrius also discussed fact gathering enhancements in his blog post, which means with every new resource module, users gain increased fact coverage for network devices. For this blog post I want to cover another cool enhancement that may have gone unnoticed. This is the ability for network devices to make use of the wait_for_connection module. If you are a network engineer that has operational Ansible Playbooks that need to reboot devices or take them offline, this module will help you make more programmatic playbooks to handle disconnects. By leveraging wait_for_connection network automation playbooks can look and behave more like playbooks for Linux or Windows hosts.
We recently released Red Hat Ansible Automation Platform which now includes multiple Software-as-a-Service (SaaS) offerings, one of which is Automation Analytics. This offering provides a visual dashboard, health notifications and organization statistics for your Ansible Automation. Automation Analytics works across multiple Ansible Tower clusters allowing holistic analytics across your entire automation infrastructure.
In a previous blog I wrote about Getting Started with Automation Analytics, but now want to expand on what data is collected and how to gain access to that data. I highly recommend reading the previous blog if you are new to Red Hat Ansible Automation Platform, Ansible Tower concepts and our SaaS offerings. This is important to many customers because they all have their own security concerns with what data leaves their premises as well as obligations to their own customers and stakeholders to make sure data sent will not be compromised in any way.
Login to the Ansible Tower host with Continue reading
With the upcoming release of the Red Hat Ansible Automation Platform there are now included Software as a Service (SaaS) offerings, one of which is Automation Analytics. This application provides a visual dashboard, health notifications and organization statistics for your Ansible Automation. Automation Analytics works across multiple Ansible Tower clusters allowing holistic analytics across your entire infrastructure.
When talking to the community and our customers, a question that often comes up is: “How do we measure success?”. Automation Analytics provides key data on Job Template usage, Ansible Module usage, organizational comparisons across your enterprise, and much more. This data can be used to assess usage, success criteria, and even charge backs between different groups. This blog post will outline how to get started with Automation Analytics and start collecting data right away.
There are some terms used in this blog post that may be unfamiliar Continue reading
Red Hat Ansible Tower can be considered the API (Application Programmatic Interface) for your Ansible Playbooks. Even if you don’t take advantage of the Web UI (User Interface) many Ansible users still benefit from using Ansible Tower because they can fit it in their existing ecosystem of tools. Are you new to using the API on Ansible Tower and want to learn how to get started? This blog post will cover my own journey of getting Github Actions to work with Red Hat Ansible Tower. My goal was to be able to have Github PRs (Pull Requests) to trigger a workflow template to perform some automated testing using an Ansible Tower workflow. The popularity of some Ansible Playbooks I wrote is on the rise, so I thought I’d add some automated testing – just to make sure I didn’t accidentally break something the community was using.
I created a workflow in Red Hat Ansible Tower to provision instances into AWS (Amazon Web Services), run some Ansible Playbooks on the provisioned Red Hat Enterprise Linux control nodes, then perform a teardown and remove the instances, VPCs and any other artifacts from AWS. This provisioning, testing and teardown allows me to help Continue reading
With over 170 Amazon Web Services (AWS) modules, including 60 specifically for Elastic Compute Cloud (EC2), Ansible makes it easy to provision and manage AWS resources. Are you using resources on AWS and looking to diversify across regions to facilitate high availability and disaster recovery? Are you concerned about how Ansible handles differences among EC2 regions? This post will help you build Ansible Playbooks that operate smoothly across regions using the ec2_ami_facts module. In our example, we’ll spin up Red Hat Enterprise Linux instances in AWS.
To spin up an Amazon Machine Image (AMI), you must know the image’s ImageID, a unique identifier for that specific image. AMI ImageIDs use a human-unfriendly hex string to catalog the AMI. For example, ami-c998b6b2. Unfortunately AMI ImageIDs are unique per region, which means the ImageID for Red Hat Enterprise Linux in us-east-1 (Virginia) is not the same as the ImageID for the identical image in us-east-2 (Ohio). Some cloud operators use AWS CloudFormation templates, which include a catalog of AMI ImageIDs for every region, to make their deployment model work across regions. While this can work, it is a bit inflexible, needs constant maintenance of the CloudFormation template, and may work in one Continue reading
This blog covers three quick and effective ways to connect your existing Ansible inventory into Ansible Tower:
If you don’t have Ansible Tower yet and want to download and try it out, please visit: https://www.ansible.com/products/tower
In October Ansible 2.7 was released and brought us two powerful agnostic network modules, cli_command and cli_config. Do you have two or more network vendors within your environment? The goal of agnostic modules is to simplify Ansible Playbooks for network engineers that deal with a variety of network platforms. Rather than having to deal with platform specific modules (e.g. eos_config, ios_config, junos_config), you can now use cli_command or cli_config to reduce the amount of tasks and conditionals within a playbook, and make the playbook easier to use. This post will demonstrate how to use these modules and contrast them to platform specific modules. I’ll show some playbook examples and common use cases to help illustrate how you can use these new platform agnostic modules.
Both the cli_command and cli_config only work with the network_cli connection plugin. For those unfamiliar with the network_cli connection plugin check out this blog post I did last April. The goal of network_cli is to make playbooks look, feel and operate on network devices, the same way Ansible works on Linux hosts.
The cli_command allows you to run arbitrary commands on network devices. Let’s show a simple Continue reading
Red Hat Ansible Automation is widely known to automate and configure Linux and Windows hosts, as well as network automation for routers, switches, firewalls and load balancers. Plus, there are a variety of modules that deal with the cloud and the API around it such as Microsoft Azure, Amazon Web Services (AWS) and Google Compute Engine. And there are other modules that interact with Software as a Service (SaaS) tools like Slack or ServiceNow. Although the downtime for these APIs is very minimal, it does happen, and it is even more likely that the connection between your Ansible control host (where you are running Ansible from) and the cloud-centric API could be down.
In this blog post, I will cover some tips and tricks for dealing with unreliable connections to cloud-centric APIs and how I build Ansible Playbooks in a reliable manner. As a technical marketing engineer, I consider my customers the Red Hat field teams, and often Solutions Architects are running playbooks from unreliable hotel wireless, coffee shops and sometimes even airplanes! I have to make sure playbooks have some more robustness built in for these odd situations. It is hair-pulling frustrating to get through a 20 task Continue reading
With the recent success of the largest AnsibleFest to date I wanted to take a minute to reflect with a network automation perspective on the colossal enhancements the engineering team at Red Hat has done for the Ansible Engine 2.6 release, the Ansible Tower 3.3 release and the recent Ansible Engine 2.7 release. As a reminder for all Ansible lovers there is a porting guide for every release to make upgrades as easy as possible!
For this blog post I am going to cover the following topics:
Connection plugins allow Ansible to connect to target hosts so it can execute tasks on them. With the Ansible 2.5 release the network_cli connection plugin was introduced, removing the requirement for the provider parameter and standardizing network modules to allow playbooks to look, feel and operate just like they do on Linux hosts. This also allowed Red Hat Ansible Tower to Continue reading
I am getting super excited about my first ever AnsibleFest! Despite using Ansible for more than five years now, I have never had the opportunity to attend this famed event. I had coworkers from previous employers attend, and they were always excited and invigorated after the conference. October is fast approaching and the energy around the event is growing every day.
I’m especially excited for AnsibleFest 2018 because it will have an entire track dedicated to my favorite subject: Network Automation. Join us for two days (October 2-3) as Ansible network developers, Ansible experts from around the world, partners and community members showcase new functionality, use cases, stories and paths to production. You will hear from the developers who design, create, test and distribute the code. You’ll also hear from industry experts and network operators who create and deploy Ansible Playbooks to manage a variety of network gear and situations.
I’ll highlight two talks I’m especially excited about, to give you an idea of what you’ll learn in the Network Automation track at AnsibleFest 2018.
First up is one of my favorite coworkers, Trishna Guha, talking about the Network-Engine role. Trishna will highlight how Network-Engine extracts data from network devices Continue reading
Enterprise customers often ask the Ansible Network team about the most common use cases for network automation. For this blog post I want to talk about one of the most used (and most versatile) set of network modules: the
command modules. The command modules let you run networking commands with Ansible, the same way a network engineer would type them on the command line. With Ansible, though, the output doesn’t just fly by the terminal window to be lost forever; it can be stored and used in subsequent tasks. It can also be captured in variables, parsed for use by other tasks, and stored in host variables for future reference.
Today we’re going to cover basic use of the network
command modules, including retaining command output with the
register parameter. We’ll also cover scaling to multiple network devices with
hostvars and adding conditional requirements with the
wait_for parameter and three related parameters:
match. The takeaway from this blog post is that any repeatable network operations task can be automated. Ansible is more than configuration management, it allows network operators the freedom to decouple themselves from routine tasks and save themselves time.
There are command modules Continue reading
The Ansible Networking Team is excited about the release of Ansible 2.5. Back in February, I wrote about new Networking Features in Ansible 2.5, and one of the biggest areas of feedback was around the network_cli connection plugin. For more background on this connection plugin, please refer to the previous blog post.
In this post, I convert existing networking playbooks that use
connection: local to use
connection: network_cli. Please note that the passwords are in plain text for demonstration purposes only. Refer to the following Ansible Networking documentation page recommendation for using Ansible Vault for secure password storage and usage.
To demonstrate, let’s use an existing GitHub repository with working playbooks using the legacy connection local method. NOTE: The connection local method will continue to be supported for quite some time, and has not been announced as deprecated yet. This repository has several examples using Ansible and NAPALM but we are highlighting the Ansible Playbooks in this post. The GitHub repository can be found here.
Networking platforms use their specific
*_config platform module for easy backups within Ansible. For this playbook we are running the Ansible Playbook Continue reading