<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

Isos at Ansible Automates DC

Ansible, DevOps

by Carlos Vasquez

Isos recently attended the Ansible conference hosted by Red Hat at Nationals Park in Washington DC.  The topics covered during the seven talks ranged widely from general business reasons, to culture and different problems Ansible helped solve.  Here were 3 interesting takeaways.

Automation is the Top Priority

Every year Red Hat performs a study ranking organizational priorities. While automation has made the list for many years, this year for the first time it was the number one priority above things like the cloud and security. This is because when automation is shown to provide a 146% Return on Investment in less than 3 months, the numbers simply can't be ignored. On top of that, automation has been shown to provide a 94% reduction in recovery time after a security incident and a 67% reduction in man-hours.

But what if you fear being replaced? Resistance is futile and you must learn to adapt. While you might be thinking this is a situation identical to how robots have replaced workers, it's not. But what if you're slammed and don't have the time to learn it? Ironically, automation will give you back time.  But what if you are convinced that your current project is too complex to be automated? One use case given was the automation of a monster of an application that required the coordinated effort of 100 people and 8 hours to take down, with every step being manual. Could there be a more extreme example?

For better or worse, automation is here to stay and if you're already doing it, expect to be asked to do more.  And if you aren't, there's a good chance you're going to be.

Expanding Automation Boundaries to Security

Ansible has spun out from the early days of Linux server configuration to Windows and the cloud. It has since become the standard for network automation and is seeing a growth in the use of containers and the Internet of Things.  On a daily basis, the team at Red Hat works to figure out how users and customers use Ansible to meet users where they're at with new solutions to help solve more problems faster.

One new area of focus is security automation, a different issue from the long solved problem of reeling servers back to the state dictated by security policies. Instead, it's about taking a more proactive versus reactive stance on security issues that arise.  It looks at things like rolling out security patches for new vulnerabilities or healing a compromised environment in a repeatable, reliable, and trusted way.  This isn't an effort in reinventing the wheel, but instead acknowledging that there are many great security tools out there and brainstorming, then, how to best unite and incorporate these tools into the current Ansible workflows.

Parsing Standard Output with the Ansible Network Engine

Sometimes there's a use case that requires the ability to parse command line output to use as input for further actions such as in closed-loop, self-healing, reactive automated systems.  One case in particular would be the standard output spat out by routers and switches and even Linux commands.  How do you go about extracting meaningful bits from that output that Ansible can then feed into other plays? To solve this problem custom parsers can be written using the Ansible Network Engine role.

While there are other solutions currently available such as TextFSM, the command line parser provided by the network engine is written in YAML instead of a Domain Specific Language.  TextFSM templates are supported, however.  After feeding the command to run and some regex patterns to the parser, the output is converted into key/value pairs that can then be passed around to other modules.

TAGS: Ansible, DevOps

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts