idle-parameters

Using idle parameters [EXPERIMENTAL]

Table of Contents

• Overview
• Requirements
• Official documentation
• Try it out
  • Using idle-routes
    • Execute deploy
    • Examine the result
  • Using idle-host
    • Execute deploy
    • Examine the result
  • Using idle-hosts
    • Execute deploy
    • Examine the result
  • Using idle-domain
    • Execute deploy
    • Examine the result
  • Using idle-domains
    • Execute deploy
    • Examine the result
  • Using a combination of idle-host and idle-domain
    • Execute deploy
    • Examine the result
  • Using a combination of idle-host and idle-domains
    • Execute deploy
    • Examine the result
  • Using a combination of idle-hosts and idle-domain
    • Execute deploy
    • Examine the result
  • Using combination of idle-hosts and idle-domains
    • Execute deploy
    • Examine the result
  • Clean up resources

Overview

This example shows how to model and use idle parameters on MTA module level: idle-host, idle-hosts, idle-domain, idle-domains and idle-routes.

All idle parameters are applicable only for modules that represent Cloud Foundry applications. Also idle parameters are considered only in blue-green deployment scenario. If the same MTA is deployed with standard cf deploy the parameters will not influence on the end result.

Idle parameters are used in the validation phase of blue-green deployment where new application versions are mapped to temporary routes, also called idle routes. Idle parameters are used to define explicitly temporary routes.

Note	The recommended way to create idle route(s) is by using idle-routes parameter! All other combinations are possible but should be avoided and used carefully if needed!

When idle parameter are not defined the SAP Cloud Deployment service will use default behavior to calculate the temporary idle routes:

${org}-${space}-${app-name}-idle.${default-domain}

All these parameters org, space, app-name and default-domain are read-only and their values depend on the Cloud Foundry region, org and space.

In Cloud Foundry the application routes include a domain, an optional hostname, and an optional context path. In MTA blue-green deployment, idle routes consist of a domain, called idle-domain, and hostname, called idle-host. Specifying any of the idle parameters influences the idle route(s).

Basically, the formula is:

idle-route = idle-host.idle-domain

It is possible to use combinations of these parameters. However, if you specify idle-routes and one or more of the following parameters: idle-host,idle-hosts,idle-domain,idle-domains, only idle-routes will be used for blue-green deployment. The rest of the specified parameters will be ignored during deployment.

It is also possible to define multiple idle routes: * Using parameter idle-routes and defining multiple values. * Using "plural" idle parameters idle-hosts and/or idle-domains, where all idle routes are a cartesian product of all idle hosts and idle domains:

idle-routes = idle-hosts X idle-domains

Note

If you are using a custom idle domain, make sure it has already been created and is currently present in the org! The SAP Cloud Deployment service does not create idle domains. This is particularly important to remember when defining any of these parameters: idle-routes, idle-domain or idle-domains.

Requirements

• Awareness of MTA blue-green deployment

Official documentation

• SAP Help Portal: Module-Specific Parameters

• SAP Help Portal: Blue-Green Deployment of Multitarget Applications

Try it out

The examples below will demonstrate different combinations of idle parameters and their result. As input for all deployments, the same MTAR will be used but with different extension descriptors. Extension descriptors define idle parameters so you can examine them.

Using idle-routes

Note	This is the recommended way to create idle route(s)! You can ignore the other options in most of the cases.

When idle-routes is defined, the new app version will be mapped to one or many temporary routes depending on the number of idle-routes:

parameters:
  idle-routes:
    - idle-route: "your-first-idle-hostname.your.first.idle.domain"
    - idle-route: "your-second-idle-hostname.your.second.idle.domain"

hostname	domain
your-first-idle-hostname	your.first.idle.domain
your-second-idle-hostname	your.second.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-routes.mtaext -f
...
Application "app-blue" started and available at "your-first-idle-hostname.your.first.idle.domain,your-second-idle-hostname.your.second.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space     host                             domain                 port   path   type    apps       services
xxxx      your-first-idle-hostname         your.idle.domain                             app-blue
xxxx      your-second-idle-hostname        our.second.idle.domain                       app-blue

Using idle-host

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes .

When idle-host is defined, the new app version will be mapped only to one temporary route using the ${default-domain} as domain:

parameters:
  idle-host: "your-idle-hostname"

hostname	domain
your-idle-hostname	${default-domain}

Execute deploy

$ cf bg-deploy ./ -e idle-host.mtaext -f
...
Application "app-blue" started and available at "your-idle-hostname.<DEFAULT_DOMAIN>"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space   host                    domain                port   path   type    apps       services
xxxx    your-idle-hostname      <DEFAULT_DOMAIN>                            app-blue

Using idle-hosts

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes .

When idle-hosts is defined, the new app version will be mapped to one or many temporary routes using the ${default-domain} as domain:

parameters:
  idle-hosts: ["your-first-idle-hostname", "your-second-idle-hostname"]

hostname	domain
your-first-idle-hostname	${default-domain}
your-second-idle-hostname	${default-domain}

Execute deploy

