Edge-Cloud Console Guide for Developers
Familiarize with our Edge-Cloud Console to start deploying your applications through our easy-to-use interface.
Last Modified: 7/1/2020
Welcome to the Edge-Cloud Console Guide for Developers! Here, you will learn about the various elements and components of MobiledgeX's user interface. This guide details the data fields available and the operations you can perform as you create your organization, add and assign users and roles, define applications, and deploy your application instances to our cloudlets. With your application(s) deployed, you can use our comprehensive Monitoring and Logging tools to obtain a detailed view of the activities performed by you and others within your organization, or analyze data and metrics to help you make informed decisions about application scalability--all within a single pane of glass.
Also, tooltips can be found throughout the Edge-Cloud Console wherever a question mark is available. Click on the question mark to access a brief helper text about an element or its function. Now, let's get started!
Create an account
First, create an account, if you haven't already done so. All users must have an account in order to receive an invite to join an organization.
To sign up for an account:
- From the Edge-Cloud Console click Create an account.
A Create new Account screen opens.
Provide your credentials. Here are some guidelines:
- Do not use spaces for Username; it must be all one word.
- Password must be at least 8 characters.
- Provide a valid email address. Use this email address later to access a link and verify your account.
- After you created your credentials and successfully logged on to our Edge-Cloud Console, Artifactory and Docker registries are automatically created for you. There will be tutorials and workshops where you are required to logon to our Docker or Artifactory registry. You will use the same credentials to log on to those registries as you would to logon to the Edge-Cloud Console.
- An email will be sent to you with a link to verify your account. Once you've verified your account, return to the Edge-Cloud Console and log on.
- Select MobiledgeX Compute.
Password and account recovery
If you forgot your password, on the Login screen, click Forgot Password?, enter your email address, and click Send Password Reset Email. You will receive an email with a link to reset your password.
If you need to unlock your account, contact your MEXadmin.
You are now ready for a brief tour of our Edge-Cloud Console where you will learn about the various elements and components available there. Preparing your application(s) to deploy on one of our available cloudlets is easy using our Edge-Cloud Console.
Create an organization and manage users
Note: Fields that contain an asterisk are mandatory and require user input.
Before you can distribute, upload, and manage applications on the MobiledgeX platform, you need to create an organization. You can think of an organization as a group of users on the MobiledgeX platform with associated applications and application deployment policies. When an organization is created, the MobiledgeX platform automatically provisions Docker container and virtual machine registries for exclusive use by the organization. You can add developer users to your organization at anytime either during or after creating your organization.
You must create an organization upon logging onto the console for the first time. Additional organizations can be formed after that. Organization names must be all one word, with no spaces or special characters.
TIP: It's best practice to keep the name of your organizations all in lower-case. There are sample files in our tutorials and workshops that require specifying Organization names in lower-case to ensure your application uploads successfully to our registries. See Step 2 within the Deploying an Application to the MobiledgeX platform guide for an example.
When selecting MobiledgeX Compute after logging on to the Edge-Cloud Console, the first screen that appears is the Organizations screen. This screen is where you add your organizations and users(optional).
To add an organization:
- Click the + icon on the screen. The Step 1 Create Organization page opens.
- For Type, select Developer or Operator. The type of organization you wish to be a part of depends on tasks you are assigned to perform as defined by you or your company.
- For Organization Name, type in a name of your organization. Observe the the naming convention rules as mentioned earlier.
- Type in an address and phone number.
- Enable Public Image if you wish to allow any users [outside of your organization] to download the image associated to this organization.
- Click Create Organization. The Step 2 Add User page opens.
- Steps 7-9 are optional. For Username, add a 'developer' user you wish to add to your organization. If you wish to skip Step 2 Add User, simply click Skip where you can return to the Organization page.
- The right-side of the screen lists the available roles you can assign your users. Select the role for the user by clicking Select Role within the Role field to display the drop-down list.
- Click Add User. The Step 3 Verify your Users page opens.
- Once you verified all the information entered is correct, click Return to the Organization page.
Although your organization is listed, it's currently not managed. Click the Manage button associated with the organization you would like to manage. Remember to perform this step each time you log into the Edge-Cloud Console. Clicking the Manage button for your organization ensures you are working within the correct organization. Additionally, clicking Manage displays all the available submenus on the left navigation pane. However, to expand or collapse the submenus, click the icon as shown in the image below.
Next to the Manage button is a quick access menu where you can perform such tasks such as Audit, Add User, and Delete your organization.
You can view users added to your organizations. The Users & Roles page lists all users, roles, and associated organizations they were assigned.
The following actions may be performed on this page:
- On the Search bar, type in the first few letters of your search to filter your search.
- From the Actions menu, click the quick access icon and select Delete to delete the user.
Assign role-based access control (RBAC)
Role-based access control provides varying levels of access specified by the user's role and responsibilities. Setting the user's roles and responsibilities requires establishing permissions and privileges, therefore, enabling access for authorized users. MobiledgeX provides 3 different levels of RBAC with varying privileges, as outlined below. Note that specifying RBAC for each user are performed within the organization page.
- Manage: Users, Cluster Instance, Apps, App Instance
- View: Cloudlets, Flavor
- Manage: Cluster Instance, Apps, App Instance
- View: Users, Cloudlets
- Manage: None
- View: Users, Cloudlets, Flavor, Cluster Instance, Apps, App Instance
Service your applications through our cloudlets
Note: The Cloudlet page is read-only and cannot be modified.
MobiledgeX cloudlets are deployed as close to the wireless network edge as possible, enabling you to access the most optimal backend for servicing your applications. Several cloudlet components directly contribute to providing you with this level of access. Refer to our Product Overview guide for more details about these components. The determining factors that dictate where you can deploy your applications include resource policies, preset locations, and the availability of cloudlets.
The Cloudlets page lets you view the available cloudlets where you can deploy your applications. For some cities, you may notice that there are multiple cloudlets available. Different Operators provide these cloudlets, and you have your choice of cloudlets to deploy your application instances.
The following actions may be performed on this page:
- Filter the available cloudlets by specific regions
- Use the Search bar to search for specific cloudlet. Type in a few letters to auto-populate your search results
- Zoom in and out to increase or decrease the view of the map
- Hover your mouse over the highlighted [numbered] cloudlets on the map to view the name of the available cloudlet
- Click the actual highlighted cloudlet to drill down to the location. Click the icon available on the bottom left corner of the map to return to the original map view
- Toggle Map: to only view a list of cloudlets and hide the entire map
- Click the refresh button to refresh the list of available cloudlets
Choose a flavor (compute substrate)
Flavors are the varying compute substrates divided by region, and based on cloudlets. Flavors include the number of CPUs, disk space, number of GPUs, and RAMs size that are best suited for running your app instances while delivering consistent processing performance. Depending on your application and the appropriate resources needed, such as CPU and memory, specify a flavor when you create a cluster instance.
Guidelines for specifying flavor
When specifying the flavor for your app instance, the flavor assigned to the app instance is dependent on the following scenarios.
Case 1. Manual. When a cluster instance is designated Manual (created manually), the flavor that is selected for the cluster instance will be the default flavor for all app instances without an app-specified flavor. Please see (3.) for further details of the app-specific flavor.
Case 2. Automatic. When an auto cluster instance is created, the flavor applied to all app instances associated will be the flavor automatically identified as the most optimum resource for the app instance. Please note, apps with an app-specific flavor will use the flavor automatically selected by the auto cluster. However, if no app-specific flavor is set for the app instance, the default flavor specified for the auto cluster will be applied for the app instance.
Case 3. App-Specific Flavor. When an app is associated with an app instance, a flavor may be designated to be the app-specific flavor. App-specific flavor applies only for apps associated with manual cluster instances. App-specific flavor serves as that particular app's default flavor. If an app-specific flavor is not selected and left blank, the default flavor applied for that app will be the flavor designated for the manual cluster instance.
The following actions may be performed on this page:
- Filter flavors by region
- Type in a few letters to auto-populate your search results
Create cluster instances
A cluster instance represents a collection of compute resources on a cloudlet for deploying your application instance, or containers. For example, you can select a Kubernetes cluster to deploy your pods, or select Docker to deploy your Docker containers. Note that some of the required fields should be identical to the information entered for the Application Definition, where applicable.
Shared Volume support
MobiledgeX utilizes Shared Persistent Volumes for Kubernetes deployments. Shared Persistent Volumes manage the storage of data within the cluster(s). If a container crashes and the kubelet restarts, subsequently, data within the cluster may be lost (the container becomes empty as a result of the reboot).
MobiledgeX’s support of Shared Persistent Volumes preserves your data by allowing you to share your Volumes across all nodes within the Kubernetes cluster. The data is transmitted via NFS over a private network. To take advantage of this feature, you must designate the amount of Gigabytes to be used by the Shared Volume field within the UI.
Note: Gigabytes utilized by the Shared Volume may not exceed 200 Gb.
It is essential to understand the various parts of the Shared Volumes and their dependencies on the supporting directories, which include Volumes, Persistent Volumes, and PersistentVolumeClaims.
Volumes: Directories containing data and is accessible to the containers within a Pod. While Kubernetes supports many different Volumes types, MobiledgeX supports PersistentVolumeClaims, and thus, making the Volume available to all the nodes within the cluster.
Persistent Volumes (PVs): Resources within the cluster. Persistent Volumes requires provisioning using a default storage class. You can view a PV as a resource in the cluster in the same way you may view a node as a cluster resource.
PersistentVolumeClaims (PVCs): Consumes the PV resources, and mounts the PV to the Pod. While Pods requests such things as CPU and memory, PVC requests specific size and access modes.
Accordingly, PVs are resources within a cluster, and PVC is the request for those resources contained in the cluster. Users may consume those stored resources across their nodes.
Some things to keep in mind about using Shared Volumes:
storageClassName within the PCV definition must either be set to standard or omitted.
- You may create more than one PVC using Shared Volume.
- The total size of the Shared Volume must not be exceeded by the PVC(s).
To set up Shared Volume support:
- Navigate to the Create Cluster Instances page.
- For Deployment type, select kubernetes. The Shared Volume size field appears.
- Specify the Shared Volume Size in GB. The minimum value is 1GB, and the maximum value is 200GB.
- Click Create.
Your Shared Volume is created. Once the cluster starts, a PV auto-provisioner is automatically created with a default storage class. If the Kubernetes manifest for the app specifies a PVC, a PV is created and then binds to the PVC.
- You can optionally set the Number of Masters and Number of Workers for your Kubernetes cluster. Each cluster has one master node and can have multiple numbers of worker nodes. Each worker node is a VM, so the more nodes you specify, the more applications you can run.
Kubernetes Manifest Example
Example Deployment using PVC
- name: myapp
- mountPath: /data
- name: demo-pv-storage
Define your applications for deployment
The Apps page lets you create application definitions for any applications deploying to our registry. Doing this creates an 'inventory' of your applications that are part of the registry. Creating an application definition also prepares it for deployment. Refer to our Tutorial: Deploying an application to the MobiledgeX platform for steps on how to deploy a sample application.
We currently support the following deployment options and file types:
|Supported Deployment Types
||Docker Compose (v3.8), Docker image
||k8s yaml with manifest, Docker image
||single helm chart
*For Helm, apiVersion v1 is currently only supported for helm charts.
The following actions may be performed on this page:
- Filter your Apps by region
- Create a new App definition
- Access the quick access menu under Actions to either Update, Delete, or Create Instance.
To specify your application definition:
- Navigate to the submenu Apps and click the + sign.
- Once the Create App page opens, populate all required fields.
- Click Create.
Warning: Validation between ports/names are not performed automatically. Therefore, when specifying your ports/names, you must ensure that there are no conflicts between them. Otherwise, your deployment will not succeed.
List of commands to upload images to MobiledgeX registries
The following lists all commands used to upload your images to our registries. Remember to replace the sample organization name with your own organization name.
If you are uploading an image to our Docker registry, use these commands:
$ docker login -u <username> docker.mobiledgex.net
$ docker tag <your application> docker.mobiledgex.net/testdorganization/images/<application name>:<version>
$ docker push docker.mobiledgex.net/testdorganization/images/<application name>:<version>
$ docker logout docker.mobiledgex.net
If you are uploading an image to our VM registry, use the following curl command:
$ curl -u<username> -T <path_to_file> "https://artifactory.mobiledgex.net/artifactory/repo-testdorganization/<target_file_path>" --progress-bar -o <upload status filename>
Deploy applications using different methods
Different methods are available to deploy your applications. Detail for each mode of deployment are covered below.
For VM deployment, use a VM image as a QCOW2 format. With the image, you can upload it to our MobiledgeX Artifactory. Upon uploading the image, you will be prompted for your username and password to proceed with the upload.
For applications deployed as Docker-based, we support Docker Compose files in the following ways:
- A Deployment Manifest argument for Docker Compose files used as input. You can either paste or manually type in your plain text file into the Deployment Manifest box or select the Docker Compose file located on your local server where it is loaded into the Manifest box.
- Docker Compose files referenced as a ZIP file. The ZIP file must be referenced from a web server (and not referenced locally), or retrieved from Artifactory.
Docker Compose files can include multiple images and options, as well as additional files. Make sure that if you are using a ZIP file as input, your ZIP file is not encrypted, and the URL should be accessible without requiring authentication.
ZIP files need to contain a
manifest.yml file, and should also include other contents, such as the example provided below. Based on the content of the
manifest.yml file, the system will read and execute the Docker Compose files within the yaml file, so it's important to remember that each file specified in the
manifest.yml file is present.
$ cat manifest.yml
For a dedicated cluster with IP access type Direct, input to the Ports argument is required. Although you may have specified the ports in your manifest, doing so does not open the ports automatically. You must also set (open) the ports via the Edge-Cloud UI Console from the Create Apps page.
Option 1: Docker Compose file as input
If you want to use the Docker Compose file as input, simply input the plain text manually into the Deployment Manifest text box from the Create Apps page. The other option is to use the file selection option and reference your file from your local server, where your text file is loaded into the Deployment Manifest text box.
Option 2: Docker Compose as a ZIP or nonZIP file from a file system or HTTP Server
To reference your Docker Compose ZIP file, make sure you are referencing it as a URL from an HTTP server. The server should be accessible without requiring authentication. For nonZIP files, you can use the file selection option and reference your nonZIP file from your local server, where it will load the content into the Deployment Manifest text box.
Option 3: Docker Compose as a ZIP file on Artifactory
If you wish to reference your Docker Compose ZIP file from Artifactory, you can do so the same way you reference the ZIP file from an HTTP server. Instead of navigating to an HTTP server, you're navigating to the ZIP file that you uploaded to MobiledgeX Artifactory. The format of the path is similar to the path that you provided when you first create your organization and pushed an image to our repository, like this:
You can reference a
k8s.yml file to deploy your application if you are using Kubernetes. You can optionally type in the content of your
k8s.yaml file directly in the Deployment Manifest, specify the URL to the path of your
K8s.yaml file, or simply locate your
K8s.yml file locally using the file selection option from the Deployment Manifest area. The content will load into the Deployment Manifest text box.
If you choose to use a Docker image to deploy a Kubernetes Manifest, you can:
- Specify the image path without an input argument to the Deployment Manifest. A Manifest will be generated for you.
- Manually provide a Deployment Manifest argument which includes the image path referenced within the Manifest itself.
Note: You cannot use a ZIP file with Kubernetes to deploy your application.
It's important to remember to specify the Service section within the
k8s.yml file. Otherwise, your deployment will not succeed. The following is an example of a deployment manifest.
- port: 80
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
replicas: 1 # tells deployment to run 1 pods matching the template
- name: nginx
- containerPort: 80
You can use a helm chart, which is a collection of files related to your Kubernetes resources, to deploy your application. If you wish to use a single helm chart for your application deployment, specify the URL path, for example,
https://resources.gigaspaces.com/helm-charts:gigaspaces/insightedge to the helm chart as input into the Image Path field under Create Apps. You are not required to provide any input into the Deployment Manifest section.
When you specify the helm chart as input in the image path, you have the option to add an Annotation. Annotations are conditions or tags added as dependencies. This area is a free form region where you can specify conditions or tags specific to your helm chart. For example, in the Key field, you can type in
version and in the Value field, type in the version of your helm chart, such as
If you require additional configurations for your application, such as adding environmental variables or including customization files for helm deployments, you can specify these types of configurations by specifying the content of the configuration file in the Config field, and selecting either Environmental Variables or Helm Customization.
Provision your applications
The App Instances page is where you provision your application and deploy it to a cloudlet. This step is called application provisioning. This page displays information such as the current applications running on the platform and their location. MobiledgeX allows you to deploy your applications to multiple cloudlets within the same Operator and region.
You also have the option to create an auto-provision policy, where based on the information you provide, MobiledgeX can automatically deploy your app instance for you and locate the most optimal cloudlet(s). Once you create your auto-provision policy, you must specify the policy during the application definition process within the Apps page. For steps on how to set up your auto-provision policy, see the section on Policies.
The following actions may be performed on this page:
- Ensure you specify the organization that you wish to manage. This ensures that the application you want to provision is within the organization you want to manage.
- From the App Instances submenu, click the + sign to launch the Create App Instance page. Or, from the Apps submenu, under the Quick Access menu, click Create Instance.
- Once you fill in all the required fields, click Create. It can take up to a few minutes to deploy your application to one of our cloudlets. The Progress bar displays the current status of the deployment.
Once deployed, information about the application appears on the App Instances page.
Debug and test
MobiledgeX provides terminal access to VMs for the purpose of debugging, testing, and monitoring the overall health of your VM. Access the terminal commands by selecting Terminal from the quick access menu under your application instance. You can also access Terminal from the Audit Logs page.
Manage your applications with policies
MobiledgeX provides several distinctive policies to manage your applications. Setting up these policies provide opportunities to allocate more compute resources, define privacy settings, and more.
Described below are three types of policies to help scale and manage your applications. These policies work independently of each other, unless otherwise noted.
The auto-provision policy can be set to manage the deployment of application instances to different cloudlets providing better service and redundancy. The auto-provision policy works by monitoring
FindCloudlet requests for applications across all cloudlets associated with the policy.
FindCloudlet returns the best available cloudlet by selecting the most optimal cloudlet based on what is defined for the auto-provision policy. If enough client
FindCloudlet counts for a particular cloudlet satisfy both Deploy Request Count and Deploy Interval Count thresholds set on the policy, a new application instance will automatically deploy to that cloudlet. Similar to the auto-scale policy, the min and max settings on the policy work to bound the number of application instances the policy will deploy.
Deploy Request Count: As mentioned earlier, the auto-provision policy works by tracking
FindCloudlet requests. Therefore, the Deploy Request Count refers to the
FindCloudlet count. Determining whether to scale up (deploy another application instance) is dependent on both the Deploy Request Count and Deploy Interval Count, where at each interval, MobiledgeX measures the number of requests since the last interval for each cloudlet. Each interval is approximately 5 minutes and is adjusted as needed by MobiledgeX. If the number of requests is above the Deploy Request Count threshold for that interval and remains above the threshold for ‘count’ subsequent intervals, MobiledgeX will deploy an instance to that cloudlet. Currently, if the threshold criteria are not met, we would not scale down (un-deploy an app instance), but rather instead not deploy. This behavior will change in a future release.
Deploy Interval Count: The number of intervals that meet the Deploy Request Count criteria to trigger automatic deployment.
Cloudlets: This is a list of available cloudlets in which your policy is limited to deploy your app instances.
Auto-provisioning will not deploy a new application instance on a cloudlet where an instance for the application already exists - regardless of whether that app was created manually or provisioned automatically. Once the auto-provision policy is created, you can reference the policy when you create a new application from the Apps page. Multiple policies may be attached to the same application to provide different levels of automation across different groups of cloudlets.
Note: Currently, only Docker and Kubernetes deployments can be auto-provisioned at this time.
To create an auto-provision policy:
1. Expand the Polices submenu.
2. Select Auto Provision Policy and click the + sign.
3. From the Create Auto Provisioning Policy screen, enter information for the required fields.
4. Click Create. The Step 2 Add Cloudlets page opens.
5. Finally, specify the cloudlets specific to the region you selected. Use the arrow to move your cloudlet selection to the box on the right.
6. Now click Add. Your Auto-Provisioning Policy appears on the Policies page. The quick access menu under Actions let you add cloudlet, delete cloudlet, or delete the entire Auto-Provisioning Policy.
The auto-scale policy governs scaling the number of nodes of a Kubernetes cluster to provide more compute resources for your application by monitoring the CPU load on the nodes [within the Kubernetes cluster]. When the CPU load on all nodes within the cluster rises above the scale-up threshold you set in the policy, another node will be added to the cluster. However, if the CPU load falls below the scale-down threshold set with the policy, that node will be removed from the cluster. These actions are limited to the min and max number of nodes set within the policy, to bound to the size of the cluster. Once the auto-scale policy is created, it can be referenced when creating a new cluster from the cluster instance page.
The ScaleWithCluster setting on your app should be set to true to have Kubernetes scale your app across all nodes within the cluster. Otherwise, your app will only run on one node in the cluster. As a result of that, auto-scale will not trigger, and you won't be unable to take advantage of an auto-scaled cluster.
Note: Auto-scale only supports Kubernetes deployments at this time.
To create an auto-scale policy:
- Expand the Policies menu.
- Select Auto-Scale Policy and click the + sign,
- From the Create Auto Scale Policy screen, enter all required fields.
- For the Minimum Nodes, set the minimum number of cluster nodes to scale.
- For the Maximum Nodes, set the maximum number of cluster nodes to scale.
- For the CPU Thresholds, set, in percentage, the min and max CPU threshold. The percentage range is between 1 and 100.
- Set the Trigger Time, in seconds. This Trigger Time defines the time that the sampled CPU threshold must be continuously met before triggering the auto-scale action. Setting the Trigger Time prevents possible anomalies of CPU activity (or lack thereof) from triggering unwanted scale up/down actions, if the anomaly activity occurs as the CPU usage is sampled.
- Expand the Policies submenu.
- To block all outbound communications, select Full Isolation.
- To specify the whitelisting of both destination IP and ports and allow for outbound communications:
- Select one of the supported Protocols, TCP, UDP, or ICMP.
- Specify your port ranges, if TCP or UDP was selected.
- Enter the Remote CIDR to specify the range of IP addresses that are allowed as destinations for outbound traffic. The Remote CIDR should use CIDR notation, for example,
Click Create Policy.
Monitor, improve, and analyze metrics and data of all clusters and applications deployed
The Monitoring Dashboard has been designed to allow the user the ability to drill down from higher-level components to lower-level components. For example, one can start at the cluster level and drill down to a single application instance.
Data is presented in tiles that are customizable, allowing the user to filter and display the analytics and data as desired. Additionally, a Stream option is provided to automatically refresh the data being presented every eight seconds.
We currently support monitoring of Kubernetes and Docker container type deployments. While you can filter by Clusters|Cloudlets and App Inst, the data and metrics rendered are specific to organizations rather than by application or cluster-specific. Therefore, when you filter by these two options, you are actually viewing clusters and application instances deployed globally within the organization.
The Monitoring Dashboard provides access to the following:
- Cluster level resource utilization, performance, and status metrics
- Load balancer (Layer 4) metrics and status
- Application Instance resource utilization, performance, and status metrics
- Application Instance event logs, showing state changes and other Application Instance events
- Distributed Matching Engine (DME) metrics, including location-based metrics for remote users
View audit logs
Historical activities performed by you and others within your organization are logged and viewed from the Edge-Cloud Console. These logs are used for diagnostic purposes or error correction, and each activity is logged by date and time. You can trace different events through the various sub-sections, which are separated into three parts-- Raw Viewer, Request, and Response. These sections provide valuable information if you require support from MobiledgeX. Simply copy and paste the traceid from the Raw Viewer section, and email the traceid to [email protected]
The following actions may be performed on this page:
- Filter logs by region
- Filter logs by time range
If you have reviewed our documentation set and FAQ page, and unable to find an answer to your question, you can contact our Support Team.
You can also email the Support Team to assist you in resolving product issues. To help expedite your request, make sure you copy and paste the tracid, which can be found on the audit logs page, into your email with a brief description of your issue.
Where to go from here