0

Tower Workflow Convergence

In Red Hat Ansible Tower 3.1 we released a feature called Workflows. The feature, effectively, allowed users to compose job templates into arbitrary graph trees. A simple workflow we saw users creating was a linear pipeline; similar to the workflow below.

The workflow feature also allowed branching. Each branch can run in parallel.

But something was missing. The ability to wait for previous parallel operations to finish before proceeding. If this existed, you could simplify the above workflow (see below).

In Red Hat Ansible Tower 3.4 the above workflow is now possible with the introduction of the Workflow Convergence feature.

For you computer sciencey folks, workflows are no longer restricted to a tree, you can create a DAG. More simply, we call this convergence; two nodes are allowed to point to the same downstream node. The concept is best shown through an example. Above, we have a workflow with 3 nodes. The first two job templates run in parallel. When they both finish the 3rd downstream, convergence node, will trigger.

In this blog post we will cover the changes to workflow failure scenarios, how workflow node failure and success propagate, how this affects the runtime graph and how Continue reading

0

Ansible Tower Advanced Smart Inventory Usage

Background

Smart Inventory is a feature that was added to Red Hat Ansible Tower 3.2. The feature allows you to generate a new Inventory that is made of up hosts existing in other Inventory in Ansible Tower. This inventory is always-up-to-date and is populated using what we call a host filter. The host filter is a domain specific query language that is a mix of Django Rest Framework GET query language with a JSON query syntax added in. Effectively, this allows you create an Inventory of Hosts and their relational fields as well as related JSON structures. 

The ansible_facts field is a related field on a Host that is populated by Job Template runs (Jobs) that have fact caching enabled. Ansible Tower bolts on an Ansible fact cache plugin with Job Template that have fact caching enabled. Job Templates of this kind that run playbooks that invoke Ansible gather_facts will result in those facts being saved to the Ansible Tower database when the Job finishes.

A limitation of the Smart Inventory filter is that it only allows equality matching on ansible_fact JSON data. In this blog post I will show you how to overcome this limitation and add Continue reading

0

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

0

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:

1. ACS URL
2. Entity ID

Defined in OneLogin, needed by Ansible Tower:

1. Issuer URL
2. SAML 2.0 Endpoint (HTTP)
3. 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

0

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 reading

0

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.

2. When should I start testing my Playbooks and roles?

Chris: You can start at any time! Tests can be added for new Playbooks or to existing Playbooks. Testing Continue reading

0

What’s New in Tower 3: Installer

In July, we released Ansible Tower 3. This blog series is a deep dive into some of the new aspects of Tower. We've reworked Tower to make it simpler and easier to automate your environments and share your automation solutions. For a complete overview of the Tower 3 updates, check out this post by Bill Nottingham, Director of Product.

Installer configuration in Tower

Before we look at what's new, let’s remember the < 3.0 installer - referred to hereafter as the legacy installer. The legacy installer configuration was designed to be ran by users without Ansible knowledge.

This requirement led to the two step process:

Step 1:
./configure prompts the user for the needed configuration information to setup Tower. This includes things like: tower mode (i.e. single machine, remote database, HA), ssh connection information, and service passwords. The Ansible variable file, tower_setup_conf.yml, is generated to be consumed by the ./setup.sh script.

tower_setup_conf.yml
admin_password: password
database: internal
pg_password: BQgA2Z43jv86dzjDEswH7K75LAwufzSXbE7jUztq
primary_machine: localhost
redis_password: S3tab7QfWe2e92JEB9hNNFUunV4ircg3EdRdjpxP

Step 2:
./setup.sh wraps the Ansible install.yml, backup.yml, and restore.yml playbooks and passes in the appropriate run-time flag to include the previously generated configuration variable file and manage the generated logs. The . Continue reading

0

Testing Ansible Roles with Docker

Background

When you first start using Ansible, you go from writing bash scripts that you upload and run on machines to running desired end state playbooks. You go from a write-once read-never set of scripts to an easily readable and updatable yaml. Life is good.

Fast forward to when you become an Ansible power user. You’re now:

