Ansible 2.5: LAUNCH AN Azure CONTAINER INSTANCE
The Ansible 2.5 release includes an additional 13 Azure modules for automators to use in their hybrid cloud journey. We have a goal of making automation as accessible as possible. As part of this goal, we are working with technology partners to bring additional automation know-how to the Ansible blog.
Special thanks to Kylie Liang from the Microsoft Azure DevEx team for giving us a closer look at one of the new Azure module features.
---
Launch an Azure Container Instance
For this blog entry, we wanted to share a step by step guide to using the Azure Container Instance module that has been included in Ansible 2.5.
The Container Instance service is a PaaS offering on Azure that is designed to let users run containers without managing any of the underlying infrastructure. The Ansible Azure Container Instance module allows users to create, update and delete an Azure Container Instance.
Getting Started
For the purposes of this blog, we’ll assume that you are new to Azure and Ansible and want to automate the Container Instance service. This tutorial will guide you through automating the following steps:
- Install Ansible and Docker
- Set up credentials for your Azure modules
- Create an Continue reading
GETTING STARTED: ANSIBLE TOWER’S API
Welcome to another entry in the Getting Started series. The API (Application Programming Interface) or, as I like to refer to it, the Magical Land of Automation Information, can be used in quite a few ways. In this Getting Started post, we will be discussing Red Hat Ansible Tower’s API and how you can use it to extract information to utilize in your playbooks and other tools.
The idea for this blog post came about when David Federlein was developing a new Ansible Tower demo and presentation. I will be making references to that codebase, which you can follow along with throughout this post. Please note that this demo utilizes Vagrant and VirtualBox so you’ll need to have those applications installed if you would like to stand up the demo yourself.
Ansible Tower’s API
Ansible Tower’s API is fully browsable. You can navigate to your instance’s REST API by typing this into your browser: http://<Tower server name>/api/v2. Once there, you can click any of the listed links and view the current objects loaded for that particular attribute in Ansible Tower. Everything you can do in Ansible Tower's UI can be done from the API; you can also use it Continue reading
Infoblox Integration in Ansible 2.5
The Ansible 2.5 open source project release includes the following Infoblox Network Identity Operating System (NIOS) enablement:
- Five modules
- A lookup plugin (for querying Infoblox NIOS objects)
- A dynamic inventory script
For network professionals, this means that existing networking Ansible Playbooks can utilize existing Infoblox infrastructure for IP Address Management (IPAM), using Infoblox for tracking inventory and more. For more information on Infoblox terminology, documentation and examples, refer to the Infoblox website
Let’s elaborate on each of these Ansible 2.5 additions. All of the following examples (and many more) are provided in the network automation community project, under the infoblox_ansible Github repo. The integrations for Ansible require that the control node (where Ansible is being executed from) have the infoblox-client installed. It can be found here and installed with pip issuing the pip install infoblox-client command.
Ansible Infoblox Modules
There are five new modules included with Ansible 2.5. They can be currently found in the development branch of the documentation:
- nios_host_record - configure host records
- nios_network - configure networking objects
- nios_network_view - configure networking views
- nios_dns_view - configure DNS views
- nios_zone - configure DNS zones
Here is an example playbook on configuring a IPv4 network using the Continue reading
Ansible 2.5: Traveling space and time
Welcome to another Ansible release! Version 2.5–“Kashmir”–has a lot of great stuff to play around with, and we're excited to get it in your hands so you can try it out.
Some of the items in this release have been covered in depth in previous Feature Spotlights: AWS EC2 Dynamic inventory plugin, the new Loop keyword, and the all-new ec2_instance module. But those are just appetizers for all of the new things that are included in this release.
Fact Namespacing
In 2.5, we are introducing fact namespacing, which makes Ansible facts available under the ansible_facts namespace (i.e. ansible_facts.os_distribution) without the ansible_ prefix.
Facts will continue to be added into the main namespace directly, but there is now a configuration boolean to enable this. Today, it’s ”On” by default, in a future release, we’ll switch that to “Off”.
Module Blacklisting
We have added a configuration file that enables administrators to filter modules that should be excluded from being used in playbook runs. Operationally, this ensures administrators have more control over which Ansible Modules are approved for use.
New magic vars
Magic vars are variables that Ansible provides to playbook runs without having to be requested. Continue reading
GETTING STARTED: UPGRADING ANSIBLE TOWER
Thanks for checking out the Getting Started series! This quick tutorial lists the basic steps needed to perform an upgrade of Red Hat Ansible Tower in a standalone configuration. Specifically, we'll be upgrading Ansible Tower 3.1.0 to the latest (as of this writing) version 3.2.2 in a few simple steps. There are some things you’ll need to keep in mind while upgrading (e.g., editing the inventory file appropriately), and a description will be offered with each example.
Upgrading is Easy
The steps to upgrading are similar to installing Ansible Tower. The original inventory file from the install should already have the hostnames and variables you'll be using, so it's suggested that you work from your current install's inventory file to populate the upgrade file.
Your older inventory file may have some different lines than the newer upgrade version, due to updated configuration options or added features. In this example, the difference between the 3.1.0 and the 3.2.2 inventory files is the added ability to enable isolated key generation for clustered installs. See below for a side-by-side comparison:
| Ansible Tower 3.1.0 | Ansible Tower 3.2.2 |
| [tower] |
Getting Started with Ansible Tower
If you’re considering evaluating Red Hat Ansible Tower, you might also be curious about what sort of support is included with a trial key. This post will explain what sort of help is available while you conduct a PoC, along with information to assist you with errors and more.
Ansible Experts Are Here to Help
After you download a trial of Ansible Tower and request a license key, there is more than just documentation and reading materials to help guide you through errors. Once you and your team are connected with Ansible and want to start working on an evaluation or proof of concept installation, there are a boatload of resources to help you on your automation journey:
Sales Representatives: Provide support from day one, helping you understand what Ansible Engine and Ansible Tower can do for you and your environment.
Getting Started Team: The product field engineering team (known colloquially as the "Getting Started" team) helps with the installation, configuration and integration of Ansible Engine and Ansible Tower.
Solution Architects: For cases that delve into deeper understanding of all things Ansible Automation, writing playbooks, or consultation/screenshared demos to ensure success of the project, a Solutions Architect can save Continue reading
Ansible Tower Feature Spotlight: Instance Groups and Isolated Nodes
As we continue to improve Red Hat Ansible Tower, we’ve focused on allowing you to automate in more flexible ways, no matter your deployment scenario. As part of this, we’ve introduced two new features: Instance Groups and Isolated Nodes. These new features allow you to use Ansible Tower automation more flexibly in ways that match both the structure of your organization and your infrastructure.
Instance Groups
What is an instance group?
Ansible introduced Clusters in Ansible Tower 3.1. Tower Clusters allow you to add capacity to your Ansible Tower environment - the more nodes in your Tower Cluster, the more job execution capacity you have. If you have to run many jobs simultaneously, adding more nodes to the cluster lets you run them all without queueing.
However, this just gives you an additional mass of capacity. If you just have one group using a Tower instance, that may be enough. But we know that many Ansible Tower instances are shared among teams, groups, and organizations that may have different uses for their automation.
That’s why, in Ansible Tower 3.2, we created Instance Groups.
An Ansible Tower Instance group is a set of cluster nodes dedicated for a particular purpose. Continue reading
Getting Started: Using New Kerberos Feature in Ansible Tower
Welcome to another post in our Getting Started series. In our previous post, we discussed how you can set up and use LDAP in your Red Hat Ansible Tower instance. In this post we are going to discuss a new feature in regard to Windows authentication with Kerberos. Before we get started, please note that these changes will not affect the current configuration you are using if you have previously used Kerberos with Ansible Tower. Your setup should function the same way as before.
Using Kerberos to Connect to Windows
Using Kerberos with Ansible and Ansible Tower to connect to your Windows hosts before the release of Ansible 2.3 required some prior scaffolding tasks be set up before you were able to fully use it. The necessary packages for Kerberos are still required to be on the machine that Ansible Tower is installed on. The documentation on the required materials and configuration changes can be found here if you are just starting out or need a refresher.
The main change that comes to using Kerberos with Ansible and Ansble Tower is how Ansible manages Kerberos “tokens” or “tickets." Ansible Tower defaults to automatically managing Kerberos tickets (as Continue reading
Loop: Plays in the future, items in the past
Welcome to another episode of Feature Spotlight. In today's post, we'll quickly cover the loop keyword being introduced in Ansible 2.5.
Everyone knows the with_* syntax in playbooks.
For example:
- name: Test that with_list works with a list
ping:
data: ''
with_list:
- 'Hello World'
- 'Olá Mundo'In Ansible 2.5, we're introducing loop as a shorter, simpler keyword for playbooks.
Example:
- name: Test that loop works with a manual list
ping:
data: ''
loop:
- 'Hello World'
- 'Olá Mundo'
It's a very minute change, and can easily be overlooked when skimming a playbook! However, when writing many lines of tasks in a playbook, why not save some potential muscle fatigue?
Let's be real, even if a playbook accomplishes a whole lot in 10 lines, that's still ten lines!
All joking aside, we wanted to make things simpler. It's much easier to remember loop than with_items or with_list.
The question after this very well may be, "What happens to with_first_found or with_dict or .... etc, etc, etc?
Well the idea here is to abstract out some of the magic that with_* really is.
Example:
- name: Test that loop works with a list via the list Continue readingComing Soon: Networking Features in Ansible 2.5
The upcoming Ansible 2.5 open source project release has some really exciting improvements, and the following blog highlights just a few of the notable additions. In typical Ansible fashion, development of networking enhancements is done in the open with the help of the community. You can follow along by watching the networking GitHub project board, as well as the roadmap for Ansible 2.5 via the networking wiki page.
A few highlighted features include:
New Connection Types: network_cli and NETCONF
Continued Enablement for Declarative Intent
Persistent SSH Connection Improvements
Additional Platforms and Modules
Let's dive into each of these topics and elaborate on what they mean for your Ansible Playbooks!
New Connection Types: network_cli and NETCONF
Prior to Ansible 2.5, using networking modules required the connection type to be set to local. A playbook executed the python module locally, and then connected to a networking platform to perform tasks. This was sufficient, but different than how most non-networking Ansible modules functioned. In general, most Ansible modules are executed on the remote host, compared to being executed locally on the Ansible control node. Although many networking platforms can execute Python code, the vast Continue reading
ANSIBLE COMMUNITY – 2017 YEAR IN REVIEW
It's time again for the annual Ansible community review. Let's start again, as we do every year, with a quick look at the numbers.
Debian Popcon
Debian’s Popularity Contest is an opt-in way for Debian users to share information about the software they’re running on their systems.
As with every year, caveats abound with this graph -- but even though it represents only a small sample of the Linux distro world, it’s useful because it’s one of the few places where we can see an apples-to-apples comparison of install bases of various automation tools. Because Ansible is agentless, we compare the Ansible package to the server packages of other configuration management tools. (Chef does not make a Debian package available for Chef server.)
We see that Ansible has continued its steady growth in 2017, increasing its user base here by approximately 50% in the past year.
GitHub Metrics
2017 was a busy year for Ansible on the GitHub front, and in 2017 we caught the notice of GitHub itself. Ansible now has its own top level topic for GitHub searches, and that search reveals over 5000 repositories of Ansible content. We also made the 2017 GitHub Octoverse report, placing Continue reading
Using Ansible to manage RHEL 5 yesterday, today and tomorrow
With the release of Ansible 2.4, we now require that managed nodes have a Python version of at least 2.6. Most notable, this leaves RHEL 5 users asking how to manage RHEL 5 systems in the future - since it only provides Python 2.4.
Background
With the release of Ansible 2.4 in September 2017, we have moved to support Python 2.6 or higher on the managed nodes. This means previous support for Python-2.4 or Python-2.5 is no longer available:
Support for Python-2.4 and Python-2.5 on the managed system's side was dropped. If you need to manage a system that ships with Python-2.4 or Python-2.5, you'll need to install Python-2.6 or better on the managed system.
This was bound to happen at some point in time because Python 2.6 was released almost 10 years ago, and most systems in production these days are based upon 2.6 or newer version. Furthermore, Python 3 is getting more and more traction, and in the long term we need to be able to support it. However, as the official Python documentation shows, code that runs on both Python 2. Continue reading
Getting Started: LDAP Authentication in Ansible Tower
Next in the Getting Started series is covering the basics of configuring Red Hat Ansible Tower to allow users to log in with LDAP credentials. In this post, we'll explain a few troubleshooting tips to help narrow down problems and correct them. As long as you have a map of your LDAP tree/forest, this post should help get users logging in with their LDAP credentials.
CONFIGURATION SETTINGS
To configure your Ansible Tower for LDAP authentication, navigate to Settings (the gear icon) and to the "Configure Tower" section. The area within these configuration settings we're focusing on is "Authentication", and the sub category should be set to "LDAP".
The fields that will be the primary focus are:
- LDAP server URI
- Bind DN and password
- User/group searches
The other fields will allow you to refine your LDAP searches to reduce the resources used in production or map your organization.
The LDAP URI is simply the IP or hostname of your LDAP server prepended with the protocol (ldap://).
The bind DN will be a user credential and password (followed by the group and domain) with access to read the LDAP structure.
REFINING USER SEARCH
With Ansible Tower able to connect to the LDAP Continue reading
Dynamic Inventory: Past, Present & Future
In Red Hat Ansible Engine 2.4, we made some changes to how inventory works. We introduced a new cli tool, and added an inventory plugin type.
The goal of this plugin type, was well, to make Ansible Engine even more pluggable. All kidding aside, we wanted to provide Ansible Engine content authors and Ansible Engine users a new way to visualize their target inventory. Using the ansible-inventory command, the targeted inventory will be listed with the details of the hosts in that inventory, and the hosts groups.
For example:
[thaumos@ecb51a545078 /]# ansible-inventory -i ~/Development/playbooks/inventory/prod.aws_ec2.yml --list
{
"_meta": {
"hostvars": {
"ec2-5x-xx-x-xxx.us-west-2.compute.amazonaws.com": {
"AmiLaunchIndex": 2,
"Architecture": "x86_64",
"BlockDeviceMappings": [
{
"DeviceName": "/dev/sda1",
"Ebs": {
"AttachTime": "2017-12-13T15:40:19+00:00",
"DeleteOnTermination": false,
"Status": "attached",
"VolumeId": "vol-0514xxx"
}
}
],
"ClientToken": "",
"EbsOptimized": false,
"Hypervisor": "xen",
"ImageId": "ami-0c2aba6c",
"InstanceId": "i-009xxxx3",
"InstanceType": "t2.micro",
"KeyName": "blogKey",
"LaunchTime": "2017-12-13T15:40:18+00:00",
"Monitoring": {
"State": "disabled"
},
"NetworkInterfaces": [
{
"Association": {
"IpOwnerId": "amazon",
"PublicDnsName": "ec2-5x-xx-x-xxx.us-west-2.compute.amazonaws.com",
"PublicIp": "5x.xx.x.xxx"
},
"Attachment": {
"AttachTime": "2017-12-13T15:40:18+00:00",
"AttachmentId": "eni-attach-97c4xxxx",
"DeleteOnTermination": true,
"DeviceIndex": 0,
"Status": "attached"
},
"Description": "",
"Groups": [
{
"GroupId": "sg-e63xxxxd",
"GroupName": "blogGroup"
}
],
"Ipv6Addresses": Continue readingMeltdown, Spectre and Security Automation
Keeping computer systems secure is one of those never ending tasks. You could be forgiven for thinking of it like "Painting the Forth Bridge". Most of the time it's 'put new software' in place, and you're good. Every now and then it’s, well, a bit more complicated.
The first week of January saw two flaws announced, called “Meltdown” and “Spectre.” Both involved the hardware at the heart of more or less every computing device on the planet – the processor. There is a great in-depth review of the two flaws here. You can also find some additional information in this blog by Red Hatter Jon Masters.
In the complex world of IT, keeping on top of security can be less painful with the help of an easy automation tool. One of our Ansible engineers, Sam Doran, has written a couple of Ansible plays to patch systems. While Meltdown and Spectre are not completely mitigated, we'd like to share these plays with you to demonstrate how to easily deploy the patches that are available; you can find them here:
If you make any improvements to them we'd welcome pull requests!
Getting Started: Adding Proxy Support
Getting Started with Adding Proxy Support
There are many reasons why proxies are implemented into an environment. Some can be put in place for security, others as load balancers for your systems. No matter the use, if you have a proxy in place, Red Hat Ansible Tower may need to utilize it. For a more in-depth look at what we will be doing in this post, you can visit our docs specifically on Proxy Support within Ansible Tower here.
Adding a Load Balancer (Reverse Proxy)
In some instances, you might have Ansible Tower behind a load balancer and need that information added to your instance. Sessions in Ansible Tower associate an IP address upon creation, and Ansible Tower’s policy requires that any use of the session match the original IP address.
To allow for support of a proxy, you will have to make a few changes to your Ansible Tower configuration. Previously, this would have been done in a settings.py file found on your Ansible Tower host, but as of 3.2 you can now make these changes in the UI. To make these edits, you must be an admin on the instance and navigate to Settings, and then Continue reading
Ansible Tower Feature Spotlight: Custom Credentials
One of the new features we added in Red Hat Ansible Tower 3.2 was support for custom credentials. The idea of custom credentials is pretty simple. In addition to the built-in credentials supported by Ansible Tower such as SSH keys, username/password combos, or cloud provider credentials, we now let the user define their own credentials for storing securely in Ansible Tower and exposing to playbooks.
However, this simplicity belies real power, opening up many new ways to automate. Let's dive into the details.
HOW CUSTOM CREDENTIALS WORK
To set up a custom credential, first you must define the custom credential Type.
Credential types consist of two key concepts - "inputs" and "injectors".
Inputs define the value types that are used for this credential - such as a username, a password, a token, or any other identifier that's part of the credential.
Injectors describe how these credentials are exposed for Ansible to use - this can be Ansible extra variables, environment variables, or templated file content.
Once you've defined a new Credential Type, you can then create any number of credentials that use that type. We'll go through examples to shed light on how this Continue reading
Accelerate Network Automation with Aggregate Resources
One of the major networking features in Red Hat Ansible Engine 2.4 was the addition of aggregate resources to the networking modules. The Ansible networking team recently talked about this at the Ask an Expert webinar in November.
What are Aggregate Resources?
Simply put, aggregate resources are a better way to iterate (or loop) without the need to execute each task one by one. That is, you can now “aggregate” a collection as a single task instead of a collection of discrete loops.
Loop Method
Aggregate Method
| Loop Method (with_items:) |
Aggregate Method (aggregate:) |
|---|---|
|
|
| 503 steps |
4 steps |
Based on feedback from customers, partners and community members, this post provides more examples and more detail of this important new feature. The simplest way to showcase this is to compare the old way and the new way, and highlight the differences Continue reading
Our Most Popular Blog Posts of 2017
2017 was such a great year for the Ansible team at Red Hat. From launching Ansible Engine to open sourcing Ansible Tower, we’ve had a year to remember. And just in case you missed them, here are our 10 most viewed blog posts of the year to showcase all the fun we’ve had.
1. How to Extend Ansible Through Plugins
Did you know a large portion of Ansible’s functionality comes from the Ansible plugin system? These important pieces of code augment Ansible’s core functionality such as parsing and loading inventory and Playbooks, running Playbooks and reading the results. In this blog, we review each of these plugins and offer a high-level overview on how to write your own plugin to extend Ansible functionality. Read more.
2. Exploring New Networking Features in Ansible 2.3
In 2016, we added the first networking modules to Ansible, since then we’ve added hundreds of modules and many networking vendor platforms have been enabled. This year, our focus on networking enablement turned to increasing performance and adding connection methods that provide compatibility and flexibility. You were eager to learn all about it and made this our second most read blog of the year! Read more.
Continue reading
Using two-factor SAML with Ansible Tower
In a previous post, I explained how Red Hat Ansible Tower works with SAML. A little known fact about Ansible Tower is that it supports two-factor SAML. More precisely, Ansible Tower can be configured to not disallow SAML with two-factor. Ansible Tower relies heavily on django-social-auth, which comes with a SAML backend, which relies heavily on python-saml. python-saml contains a default setting, specifically requestedAuthnContext, that, put simply, requests that the idp authenticate the user using a password. To reiterate, Ansible Tower will ask for the user to be authenticated by a password and not be given the choice to authenticate the user by two-factor.
In order to allow the IDP to choose two-factor, we need to not ask it to authenticate using password. More specifically, we need to not include the samlp:RequestedAuthnContext directive at all. Ansible Tower shouldn’t be making the presumption about the IDP’s authentication methods on the other side. Maybe the IDP supports calling the employee on the phone to authenticate. This is a decision that should be made by the IDP.
Let’s see how we make this happen. Create the file /etc/tower/conf.d/saml.py with the following content:
"SOCIAL_AUTH_SAML_SECURITY_CONFIG": {
"requestedAuthnContext": False
}
Then issue Continue reading