You have to also update the components section to define additional components such that they use the two new parameters and build the complete load balancing configuration.
For this example, you have to write the components section as follows:
components:
-
name: lbvserver-comp
type: ns::lbvserver
properties:
name: $parameters.name + "-lb"
servicetype: HTTP
ipv46: $parameters.ip
port: 80
lbmethod: $parameters.lb-alg
components:
-
name: svcg-comp
type: ns::servicegroup
properties:
name: $parameters.name + "-svcgrp"
servicetype: HTTP
components:
-
name: lbvserver-svg-binding-comp
type: ns::lbvserver\_servicegroup\_binding
properties:
name: $parent.parent.properties.name
servicegroupname: $parent.properties.name
-
name: members-svcg-comp
type: ns::servicegroup\_servicegroupmember\_binding
repeat: $parameters.svc-servers
repeat-item: srv
properties:
ip: $srv
port: str($parameters.svc-port)
servicegroupname: $parent.properties.name
In this example, the original component lbvserver-comp (from the previous example) now has a child component called svcg-comp. And, the svcg-comp component has two child components within it. Nesting a component within another component allows the nested component to create configuration objects by referring to attributes in the parent component. The nested component can create one or more objects for each object created in the parent component.
The svcg-comp component is used to create a service group on the NetScaler instance by using the values provided for the attributes of the resource "servicegroup". In this example, you are specifying static value for servicetype, while name gets its value from the input parameter. You refer to the parameter name defined in the parameters section by using $parameters.name + "-svcgrp" notation, where -svcgrp is appended (concatenated) to the user-defined name.
The component svcg-comp has two child components, lbvserver-svg-binding-comp and members-svcg-comp.
The first child component, lbvserver-svg-binding-comp, is used to bind a configuration object between the service group created by its parent component and the load balancing virtual server (lbvserver) created by the parent’s parent component. The $parent notation, also called the parent reference, is used to refer to entities in the parent components. For example, servicegroupname: $parent.properties.name refers to the service group created by the parent component svcg-comp, and name: $parent.parent.properties.name refers to the virtual server created by the parent’s parent component lbvserver-comp.
The members-svcg component is used to bind configuration objects between the list of services to the service group created by the parent component. The creation of multiple binding configuration objects is achieved by using the repeat construct of StyleBook to iterate over the list of servers specified in the parameter svc-servers. During the iteration, this StyleBook component creates a Nitro configuration object of type servicegroup_servicegroupmember_binding for each service (referred to as srv in the repeat-item construct) in the service group, and it sets the ip attribute in each Nitro configuration object to the IP address of the corresponding server.
Generally, you can use the repeat and repeat-item constructs in a component to make that component build multiple configuration objects of the same type. You can assign a variable name to the repeat-item construct, for example, srv, to designate the current value in the iteration. This variable name is referred to in the properties of the same component or in child components as $\<varname\>, for example $srv.
In the above example, you have used nesting of components inside each other to easily construct this configuration. In this particular case, nesting of components was not the only way of building the configuration. You could have achieved the same result without nesting, as shown below:
components:
-
name: members-svcg-comp
type: ns::servicegroup\_servicegroupmember\_binding
repeat: $parameters.svc-servers
repeat-item: srv
properties:
ip: $srv
port: str($parameters.svc-port)
servicegroupname: $components.svcg-comp.properties.name
-
name: lbvserver-svg-binding-comp
type: ns::lbvserver\_servicegroup\_binding
properties:
name: $components.lbvserver-comp.properties.name
servicegroupname: $components.svcg-comp.properties.name
-
name: lbvserver-comp
type: ns::lbvserver
properties:
name: $parameters.name + "-lb"
servicetype: HTTP
ipv46: $parameters.ip
port: 80
lbmethod: $parameters.lb-alg
-
name: svcg-comp
type: ns::servicegroup
properties:
name: $parameters.name + "-svcgrp"
servicetype: HTTP
Here, all the components are at the same level (that is, they are not nested) but the result achieved (the NetScaler configuration generated) is the same as that of the nested components used earlier. Also, the order in which the components are declared in the StyleBook does not impact the order of creation of the configuration objects. In this example, the components svcg-comp and lbvserver-comp, even though declared last, must be built before building the second component lbvserver-svg-binding-comp because there are forward references to these components in the second component.
By convention, the names of StyleBooks, parameters, substitutions, components and outputs are in lowercase. When they contain multiple words, they are separated by a "-" character. For example "lb-bindings", "app-name", "rewrite-config", and so on. Another convention is to suffix component names with "-comp" string.