Make docker compose more seamless

[inodb]

Fix #7649. Add docker compose files to https://github.com/cBioPortal/cbioportal-docker-compose, initial work by @nr23730 & the Hyve - thanks! I figured it might be cleaner to keep the docker compose out of this repo, since it is using containers from various other repos (e.g. session-service). Might make sense to add genome nexus or oncokb as well at some point

Instructions can be found here:

https://github.com/cBioPortal/cbioportal-docker-compose

TODO:

• change above commands to use docker run and add to README
• add entrypoint to check for database connection. Need to figure out where to read the properties from (either env or properties file)
• do migration as part of entry as well to avoid having to do both step 3 and 4
• check whether we want to use docker volumes or just some directory on disk
• mongo also needs persistent volume (e.g. ${MONGODB_DATA_DIR:-../mongo_files/}:/data/db). Currently session service container has this, but should be mongo container
• update example commands
• update import data section or incorporate into comprehensive example
• remove manual update docker version script
• fix failing localdb test

[dippindots]

Thanks for making this happen, it's a very easy and pleasure installation experience!

[nr23730]

Very nice work! This is a lot more convenient than before!

[pvannierop]

@inodb I do not think I entirely agree with your rationale for moving the docker-compose solution to a different repo. It is making it more complicated than needed no? All other services are dependencies for running cBioPortal and I see this not as reason for moving everything.

[inodb]

@pvannierop Thanks for looking at this! The reasoning for moving to a separate repo was a bit short, let me elaborate

Some pros for moving to separate repo:

1. When following documentation to set up an instance one can use a git clone to get all the docker-compose related files. No need to pull the backend repo with unrelated code. Ofc this could also be a bunch of wget/curl statements instead, but this worked ok
2. If it was part of the repo the docker-compose would point to a different version of the backend code, then the one checked out. This is a bit confusing. Note that also the tagged version of the backend repo would contain a docker-compose file that points to an older version
3. It might make sense to re-use the docker compose file in other repos (e.g. cbioportal-frontend, session-service or oncokb) for testing. Pulling just that repo with docker-compose could be helpful

There are advantages for keeping it in the same repo as well. I find these rule of thumbs help with deciding:

1. Whenever changing one of the repos requires changing the other repo as well most of the time
2. You want to enforce some consistent use of styling/packages across both repos
3. You want to use the same CI/CD scripts

In this case I'm expecting the cbioportal-docker-compose repo to mostly change independently from backend changes so I don't think 1 applies. 2 def does not apply. The third one might apply, but doesn't really outweigh the pros of moving to a separate repo imo

[pvannierop]

@inodb Thnx for your elaborate explanation.

If it was part of the repo the docker-compose would point to a different version of the backend code, then the one checked out. This is a bit confusing. Note that also the tagged version of the backend repo would contain a docker-compose file that points to an older version

Ah I was under the impression that the docker-compose would deploy the current version of the cBioPortal repo currently checked out. I fully understand the choice now. Thnx.