Virtuozzo Application Platform 3.3 / 3.3.1

This document is preliminary and subject to change.

In this document, you will find all of the new features, enhancements and visible changes included in the PaaS 3.3 / 3.3.1 releases:

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


Multiple Environment Regions
I/O Usage Monitoring & Updated Statistics

Multiple Environment Regions

Providing impressive flexibility, today platform starts to remove the geographical constraints of cloud hosting, making it truly universal through giving hosting service providers the possibility to aggregate various types of hardware within the confines of a single platform. Being named regions, each of such hardware sets may have a different capacity, pricing and location, allowing you to:

  • choose between higher quality or more cost affordable hardware due to storage tiering
  • easily migrate environments between regions in order to instantly adapt to new conditions and requirements
  • achieve higher availability through distributing your applications among several regions in different datacenters throughout the globe, simultaneously working with a single platform and account

The preferred region for your project’s hosting (in case your hosting provider have added several) can be easily chosen through the dashboard - just expand the drop-down list of the available locations in the top right corner of your environment wizard. Every region is supplemented with a short description, intendent to reveal its main specifics, and the appropriate tiny icon, which can differentiate, for example, the actual geographical location of the corresponding hardware. The full information and pricing details for each of the regions can be found within the Quotas & Pricing frame (accessible through selecting the same-named item of the Balance dashboard menu or clicking on the More details… string at the bottom of the region’s list).

Using the abovementioned list, you can either specify the hardware set for your new environment or migrate the existing one (in case this ability is allowed by your hosting provider) to another location due to a more preferable hardware capacity, pricing policy or physical location. Such environment migration is an extremely powerful tool, that can help you to benefit in both cost and productivity - for example, you can choose cheaper hardware for the development/testing stages and subsequently migrate your production-ready application to the hardware with the best parameters, just before the release.

The corresponding dialog frame can be accessed through either selecting the Migrate… item within the list of regions while changing your environment topology or navigating to the environment Settings > Migration section. Herewith, two different relocation modes are provided, which availability depends on the current and chosen target regions:

  • live migration - available only between those hardware sets, which belongs to the same datacenter (such target regions are marked with the LM label). This type of migration allows to move your environment without any additional configurations or restarting the containers in it and ensures that your customers won’t face any downtime during this operation.
  • offline migration - allowed to be performed between any regions. In contrast to the “live” mode, in this case your environment will be shut down for the whole period of its relocation. In addition, most likely it will undergo some modifications (as this mode is implied to be used for migration to another datacenter) like changing the nodes' IP-addresses and, optionally, switching an environment to the new domain name (if it differs from the current region’s one). Thus, after the migration is completed, some manual configurations may be required to restore the normal operability of your application - all of the required information will be additionally sent to you via email.
    Note: that costs for the usage of resources and options may vary in different regions, thus it’s recommended to get acquainted with the appropriate new pricing model in advance, as it will be applied automatically after the relocation is done.

The complete guides on managing regions and performing environment migration in particular can be found within the corresponding linked documents.

More info

Back to the list of Features


The “Endpoints” term at the platform refers to the newly implemented feature of TCP/UDP mapping via the Shared Gateway, which became available within the 3.3 PaaS version. It is dedicated to significantly simplify the PaaS instances' collaboration with third-party tools and resources by providing the direct connection links (over either raw TCP or UDP protocol) without the mandatory Public IP address attached to the corresponding node.

The list of Endpoints can be managed within the environment’s Settings section under the same-named menu point. Depending on the nodes your environment includes, you can see some preconfigured endpoints here (like RDP links for the Windows-based containers) and also have an ability to Add some custom ones. During this operation, the following parameters should be specified:

  • Node - select a container of the chosen environment (using the drop-down list) the endpoint will be added for
  • Name - either specify the title for a new endpoint or select one of the preconfigured options (note that some instances, like DBs, may have some special protocols/ports listed in accordance to the functionality they handle)
  • Private port - local port that will be used for mapping (it’s substituted automatically in case the predefined Name was selected)
  • Protocol - select either TCP or UDP

