Using Apache Velocity in your Nimbus scripts.

Nimbus uses Apache’s VTL to bind the UI variables to your script.

That kindof says it all. When Nimbus was created, it was important to find a flexible solution to “bind” the variables you configure in the UI with your Terraform / Cloud formation… etc. scripts. To do this, we pre-processes your script using Apache’s Velocity template language (VTL). If you don’t know VTL, it’s basically like JSP programming, or handlebars. Nimbus provides an object tree that can be referenced to replace strings, or iterate and perform logical conditions on your variable data, and replace stuff in your script. Its incredibly powerful, and assures that you have a consistent layer of logical processing that can be repeated across different platforms and clouds.

You can learn more about VTL at the link below:

https://velocity.apache.org/engine/1.7/user-guide.html

Nimbus provides an object model that you can use to add complex logic to your scripts.

You can reference Nimbus objects in a VTL script by using the ${context.<variable path>} notation. This will only work if you specify that your script supports Nimbus scripting when you define it. Each script can access the following data:

PathObject TypeDescriptionOptional?
${context.cloud}CloudThe cloud configuration being used in this script
${context.orchestrator}OrchestratorThe IaC platform configuration being used in this script
${context.application}ApplicationThe application this build is for
${context.organization}OrganizationThe organization this build is for
${context.environment}TemplateThe root template (environment template) that this script lies within
${context.template}TemplateThe environment, zone, or service template that this script is for.
${context.parent}TemplateThe parent (if applicable). This is the environment if this is a zone script, or the zone if this is a service script. For the environment script, this will be NULL.Optional



Each of these paths references an object that has fields. You can use the below reference to the fields available for each object type, and what they provide:

ObjectPropertyDescriptionFormatOptional
CloudtypeThe unique identifier of the type of cloud. Currently one of: aws, azure, gcpString
CloudnameThe name of the cloud account as you configured itString
ClouddescriptionThe description you provided of the cloud accountStringOptional
CloudvarsCloud specific variables, excluding sensitive information. For AWS this may specify the region.Map(String,String|Number)Optional
OrchestratortypeThe unique identifier of the type of IaC platform such as "terraform"String
OrchestratornameThe name of the account as you configured itString
OrchestratordescriptionThe description you provided of the IaC platform accountStringOptional
OrchestratorvarsIaC platform specific variables, excluding sensitive informationMap(String,String|Number)Optional
TemplateuniqueIDA globally unique ID of the template. This idnetifier will be best practice in the format of - - - String
TemplatetypeThe type of template this is, currently one of : environment, zone, or objectString
TemplatecontainerTrue if this template has childrenBoolean
TemplateserviceThe unique identifier of the service this template deploysString
TemplateidentifierThe unique identifier of this configuration within the specific environment that is specified as the identifier when you configured it.String
Templatenamethe user-friendly name of this template instanceString
Templatedescriptionthe description you provided of this template instanceStringOptional
Templateparentthe parent of this template which will be the zone if this is an object, or the environment if this is a zone. The environment template will have a null value for the parent.TemplateOptional
TemplatechildrenAn array of children template instances. This is applicable if container is TRUE.Template[]Optional
TemplateportsAn array of ports configured for this template. Port[]Optional
TemplateconnectionsAn array of other peer templates that this template has a connection with. These are used to identify how to filter traffic between zones. This list will be the other zones that this template should allow traffic inbound fromTemplate[]Optional
TemplatevarsThe variables that are configured for this template, with their specified values.Map(String,String|Number)Optional
TemplatepropsThe output properties expected for this template. This will be a Map, with the key being the identifier of the property, and the value being a uniquely generated name that should be used as the value of key to the property in the script. Nimbus will look for that unique ID and map it to the correct template's properties.Map(String,String)Optional
PortprotocolTCP or UDPString
Portaddressthe Inet address to set for the port filters. This will be an address that the cloud filters inbound traffic to.String
PortportThe allowed port number. Only a single number is allowed.Number
ApplicationidentifierThe unique identifier of the applicationString
ApplicationnameThe user friendly name of the applicationString
ApplicationdescriptionThe description you provided of the applicationStringOptional
ApplicationfieldsAny custom fields configured for this application along with their configured value. Map(String,String|Number)Optional
OrganizationpathThe path to this organization in the organization hierarchyString
Organizationnamethe user friendly name of this organizationString
OrganizationdescriptionThe optional description of this organization that you provided.StringOptional
OrganizationfieldsAny custom fields configured for this organization along with their configured value. Map(String,String|Number)Optional

Watch outs, and best practices

  • If you are combining VTL with the IaC platform’s scripting language, you may need to escape any statement that you don’t want Nimbus to process. For example, in Terraform - if you use the ${} notation, you will need to escape it with a ‘\’ character: \${}.

  • NULL values are rendered as empty strings in VTL.

  • You should run a compile test on any VTL script that has complex VTL in it. this will help assure your scripts work correctly.

  • If you want to handle all your logic in the IaC platform’s scripting language. You can make a separate “variable” file to bind all your Nimbus UI elements, then you can reference those variables locally. in your other scripts. (just make sure to flip the flag telling Nimbus to pre-process the script)