Hello,

We have deployed a CF instance in one of our servers and I would like to
know if the Cloud Controller or Nignx can be configured so that it can be
accessed through a public IP instead of by using a domain name. For
instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
could be accessed through 1. 2. 3. 4/api or something similar, the uaa
through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

The idea of doing this is because we want to avoid, if possible, having to
acquire a domain name, but still have the need to access the CF instance
from outside the network where it's installed.

Thanks in advance,
Oriol.

Search Discussions

  • Ben Langfeld at Dec 3, 2012 at 1:58 pm
    Domain names are stupid cheap...

    Regards,
    Ben Langfeld


    On 3 December 2012 11:29, Oriol Collell Martin
    wrote:
    Hello,

    We have deployed a CF instance in one of our servers and I would like to
    know if the Cloud Controller or Nignx can be configured so that it can be
    accessed through a public IP instead of by using a domain name. For
    instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
    could be accessed through 1. 2. 3. 4/api or something similar, the uaa
    through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

    The idea of doing this is because we want to avoid, if possible, having to
    acquire a domain name, but still have the need to access the CF instance
    from outside the network where it's installed.

    Thanks in advance,
    Oriol.
  • Oriol Collell Martin at Dec 3, 2012 at 2:08 pm
    yeah I know, the price is not the problem, but it's just "easier" to set up
    with just the IP because you don't have to worry about the DNS server and
    that stuff. Just wanted to know if it is possible to do with an IP to
    evaluate the two options.

    Thanks,
    Oriol.

    El lunes, 3 de diciembre de 2012 14:51:15 UTC+1, Ben Langfeld escribió:
    Domain names are stupid cheap...

    Regards,
    Ben Langfeld


    On 3 December 2012 11:29, Oriol Collell Martin <[email protected]<javascript:>
    wrote:
    Hello,

    We have deployed a CF instance in one of our servers and I would like to
    know if the Cloud Controller or Nignx can be configured so that it can be
    accessed through a public IP instead of by using a domain name. For
    instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
    could be accessed through 1. 2. 3. 4/api or something similar, the uaa
    through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

    The idea of doing this is because we want to avoid, if possible, having
    to acquire a domain name, but still have the need to access the CF instance
    from outside the network where it's installed.

    Thanks in advance,
    Oriol.
  • Jesse Zhang at Dec 3, 2012 at 4:00 pm
    I don't think it's currently possible, although you are welcome to patch it
    :)
    You don't have to acquire a domain name to start trying out Cloud Foundry,
    there are various tricks you could use

    1. If you have one router, try using ZeroConf / Avahi to configure a
    domain name within your LAN
    2. Again this is only valid within your intranet: override your DNS
    servers with your org's
    3. Least convenient: on all your test machines, hack your /etc/hosts ...

    Ideas?

    Cheers,
    Jesse

    On Mon, Dec 3, 2012 at 9:29 PM, Oriol Collell Martin wrote:

    Hello,

    We have deployed a CF instance in one of our servers and I would like to
    know if the Cloud Controller or Nignx can be configured so that it can be
    accessed through a public IP instead of by using a domain name. For
    instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
    could be accessed through 1. 2. 3. 4/api or something similar, the uaa
    through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

    The idea of doing this is because we want to avoid, if possible, having to
    acquire a domain name, but still have the need to access the CF instance
    from outside the network where it's installed.

    Thanks in advance,
    Oriol.
  • Oriol Collell Martin at Dec 3, 2012 at 3:44 pm
    Thanks for the answer Jesse! I see that it's only possible to make such a
    configuration within a LAN. So I think the best option will be to acquire a
    domain name to access it from outside the LAN. It'd be nice to patch it,
    but I don't have enough knowledge to do so.

    Oriol.

    El lunes, 3 de diciembre de 2012 16:29:42 UTC+1, Jesse Zhang escribió:
    I don't think it's currently possible, although you are welcome to patch
    it :)
    You don't have to acquire a domain name to start trying out Cloud Foundry,
    there are various tricks you could use

    1. If you have one router, try using ZeroConf / Avahi to configure a
    domain name within your LAN
    2. Again this is only valid within your intranet: override your DNS
    servers with your org's
    3. Least convenient: on all your test machines, hack your /etc/hosts
    ...

    Ideas?

    Cheers,
    Jesse


    On Mon, Dec 3, 2012 at 9:29 PM, Oriol Collell Martin <
    [email protected] <javascript:>> wrote:
    Hello,

    We have deployed a CF instance in one of our servers and I would like to
    know if the Cloud Controller or Nignx can be configured so that it can be
    accessed through a public IP instead of by using a domain name. For
    instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
    could be accessed through 1. 2. 3. 4/api or something similar, the uaa
    through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

    The idea of doing this is because we want to avoid, if possible, having
    to acquire a domain name, but still have the need to access the CF instance
    from outside the network where it's installed.

    Thanks in advance,
    Oriol.
  • Andrea Campi at Dec 3, 2012 at 3:59 pm

    On Mon, Dec 3, 2012 at 4:29 PM, Jesse Zhang wrote:

    I don't think it's currently possible, although you are welcome to patch
    it :)
    You don't have to acquire a domain name to start trying out Cloud Foundry,
    there are various tricks you could use

    1. If you have one router, try using ZeroConf / Avahi to configure a
    domain name within your LAN
    2. Again this is only valid within your intranet: override your DNS
    servers with your org's
    3. Least convenient: on all your test machines, hack your /etc/hosts
    ...
    There are ways, you could patch this in CF (ugh), or put a reverse proxy in
    front to add a Host header, or some of the stuff you mention…
    That's the easy part.

    What would be *less* fun is to write each app to deal with the /myapp part
    of what Oriol is asking for.

    I really don't understand how this is easier than using a proper domain.
    If maintaining the DNS is so much pain (?), just point *.yourdomain.com to
    the public IP address.
    Even easier, use a DDNS provider.
    Or even just http://proxylocal.com

    All of these are in my opinion a lot less painful than using an IP address
    as a host name.
  • Stefan at Dec 15, 2012 at 1:36 pm
    You don't want to go that route. The whole principle driving Cloud Foundry
    is that it assigns a unique domain name to each application and for that to
    work you need to do a wild card DNS assignment to the node where the router
    lives.

    I'm attaching below an expect script that automates the DNS assignment to a
    node configured with the Cloud Foundry dev setup. It makes some assumptions
    on where Cloud Foundry is installed ("/root/cloudfoundry") but should
    document the complete required configuration steps for assigning an
    arbitrary domain to a node. As an example, if the node has IP 1.2.3.4 and
    you have made a wildcard DNS assignment of *.my.custom.domain.com to
    1.2.3.4 then you use the script with:

    cf_assign_domain.expect 1.2.3.4 my.custom.domain.com

    and then use "vmc api.my.custom.domain.com" to login. Note that ssh into
    the root account has to be configured for the script to work. Hope this
    helps.

    /Stefan

    #!/usr/bin/expect

    ## This script will set a custom domain name for Cloud Foundry vcap_dev
    based installation.
    ## It updates:
    ## - the configuration files in the .deployment/<deployment name>/config
    directory
    ## - the nginx_router configuration

    set timeout 600

    if {[llength $argv] < 1} {
    puts "Usage: hostname \[domain\]"
    exit
    }

    set rhost [lindex $argv 0]
    set domain "vcap.me"


    if {[llength $argv] > 1} {
    set domain [lindex $argv 1]
    }

    set ctrl_a_d "\01d"

    spawn /usr/bin/ssh $rhost
    expect "*root@"

    send {ip=`ifconfig eth0 | sed -n 's/.*inet addr:\(\S*\).*/\1/p'`}; send "\r"
    expect "*root@"

    #send "echo \$ip\r"
    #expect "*root@"

    #send "screen -S cf_domain_set \r"
    #expect "*root@"

    ## stop all services
    send "/root/cloudfoundry/vcap/dev_setup/bin/vcap_dev stop\r"
    expect "*root@"

    send "cd cloudfoundry/.deployments/devbox\r"
    expect "*root@"

    send "find config -type f| xargs sed -i
    's|cloud_controller_uri:.*|cloud_controller_uri: http://api.$domain|'\r"
    expect "*root@"

    send "find config -type f| xargs sed -i \"s|local_route:.*|local_route:
    \$ip|\"\r"
    expect "*root@"

    send "sed -i 's|^admins:.*|admins: \[ admin@$domain \]|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|allow_external:.*|allow_external: true|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|allow_external_app_uris:.*|allow_external_app_uris: true|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|external_uri:.*|external_uri: api.$domain|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|url:.*|url: http://uaa.$domain|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i -e '/^uaa:/,/^\w/{/^\w/!d}' -e '/^uaa:/d' config/uaa.yml\r"
    expect "*root@"

    ## add uaa domain config to uaa.yml
    send "echo uaa: >> config/uaa.yml\r"
    expect "*root@"
    send "echo ' uris: \[ uaa.$domain, login.$domain \]' >> config/uaa.yml\r"
    expect "*root@"

    send "sed -i 's|\"domain\":\"\[^\"\]*\"|\"domain\":\"$domain\"|'
    config/deploy.json\r"
    expect "*root@"

    ## fix resolver in nginx router config (use Google DNS)
    send "sed -i -e '/^ *resolver.*/d' -e 's/server *{.*/&\\n resolver
    8.8.8.8;/' deploy/nginx/nginx-0.8.54/conf/nginx_router.conf\r"
    expect "*root@"

    ## restart nginx_router
    send "service nginx_router restart\r"
    expect "*root@"

    ## start all services
    send "/root/cloudfoundry/vcap/dev_setup/bin/vcap_dev start\r"
    expect "*root@"
    send "exit \r"

    On Monday, December 3, 2012 2:29:12 PM UTC+1, Oriol Collell Martin wrote:

    Hello,

    We have deployed a CF instance in one of our servers and I would like to
    know if the Cloud Controller or Nignx can be configured so that it can be
    accessed through a public IP instead of by using a domain name. For
    instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
    could be accessed through 1. 2. 3. 4/api or something similar, the uaa
    through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

    The idea of doing this is because we want to avoid, if possible, having to
    acquire a domain name, but still have the need to access the CF instance
    from outside the network where it's installed.

    Thanks in advance,
    Oriol.
  • Oriol Collell Martin at Dec 15, 2012 at 1:41 pm
    Thank you very much Stefan, now I am having some issues configuring the
    domain and this will probably help.

    El sábado, 15 de diciembre de 2012 14:36:49 UTC+1, [email protected]
    escribió:
    You don't want to go that route. The whole principle driving Cloud Foundry
    is that it assigns a unique domain name to each application and for that to
    work you need to do a wild card DNS assignment to the node where the router
    lives.

    I'm attaching below an expect script that automates the DNS assignment to
    a node configured with the Cloud Foundry dev setup. It makes some
    assumptions on where Cloud Foundry is installed ("/root/cloudfoundry") but
    should document the complete required configuration steps for assigning an
    arbitrary domain to a node. As an example, if the node has IP 1.2.3.4 and
    you have made a wildcard DNS assignment of *.my.custom.domain.com to
    1.2.3.4 then you use the script with:

    cf_assign_domain.expect 1.2.3.4 my.custom.domain.com

    and then use "vmc api.my.custom.domain.com" to login. Note that ssh into
    the root account has to be configured for the script to work. Hope this
    helps.

    /Stefan

    #!/usr/bin/expect

    ## This script will set a custom domain name for Cloud Foundry vcap_dev
    based installation.
    ## It updates:
    ## - the configuration files in the .deployment/<deployment
    name>/config directory
    ## - the nginx_router configuration

    set timeout 600

    if {[llength $argv] < 1} {
    puts "Usage: hostname \[domain\]"
    exit
    }

    set rhost [lindex $argv 0]
    set domain "vcap.me"


    if {[llength $argv] > 1} {
    set domain [lindex $argv 1]
    }

    set ctrl_a_d "\01d"

    spawn /usr/bin/ssh $rhost
    expect "*root@"

    send {ip=`ifconfig eth0 | sed -n 's/.*inet addr:\(\S*\).*/\1/p'`}; send
    "\r"
    expect "*root@"

    #send "echo \$ip\r"
    #expect "*root@"

    #send "screen -S cf_domain_set \r"
    #expect "*root@"

    ## stop all services
    send "/root/cloudfoundry/vcap/dev_setup/bin/vcap_dev stop\r"
    expect "*root@"

    send "cd cloudfoundry/.deployments/devbox\r"
    expect "*root@"

    send "find config -type f| xargs sed -i
    's|cloud_controller_uri:.*|cloud_controller_uri: http://api.$domain|'\r"
    expect "*root@"

    send "find config -type f| xargs sed -i \"s|local_route:.*|local_route:
    \$ip|\"\r"
    expect "*root@"

    send "sed -i 's|^admins:.*|admins: \[ admin@$domain \]|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|allow_external:.*|allow_external: true|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|allow_external_app_uris:.*|allow_external_app_uris: true|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|external_uri:.*|external_uri: api.$domain|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i 's|url:.*|url: http://uaa.$domain|'
    config/cloud_controller.yml\r"
    expect "*root@"

    send "sed -i -e '/^uaa:/,/^\w/{/^\w/!d}' -e '/^uaa:/d' config/uaa.yml\r"
    expect "*root@"

    ## add uaa domain config to uaa.yml
    send "echo uaa: >> config/uaa.yml\r"
    expect "*root@"
    send "echo ' uris: \[ uaa.$domain, login.$domain \]' >> config/uaa.yml\r"
    expect "*root@"

    send "sed -i 's|\"domain\":\"\[^\"\]*\"|\"domain\":\"$domain\"|'
    config/deploy.json\r"
    expect "*root@"

    ## fix resolver in nginx router config (use Google DNS)
    send "sed -i -e '/^ *resolver.*/d' -e 's/server *{.*/&\\n resolver
    8.8.8.8;/' deploy/nginx/nginx-0.8.54/conf/nginx_router.conf\r"
    expect "*root@"

    ## restart nginx_router
    send "service nginx_router restart\r"
    expect "*root@"

    ## start all services
    send "/root/cloudfoundry/vcap/dev_setup/bin/vcap_dev start\r"
    expect "*root@"
    send "exit \r"

    On Monday, December 3, 2012 2:29:12 PM UTC+1, Oriol Collell Martin wrote:

    Hello,

    We have deployed a CF instance in one of our servers and I would like to
    know if the Cloud Controller or Nignx can be configured so that it can be
    accessed through a public IP instead of by using a domain name. For
    instance, let's say that the IP is 1. 2. 3. 4, the idea is that the api
    could be accessed through 1. 2. 3. 4/api or something similar, the uaa
    through 1. 2. 3. 4/uaa and deployed applications through 1. 2. 3. 4/myapp.

    The idea of doing this is because we want to avoid, if possible, having
    to acquire a domain name, but still have the need to access the CF instance
    from outside the network where it's installed.

    Thanks in advance,
    Oriol.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedDec 3, '12 at 1:29p
activeDec 15, '12 at 1:41p
posts8
users5

People

Translate

site design / logo © 2023 Grokbase