IM Web Interface

The IM Web client is a graphical interface to access the XML-RPC or REST APIs of IM Server.

Installation

Prerequisites

IM web interface is based on PHP, so a web server (e.g. Apache) with PHP support must be installed.

Also the mcrypt PHP modules must be installed and enabled.

It is also required to install the PHP module to access SQLite databases.

In case of using the REST API it is also required to install the CURL PHP module.

Installing

Select a proper path in the document root of the web server to install the IM web interface (i.e. /var/www/im):

$ tar xvzf IM-web-X.XX.tar.gz
$ mv IM-X.XX /var/www/im
$ chown -R www-data /var/www/im

Configuration

The web interface reads the configuration from $IM_WEB_PATH/config.php. It has the following variables:

Docker Image

A Docker image named grycap/im-web has been created to make easier the deployment of an IM web GUI using the default configuration. Information about this image can be found here: https://registry.hub.docker.com/u/grycap/im-web/.

This container is prepaired to work linked with the IM service container grycap/im, in this way:

  • First launch the IM service specifying the name “im”:

sudo docker run -d -p 8899:8899 --name im grycap/im

  • Then launch the im-web container linking to the im:

sudo docker run -d -p 80:80 --name im-web --link im:im grycap/im-web

  • It also supports environment variables to set the IM service location:

    • im_use_rest: Uses the REST API instead of the XML-RPC that is the default one. Default value “false”.

    • im_use_ssl: Uses HTTPS to connect with the REST or XML-RPC APIs. Default value “false”.

    • im_host: Hostname of the IM service. Default value “im”.

    • im_port: Port of the IM service. Default value “8899”.

    • im_db: Location of the D.B. file used in the web application to store data. Default value “/home/www-data/im.db”.

    • openid_issuer: OpenID Issuer supported use “” to disable OpenID support.

    • openid_name: OpenID Issuer name.

    • client_id: OpenID Client data.

    • client_secret: OpenID Client secret.

    • redirect_uri: OpenID Redirect URI.

    • cred_crypt_key: Key to crypt the credentials data. It must be 32 chars long.

docker run -p 80:80 -e "im_use_rest=true" -e "im_host=server.domain" -e "im_port=8800" -d grycap/im-web

There is also a version SSL enabled. In this case the docker image have a selfsigned certificate for testing purposes. Add your own in the docker command:

docker run -p 80:80 -p 443:443 -v server.crt:/etc/ssl/certs/server.crt -v server.key:/etc/ssl/certs/server.key -d grycap/im-web:1.5.5-ssl

Then you can access the IM Web portal in the following URL: http://localhost/im-web/.

Usage

The web interface of the IM enables the user to manage all the aspects related with the management of the life-cycle of his virtual infrastructures.

Register

To access the Web interface the user must register first to the application. Each user must include a username and a password to access the platform. From 1.5.6 version OpenID authentication has been added.

_images/register.png

Fig 1. Register page.

Credentials

The first step is to manage the user credentials to access all the components of the platform, specially the Cloud providers. Fig. 2 shows a list of user credentials. In this list there are two related with the IM components:

  • InfrastructureManager: user and password to access the IM service.

  • VMRC: user, password and URL to access the VMRC service

When a new user is registered (or access with OpenID credentials) the web UI automatically creates credentials to both of them to make easier the creation of credentials process. The rest of elements of this list are the user credentials to access diferent Cloud providers.

_images/cred_list.png

Fig 2. List of credentials.

Fig. 3 shows the form to add or edit the user credentials. Initially the user must select the credentials type using the selectors with the corresponding images type. Then the specific form for the Cloud provider selected will be shown, where the user must fill the needed fields.

_images/creds_add.png

Fig 2. Add new credential.

RADLs

The RADL section enables the management and share RADL documents with other users of the platform. Fig. 4 shows the list of RADLs available for an specific user. From the list the user can manage the RADLs and also launch the infrastructure described in the RADL with a single click with the launch button.

_images/radl_list.png

Fig 4. List of RADL documents.

In case of using a parametric value in the RADL document. The web interface will ask for them showing a modal dialog as in Fig. 5.

_images/radl_params.png

Fig 5. Launch a parametric RADL.

The user can add or edit an RADL document (if the they have the correct permissions). In this case the platform will show the RADL document form (Fig. 6). In the top of the form the user can edit the RADL document that describes the infrastructure to be launched. In the botton he can manage the access permissions to the document to users of an specific group (Permission_Group) or to all the platform users (Permission_Other). It uses a similar schema of linux file systems. The user can give other users access to read (r), modify (w) or launch (x) the RADL document.

_images/radl_edit.png

Fig 6. Edit a RADL document and permissions.

Infrastructures

The Infrastructures section enables the management of the infrastructures owned by the current user available in the IM service. The list (Fig. 7) shows a row for each infrastructure. The user can access the information about each VM of the infrastructure clicking in the ID of desired VM. He can also click in the message Show of the column Cont. Message to check the contextualization log as shown in Fig. 9. In case of failure of the contextualization process the Reconfigure button will be available enbling the user to invoke the ctxt. step again. The user can also delete the whole infrastructure or add new resources using the buttons of the next columns. When adding new resources the form show in Fig. 9 will appear. In this form the user will specify the RADL to add resources to the infrastructure.

_images/inf_list.png

Fig. 7. List of user infrastructures.

In the VM information page (Fig. 8) the user can see all the information about the VM. In the top of the page the state, the cloud provider where it is deployed and the available IPs are shown. The rest of RADL fields are shown below. In this section the user can look up for the credentials needed to access the VM (username, password or private_key). In case of the private_key a “download” button will appear enabling the user to download the key to a file to acccess the node. The contextualizacion message of this VM will be show if the user press the message “Show >>” of the row “Cont. Message”. The user can also stop, start and destroy the VM using the buttons located at the bottom of the page.

_images/vm_info.png

Fig. 8. Information about a VM of the infrastructure.

_images/cttxt_log.png

Fig 9. Contextualization log of the infrastructure.

_images/inf_add_resource.png

Fig 10. Add new resources to a running infrastructure.

Recipes

The Recipes section enables the management of a set of recipes to make easy the installation of certain applications to non advanced users. This feature is only enabled in case that the IM service recipes database is available to the web interface (see Configuration). Only Admin users can manage recipes. “Standard” users can only see the recipes and use it in their RADL documents adding application requirements like the following:

disk.0.applications contains (name='<application_name>' [and version='<application_version>'])
_images/recipes_list.png

Fig 11. List of recipes.

Fig. 12 shows the form to edit the recipe properties. The Admin user has to specify:

  • Name and version: Name a version of the application to be identified in the RADL document.

  • Description: A text to describe the recipe

  • Module: A module enable to group similar recipes in modules.

  • Galaxy Module: If the recipe need to download an Ansible Galaxy module it must be specified here, otherwise leave it blank.

  • Recipe: The steps in Ansible language to install the application.

  • Requirements: Some hardware requirements of the application. It will me merged with the RADL document where the application is included.

_images/recipe_add.png

Fig 12. Form to edit/add a recipe (only admin users).

Admin

In the Admin section, users with administrator permissions can manage users and groups of the web interface. Figures 13 and 14 shows the pages to manage users. The Admin user can assign groups to users and set the flag of “administrator”.

_images/user_list.png

Fig 13. List of users in the web interface.

_images/user_edit.png

Fig 14. Edit user data.

Figures 15 and 16 shows the pages to manage groups.

_images/group_list.png

Fig 15. List of groups in the web interface.

_images/group_edit.png

Fig 16. Edit group data.