Compose projects improvements

[mathroc]

Is your feature request related to a problem? Please describe.

My use case to use lazydocker from a devcontainer project. I'm using devpod to start them.

It reads a .devcontainer.devcontainer.json config file to find the docker-compose.json config and from there start its services, but it also applies features to them which are basically docker image build steps. so the running containers are not all exactly the one defined in docker-compose.yaml. It also supports merging docker-compose.yaml files (same as COMPOSE_PROFILES does).

Once the containers are started it'll start an IDE in remote dev mode. so the IDE terminal will run inside the main container. In that main container, I have a devcontainer feature that mounts the Docker socket and install docker. Then I would like to use lazydocker docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock lazyteam/lazydocker ... to have an overview of the services in that project only.

currently it will list all running containers, and won't understand that some of them are running in compose projects

Describe the solution you'd like

I think there are 2 sides to this:

filtering

Maybe it's as easy as adding a --filter-label a.label.name=some.label.value option. It could be used with the project name or config hash. And would solve 90% of this specific issue.

better compose project detection

I don't know how compose projects are detected but using the container labels to detect when a container belong to a project could improve things a lot I think. Some of the things we can get from the labels:

• the project name: com.docker.compose.project
• the config hash: com.docker.compose.config-hash
• the service name: com.docker.compose.service
• the service image: com.docker.compose.image
• the list of compose files : com.docker.compose.project.config_files
• the project dir: com.docker.compose.project.working_dir
• the project env file: com.docker.compose.project.environment_file

This is more work but would make the tool better for other use cases too. Easier to list running projects, switch between them etc.

The last 3 labels I listed are file/dir paths, but when running lazydocker from inside another container the path won't match so relying on those as little as possible would be nice. We can always mount the correct folders in the container but if it can be avoided it's even better

Describe alternatives you've considered

Didn't found alternatives yet

related issues:

• Make it easier to deploy lazydocker as part of a container 'stack' #200
• Switching projects #189
• Scope containers to project #565
• Add docker-compose profile support #423