CloudForms and Ansible

CloudForms with Ansible batteries included

This first exercise of the lab will guide you through the process of creating a Service Catalog Item based on an Ansible Playbook.

Introduction to Ansible

Today, every business is a digital business. Technology is your innovation engine, and delivering your applications faster helps you win. Historically, that required a lot of manual effort and complicated coordination. But today, there is Ansible - the simple, yet powerful IT automation engine that thousands of companies are using to drive complexity out of their environments and accelerate DevOps initiatives.

Red Hat CloudForms can integrate with IaaS, PaaS, public and private cloud, and configuration management providers. Since version 4.2 of CloudForms, it can also integrate with Ansible Tower by Red Hat. The latest version which is 4.6, which has an improved “embedded Ansible” role which allows it to run Playbooks, manage credentials and retrieve Playbooks from a source control management like git.

This integration give customers the capability to build Service Catalogs from Ansible Playbooks to allow end users to easily browse, order and manage resources from Ansible. Ansible Playbooks can be used in Control Policies which can not only detect problems, but also automatically fix them. The User Interface of CloudForms can be extended seamless with additional menus and buttons, which utilize Ansible Playbooks to perform user initiated tasks.

Value provided by a Service Catalog

One of the features a Cloud Management Platform provides, is a Self Service User Interface. From the Service Catalog users can order, manage and retire Services. Services are categorized in Catalogs, where they can be organized and easily consumed.

By providing a Service Catalog, users can deploy the Services they need quickly and easily. This helps to improve agility, reduce provisioning time and free up resources in internal IT.

Service Basics

But first some basics. Four items are required to make a Service available to users from the CloudForms Self Service Catalog:

  1. Provisioning Dialog

The Provisioning Dialog specifies the list of customizable parameters. For example, when ordering a Virtual Machine, users can specify the number of virtual CPUs, how much memory the VM should have and other parameters. The list of possible parameters is defined in the Provisioning Dialog

  1. A Service Dialog

    When the user orders a Service Catalog Item from the Service Catalog, you might want to allow them to override certain default values. For example, you might allow users to choose from a range of values of how much memory the new Virtual Machine can have. You might want them to only choose from a list of predefined values like 2, 4, or 8 GB of RAM - but not more or less. This is specified in the Service Dialog.

  2. A Service Catalog Item

    The Service Catalog Item is what users will see in the Service Catalog and are able to order. It usually consists of a Service Dialog allowing users to change specific parameters, it can have a nice icon and an (optional) HTML description. Service Catalog Items are organized in Service Catalogs for easier navigation.

  3. A Service Catalog

    The Service Catalog allows administrator to organize the Catalog Items. You might want to have a Catalog for different Virtual Machine types, or one offering certain applications like Wordpress, MariaDB etc. Or you might want to categorize by Operating System. This is done by creating Service Catalogs and adding Items to them.

We can also use Role Based Access Control to make certain Service Catalog Items available only to specific groups of users.

Power on target VM

The following lab will use UI customizations to illustrate how easy it is to add additional functionality to CloudForms. The example will use an Ansible Playbook which will be executed on a Virtual Machine. Ansible uses SSH to access the remote machine and therefore the VM has to be powered on. The following steps will power on a Virtual Machine which we later use as the target for the Ansible Playbook.

  1. Navigate to Compute -> Infrastructure -> Virtual Machines

    navigate to virtual machines

  2. Tiles represent the Virtual Machines. Note that the VM “cfme001” is powered off.

    VM cfme001 is turned off

  3. Click on the tile icon “cfme001” to see the VM details.

  4. Click Power -> Power On to power on the Virtual Machine

    cfme001 power on

  5. CloudForms will perform this action in the background and it will take a few minutes to complete. Click on the reload icon in the menu bar to reload the screen.

    reload VM details

  6. Verify the “Power State” of the Virtual Machine has changed to “on” before you proceed with the next steps of the lab.

    cfme001 powered on

