Redis is an open-source, networked, in-memory, key-value data store with optional durability. It is written in ANSI C. The development of Redis has been sponsored by Pivotal since May 2013; before that, it was sponsored by VMware. According to the monthly ranking by DB-Engines.com, Redis is the most popular key-value store. The name Redis means REmote DIctionary Server.
docker run --name some-redis -d redis
This image includes EXPOSE 6379 (the redis port), so standard container linking will make it automatically available to the linked containers (as the following examples illustrate).
docker run --name some-redis -d redis redis-server --appendonly yes
If persistence is enabled, data is stored in the VOLUME /data, which can be used with --volumes-from some-volume-container or -v /docker/host/dir:/data (see docs.docker volumes).
For more about Redis Persistence, see http://redis.io/topics/persistence.
docker run --name some-app --link some-redis:redis -d application-that-uses-redis
redis-clidocker run -it --link some-redis:redis --rm redis sh -c 'exec redis-cli -h "$REDIS_PORT_6379_TCP_ADDR" -p "$REDIS_PORT_6379_TCP_PORT"'
You can create your own Dockerfile that adds a redis.conf from the context into /data/, like so.
FROM redis
redis.conf /data/
CMD [ "redis-server", "/data/redis.conf" ]
Alternatively, you can specify something along the same lines with docker run options.
ocker run --volumes-from datacontainer --name myredis redis
Using this method means that there is no need for you to have a Dockerfile for your redis container.
If you have any questions about the image, please contact us through a GitHub issue or in the IRC channel #docker-library on Freenode.
If you want to contribute, we are always thrilled to receive pull requests, and do our best to process them as fast as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.
If your pull request is not accepted on the first try, don't be discouraged! If there's a problem with the implementation, hopefully you received feedback on what to improve.
We recommend discussing your plans through a GitHub issue before starting to code - especially for more ambitious contributions. This gives other contributors a chance to point you in the right direction, give feedback on your design, and maybe point out if someone else is working on the same thing.
Any significant improvement should be documented as a GitHub issue before anybody starts working on it. Please take a moment to check that an issue doesn't already exist documenting your bug report or improvement proposal. If it does, it never hurts to add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.