First, thank you!

I'll try and poke at this today or tonight as pandemic schedule allows. Overall though - I definitely need to heavily tweak this so that we're adding Docker, not replacing everything with Docker. I think adding Docker is great, but we shouldn't remove the over local run options that exist. I see things like start-all.sh (our current local run mechanism) are removed...I'll try and get this working then get both options working :)

Yeah, it didn't look like that side of things was completely working and figured it wasn't very likely to be used on the OSX/linux side of things, but we can put that back. I've been messing with the build trying to get it to work, but there are a couple problems.

1. Need to get the build to wait until all Redis instances are ready to serve requests before the tests start.
2. Need to figure out how to get linux docker to work on Windows in AppVeyor. On my local machine, just doing a normal docker-compose up works fine.

I've never gotten the Docker for Linux containers to work on the Windows AppVeyor builds (if we can, great!), but yet another reason for it to be additive :)

Locally, the start-all.sh works as-is, but you'll need redis-server compiled locally. We use it through WSL all the time for testing...so it is working. I'm guessing the missing redis-server build was the issue there.

Trying to spin this up locally now, but wondering if we can greatly reduce the diff here when creating the Docker image? I'm not sure why all the directories are necessary for example - can you help me understand there?

Well the problem is that the servers were stepping on each other even with the dbfile set to be different for each server. Not sure if that is something different with newer versions of Redis or what.

@ejsmith hmmm that shouldn't happen - that's why they have a different DB file - I shall poke locally and see if I can get it working equally unrolling the directory changes :)

@ejsmith Got it working here decently - but not AppVeyor yet, want me to push to this branch or make another PR? Simplifies the changes greatly and gets NRediSearch working...but we can't use the alpine image, due to it not being able to load modules (so it's a bit slower to build, but not terrible).

Nice! Whatever you think is best. Just let me know and I will take a look and see if I can help some more.

Pushed up to simplify everything...let's see about CI now (I'm not sure we can use this on Windows AppVeyor...but let's see!)

@ejsmith I propose this: let's get this working docker image in without CI changes as an addition, then tackle the CI bits in another PR. I'd like to get this in master for more brutal Sentinel testing ASAP and I don't think we need to couple the 2 together...even if CI requires a few tweaks to the Docker build in the end.

Thoughts? Ideas?

Yeah that seems reasonable to me. Let’s do it.

Done - let's check CI then can work on the Docker there as a follow-up if we can get it working.