Adding docker-compose project display

[art049]

I think adding something to display that some containers have been created from the same docker-compose project could be interesting.
Maybe something as htop tree view.

If you think it's worth it, what could be worth implementing in order to have a first interesting integration?

[art049]

Hello @bcicen, do you think it'd be interesting to add this feature ?
I'm really interested to implement this 😉!

[luckydonald]

I think that would be a useful feature.

[stokito]

If container started from docker-compose then it will have a group of labels with "com.docker.compose." prefix. You can make docker inspect :

 "Labels": {
            "com.docker.compose.config-hash": "0a2749064f846be47808f2330dfc21ef2cd4fd8b39926c9f48f5a2bf4cccf5ad",
            "com.docker.compose.container-number": "1",
            "com.docker.compose.oneoff": "False",
            "com.docker.compose.project": "dockerise",
            "com.docker.compose.project.config_files": "/home/dockerise/docker-compose.dev.yml",
            "com.docker.compose.project.working_dir": "/home/dockerise",
            "com.docker.compose.service": "wildfly",
            "com.docker.compose.version": "1.25.0"
 }

We can group containers if they have the same com.docker.compose.project.
Just to visualize IntelliJ have such grouping:

[pirate]

I'd pay a $50 bounty for someone to implement this (through GitTip/paypal/sponsors/whatever your platform of choice). It would vastly improve my ctop experience and I rely on ctop for about a minute ~50 times a year.

I don't know how complex the ctop internals are so it may not be enough to entice anyone, but hey, it's more than nothing and open-source is real work that doesn't have a good compensation system right now, so donations/bounties are how I try to help 🤷.

I'm imagining a UX like this for viewing docker-compose containers grouped by project in ctop (with aggregate totals for each project):

$ cd /opt/mailu
$ docker-compose up -d
$ cd /opt/matomo
$ docker-compose up -d
...
$ ctop --compose

  ctop - 18:26:16 UTC   2 projects   15 containers                                                                                                                                                                                                                         

    NAME                    CID                               CPU      MEM             NET RX/TX       IO R/W          PIDS

 + ◉  mailu                  /opt/mailu                       2%       717M            3.5G / 2.2G     314M / 6.5G     71
   ✚ ◉  mailu_admin_1          567c6e40c9f4                     0%       216M / 3.84G    622M / 847M     24M / 0B        6       
   ✚ ◉  mailu_antispam_1       99c2490bd075                     0%        71M / 3.84G    155M / 141M     28M / 54M       4
   ✚ ◉  mailu_database_1       b6531b18a9da                     1%        29M / 3.84G    523M / 382M     183M / 1.59G    15
     ◉  mailu_fetchmail_1      fe26570a0690                     0%        14M / 3.84G    910K / 877K     6M / 0B         1
   ✚ ◉  mailu_front_1          8b30aab48008                     1%        16M / 3.84G    584M / 681M     24M / 36K       4
   ✚ ◉  mailu_imap_1           82b02542519f                     0%        26M / 3.84G    2M / 4M         15M / 1M        7
     ◉  mailu_redis_1          d83e1fb2d8a4                     0%        6M / 3.84G     220M / 70M      7M / 5.47G      5
   ✚ ◉  mailu_resolver_1       8de8dc0f89fc                     0%        18M / 3.84G    362M / 167M     18M / 88K       1
   ✚ ◉  mailu_smtp_1           f926e3697ae1                     0%        44M / 3.84G    116M / 145M     9M / 74M        18
   ✚ ◉  mailu_webdav_1         04a6fc7242ad                     0%       216M / 3.84G    49K / 480B      9M / 0B         1
   ✚ ◉  mailu_webmail_1        a1e27e2af6ad                     0%        61M / 3.84G    7M / 27M        32M / 12K       9
 
 + ◉  matomo                 /opt/matomo                      1%       234M            1.9G / 1.5G     239M / 2.9G     25
     ◉  matomo_argo_1          d109f307c457                     1%        14M / 512M     566M / 262M     524K / 0B       11
   ✚ ◉  matomo_mariadb_1       4b1d45531c84                     0%       181M / 1.95G    186M / 338M     144M / 2.49G    8
     ◉  matomo_phpfpm_1        b5953347d1db                     0%        37M / 1.95G    360M / 684M     90M / 460M      4
   ✚ ◉  matomo_nginx_1         fb472389be8b                     0%         2M / 512M     566M / 262M     2M / 0B         2

[stokito]

@pirate if the project author is not interested then I'll try to implement this on Monday. Right now I have a spare week and I anyway wanted to try programming in Go

[stokito]

Added "compose project", "compose service", "compose config", "compose workdir" fields.
They are shown in container info view.
Since the fields may be empty so added a condition to show them only if they have a value.

