xPlore.Cloud User Documentation

Note

  • This is the user documentation which is meant to help a Self Service Portal user.
  • If you are a developer and want to learn how to use HyBench (Hybrid Workbench) to quickly add/enhance support for a target cloud, you should visit xPlore.Cloud Developer Documentation.
  • On the other hand, if you are a developer tasked with customizing/rebranding the Self Service User Portal, you should visit xPlore.Cloud API Documentation.

Note

xPlore.Cloud is a unique tool to quickly build an orchestration layer for an arbitrary hybrid cloud. It is completely cloud agnostic and provides a very quick, efficient and predictable way to create a self service portal with any number of participating public and/or private clouds like AWS, Azure, GCP, OpenStack etc, as well as raw hypervisors like VMWare, KVM, Xen etc.

xPlore.Cloud Self Service Portal

This essentially is the xPlore menu item in the top menu bar when you log into your xPlore.Cloud account as an Admin/Owner. However, if you log in as a normal DevOps user, you will land directly into the Service Portal.

The xPlore.Cloud service portal has an uniform look and feel across clouds and cloud resources. So, if you know how to use one resource type for one cloud, you basically know how to use almost all resources on all participating clouds.

To understand how to use the Service Portal, all you need to know a few intuitive elements of the UI that are uniform across clouds and cloud resources. Here are these basic ingredients:

(Concepts marked with a * below are the ones that are essential to understand so as to use the xPlore.Cloud Service Portal. Others can be left for a second reading if they don’t make sense rightaway.)

  1. A Cloud Access Server (CAS): From a back-end perspective, this is a server that facilitates the connectivity between the service portal and the target cloud. From the portal user’s perspective, this usually corresponds to a particular Cloud account. However, your organisation’s programmers may well have abstracted this one-to-one connection and created a more meaningful term for you to refer to. E.g., they could have used a single CAS to connect to multiple Cloud accounts and provided the CAS’ names that might have better contextual meanings to you as a user. In most situations, your administrator should already have exposed only the CASes that you need access to and you may not even need to bother about what they represent, except for the immediate connotations like, use the Development CAS to launch dev servers and use the Production CAS to launch production servers. That sort of thing. (It is not essential to understand this to be able to use the Service Portal).

  2. A Region: Region is a further classification method within a CAS. In many public and private clouds, the concept of a Region may already have a natural correspondence. E.g. the regions in AWS or Azure. But, in case of others, this could be something artifically created by the developers. For example, in the xPlore.Cloud reference implementation for VMWare, the Regions correspond to different vSphere or ESXi hosts. Again, in most cases, your Administrators should already have restricted your access to the ones that are relevant to you and you may not need to directly bother about this at all. (It is not essential to understand this to be able to use the Service Portal).

  3. Feature/Cloud Resource: * A Feature usually corresponds to a particular Cloud Service, which may or may not correspond to a particular Cloud Resource. For example, a Server feature within xPlore.Cloud represents a Virtual Machine. But, in different clouds this might be called by different names and exposed through specific cloud services. At AWS, these are EC2 instances, in Azure and VMWare this is called a Virtual Machine. But, within xPlore.Cloud, this will always be referred to as a Server.

    Within the Service Portal, when you click on a Feature name in the Features drop down (marked by an orange rectangle in Fig 1 below), you should typically get back a list of instances that corresponds to the Cloud Resource that corresponds to the Feature. For instance, in Fig 1, we see a list of Servers (EC2 instances in this case as this is an AWS account).

https://docs.xplore.cloud/_static/img/xplore-adminview-001.png

Fig 1: Owner/Admin view of xPlore.Cloud front-end

  1. Action: * An action is some kind of an operation on a Feature/Cloud Resource. For example, for the Feature Server, there can be the following actions:

    1. Resync (Resync xPlore.Cloud data cache with that of the target cloud)
    2. Create (Create a new server)
    3. Start (Start a server)
    4. Stop (Stop a server)
    5. Terminate (Terminate a server)
    6. Console (Launch a RDP/SSH connection to the server)

    Within the xPlore.Cloud Service Portal, actions appear as buttons in the row representing an instance of the corresponding cloud resource. In Fig 1 above, these appear within the blue rectangles. The small rectangle at top-right are the global actions Create and Resync.