Grokzen / docker-redis-cluster

Dockerfile for Redis Cluster (redis 3.0+)
MIT License
1.47k stars 549 forks source link

Unable to run cluster after container restart #47

Closed zidoo closed 6 years ago

zidoo commented 6 years ago

Hi, I'm pretty fresh in Docker land, please forgive me if I misunderstood something.

After container restart cluster was unable to start properly. Looks like problem is in docker-entrypoint.sh:16:19 - removing nodes.conf for each instance.

Am I doing something wrong or this is some kind of bug?

~ docker version
Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:05:26 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:13:46 2018
  OS/Arch:          linux/amd64
  Experimental:     true
 ~ uname -a
Darwin zmp.local 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
Grokzen commented 6 years ago

Basically the container is not really built for restarting i think. Are you using the Makefile commands up & down to start/stop your containers? I never have issues when using make up followed by make down and then starting it again.

zidoo commented 6 years ago

Just basic usage:

~ docker run -e "IP=0.0.0.0" -p 7000-7007:7000-7007 grokzen/redis-cluster:latest
~ redis-cli -c -p 7002
127.0.0.1:7002> cluster nodes
af32a8bb3b8a3faea56a190a36b5741da6913d83 127.0.0.1:7004@17004 slave 1da545b2077bcce2715c062feaae985d4109ac80 0 1533551051164 5 connected
d45473deb3bea71c7563d98329fda678a4bd4da4 127.0.0.1:7003@17003 slave 6c0653a9067a1ad2d8cfaeb17bd95352023ba791 0 1533551050000 3 connected
4ce6e8086ede44720f2dcf92336c5c6e3bf19c06 127.0.0.1:7005@17005 slave fdb81f006560c2dacac18b982d0bb2835db52114 0 1533551050555 2 connected
6c0653a9067a1ad2d8cfaeb17bd95352023ba791 127.0.0.1:7002@17002 myself,master - 0 1533551050000 3 connected 10923-16383
fdb81f006560c2dacac18b982d0bb2835db52114 127.0.0.1:7001@17001 master - 0 1533551050659 2 connected 5461-10922
1da545b2077bcce2715c062feaae985d4109ac80 127.0.0.1:7000@17000 master - 0 1533551050000 1 connected 0-5460

~ docker ps
CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS              PORTS                                        NAMES
05a684759cfd        grokzen/redis-cluster:latest   "/docker-entrypoint.…"   31 seconds ago      Up 30 seconds       6379/tcp, 0.0.0.0:7000-7007->7000-7007/tcp   sad_hamilton
 ~ docker restart sad_hamilton
sad_hamilton
~ redis-cli -c -p 7002
127.0.0.1:7002> cluster nodes
7efad9c0e9a2b9d5b3fa1ec6d933a325517a6608 :7002@17002 myself,master - 0 0 0 connected 12222 16287

Anyway, I'm just not sure that removing nodes files is necessary each time.

Grokzen commented 6 years ago

Well i am not really sure how you would decide automatically when to do what then. If there is some condition that we can detect and act upon, then sure, but otherwise i would say that you should use docker-compose solution or add --rm to your basic container run to delete the container after exit so a new one will be created fresh the next start.

zidoo commented 6 years ago

I actually need container to stay exactly same as it was before restart. I'm just not sure why rebuild cluster on each restart - I know that lot of people uses Redis as cache only but Redis is very good as permanent storage in specific cases.

Thanks for advice. Cheers, Z

Grokzen commented 6 years ago

@zidoo I know and understand that you might need it to perform in that way for your case. But remember that it is stated in the readme the intent and purpose of this repo and this version of a redis container The main usage for this container is to test redis cluster code. For example in https://github.com/Grokzen/redis-py-cluster repo.. So therefore it is not intended for persistent runs across time. It is more designed for very rapid deployment, but it should/could be trashed at any time and you just have to start or create a new container of it when running your tests or trying out the cluster features. BUT, if you ever would like to submit some modifications that would help you out to make it more persistent safe, please submit a PR for it and i will review and if i like it i will merge it, if it still maintains the core feature of quick and simple start.