Skip to end of metadata
Go to start of metadata

Now that our servers are registered in Ansible’s inventory, it is time to have our instances automatically get their configuration from Ansible when they start.

Creating the Ansible job template

The first step is to set up a configuration job template in Ansible to configure the instances of our Role, and to enable provisioning callbacks. This is well explained in Tower’s documentation. Create a job template, with machine credentials that will allow access to instances managed by Scalr, and the playbook of your choice.

Note on the playbook: for successful configuration, the hosts mention in the playbook must match a group to which the host that will request configuration belongs. For instance, if your playbook has a hosts: webservers mention, your Scalr-managed server will have to belong to the webservers group to be configured successfully. You could use the Farm Role group names generated by the inventory script, but if you don’t want your playbooks to break each time you rename a Farm Role in Scalr, we recommend writing separate playbooks for each role, and using hosts: all in each of these playbooks.

Make sure that the job template applies to the inventory that contains the group that we configured in step 1, otherwise the callback script will fail with an error "No suitable host was found".

Once you have the host configuration key and your job template is saved, proceed to the next step.

Adding the Ansible callback script

In this step, we will configure a Scalr Script that will be executed by the Servers when they start, to fetch the configuration from Ansible.

In the Main menu, click on “Add New” next to Scripts:

Give a name to this new script, for instance “Ansible provisioning callback”. Set the following as contents:


curl --data "host_config_key=$ANSIBLE_CONFIG_KEY" $ANSIBLE_CALLBACK_URL

Click on Create to save this script.

This script is generic and can be used with any Role or Farm Role. Each Role that wants to use it will only need to define the ANSIBLE_CONFIG_KEY and ANSIBLE_CALLBACK_URL global variables appropriately.

Setup a Role to be automatically configured by Ansible

The final step is to configure a Role with the proper Global Variables and Orchestration Rules to run this script when a Server is started.

Create a new Role. Setup the two necessary Global Variables (ANSIBLE_CONFIG_KEY and ANSIBLE_CALLBACK_URL) with the values provided by Ansible Tower:

Then, in the Orchestration section, add an Orchestration rule to run our Script when a Server is up and ready (HostUp event), on the machine that triggered the event (Triggering instance only target):

Click on Save to save these changes.

Giving Ansible SSH access to the servers

To configure your servers, Ansible needs to have an SSH access to them. A simple and secure way to do so is to store the fingerprint of the SSH key that Ansible will use in a Global Variable in Scalr, and then to use Orchestration to register this SSH key on the Server when it starts.

In this exemple we will create the Global Variable and the Orchestration Rule at the Role level, you could also create it at the Environment or Account scope if Ansible will use the same key for all the servers in this Environment or Account. See Global Variable Scopes and Account-Scope Orchestration.

We will start by creating the Script that registers the SSH key on the Server. Go to the Scripts section, and create a new Script with the following contents:

mkdir -p /root/.ssh
echo "$ANSIBLE_SSH_KEY_FINGERPRINT" >> /root/.ssh/authorized_keys

Click Create to save this Script.

This script assumes that Ansible connects as root to the Server. If that is not the case, replace /root in the script by the home directory of the user Ansible is using.

Now go back to the Role configuration, and click on the Global Variables section. Create a new Global Variable called ANSIBLE_SSH_KEY_FINGERPRINT. Set the SSH key fingerprint as the value:

Finally, create a new Orchestration Rule in the orchestration section to run the Script we just created before we make the provisioning callback to Ansible Tower. Note that the execution mode is set to Blocking and the order value was modified to make sure this Script completes before the provisioning callback script runs.

Click on Save to save the Role.

And this is all! All Servers using this Role will now be automatically configured by Ansible. To test this behavior, create a Farm with a Farm Role based on the Role we just created, make sure that the Security Groups configuration allow your server to reach the Tower installation on port 443 and allow your Tower server to reach port 22 on your Servers, launch the Farm, and after a few minutes you should see the job being launched in Ansible. If that is not the case, check out the Troubleshooting the integration page.

  • No labels