Multiple projects with chadburn : jobs registered/deregistered loop

[EmmanuelVella]

Hello,

I have a project that I need to deploy multiple times on my staging server, with differents COMPOSE_PROJECT_NAME. I noticed that in this case, the jobs are in registered/deregistered loop :

This is easy to reproduce with the project docker-compose example :

version: "3"
services:
  chadburn:
    image: premoweb/chadburn:latest
    depends_on:
      - nginx
    command: daemon
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

  nginx:
    image: nginx
    labels:
      chadburn.enabled: "true"
      chadburn.job-exec.datecron.schedule: "@every 5m"
      chadburn.job-exec.datecron.command: "uname -a"

Then in 2 different terminals :

COMPOSE_PROJECT_NAME=project1 docker compose up
COMPOSE_PROJECT_NAME=project2 docker compose up

I don't know how I can avoid this behavior ! Do you have a hint ?

Thank you !

[maietta]

Be sure to give each job a different name.

chadburn.job-exec.<JOB_NAME>.schedule: .....

Chadburn, like Ofelia to which this project is forked from, relies on Docker Labels under the hood to track and take action upon the containers. Even if your application stack, as defined by docker compose names are different, your re-use of the datecron between multiple projects will result in a conflict despite the logical idea that they'd be different because of the stack names.

Docker labels aren't that smart. We humans have to ensure the labels are different.

[EmmanuelVella]

Thank you very much for your answer, I just tested like this and it works !

- "chadburn.job-exec.${COMPOSE_PROJECT_NAME}:datecron.schedule=@every 5m"
- "chadburn.job-exec.${COMPOSE_PROJECT_NAME}:datecron.command=name -a"

[EmmanuelVella]

I spoke too fast, now each chadburn container picks up all labels :

Not sure it's a real issue however...

[maietta]

Hmm.... can't jump in at the moment to help as I'm quite busy with other things. I think someone else mentioned this on the Ofelia project. Have you take a look there yet? Chadburn is a hard fork and will be undergoing extensive work sometime in the near future, provided I can get all my ducks lined up, so to speak. Given they were mostly the same codebase at one point, might be worth a look.

[EmmanuelVella]

Indeed, I found a correponding issue : mcuadros/ofelia#156. Last answer says to have only one ofelia instance per host.

[maietta]

That is correct.

You'll need Chadburn running for the host system, then define your labels for each of your apps. You don't need, nor should you include Chadburn itself for each stack.

Does that actually look like the problem?

[C-Duv]

I guess having multiple Chadburn/Ofelia on the same Docker host seems weird as one is bound to Docker labels of a unique Docker daemon.

But as OP's situation it can happen.
Say when you are working on multiple projects all using Chadburn as scheduler.

Is there a way to change the labels' prefix a given Chadburn container/instance is looking at?

[maietta]

Hi @C-Duv. I'm not sure I follow.

If there was a convenient way to prefix the labels based on project, such as in the case of a stack deployment, that'd be helpful to many I'm certain. Some might call it having a scope or perhaps having context. Whatever the nomenclature would be, it probably needs to exist.

Adding this though shouldn't be trivial. It should be carefully considered and implemented and well documented.. Maybe I should start soliciting an open discussion among Chadburn/Ofelia users to help shape the major release. There are a lot of things that must be addressed and it basically requires a major overhaul to get right.

Right now, Chadburn is stable and that's the way I like it but it's clearly not good enough for the more complex use-cases.

One idea that I have would be to create the documentation first and let the community help me design a future build and layout all the use-cases. I can then get to work building from that along with all the examples and tests. In this way, I think it'd be easier to build from the ground up. It would help catch any design problems early and let me check off all the issues others have raised over the years in Chadburn and Ofelia.

I'm mulling over the idea of a fresh new project with a new name entirely. One major tasks is that I want this to work in a Docker Swarm and Kubernetes Clusters easily. I'd also like to introduce an API and Web UI as well, all held from with in portable binary. I'm currently building another tool based around Pocketbase as a framework.

Your thoughts are appreciated.

[C-Duv]

I am certainly not aware of the impact my idea can have on core code but the reasoning was the following:

• Containers expose their labels to Docker daemon.
• Chadburn (or Ofelia) asks labels of all running containers to Docker and ignores any label whose name does not starts by chadburn..
• Multiple running Chadburn all speaks with the same Docker daemon, so they read the same labels and react to them (the same way).

If both (or more) Chaburn instance were ignoring the labels not meant to them two instance could be used on the same Docker host without competition.

So yes, the simple solution (I think) is to have containers using a specific label prefix and one Chadburn instance being tell to use this specific label.

I don't know Go nor the Chadburn code base but I can see a labelPrefixconstant in the cli/docker-labels.go file which seems to be used by other source code files.

So adding an optional --label-prefix="foo." CLI option to change this variable seems a straightforward solution.

Of course, a time of exchange between users and coders on how (and if) tacle this issue is a good idea.