Groups and Environments¶
Groups in CloudBolt map users to roles for a specified set of environments. You can assign one or more roles to users in a group.
A role allows you to assign specific privileges to group members. Those privileges apply only to resources and environments that are associated with the group. For example, a user with the default requestor role on a group is allowed to request resources in the environments associated with the group. By default, a resource admin role on that same group can manage any of the servers that belong to that group. There are a total of five out-of-the-box roles on groups that are covered in detail in Users and Permissions, and you can also configure your own.
Groups are stored hierarchically in CloudBolt to help you:
- Easily model organizational structures for staff.
- Delegate permission to administer the groups to the appropriate person within these organizations.
NOTE you can define any type for Groups, but you are required to explicitly make new group types capable of ordering resources.
To do that, navigate to Admin -> Users & Settings -> Miscellaneous settings edit Valid group types for Orders
Make sure your group type is in the list.
An environment in CloudBolt is a logical grouping of resources. Environments may be defined by a combination of physical location, purpose, and technologies used within the environment.
Here are a few example environments:
- San Jose Prod Datacenter
- Training Lab in Bldg 45
- Xen Testbed
- SF QA Lab
Each environment has a single resource handler that is used whenever CloudBolt creates or alters any of the servers in the environment. For example, when a user clicks Power Off on a server, CloudBolt contacts the resource handler for that server (e.g., a vCenter instance) and instructs it to power off the server.
Environments can also be associated with a configuration management and/or provisioning system (like Chef, Puppet, HP Server Automation, and Cobbler) to support installing OSs, applications, patches, or other components.
Groups and Environments in the Ordering Process¶
When you click the New server link, you must choose which group and environment to order server(s) for. This generates the rest of the order form based on these group and environment selections. Ordering Blueprints also takes into account the configuration of the Blueprint, in addition to the group and environment.
CloudBolt admins and others with the group.manage_parameters permission can associate parameters with groups and environments to customize the order form. For example, a Resource Admin (with default permissions) for the Acme group could add an expiration date parameter to this group, causing CloudBolt to ask anyone ordering server(s) in this group for the expiration date.
The concept that group and environment selections can determine the parameters for server construction is central to CloudBolt. More information on parameters and preconfigurations can be found in the Order Form Customization section.
Exporting and Importing Environments¶
Environments can be exported as files in order to be easily reused across CloudBolt instances. Exported environments are typically stored as zip files containing JSON-formatted metadata about the environment.
It’s possible to export both from the details page of an environment in the UI and using the API. When exporting, you can choose between a sanitized or instance-specific version of the environment, where the sanitized version will omit potentially sensitive information or details that may not make sense when importing into a different CloudBolt, such as groups and the associated Resource Handler. Environments can be imported from the Environments list page or using the API, and have an option to either replace the existing environments or create a new one.
Exports will also contain all the necessary details on any environment parameters, limits, OS Builds, and networks. The import process will look for existing matching objects to use and create new ones if none are found.