# Install Redis from source using Ansible? **URL:** \ **Category:** Ansible Project\ **Created:** [September 27, 2013, 1:58pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566 "2013-09-27T13:58:36Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Nicolas\_Grilly](https://avatars.discourse-cdn.com/v4/letter/n/77aa72/32.png) [@Nicolas\_Grilly](https://forum.ansible.com/u/Nicolas_Grilly)\ **Post date:** [September 27, 2013, 1:58pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/1 "2013-09-27T13:58:36Z")
Hello, I’m trying to install Redis from source using Ansible, and here is the resulting playbook: - hosts: all vars: redis\_version: 2.6.16 tasks: - name: Download Redis shell: creates=/tmp/redis-$redis\_version wget -O - [http://download.redis.io/releases/redis-$redis\_version.tar.gz](http://download.redis.io/releases/redis-$redis_version.tar.gz) | tar -xz -C /tmp - name: Install Redis command: creates=/usr/local/bin/redis-server chdir=/tmp/redis-$redis\_version make install sudo: yes - name: Create user redis user: name=redis system=yes home=/var/lib/redis shell=/bin/false sudo: yes - name: Configure Upstart for Redis copy: src=files/upstart\_redis.conf dest=/etc/init/redis.conf sudo: yes notify: Restart Redis handlers: - name: Restart Redis service: name=redis state=restarted sudo: yes upstart\_redis.conf content is: start on runlevel [2345] stop on runlevel [!2345] console log respawn setuid redis exec /usr/local/bin/redis-server --bind 127.0.0.1 --dir /var/lib/redis Any critics? Does this looks good/bad/improvable to you? Cheers, Nicolas ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [September 27, 2013, 2:39pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/2 "2013-09-27T14:39:43Z")
If you’re going to set sudo: yes on every task, set it on each play instead, and this will keep things shorter. You are still using old style variables, and this is terrible, because it repeats this for other users. {{ redis\_version }} The wget should use the “get\_url” module instead, and you can use “register” and “when: othertask.changed” to decide when to extract the tarball. Don’t just configure the service in the handler, as if Redis is down and you rerun the script it won’t start it. Stick a “state=started enabled=yes” in your task section also. Your make install step since has the directory as a “creates” won’t work for upgrades. You’re probably ok with this, but making an OS package for the Redis version you are deploying may be a huge improvement. ---
**Author:** ![Jean\_Philippe\_Caruan](https://avatars.discourse-cdn.com/v4/letter/j/13edae/32.png) [@Jean\_Philippe\_Caruan](https://forum.ansible.com/u/Jean_Philippe_Caruan)\ **Post date:** [September 27, 2013, 3:27pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/3 "2013-09-27T15:27:28Z")
Le 27/09/2013 16:39, Michael DeHaan a �crit : > The wget should use the "get\_url" module instead, and you can use > "register" and "when: othertask.changed" to decide when to extract the > tarball. Hi Michael, could you be more specific of give an example about this register/changed behaviour ? I also have unnecessary untar in my playbooks and I'm looking for a way to do it clean, but I don't find information easily in the documentation. (sorry, this is off the topic "install redis") Thanks. ps : my redis installation looks like this 🙂 : - name: Install redis   apt: pkg=redis-server state=present - name: Start redis   service: name=redis-server state=running enabled=yes -- Jean-Philippe Caruana ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [September 27, 2013, 3:33pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/4 "2013-09-27T15:33:08Z")
Something like this: - get\_url: url=[http://example.com/tarball.tar.gz](http://example.com/tarball.tar.gz) dest=/the/tarball.tar.gz register: get\_url\_result - shell: tar -xvf /the/tarball.tar.gz when: register.changed - shell: make install chdir=/whatever/directory when: register.changed This will only download the tarball when it is not already present (saving upstream bandwidth – always locally cache or have a copy of content and don’t have a hundred nodes hit the same upstream server! That’s not fair to the upstream and it’s also slow), but will only extract it when it has needed to be downloaded. This will make your playbooks both faster and more repeatable. ```auto ``` ---
**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:** [September 27, 2013, 3:48pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/5 "2013-09-27T15:48:03Z")
Normally I do a -get\_url in local action and then copy to all machines (if its from external source, like redis site), this would clobber my bandwidth only and not theirs. but ... hmm ... -get\_url: url=torrent:.... might be nice feature for when doing mass installs (might require special deps to be added though) ---
**Author:** ![Jean\_Philippe\_Caruan](https://avatars.discourse-cdn.com/v4/letter/j/13edae/32.png) [@Jean\_Philippe\_Caruan](https://forum.ansible.com/u/Jean_Philippe_Caruan)\ **Post date:** [September 27, 2013, 3:49pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/6 "2013-09-27T15:49:49Z")
Le 27/09/2013 17:33, Michael DeHaan a �crit : > Something like this: > > - get\_url: url=[http://example.com/tarball.tar.gz](http://example.com/tarball.tar.gz) dest=/the/tarball.tar.gz >   register: get\_url\_result > > - shell: tar -xvf /the/tarball.tar.gz >   when: register.changed > > - shell: make install chdir=/whatever/directory >   when: register.changed > > This will only download the tarball when it is not already present > (saving upstream bandwidth -- always locally cache or have a copy of > content and don't have a hundred nodes hit the same upstream server! > That's not fair to the upstream and it's also slow), but will only > extract it when it has needed to be downloaded. > > This will make your playbooks both faster and more repeatable. I think you meant   when: get\_url\_result.changed Otherwise it fails : TASK: [Extract Java archive] ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [September 27, 2013, 4:54pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/7 "2013-09-27T16:54:46Z")
Yep, I did. Glad it’s working out! ---
**Author:** ![Nicolas\_Grilly1](https://avatars.discourse-cdn.com/v4/letter/n/d9b06d/32.png) [@Nicolas\_Grilly1](https://forum.ansible.com/u/Nicolas_Grilly1)\ **Post date:** [September 27, 2013, 6:18pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/8 "2013-09-27T18:18:12Z")
Thank you Michael for your critical review of my playbook. My comments hereunder. ---
**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:** [September 27, 2013, 6:51pm UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/9 "2013-09-27T18:51:18Z")
debian based distros all will default to starting a service when it is installed., so enabled= is not always needed on install as it is the default state, but it is prudent to add in case someone manually disables it. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [September 28, 2013, 3:21am UTC](https://forum.ansible.com/t/install-redis-from-source-using-ansible/13566/10 "2013-09-28T03:21:33Z")
re: old style variables It’s not strictly deprecated in that it doesn’t have a decided date yet, it’s just heavily discouraged. It will likely generate a deprecation warning in future releases though as it’s valid in bash it may not.