Build configuration
3 minute read
Server tiers
Server tiers deploy one or more servers of a particular role. The OS build and other primary attributes, such as the hostname template, are typically set by the admin; end users choose the rest at the time of order, within the options and constraints defined for the target environment.
These items can be enabled for one or multiple environments, each with its own parameter options. The environment configuration form lets blueprint managers predefine certain values, so the order form does not prompt the user for them.
Preconfigurations override their constituent parameters on the same environment and appear on the form in their place. A preconfiguration on the group selected on the order form does not appear if all of its constituent parameters are already predefined on the selected environment.
Examples of the range of choice a tier can offer end users:
- A single Windows server for a specific environment, always with two CPUs, 4 GB of memory, on the same dev VLAN.
- A single Ubuntu server across the user’s choice of 10 environments, with hardware resources varying by environment: one CPU and 2 GB of memory in VMware; a t1.micro instance type in AWS.
- A tier that leaves every choice to the end user: OS, environment, server quantity, resources, network, and so on. This is the type of blueprint behind the New Server button.
Cost preview
For blueprints with a single server tier that has specific environments configured (rather than allowing all capable environments), the order form shows end users a cost comparison chart for each environment, based on its base cost.
Blueprint action items
Actions can be added as blueprint items to perform any automatable operation. They can run code on servers in a tier that was just deployed (remote script actions), on the Cloud Management Platform server itself (plugins), or integrate with external systems, using any of the action types supported elsewhere in the product.
Examples of what action items can do:
- Email the monitoring team about a newly deployed resource that needs monitoring.
- Connect to the backup system to enable backups for servers this blueprint deploys.
- Create a new Azure website (see sample scripts in the CloudBolt Forge).
- Message your team’s chat room (see sample webhooks in the CloudBolt Forge).
- Check a deployment’s projected cost against the budget, declining the order or initiating an exception request if it exceeds the budget.
Action items can supply everything they need at runtime, use values from servers in other tiers (for example, the IP of a database server deployed earlier in the same blueprint), or prompt the user for input. See Action input parameters for details on inputs, and Action context for what context actions receive.
Only Super Admins can create or edit plugins, even within a blueprint. Blueprint managers control other action types but cannot share or edit shared actions unless they are also Super Admins.
Blueprint sub-component items
You can define blueprints in the Catalog for use as items within other blueprints. These sub-component blueprints can be as simple or complex as needed, provided they are orderable by any group and do not contain their own sub-blueprints. Nesting is limited to one level, so a blueprint already used as a sub-component does not offer the option for its own sub-blueprints.
Sub-blueprint settings
Is Orderable: set to false to restrict a catalog blueprint to sub-component use only, hiding it from direct ordering.
Execution Scope: restrict which servers a sub-blueprint’s actions can act on:
- Restricted: only servers within that sub-blueprint.
- Unrestricted: any server in the resource.