CODEWITHSUNDEEP
ansible
sorin
sorin

Reputation: 170758

How can I speedup ansible by not running entire sections too often?

Assume that a normal deployment script does a lot of things and many of them are related to preparing the OS itself.

These tasks are taking a LOT of time to run even if there is nothing new to do and I want to prevent running them more often than, let's say once a day.

I know that I can use tags to filter what I am running but that's not the point: I need to make ansible aware that these "sections" executed successfully one hour ago and due to this, it would skip the entire block now.

I was expecting that caching of facts was supposed to do this but somehow I wasnt able to see any read case.

Upvotes: 0

Views: 136

Answers (2)

ydaetskcoR
ydaetskcoR

Reputation: 56997

Unfortunately, as far as I know, fact caching only caches host based facts such as those created by the setup module so wouldn't allow you to use set_fact to register a fact that, for example, a role had been completed and then conditionally check for that at the start of the role.

Instead you might want to consider using Ansible with another product to orchestrate it in a more complex fashion.

Upvotes: 1

Petro026
Petro026

Reputation: 1309

You need to figure out how to determine what "executed successfully" means. Is is just that a given playbook ran to completion? Certain roles ran to completion? Certain indicators exist that allow you determine success?

As you mention, I don't think fact caching is going to help you here unless you want to introduce custom facts into each host (http://docs.ansible.com/ansible/playbooks_variables.html#local-facts-facts-d)

I typically come up with a set of variables/facts that indicate a role has already been run. Sometimes this involves making shell calls and registering vars, looking at gathered facts and determining if certain files exist. My typical pattern for a role looks something like this

roles/my_role/main.yml

- name: load facts
  include: facts.yml

- name: run config tasks if needed
  include: config.yml
  when: fact_var1 and fact_vars2 and inv_var1 and reg_var1

You could also dynamically write a yaml variable file that get's included in your playbooks and contains variables about the configured state of your environment. This is a more global option and doesn't really work if you need to look at the configured status of individual machines. An extension of this would be to write status variables to host_vars or group_vars inventory variable files. These would get loaded automatically on a host by host basis.

Upvotes: 1

Related Questions