The rest of the fields, i.e. Public port and Access URL, will be configured automatically by the platform.

You are able to add as many custom endpoints as it’s allowed for your account (this limit depends on your hosting provider) using the tool panel at the top, or Edit / Remove the already existing ones by means of the same-named buttons ibid.

Note: that for linking functionality to work properly with the VPS and Docker® containers, the corresponding private ports (stated during the endpoint addition) at these nodes should be opened by an owner manually.

To get the detailed information on managing Endpoints and to find out the corresponding use cases, refer to our documentation.

More info

Back to the list of Features

I/O Usage Monitoring & Updated Statistics

Statistics monitoring is an easy but powerful tool, that helps to manage environments smartly. The information, provided by the platform in-built statistics module, covers all the billable resources' consumption, so it can help to adjust the topology according to your needs and to cut the spends greatly. In the current PaaS 3.3 release the Statistics section, which can be accessed through selecting the same-named button next to the necessary node of an environment, has been completely redesigned and improved to show an even greater amount of information, where the main amendment implemented became the addition of the very common and popular storage measurement method - monitoring of the Input/Output Operations per Second amount.

Now, inside the Disk statistics' section (formerly known as HDD), in addition to the amount of data stored by a node (presented in Mb at the left vertical axis), the containers' I/O usage is displayed (the second axis to the right of the graph with the input operations per second unit).

Note: that currently IOPS statistics for the Windows-based nodes is not provided.

Obviously, the more operations that are handled - the higher the system load is. Thus, to avoid the hardware efficiency degradation, their amount is limited - the corresponding I/O usage threshold (defined by the chosen hosting provider) can be seen at the same Disk statistics' chart, being marked with a red dotted line. Reaching this point implies that the performance of your container can be negatively affected, so it is needed to enlarge the number of servers used or to optimize the application itself (you can set the appropriate load alert for being additionally notified about this).

To find more information on the I/O statistics usage, refer to the corresponding guide.

Besides that, the whole Statistics section has undergone a few more changes, like:

  • all four graphs were complemented with a line, which displays the corresponding resource’s limit, herewith:
    • CPU and RAM limits are defined based on the cloudlets amount you’ve allocated for a node
    • Network and Disk limits depend on your hosting provider settings
  • measurement units were moved to the popup legend
  • numerical values are rounded with a new algorithm now, which makes them easier for perception

In such a way, every resource type, consumed by your environment, can be monitored with the improved usability and level of clarity. Find more information on the resources' usage tracking in our documentation.

More info

Back to the list of Features


Zero Downtime Deployment for PHP (3.3 / 3.3.1)
New Style for One-Click Installation Widgets
Pre-Installation Access to Docker® Container Settings (3.3.1)
Platform API Refactoring (3.3.1)
Scroll Lock for Logs Auto-Refresh (3.3.1)
Software Stack Versions

Zero Downtime Deployment for PHP (3.3/3.3.1)

The absolute majority of production environments need to be accessible to customers at any time, and the most common problem here is the process of project re-deployment (update). Usually, it is solved with the help of additional software (Capistrano, Fabric, etc.), but their integration is rather complicated and may require extra resources or even instances, as well as the valuable time spent for configuring these tools.

Obviously, a better solution is required, and such was proposed for PHP applications, run on the top of Apache, by the father of this programming language and simultaneously our technical advisor - Rasmus Lerdorf. The way the deployment process is managed, described in the linked article, was taken as a basis for the platform Zero Downtime Deployment mechanism implementation.

The core of this solution is in using a special requests' redirector, called *symlink *(symbolic link). Each time the deployment process is run (including the initial one), the corresponding app’s files are stored in a separate server folder, where the name includes the timestamp it was created at. This allows the deployment process to be completed without influencing the actual application version and customers, that are currently working with it. Once installation is finished, the abovementioned symlink switches to a new project folder, so all the newly received requests will be redirected to it for now. Herewith, the previous app version remains stored at the server, ensuring that all the “old” users' sessions will stay active to be eventually fully processed without interruption.

