Allow colors for container log messages to be specified in docker-compose.yml

[jwiegley]

When debugging a particular group of containers run with docker-compose, one becomes very familiar with looking for messages reported from a certain color. However, every once in a while these colors unpredictably change. It would be nice if the RGB code could be specified for each container in the docker-compose.yml file, to ensure the colors are always what I expect.

Including @nweston, whose brought this idea to my attention.

[mutchco]

I second this

[theskipster]

+1

In addition, 'red' should not be removed from the colours to be chosen, as it denotes something has gone wrong.

[mrglaser]

+1

This would be incredibly helpful in particular during development phases where you up and down dockers a lot. Colors keep changing each time as of now.

[Greek64]

+1
It happens quite frequently that some of the most talkative containers get the same color (or pretty much the same), which makes differentiating their log outputs a bit tedious.
And up/downing the whole service bundle just to switch the colors seems a bit of an overkill...

[michaelfranzl]

+1.

This would be very useful. Right now, it seems that the colors change randomly after each restart.

If colors are not made configurable, at least they should stay constant over time.

[Rafalsky]

+1

Where on the source colors are specified. Like to know how complicated pull request will be.

[Johanneke]

+1

Would be great to config this in the docker-compose file :-)

[michaelchadwick]

This would be a great feature.

@Rafalsky I think the relevant code starts here: https://github.com/docker/compose/blob/master/compose/cli/log_printer.py#L43-L44

def build_log_presenters(service_names, monochrome):
    ...
    for color_func in cycle([no_color] if monochrome else colors.rainbow()):
        yield LogPresenter(prefix_width, color_func)
    ...

colors.rainbow() seems to be defined here: https://github.com/docker/compose/blob/master/compose/cli/colors.py#L43-L49

def rainbow():
    cs = ['cyan', 'yellow', 'green', 'magenta', 'red', 'blue',
          'intense_cyan', 'intense_yellow', 'intense_green',
          'intense_magenta', 'intense_red', 'intense_blue']

    for c in cs:
        yield globals()[c]

I've looked at it once before, but can't exactly figure out the best way to implement this feature, but hope that helps someone!

[chris-crone]

Thanks for the report!

It's unlikely that we'd add log output colours to the Compose format but it would definitely help if the colours were deterministic between runs.

[ghost]

It's very annoying seeing red output to the console when nothing is going wrong -_-

[markus-lundin-86]

+1

I spawn test containers with a color themed naming convention, rather then a numeric one. i.e. "container-blue". It is initially confusing when log-color does not match the naming convention for new project-members.

[naltatis]

I'm piping my output through colout as a workaround. Not pretty but works :)
https://github.com/neuland/micro-frontends/tree/master/2-composition-universal

docker-compose up --build | colout "team_green_1" green | colout "team_blue_1" cyan | colout "team_red_1" red | colout "nginx_1" white"

[xinin]

+1
It could be something like

version: '3.7'
services:
  container1:
    **labels: 
      color: red**
    container_name: container_red
  container2:
    **labels: 
      color: blue**
    container_name: container_blue

[Greek64]

@xinin
I don't think the parameter setting is the problem here.

After having a look through the code, one can see that the function that sets the color to the log stream output is doing so in a carousel manner from an array of predefined colors (as many of us would have expected), but is totally independent of the rest of the code (in the sense that it has no information about the container the log stream comes from).

To make the log color container specific would mean to expand several functions with extra arguments and drag this information down to this level.

If I get some free time (which will be a bit tough before this summer) I will take a closer look at it.

---

For anyone interested, here's a jumpstart:

Function log_printer_from_project (/compose/cli/main.py) creates a new LogPrinter class (/compose/cli/log_printer.py) instance. It passes to the constructor an instance of a LogPresenter class (/compose/cli/log_printer.py) returned from build_log_presenters (/compose/cli/log_printer.py), which is the actual function that sets the colors (it returns LogPresenters with set colors). The LogPrinter than uses this array of LogPresenters to format the container output streams.

The build_log_presenters function knows the actual name of the container (since it does format it accordingly), but that's it. We now only have to relay to it also the color information per container.

[bourdeau]

If at least red could be excluded from container name, and kept for stderr. It's a bit disturbing to see red as container name.

[Jamtastic808]

Yes. PLEASE.

[alp82]

This would be a great feature.

[derekrprice]

I have 9 containers starting and one of them has started to show up frequently with a black container name, which is really annoying on my black terminal background. The dark blue isn't much better.

[sparkacus]

We're in the process of migrating a shed load of applications to containers and being able to define the colour a service is linked to would be super helpful for our team.

[michaelchadwick]

@naltatis thanks for the shoutout for colout! It works like a charm.

[Greek64]

@jcsirot
While I do welcome the changes, I would suggest re-opening this issue, as the PR does not actually resolve this issue, which is to Allow colors for container log messages to be specified in docker-compose.yml.

[chris-crone]

Hi @Greek64,

We see the Compose format as a way of modelling container based applications and use it not only for docker-compose but also for Swarm and Kubernetes (with docker stack deploy). As such, I don't think that a service level log colour in the format makes sense as other orchestrators wouldn't use it.

We could consider a docker-compose specific label or something though. What use case is not solved by the colours being deterministic as they are with #6996?

[Greek64]

As such, I don't think that a service level log colour in the format makes sense as other orchestrators wouldn't use it.

Yeah, that makes sense.

What use case is not solved by the colours being deterministic as they are with #6996?

Intuitively I would say the use case where you want to select a specific color to display for a specific service?
Not that I have any need for this use case at the moment (I'm actually trying to outsource the logging from the docker daemon completely), but that was the whole premise of this issue.

I guess #6996 is a good middle ground solution.