Understanding DNS requirements

[m...@matt-j.co.uk]

Hi All,

Lots in here, but i'm really hoping someone can help out!

If you know the answers to some of this but not all, please still shout :)

I'm trying to understand how we should be configuring DNS for our cloud foundry V2 installation as currently it doesn't 'feel right'.

I'm sure i'm missing something key somewhere.

Current situation:

• We have *.ourdomain.net pointed at the GoRouter IP address.

• We have the following defined URL's in our CF deployment manifest (obviously lots removed, just left the bits to give context to the URL's).
  

name: cpg-cf-138

releases:

- name: cf

  version: 138

properties:

# properties.domain---------------

  domain: ourdomain.net

  system_domain: ourdomain.net

  system_domain_organization: org1

  app_domains:

   - ourdomain.net

  cc: &cc

    port: 80

    srv_api_uri: http://api.ourdomain.net

    external_host: ccng

  ccng: *cc

  uaa:

    port: 80

    no_ssl: false

    require_https: false

    dump_requests: true

    spring_profiles: postgresql

    url: https://uaa.ourdomain.net

    token:

        url: https://uaa.ourdomain.net/oauth/token

    login:

        url: https://uaa.ourdomain.net/login.do

 

 

Questions

1. Login not working via GoRouter like everything else

While 'cf target' works fine pointing to api.ourdomain.net (and getting passed through the gorouter as needed), login.ourdomain.net does not work via the gorouter.

The only way we could get 'cf login' to work was by having a static hosts file entry for 'login.ourdomain.net' pointing to the IP of our UAA.

This overrode the *.ourdomain.net DNS record pointing to the IP of our GoRouter.

Is this normal behaviour? Does Login always need it's own separate DNS entry instead of requests hitting the router?

Also, we are using the UAA for authentication at the moment and do not have the seperate login service instance;

•  i'm wondering if we DID have this login service, it would have registered with the gorouter and the gorouter would then pass login.ourdomain.net properly? If this is the case, how can we register login.ourdomain.net with the gorouter so it passes those requests to the UAA?

As you can see, this question is really around clarity of what should pass through the gorouter, gorouter 'route registration' and why login appears special in our case.

Sources for following this '*.ourdomain.net > GoRouter' approach for DNS from http://docs.cloudfoundry.com/docs/running/deploying-cf/openstack/install_cf_openstack.html

2. Defining system and 'customer facing' DNS Domains (Background)

What we were initially trying to achieve, was to have all the internal CF components on one domain (platform.ourdomain.net for example) and all the 'customer applications and services' on another (apps.ourdomain.net for example).

ie

  - login.platform.ourdomain.net

  - api.platform.ourdomain.net

  - uaa.platform.ourdomain.net

  - per-app UUID generation then at <uuid>.apps.ourdomain.net (b8ccc77a37e0e9efd63c911419796f0f.ourdomain.net for example)

  - Application names without custom domains such as app1-mj.apps.ourdomain.net

we were hoping this was the differentiation between system_domain and domain in the CF deployment manifest, however could find no useful documentation explaining this and looking through the source code seemed to suggest that system_domain isn't used that much at all.

Also, it seems lots of code is hard-coded to use the properties.domain, (such as login.<properties.domain>) again, suggesting system_domain is not used for this purpose.

Alas, when we tried defining different combinations of system_domain, domain and hardcoded URL's (such as in the uaa login section above) we couldn't get the results required.

So our questions here are;

- What are the intended differences between domain and system_domain?

- If we wanted the per-app UUID.ourdomain.net generated on a separate subdomain, how would we go about this?

- Is there any documentation that properly explains the use of DNS internally within CF?

- Should we be hard-coding internal 'system' URL's to achieve our goal, and if so is there documentation for which properties need to be defined?

Kind Regards,

Matt

[Ferran Rodenas]

Matt, shout here for question 1):

If you're not using the login service, add a login.enabled = false property at your deployment manifest. CCNG redirects logins to the Login service or the UAA service based on that property (by default, if the property is not set, it assumes that the login service is enabled, so it will redirect all logins to login.ourdomain.net instead of uaa.ourdomain.net).

- Ferdy

2013/9/3 <m...@matt-j.co.uk>

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[James Bayer]

Do you have a login job in your BOSH deployment manifest? This will simply put an HTML-based login form web app available that leverages the UAA. Search for "login" here:

http://docs.cloudfoundry.com/docs/running/deploying-cf/vsphere/cloud-foundry-example-manifest.html

The login job uses a vcap-registrar process to register a route for login.YOURDOMAIN with the gorouter over NATS.

https://github.com/cloudfoundry/cf-release/blob/master/jobs/login/spec#L7

https://github.com/cloudfoundry/cf-release/blob/master/jobs/login/templates/cf-registrar.config.yml.erb

For # 2 we'll need some help from the engineers.

- What are the intended differences between domain and system_domain?

Using run.pivotal.io as an example, the system domain should be "run.pivotal.io" and supports "api.run.pivotal.io", "uaa.run.pivotal.io" and "login.run.pivotal.io" 

We use an app serving domain of cfapps.io. This means that all Cloud Foundry organizations are able to use subdomains using that system domain like:

foo.cfapps.io

bar.cfapps.io

Here are the properties section for how we configure our environment:

properties:
  domain: run.pivotal.io
  system_domain: run.pivotal.io
  system_domain_organization: yourorgnamehere
  app_domains:
  - cfapps.io

- If we wanted the per-app UUID.ourdomain.net generated on a separate subdomain, how would we go about this?

I believe the app_domains would provides for this use case unless I've missed something about how the UUID works.  

- Is there any documentation that properly explains the use of DNS internally within CF?

I'm sure this needs more help. Hopefully this post helps provide more raw material for what can be improved.

- Should we be hard-coding internal 'system' URL's to achieve our goal, and if so is there documentation for which properties need to be defined?

No, you should not have to hard-code system URLs.

[mariash]

'domain' is used by all CF components (UAA, Login, CC). 'system_domain' is used by cloud controller only for initialization step. This is the domain that is used by 'system_domain_organization' for "system" apps like the console.

When CC boots for the first time it creates first organization (system_domain_organization) and creates the system_domain domain with the system_domain_organization as its owner. If this is not configured, apps will be able to use the same base domain as the CC for their own routes. And this domain may be claimed by any user's organizations, as no one "owns" it.

Concerning, UUID.ourdomain.net do you want to use UUID as host name for your apps? If that's the case I guess you can modify your routes to generate UUID instead of providing it. https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/models/core/route.rb

[Troy Astle]

Thanks for the info @Marlash @James and @Ferdy, starting to get more clarity now.

@Ferdy. 

I was looking into the property you mentioned to disable the login service and had no success.

Have you used this successfully in the past.

Troy.

[Ferran Rodenas]

Yes, it what we usually use when deploying CF over OpenStack. Take a look at the example deployment manifest at http://docs.cloudfoundry.com/docs/running/deploying-cf/openstack/install_cf_openstack.html

- Ferdy

2013/9/5 Troy Astle <troy....@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[Matt Johnson]

Adding my thanks @Marlash @James and @Ferdy, makes a lot more sense now and ensures we are not second guessing our configuration choices.