Cloud Manager » Deploying Markeplace Solutions

CloudManager allows packaged (Marketplace) Solutions to be easily installed by users with OneClick and minimal to no configuration. The administrator can make this solutions available either as part of a Solution Repository or standalone. This is useful to make common solutions and services easy to install, such as databases, message-brokers, reusable middleware (e.g. a SSO Gateway or Payments Gateway), dev/devops tools, and other sorts of applications such as CMSs, game servers, and what ever the administrator considers useful.

Browsing Solutions and Solution Repositories

A sub-set of solutions selected as featured by the administrator is displayed in the user dashboard (the landing view when a user logins and/or navigates to the cloud manager from other apps). To display the full-set of marketplace solutions click on the button Marketplace in the top-right toolbar. This navigates to Solution list view.

In the Solution list view, all enabled standalone solutions and solution declared in Solution Repository indexes are displayed. For each solution item, the name, icon, keywords, and short description is displayed.

When using CloudManager in EInnovator Public Cloud cloud.einnovator.org several Solution Repository with a large number of solutions are pre-defined and ready for install. When using on-premises installations it may depend on the administrator choice. Some Solution Repository are pre-configured at deployment time, but the administrator may change the set of available repositories, or disable/enabled different solutions.

Image shows a snapshots of a list of marketplace solutions.

Solution List

Installing Solutions

Installation solutions is mostly straight-forward. The solution details page show a summary details about the solutions, including an name, icon, keywords, description, project home, etc. Often more than one version is available. A combobox selector can be used to select the version to install.

Currently, Cloud Manager support two-types of packaging for solutions: Helm charts, and extended manifest files. The installation experience for the two types of packaging is similar, and in many/most cases users can perform the installation without much considerations about the type of packaging being used. It is also possible, that the same solution may show up in more than one repository, with same or different packaging type.

For solutions packages as Helm charts, you can open configuration modal with button Config. This allow default settings for the installation configuration to be modified. Common setting that are available for update include memory and storage footprint, number of replicas, username/password credentials, ingress URL, and other. The modal also allow to preview the README.md file packaged with the Chart, and some meta-data about the Chart.

For solutions packaged as manifest files, the UI for resource selection is different. Some solutions support multiple plans that can be selected from.

Image below shows a snapshots of the UI with the details of a solution packaged as an Helm Chart (Zookeep) (left-hand side), and the configuration settings modal (right-hand side).

Solution Details Chart Config

Button Install opens a modal to make setup final installation details, including:

Space — where the solution should be installed. (and the underlying Cluster)
Name – name for the installation:
- For Helm charts, the name is designated as the release name.
- For extended manifest files, the name is used as base to name created resources (e.g. Deployment, Pod, Service, Secret, ConfigMap) – as full name or as prefix to such names.

For extended manifest files additional fields that can be specified include:

Host – host name to create a route/ingress. Other may be added.
Category — descriptive category or type of deployment
Stack — (optional) Stack used in implementation
Auto-Environment options:
- Auto-Env — To created stack-dependent options
- Space Inherit — Inherit common Space-level defined environment variables
- Cluster Inherit — Inherit common Cluster-level defined environment variables
- Connectors — Create a default connector for the deployment to allow other services to bind to
- Bindings — To create stack-dependent bindings for the deployment
- Ignore Unbound — True if bindings that don’t have a matching connectors in the Space should be ignore