Demo mode friendly docker-compose file

[jc-harrison]

As of #610 the docker-compose.yml in the project root is well-suited for all of the dev use-cases. However, I think it would be useful to have a separate docker-compose file designed for a production setup which doesn't depend on the git repository.

The differences between this and the top-level docker-compose file would be:

• Only the essential ports exposed
• No build sections (since this would be intended to be used without the git repo)
• An additional env var (e.g. RELEASE_TAG, default latest) to set the tag to pull from docker cloud (this would be useful in a situation where somebody has done pip install flowclient and therefore has a release version of flowclient, which may not be compatible with the latest flowapi image)
• Default values for all env vars except things like passwords, but allow the user to override those env vars where it is sensible to do so

This docker-compose file could be tucked away in the docs somewhere, to avoid confusion with the dev setup, but prominently linked-to in the docs (making it clear that the docker-compose file is all that's required to spin up a full FlowKit system, and the git repo is not needed).

The docs should also include instructions for how the user can know when the system is up and ready (since this can take a while, e.g. when using the synthetic data image) and how to stop all the containers (docker-compose down -v).

I'm not sure what's the best way to allow users to choose which flowdb image to use (they may want to try running the worked examples, in which case the synthetic data image would be best, or for a production setup they would probably want the "empty" flowdb image). Perhaps we want a "demo" docker-compose file and a "production" one? Or maybe just choose the one we think will be most useful.

[greenape]

I'd argue that a compose-file is actually the wrong thing for production, and they should be using a stack-file instead, in order to get the benefit of docker's secrets.

I'd maybe also distinguish between production and an easy to use demo mode.

[greenape]

Does the just merged #610 solve this one, or do we want to keep it open because it isn't applicable for demo mode?

[jc-harrison]

I'd like to keep this open, because I think a demo-mode compose file would be useful.

We might also want to consider a docker stack file for FlowAuth (probably doesn't want to be combined into the existing stack file, because FlowAuth should be independent of the rest of FlowKit in a deployment scenario).

[greenape]

Had a thought about this - for the worked examples, why don't we dockerize them, with one of https://jupyter-docker-stacks.readthedocs.io as a base? That would allow you to spin up a completely working demo system with a single command.

[jc-harrison]

That's a very good idea. Would you imagine this would change the way we run the worked examples for inclusion in the docs, or would the dockerised examples only be used when spinning up a demo system?

[greenape]

While it would nice to only do stuff in one way, I'm kind of inclined to think that there'll be a lot of suffering involved in dockerizing the docs build successfully on CI.

[greenape]

Think we can close this @jch1g10?