Fix: Use exact service name match when searching container labels #39
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is an issue with
findContainerByServiceName
where it incorrectly matches containers with similar names, specifically when one service name is a prefix of the other.The check that the label contains the string
traefik.<svcType>.services.<svcName>
will match for both the service name<svcName>
but also services such as<svcName>-suffix
. If the docker container for the longer service is looked up first, then it will incorrectly retrieve the port binding from that container.The labels should be in the format
traefik.<svcType>.services.<svcName>.<attribute>
so just add a dot at the end of the needle and useHasPrefix()
to ensure an exact match. The added test verifies the fix for this issue wherehello
would end up with"http://192.168.100.100:5566"
instead of5555
. Unfortunately, since it depends in which order the containers will be iterated over, it doesn't fail (without the fix) all the time.Here is the output of a non-passing run: