Happy Automating to All!
We're pretty busy working on features and updates during the year, but we wanted to have a little fun with playbooks again this holiday season. Last year we created the festive playbook and this year we're celebratating with "naughty or nice" cow-back output plugins. If your playbook completes successfully you'll be greeted by this friendly holiday cow...
But if your playbook fails...it just might get a visit from Krampus!
The "nice" plugin can be found here and the "naughty" plugin can be found here. Special thanks to our Senior Engineering Manager James Laska for the "nice" callback plugin!
We wish you many successful playbooks this season and happy automating to all!
Tweet #HappyAutomating
Getting Started: Setting Up A Job Template
Welcome to another post in our Getting Started series. In our previous post, we discussed the basic structure of how you can write your first playbook.
In this post, we will discuss how to set up job templates and run them against your inventory. We will also discuss job output and how you can view previous job runs to compare and contrast successful/failed runs.
Before we get started, a gentle reminder that in order to run job templates successfully in Red Hat® Ansible® Tower, you will need to have an inventory present, an updated project to select a playbook from to run against and up-to-date credentials.
Job Templates: What Are They?
Job templates are a definition and set of parameters for running an Ansible Playbook. In Ansible Tower, job templates are a visual realization of the ansible-playbook command and all flags you can utilize when executing from the command line. A job template defines the combination of a playbook from a project, an inventory, a credential and any other Ansible parameters required to run.
When you run playbooks from the command line you use arguments to control and direct it. Whether you're invoking an inventory file Continue reading
Using SAML with Ansible Tower
This blog post focuses on getting Red Hat Ansible Tower to use SAML as quick as possible. We will use the free OneLogin SAML provider service. Users with an existing SAML service may still find this blog post useful; especially the last section with some troublehooting tips.
Getting Ansible Tower to interoperate with OneLogin SAML requires both systems to have values from each other. This blog post is separated into three sections: the interdependent fields of the two systems, a detailed walkthrough of configuring OneLogin and Ansible Tower with both interdependent and per-system fields and values, and the troubleshooting of potential misconfigurations and corresponding error messages in Ansible Tower.
Interdependence of Ansible Tower and OneLogin
Defined in Ansible Tower, needed by OneLogin:
- ACS URL
- Entity ID
Defined in OneLogin, needed by Ansible Tower:
- Issuer URL
- SAML 2.0 Endpoint (HTTP)
- X.509 Certificate
Ansible Tower and OneLogin Definitions
| Ansible Tower |
OneLogin |
|---|---|
| SAML ASSERTION CONSUMER SERVICE (ACS) URL |
ACS (Consumer) URL |
| SAML SERVICE PROVIDER ENTITY ID |
Audience |
| SAML ENABLED IDENTITY PROVIDERS (python dictionary where entity_id is the “magic” key) |
Issuer URL |
| SAML ENABLED IDENTITY PROVIDERS (python dictionary where url is the “magic” key) |
SAML 2.0 Endpoint (HTTP) |
| SAML ENABLED IDENTITY Continue reading |
OpenShift Ansible Broker: Available Now
Our Red Hat colleagues over on the OpenShift Container Platform team have announced the general availability of OpenShift Ansible Broker, which is a new way to easily orchestrate things external to an OpenShift-deployed containerized application by using Ansible automation. But just what is the OpenShift Ansible Broker, and how does it fit into the wider Ansible ecosystem?
At the simplest level, the Red Hat OpenShift team has given users a way to expose Ansible workloads in the OpenShift Container Platform Service Catalog via the Open Service Broker API.
If you haven’t already, we’d recommend you read What’s new in OpenShift 3.7 as this has a good explanation of the concepts and motivation behind the work.
This is a fantastic development that places Ansible in a prime position within the OpenShift Container Platform Service Broker and great news for the continued journey for Ansible as Red Hat’s language of automation. It extends the current capabilities of Red Hat OpenShift Container Platform with Ansible’s simple, powerful, and agentless capability, making the journey to hybrid cloud easier. There are some best practices about how you can use this new capability to achieve maximum benefit, and we’d like to discuss that here.
Automation Field Guide: Quick AWS NextCloud Instance
This is a practical use story utilizing Ansible to solve a small hurdle in an everyday workflow.
Code for this can be found here.
In this post, I’ll be sharing a practical situation where Ansible makes tasks easier. The Getting Started team works with organizations who may be putting together a proof-of-concept to evaluate Red Hat® Ansible® Tower. If troubleshooting gets into the weeds, it can include sharing documentation, instructions for common setup scenarios, or going through system settings to make sure everything’s in order.
Sometimes there's no other way: we need to get a full environment report from the system to troubleshoot, mostly in the form of a sosreport. We found that getting the report to us can be challenging, so we had to find a reliable way for people to send us their log files. A file drop web app that could be spun up on demand fit the need nicely. A Nextcloud install with a CentOS LAMP stack turned out to be a great tool, using Ansible to automate the provisioning and installation for us. Because this little trick proved so helpful, I wanted to share how I put the short playbook together, Continue reading
5 Things You Can Do With AWX
As you’ve probably already heard, Red Hat announced the release of the AWX project at AnsibleFest in San Francisco. AWX is the open source project behind Red Hat® Ansible® Tower, offering developers access to the latest features, and the opportunity to directly collaborate with the Ansible Tower engineering team.
AWX is built to run on top of the Ansible project, enhancing the already powerful automation engine. AWX adds a web-based user interface, job scheduling, inventory management, reporting, workflow automation, credential sharing, and tooling to enable delegation.
Even if you’re only managing a small infrastructure, here are 5 things you can do with AWX. And we promise, they’ll make your job as a system administrator a whole lot easier:
Delegate
Central to AWX is the ability to create users, and group them into teams. You can then assign access and rules to inventory, credentials, and playbooks at an individual level or team level. This makes it possible to setup push-button access to complex automation, and control who can use it, and where they can run it.
For example, when developers need to stand up a new environment, they don’t need to add another task to your already overbooked Continue reading
8 Use Cases for Modernizing and Automating Workflows
Managing an organization’s many tools and business processes is becoming increasingly complicated as technology expands. Whether your teams are performing their weekly system reboot, or looking to configure instances to a desired state, it’s no secret that automation is critical to increase speed, efficiency, productivity, and accuracy. Listed below are several instances1 where automation can help across your enterprise.
- Weekly system reboot: There’s nothing worse than doing the same thing for 8 hours a day! Eliminate repetitive, manual processes with automation.
- Enforce security guidelines: Rules are rules. It’s best to automate in an effort to achieve strict security standards.
- Monitor configuration drift: Use check mode with Ansible tasks to enforce desired settings and see if your configuration has drifted.
- Disaster recovery: Disaster recovery can involve a wide range of components. Act across different variables of the technology stack to identify problems and eliminate cross team dependencies.
- Command blaster: Remarkably easy to write, you can run commands across your environment for any number of servers.
- Database binary patching: Several databases use outdated binary sets. Patch the binaries in accordance with the release of the latest patch.
- Instance provisioning: Use modules for several cloud providers to create new instances and tailor Continue reading
Fumbling Through Networking
This blog post is written by a systems person who has always dodged networking ... until now. I gave Ansible networking modules a try with a vyos Vagrant image. This blog describes how I fumbled through the process of writing my first Ansible playbook to successfully gather facts from a running vyos virtual machine.
First things first, I need a network thingy to run commands on. I don’t have a physical networking thingy so let’s go searching for a virtual one. After some googling for a Cisco IOS virtual machine I found and started to download an ISO. While that was going on I pinged my co-worker Ben on Slack. Ben’s a networking guy within Ansible. I asked him what virtual device he uses. He pointed me at a vyos Vagrant image. So I canceled the Cisco IOS ISO download and ran the needed vagrant commands.
vagrant init higebu/vyos
vagrant up
Ok, that did something but what did it do? Let me try the old vagrant ssh. Nope, that didn’t work. Oh, I got another message from Ben on slack. He mentions I’m going to need a plugin to make this work smoothly with Vagrant and to run:
vagrant plugin install Continue readingAnsible Tower 3.2: Available Now
We're happy to announce that Red Hat Ansible Tower 3.2 is now generally available.
With Red Hat® Ansible® Tower 3.2, we're working to make sure you can automate more flexibly, and manage more globally across your enterprise. For more information:
- Check out the Ansible Tower 3.2 documentation
- See our Deep Dive into Ansible Tower 3.2
- Join us for our What’s New in Ansible Tower 3.2 Webinar on Tuesday, Oct 10th at 2PM EDT
Go get it now via local install, Vagrant, or Amazon AMI. Ansible Tower 3.2 is available for Red Hat Enterprise Linux 7, CentOS 7, Ubuntu 14.04, and Ubuntu 16.04. If you have any questions, or run into any issues, don't hesitate to contact us via the Red Hat Customer Portal.
Faster Builds with Ansible Container 0.9.2
The focus for the latest release of Ansible Container is on making builds faster through the availability of pre-baked Conductor images. The release landed this week thanks to the dedication of Joshua ‘jag’ Ginsberg, Ansible’s Chief Architect, who managed to put the finishing touches on the release while at AnsibleFest San Francisco.
The Ansible Container project is dedicated to helping Ansible users re-use existing Ansible roles and playbooks to build containers, and deploy applications to OpenShift. The Conductor container is at the center of building, orchestrating, and deploying containers. It’s the engine that makes it all work, and it brings with it a copy of Ansible, a Python runtime, docker packages, and other dependencies.
The first step, before any serious work gets done by the command line tool, is standing up a Conductor container. And up until now, that meant building the image from scratch, and waiting through all the package downloading and installing. This happens at the start of a project, and repeats anytime you find yourself needing to rebuild from scratch.
With this release, the team has made available a set of pre-baked images based on several distributions that are popular within the community. These images are currently Continue reading
ANSIBLE + MICROSOFT AZURE NEWS
The Azure and Ansible teams are collaborating on several interesting projects that we want to share. And if you joined us for AnsibleFest San Francisco earlier this month, you met both teams and heard some of the news. More on that below.
MS Ignite 2017
If you use Ansible to manage Azure and Windows environments, then hopefully you can join us at Microsoft Ignite this week in Orlando.
Ansible’s Matt Davis will co-present with Microsoft’s Hari Jayaraman, to discuss popular DevOps tools customers use to implement infrastructure as code processes in Azure. And the Ansible team will be in the Red Hat booth (#527) to demo automating Azure environments or any other questions you may have.
Session Info:
Infrastructure as Code
Friday, September 29
10:15 AM - 11:00 AM
Hyatt Regency Windermere W
New Azure Modules in 2.4
One of the many announcements at AnsibleFest included the 16 new Azure modules contributed by the Azure team. The focus of the team was to cover the base use cases for Ansible users running workloads at scale in Azure.
New modules were added to manage Azure services:
- Availability sets
- Scale sets
- Authentication (ACS)
- Functions
- DNS
- Load Balancer
- Managed Disks
VMC Launches with Ansible Modules for Provisioning and Management
With the recent announcement of VMware Cloud on AWS (VMC) availability and pricing, the first question the Ansible team received was, “Will the vmware_guest modules work with cloud?”
Before we answer that question, let’s take a step back and look at why teams use Ansible to provision and manage VMware environments. VMware offers several automation tools that work well within the VMware ecosystems - so why Ansible?
What if you want to share automation across VMware and non-VMware infrastructure?
Enter Ansible. Ansible allows organizations to standardize on a simple IT automation language, regardless of technology, vendor or functional area.
- VMware -
- Cloud -
- Windows -
- Linux -
- Networking -
- Etc.
The Ansible VMware page does a good job of covering the key points if you want more detail.
VMC Launch
The good news is - yes - the Ansible VMware modules work with VMC out of the box.
VMC was announced as a hybrid cloud solution for VMware customers who want to leverage tools and skills that already exist in the organization. Using Ansible to provision VMs in on-premise (vSphere) and cloud (VMC) environments works in exactly the same manner.
This is the way you would expect the Ansible modules Continue reading
Red Hat Ansible Automation: Engine, Tower or Both
Whether you’re a seasoned veteran of Ansible, or just starting out, the following blog provides experts and newbies with an update to the Red Hat Ansible Automation portfolio of products from Red Hat. You may have seen the official press release, and this blog hopes to answer some of the questions you still have.
Built on open source, backed by Red Hat
The Ansible project is one of the most popular open source projects, with almost 3,000 contributors in just over five years of existence. The Ansible project has always been an important part of the Ansible Tower “built-for-enterprise” story, but over the past few years a pattern has begun to emerge.
The Ansible project has grown over time, moving from just managing Linux servers to managing different types of devices: servers, virtual machines, containers, networking hardware, Windows platforms… even smart light bulbs. With the breadth of abilities to automate highly heterogeneous environments we received more requests for additional Red Hat offerings for diverse automation use cases. Red Hat Ansible Engine is now available for individuals and small teams to receive support for their Ansible environment, even if they do not need enterprise scalability via Ansible Tower.
Red Hat Continue reading
Deep Dive: Red Hat Ansible Tower 3.2
We are excited to announce the release of Red Hat Ansible Tower 3.2 for availability soon. Our engineering team has been working hard to enable Ansible Tower to provide the best platform for managing, executing, and delegating your Ansible automation throughout your entire enterprise, whether you’re managing servers, applications, networks, and more.
With Ansible Tower 3.2, we’re continuing to innovate in two main areas:
- making automation more powerful and more flexible
- enabling continued enterprise-wide deployment of automation
To do that, we’ve enhanced several areas of Ansible Tower, and I’m happy to talk about them today.
Enhanced Integration with Red Hat Insights
With Ansible Tower 3.1, we built the first step of our integration with Red Hat Insights - allowing you to sync Insights remediation playbooks to Ansible Tower for use as needed. We’ve continued to enhance this integration in Ansible Tower 3.2. Now, we bring the ability to view Insights Actions directly in Ansible Tower. With this, you can more easily see your minor, major, and critical issues, and with just a few clicks, schedule remediation with Insights Plans.
Built-in Fact Caching
Ansible facts give you powerful capabilities to adjust, branch, and conditionalize playbook execution Continue reading
Coming Soon: Networking Features in Ansible 2.4
Wow, how time flies! Here we go with another Ansible Project release packed full of updates for automating network infrastructure. After spending the last year heavily focused on building much of the foundation for Ansible network integration, this release represents the beginning of the journey towards building more application-aware, declarative-based Ansible modules. This is an exciting time and on behalf of the entire Ansible community, including the Ansible network engineering team. I’m very pleased to share with you the enhancements and updates to network integration included with the forthcoming Ansible 2.4 open source release.
The initial introduction of network support was originally conceived to help operators focus on being able to execute configuration changes on network devices with a set of imperative-based configuration modules.
Today, the Ansible network modules are focused on pushing configuration statements to network devices. It was a small step, but an important one in the journey towards full configuration management of physical network devices.
Since then, we have turned our attention towards how to better help organizations become more agile in actively managing network configurations. Over the course of the Ansible 2.4 release, we have been phasing in a more intelligent approach to building Continue reading
Why You Should Attend AnsibleFest
It’s that time again! The time when automators from all over converge at the official event for all things Ansible — AnsibleFest San Francisco! Fresh off the heels from a packed house at AnsibleFest London in June, AnsibleFest San Francisco is shaping up to be the biggest AnsibleFest ever. With about a week before showtime, now’s the best time to start planning a trip to the “City by the Bay” for a fantastic event before it sells out.
To give a better idea of what to expect (and how to convince your manager to go), I’ve provided the top five reasons to go to AnsibleFest in San Francisco:
1. Expanded agenda and a session on Key Topics and Trends with Jim Whitehurst Red Hat CEO
We’ve heard your feedback, and listened: now more breakout sessions! We have made an unprecedented increase in sessions, up from 16 to 25, from customers, partners and the community. All session have been posted to the AnsibleFest agenda so you can see the better-than-ever lineup we have created.
2. All Ansible, all the time
Of course, we realize that Red Hat Summit is the company’s flagship event (I’ve been to seven of them), but Summit Continue reading
Five Questions: Testing Ansible Playbooks & Roles
Next up in our #AskAnsible posts is Chris Meyers, our Senior Software Engineer.
Learn his take on five key questions we often get regarding testing Ansible Playbooks and roles.
1. Why should I test my Playbooks and roles?
Chris: Ansible Playbooks and roles should be treated like production code. Production code usually has unit tests, functional tests, and integration tests.
- Unit testing Ansible is equivalent to unit testing SQL queries, you just normally don’t do it. Ansible unit testing belongs at the Python module level.
- Function testing with Ansible would require a large amount of system state setup or mocking, and it just isn't realistic.
- Integration testing is the most useful. It ensures that your intent, expressed in English, is translated correctly to Ansible’s declarative language.
- Ex: you want to set up a LAMP or MEAN stack. A simple integration test would be to issue an http request that you know exercises the database. The integration test would ensure that your setup is correct from end to end.
Chris: You can start at any time! Tests can be added for new Playbooks or to existing Playbooks. Testing Continue reading
Getting Started: Writing Your First Playbook
Welcome to another post in our Getting Started series. Keep reading to learn how to draft a Playbook that can be run in Ansible or Ansible Tower. You can also use it along with the Module Index and the other docs to build your own Playbooks later.
What is a Playbook?
Playbooks are esentially sets of instructions (plays) that you send to run on a single target or groups of targets (hosts). Think about the instructions you get for assembling an appliance or furniture. The manufacturer includes instructions so you can put the parts together in the correct order. When followed in order, the furniture looks like what was purchased.
That's basically how a Playbook works.
The Playbook we're building will install a web server on a target RHEL/CentOS 7 host, then write an index.html file based on a template file that will reside with the final Playbook. You'll be able to take the example Playbook and additional files from this blog and test it out for yourself. While going over the example Playbook, we'll explain the modules that are used.
AuthorsThe author adds instructions for the modules to run, often with additional values (arguments, locations, etc. Continue reading
British Army Talks DevOps at AnsibleFest London 2017
AnsibleFest London on June 22 turned out to be our largest AnsibleFest to date with over 800 people from 25 countries. Thank you to everyone who attended.
One of the highlights from the conference was "Efficiency and Effectiveness through DevOps" by the British Army. Lt Col Dorian Seabrook, Head of Software Delivery, and Aidan Beeson, Linux Technical Architect, spoke about their experiences using Red Hat Enterprise Linux and Ansible Tower by Red Hat to implement modern DevOps and CI methodologies within their organization.Watch their talk below and stay tuned for the rest of the AnsibleFest London 2017 presentations. We will have all of them available for you soon!
Want to learn more about how the British Army is migrating its cloud infrastructure to Red Hat solutions? Read the latest press release.
Five Questions: Windows Automation
For #AskAnsible posts, we interview Ansible experts on IT automation topics and ask them to share their direct experiences building automation solutions.
In this post, I’ve asked Matt Davis five questions about Ansible for Windows automation.
Matt Davis is a Senior Principal Software Engineer for Ansible, focused on Ansible's Windows support. He has over 20 years experience in software engineering, architecture and operations at companies large and small. An avid musician, maker and home hacker, Matt lives with his wife and daughter in Beaverton, Oregon. You can follow him on Twitter at @mattdavispdx.
1. How is Ansible for Windows different than System Center Configuration Manager (SCCM) or Powershell Desired State Configuration (DSC)?
Matt: SCCM is generally considered a legacy workstation-flavored management technology, dating from the mid 1990s (though many places use it for server management, too). It requires agents on the managed hosts, which must be installed, configured and kept up-to-date. SCCM executes many operations locally and asynchronously from the server, so it's often difficult to orchestrate interdependent changes across hosts, and to reason about the overall system state at any point in time as part of larger deployments.
DSC is a much more modern management technology, supporting both an Continue reading