README.adoc

Keeping exisiting routes on update

Table of Contents

• Overview
  • Deploy
  • Manually map routes to the Cloud Foundry apps
  • Examine the new routing
  • Re-deply to simulate update
  • Check out the result
• Clean up resources

Overview

This example shows how to preserve manual mappings of app routes during MTA deployment. This feature tends to be useful, for instance, when tenant onboarding for multitenant apps generates a separate route for each tenant and that route is not maintained in an *.mtaext extension descriptor given to the MTA deployer.

It can be activated in 3 ways:

• global parameter keep-existing-routes: true

• module level parameter keep-existing-routes: true

• module level parameter keep-existing:…​

  ...
  parameters:
    keep-existing:
      routes:true

Note	See mta.yaml or mtad.yaml in the current directory.

Deploy

You can deploy it directly from an mtad.yaml file:

$ cf deploy ./ -f ;

Alternatively, you can build an MTAR archive from an mta.yaml file:

$ mbt build -p cf -t . ;

And then deploy the built MTAR archive:

$ cf deploy a.cf.app_0.0.0.mtar -f ;

Manually map routes to the Cloud Foundry apps

$ cf map-route cf-app-unmapping-routes apps.internal --hostname "custom-host"
$ cf map-route cf-app-keeping-complex-param apps.internal --hostname "custom-host"
$ cf map-route cf-app-keeping-simple-param apps.internal --hostname "custom-host"

Examine the new routing

$ cf apps
Getting apps in org ...
name                           requested state   instances   memory   disk   urls
cf-app-keeping-complex-param   started           1/1         1G       1G     custom-host.apps.internal, <org>-<space>-cf-app-keeping-complex-param.<default-domain>,
cf-app-keeping-simple-param    started           1/1         1G       1G     custom-host.apps.internal, <org>-<space>-cf-app-keeping-simple-param.<default-domain>
cf-app-unmapping-routes        started           1/1         1G       1G     custom-host.apps.internal, <org>-<space>-cf-app-unmapping-routes.<default-domain>

Re-deply to simulate update

$ cf deploy -f ;

or:

$ cf deploy a.cf.app_0.0.0.mtar -f ;

Check out the result

$ cf apps
Getting apps in org ...
name                           requested state   instances   memory   disk   urls
cf-app-keeping-complex-param   started           1/1         1G       1G     custom-host.apps.internal, <org>-<space>-cf-app-keeping-complex-param.<default-domain>,
cf-app-keeping-simple-param    started           1/1         1G       1G     custom-host.apps.internal, <org>-<space>-cf-app-keeping-simple-param.<default-domain>
cf-app-unmapping-routes        started           1/1         1G       1G     <org>-<space>-cf-app-unmapping-routes.<default-domain>

Note that apps that have their 'keep-existing..' parameters activated have the url custom-host.apps.internal. However, in the app cf-app-unmapping-routes has the url unmapped.

Clean up resources

It is recommended to stop or undeploy your MTAs when they are no longer needed. In order to do so, run the following command:

$ cf undeploy <mta-id> -f --delete-services