Service and Container correlation is broken

[pvande]

Describe the bug When multiple projects use the same service names, it's possible – and potentially common – for the listed services to refer to another project's containers.

To Reproduce Steps to reproduce the behavior:

1. Create two separate docker-compose.yml files in two different directories.
2. Add both an app service and a project-specific service to each docker-compose.yml file.
3. Build and run both project's containers.
4. Run lazydocker in both projects.

Expected behaviour Each instance of lazydocker shows two services, and both services refer to different containers.

Observed behavior lazydocker matches the Service record against the first Container with a matching service name label. This can be easily validated by examining the com.docker.compose.project label in the "Container Config" panel for the listed services.

This bug has a few knock-on effects:

• The Containers panel only shows containers that have a service name that does not match a Service in the current project. If (e.g.) the app Service has captured the container for the wrong project, the container for the correct app Service is also inaccessible.
• Since the docker-compose project name cannot be reliably determined externally (without introducing a new convention), lazydocker currently relies on the appropriate label of the first Service's container to determine the project name (falling back to $PWD). If that Service has captured the container for the wrong project, the displayed project name will also be incorrect.

Desktop (please complete the following information):

• OS: macOS 10.14.5
• Lazydocker v0.5.5

Additional context

The Service and Container matching behavior described is supported by a reading of the current logic here: https://github.com/jesseduffield/lazydocker/blob/bd16a78b06542bb956d869e4d0285188fe6353e9/pkg/commands/docker.go#L249-L290

[jesseduffield]

Damn this is tricky. Does anybody know what might be a better way of linking containers to services?

[pvande]

@jesseduffield Untested thoughts:

• Right now, lazydocker is using docker-compose config --hash='*' to enumerate the services available, which returns the hash of the service's config as an ID. That ID can be correlated by inspecting the docker container with a corresponding label (as in docker container list -aqf label=com.docker.compose.config-hash=${CONFIG_HASH}, yielding one or more container IDs).
• Alternately, docker-compose ps -q will display all of the container IDs that are part of the "current" docker-compose project. Each of these containers contains labels naming the service, project name, config has, container number (for multi-container services), and more.

If nobody else jumps on this quickly, I may take a stab at it myself – though I'm sure most others would be a fair sight faster. :)

[dsschneidermann]

This is causing some grief in our tooling setup for me. It looks like the PR above has already gone down some paths, that seem to have not worked out very well, race conditions and so.. Do we have any other options for approaches to fix this?

My proposal here is: would it be possible to pass --filter label=value arguments along from the command-line to the whichever "docker ps" / "docker container ls" commands that are invoked to discover containers and such?

The reasoning for this is as a workaround; docker-compose makes sure to set the "com.docker-compose.project" label on starts and I have access to the project name from outside (usually this is the folder name, or COMPOSE_PROJECT_NAME). If this is a viable change to make, I'll gladly try a stab at the PR.

With the additional filtering, lazydocker won't be able to show "standalone containers", but that is an acceptable loss IMO when using it specifically for project monitoring.

[jotavemonte]

@jesseduffield Hello! I opened a PR to fix this issue. Please check out when you have time #633 .

Thank you!