ctop
ctop copied to clipboard
bcicen
Adding docker-compose project display
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?
Hello @bcicen, do you think it'd be interesting to add this feature ? I'm really interested to implement this 😉!
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:
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
@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
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.
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.
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
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!
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:
- If this feels ok to group all non compose projects into noname group. I.e. each container always belongs to a group
- If this feels ok with sorting, especially sorting by status field.
Could maybe the caret be a separate new first column? That way it would be on a different vertical level.
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 :)
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 [email protected]