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.

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.

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 ?