UPDATE: You can now use the top-level name property in your docker-compose YAML file. This is available from Docker Compose v2.3.3
This is the result of the #745 proposal. An issue which persevered for about 8 years.
Previously:
Right now, we can use the .env file to set the custom project name like this:
COMPOSE_PROJECT_NAME=SOMEPROJECTNAME
It's not flexible, but it's better than nothing. Currently, there is an open issue regarding this as a proposal.
Answer from Ayushya on Stack OverflowUPDATE: You can now use the top-level name property in your docker-compose YAML file. This is available from Docker Compose v2.3.3
This is the result of the #745 proposal. An issue which persevered for about 8 years.
Previously:
Right now, we can use the .env file to set the custom project name like this:
COMPOSE_PROJECT_NAME=SOMEPROJECTNAME
It's not flexible, but it's better than nothing. Currently, there is an open issue regarding this as a proposal.
I know this question was asked a long time ago, but I ran into the same problem. There's a suggestion to add the feature https://github.com/docker/compose/issues/745, but they don't want to.
However, I have a Makefile in the root of the directory and then you can add something like in the Makefile:
.PHONY: container-name
container-name:
docker-compose -p $PROJECT_NAME up -d container-name
and then run make container-name
I know it isn't what you asked for, but could maybe make your life a bit easier.
Videos
There's a relevant issue on Github for Docker compose that you might want to check out.
This is just an answer based on my initial comment.
When building multiple services off of the same image it is usually safe to just build it again. In this case, bundle can just build .. Since you are just building web again, it will be cached (thus building quickly) and have the same image ID as well.
This can be done in with a parameter of the docker-compose call:
$> docker-compose -p THISISMYPROJECT_AND_NWK_NAME up -d
Unfortunately there is no way to persist it at the moment. (see: https://github.com/docker/compose/issues/745)
That's why I personally prefer adding a bash alias for my projects in ~/.bash_aliases (Debian based Linux) for example:
# project PROJECT shortcuts
alias dc_PROJECT_up='docker-compose -p PROJECT up -d'
alias dc_PROJECT_down='docker-compose -p PROJECT down'
# general docker compose shortcuts
alias dc='docker-compose '
alias dc_up='docker-compose up -d'
alias dc_down='docker-compose down'
So I can call dc_PROJECT_up to start my project with a project name PROJECT. The network name is PROJECT_default then.
Additionally you can setup additional networks with custom names in the docker-composer.yml like this (v. 2.1):
version: '2.1'
...
networks:
mynwk:
driver: bridge
name: mynwk
...
You can check this with the following command:
$> docker network ls
You should get a list of networks including yours and the default one.
you can create an .env file with key=value options such as
COMPOSE_PROJECT_NAME={project name}
you should note that this will only work when the .env file is in the current path
If you run docker-compose multiple times, it uses the project name to keep one directory's containers, networks, and volumes separate from another's. Compose doesn't keep any filesystem state or run a background daemon, so metadata on the containers is the only way to keep track of this.
Say you have three Compose projects, and project-a/docker-compose.yml, project-b/docker-compose.yml, and project-c/docker-compose.yml all have a service named db:. Because their project names are different, Compose knows that it shouldn't reuse one db container for another project, it knows which container should be destroyed by docker-compose down, and so on.
A docker-compose -p option is required if you want to run multiple copies of the same Compose stack in the same directory. Otherwise the directory name is used as the default project name, and they'd conflict with each other. That's probably what Visual Studio is thinking about.
If you look at docker ps, docker network ls, and docker volume ls output you will see the name included in object names, project-a_db_1. If you use the detailed inspect forms of these commands you will see some Compose-related labels, and these are what Compose actually looks for.
By default, Compose bases the project name on basename of the directory compose
commands are run from. The project name can be overridden either by
passing a -p / --project-name option for each command or setting the
COMPOSE_PROJECT_NAME environment variable.
Use case is basically to maintain different projects with this. For e.g.:- You can use same docker-compose.yml to have 2 different projects.
In the command which you mentioned
docker-compose -f "D:\Trials\Docker\VsDokWeb\DokWeb3\docker-compose.yml" -f "D:\Trials\Docker\VsDokWeb\DokWeb3\docker-compose.override.yml" -f "D:\Trials\Docker\VsDokWeb\DokWeb3\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose5511081461456614166 --no-ansi config
docker-compose -f "D:\Trials\Docker\VsDokWeb\DokWeb3\docker-compose.yml" -f "D:\Trials\Docker\VsDokWeb\DokWeb3\docker-compose.override.yml" -f "D:\Trials\Docker\VsDokWeb\DokWeb3\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose5511081461456614166 --no-ansi build
docker-compose -f "D:\Trials\Docker\VsDokWeb\DokWeb3\docker-compose.yml" -f "D:\Trials\Docker\VsDokWeb\DokWeb3\docker-compose.override.yml" -f "D:\Trials\Docker\VsDokWeb\DokWeb3\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose5511081461456614166 --no-ansi up -d --no-build --force-recreate --remove-orphans
If you see, it's manipulating the same project and that's why -p is given.