Understanding how CloudBolt’s objects are meant to be used together will help you use CloudBolt more effectively.
CloudBolt models your enterprise cloud using the following building blocks:
- Resource Handlers are connections to your virtualization tools: VMware, AWS, OpenStack, etc. They let CloudBolt discover your VMs, VM images, clusters, networks, and more.
- Environments are a grouping of things, including a resource handler and one of its clusters/regions, a subset of VM images and networks, an optional configuration manager (like Puppet or Chef), and some other configuration.
- Groups are collections of CloudBolt users. They are used to manage access to CloudBolt environments, blueprints, services, reports, servers and many other objects.
- Servers represent VMs. Every server belongs to one environment and one group.
- The Catalog simplifies complex orchestration into blueprints that are built by admins and ordered by users.
- Make some or all of the Networks within your virtualization or cloud platforms available in CloudBolt.
- Orchestration framework enables admins to configure and automate custom workflows.
- And several other technology connectors for your Configuration Managers (such as Chef and Puppet), Infoblox Integration (IP Management or IPAM), Container Orchestrators (e.g. Docker), Provision Engines (such as Cobbler and HP Server Automation).
In addition, CloudBolt introduces several novel tools and concepts that make managing your enterprise cloud even easier:
- A high-performance job engine that works under the hood to process your orders, orchestrations, and ad-hoc management.
- Continuous Infrastructure Testing performs end-to-end tests of your orders on a routine basis and gives you perspective of which parts of your infrastructure are healthy or not.
- Rules perform if-this-then-that checks on a routine basis, performing such actions as quota enforcement, lab clean-up, and anything you can model with a Python script.
- A RESTful CloudBolt API v2.0 and internal Python API as well as samples in the product and on the CloudBolt Forge (http://github.com/CloudBoltSoftware/cloudbolt-forge).
- Rates in CloudBolt provide a technology-agnostic way of modeling charge-back or show-back for your infrastructure based on criteria and rates that you define, without being tied to a specific technology’s pricing structure.
- Inventory and cost reports built into the product that make it easier to invoice and communicate the scale of your infrastructure.
Let’s look at the fictitious company “Yoyodyne” to see how it makes use of CloudBolt’s core objects to manage their infrastructure.
When the yo-yo craze revitalized, Yoyodyne became a household name. Now they run a booming business selling yo-yos both online and off. Because their computing infrastructure became fragmented and complicated, they adopted CloudBolt to streamline it and make it easier to use.
Yoyodyne develops their website at their Portland headquarters. They have a VMware vCenter with two clusters: one for development and another for production. Two teams are responsible for maintaining the website: a principal “Dev” team and another “QA” team. The QA team is responsible for testing and deploying the website to production, so they need access to both clusters, but the Dev team only needs access to the development cluster.
To enable this workflow in CloudBolt, Yoyodyne started by creating a resource handler that connects to their vCenter. With this done, CloudBolt could discover all of their pre-existing VMs and enable them to be managed from within CloudBolt.
To enable ordering of VMs, Yoyodyne created two environments that used their vCenter resource handler:
- A “Development” environment that exposes their development cluster and the VM images that the developers need
- A “Production” environment that exposes their production cluster and just their production images
The order forms for each environment were customized by changing the environment’s parameters to give the “Development” environment more ordering flexibility than the “Production” environment, which has strict VM-size requirements.
To give Yoyodyne’s teams access to these order forms, they added two groups of users to CloudBolt: “Developers” and “QA”. The “Developers” group was given access to the “Development” environment, and the “QA” group was given access to both environments.
By modelling Yoyodyne’s teams and business rules in CloudBolt, their employees now have simple and controlled self-service access to Yoyodyne’s infrastructure. CloudBolt’s automation means fewer mistakes are made, less time is spent creating or managing VMs, and Yoyodyne’s infrastructure becomes more valuable.