Further unify docker-compose

[cincodenada]

This is moving towards #1858, and proposes a solution to one of the remaining roadblocks, which is the differing docker-compose files.

Docker-compose has a facility for overriding parts of a base configuration. This leverages that by creating two new files, docker-compose.prod.yml and docker-compose.dev.yml, which contain docker configuration specific to prod or dev, and removes most non-common configuration from the main docker-compose.yml.

This is a draft because it will require some sort of updates, to functionality or documentation, in order to be a functional setup. As-is, everything will come up fine, but no ports will be exposed, so the application will be running in its own little world, inaccessible from the outside. Which seems like not a terribly useful state :smile:

So, there are a couple ways to go with this setup. Firstly, if a docker-compose.override.yml is present, docker-compose will automatically use it and apply the configuration. I don't want to have that file as a committed file in the git repo, because it is useful to have that facility to tweak the configuration without introducing conflicts to the git-tracked docker-compose.yml. I think we should add documentation about this in any case - it should address a pain point in upgrades if we can reduce the conflicts people have laying around in their project repos by moving them into the un-tracked docker-compose.override.yml.

This could go hand-in-hand with this upgrade, in that we could require folks to copy the appropriate file (docker-compose.prod.yml or docker-compose.dev.yml) to docker-compose.override.yml as a starting point, and then tweak it however they need to. This would require updating the documentation to add that step. I like this approach because it nicely mirrors the nginx config setup, which is already part of the process. The main downside is that it requires an extra step for folks who are upgrading existing instances. There may be ways to mitigate this by adding some check to ./bw-dev upgrade or to application startup. And it may be worthwhile to figure out some sort of in-code channel for announcing/migrating these sort of breaking changes on upgrade anyway?

An alternative: you can also specify exactly what dockerfiles you want to use - so if you run docker-compose -f docker-compose.yml -f docker-compose.prod.yml, it will combine those two files and use the result. We could alter ./bw-dev's use of docker-compose to specify files like that as an alternative to the above, which would work fine. That's a little more complicated I think, and it also makes it so that running docker-compose outside of ./bw-dev won't work right, which might be confusing. But an advantage is that it wouldn't require any migration for existing instances if we did it right.

Let me know how all of this sounds - if we go with the copy-to-override option, I can open a documentation PR to add that step to the process there.

[mouse-reeve]

I'm leaning towards adding an override file, in part because I've thought for a while that we should have a way to include update path with code changes that require it. Something analagous to the database migrations, but for running whatever shell script (or whatever) is necessary to get the latest version working

[cincodenada]

Okay, I've gone through and rebased and updated this, with a mind towards using the .override.yml file, and I think it's a good step towards getting rid of the production branch entirely (I have further schemes once this is merged, ha)

The remaining thing is how to create the initial docker-compose.override.yml created: for new users, we could add one more step to the instructions, but for existing users it would be pretty mean to break their setup unless they know to copy the magic file.

I had a couple ideas here, and wanted your thoughts on them:

1. Add a check to ./bw-dev (before it runs any commands) that checks to see if docker-compose.override.yml exists, and if not, copies it over
   • This would work pretty well I think and take care of new setups and upgrades, but it is kinda messy, since it's only used once but would be running every time. Additionally, we don't have any other initialization-type logic in ./bw-dev yet, and I'm not sure I want to set that precedent.
2. Do the same check, but only in the update and setup commands
   • Less foolproof, but also less messy, and still covers the main use cases. Admins who are doing upgrades outside of ./bw-dev update should probably be reading the release notes anyway :wink:
3. Revive update.sh and add an update script to do the copy
   • I'm not familiar with the history here, and why it's disabled - it seems like a good place for this kind of thing, as long as we also ran update.sh in the setup command, which seems like a good idea anyway, but if it's complicated to revive this command, perhaps best left to another PR.

In any case, I also want to add some sort of check at buildtime or runtime so we can throw a big warning admins if they are running without ports set up, with directions on how to fix it, which should take care of any gaps. This would particularly make option 2 nicer, I think.

[mouse-reeve]

I think the problem with the update script was that the order of things in it was off and it was causing issues? and I disabled it because that was quicker than fixing the problem. That was for the celery beat migrations. But I'd be happy to revive it.