Closed mike-kaimika closed 3 years ago
I wonder if we should move away from committing docker-compose.yml
and make it into another .template
file. It's a bit inconvenient to have git clobber the local config every pull. I realize the new one is general purpose, but I'm thinking of laptop deployments where the current compose file might need to be modified beyond what the new generalized one provides, based on various Windows quirks.
We can if you want. I assume we'd be making it a .template
file so that the real docker-compose.yml
can be git ignored? What type of changes are required on Windows that aren't covered by the current iteration?
I'm trying to reduce installation configuration steps for the Windows deploys, so one change I'm looking at is using internal volume management for the postgres container, which requires an additional build step (which does not require additional configuration) but eliminates the need for the user to create a named volume. I also don't want users to have to manage environment variables. And we'll be running under http on the laptops since they won't be on the internet when the tool is running (just a user's laptop or an internal ship network)
It sounds like we'd be managing to distinct deployment options at that point, so maybe the right answer is to have separate releases for each avenue? We already do a specific release branch for the server (to keep gulp compiled), so we could do two? This one might be better to talk through verbally
Resolves #75