Derp Ops -- The blog of Jesse Keating

A computer, bike, and climb nerd living in the Pacific Northwest. I do cloudy things with computers, currently at GitHub.

View on GitHub
25 December 2014

Ansible copying content from one remote system to another

by Jesse Keating

Just a quick tip of you're trying to do the same thing I was trying to do.

The Problem

I am generating some content on Server A. I want to replicate this content onto Servers B and C.

The Solution

TL;DR: Read files content from Server A. Write files on Servers B and C from those contents.

Ansible provides a couple modules that make this possible. The first one we'll look at is the slurp module. This module allows you to read in contents of a file from a remote system. Here is an task to read the content, utilizing the run_once mechanism:

- name: slurp keystone certs
  slurp: src=
  with_items:
    - /etc/keystone/ssl/certs/ca.pem
    - /etc/keystone/ssl/certs/signing_cert.pem
    - /etc/keystone/ssl/private/cakey.pem
    - /etc/keystone/ssl/private/signing_key.pem
  register: pki_certs
  run_once: true

This will read each of those files in and save the results in the pki_certs variable. Ansible will only do this once, presumably on the host where this content was generated with a previous run_once task. However the variable data will be assigned to every host to make it easily accessible.

Next we need to write out the content on our other systems. There are a couple things to consider. First, because the files were read via a with_items loop, the registered content is in a list, specifically in pki_certs.results. This is easy enough to deal with because the results list is a list of dictionaries, and the name of the file is part of that dictionary. The filename resides in the item key, while the content resides in the content key. This allows us to template out both the path to be written as well as the content to be written at that path.

The next thing we need to consider is that the slurp module stores content in base 64 encoding. That means when we write it back out, we need to decode it from base 64, otherwise Ansible will happily write out some long strings that look nothing like your file. To decode from base 64, simply use the b64decode filter on the content variable.

The last thing to consider has to do with yaml and whitespace and ansible. This may not come into play with every file, but these files have multiple lines. A somewhat recent change in Ansible means that if the "short form" of task description is used (with key=value parameters) your written out file will have double linefeeds. The simple solution is to use "long form" task syntax as you'll see below:

- name: write out keystone certs
  copy:
    dest: ""
    content: ""
    owner: keystone
    group: keystone
    mode: 0700
  with_items: pki_certs.results

Because every host has access to the pki_certs variable this task can run across all of them. You might see a change registered for the first host in the loop, even though it was the source of the content, due to permissions or ownership changes, however subsequent runs will be nice and clean.

Hopefully this helps you out and saves you from spending an afternoon poking around at it like I just did!

tags: