mirror of
https://github.com/mageddo/dns-proxy-server.git
synced 2026-04-25 09:25:56 +03:00
[GH-ISSUE #384] Resolution of host.docker goes to the container hosting DPS, rather than the host. #135
Labels
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/dns-proxy-server-mageddo#135
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lflare on GitHub (Mar 20, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/384
As also mentioned in #380, I recently noticed that a few production applications I have suddenly stopped being able to connect to my database, which is hosted on the host's network stack. This configuration was done through simply specifying
host.dockerin the configuration fields, and I had no issue with it up till 3.13.1.However just today, as I have most of my containers on auto-update for the most parts, including DPS, when DPS updated to 3.14, I noticed that
host.dockerstopped resolving to172.18.0.1, and instead started resolving to172.18.0.254, which was the IP address of the DPS container. I understand that the resolution ofhost.dockermight have changed, but perhaps it would be great to specify this as a potentially breaking change?@mageddo commented on GitHub (Mar 20, 2023):
Hey @lflare , it isn't a
breaking changeplanned breaking change, it's a bug, sorry for that, the #380 was supposed to do a better ensure of the feature behavior, someway it broke your use case.You are running DPS on a container, right?
@mageddo commented on GitHub (Mar 21, 2023):
Are you using the latest tag? I wouldn't recommend you to use the
latesttag on environments or "auto update" the container to the latest version automatically, DPS latest tag is used for the very recent versions including pre-releases.It would be better before upgrade to test your usecases then release it to your prod env. See a bit more information at Reproducible builds.
I intend to respect major, minor and minor releasing but bugs are an unexpected behavior.
@mageddo commented on GitHub (Mar 21, 2023):
3.14.4 is out, it fixes the this issue, can you try it?
@lflare commented on GitHub (Mar 21, 2023):
The issue seems to have been resolved. Thanks for the quick turnaround.
With regards to the stability and reproducibility of builds, perhaps there can be some kind of
productiontag, or perhaps having anightly/unstabletag instead? I think Docker defaults to thelatesttag when it comes to pulling or running an image, so perhaps it might be better releasing new versions under a different tag,unstableornightly, letting it get enough traction and bug stomping before re-releasing it under thelatesttag?@mageddo commented on GitHub (Mar 22, 2023):
That's good news.
Sounds like a good idea, I will change the latest to latest stable version and create a
nightlytag.