The New Cloudify UI – Features and Tutorial
We recently wrote about our most innovative release yet, Cloudify 4.0. Part of this grand release was the shiny new user interface. With this post, I want to highlight most of the components of the UI, and hopefully give you all a good idea of the work that went into building this as well as the power of this dashboard tool.
The main concept behind the Cloudify UI framework is to supply a catalog of different components, each showing a specific scope of data, allow users to build their own personalized dashboards by combining the components that are most relevant to their deployments, and control them from a single pane of glass. We call these components “widgets”.
Watch our Cloudify 4.0 webinar on-demand today! Go
Cloudify UI Framework – Overview and Concepts
UI Structure: Templates and Pages
Cloudify’s UI framework is built from templates. A template is a pre-defined set of pages, where each page offers a view of specific aspects of the system. The pages, and the way they are organized, optimize the presentation of the relevant data for the current user. We provide two out-of-the-box templates – one for Cloudify users who might want to run services from a catalog and manage them, and one for sysadmins who orchestrate the environment and manage Cloudify’s settings.
The building blocks of the UI framework are the widgets (on the left sidebar). Cloudify’s UI comes with a catalog of out-of-the-box widgets which are designed to present different types of data in a variety of forms. We provide a blueprints + deployments + executions view, plugins and snapshots lists, monitoring graphs, and data regarding the users, groups, and tenants in the system, and more. The catalog also contains graphs, action buttons, topology and source views, and even widgets that retrieve data from external applications like Github.
Edit Mode allows the users to add more pages and customize them with new widgets from the catalog. This option is always available for admins, and can be made available to users if enabled by an admin in the configuration settings.
As part of Cloudify’s “open architecture” concept, the UI framework allows users to write their own widgets and publish them in the catalog. Users can write widgets that present Cloudify’s data, and even combine widgets that share an external system’s information which you would like to present as part of a unified dashboard.
Users can also define a different configuration for each widget they create regarding its behavior, presentation, or access control. For example, you might want to limit the access of some of your widgets so that only admins are able to add them to their pages.
The colors, logos, and appearance of the screens can be edited to fit your company’s needs as well. This is Cloudify’s way of ensuring your dashboards are customized to your needs and preferences, and truly represents what you would like to see in your applications management portal.
Performing Actions in Cloudify UI
This section of the blog post will cover user and admin-only actions from the point of view of someone inside the UI. We will be uploading a video soon to show these steps in a visual manner.
Admin and User Actions
Login and Logout
Cloudify 4.0 supports user management, and you must therefore login to the manager with a user – either one that is defined in Cloudify itself, or via an LDAP system that Cloudify is set to work with. You can see the logged-in user in the top right corner of the screen, and perform action from the user drop-down menu.
Cloudify 4.0 supports resources separation between different tenants on the same manager.
Upon login into the manager, each user will have a list of the tenants available for him, and switching between them is done simply by choosing the desired tenant from the list.
Each action regarding a Cloudify resource – blueprint, deployment, execution, plugin – is made in the context of the current tenant. That means a blueprint uploaded to a specific tenant will only be available to users who are permitted to access this tenant. If you can’t see a resource you created, make sure you are in the right tenant.
The default tenant is the tenant automatically created upon the Manager’s creation. No users or resources are automatically assigned to it, or to any other tenant.
The first page in the template is an overview dashboard presenting the status of the system. Admins will see how many deployments, plugins and nodes are running, and also a list of the systems’ logs and events. User’s template dashboard will show statuses of deployments and executions.
The blueprints catalog contains a widget showing the Cloudify Examples Github repository. You can set the widget to show the content of different repositories. If the repository contains a PNG file named “blueprint.png”, that image will be presented as the icon in the catalog. To upload an application blueprint from the repository, just choose “upload”.
On this screen you can see the blueprints that have been uploaded to the current tenant and choose to deploy them. The widget can be configured to show the blueprints in either a catalog or table view.
When clicking on a specific blueprint you get to the blueprint’s drill-down page where you can see its topology, the deployments instances from this blueprint, inputs, outputs, and the blueprint’s source code. You can also upload new blueprints from this page, by choosing the “upload” option.
The deployments page presents the active deployments in the current tenant and the statuses of their nodes. From this page you can perform actions on deployments, such as executing a workflow, and drill-down into a specific deployment to see it’s executions, topology, inputs and outputs, and source code. You can also execute workflows from the inner page of the deployment.
Managing tenants, groups and users
Tenants, user-groups, and users management can be done from the tenant-management page, which is available in the admin template out-of-the-box.
Connecting to LDAP
To work with users managed in an external, LDAP-based user management system, you will first need to make sure our Cloudify server is configured for that option. This is done either while bootstrapping Cloudify Manager or by setting that option when the Manager is still clean, meaning no actions were performed on it yet.
You will then need to create Cloudify user-groups which are connected to the appropriate LDAP groups. Once you assign those groups to Cloudify tenants, you create the connection between LDAP groups and users, and Cloudify resources.
Now you can log in with an LDAP user that is a member of the chosen group. Cloudify will address the LDAP system for authentication, and will then allow the users to login to any tenant their group has access to. Once the user has logged into Cloudify, he will appear in the users list, but no actions on it will be available from Cloudify, to prevent creating gaps between the two systems.
Creating and restoring snapshots
Snapshots creation and restore is done from the snapshots widget. Upon migrating from an older, tenant-less version to Cloudify 4.0, you might want to restore a Manager’s snapshot to a specific tenant (by doing so you can restore snapshots from different managers to one manager with full separation). When you are performing this restore make sure to specify a new, non-existing tenant to restore to.
Plugins are uploaded to the manager as wagons. Like all other resources, plugins are uploaded to the manager in the context of the current tenant, so you might need to upload a plugin to more than one tenant if you want to use it with blueprints from different tenants.
You can find the OOTB cloudify plugins at http://getcloudify.org/downloads/plugin-packages.html.
For more information about plugins, please refer to the plugin documentation.
Secrets storage is implemented inside the Cloudify database in order to provide a variable store for data that you do not want to expose in plain text in Cloudify blueprints. For example, you might not want to expose login credentials for a platform to all blueprint users. You can therefore add those secrets and their keys here in the Secret Store page.
For more information on using secrets via the CLI, refer to the CLI documentation.
In Cloudify Premium, an admin user can create a cluster of Cloudify Managers to provide high availability of Cloudify Managers. To do that, we create a cluster containing one Cloudify Manager that is designated the active Cloudify Manager, and others which are designated hot standbys. The standbys concurrently mirror the data of the active Manager. In the event that the master Cloudify Manager fails, an automatic failover switch activates one of the hot standbys as the master.
You can define and manage the cluster from the HA page. For more information regarding Cloudify’s HA solution, please refer to the high availability documentation.
In this post, we looked at what Cloudify’s new and improved UI offers users interested in having a single pane of glass to handle their cloud deployments. As with Cloudify itself, our UI is designed to be tool agnostic, and users can plug in any external system with an API.
Watch the tutorial video below to see the UI in action:
We are always improving the UI, so come back soon for more Cloudify UI goodness!