Feature Request: Group 'docker ps' items by Compose profile

Hello,

Can’t see it as having been requested before. I’m running quite a few containers now on my own self-hosting, and I make extensive use of docker-compose profiles (combined with linux CLI aliases) to make controlling the stack of containers much easier.

It would be great if the output of ‘docker ps’ was configurable (or by default) grouped containers together in the list by their profile, and allowed configurable coloring per-profile, as well as an arbitrary separator (line) between the profile groups.

When there are a large number of containers this would help greatly to quickly find the one you’re looking for.

So that terminal output would look less like this:

And more like this:

If I could colorise/attribute a colour by compose profile, that would be extremely helpful for rapid location of the block of containers, too. Mostly though, it would just be awesome for ‘docker ps’ output to be grouped by compose profile data, if it’s there.

Some sort of sort-order and grouping would be a nice idea indeed. You might want to elaborate more on how the output looks for containers that are not deployed with a profile or if you have a mix of containers with profiles and containers without profiles.

For time beeing, you can try if --filter mitigates the problem. You could use it to limit the output to a docker compose project name or (if available) to a profile.

As I didn’t use profiles, I will provide the example for the compose project name:

project_name=monitoring
docker ps --filter label=com.docker.compose.project=${project_name}

You can check if docker-compose adds a label for the profile as well and then use it as a filter:

docker inspect ${container id or name} --format '{{json .Config.Labels}}'

I can elaborate on containers that are no specified with a profile.

I think they should just be grouped into a general block ‘[ CONTAINERS ]’ or similar. The ideal default behaviour would be that containers with profiles are grouped and displayed together (or for solo containers, just on their own but in their own section as shown in the mock up image above).

There is no label automatically added by compose.

docker inspect postgres:

            "Labels": {
                "com.docker.compose.config-hash": "63b87db6aa9c04f539b7e35f20f3c1eedba57f39d1ba61e0f9c9b6c4a39c749d",
                "com.docker.compose.container-number": "1",
                "com.docker.compose.oneoff": "False",
                "com.docker.compose.project": "docker",
                "com.docker.compose.project.config_files": "docker-compose.yml",
                "com.docker.compose.project.working_dir": "/home/tom/docker",
                "com.docker.compose.service": "postgres",
                "com.docker.compose.version": "1.28.5"
            },

It can be added easily manually to the compose file:

    labels:
      - profile=apps

docker inspect postgres:

            "Labels": {
                "com.docker.compose.config-hash": "ed10cf093940fdb2ae82d12f45a1635f5141ca6beb21f4006208b6552ea6b9bf",
                "com.docker.compose.container-number": "1",
                "com.docker.compose.oneoff": "False",
                "com.docker.compose.project": "docker",
                "com.docker.compose.project.config_files": "docker-compose.yml",
                "com.docker.compose.project.working_dir": "/home/tom/docker",
                "com.docker.compose.service": "postgres",
                "com.docker.compose.version": "1.28.5",
                "profile": "apps"
            },

Ideally though, it would be automatically added to allow for searching based on profile without creating unnecessary bloat in docker-compose.yml files.

Adding the label also does not enable the --filter command to work unfortunately.

docker ps --filter label=profile=${apps}
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES


I see. It kind of feels wrong that no profile label is added, while all the other labels are.

It shouldn’t matter whether a label is self defined or auto generated. Is it safe to assume that you declared the envionment variable “apps=whatever” before you executed the docker ps command?

Maybee unrelated, but sill worth knowing: have you ever considered to define a project name when deploying your compose files? If no project name is specified, the folder name (where the compose file is) will be used. The project name will be the prefix for objects (like containers, volumes and network) by default.

Yes, seems silly not to create a label.

You are right, the syntax was bad! The filter does work:
docker ps --filter label=profile=apps


CONTAINER ID   IMAGE                           COMMAND                  CREATED          STATUS          PORTS      NAMES
d0efa98a936b   postgres:13.2-alpine            "docker-entrypoint.s…"   33 minutes ago   Up 33 minutes   5432/tcp   postgres
a64487d357bb   ghcr.io/linuxserver/wireshark   "/init"                  35 minutes ago   Up 35 minutes              wireshark

This is cool, as I can at least manually add some functionality by combining with bash aliases for each of my profile names, e.g or similar.

docps apps

But for me, it would also be really nice to include grouping by profile as a default behaviour to ‘docker ps’ so that people don’t have to add bash aliases or define a label in their docker-compose.yml.

I generally don’t bother, because usually I create a new VM to contain everything, if I feel that it would warrant its own project. Mostly because this allows me to manage the resources I provide to those containers. e.g. No. of CPU, extra RAM etc. It also helps to isolate the project as I can restrict the access that it has to the network, and which other machines it can interact with. This is particularly easy via the dedicated VM method, because I can configure it all in Proxmox via a GUI.

I am not sure if we discuss the same “project name” here. I am refering to the bracket arround a single docker compose deployment:

  -p, --project-name NAME     Specify an alternate project name
                              (default: directory name)

Good that you have an easy managable setup. No one wants to waste time with overhead :slight_smile:

I think I understand.

You mean to separate all container profile into separate project?

docker-compose.core.yml
docker-compose.system.yml
etc?

Because I use traefik labels (in docker-compose files) this would mean I have to write a rule for the reverse proxy, rather than traefik labels, as the only way to access the traefik container would be externally via port? Maybe I’m wrong?

Slightly off-topic for the feature request though :smiley:

With docker-compose the file name and project name are different things. You can even use the same file to bootstrap n independend deployments with different project name.

I don’t see how defining the traefik rules as container labels would relate to deploy compose files with the --project-name. It should work regardless.

Regarding the FR, you might be better off to raise it as issue in the Github project: Issues · moby/moby · GitHub