$ cf bg-deploy ./ -e idle-hosts.mtaext -f
...
Application "app-blue" started and available at "your-first-idle-hostname.<DEFAULT_DOMAIN>,your-second-idle-hostname.<DEFAULT_DOMAIN>"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space     host                        domain             port   path   type    apps       services
xxxx      your-idle-hostname          <DEFAULT_DOMAIN>                         app-blue
xxxx      your-second-idle-hostname   <DEFAULT_DOMAIN>                         app-blue

Using idle-domain

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes.

When idle-domain is defined, the new app version will be mapped only to one temporary route using the ${default-host}-idle as host:

parameters:
  idle-domain: "your.idle.domain"

hostname	domain
${default-host}-idle	your.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-domain.mtaext -f
...
Application "app-blue" started and available at "<org>-<space>-app-idle.your.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space    host                       domain            port   path   type    apps       services
xxxx     <org>-<space>-app-idle     your.idle.domain                        app-blue

Using idle-domains

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes.

When idle-domains is defined, the new app version will be mapped only to one or many temporary routes using the ${default-host}-idle` as host:

parameters:
  idle-domains: ["your.first.idle.domain", "your.second.idle.domain"]

hostname	domain
${default-host}-idle	your.first.idle.domain
${default-host}-idle	your.second.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-domains.mtaext -f
...
Application "app-blue" started and available at "<org>-<space>-app-idle.your.idle.domain,<org>-<space>-app-idle.your.second.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space    host                     domain                  port   path   type    apps       services
xxxx     <org>-<space>-app-idle   your.idle.domain                              app-blue
xxxx     <org>-<space>-app-idle   your.second.idle.domain                       app-blue

Using a combination of idle-host and idle-domain

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes.

When both idle-host and idle-domain are defined, the new app version will be mapped only to one temporary route:

parameters:
  idle-host: "your-idle-hostname"
  idle-domain: "your.idle.domain"

hostname	domain
your-idle-hostname	your.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-host-idle-domain.mtaext -f
...
Application "app-blue" started and available at "your-idle-hostname.your.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space  host                 domain            port   path   type    apps       services
xxxx   your-idle-hostname   your.idle.domain                        app-blue

Using a combination of idle-host and idle-domains

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes.

When both idle-host and idle-domains are defined, the new app version will be mapped to one or more temporary routes depending on the number of idle-domains:

parameters:
  idle-host: "your-idle-hostname"
  idle-domains: ["your.first.idle.domain", "your.second.idle.domain"]

hostname	domain
your-idle-hostname	your.first.idle.domain
your-idle-hostname	your.second.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-host-idle-domains.mtaext -f
...
Application "app-blue" started and available at "your-idle-hostname.your.first.idle.domain,your-idle-hostname.your.second.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

spa     host                  domain                  port   path   type    apps       services
xxxx    your-idle-hostname    your.first.idle.domain                        app-blue
xxxx    your-idle-hostname    your.second.idle.domain                       app-blue

Using a combination of idle-hosts and idle-domain

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes.

When both idle-hosts and idle-domain are defined, the new app version will be mapped to one or more temporary routes depending on the number of idle-hosts:

parameters:
  idle-hosts: ["your-first-idle-hostname", "your-second-idle-hostname"]
  idle-domain: "your.idle.domain"

hostname	domain
your-first-idle-hostname	your.idle.domain
your-second-idle-hostname	your.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-hosts-idle-domain.mtaext -f
...
Application "app-blue" started and available at "your-first-idle-hostname.your.idle.domain,your-second-idle-hostname.your.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space   host                       domain            port   path   type    apps       services
xxxx    your-idle-hostname         your.idle.domain                        app-blue
xxxx    your-second-idle-hostname  your.idle.domain                        app-blue

Using combination of idle-hosts and idle-domains

Note	This is NOT the recommended way to create idle route(s)! See Using idle-routes.

When both idle-hosts and idle-domains are defined, the new app version will be mapped to one or more temporary routes depending on the number of idle-hosts and idle-domains:

parameters:
  idle-hosts: ["your-first-idle-hostname", "your-second-idle-hostname"]
  idle-domains: ["your.first.idle.domain", "your.second.idle.domain"]

hostname	domain
your-first-idle-hostname	your.first.idle.domain
your-second-idle-hostname	your.first.idle.domain
your-first-idle-hostname	your.second.idle.domain
your-second-idle-hostname	your.second.idle.domain

Execute deploy

$ cf bg-deploy ./ -e idle-hosts-idle-domains.mtaext -f
...
Application "app-blue" started and available at "your-first-idle-hostname.your.first.idle.domain,your-first-idle-hostname.your.second.idle.domain,your-second-idle-hostname.your.first.idle.domain,your-second-idle-hostname.your.second.idle.domain"
...

Examine the result

Check what are the created routes and which apps are mapped to them:

$ cf r
Getting routes for org xxxx / space xxxx as xxx ...

space   host                         domain                  port   path   type    apps       services
xxxx    your-first-idle-hostname     your.first.idle.domain                        app-blue
xxxx    your-first-idle-hostname     your.second.idle.domain                       app-blue
xxxx    your-second-idle-hostname    your.first.idle.domain                        app-blue
xxxx    your-second-idle-hostname    your.second.idle.domain                       app-blue

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