docker-compose: explicitly define COMPOSE_PROJECT_NAME #75
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[COMPOSE_PROJECT_NAME](https://docs.docker.com/compose/reference/envvars/#compose_project_name) defines a namespace that docker-compose prefixes all networks, containers, and volumes with. This previously wasn't set, in which case `docker-compose` defaults `COMPOSE_PROJECT_NAME` to the `basename` of the folder that contains the `docker-compose.yaml` file (literally `docker-compose` in our case). Not defining this variable has worked up until now, but docker-compose will treat all resources defined in `docker-compose.yaml` as brand new if the folder contains `docker-compose.yam` was ever renamed. All the data from the old volumes will have to be manually moved over. Defining this environment variable (and making sure all docker-compose commands are run relative to this file) will prevent this from happening. I debated between two values for COMPOSE_PROJECT_NAME: `docker-compose` and `sourcegraph-docker-compose`. `docker-compose` should allow our existing users to upgrade without any manual migrations, but it's more ambiguous than `sourcegraph-docker-compose`. We could choose to set `COMPOSE_PROJECT_NAME=sourcegraph-docker-compose`, but we'll need to figure out a migration path for our existing users (dump the postgres database?) .
|
cc @slimsag PTAL and weigh in |
I think that If we start trying to suggest the docker-compose method over the server method for dev laptop deployments, we would want to do something else. |
slimsag
approved these changes
Feb 28, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
COMPOSE_PROJECT_NAME defines a namespace that docker-compose prefixes all networks, containers, and volumes with. This environment variable wasn't previously set, in which case
docker-composedefaultsCOMPOSE_PROJECT_NAMEto thebasenameof the folder that contains thedocker-compose.yamlfile (literallydocker-composein our case).Not defining this variable has worked up until now, but docker-compose will treat all resources defined in
docker-compose.yamlas brand new if the folder containsdocker-compose.yamlwas ever renamed. All the data from the old volumes will have to be manually moved over. Defining this environment variable (and making sure all docker-compose commands are run relative to this file) will prevent this from happening.I debated between two values for
COMPOSE_PROJECT_NAME:docker-composesourcegraph-docker-compose.docker-composeshould allow our existing users to upgrade without any manual migrations, but it's more ambiguous thansourcegraph-docker-compose. We could choose to setCOMPOSE_PROJECT_NAME=sourcegraph-docker-compose, but we'll need to figure out a migration path for our existing users (dump the PostgreSQL database?) .