Note: that only two latest package versions are stored, while the older ones will be removed automatically during further deployments. Still, a particular folder can be simply renamed to avoid being erased.

As you can see, PHP zero-downtime deployment at the platform does not require any additional actions or resources, except the doubled disk space needed for the second project copy (which, nevertheless, can be easily released manually when all the “old” requests are processed). In such a way, you won’t experience any inconvenience, while the benefits of this new approach are obvious.

The improvement described above was integrated to both PHP application servers' templates - Apache (by means of the mod_realdoc module addition, which controls the symlink behaviour) and NGINX-PHP (though applying special configurations to the nginx.conf file). In such a way, this functionality is automatically ensured (regardless of the deployment source used - archive or VCS) at all of the new and already existing Apache or NGINX-PHP instances.

And starting with PaaS 3.3.1 version, the ZDT deployment feature availability is additionally controlled by your hosting provider. Also, you’ve got an ability to define whether you’d like to apply it through ticking the corresponding checkbox (with a link to the detailed information on this feature for comprehending its functionality) during your PHP app deployment to the ROOT context. Herewith, if a project source represents a VCS repository, this choice will be remembered and used for all the further auto-updates of an application, until the ZDT option is disabled manually.

More info

Back to the list of Improvements

New Style for One-Click Installation Widgets

The installation widgets become an important part of the platform invitation policy, representing a very flexible and powerful solution for applications' distribution. Such a widget can be easily prepared and placed at the required page for users to sign up and deploy the corresponding app within the platform, in just one-click.

Among the attributes a widget is configured with, the data-theme one is responsible for its visualization, allowing a choice from several available color schemes (flat-blue, flat-purple, flat-orange, flat-green). And recently this default styles' palette was extended with a new widget type, which is design to match the continuously evolving platform branding style. It could be enabled for all the new or already existing one-click installation widgets through stating the modern value for the abovementioned data-theme parameter to make your widget look much more presentable.
More info

Back to the list of Improvements

Pre-Installation Access to Docker Container Settings (3.3.1)

While working with Docker containers at the platform, you are supplied with specific information on their most common settings and can configure them directly through the environment wizard. But if the required template is just chosen for installation, normally it needs to be downloaded first (if working with the central registry hub) to provide all the required information about the corresponding environment variables and other startfile configurations. Thus, while adding a new Docker image, you used to have the empty fields instead of the required data at the container settings frame. Of course, you can already specify the necessary settings at this stage (and they will be applied as expected during the image installation and, in case of matching the default ones, will overwrite the default values). However, the problem here is that you can hardly predict the used parameters beforehand for setting them appropriately.

So, in order to deal with this hurdle, the platform-developed daemon for maintenance on Docker templates has been updated in the confines of the current 3.3.1 platform version. For now, all the abovementioned information is automatically fetched within the image manifest once you’ve entered the appropriate frame (i.e. the Docker container settings one) via the topology wizard. As a result, you can browse, edit and apply any necessary parameters even without downloading the image itself.

More info

Back to the list of Improvements

Platform API Refactoring (3.3.1)

In order to improve your experience quality while working with platform API, we’ve performed substantial refactoring (i.e. restructuring the existing code without changing its original behavior) for making it more clear, logical, and easier to understand. As a part of this refinement, the new altnames (alternative names) for some API parameters were added - you can find a couple of such improvement examples for the AddNode method below:

  • registryUser altname for dockerHubUser
  • registryUrl altname for dockerHubUrl
  • registryPassword altname for dockerHubPassword
  • dockerRunCmd altname for dockerRunArgs

All the newly added altnames represent aliases for their original names, so the complete backwards compatibility is ensured. Thus, all the already written integrations via our API remain operative without the necessity to obligatorily update them (until you’d like to get shorter and clearer code).

