Ansible 2.5: Traveling space and time

March 23, 2018 by Dylan Silva

Ansible-2-5-Blog-HeaderWelcome 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. In 2.5, we’ve added a handful of new magic variables have been added and can now used in your playbooks.

  • ansible_inventory_sources: Display current inventory sources being used
  • ansible_limit: Display current limit value for run
  • ansible_run_tags: Display current tags “activated” in run
  • ansible_forks: Display number of forks for run
  • ansible_skip_tags: Display skip_tags applied for run

Windows

To ease the privilege escalation on Windows systems, we’ve expanded become capabilities to include:

  • Support to become NT AUTHORITY\System, NT AUTHORITY\LocalService, and NT AUTHORITY\NetworkService
  • Updated become to work with async on Windows hosts
  • Improved become elevation process to work on standard Administrator users without first disabling UAC on Windows hosts

Cloud

Cloud deployments and automation remains a key strategic area of focus. Ansible 2.5 continues this trend, and adds significant new capabilities for cloud provisioning, ongoing day 2 management, and integrations that help enable hybrid cloud management.

Amazon Web Services (AWS)

We’re continuing our AWS leadership with a handful of new community modules. As I mentioned in my earlier webinar, we’re effectively deprecating the previous ec2 module in favor of a brand-new ec2_instance module. Beyond that, there are a few others coming in this release:

We are also introducing a new EC2 dynamic inventory plugin These inventory plugins have the ability to utilize the newly released Ansible inventory plugin system.

Microsoft Azure

Our friends at Microsoft have been diligent in adding new Azure modules and capabilities in each release. Updates and additions include:

Google Cloud (GCP)

Ansible 2.5 includes the gcp_dns_managed_zone module provided by our Partners at Google.
And in an interesting side-note, this module is one of the first being provided by Google using their module auto-generation tooling that automatically creates GCP modules. We reviewed this tool with the google team, and are confident that it does a great job creating modules in a manner that makes sense; rather than just mirroring an API.

VMware

In the past few months, Red Hat Engineering, coupled with the Ansible community, have established Working Groups in specific areas. One of these new areas of focus is centered around growing Ansible’s VMware automation capabilities. As such, quite a bit of content is available this release:

With the Ansible 2.5 release, we’re also formally announcing the deprecation of the existing vsphere_guest module. This module has been around for quite some time, and as such is a little long in the tooth. The good news: now is the time to start transitioning your playbooks to use the newly refactored VMware modules. 

New Plugins:

In my opinion, Ansible Plugins are one of the most under-appreciated capabilities of our platform. We continue to add capabilities here to enable you to easily pull in external data to playbook runs, alter callback functions, and change the connection type for certain environments (i.e. Networks).

Lookups

  • aws_ssm: Query AWS ssm data
  • aws_account_attribute: Query AWS account attributes such as EC2-Classic availability
  • config: Lookup Ansible settings
  • openshift: Return info from Openshift installation
  • redis: Look up date from Redis DB, deprecates the redis_kv one

Callbacks

  • yaml: Ansible output that can be quite a bit easier to read than the default JSON formatting

Connections

While technically not new plugins, these connection plugins can now be used directly with network-specific modules. 

  • network_cli: Provides a connection to remote devices over the SSH and implements a CLI shell.
  • netconf: Provides a connection to remote devices over the SSH NETCONF subsystem

While neither is technically a new plugin, these connections may now be used directly with network modules. See Network Best Practices for Ansible 2.5 for more details. And read more about the latest networking updates in our Ansible 2.5 Networking features blog post.

Filters

  • parse_xml: Convert the XML output of a network device command into structured JSON output
     

SUMMARY

Of course, this was just a quick summary of some of the great content that’s in Ansible 2.5. For  the entire documentation check out our Ansible 2.5 docs page. If you want to learn more about the details, check out the changelog for the full list of updates in 2.5.

Do you already have a bunch of Ansible content, and want details on deprecated modules and other content? Check out the Porting guide for full details, and what steps to take to mitigate any potential issues in your playbooks.

Want to get involved? Reach out to us on Freenode in #ansible, or on the Ansible project list.

Want support for your Ansible installation? 

Check out Ansible Engine, and re-use all of your existing playbooks and Roles, but now, with support. Do you want to better manage your Ansible at scale in your organization? Try Ansible Tower.

Share:

Topics:
Ansible Automation


 

Dylan Silva

Dylan is a Principal Product Manager, Ansible, Red Hat. Starting as an early Core community member in Ansible's early days, Dylan now manages product roadmap for Ansible Core. He’s a self-proclaimed Linux and OSS diehard, Internet geek, and father to #Ansipup Honey. You can follow him on twitter and GitHub at @Thaumos.


rss-icon  RSS Feed

Ansible Tower by Red Hat
Ansible Fest Austin 2018
Learn About Ansible Tower