Closed SAOPP closed 2 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?
Yep, due to some features, it now looks like this on this host.
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.
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.
@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"
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.
@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.
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.
I like that idea. I'll take a look at implementing it soon.
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.
And btw, Watchtower example of scope is very good solution :+1:
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...