• Writing playbooks that run on multiple distros

• Breaking down your complex Ansible project into multiple bite-sized roles

• Using variables like a boss: host vars, group vars, include variable files

• Tagging every possible task and role so you can jump to any execution point and control the execution flow

• Sharing your playbooks with colleagues and they’ve started contributing back

As you gain familiarity with Ansible, you inevitably end up doing more and more stuff-- which in turn makes the playbooks and roles that you’re creating and maintaining longer and a bit more complex. The side effect is that you may feel that development begins to move a bit slower as you manually take the time to verify variable permutations. When you find yourself in this situation, it’s time to start testing. Here’s how to get started by using Docker and Ansible to automatically test Continue reading

0

ansible + ec2 + tags

This post is a direct result of the insightful questions asked by attendees during Ansible Fest 2015 San Francisco during the "Ask an Expert". This was a great opportunity for the Ansible Tower team to engage with customers of both Ansible and Tower and to understand their use cases, frustration, and love when working with our products.

Ansible Fest 2015 San Francisco

^*The "Ask an Expert" allowed attendees to sign-up for 15 minute slots to talk with Ansible employees about particular problems or use cases. This resulted in over 50 customer questions! Two Ansible employees were stationed at a heavy traffic area to engage attendees and listen to their initial questions or concerns to help choose from more than 15 experts to best engage with. Attendees then engaged with the expert, identifiable by the "Ask an Expert" picture included in their check-in packet, during their registered time.

* The "Ask an Expert" interaction was much more organic than the above description. Times often ran over when in-depth conversations were had and empty time slots were often filled with discussion from attendees in a more ad-hoc manor.

The feedback from the "Ask an Expert" from the attendees was overwhelmingly positive. I can say that the feeling Continue reading

0

ansible + ec2 + tags

"How do I spin up multiple ec2 instances, all with differing tags?"

This question is one of the many insightful questions asked by attendees during AnsibleFest 2015 San Francisco at our "Ask an Expert" tables. AnsibleFest was a great opportunity for the Ansible team to engage with customers of both Ansible and Tower and to understand their use cases, frustration, and love when working with our products.

The "Ask an Expert" program allowed attendees to sign-up for 15 minute slots to talk with more than 15 Ansible experts, resulting in over 50 customer questions! 

Feedback from the attendees was overwhelmingly positive. I can say that the feeling is mutual from the Ansible team side! It was a joy to hear from so many users of Ansible and Tower.

 

Example AnsibleFest "Ask an Expert" sign-up sheet:

 

Onto the Playbook

Now that we have the back story out of the way, let's get into the playbooks. Several attendees asked how to spin up multiple ec2 instances, all with differing tags.

Extrapolating from that question the user wants/concerns are:

• The ec2 doesn't "count" (spins up multiple identical instances)
• Run tasks/plays against spun up instances (obviously)
• Assign different properties to each instance (i.e. tags)

From the above requirements I will demonstrate a general Continue reading

0

How We Chose MongoDB for Ansible Tower System Tracking Feature

System Tracking

This is not a generic “Postgres vs. MongoDB” performance post. This post details the process of comparing Postgres vs. MongoDB with a particular use case in mind, System Tracking.

Desirable Databases Features

Postgres is a candidate database since it is already in use by Tower. MongoDB is the other database considered for an in depth analysis for many reasons including: (1) document store of the JSON structure, (2) arbitrary structure query support, (3) and the ability to run on a single machine and later scale.

Comparing the two databases begins with identifying our System Tracking requirements. What is System Tracking?

For Tower, System Tracking is time based snapshots of machine facts. Facts are key value pairs of system state. The inspiration comes from the open source Ansible. Ansible facts will be supported in System Tracking along with 3 other fact types: packages (i.e. rpm or apt-get), services (i.e. mongodb, apache2), and files (i.e. /var/log/message). We support these 3 facts as fact modules. We also want to allow for customer built modules. Facts generated by the 4 core modules plus user created modules would be stored in Tower’s System Tracking database; allowing customers to take advantage Continue reading