We have introduced Ansible Open Source as the newest configuration management integration within Cloud Assembly. This new addition will greatly expand the application delivery story that exists within Cloud Automation Services.
.terminal {
border: 1px grey dashed;
padding: 10px;
background-color: whiteSmoke;
color: black;
font-family: “Lucida Console”, Monaco, monospace;
font-size: small;
line-height: 1.5;
}
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
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!
