Using infrastructures with workflows

Attaching workflows

Workflows can be attached at multiple points as part of an infrastructure:

infrastructure with workflows

  1. pre-deployment workflows will be executed before servers get allocated to instances. Typically at this stage you would allocate infrastructure-wide resources such as subnets.

  2. InstanceArray workflows - these workflows will be executed in-lieu of the default provisioning steps for each instance of an InstanceArray (cluster of instances). One of these steps is the OS install step which is governed via the OS Template mechanism. More on this below.

  3. post-deployment workflows will happen after everything else. This is where admins will add nodes to a cluster, notify external systems of provisioning completion etc.

Empty infrastructures

You can have an empty infrastructure with workflows attached to either pre or post deploy. In this case 1. no networking provisioning is done automatically 2. no server allocation is done automatically 3. a subnet is allocated but no IPs are allocated to servers

Attaching a workflow to a instance array

If you attach a workflow to an instance array, the workflow will be executed on each instance. You can control how provisioning will be done for that instance:

  1. The InstanceArray’s definition will instruct the system on which servers to allocate from the pool of servers of the associated datacenter.

  2. The InstanceArray’s network port configurations will instruct the system to use the built-in support for networking. Left unattached the associated switch ports will be left in a shutdown state.

  3. The InstanceArray’s template field will instruct the system on how to perform the OS install step. If populated with a pre-defined OS Template it will use the assets and steps defined in that template. If a regular built-in template is used, the system will use the built-in mechanism (which includes diskless setups).

Specifying certain server IDs

If a certain server has to be used it can be specified using the objDeployOptions object of the infrastructure_deploy() function.

For example:

{
	"instance_array": {
		// InstanceArray ID 99
		99: {
			// Server type ID 75
			"75": {
				"server_count": 1
                
                // If the preferred server is not of server type 99 an error will not be thrown and another server will be allocated.
                // If the preferred server cannot be allocated for any kind of reason, an error will not be thrown and another server will be allocated instead.
                // The preferred is only given allocation priority.
                "server_ids": [5]
			}
		}
	}
}

While supported, this mechanism is not recommended as it makes workflows less portable. Server types should be used instead.