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

Re: Using cluster DNS for the integrated registry

Ok, I can test some scenarios out.

Anyone have any suggestions for a way around requiring users to modify /etc/resolv.conf? I see that Docker has a --dns flag for the daemon, but it appears that is only used to set up resolv.conf in containers, so that’s not helpful.

On the Docker roadmap (for 1.8 or later) is configurable namespace support, meaning we’d be able to drop in a config file for docker that says that when you see the image namespace docker-registry.default.svc.cluster.local, use registry 172.x.x.x. If we had that today, that would solve this problem, but it’s not here yet…


> On May 28, 2015, at 10:12 AM, Clayton Coleman <ccoleman redhat com> wrote:
> If we need a patch to skydns to avoid ourselves as master, it should not be too hard to land.  At the point where we initialize DNS we know our ips and we can pass resolvers in directly.
>> On May 28, 2015, at 10:00 AM, Andy Goldstein <agoldste redhat com> wrote:
>> I am not very familiar with how SkyDNS works and will need to look into it. If anyone else knows, please chime in! :-)
>> Andy
>>> On May 28, 2015, at 9:50 AM, Erik M Jacobs <ejacobs redhat com> wrote:
>>> Hi Andy,
>>> We are already seeing pretty serious issues when SkyDNS is used as a
>>> resolver for the main system - see Jorge Morales' thread on the
>>> openshiftbeta list.
>>> Does SkyDNS automatically perform lookups using the *second* (or
>>> further) resolver from /etc/resolv.conf? Otherwise when my system tries
>>> to lookup "registry.access.redhat.com" it's going to ask SkyDNS and then
>>> SkyDNS is going to ask... itself...
>>> Erik M Jacobs, RHCA
>>> Principal Technical Marketing Manager, OpenShift Enterprise
>>> Red Hat, Inc.
>>> Phone: 646.462.3745
>>> Email: ejacobs redhat com
>>> AOL Instant Messenger: ejacobsatredhat
>>> Twitter: @ErikonOpen
>>> Freenode: thoraxe
>>>> On 05/28/2015 09:22 AM, Andy Goldstein wrote:
>>>> We are looking to move from using the docker-registry service’s IP to its cluster DNS entry (docker-registry.default.svc.cluster.local) to make certificate generation and push/pull secret usage easier. Currently, the master caches the registry’s service IP and uses that when creating image references in image streams. If the service is deleted and recreated, it most likely gets a new IP, invalidating previously generated image references, and you also have to restart the master for it to pick up the new IP. Additionally, if you want the registry to use TLS, you must generate a certificate for it, and any time the IP changes, you’ll have to generate a new certificate.
>>>> We’d like to use the cluster DNS entry exclusively, but there are some challenges. The biggest is that in order for Docker to be able to talk to the registry using its DNS entry, the host where Docker is running must use the IP address of the OpenShift master as a resolver for DNS. This is straightforward to implement for Ansible-based installations (we have a Trello card to do this work soon). But for developers running OpenShift from source and anyone running OpenShift via ‘docker run’, it’s not automatic; you have to manually edit /etc/resolv.conf to add a nameserver entry for your master (which most likely will just be if you’re running an all-in-one setup).
>>>> I’m wondering if anyone has any ideas for a way to eliminate the need to manually edit /etc/resolv.conf on your host and still have the host’s Docker daemon be able to resolve cluster DNS entries like the registry?
>>>> TIA,
>>>> Andy
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev lists openshift redhat com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>> _______________________________________________
>> dev mailing list
>> dev lists openshift redhat com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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