Docker Community Forums

Share and learn in the Docker community.

DTR UI has issues getting accounts and other meta info from UCP

Hi there,

this is my story:
I am currently setting up a UCP / DTR Cluster for a customer. Requests are externally load balanced by some netscaler setup (managed by closed admin team - no further insights on that so far for me).
UCP / DTR requests are forwarded based on hostname (ducp.x.y and dtr.x.y) as outlined further down.
UCP works fine - DTR setup went smooth after fixing some CA issues and just accessing the UI and clicking around works nice and flawless.

Issue:
When accessing DTR use cases like “new repository” the Chrome dev-console reveals that under the hood DTR UI gets errors when accessing /enzi/… URLs. Thus (almost) no UCP interaction seems possible … as far as I know the enzi backend resides “in” UCP (?) so the calls should somehow be routed to UCP - but console shows https://dtr.x.y/enzi/… calls.

Details:
There is a three node UCP cluster and on each manager node there is a DTR instance deployed on ports 8080/8443 (we do not yet have workers available for that - but that should not be of interest for my issue).
UCP access is possible without trouble (Port 443 default).
DTR can also be accessed without trouble on first glance.
But - if you access say “combined” use cases like “new repository” I get the before mentioned problems accessing https://dtr.x.y/enzi/v0/accounts … URLs.
As far as I can tell all calls to this URL fail.

Looking at dtr-nginx logs doesn’t bring up any more info.

ucp-api logs show loads of calls to API SegmentIo to fail but these shouldn’t be an issue either. btw - why do these take place if metrics are opted out in UCP ?

Any hints ? Where else to look ?

I should probably add the versions:

  • docker-ee 19.03.5
  • ucp 3.2.3
  • dtr 2.7.4

Hi there - did nobody ever experience this issue ? Or did I include too little info ?

Anybody out there with a similar scenario and no such issues ?

As running UCP and DTR on the same host is neither supported, not recommended, I guess there any not many people experienced with your situation.

Works like a charm if UCP and DTR are running on different nodes.

@meyay thank you for your answer/comment.

I am aware that this scenario is neither supported, nor recommend - but still … it works - on two other installations (one of them all on one swarm manager host - non production but a helpful demo setup).

I am still curious if there is a way to track the 502 in this particular issue down to the root cause.

As written above - all other API and UI calls/requests work fine … only the /enzi/ is in trouble - and I tried to track it on the different -auth- container instances but to no avail as of yet.

Any hints on how to actually debug “into” it - given a decent dose of docker knowledge of course.
Or would You guys advise to leave it untouched - drop all, reinstall and hope for the best ?