No instances found for container


#1

We have a customer who is reporting that they are seeing this repeated over and over in the logs on their appliance server:

May 22 11:58:37 dvlva0bt docker[5692]: ERROR 2018/05/22 15:58:37 premkit/log/gin.go:52 [GIN] 401 |    24.826µs | 10.4.12.110:3512 | POST   /api/v1/session/ping
May 22 11:58:45 dvlva0bt docker[5955]: WARN 2018-05-22T15:58:45+00:00 [replicated-native] templates_context_start.go:118 No instances found for container (MyContainerName, Container Image Name), failed to retrieve private ip address

Is this something we can resolve?


#2

Tooky,

That sounds like a sequencing issue. If one container has a template function that references another (for instance, with the NodePrivateIPAddress function) then that container must start after the one it references - otherwise the value won’t have been populated yet. This can be enforced with subscriptions - Marc’s written up how to use them here.


#3

Sorry about the slow reply here. I’ve just looked properly at your answer.

I found this in out replicated.yml

identity:
  enabled: '{{repl if ConfigOptionNotEquals "auth_source" "auth_type_internal"}}true{{repl else}}false{{repl end}}'
  provisioner: 'http://{{repl NodePrivateIPAddress "MyContainerName" "Container Image Name"}}:6006'
  sources:
  - source: ldap
    enabled: '{{repl if ConfigOptionEquals "auth_source" "auth_type_ldap"}}true{{repl else}}false{{repl end}}'
  - source: ldap_advanced
    enabled: '{{repl if ConfigOptionEquals "auth_source" "auth_type_ldap_advanced"}}true{{repl else}}false{{repl end}}'

which must have been copy and pasted from https://help.replicated.com/docs/ldap-and-identity/config/

The interesting thing is that LDAP auth seems to work ok! What should we have in there?


#4

Does your LDAP auth use a provisioner hosted as part of your app? (that’s what this looks like)


#5

No, we just use the Identity API to check credentials at this point. The provisioner is for syncing tables, right?

Can we just remove that line?


#6

I don’t think that line (as currently written) will ever produce useful output, as it is evaluated before any components are scheduled - and there’s no way to sequence it to run after components are scheduled.