Ansible + ServiceNow Part 1: Opening and Closing Tickets
As a Network Engineer, I hated filling out tickets. Anytime a router would reboot or a power outage took place at a remote site, the resulting ticket generation took up about 50% of my day. If there had been a way to automate ticket creation, I would have saved a lot of time. The only thing unique to provide would have been case-specific comment sections needing additional information about the issue.
While ticket creation was a vital activity, automating this was not an option at the time. This is surprising because my management was always asking me to include more information in my tickets. Tickets were often reviewed months later and sometimes never got created or did not have much relevant information included.
Fast forward to today, companies are now data mining from tickets with a standard set of facts that are pulled directly from the device during ticket creation, such as network platform, software version, uptime, etc. Network operations (NetOps) teams now use massive amounts of ticket data to make budget decisions.
For example, if there were 400 network outages due to power issues, NetOps could then make a case to spend $40,000 on battery backups, having proved Continue reading
What’s New in Ansible Tower 3.5
We're excited to announce that Red Hat Ansible Tower 3.5 is now generally available. In this release, there are several enhancements that can help improve automation practices. Engineering has been working hard to enhance Ansible Tower and here are a few things we're most excited about:
- Red Hat Enterprise Linux 8 support
- Support for external credential vaults via credential plugins
- Become plugins now supported in Ansible Tower
In addition to a number of enhancements that have been made, the Ansible Tower 3.5 release saw over 160 issues closed. Let’s go over the highlights in this release.
Red Hat Enterprise Linux 8 support
Red Hat Enterprise Linux is an innovative operating system, designed to provide a consistent foundation for the enterprise hybrid cloud. It offers one enterprise Linux experience for applications across IT environments. With Ansible Tower 3.5 (and Ansible Engine 2.8), support for managing RHEL 8 nodes is baked in. Ansible Tower 3.5 can also be run on Red Hat Enterprise Linux 8 as the control node for Red Hat Ansible Automation.
External credential vaults
Ansible Tower 3.5 brings support for external credential vaults. The existing credential store is still available for use. However, Continue reading
What’s New in Red Hat Ansible Engine 2.8
Red Hat Ansible Engine 2.8 is now available. This release features many improvements and enhancements (please refer to the CHANGELOG for more details). Also, new features worth highlighting here are Ansible content (Collections), BECOME being the default privilege escalation path, no longer depending on paramiko, and BECOME plugins, and other notable improvements and changes.
The future of how Ansible content is handled
The Ansible community is excited to provide new modules and plugins for Ansible users. This keeps Ansible maintainers busy; merging new code into repositories as fast as a team can. Occasionally, things get left behind. Content that could have been released ends up waiting for the next Ansible Engine release. Currently, the official Ansible Engine release process is the only way for users to utilize or consume new content easily.
As such, the Ansible community has begun the journey of providing our users with more flexibility to create and consume content. In Ansible Engine 2.8, modifications are in place for how Ansible Engine handles content not delivered in the official release. These changes allow for the creation of a new delivery method to users. This delivery method should not depend on Ansible maintainers to manage content Continue reading
Tower Workflow Convergence
In Red Hat Ansible Tower 3.1 we released a feature called Workflows. The feature, effectively, allowed users to compose job templates into arbitrary graph trees. A simple workflow we saw users creating was a linear pipeline; similar to the workflow below.
The workflow feature also allowed branching. Each branch can run in parallel.
But something was missing. The ability to wait for previous parallel operations to finish before proceeding. If this existed, you could simplify the above workflow (see below).
In Red Hat Ansible Tower 3.4 the above workflow is now possible with the introduction of the Workflow Convergence feature.
For you computer sciencey folks, workflows are no longer restricted to a tree, you can create a DAG. More simply, we call this convergence; two nodes are allowed to point to the same downstream node. The concept is best shown through an example. Above, we have a workflow with 3 nodes. The first two job templates run in parallel. When they both finish the 3rd downstream, convergence node, will trigger.
In this blog post we will cover the changes to workflow failure scenarios, how workflow node failure and success propagate, how this affects the runtime graph and how Continue reading
Using Infoblox as a dynamic inventory in Red Hat Ansible Tower
Do you still use spreadsheets to keep track of all your device inventory? Do you have Infoblox Appliances deployed in your infrastructure? Do you want to start automating without the burden of maintaining a static register of devices? If you answered yes to any of these questions, this blog is for you.
Operations teams often struggle to keep their Configuration Management Databases (CMDBs) up-to-date, primarily because they were not involved in the specification process to share what pieces of information are relevant to them, or even if they were, once it is put in place: Teams are not allowed to change any of their Configuration Items (CI) because they have only read-only access!
The reality is that a lot of the time when we talk about a CMDB, we are talking about tables in a database without any version control mechanism, therefore only read access is provided to end users.
The impact is that in order to perform lifecycle management (Create/Update/Decommission) of their configuration items, teams must go through a fastidious and manual process until they give up changing CIs (Configuration Items) in the CMDB and just leave everything as it is. What happens next? Different teams start Continue reading
Build a quick CI system using Red Hat Ansible Tower with GitHub Actions
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
Summary of Authentication Methods in Red Hat Ansible Tower
Red Hat Ansible Tower 3.4.0 has added token authentication as a new method for authentication so I wanted to use this post to summarize the numerous enterprise authentication methods and the best use case for each. Ansible Tower is designed for organizations to centralize and control their automation with a visual dashboard for out-of-the box control while providing a REST API to integrate with your other tooling on a deeper level. We support a number of authentication methods to make it easy to embed Ansible Tower into existing tools and processes to help ensure the right people can access Ansible Tower resources. For this blog post I will go over four of Ansible Tower’s authentication methods: Session, Basic, OAuth2 Token, and Single Sign-on (SSO). For each method I will provide some quick examples and links to the relevant supporting documentation, so you can easily integrate Ansible Tower into your environment.
1. Session Authentication
Session authentication is what’s used when logging in directly to Ansible Tower’s API or UI. It is used when a user wants to remain logged in for a prolonged period of time, not just for that HTTP request, i.e. when browsing the UI or Continue reading
Find the right AMI everytime: Make your AWS application work in any region
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
Three quick ways to move your Ansible inventory into Red Hat Ansible Tower
If you’ve been using Ansible at the command line for a while, you probably have a lot of servers, network devices, and other target nodes listed in your inventory. You know that Red Hat Ansible Tower makes it easier for everyone on your team to run your Ansible Playbooks. So you’ve thought about using Ansible Tower to take your automation to the next level, but you want to retain all the data and variables in your existing inventory file or directory. Are you worried about transferring your inventory from command-line use to Ansible Tower? Let me show you how easy it is to import your existing Ansible inventory into Ansible Tower!
This blog covers three quick and effective ways to connect your existing Ansible inventory into Ansible Tower:
- Migrating an inventory file from the Ansible Tower control node (awx-manage)
- Migrating an inventory file from anywhere with a playbook
- Setting Tower to access a git source-controlled inventory file
If you don’t have Ansible Tower yet and want to download and try it out, please visit: https://www.ansible.com/products/tower
If you’re using dynamic inventory, you don't need to import your inventory into Ansible Tower. Dynamic inventory retrieves your inventory from an Continue reading
Ansible Community Update — February 2019
Ansible is a popular project by many metrics, including over 42,000 commits on GitHub. Our community contributes a lot of pull requests (PRs) every month. Unfortunately, the volume of incoming PRs means contributors often have to wait days, weeks, or months for PRs to be merged. Sometimes it takes that long for a cursory review. We want to change that, but we need your help!
The Core team and community at large are kicking off new initiatives under the contributor experience umbrella. The idea is to help address causes that slow down quality PRs from being merged into Ansible's codebase.
To help with this, we are dedicating one day a month to doing a community review. The goals we are setting for these meetings are:
-
Give potential new community members a place to learn and experiment with Ansible's review process and exchange feedback
-
Identify process and documentation improvements via feedback provided from the Ansible community
-
Give PRs needed attention; remove blockers where necessary
-
Identify PRs that could be merged or closed
We’re particularly interested in feedback from people starting their journey with open source as it helps us to improve our processes and documentation. It’s helpful to have new contributors Continue reading
Ansible Operator: What is it? Why it Matters? What can you do with it?
The Red Hat Ansible Automation and Red Hat OpenShift teams have been collaborating to build a new way to package, deploy, and maintain Kubernetes native applications: Ansible Operator. Given the interest in moving workloads to Kubernetes, we are happy to introduce a new tool that can help ease the move toward cloud native infrastructure.
What is Kubernetes? The simplest definition of Kubernetes I’ve ever used is, “Kubernetes is a container orchestrator.” But that is a simplified definition.
What is OpenShift? Red Hat OpenShift Container Platform is an enterprise-grade Kubernetes distribution. It enables management of container applications across hybrid cloud and multicloud infrastructure.
First, let’s identify the problem operators can help us solve. Operators help simplify deployment, management, and operations of stateful applications in Kubernetes. But, writing an operator today can be difficult because of the knowledge of Kubernetes components required to do so. The Operator SDK is a framework that uses the controller-runtime library to help make writing operators more simple. The SDK enables Operator development in Go, Helm, or Ansible.
Why It Matters
What can an Ansible Operator give us that a generic operator doesn’t? The same things Ansible can give its users: a lower barrier to entry, faster iterations, Continue reading
Deep Dive on cli_command for Network Automation
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.
What can you do with the cli_command?
The cli_command allows you to run arbitrary commands on network devices. Let’s show a simple Continue reading
Webinar: “How to Make Your Mark: Ansible Community Contributions”
On Wednesday, January 30, 2019, 9:30 AM EST, we will be hosting a webinar, How to Make Your Mark: Ansible Community Contributions. This webinar is tailored for everyone in the Ansible community. Whether you're a brand new member of the Ansible community or a full-fledged Red Hat Ansible Tower customer, contributing to the Ansible projects is a way to put features and fixes into the tools you use daily.
Join John "gundalow" Barker (Principal Software Engineer, Ansible Community) and Alicia Cozine (Technical Writer, Ansible Documentation) as they discuss and demonstrate contribution how-to’s and best practices. They will also quell some common myths about contributing to Ansible and dive into the Ansible development workflow.
There are no prerequisites for attending this webinar. You don’t need to know git, understand GitHub, nor write Python. There will also be a Q&A session during the webinar. If you have questions about how or where to get started after the webinar, please ask them! One of the best parts about being a community is continually improving the way we work. If you have suggestions for documentation, process, etc. but don’t know the best place to ask, this webinar will help.
Ansible Contributor Experience Working Group Continue reading
AnsibleFest is heading to Atlanta!
We are excited to announce the dates and location for AnsibleFest 2019. We’ve selected a location that not only provides the ease of use (or access in this case) that users expect from all things Ansible, but also the enjoyment folks expect after automating their way through complex problems.
ATLANTA! Home of the Braves (MLB), Falcons (NFL), Hawks (NBA), the largest aquarium in the world, the busiest airport in the world, and great restaurants like The Varsity and Old Lady Gang. Soon it will also be the home of AnsibleFest 2019!
Join us at the Hilton Atlanta Downtown, September 24-26, 2019. We will follow the same format as last year with a Welcome Party on September 23, two days of content on September 24-25, and some add-on options, like workshops, on September 26. There will also be a Contributor Summit again (details to follow at a later date). We’ll be bringing back the high quality experiences attendees have come to expect, including Ask an Expert and the Getting Started Hub. But, most importantly, we’ll have sessions from folks across the Ansible community.
Here’s what to expect between now and AnsibleFest Atlanta 2019:
- The AnsibleFest sponsorship prospectus will be available in Continue reading
What’s New in Ansible Tower 3.4
We hope that 2019 will be a great year and the Ansible team is here to start it off right. We're happy to announce that Red Hat Ansible Tower 3.4 is now generally available. In this release, there are several enhancements that can help improve automation practices. Engineering has been working hard to enhance Red Hat Ansible Tower. We're most excited about workflows enhancements, job slices, and some other nifty features. Let’s dive a little deeper into what we’re excited about in this release.
Workflow Enhancements
The enhancements to workflows in Red Hat Ansible Tower 3.4 are a combination of internal and customer requested features. This is designed to bring needed hybrid cloud management capabilities to engineers and administrators around the globe.
Workflow Convergence
Workflow convergence enables a convergence step that tracks the completion of multiple workflow jobs before continuing. For example, when deploying application updates there might be a need to wait until a group of nodes drains from a load balancer pool before having a service stopped on any node in the group. This helps enable a more complete dependency chain for jobs inside workflows.
Nested Workflows
Workflows have been able to have job templates Continue reading
Ansible Tips and Tricks: Dealing with Unreliable Connections and Services
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
Integrating Ansible and Red Hat Enterprise Linux 8 Beta
Red Hat is proud to announce that Ansible supports managing Red Hat Enterprise Linux 8 Beta hosts. Before you can manage Red Hat Enterprise Linux 8 Beta nodes with Ansible 2.7, though, you need to set the appropriate python interpreter. Ansible allows you to manage a huge range of hosts and devices, from legacy systems to beta-release testing platforms, by working with both Python 2 and Python 3. However, with Ansible 2.7 managing Red Hat Enterprise Linux 8 Beta, you must define which Python to use. When Ansible 2.8 is released, we plan for Ansible to automatically discover the correct Python to use on Red Hat Enterprise Linux 8 Beta hosts.
Setting the Python interpreter on Red Hat Enterprise Linux 8 Beta managed nodes
You can define the python interpreter Ansible should use on your Red Hat Enterprise Linux 8 Beta nodes with an inventory host_var, a group_var, a play, or an ad-hoc command. You must do this on every Red Hat Enterprise Linux 8 node just as you would for any Python3 enabled host. To set the python interpreter in your inventory with a host_var:
[RHEL8hosts]
RHEL8.example.com ansible_python_interpreter=/usr/libexec/platform-python
This example directs Ansible to use Continue reading
Ansible and Infoblox: Roles Deep Dive
As Sean Cavanaugh mentioned in his earlier Infoblox blog post, the release of Ansible 2.5 introduced a lookup plugin, a dynamic inventory script, and five modules that allow for Infoblox automation. A combination of these modules and lookups in a role provides a powerful DNS automation framework.
Summary
Today we are going to demonstrate how automating Infoblox Core Network Services using Ansible can help make managing IP addresses and routing traffic across your network easy, quick, and reliable. Your network systems for virtualization and cloud require rapid provisioning life cycles; Infoblox helps you manage those lifecycles. When paired with Infoblox, Ansible lets you automate that work. Ansible’s integration with Infoblox is flexible and powerful: you can automate Infoblox tasks with modules or with direct calls to the Infoblox WAPI REST API.
This post will walk you through six real-world scenarios where Ansible and Infoblox can streamline your network tasks:
- Creating a provider in one place that is reusable across a collection of roles.
- Expanding your network by creating a new subnet with a forward DNS zone. Ansible modules for Infoblox make this common two-part task simple.
- Creating a reverse DNS zone, for example, to flag email from any Continue reading
Red Hat Ansible Network Automation Updates
For this blog post I am going to cover the following topics:
- The httpapi connection plugin
- Support for Arista eAPI and Cisco NX-API
- net_get and net_put
- netconf_get, netconf_rpc and netconf_config
- cli_command and cli_config
The HTTPAPI connection plugin
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
The release of Red Hat Ansible Engine 2.7
Red Hat Ansible Engine 2.7 is now available, featuring improved stability, speed and performance.
Preparing for the Future
Ansible Engine 2.7 continues to improve compatibility with modern versions of Python. As a result of changes to support newer versions of Python, support for running Ansible Engine with Python 2.6 has been removed. Management of systems with Python 2.6 installed is still possible, though the system Ansible Engine is running from must have Python 2.7 or Python 3.5 or later. This means if ansible-pull is being used the system running ansible-pull will need Python 2.7 or Python 3.5 or later.
A new file locking feature is designed to prevent race conditions when delegating to a central resource. For example, if a play calls for several hosts to write to a single file on a remote host it is likely multiple hosts would attempt to write to the file at the same time. This can now be done in Ansible Engine 2.7.
Deprecating use of features is often a challenging task. This task can be even more challenging when it involves multiple Ansible core modules. In Ansible Engine 2.7, several modules have Continue reading