20

Example scenario: config files for a certain service are kept under version control on a private github repo. I want to write a playbook that fetches one of these files on the remote node and puts it into the desired location.

I can think of several solutions to this:

  1. do a checkout on the machine that runs ansible (local_action) and then use the copy module
  2. do a checkout on the remote node (with the git module), copy the files to the desired location with command: cp src dest creates=dest (perhaps do this with a handler - only when repo has changes to be pulled)
  3. use the url module or command: wget https://raw.github.com/repo/.../file creates=file in the playbook to only download the file of interest. Is the command module actually going to check if the file to be created is different from the one that may already exist or does it just check the file exists?
  4. use wget on the machine that runs ansible (local_action) and then use the copy module to push it to the remote node

What are the advantages/disadvantages of these. Which (if any) of these could be considered good practice. What is the best general solution to this?

pldimitrov
  • 1,597
  • 2
  • 16
  • 21
  • Solution 3: definitely just check the file exists. And only if add creates: parameter for command. – mmv-ru Feb 09 '18 at 14:24

1 Answers1

10

I'll start by saying that we chose the 2nd solution for our production environment and I guarantee one thing - it just works. Now for the longer version:

Solution no. 1:

  • Simple and robust - will just work
  • Does not "contaminate" production servers with irrelevant files (other configuration files)
  • Does not load production servers with I/O to GitHub (probably negligible)

Solution no. 2:

  • Simple and robust - will just work
  • To reduce contamination, we clone the configuration repo to /tmp and delete it at the end of the playbook

Solution no. 3/4:

My guess it will work, but feels a bit strange to have your configuration in source control and then not really using source control features. The advantage of these solutions is that you can "cherry pick" which configuration files you want to download rather than cloning the whole repository. This also reduces I/O against github as cloning becomes heavier over time.

Shahar
  • 800
  • 8
  • 10
  • 2
    I decided to try the 1st solution and I think it turns out to be exactly what I wanted. I think it scales better (at least for my use case) as you only talk to github once (on the ansible server), instead of once per remote node per task call. – pldimitrov Feb 08 '14 at 21:14
  • 3
    As far as scalability is concerned, I think it really depends on your use case. Would you rather limit Github calls or file copies ? With the first solution, you have only one call to github but then you have X copy, one for each node. Your ansible playbook might then be a little bit long to process many remote nodes depending on your connection (e.g. copying 50Mo on 20 hosts = 1Go of data for only your control machine) whereas letting each node contact github would use only 50Mo on each node, and github is surely scaled for that... – Pom12 Jul 07 '15 at 12:39