The VM should also report an IP address in the network.

Now our test VM is up and running and we can proceed with the next steps.

Make sure embedded Ansible role is enabled and running

Before we continue, we want to make sure the embedded Ansible role is enabled and running.

  1. Click on your user name on the top right and click on Configuration

    navigate to configuration

  2. Make sure the “Embedded Ansible” and the “Git Repositories Owner” Roles are enabled

    ansible role enabled

  3. Click on Diagnostics in the accordion on the left and click on the Workers tab

  4. Make sure you can see a line indicating the “Embedded Ansible Worker” is in state “started”

The git role is not represented by a specific worker process.

![ansible worker started](/img/summit-fy19-ansible-worker-started.png)

We’ve noticed that sometimes the role does not start automatically. You can trigger a restart by clicking on Diagnostics -> Server and then Configuration -> Restart Server. This will trigger a restart of all services and can take a few minutes to complete. Only do this, if your Embedded Ansible role was not in state “started”.

restart CloudForms Server

Add a Git repository of Ansible Playbooks

To be able to run Ansible Playbooks, they have to become available in CloudForms. Custom git repositories can be used as well as GitHub, GitLab or others. Other Source Control Management Systems like Subversion or Mercurial are planned for later versions.

  1. Navigate to Automation -> Ansible -> Repositories.

    navigate to Ansible repositories

  2. Click on Configuration -> Add New Repository

    Add new repository

If the menu item “Add New Repository” is disabled, the Git Repository Role is not active.

  1. Fill in the form.

    An internal name for the git repository:

    Name: Github

    A description for the git repository:

    Description: Example Playbooks

    How to access the git repository:


    Update on Launch causes CloudForms to check for new Playbooks or updated Playbooks before a Playbook is launched.

    SCM Update Options: check “Update on Launch”

    add a new repository

  2. Click on Add to save the settings

It takes a few seconds for the action to complete. A pop up notification will inform you after the task was completed.

  1. You can click on your username in the top right corner and then on Tasks to see all currently running tasks. Switch to All Tasks to see the progress of your Repository import.

  2. Verify the task completed successfully

    after Ansible repo task compled

  3. Navigate back to Automation -> Ansible -> Repositories.

    navigate to Ansible repositories

  4. Click on the Reload icon to refresh the screen. After the initial import completed, you will see the list of available repositories.

    list of Ansible repositories

  5. Click on the repository to see the details.

    Ansible repository details

  6. Click on Playbooks to see the list of automatically imported playbooks.

    list of imported playbooks

This confirms that all playbooks have been imported successfully.

Store Virtual Machine Credentials

Ansible is using SSH by default to perform actions on the target machine. To be able to login, it has to know the login credentials.

  1. Navigate to Automation -> Ansible -> Credentials

    navigate to Ansible credentials

  2. Click on Configuration -> Add a new Credential

    add new credentials

  3. Use the following settings:

    A user descriptive name for the Credentials you want to store:

    Name: Virtual Machine credentials

    CloudForms supports several credential types to connect to other systems. For this lab we chose “Machine”:

    Credential type: Machine

    The username used to login to the target system:

    Username: root

    The password used to login to the target system:

    Password: <to_be_provided>

    Passwrds are stored encrypted in the CloudForms database.

    provide VM credentials

  4. Click *Add to save the credentials

    Once more this is an action which is preformed in the background and it can take a few seconds until you can see the new credentials in the Web UI.

Create an Ansible Service Catalog

To offer a Service Catalog Item to users, they have to be organized in Service Catalogs. Create one by following these steps:

  1. The next step is to create a Service Catalog. First we have to navigate to Services -> Catalogs.

    navigate to services, catalog

  2. On this screen click on Catalogs on the left

    service catalogs

  3. Click on Configuration and Add a New Catalog

  4. Fill out name and description:

    A user friendly name of the Service Catalog. End users will see the different Service Catalogs by name:

    Name: Ansible

    Additional description about the Service Catalog. End users will see the description and it will help them to find the Service Catalog Items they are looking for:

    Description: Order Ansible Playbooks from a Service Catalog

    add a new catalog

  5. Click on Add to save the new Catalog

