# dealing with Redis and it's rewritten configuration files

**URL:** <https://forum.ansible.com/t/dealing-with-redis-and-its-rewritten-configuration-files/14919>\
**Category:** Ansible Project\
**Created:** [April 2, 2014, 12:42pm UTC](https://forum.ansible.com/t/dealing-with-redis-and-its-rewritten-configuration-files/14919 "2014-04-02T12:42:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\
**Post date:** [April 2, 2014, 12:42pm UTC](https://forum.ansible.com/t/dealing-with-redis-and-its-rewritten-configuration-files/14919/1 "2014-04-02T12:42:55Z")

</div>

How do people generally set up Redis through ansible?

Right now we’re using the fairly standard approach of templating the configuration files, and using a notify handler to restart redis whenever the configuration file changes.

The problem with this is that Redis often rewrites its configuration files; for example when a new master is elected.

So if we run a provision again, ansible resets the configuration file to its original value (pointing at the old master), and then restarts Redis. Due to the way Redis and our system is set up, that doesn’t actually appear to be a problem. The new master has a larger epoch value so the restart does not cause the master to change; and our system can tolerate a restarting Redis.

It just seems wrong, so I’m curious to here how other people configure Redis with ansible.

thanks,  
Bryan

---

<div class="post-metadata">

**Author:** ![C\_Morgan\_Hamill](https://avatars.discourse-cdn.com/v4/letter/c/ebca7d/32.png) [@C\_Morgan\_Hamill](https://forum.ansible.com/u/C_Morgan_Hamill)\
**Post date:** [April 2, 2014, 1:38pm UTC](https://forum.ansible.com/t/dealing-with-redis-and-its-rewritten-configuration-files/14919/2 "2014-04-02T13:38:32Z")

</div>

Excerpts from Bryan Larsen's message of 2014-04-02 08:42:55 -0400:

> The problem with this is that Redis often rewrites its configuration files;  
> for example when a new master is elected.

I haven't actually used Ansible to set up Redis, but I have run into  
software that does this, and I would note three things:

1. Ugh tell upstream to not do this. They probably won't listen but  
&nbsp;&nbsp;&nbsp;it's just a terrible thing, in my opinion.

2. The lineinfile module can be made to do some terrifying things, and  
&nbsp;&nbsp;&nbsp;you might finds it useful: if you're a bit clever with your regexes  
&nbsp;&nbsp;&nbsp;and backrefs, you can make almost any change you can perform with it  
&nbsp;&nbsp;&nbsp;idempotent. As an example, this horrifying snippet I use to  
&nbsp;&nbsp;&nbsp;configure ntp.conf:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- name: Comment out default timeservers.  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lineinfile:  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;state: present  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dest: /etc/ntp.conf  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;backrefs: yes  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexp: '^(server (?!{{ ntp\_server }}).\*)'  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;line: '#\\1'  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;register: result  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;until: not result|changed  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;retries: 5  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;delay: 1  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;notify:  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- restart ntpd

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- name: Set timeserver.  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lineinfile:  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;state: present  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dest: /etc/ntp.conf  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;insertafter: '^#server .\*'  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regexp: '^server .\*'  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;line: 'server {{ ntp\_server }}'  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;notify:  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- restart ntpd

&nbsp;&nbsp;&nbsp;This will comment out any 'server directive beside the one I want, and  
&nbsp;&nbsp;&nbsp;then insert my desired one.

3. Perhaps write some custom facts that get the current state of the  
&nbsp;&nbsp;&nbsp;Redis configuration and incorporate them into the template? You  
&nbsp;&nbsp;&nbsp;might also find Redis' CONFIG GET/SET/REWRITE commands useful.

---

<div class="post-metadata">

**Author:** ![Bryan\_Larsen](https://avatars.discourse-cdn.com/v4/letter/b/9de053/32.png) [@Bryan\_Larsen](https://forum.ansible.com/u/Bryan_Larsen)\
**Post date:** [April 2, 2014, 2:55pm UTC](https://forum.ansible.com/t/dealing-with-redis-and-its-rewritten-configuration-files/14919/3 "2014-04-02T14:55:13Z")

</div>

Thanks for your suggestions.

I think my approach will be to use the template file to create the configuration only if it doesn’t exist, and then use config set/rewrite to set any configuration variables that may change over the project lifetime.

Ansible 1.6 includes some more options to the redis module to make the second part easier, so I may just wait until ansible 1.6 is stable. As I said, my current approach that resets the configuration files and restarts redis on every provision appears to work, it just feels icky.

Bryan

---

<div class="post-metadata">

**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\
**Post date:** [April 2, 2014, 10:56pm UTC](https://forum.ansible.com/t/dealing-with-redis-and-its-rewritten-configuration-files/14919/4 "2014-04-02T22:56:09Z")

</div>

I would use custom fact script on each target that queries locally to see if it ‘is master’, put it in /etc/ansible/facts.d and it will run automatically on gather facts.

I would make sure only 1 master appears when going over the facts, then you can just feed it to the template from the ‘fact’ and it should not change that in the config (nor restart the server if there aren’t any other changes).

Brian Coca