I came across an interesting issue which i tried resolving and investigating on my own. I think i can already feel the solution with my fingertips but i just cant grasp it. ..
Any help would be really nice and would be grateful for it.
Common docker network:
local bridge, with defaul driver "Subnet": "172.19.0.0/16","Gateway": "172.19.0.1"
a proxy container (nginx) which handles ssl and two domains and internal routing to two containers on the network
"120253b9613d95bb4d540abe3676c7d309cdc9ac531cc81de9acd548737b829e": {
"Name": "youtrack",
"EndpointID": "0ff42cc51535663df36a47f79f41f4df5bdb229c411b2aa0200fffc0c3e7b824",
"MacAddress": "02:42:ac:13:00:03",
"IPv4Address": "172.19.0.3/16",
"IPv6Address": ""
},
"639a75318859f2b60c93585a77d259f919f307a3f0653fd75cbcc8cad932e3ac": {
"Name": "proxy",
"EndpointID": "7923e5fbe27e0b2a4ff3b8f765a5a2fb34b3b97c10f2545fb875facd04d71fdb",
"MacAddress": "02:42:ac:13:00:02",
"IPv4Address": "172.19.0.2/16",
"IPv6Address": ""
},
"8b0d7cf3f4d09d9fe281e742e747c9947528519e730c0e58a07bec9a6d097083": {
"Name": "gitlab",
"EndpointID": "84b454e38b9178f5f55cefb310f839de1abcd2ed0e7b58018e9522e08dfbff01",
"MacAddress": "02:42:ac:13:00:04",
"IPv4Address": "172.19.0.4/16",
"IPv6Address": ""
}
when communicating from outside world on the container-one.company.com and container-two.company.com through the proxy, there are no issues. Everything works as expected.
Now thing is theese two containers have integration through https. (VCS integration) between youtrack which is issue management and gitlab which is code git repository. And main integration property is the URL of the server. So container-one.company.com's settings include container-two.company.com domain as https point for integration. And the container-two.company.com's settings include container-one.company.com url for the VCS integration.
I have already checked that BOTH domains resolve to the SERVER IP and not Docker's internal IP.
When i did testing and set up a reverse proxy with IDENTICAL config, but pointing BACK to the server. So the flow was SERVER1 which has all 3 containers and SERVER2 which only had nginx container with both of domains, but it redirected back to SERVER1 proxy. So only difference was BOTH containers resolved IP which was not of their own server, but some different server.
That's why i do think there is issue with how docker is handling network calls and it somehow tries to "optimize" both calls to go through internal docker's network instead through proxy, like all external calls.
And i can mention that Nginx's config is really only ssl termination and maping based on the domain. IF domain container-one.company.com proxy pass to youtrack container and its port and if container-two.company.com proxy pass to the gitlab cotntainer and its internal port. All plain http, no complications.
NOTE: I have tried with the solution:
ports:
- "IP:443:443"
And
--add-host property
Same behaviour.
UPDATE1: For more clarification adjusted and provided two diagrams with additional explanations and behaviour.
this is the current setup and desired setup. And as you see when trying to make VCS integration ON the same host from a YOUTRACK container to GITLAB one using FQDN it all fails, says it does not map/point to a valid repository url.
But however if you move both domains to a different server, the top-level proxy (diagram 2 which is incoming). It is actually on a different server and CONTAINER is pointing to that container (i even used the add-host property so not even a valid domain to the dummy proxy, on a different host). Then it went through.
Meanwhile, this kind of configuration (moving the FQDN from the same host to a different one and PROXYing it back to the original with NO changes to ANY of the original proxy configurations), works like a charm.
TLDR: Issue was that UFW did not let full 443:443 binding through so I had to add:
sudo ufw allow 443
sudo ufw reload
Note symptoms were:
and with ports configuration:
- "IP:443:443"
It then worked.
Full debugging was made with:
docker run --rm -it --network container:gitlab nicolaka/netshoot:latest
Which allowed all telnet,ping,curl tests to figure out that even tho ping was going through connections on port 443 did not.