Create a Service Catalog Item

In the following step we create a Service Catalog Item which will execute an Ansible Playbook.

  1. Navigate to Services -> Catalogs

    navigate to Services Catalogs

If you followed the instructions by the letter, you’re already in this part of the UI.

  1. Navigate to Catalog Items in the accordion on the left

    navigate to Catalog Items

  2. Click on Configuration -> Add a New Catalog Item

    create new catalog item

  3. Select Ansible Playbook as Catalog Item Type

    select ansible playbook as type

  4. Use the following parameters when defining the Service Catalog Item:

    The user friendly name of the Service Catalog Item. It will be presented to the end user:

    Name: Install Package

    Additional description about the Service Catalog Item to make it easier for the end user to find what they are looking for:

    Description: Install Package via Ansible Playbook

    You can hide Service Catalog Items from users by setting this to “No”. For this lab we want to allow users to order the Service Catalog Item, so we set this to “Yes”

    Display in Catalog: Yes

    In which Service Catalog do you want the Service Catalog Item to show up?

    Catalog: Ansible

    You might have many git repositories, to better identify the correct Ansible Playbook, you first select the Repository. We only have one Repository so far, so this is simple:

    Repository: Github

    The actual Playbook which will be exected when the Service Catalog Item is ordered.

    Playbook: playbooks/InstallPackage.yml

    The credentials used to login to the target machine to run the Ansible Playbook:

    Machine Credentials: Virtual Machine credentials

    Ansible Playbooks can use variables which gives us more flexiblity. In this example the package name is not hard coded, but can be set and changed from a variable:

    Variables & Default Values: add one new entry with:

    Since a Playbook can have multiple variables, you can add multiple lines.

    Variable: package_name

    Default Value: httpd

    Click the little plus (“+”) icon to save the row. We only use one variable in this playbook, but your Playbooks might use more.

    Dialog: Create New

    Use “InstallPackage” as the name of the Dialog. CloudForms will automatically create the Service Dialog for us, to save some time. The automatically created Service Dialog is still fully customizable, which we will do in a later part of the lab.

    dialog to create InstallPackage Service Catalog Item

  5. Click Add to save all changes

Test the Service Catalog Item

We want to make sure the resulting Service Catalog Item actually works.

  1. Navigate to Services -> Catalogs

    navigate to service catalogs

  2. Click on Service Catalogs in the accordion on the left, if not already selected

    navigate to Ansible Service Catalog

  3. Select the “Install Package” Service Catalog Item

    select install package Service Catalog Item

  4. Click Order

  5. Select the following options:

    These are the credantials stored in CloudForms earlier, to log into the target machine:

    Machine Credentials: Virtual Machine Credentials

    On which machine the Playbook should be executed:

    Hosts: localhost (should already be the default)

    The varaible specified when creating the Service Catalog Item, which can be overriden by the end user during order:

    package_name: httpd (should already be the default)

    parameters for the Ansible InstsallPackage Playboosk

  6. Click on Submit

  7. After submitting your order, you will be redirected to the Requests Queue. You should also see pop up notifications on the top right informing you about the progress of your order.

Click on Refresh to monitor the progress of your order

  1. Navigate to Services -> My Services

    navigate to My Services

  2. Every time a user places an order a object under “My Services” is created. You should see one tile labeled “Install Package”

    My Service Install Package

  3. Click on the tile icon to get more details

    My Service Install Package Details

  4. Click on the tab Provisioning to see details of the Ansible Playbook run

    My Service Install Package Provisioning

In this example the Playbook completed successfully. In your case it might be still running and not be complete. Click the little reload icon on the page to reload the information while the Playbook is executed in the background.

This concludes this part of the lab.