
Properly setting up Redis and Sidekiq in production on Ubuntu 16.04 - thomasrw
https://thomasroest.com/2017/03/04/properly-setting-up-redis-and-sidekiq-in-production-ubuntu-16-04.html
======
mperham
I disagree with the redis quickstart guide - making the user download a
tarball, compile source and install systemd service scripts is ridiculous. As
long as the Redis version is somewhat recent, they should install straight
from the distro. That should replace your first two sections with `apt-get
install redis-server`.

~~~
JdeBP
The problem for many third party softwares that motivates them to bypass the
package management is that the lag time for Debian and Ubuntu LTS releases is
huge. People going the apt route are going to be stuck with redis 3.0.6 from
2015 for years.

* [http://packages.ubuntu.com/xenial/redis-server](http://packages.ubuntu.com/xenial/redis-server)

Some softwares, such as MySQL Community Edition, come with third-party-made
packages, and the instructions are "Add us to your package manager's list of
repositories; and pull Debian/Ubuntu packges from us.". The downsides of this
are:

... for the system administrator, the necessity of a degree of trust that the
third-party package repository will not sneak in bad versions of other
packages. Package managers are not good at allowing system administrators to
control and to limit what systems will pull from individual repositories.

... for the third party developers, the need to know how to build
Debian/Ubuntu packages, and to keep up to date with all of the integration
work that the Debian/Ubuntu maintainers would be doing for them, including all
of the Debian/Ubuntu patches.

* [https://sources.debian.net/src/redis/2:3.0.6-1/debian/patche...](https://sources.debian.net/src/redis/2:3.0.6-1/debian/patches/)

This highlights a problem with the quickstart guide that you got wrong. It
does not make the user install systemd service scripts. It makes the user
install _van Smoorenburg rc scripts_ , complete with PID file nonsense, run
levels, hand-rolled log management, and a lack of correct (or indeed any) LSB
headers. This is two init systems behind the times for Ubuntu, which was
upstart before it was systemd, and which hasn't been van Smoorenburg rc for
over a decade now.

Ironically, the systemd service units are some of the very things that are
added on by the Debian/Ubuntu maintainers that one loses by not going the
Debian/Ubuntu packaging route:

* [https://sources.debian.net/src/redis/2:3.0.6-1/debian/redis-...](https://sources.debian.net/src/redis/2:3.0.6-1/debian/redis-server.service/)

* [https://sources.debian.net/src/redis/2:3.0.6-1/debian/redis-...](https://sources.debian.net/src/redis/2:3.0.6-1/debian/redis-sentinel.service/)

Adding systemd service units to redis proper, in contrast, has been stalled
for a while now:

* [https://github.com/antirez/redis/pull/2004](https://github.com/antirez/redis/pull/2004)

* [https://github.com/antirez/redis/issues/3251](https://github.com/antirez/redis/issues/3251)

~~~
mperham
Yikes, that's even worse. init.d is a tire fire.

As someone who maintains software that uses Redis heavily, I view 3.0 as
somewhat recent and very usable for most. There hasn't been significant
functional changes in Redis since 2.8 (the SCAN commands). Nothing significant
in 3.0; the GEO* commands are the major feature in 3.2.

I still have plenty of customers on Redis 2.8.

