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:

lazydocker/pkg/commands/docker.go

Lines 249 to 290 in bd16a78

	func (c *DockerCommand) assignContainersToServices(containers []*Container, services []*Service) {
	L:
	for _, service := range services {
	for _, container := range containers {
	if !container.OneOff && container.ServiceName == service.Name {
	service.Container = container
	continue L
	}
	}
	service.Container = nil
	}
	}
	// filterOutExited filters out the exited containers if c.ShowExited is false
	func (c *DockerCommand) filterOutExited(containers []*Container) []*Container {
	if c.ShowExited {
	return containers
	}
	toReturn := []*Container{}
	for _, container := range containers {
	if container.Container.State != "exited" {
	toReturn = append(toReturn, container)
	}
	}
	return toReturn
	}
	// obtainStandaloneContainers returns standalone containers. Standalone containers are containers which are either one-off containers, or whose service is not part of this docker-compose context
	func (c *DockerCommand) obtainStandaloneContainers(containers []*Container, services []*Service) []*Container {
	standaloneContainers := []*Container{}
	L:
	for _, container := range containers {
	for _, service := range services {
	if !container.OneOff && container.ServiceName != "" && container.ServiceName == service.Name {
	continue L
	}
	}
	standaloneContainers = append(standaloneContainers, container)
	}
	return standaloneContainers
	}

[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!

[jesseduffield]

Should be fixed by #774 (v0.25.0). Let me know if the issue persists: that PR was intended to fix a bunch of issues in one go.