jittering / traefik-kop

A dynamic docker->redis->traefik discovery agent
MIT License
189 stars 14 forks source link

Possibility to ignoring specific containers #36

Closed SAOPP closed 2 months ago

SAOPP commented 4 months ago

Hi there!

Is it possible to add a label to indicate the names of those containers that should not be monitored?

I encountered on one of my hosts the fact that there was already a kop there, and I needed to add several new services that had to be monitored by another (new) kop to another traefik, and it turns out that I can't ignore the old containers that work in conjunction with old kop instance, and the wrong entries still end up on my other traffic...

chetan commented 4 months ago

@SAOPP I'm not sure I understand your setup here. Are you trying to run two instances of kop on a single docker host, each pushing services to different redis+traefik instances?

SAOPP commented 4 months ago

Yep, due to some features, it now looks like this on this host.

chetan commented 3 months ago

Still not sure what you're looking for here. Please re-open and add more info if it's something you're still interested in.

SAOPP commented 3 months ago

Hi! I already forgot that I left such a request. :smile:

I was talking about a flag that would contain the names of containers that should be ignored, for example:

variable: "container_name_1, container_name_2"

For what? To ignore the necessary containers, even if it's containers have traefik labels.

chetan commented 3 months ago

@SAOPP so you want to configure traefik-kop to ignore containers specified as a list in the variable? So something like:

services:
  traefik-kop:
    image: "ghcr.io/jittering/traefik-kop:latest"
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - "REDIS_ADDR=192.168.1.50:6379"
      - "BIND_IP=192.168.1.75"
      - "IGNORE_CONTAINERS=container_name_1, container_name_2"
PARitter commented 3 months ago

Wouldn't it be better practice to do this with container labels - a label you can put on a container that tells Traffic-Kop to ignore this container. Or maybe a switch on Traffic-Kop that tells it only to process containers that have a specfic label?

e.g., the "enable" label use by Watchtower

Doing this you don't need to maintain a "list" inside traffic-kop and update/restart the container as your collection of containers changes - you just let each container declare its intent as it comes up. Much easier to manage if the container collection is in any way dynamic.

chetan commented 3 months ago

@PARitter agree, however it sounds like the specific use-case here, which I don't entirely understand, somehow has two separate traefik-kop instances scanning the same container. So they want one of the kops to process it but not the other.

PARitter commented 3 months ago

Seems to me you could still handle that use case in a simple/clean way using labels. Just let Traffic-Kop take a "namespace" of sorts that it will manage, which can be set using environment varialbles. And then let each container declare what Traffic-Kop "namespace" it wants to manage its traffic using a label. E.g., create a traffic-kop for "internal-services" and one for "external-services" and then let each container declare using a label which should react to it (perhaps even allowing a container to be part of more than 1 namespace).

I know I'm just a random voice responding on GitHub, but it seems to me that having a service like Traffic-Kop use provisioned lists of containers it should manage is a really poor idea. If you are going to do that just set up the HTTP proxy (nginx, traefic, whatever) and provision the routes! The whole idea of Traffic-Kop is to automate this - and provisioning lists of containers is not very automated.

chetan commented 3 months ago

I like that idea. I'll take a look at implementing it soon.

SAOPP commented 3 months ago

Hi!

I like the main idea of @PARitter :+1: But as @chetan write, with labels all instances will be ignore some of, so need some flexible case for ignoring container for one instance only.

SAOPP commented 3 months ago

And btw, Watchtower example of scope is very good solution :+1:

chetan commented 3 months ago

I've got a tentative patch for this. Please review the readme and let me know your thoughts.