Virtuozzo Application Platform 4.7 / 4.7.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 in the PaaS & CaaS 4.7 and 4.7.1-2 releases:
For detailed information on using any of the platform’s features, please refer to the users' documentation.
Features
Data Storage Container
Actualization of Limits for Existing Containers
[Back to the top](#back)
Data Storage Container
In the confines of PaaS 4.7 release, we are glad to present so much-awaited by lots of our customers feature - Data Storage Container. It represents a special type of node, intended for the part of data it comprises (named volume) to be shared with other server(s). This allows to benefit on better projects organization and advanced data handling possibilities, like:
- no redundant data duplications - just share the files among the instances they are required at
- simplified management - one set of configurations for multiple nodes
- data preservation - ensure safety of your data during application updates through storing it apparently
- funds saving - single data copy implies lower disk space consumption and therefore lower costs
Data storage implementation at the platform assumes usage of the network file system (NFS) on the storage node (server) to provide export of volumes to the remote hosts (clients). In order to set the communication and route requests between such containers, the remote procedure call (RPC) utility is used. Actually, the whole procedure is performed in two steps: at the first one, the data is exported (shared) from the storage container to some other instance, and at the second - the appropriate directory is mounted at a client.
And in order to ensure the best experience while leveraging this feature, the new Storage-dedicated node type has been implemented. It has a number of benefits for data storing compared to the rest of container types, such as depended software being pre-installed and enlarged amount of allocated disk space (whilst its exact amount depends on a particular hosting provider’s settings and can vary for different account types).
Beside that, the developed solution is applicable to all of the platform native container templates, as well as for Docker-based ones - the appropriate functionality can be accessed through the upgraded file manager and the renewed Docker volumes configuration section. Herewith, the whole process is completely automated, so that you only need to add a mount point through the corresponding form. All of the further required operations (including installation of the necessary software) will be done by the platform automatically. In such a way, any container can be easily treated as either storage or client upon the necessity.
Actualization of Limits for Existing Containers
There exists a number of limitations, which are defined by hosting service provider (e.g. limit on amount of nodes within a layer or environment, server size, network bandwidth, etc.) for each account type. They are always read and considered during the new containers creation, but, previously, their change (e.g. while upgrading an account) has not influenced the already created environments (so-called legacy ones).
Thus, during the 4.7 Platform upgrade maintenance activities, all of the existing containers will be automatically patched to match the required thresholds. Moreover, the new quotas' appliance flow was implemented, so that for now the changes made by your provider will affect not only the new containers, but all of the related ones. Herewith, if this should result in decreasing of the available disk space amount at a particular instance, the special pre-check procedure is performed, aimed to ensure that no data will be lost and at least 5GB of free disk space will remain free. Otherwise, i.e. if a new value does not meet these requirements, the quota will stay unchanged, ensuring normal container’s work, so you can be confident that no a single file will be lost due to this novelty.
As for the rest of limits, including cloudlets per container threshold, their alteration is applied without any pre-checks. So if you presuppose some limits changing for your old containers, it might be worth to review the appropriate apps performance after the upgrade (e.g. through the Statistics section) and adjust the topology accordingly (for example, add more nodes for all of the requests to be processed properly).
In such a way, from now on, the new values will be instantly applied to all of your containers just after being modified (both manually by your provider or being caused by some automatic processes). In particular, this improves your experience when upgrading an account to paid version, as the enlarged limitations are to be applied to environments you’ve created during trial period without the necessity to re-create them.
Improvements
Dockers Integration Enhancements (4.7 / 4.7.1)
UI/UX Updates
API Alias for VCS Projects Denomination
Import File Types
External Traffic Triggers
Git Module Update
New Defaults for Apache PHP (4.7.2)
Software Stack Versions
[Back to the top](#back)
Dockers Integration Enhancements
Default Entry Point
Revised & Concretized Error Messages
Volumes Path Validation
Automatic Addition of Volumes during Mounting (4.7.1)
Default Entry Point
Docker containers are usually provisioned with the predefined run options, used to determine their behaviour on the start. However, sometimes the Entry Point for the executing application is not mentioned within the image manifest.
So, starting with the 4.7 PaaS version, if the corresponding value is nil or null (i.e. not defined) the Platform will automatically substitute it with the default /bin/sh -c entry point. Within the appropriate Run Config section of the Docker containers settings frame, such one will be shown dimmed to mark that it’s just a placeholder, which can be easily changed to any required custom value.
Revised & Concretized Error Messages
Once some issue occurs during the Docker container creation, it can be hard to find out which problem it was caused by. Due to this, within the current release, we’ve reviewed and analyzed all of the appropriate error messages (i.e. which appear at the dashboard in such situations) for them to be more explicit and to correctly point to the root of the happened issue.
Such improvement ensures you won’t be mislead by the common problem description and will learn what has actually occurred instead - i.e. whether this concerns network connection failure or usage of unsupported OS version, some temporary technical issue or authentication failure, etc. In such a way, the issue could be easily resolved.
Volumes Path Validation
Previously, the semicolon “;” character was used by internal platform system processes (such as addvolume, update and setup) while working with Docker volumes as a sign to separate different volumes' paths. Thus, if being specified during the new volume addition within the corresponding Docker container settings dashboard UI frame, it had to be validated as an unallowed symbol.
Starting with the present Platform release, the appropriate system services were properly rewritten in order to get rid of such a semicolons-bounded processing. So for now the corresponding character is allowed to be used while designating Docker volumes' mounting within Local Filesystem.
Automatic Addition of Volumes during Mounting (4.7.1)
In order to automatically spread the existing Mount Points (i.e. created via Config Manager) across all the newly added nodes during horizontal scaling of Docker containers, previously it was needed to declare the appropriate volume at the initial (master) node of the layer manually (so subsequently its settings could be automatically copied by the system). Thus, in confines of the 4.7.1 Platform upgrade, the corresponding enhancement was implemented - for now, each mount operation (performed for Docker-based environment with the Mount to all nodes flag being enabled) includes an additional step of the relevant volume creation.
In such a way, while increasing the Docker containers count, mount points will be automatically cloned for new nodes of the appropriate layer, so that you do not need to perform this manually after each scaling operation.
UI/UX Updates
Renewed Configuration Manager
Updated Environment Sharing Workflow
New Account Limits
Triggers Names in Task Panel
Logs UI Amendments
MiB - New Memory Consumption Unit
Hierarchy for Resource Usage Displayment
Renewed Configuration Manager
Within the current 4.7 PaaS release, the major update was implemented to the in-build platform Configuration Manager. For now, within the left (menu) part, you can notice 3 new main sections appeared: Root, Mount Points and Exports. The last two ones are devoted to the data storage container feature, while the first directory gives an access to the container’s file system, i.e. its ROOT folder.
Below these elements, you can find a special Favorites section, intended for storing shortcuts to the items you are mostly interested in (so you can easily access folders and files that are oftenly used). Depending on the container-driven technology, the following content is shown here by default:
- for native platform containers - list of the folders you have used to work with (i.e. that were normally shown within Config manager before the current PaaS upgrade)
- for Docker containers - all of locally mounted volumes (both predefined within the appropriate image manifest and customly added ones)
Nevertheless, if needed, this list can be easily adjusted on your own (i.e. through removing the existing items and/or addition of the new ones). Herewith, excluding an item from this list does not implies its physical deletion - you still can access any of them through the corresponding Root section.
When switching to it, you’ll see the file system tree in the right-hand part of the manager, with the path string and the Actions for the current directory expandable list above. These options provide the following functionality:
- easily switch between the nested within path directories by simply clicking on any of them. Also, here you can specify the destination folder manually by typing its full location - the appropriate input field appears upon clicking on the empty space wherever at the path bar
- the action list contains a number of functions for the selected directory management, e.g. content refresh, new item creation, addition to the favorites, mounting or deletion
The file tree itself for now provides the additional information on the file size, its last modification date and type (be aware that only the regular file type can be edited - for that, just double-click on it or use the corresponding Open action). Each opened element is shown within a separate sub-tab so you can switch between them without closing the previous one, which makes it much more convenient to explore the file system. Herewith, the new Search option became available for the file’s view/edit mode, which allows to easily find the needed information, whilst the additional Match case and Regex search options will help you even more.
Updated Environment Sharing Workflow
Environment sharing functionality represents a part of the account collaboration feature, that allows to organize access to a single environment from different accounts. In the current release, it was amended to ensure more simple accounts management. So for now, when an owner shares an environment (available to be performed through the environment Settings > Account Management section), the following operations will be performed depending on the current accounts' collaboration state:
- owner and user aren’t in collaboration - the specified user receives the “Invite to link account” email with the confirmation link. Upon clicking on it, the platform dashboard is opened (whilst the appropriate account will be automatically registered if it doesn’t exist yet) with the owner’s environment being already displayed. Herewith, a user won’t receive the additional “Access to environment(s) has been granted” email, while owner still gets the “Invitation has been confirmed” one
- owner and user are in collaboration - the entered email address will appear in the list at the owner’s dashboard after the page with it is refreshed, whilst the appropriate user will receive the “Access to environment(s) has been granted” email. By clicking on the link within it, the dashboard will be automatically opened, with the owner’s environment being already displayed
New Account Limits
In order to keep you informed on the existing account limitations, all of them are gathered within the corresponding Account Limits tab of the Quotas & Pricing information frame. Within the PaaS 4.7 release, it was complemented with a few new records due to the number of new features being implemented. Namely, the added parameters are: Maximum disk space per node, Maximum disk space per storage node and External network bandwidth.
As usual, all of these values are regulated by your hosting provider and can vary depending on your account type. Beside that, the new Contact Us button has appeared below the list in order to make it easier for you to negotiate the current limits incrementation in case of necessity.
Triggers Names in Task Panel
As a part of the platform dashboard interface, Tasks panel is used to quickly analyze the recent actions made on account, which, obviously, should be completely clear for your understanding. Thus, in the current Platform upgrade, the related to the triggers' usage records within this section were complemented with the appropriate triggers names.
Such an update becomes especially useful if considering the number of default load alerts triggers, that are automatically set for each new environment starting from the 4.6 PaaS version. So for now, in case of necessity to manage them, you will know exactly which one to work with. Beside that, triggers within the automatic horizontal scaling section got their own hs-add-{env_name} and hs-remove-{env_name} names, so their addition or some settings' changing will be reflected in Task Panel accordingly.
Logs UI Amendments
With an aim to improve server logs perception, a number of updates was applied to the corresponding dashboard section. The most significant change here is implementation of two log’s viewing modes: Tail and Pages, which can be switched with the corresponding buttons at the top pane.
The Tail mode is used by default and is based on the auto-refresh feature, which ensures delivering of the most recent information on your environment every few seconds. This allows to track different real-time processes (e.g. installation or update) right during their execution.
Upon switching to the Pages mode, you’ll get access to the whole logged info that is being splitted into pages, whilst the navigation pane at the bottom allows to switch between them (one-by-one or through typing the appropriate page number). In this case, if you need to get the latest data, the file should be refreshed manually using the corresponding button right next to the navigation keys.
Among other improvements are:
- when switching between the same-typed nodes (i.e. for the horizontally scaled server), the currently shown log file will be opened for the destination node as well
- container restart won’t cause the logs tab closing - the connection will be re-established once the server is up again
- also, we’ve improved the compatibility of logs displayment in different browsers, standardized clarification message for an empty log and fixed a bunch of other minor bugs
MiB - New Memory Consumption Unit
From now, the platform will utilize two types of units for the memory consumption measurement: MiB (mebibyte) and MB (megabyte). The difference between them is all about math:
- 1 MiB = 1024 KiB (and similarly, 1 KiB = 1024 Bytes)
- 1 MB = 1000 KB (1 KB = 1000 Bytes)
So in order to avoid any miscalculations, be aware that starting with the current release, the MiB unit will be used for RAM calculation, whilst MBs - for traffic and disk space measurement. Due to this novelty, the appropriate computation logic and naming were applied everywhere at the dashboard. Obviously, the appropriate recalculations were also implemented for all of the corresponding quotas' values and network tariffs.
Herewith, consider that the new memory calculation flow is to be applied to environments only after the 4.7 Platform upgrade, i.e. this change won’t affect the previously gathered billing data.
Hierarchy for Resource Usage Displayment
Striving to improve perception of resource allocation to environments, a small visual update was applied to the Usage column at our dashboard. From now on, the smallest environment components (i.e. containers) have the tiniest hard disk and cloudlets icons before these parameters values, whilst the next for the size block - layer - has them a bit bigger (to represent that it can consist of several nodes and thus the appropriate resources values are combined). And environments, as a top of hierarchy, have the biggest resource icons, which values represent the overall resource usage. In such a way, this helps to percept the displayed topology and separate elements' resource consumption a bit easier.
API Alias for VCS Projects Denomination
Usage of different version control systems (VCS) for project development and management is a widely spread solution, thus interaction with such services should be as simple and clear as possible. However, since the platform uses the context label for the deployed applications, this may rarely cause a little confusion, as at VCS it’s commonly has the project denomination.
Due to this, in the present 4.7 release, the related to interaction with version control systems platform API methods got a slight improvement, aimed to avoid these terms' misleading. For now, the project parameter within the VCS API calls can be substituted with the context one as equal. Such new label can be applied for the following methods: CreateProject, DeleteProject, EditProject, GetProject and Update.
Import File Types
As one of the ways to create a new environment, the platform supports usage of the specially composed JSON files, that contain description of the required topology and/or application to be hosted, representing a kind of deployable “environment image”. Such images can be utilized through various platform features, like import (used, in the most cases, to restore the previously exported environment), one-click installation widgets (to deploy a new solution) or add-ons (aimed to patch the already set up environment with some additional software).
Currently, in order to complement and extend the ability to use such environment templates (which, in particular, are highly convenient in confines of various automation processes' and DevOps scenarios' implementation), the import flow has been updated to support the .jps file type. Similarly to .json, it will be uploaded and, consequently, automatically executed on the Cloud to build the environment, described within it.
Also, to completely fulfil this feature, one more additional extension is now supported by the platform - .cs, which stands for source code. Being written in C#, it is associated with the .NET language and allows the corresponding type of environments to be automatically created and managed (obviously, if such are available at the current platform).
External Traffic Triggers
With an aim to make environments' network usage monitoring more efficient (and considering the recently extended triggers' functionality), this time we’ve added a new Network (out ext.) trigger for load alerts. This was dictated by the necessity to track the external traffic loading, which usage rate could not be correctly measured within the common Network (out ext + in ext.), as incoming traffic is not limited (and not charged) by the platform. In addition, for the Network (out ext.) trigger, it became possible to measure loading not only in Mbps, but also in percentage considering the network bandwidth limit, specified for the current account.
Based on that, a new automatic load alert has been added to their default set, so each newly created container will contain an additional network trigger with the following conditions stated:
network (out ext.) is > 90% for 10 minutes (with 12 hours frequency)
This allows to inform you upon the traffic usage is coming close to external network consumption limit, so you can react on the issue in time. Moreover, such a trigger type is now also used within the automatic horizontal scaling functionality, allowing to automatically increase the limit (through spreading load between the existing and newly added nodes) without any manual interferences.
Git Module Update
Within the current release, those platform servers that are able to interact with remote Git repositories (i.e. all of the non Java-based application servers and Maven build node) were patched to use RPM builds with the latest version of Git software, namely: git-1.8.3.1-6.el7_2.1 and perl-Git-1.8.3.1-6.el7_2.1.
Such an update was forced by the recently discovered CVE-2016‑2315 vulnerability, which has been successfully fixed in the confines of the abovementioned releases. And as for all of the containers, which will be created after the 4.7 Platform upgrade, obviously they will use these new packages automatically.
New Defaults for Apache PHP (4.7.2)
In confines of the 4.7.2 Platform upgrade, a new flow of the optimal parameters' calculation for Apache PHP application server was implemented. It implies considering of CPU capacity of used hardware and amount of the available for a container resources. Such an approach brings maximum efficiency during this server usage. Here, the following formula is used:
MaxClients = ServerLimit = min({server_RAM}* / 30MiB, **{cores_count}** * 5)*
Due to this statement, both MaxClients and ServerLimit values are stated equal according to the lower value among one of them, i.e.:
- allocated to the node amount of RAM, divided by 30;
- cores number of hoster’s physical server the container is placed at, multiplied in 5 times.
In such a way, the abovementioned parameters will dynamically change based on the amount of allocated cloudlets, but won’t grow over the used hardware limits.
Beside that, the MaxRequestsPerChild parameter for now is equal to 500 instead of the previously used 5000 value. In case you’d like to change this value to your custom one, this can be done through the corresponding httpd.conf file (do not forget to Disable Automatic Configs Optimization beforehand).
Software Stack Versions
The component templates versions have been updated to their latest versions since the previous release:
| Stack | PaaS 4.7-4.7.2 |
|---|---|
| Tomcat 6 | 6.0.44 |
| Tomcat 7 | 7.0.67 |
| TomEE | 1.7.4 |
| Jetty 6 | 6.1.26 |
| GlassFish 3 | 3.1.2.2 |
| Java 6 | 1.6.0_45 |
| Java 7 | 1.7.0_79 |
| Java 8 | 1.8.0_92 |
| MariaDB | 5.5.47 / 10.1.10 |
| MongoDB 2.6 | 2.6.11 |
| MongoDB 3.0 | 3.2 |
| MySQL | 5.6.29 / 5.7.12 |
| PostgreSQL 9 | 9.5.2 |
| CouchDB | 1.6.1 |
| nginx | 1.8.1 |
| Maven | 3.3.9 |
| Centos 7 | 7.2 |
| Memcached | 1.4.24 |
| Apache | 2.4.6 |
| NGINX PHP | 1.8.1 |
| NGINX Ruby | 1.8.1 |
| PHP 5.3 | 5.3.29 |
| PHP 5.4 | 5.4.45 |
| PHP 5.5 | 5.5.36 |
| PHP 5.6 | 5.6.22 |
| PHP 7 | 7.0.7 |
| Ruby 1.9.3 | 1.9.3-p551 |
| Ruby 2.0.0 | 2.0.0-p643 |
| Ruby 2.1 | 2.1.8 |
| Ruby 2.2 | 2.2.4 |
| Ruby 2.3 | 2.3.0 |
| Python 2.7 | 2.7.11 |
| Python 3.3 | 3.3.6 |
| Python 3.4 | 3.4.4 |
| Python 3.5 | 3.5.1 |
| Node.js | 0.10.42 / 0.12.10 |
| Node.js 4 | 4.3.0 |
| Node.js 5 | 5.6.0 |
Back to the list of Improvements
Bug Fixes
In the tables below, you can see the list of bug fixes in PaaS 4.7, 4.7.1 and 4.7.2:
| PaaS 4.7 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PaaS 4.7.1 | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
| PaaS 4.7.2 | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| |||||||||
