redis #7

Supports: trusty
Add to new model


Redis is a key-value database in a similar vein to memcache but the dataset is non-volatile. Redis additionally provides native support for atomically manipulating and querying data structures such as lists and sets. The dataset is stored entirely in memory and periodically flushed to disk. This charm supports data replication and provides both the master and the slave services.


Redis ( is an open source, advanced key-value cache and store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs. In order to achieve its outstanding performance, Redis works with an in-memory dataset that can be written to disk. Redis also supports master-slave asynchronous replication.

Redis can be configured in a master or slave configuration. This charm provides a single stand alone implementation of Redis software supporting the master-slave relationship. Go to the Redis web pages for more information on replication.


To deploy this charm first bootstrap your Juju environment and issue the following command:

juju deploy redis

Expose the master if you need to contact them for some reason.

juju expose redis


Redis can be set up with master-slave replication in Juju. This allows the Redis slave to be an exact copy of master server. A master can have multiple slaves.

To set up a master-slave scenario, deploy two services using this charm, one for the master and one the slave server, then relate the two.

juju deploy redis redis1
juju deploy redis redis2
juju add-relation redis1:master redis2:slave

Connecting to the charm

The charm provides a db relation for services wanting to connect to the Redis service. When the relation established the following data is passed to the related units:

  • hostname: the Redis server host name;
  • port: the port the Redis server is listening to;
  • password: the optional authentication password, or an empty string if no authentication is required.

Testing Redis

To test if Redis software is functioning properly, telnet to the Redis private ip address using port 6379. First you need to retrieve the private address of the Redis instance, then you can use juju ssh to connect to that address, for instance::

juju ssh redis/0 telnet `juju run --unit redis/0 "unit-get private-address"` 6379

You can also install the redis-tools package apt-get install redis-tools and connect using the Redis client command:


From there you can issue Redis commands to test that Redis is working as intended.

Development and automated testing.

To create a development environment, obtain a copy of the sources, run make sysdeps to install the required system packages and then make to set up the development virtual environment. At this point, it is possible to run unit and functional tests, including lint checks, by executing make check.

Run make deploy to deploy the local copy of the charm for development purposes on your already bootstrapped environment.

Use make help for further information about available make targets.

Redis Information


(int) Set the number of databases. The default database is DB 0. You can select a different one on a per-connection basis using SELECT <dbid> where dbid is a number between 0 and 'databases'-1.
(string) Specify the log file name.
(string) Specify the Redis server verbosity level. Choices are: - debug (a lot of information, useful for development/testing); - verbose (many rarely useful info, but not a mess like the debug level); - notice (moderately verbose, what you want in production probably); - warning (only very important / critical messages are logged).
(string) Don't use more than the specified amount of memory. When the memory limit is reached Redis will try to remove keys according to the eviction policy selected (see "maxmemory-policy" below). If Redis can't remove keys according to the policy, or if the policy is set to "noeviction", Redis will start to reply with errors to commands that would use more memory, like SET, LPUSH, and so on, and will continue to reply to read-only commands like GET. This option is usually useful when using Redis as an LRU cache, or to set a hard memory limit for an instance (using the "noeviction" policy). It is possible to specify the memory size in the usual form of 1k, 5GB, 4M and so forth: - 1k: 1000 bytes; - 1kb: 1024 bytes; - 1m: 1000000 bytes; - 1mb: 1024*1024 bytes; - 1g: 1000000000 bytes; - 1gb: 1024*1024*1024 bytes.
(string) how Redis will select what to remove when maxmemory is reached. You can select among five behaviors: - volatile-lru: remove the key with an expire set using an LRU algorithm; - allkeys-lru: remove any key according to the LRU algorithm; - volatile-random: remove a random key with an expire set; - allkeys-random: remove a random key, any key; - volatile-ttl: remove the key with the nearest expire time (minor TTL); - noeviction: don't expire at all, just return an error on write operations. Note: with any of the above policies, Redis will return an error on write operations, when there are no suitable keys for eviction.
(boolean) Set the Linux kernel overcommit memory setting to 1 so that no memory overcommit handling is performed. When this is enabled, the performance for memory-intensive tasks is increased, but there is more risk of memory overload. This option is ignored when the charm is deployed to a local environment.
(string) Require clients to issue AUTH <PASSWORD> before processing any other commands.
(int) Accept connections on the specified port.
(int) If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence of communication. This is useful to detect dead peers and to take the connection alive from the point of view of network quipment in the middle. The specified value is in seconds.
(int) Close the connection after a client is idle for N seconds (0 to disable).