Cloud Automation

Ansible Integration Comes to Cloud Assembly!

It’s not enough for platforms delver infrastructure anymore. Applications are first class citizens in Clouds, and customers have an expectation that automation delivers these applications in a configured state. The term behind this is frequently referred to as “Confguration Management”. Configuration Management can trigger many things – sometimes it might be compliance configurations on an endpoint system. Other times, it might be an applicaton configuration put in place. It might even be both!

This month, we have added Ansible Open Source as our newest Configuration Management integration within Cloud Assembly. With this integration in place, customers can add an Ansible control host to Cloud Assembly, and execution both provisioning and deprovisioning playbooks as part of the provisioning lifecycle of a machine. This provides our customers with another option, complimenting the existing Puppet Enterprise functionality we have today.

A couple of key facts about this integration

  • This integration is specific to Ansible Open Source, not Ansible Tower or AWX.
  • We require version 2.6+ for the integration to function. Please ensure you are either using the Ansible repository on your Linux distribution of choice, as well as upgrading the package using pip if necessary. You can find your version by using the ansible –version command

QuickStart Help

We’ve provided a GitHub repository with simple configuration details for getting started quickly with this integration. You can access this on GitHub here,  This repository contains…

  • A sample blueprint
  • A sample NGINX playbook
  • Configuration Instructions for Ansible Open Source

Configuring Ansible Open Source

In order to consume this integration, a few items must be configured ahead of time

  • Ansible installed on the Control Host
  • The Ansible host file path (usually /etc/ansible/hosts) is accessible. Integration Tip: Add an entry (even localhost) to this hosts file before provisioning, If you don’t you’ll receive a warning indicating that no entries exist in the file.
  • Ansible Playbooks (automation workflows) stored in an appropriate directory
  • An SSH private key configured (preferred) OR Remote SSH Username/Password configured for destination systems

In my configuration screen below, I’ve used the root user. This is typically not preferred from a security standpoint but as this is a lab environment, we’ll let it slide.

Once the integration is configured, we can configure an Ansible object on our design canvas.

Ansible On the Canvas

Below, you can see a sample blueprint.yaml file that I have created to demonstrate this integration. This YAML file works with Ubuntu to deploy an NGINX web server onto a host. This is a very simple playbook.

formatVersion: 1
inputs: {}
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      image: ubuntu
      flavor: small
      constraints:
        - tag: 'env:vsphere'
      cloudConfig: |
        package_update: true
        packages:
          - python
        users:
          - name: root
            ssh-authorized-keys:
              - ssh-rsa <my public key> 
   Ansible:
     type: Cloud.Ansible
     properties:
       inventoryFile: /etc/ansible/hosts
       username: root
       playbooks:
         provision:
           - /root/playbooks/web.yml
       osType: linux
       groups:
         - web
       maxConnectionRetries: 10
       host: '${resource.Cloud_Machine_1.*}'
       account: Ansible-OSS
       privateKeyFile: ~/.ssh/id_rsa

This blueprint deploys a Cloud Agnostic machine into my vSphere environment. We use Cloud-init to “push” the publish SSH key into this host, which Ansible is going to use against my private key in order to authenticate and execute the playbook. We add the python package to ensure its present as Ansible needs this to run.

Once the machine itself completes its configurations and deployment, our Ansible integration will reach out to our Control Host and update our Ansible Hosts file with the group configuration we specify in our blueprint. Once complete, the playbook is executed remotely on the end machine.

Note: We do not have to predefine our SSH key if we don’t want to! Cloud Assembly, with Cloud-Init has the ability to dynamically generate the SSH keypair for the machine and leverage it!

Secondary Note: If you opt to leverage Username/Password authentication for the remote authentication, the password file is stored in the Ansible vault file, which is encrypted. To use this path, ensure that you have the vault_password_file parameter in your ansible.cfg file. Alternatively, you can use the ANSIBLE_VAULT_PASSWORD_FILE environment variable as well.

Wrapping Up

This integration greatly expands the application delivery story that exists within Cloud Automation Services today. We can perform basic host configuration and installation leveraging cloud-init, and as we require more granular control over the way applications deploy, are configured, and maintained – we provide the option of Puppet Enterprise or Ansible Open Source, 2 of the most consumed configuration management platforms in the industry today!

Cloud Automation Services is about giving our customers choice. That choice can be which could you want to run your workloads in, and now, which Configuration Management tool you want to consume to deliver your end state workloads!

Sign up for a trial of Cloud Automation Services today and see how you can get started quickly today!

Related Posts:

Related Articles