Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

28 Custom Application Domains

In a standard SUSE Cloud Foundry deployment, applications will use the same domain as the one configured in your scf-config-values.yaml for SCF. For example, if DOMAIN is set as example.com in your scf-config-values.yaml and you deploy an application called myapp then the application's URL will be myapp.example.com.

This chapter describes the changes required to allow applications to use a separate domain.

28.1 Customizing Application Domains

Begin by adding the following to your scf-config-values.yaml. Replace appdomain.com with the domain to use with your applications:

bosh:
  instance_groups:
  - name: api-group
    jobs:
    - name: cloud_controller_ng
      properties:
        app_domains:
	- appdomain.com

Ensure uaa has been deployed, then proceed with this step.

If this is an initial deployment, use helm install to deploy scf:

Note
Note: Setting UAA_CA_CERT

Starting with SUSE Cloud Application Platform 1.5.2, you no longer need to set UAA_CA_CERT when using an external UAA with a certificate signed by a well known Certificate Authority (CA). It is only needed when you use an external UAA with either a certificate generated by the secret-generator or a self-signed certificate.

If you need to set UAA_CA_CERT:

  1. Obtain your UAA secret and certificate:

    tux > SECRET=$(kubectl get pods --namespace uaa \
    --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
    
    tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
    --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"
  2. Then pass --set "secrets.UAA_CA_CERT=${CA_CERT}" as part of your helm command.

tux > helm install suse/cf \
--name susecf-scf \
--namespace scf \
--values scf-config-values.yaml

If this is an existing deployment, use helm upgrade to apply the change:

Note
Note: Setting UAA_CA_CERT

Starting with SUSE Cloud Application Platform 1.5.2, you no longer need to set UAA_CA_CERT when using an external UAA with a certificate signed by a well known Certificate Authority (CA). It is only needed when you use an external UAA with either a certificate generated by the secret-generator or a self-signed certificate.

If you need to set UAA_CA_CERT:

  1. Obtain your UAA secret and certificate:

    tux > SECRET=$(kubectl get pods --namespace uaa \
    --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
    
    tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
    --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"
  2. Then pass --set "secrets.UAA_CA_CERT=${CA_CERT}" as part of your helm command.

tux > helm upgrade susecf-scf suse/cf \
--values scf-config-values.yaml \
--version 2.20.3

Wait until you have a successful scf deployment before going to the next steps, which you can monitor with the watch command:

tux > watch --color 'kubectl get pods --namespace scf'

When scf is successfully deployed, the following is observed:

  • For the secret-generation and post-deployment-setup pods, the STATUS is Completed and the READY column is at 0/1.

  • All other pods have a Running STATUS and a READY value of n/n.

Press CtrlC to exit the watch command.

When the scf is complete, do the following to confirm custom application domains have been configured correctly.

Run cf curl /v2/info and verify the SCF domain is not appdomain.com:

tux > cf api --skip-ssl-validation https://api.example.com
tux > cf curl /v2/info | grep endpoint

Deploy an application and examine the routes field to verify appdomain.com is being used:

tux > cf login
tux > cf create-org org
tux > cf create-space space -o org
tux > cf target -o org -s space
tux > cf push myapp
cf push myapp
Pushing app myapp to org org / space space as admin...
Getting app info...
Creating app with these attributes...
  name:       myapp
  path:       /path/to/myapp
  routes:
+   myapp.appdomain.com

Creating app myapp...
Mapping routes...

...

Waiting for app to start...

name:              myapp
requested state:   started
instances:         1/1
usage:             1G x 1 instances
routes:            myapp.appdomain.com
last uploaded:     Mon 14 Jan 11:08:02 PST 2019
stack:             sle15
buildpack:         ruby
start command:     bundle exec rackup config.ru -p $PORT

     state     since                  cpu    memory       disk          details
#0   running   2019-01-14T19:09:42Z   0.0%   2.7M of 1G   80.6M of 1G
Print this page