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

[mag37]

I think I'm onto something. Had the issue again with a different stack entirely.

I think the issue stems from docker's project entity and the -p flag in docker compose specifically. When doing docker-compose up -d in the containers folder by itself, I'm getting the following error, which coincidentally is the same error that I get when trying to update it using dockcheck.

Error response from daemon: Conflict. The container name "/container" is already in use by container "{long_string}". You have to remove (or rename) that container to be able to reuse that name.

Once I redo the command specifying the project like so docker-compose -p project up -d, the container updates as normal.

I think what's happening is that dockcheck doesn't know that the container was launched using the -p parameter. I'm not 100% sure if that's something that you can fix, but I'm fairly sure if there's a way for dockcheck to... check if that's the case before attempting to up -d the container, and pass the parameter and value if it is, that would solve the issue!

Originally posted by @kennywasafk in #117

[mag37]

Comment copied, originally posted in https://github.com/mag37/dockcheck/issues/117#issuecomment-2851061392

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.

[mag37]

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.