Now I would like to discuss how to properly design UI.
Instead of rows we may show tree where branch is compose project and leafs are services:

◉  mailu               /opt/mailu
  ◉  mailu_admin_1     567c6e40c9f4       0%       216M / 3.84G    622M / 847M     24M / 0B        6       
  ◉  mailu_webmail_1   a1e27e2af6ad       0%        61M / 3.84G    7M / 27M        32M / 12K       9
◉  matomo              /opt/matomo
  ◉  matomo_argo_1     d109f307c457       1%        14M / 512M     566M / 262M     524K / 0B       11

Pros:
In tree style we may also show total aggregated memory and CPU usage for each compose project.
We may add actions like up/down the whole compose project.
Cons:
In the same time this brings a UX problem: how to sort by MEM/CPU?
If a user wants to sort by CPU then he or she is looking for most heavy processes.
But, to keep grouping we can only sort containers inside of one compose project.
The compose projects in the same time must be always sorted by name.

Or we may just add a prefix to name with compose project / service / name:

◉  mailu/admin/mailu_admin_1      567c6e40c9f4  0%       216M / 3.84G    622M / 847M     24M / 0B        6       
◉  mailu/webmail/mailu_webmail_1  a1e27e2af6ad  0%        61M / 3.84G    7M / 27M        32M / 12K       9
◉  matomo/argo/matomo_argo_1      d109f307c457  1%        14M / 512M     566M / 262M     524K / 0B       11

Pros:
More compact view but we'll have some tautology because container name usually already have compose project name and service e.g. mailu_webmail_1.
But user may set any container_name in docker-compose.yaml so we still need to prepend at least compose project.
The sort logic remains the same i.e. we consider each container as a separate unit.
Cons:
Not clear for a user how not up/down the whole compose project.
Less information shown like working dir and total CPU/MEM per compose project.

My proposition is to use a third simplest possible solution: keep almost everything as is ;)
Total usage CPU/MEM of compose project probably almost never needed. Most often it will be only one compose project executed on a computer.
In 99% of cases container name anyway contains compose project name.
Show containers as they are shown now but on name sorting always put them together i.e. first sort by compose project and only then by container name inside of the project.
This will protect from rare cases when container_name is set, or some other container has a similar name.
For each container add a menu item "docker compose: Down" and for each container info view add details about compose project.
So you can down the whole compose project from menu of any container that belongs to the same compose project.

This is easy to implement and covers most basic needs.

[pirate]

Total usage CPU/MEM of compose project probably almost never needed

The tree view with aggregate totals for each project is important in my mind 😅, because I use 3-8 compose projects on each server, with about 6 servers running at any time. Seeing high total memory/CPU/IO being used is the main thing I'm looking for as a red flag to investigate high load or failure on a particular project.

Why not sort by both? E.g. list the projects using the most aggregate memory from top -> bottom, then within each project, sort the leaf containers by memory use as well.

[stokito]

I see, we just have different usage scenarios: for me as a developer the most important is to easily shutdown compose projects but for you as server admin is more important to see usages.
Then yes, we should use a tree view.
Tomorrow I'll try to implement the tree view

[stokito]

Hi @pirate please checkout and test my branch stokito:docker_compose

[pirate]

Could you bump the grouping carets out 1 character to the left so that the hierarchy can be visually scanned a bit easier? other than that it looks great @stokito!

[stokito]

At this moment we can't: down arrow is shown if status is empty which happens only for groups while empty health check column is almost always empty by itself.
This should be implemented somehow on UI level and unfortunately this is too complicated for me and I hope @bcicen can easily make a tree.
The PR must be reviewed, discussed and accepted only then I'll continue to work on this feature.
ATM I want to test and receive a feedback. For example:

1. If this feels ok to group all non compose projects into noname group. I.e. each container always belongs to a group
2. If this feels ok with sorting, especially sorting by status field.

[luckydonald]

Could maybe the caret be a separate new first column? That way it would be on a different vertical level.

[pirate]

Everything feels ok to me @stokito, I can pay out your bounty however you prefer (message me on twitter/email to coordinate?). Would love to see it reviewed and merged too, but don't want to hold your bounty hostage because the review process is subject to @bcicen's time availability :)

[stokito]

In 6b96656 I tried to make the stack triangle look better:

I used a Small Triangle symbol because it looks better in Monospace (default font in Ubuntu's terminal). Also the symbol is from Unicode 1993 so probably it will supported much better then others newer.
We can try another triangle symbols: https://unicode-table.com/en/search/?q=Triangle
Please check how it looks on MacOS.

@pirate thank you, I just found a job so you can donate to some other project.
Anyway if you'll need anything else just ping me to stokito@gmail.com