Virtuozzo Application Platform 5.1/5.2

This document is preliminary and subject to change. In this document, you will find all of the new features, enhancements and visible changes included to the PaaS 5.1 and 5.2 releases:

• Features
• Improvements
• Bug Fixes

For detailed information on using any of the platform features, please refer to the users' documentation.

Features

Transition of Platform Infrastructure into Docker Containers Optimized UX for Deployment, Tasks and Env Management Panels
Billing History Data Export
Auto Update of Dockerized Stack Templates
FTP Access to Storage Container

Back to the top

Transition of Platform Infrastructure into Docker Containers

The infrastructure node represents a set of internal components, responsible for performing all operations within the platform (e.g. managing resources, processing requests, supporting system maintenance, etc.). Starting with 5.1 PaaS release, all infrastructure modules are provisioned as Docker containers, ensuring the following inherent benefits of this containerization technology:

• resource utilization - allows to apply more lightweight solutions with lower resource consumption to run applications
• standardization and compatibility - reduces risk to meet problems with resolving application dependencies or OS related issues, as Docker containers run in the same way on any hardware
• isolation and security - ensures infrastructure modules' insulation (so that containers can’t affect host system or each other), which grants complete control over traffic flow and management

As a result of such transition, the Platform upgrade procedure was notably simplified and accelerated, allowing to deliver new platform features much more quicker. More info

Optimized UX for Deployment, Tasks and Env Management Panels

In order to simplify operating with multiple environments in the platform dashboard, its user interface layout has been updated. For that, Deployment Manager and Tasks sections were merged into a single collapsible frame with the appropriate tabs being available at the bottom of the dashboard. If needed, this panel can be minimized to free more space for your environments list display, making it easier to access the required options.
Also, upon working with a particular environment, a dedicated tab will be opened at the bottom of the above-mentioned frame (next to the default Tasks and Deployment Manager ones). Here, all available management operations for this environment (like Settings, File Manager, Logs, Statistics, etc.) are grouped, being opened into separate sub-frames within a single tab. Herewith, such additional environment-dedicated tabs can be closed if they are no longer needed, while Tasks and Deployment Manager ones are opened permanently.
More info

Billing History Data Export

To help you with financial analysis of hosting spends, a possibility to download billing history as a csv file was implemented within the current 5.1 Platform version. The appropriate Download CSV button was added to the Billing history section (for both per environment and per account options). In order to make the displayed data more clear and to speed up its fetching, the following gradation was added for the Interval field:

• hour - can be used with 1 day period
• day - can be used with 7 days period
• week - can be used with 4 weeks period
• month - can be used with 1 year period
• year - can be used with 10 years period

Herewith, by shifting the data range (with the appropriate Start and End fields), you can get a granular billing history info even for the oldest data. For example, to get statistics on daily spends from a year ago, specify a period with 7-day difference or less (e.g. from 01-01-2016 to 07-01-2016).

Auto-Update of Dockerized Stack Templates

Within the current platform upgrade, a special tags auto-update option was implemented for dockerized templates. This feature is intended to regularly renew the lists of provisioned stack versions according to the latest updates within the central templates repository. As a result, new software releases become automatically available for you with almost no delay due to eliminating the necessity of hosting provider’s manual intervention. Herewith, the update frequency and enabling of this feature in general depends on a particular platform settings.

In conjunction with the latest tag improvement, such tags auto-update approach allows to keep utilized server software actual - the delivered updatescould be easily integrated by means of the Docker container redeploy functionality.

FTP Access to Storage Container

In order to make data management within Storage container more comfortable, FTP support was implemented for this type of node. Within the current 5.1 Platform release, FTP add-on was updated to enable its installation on Storage environment layer just as on any other one (load balancer, application server, etc.). Immediately after that, you can start working over FTP with any prefered client application (e.g. FileZilla) to transfer files, read and download logs, edit configurations, synchronize folders content and so on.

More info

Improvements

UI/UX Improvements
API Improvements
MySQL/MariaDB Security Enhancements
Default Aliases for Container HostnameMaster Node Environment Variables (5.2)
Fixes Compatible with Prior Versions
Software Stack Versions

