[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kolab / Complex Distributed Application in OpenShift




----- Original Message -----
> On 2014-11-07 00:38, Clayton Coleman wrote:
> >> On Nov 5, 2014, at 5:43 AM, Jeroen van Meeuwen (Kolab Systems)
> >> <vanmeeuwen kolabsys com> wrote:
> >> In case of the LDAP setup though, where what is otherwise just
> >> "989a663bc081", even just an (extra) /etc/hosts entry of
> >> "989a663bc081.local" would allow the setup to continue.
> > 
> > I believe services would get a reachable DNS entry, but not an etc
> > hosts file entry.  The reason being is that the service is the
> > mechanism by which those links are exposed.  In the absence of an
> > internal DNS server we might still expose this in the container as
> > "servicename.local"
> > 
> 
> The "service" is currently published to my other containers as a set of
> environment variables that I can just use -- I have no requirement for
> consumers of LDAP services to know anything about DNS or hostnames or
> FQDNs for as far as such would relate to their capabilities to just
> consume LDAP -- its setting up LDAP that is the problem.
> 
> So, I'm not sure how such "service" would help my primary concern of not
> being able to successfully execute setup, which requires the container
> to hold:
> 
>    - an FQDN with at least one dot (.) character,
> 
>    - which resolves to an address available on one of the local network
> interfaces,
> 
>    - and for which the IP address resolves back to the original name (not
> strictly required).
> 
> As far as I'm concerned -- replicated LDAP deployments notwithstanding
> -- no other system is interested in either one of the three.
> 
> I've noticed that /etc/hosts is already populated with an entry of
> "172.$x.$y.$z $containerId", which I believe could solve my problem
> really quickly, if the routine that does that also inserts
> "$containerId.local" on very much the same line.

Docker does not currently expose this through - we should probably open an issue on Kubernetes in the vein of the default DNS entry for each pod.  I raised that here https://github.com/GoogleCloudPlatform/kubernetes/issues/1261#issuecomment-62457810 and will follow up more.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]