More info

Back to the list of Improvements

Scroll Lock for Logs Auto-Refresh (3.3.1)

Viewing the log files at the platform is supplied by a special Auto refresh option, aimed to help you in tracking your instances' activities in a “live” mode, i.e. without significant delays. For that, the most actual data on all of the actions that occurred is output within the appropriate frame, being continuously updated. However, this can cause some inconvenience, when, for example, there is too much information being received simultaneously or if you require some time to analyze the obtained results, while the information of interest has left far behind.

That’s why we’ve implemented a small amendment, which, however, is intended to improve the usability of this information source greatly. According to it, when you suddenly notice some important data among the received strings, you just need to scroll up a bit for the current frame’s position to be locked. Herewith, the most recent information will continue gathering implicitly, allowing you to consider the required records in more details. And upon returning the frame’s scroller to the bottom edge, it will automatically resume following the newly received information as usual.

More info

Back to the list of Improvements

Software Stack Versions

The component templates versions have been updated to their latest versions since the previous release:

StackPaaS 3.3PaaS 3.3.1
Tomcat 66.0.436.0.43
Tomcat 77.0.617.061
Java 61.6.0_451.6.0_45
Java 71.7.0_791.7.0_79
Java 81.8.0_451.8.0_45
MariaDB5.5.42 / / 10.0.17
MongoDB 2.6-2.6.10
MySQL5.6.24 / / 5.7.7
Centos 66.66.6
NGINX Ruby1.
Node.js0.10 / 0.120.10 / 0.12

Back to the list of Improvements

Bug Fixes

In the tables below, you can see the list of bug fixes in PaaS 3.3 and 3.3.1:

PaaS 3.3
JE-15522The unhandled error appears during Maven authentication failure
JE-16675Improper default WebSockets configuration for the NGINX-balancer/NGINX-PHP servers
JE-18079Internal DNS server is restricted to access the Memcached node because of the insufficient firewall rules inside
JE-19407Domain names with ‘_' symbol are allowed
JE-19843Ability to set a float value for the cloudlets' amount at the topology wizard
JE-19885The same list of environment variables is written for a few times for cartridges
JE-19945Ability to view exported files for the deleted environment
JE-19990Improper path to the custom context after it is renamed to ROOT
JE-20105Incorrect displaying of the Auto Horizontal Scaling dashboard section after exiting the Full Screen mode
JE-20136Error while trying to restart the slave node of the GlassFish 3 cluster
JE-20242Error while trying to enable HA in an environment with the already disabled non-NGINX balancer
JE-20318Authentication for Maven can’t be disabled
JE-20322Unable to deploy Java project with ‘_' symbol in the context name
JE-20417The “URL is not valid” error appears while trying to add the VCS project with username specified inside a link
JE-20474Incorrect validation while trying to add VCS project with the space in URL
JE-20485Ability to set the amount of resources smaller than the minimal requirements are via the topology wizard
JE-21091Unhandled error for accounts in collaboration with different Export/Import permissions
PaaS 3.3.1
JE-19468Ability to add an environment variable with {} characters for Docker® image causes an error while trying to edit the container settings
JE-19958The alignment position of engines' drop-down list varies for different tabs within the topology wizard
JE-20116The “Invalid action limits” error occurs if the newly set Scale up/down value matches the previously used value of the opposite one
JE-21386The 2.2.2 Ruby engine version is missed in the topology wizard
JE-21417Files of the deployed project are not present at all instances after importing an environment with multiple application servers
JE-21434Information about VPS is missed while exporting an environment with it
JE-21595Incorrect message within Task Manager record while resetting the password for the set of VPS or Docker® nodes
JE-21653In case Docker® image settings were not requested before its creation, an array with exposed ports is displayed as a single variable instead of being divided into separate ones
JE-21725Missed validation of environment variables names during their addition or editing for Docker® containers

Back to the top