Containers started with -p flag not restarted with -p flag. #174

Activity

1. mag37

   added

   bugSomething isn't workingSomething isn't working

   on May 6, 2025
2. mag37 commented on May 6, 2025

   

   mag37

   on May 6, 2025

   OwnerAuthor

   More actions

   Comment copied, originally posted in #117 (comment)

   Oh nice find!
   I just tested quickly and I think you're correct.

   • Started a container docker compose up -d
     • Saved the inspect docker inspect ABC > abc.out then shut it down again.
   • Started the same container with docker compose -p XYZ up -d
     • Saved the inspect docker inspect ABC > xyz.out and shut it down again (had to use the -p XYZ).

   The compose file was formatted like this:

   ---
   services:
     ABC:
       container_name: ABC
   ....

   When diffing the output, the only thing that changed (except for unique IDs and hashes) was:

   ### project name:
           "Config": {
                   "com.docker.compose.project": "XYZ"
   
   ### and network-name (as I didnt declare that in the compose)
               "Networks": {
                   "XYZ_default": {

   Sadly though it does not state if the -p flag is used or not and the project name can be set in a few ways.
   Quoting the docs

   Use -p to specify a project name

   Each configuration has a project name. Compose sets the project name using the following mechanisms, in order of precedence:

   • The -p command line flag
   • The COMPOSE_PROJECT_NAME environment variable
   • The top level name: variable from the config file (or the last name: from a series of config files specified using -f)
   • The basename of the project directory containing the config file (or containing the first config file specified using -f)
   • The basename of the current directory if no config file is specified Project names must contain only lowercase letters, decimal digits, dashes, and underscores, and must begin with a lowercase letter or decimal digit. If the basename of the project directory or current directory violates this constraint, you must use one of the other mechanisms.

   So I'm not entirely sure how I'd change things to take this into account. Maybe it would be safe to always use the -p flag with the value from com.docker.compose.project? Maybe it wont - there's so many different environments.
3. mag37 commented on May 6, 2025

   

   mag37

   on May 6, 2025

   Last edited by mag37

   OwnerAuthor

   More actions

   I will consider doing some testing with the -p flag.
   If it might be viable to always (or at least optionally) use the com.docker.compose.project label contents together with -p or if this causes any issues.

   From initial testing it seems to be working fine, but I wonder what will happen if you

   1. Start with docker compose up -d with eg container_name: XYZ
   2. Use the com.docker.compose.project (which will be XYZ) and restart with docker compose up -p XYZ -d
   3. Change the compose to container_name: ABC
   4. Restart the stack with docker compose up -d as you would.

   Also what happens if you use something else to orchestrate the composes.