[Back to the top](#back)

UI/UX Improvements

Latest Tag for Dockerized Stack Templates Basic Management Options within Empty Environment Group Layout
Clarification on Port Settings for Docker Containers

Latest Tag for Dockerized Stack Templates

To simplify operating with various software, all platform dockerized stacks were complemented with dedicated latest tags: per whole template (tomcat:latest, mysql:latest, etc.) and per each major stack version (tomcat:7-latest, mysql:5.7-latest, mariadb:5-latest). Herewith, the appropriate grouping is automatically applied to stack tags list within topology wizard:

• if stack has several versions, they will be shown in the expandable list with the latest tag at the top (hover over to see the exact version)
• if stack has several minor versions of the same major one, the appropriate record will be converted into a general view (e.g. 7.x.x) with a list of exact minor releases and the corresponding latest tag (e.g. 7-latest)

Basic Management Options within Empty Environment Group Layout

With an aim to make dashboard UI more intuitive, background for an empty environment group was updated with buttons on a number of common actions, which may be needed to get started with this feature. Namely, quick access was provided to the following operations:

• Create New Environment
• Add Environment to This Group
• Deploy Solution from Marketplace

And for the case there are no environments within an account at all, the similar background was added to the dashboard start page. Herewith, the Collaborate on Shared Environment option is shown instead of the Add Environment to This Group one. More info

Clarification on Port Settings for Docker Containers

By default, all Docker containers within the platform are provisioned with the following open ports: 80, 8080, 8686, 8443, 4848, 4949 and 7979. In case any other container port is needed to be accessed via Shared Load Balancer, the appropriate endpoint can be easily attached to the environment. Alternatively, Public IP can be used to get direct access to all container ports.

To make such specifics more clear, the appropriate Ports tab within the Docker container settings wizard was updated. For now, it provides a core information on default ports, endpoints / Public IP usage and has a special explanatory image to visualize ports behaviour, making it easier to percept. More info

API Improvements

New GetEnvs Method with Pre-Sorted Response
Set- & Get- ContainerEnvVars Methods for Environment Layer
Support of Parameters Aliases within CLI Commands
Updated Namespace for API Calls within Cloud Scripting

New GetEnvs Method with Pre-Sorted Response

The GetEnvsByCriteria is a new API method which allows to get information about all your environments whilst sorting them to simplify the perception. It uses a special criteria parameter (specified in JSON format) with the following options:

• order - can be assigned either ASC or DESC value to sort environments in ascending / descending order respectively
• orderField - sorts environments by either status (e.g. running, stopped) or name

In case of a big number of applications and projects being run on an account, this method can help to speed up and simplify the appropriate data fetching.

More info

Set- & Get- ContainerEnvVars Methods for Environment Layer

In the present PaaS 5.1 release, two new API methods were added to help managing environment variables in Docker containers and dockerized stacks. Both operations were designed to work with all the nodes within a layer:

• GetContainerEnvVarsByGroup - gets list of all the environment variables
• SetContainerEnvVarsByGroup - sets variable values for nodes of a particular type

In conjunction with the on-going conversion to the dockerized templates, these API methods will be especially useful, as they will become applicable for all platform-managed stacks.

More info

Support of Parameters Aliases within CLI Commands

A lot of API methods in the platform have a number of aliases for their parameters (i.e. alternative names, which can be used on a par with original denominations). Usually, such variations appear due to steady API development, supporting legacy implementations and ensuring backward compatibility. For example, the frequently used envName parameter can be equally replaced with its previous appid or domain denominations, whilst zdt parameter name can be similarly substituted with the atomicDeploy string, and so on.

In the current 5.1 platform upgrade, support of such aliases was implemented for platform CLI as well (including the appropriate parameters designation within JSON files). This allows developers to operate with the same preferred parameter denominations when using both API and CLI.

More info

Updated Namespace for API Calls within Cloud Scripting

The platform API documentation provides examples on calling methods via HTTP using URL (REST) and through Cloud Scripting (Scripting). In the current upgrade, namespace for the latter one was updated to a new format through substituting its hivext part with jelastic string. As an example, for now the following expression should be used when referring to VCS API requests - jelastic.environment.Vcs.{method-name}. Herewith, the former version (i.e. hivext.environment.Vcs.{method-name}) is considered outdated, although remaining operable for compatibility reasons.

More info

MySQL/MariaDB Security Enhancements

According to native MySQL and MariaDB implementation specifics, a one will see the appropriate directory content if accessing a page with no specified entry point on these servers via direct URL. In most cases, such behaviour should be avoided as it may reveal some sensitive data (e.g. backups, temporary or hidden files, etc.), which must not be exposed for clients. Thus, restriction on directory indexing was enabled for both MySQL and MariaDB stacks.

Another implemented improvement is automatic generation of self-signed certificates for MySQL/MariaDB nodes, which allows to establish encrypted HTTPS connection to their admin panels via Public IP right after instance creation, i.e. without any additional configurations being required.

Default Aliases for Container Hostname

When referring to a particular container, two formats of a hostname could be used in the platform internal DNS (with either hyphen or period as a separator):

• node**{node_id}**-**{env_name}**.**{hoster_domain}** - default record for all node types
• node**{node_id}**.**{env_name}**.**{hoster_domain}** - additional record for Docker containers (i.e. beside of the default common one)

where:

• {node_id} - unique container identifier
• {env_name} - internal environment domain (based on environment name, set during its creation)
• {hoster_domain} - domain name of a platform a node was created at

From now on, both of the above-specified records will be automatically added for each new container and can be used for refering to both native and Docker containers. Herewith, for the already existing containers, number of DNS records will remain the same.

Master Node Environment Variables (5.2)

When setting up an environment topology, the very first instance to be created on a particular environment layer is automatically considered as a master, i.e. the main one. For example, such initial container will be taken as a template for all layer nodes during environment cloning or, in case High-Availability is enabled, applications will be deployed only to the master node. Starting with the 5.2 PaaS version, each newly created Docker container (and dockerized stack) is provisioned with the master node details for a layer it is placed at, which are defined within the appropriate variables:

• MASTER_ID - unique digit identifier (Node ID), e.g. 226501
• MASTER_HOST - network address for referring to a master node, composed of container ID and environment name (without the Platform domain suffix), e.g. node226501-my-app
• MASTER_IP - master container internal IP address, e.g. 192.168.13.31

Such implementation will help to identify master node much easier - for example, to discover a container where the data is actually stored when utilizing master as a storage for sharing data across the layer. Also, when packaging clustered solutions via JPS, these variables allows to prescribe the appropriate master node host and IP address fetching without an environment being actually created yet.

Fixes Compatible with Prior Versions

Below, you can find lists of fixes which except of being implemented within PaaS 5.1 and 5.2 releases, have been also integrated to preceding platform versions by means of the appropriate patches:

Back to the list of Improvements

Software Stack Versions

The most notable software stack updates in confines of PaaS 5.1 and 5.2 releases are:

• the legacy Ruby versions (namely 1.9.3, 2.0.0 and 2.1) are no longer maintained by the platform
• the latest Ruby 2.4 release was added
• the RHEL OS template support was implemented for Docker containers

This way, for now the list of the component templates versions is the following:

Back to the list of Improvements

Bug Fixes

In the table below, you can see the list of bug fixes in PaaS & CaaS 5.1 and 5.2:

Back to the top