Hands On With Ansible collections
Ansible collections have been introduced previously through two of our blogs Getting Started with Ansible Content Collections and The Future of Ansible Content Delivery. In essence, Ansible Automation content is going to be delivered using the collection packaging mechanism. Ansible Content refers to Ansible Playbooks, modules, module utilities and plugins. Basically all the Ansible tools that users use to create their Ansible Automation. Content is divided between two repositories:
- Ansible Galaxy (https://galaxy.ansible.com)
- Automation Hub (https://cloud.redhat.com/ansible/automation-hub)
Ansible Galaxy is the upstream community for sharing Ansible Collections. Any community user can create a namespace and share content with anyone. Access to Automation Hub is included with a Red Hat Ansible Automation Platform subscription. Automation Hub only contains fully supported and certified content from Red Hat and our partners. This makes it easier for Red Hat customers to determine which content is the official certified, and importantly supported, content. This includes full content from partners such as Arista, Cisco, Checkpoint, F5, IBM, Microsoft and NetApp.
In this blog post we'll walk through a use case wherein, the user would like to use a Red Hat certified collection from Automation Hub Continue reading
Using Ansible Automation Platform, GitLab CE and Webhooks to Deploy IIS Website
Inside Red Hat Ansible Automation Platform, the Ansible Tower REST API is the key mechanism that helps enable automation to be integrated into processes or tools that exist in an environment. With Ansible Tower 3.6 we have brought direct integration with webhooks from GitHub and GitLab, including the enterprise on-premises versions. This means that changes in source control can trigger automation to apply changes to infrastructure configuration, deploy new services, reconfigure existing applications, and more. In this blog, I’ll run through a simple scenario and apply the new integrated webhook feature.
Environment
My environment consists of Ansible Tower (one component of Red Hat Ansible Automation Platform), GitLab CE with a project already created, and a code server running an IDE with the same git repository cloned. A single inventory exists on Ansible Tower with just one host, an instance of Windows 2019 Server running on a certified cloud. For this example, I’m going to deploy IIS on top of this Windows server and make some modifications to the html file that I’d like to serve from this site.
My playbook to deploy IIS is very simple:
---
- name: Configure IIS
hosts: windows
tasks:
- name: Install Continue readingAutomation Analytics – UX Enhancements
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.
Enhanced Filtering
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.
Announcement: Ansible Contributor Summit Europe
For the past few years we’ve held a conference specifically for contributors at the same time as AnsibleFest. The additional days brought together existing contributors to the open source Ansible code base and those wanting to get involved.
It is with great pleasure that we announce a European Contributor Summit will be held in Gothenburg, Sweden, ahead of the usual summit at AnsibleFest! On March 29 we’ll be welcoming new and old contributors alike. So if you already contribute to Ansible, or would like to, but don’t know how or where to start, this event is for you.
Contributor Summit US will again be held the day before this year’s AnsibleFest event in San Diego. You can sign up for AnsibleFest updates here.
Ansible Contributor Summit is a day-long working session with the core developer team and key contributors. We’ll discuss important issues affecting the Ansible community, and you can take part in person or online. Information for remote participation will be announced about a week beforehand. There is an additional hackathon the following day, on March 30, where you can sit down with fellow contributors to work through anything specific.
The event is free to attend, although registration is Continue reading
Intro to Automation Webhooks for Red Hat Ansible Automation Platform
If your organization has adopted DevOps culture, you're probably practicing some form of Infrastructures-as-Code (IaC) to manage and provision servers, storage, applications and networking using human-readable, and machine-consumable definitions and automation tools such as Ansible. It's also likely that Git is an essential in your DevOps toolchain, not only for the development of applications and services, but also in managing your infrastructure definitions.
With the release of Red Hat Ansible Tower v3.6, part of the Red Hat Ansible Automation Platform, we introduced Automation Webhooks that helps enable easier and more intuitive Git-centric workflows natively.
In this post we'll explore how you can make use of Automation Webhooks, but first let's look at IaC for some context and how this feature can be used to your organization's benefit.
Understanding Infrastructures-as-Code
Infrastructure-as-Code (IaC) is managing and provisioning computing resources through human-readable machine-consumable definition files, rather than physical hardware configuration or interactive configuration tools. It is considered one of the essential practices of DevOps along with continuous integration (CI), continuous delivery (CD), observability and others in order to automate development and operations processes and create a faster release cycle with higher quality. Treating infrastructure like it is code and subjecting Continue reading
Deep Dive on VLANS Resource Modules for Network Automation
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.
VLAN Example
Let's start with an example of the eos_vlans Continue reading
Agnostic Network Automation Examples with Ansible and Juniper NRE Labs
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.
About NRE Labs
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
How Useful Is Ansible in a Cloud-Native Kubernetes Environment?
A question I've been hearing a lot lately is "why are you still using Ansible in your Kubernetes projects?" Followed often by "what's the point of writing your book Ansible for Kubernetes when Ansible isn't really necessary once you start using Kubernetes?"
I spent a little time thinking about these questions, and the motivation behind them, and wanted to write a blog post addressing them, because it seems a lot of people may be confused about what Kubernetes does, what Ansible does, and why both are necessary technologies in a modern business migrating to a cloud-native technology stack (or even a fully cloud-native business).
One important caveat to mention upfront, and I quote directly from my book:
While Ansible can do almost everything for you, it may not be the right tool for every aspect of your infrastructure automation. Sometimes there are other tools which may more cleanly integrate with your application developers' workflows, or have better support from app vendors.
We should always guard against the golden hammer fallacy. No single infrastructure tool—not even the best Kubernetes-as-a-service platform—can fill the needs of an entire business's IT operation. If anything, we have seen an explosion of specialist tools Continue reading
How to Add Approval Steps to Ansible Tower Workflows
Suppose you have a workflow set up in Red Hat Ansible Tower with several steps and needed another user to view and approve some or all of the nodes in the workflow. Or maybe a job is running inside of a workflow but it should be viewed and approved within a specific time limit, or else get canceled automatically? Perhaps it would be useful to be able to see how a job failed before something like a cleanup task gets set off? It is now possible to insert a step in between any job template or workflow within that workflow in order to achieve these objectives.
Table of Contents
A New Feature for Better Oversight and More User Input
How to Add Approval Nodes to Workflows
What Happens When Something Needs Approval?
Approval-Specific Role-Based Access Controls
A New Feature for Better Oversight and More User Input
The Workflow Approval Node feature has been available in Ansible Tower since the release of version 3.6.0 on November 13, 2019. In order to visually compare the additional functionality, examine the before and after examples of a workflow Continue reading
Rebooting Network Devices with Ansible
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.
Table of Contents
Comparing wait_for and wait_for_connection
Using reset_connection in combination
Comparing wait_for and wait_for_connection
There are two great modules that can wait for a condition to be met, wait_for and the wait_for_connection. I highly recommend against using the pause module if you Continue reading
Ansible Content Collections: The Sensu Go Use Case
In Getting Started With Ansible Content Collections, which presented the general idea behind what is becoming a new standard in the distribution of Ansible content, we learned about the what, the why and the how of Ansible Collections (and hopefully it got you excited about Ansible Collections!). In this post, we'll take things a bit further, continuing the journey into the world of Ansible Collections accompanied by the certified Sensu Go Ansible Collection that our team at XLAB Steampunk developed and supports for Sensu.
What to expect?
This article will guide you through the process of creating a fully functioning automated deployment of the Sensu Go monitoring agent and backend with the help of roles and modules included in the Sensu Go Ansible Collection.
If you are not familiar with Sensu Go, this quick introduction to Sensu Go will help you get up to speed.
Before we begin, let's first talk about the collection we're taking along for the ride.
The Sensu Go Ansible Collection: the basics
What exactly do we need for a complete and fully functioning deployment of Sensu Go? First, the Sensu Go monitoring backend. Then, to allow the backend to Continue reading
Automation Analytics: Part 2 – Looking at Data Collection
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.
unified_job_template_table.csv
Retrieving the data:
Login to the Ansible Tower host with Continue reading
What’s New In Red Hat Ansible Tower 3.6
As part of the release of Red Hat Ansible Automation Platform, we’re happy to announce the release of Red Hat Ansible Tower 3.6. Ansible Tower is the scalable execution framework of the Ansible Automation Platform, providing an API around automation that you can use to scale automation across your enterprise and integrate automation into your tools and processes.
Workflow Pause and Approvals
Not all automation processes can proceed entirely without human input. In Ansible Tower 3.6, we’ve added pause and approval to Ansible Tower workflows to help enable more flexible automation. At any step in a workflow you can pause and wait for an approval from an administrator, or any other you delegate approval permissions to. Need to verify that your deployment was fully successful before updating the external DNS entries? Need to ensure that your developers won’t spin up 300 extra cloud servers when provisioning new dev environments? Now you can do that, integrated directly in Ansible Tower workflows.
Customizable Notifications
Notifications were introduced in Ansible Tower 3.0, allowing the status of any job to be reported out via email, Slack, IRC, and more. In Ansible Tower 3.6, we’ve made the content Continue reading
Manage Secrets and Protect Sensitive Data
Automation is an essential part of modern IT. In this blog I focus on Ansible credential plugins integration via Hashicorp Vault, an API addressable secrets engine which will make life easier for anyone wishing to handle secrets management and automation better. In order to automate effectively, modern systems require multiple secrets: certificates, database credentials, keys for external services, operating systems, networking. Understanding who is accessing secret credentials and when is difficult and often platform-specific and to manage key rotation, secure storage and detailed audit logging across a heterogeneous toolset is almost impossible. Red Hat Ansible Tower solves many of these issues on its own, but its integration with enterprise secret management solutions means it can utilize secrets on demand without human interaction.
In terms of secrets management, I will demonstrate how some of the risks associated with an automation service account can be mitigated by replacing password authentication with ssh certificate based authentication. In the context of automation, a service account is used to provide authorised access into endpoints from a central location. Best practices around security state that, shared accounts could pose a risk. While Red Hat Ansible Tower has the ability to obfuscate passwords, private keys, etc. Continue reading
Continuous Improvements in Ansible and Kubernetes Automation
Ansible is an ideal tool for managing many different types of Kubernetes resources. There are four key features that really help:
- Modules and plugins for creating, updating, removing and obtaining information about Kubernetes resources
- Templating of Kubernetes resource definitions
- Powerful inventory system
- Secrets management
Together these combine to help enable repeatable deployment and management of applications and multiple Kubernetes clusters in a single role for every resource.
Since the last blog post on Kubernetes features for Ansible Engine 2.6, there have been a number of improvements to Ansible's Kubernetes capabilities. Let’s go over some of the improvements to the modules and libraries and other new features that have been added in the last year, and also highlight what is in the works.
New features
Better change management through apply mode
The k8s module now accepts an apply parameter, which approximates the behavior of kubectl apply. When apply is set to True, the k8s module will store the last applied configuration in an annotation on the object. When the object already exists, instead of just sending the new manifest to the API server, the module will now do a 3-way merge, combining the existing cluster state, the Continue reading
Getting Started With Automation Analytics
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.
What you need to get started:
- Red Hat Ansible Tower 3.5.3 or newer
Ansible Automation Platform terminology
There are some terms used in this blog post that may be unfamiliar Continue reading
Getting Started With Ansible Hub
In the past, Ansible content such as roles, modules and plugins was usually consumed in two ways: the modules were part of the Ansible package, and roles could be found in Galaxy. However, as time went on the current method of content distribution had challenges with scale for both contributors and consumers of Ansible content. Dylan described this in a blog post worth reading.
Recent releases of Ansible started a journey towards better content management. In previous Ansible releases, each and every module was strictly tied to the release schedule of Ansible and community, customer, and partner feedback demonstrated that the release schedule of content needed to evolve. Ansible content collections allow our Ansible contributors to create specialized content without being tied to a specific release cycle of the Ansible product, making it easier to plan and deliver. For Ansible newcomers, the collections come “pre-packaged” with modules and playbooks around common use cases like networking and security, making it easier to get off the ground with Ansible. If you want to learn more about Ansible content collections, check out our series about collections!
The introduction of collections to the Ansible ecosystem solves a number of challenges for access to Continue reading
Getting Started With Ansible Content Collections
With the release of Red Hat Ansible Automation Platform, Ansible Content Collections are now fully supported. Ansible Content Collections, or collections, represent the new standard of distributing, maintaining and consuming automation. By combining multiple types of Ansible content (playbooks, roles, modules, and plugins), flexibility and scalability are greatly improved.
Who Benefits?
Everyone!
Traditionally, module creators have had to wait for their modules to be marked for inclusion in an upcoming Ansible release or had to add them to roles, which made consumption and management more difficult. By shipping modules within Ansible Content Collections along with pertinent roles and documentation, and removing the barrier to entry, creators are now able to move as fast as the demand for their creations. For a public cloud provider, this means new functionality of an existing service or a new service altogether, can be rolled out along with the ability to automate the new functionality.
For the automation consumer, this means that fresh content is continuously made available for consumption. Managing content in this manner also becomes easier as modules, plugins, roles, and docs are packaged and tagged with a collection version. Modules can be updated, renamed, improved upon; roles can be updated to Continue reading
Getting Started With Automation Hub
In the past, Ansible content such as roles, modules and plugins was usually consumed in two ways: the modules were part of the Ansible package, and roles could be found in Galaxy. However, as time went on the current method of content distribution had challenges with scale for both contributors and consumers of Ansible content. Dylan described this in a blog post worth reading.
Recent releases of Ansible started a journey towards better content management. In previous Ansible releases, each and every module was strictly tied to the release schedule of Ansible and community, customer, and partner feedback demonstrated that the release schedule of content needed to evolve. Ansible content collections allow our Ansible contributors to create specialized content without being tied to a specific release cycle of the Ansible product, making it easier to plan and deliver. For Ansible newcomers, the collections come “pre-packaged” with modules and playbooks around common use cases like networking and security, making it easier to get off the ground with Ansible. If you want to learn more about Ansible content collections, check out our series about collections!
The introduction of collections to the Ansible ecosystem solves a number of challenges for access to Continue reading
Network Features Coming Soon in Ansible Engine 2.9
The upcoming Red Hat Ansible Engine 2.9 release has some really exciting improvements, and the following blog highlights just a few of the notable additions. In typical Ansible fashion, development of Ansible Network enhancements are done in the open with the help of the community. You can follow along by watching the GitHub project board, as well as the roadmap for the Red Hat Ansible Engine 2.9 release via the Ansible Network wiki page.
As was recently announced, Red Hat Ansible Automation Platform now includes Ansible Tower, Ansible Engine, and all Ansible Network content. To date, many of the most popular network platforms are enabled via Ansible Modules. Here are just a few:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
A full list of the platforms that are fully supported by Red Hat via an Ansible Automation subscription can be found at the following location: https://docs.ansible.com/ansible/2.9/modules/network_maintained.html#network-supported
What we’ve learned
In the last four years we’ve learned a lot about developing a platform for network automation. We’ve also learned a lot about how users apply these platform artifacts as consumed in end-user Ansible Playbooks and Roles. In the Continue reading