Virtuozzo Application Platform 5.4

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.4 release.

Container Firewall Management via User Interface

One of the major features of PaaS 5.4 release is a newly implemented possibility to manage firewall rules through a comfortable graphical interface on the container level (excluding custom Docker- and Windows-based nodes) - the dedicated same-named section was added to the environment Settings menu.

Here, the following three tabs are available:

• Overview - provides general information on the feature, allows to change Firewall State (which is enabled for all containers by default) and shows Isolated Env Group(s) the current environment is included to
• Inbound Rules - allows to manage incoming requests (not listed ones will be denied by default)
• Outbound Rules - allows to control outgoing connections (not listed ones will be allowed by default)

A number of default rules is automatically added to the inbound section by the Platform to make your node operable. Rules within the list are grouped by layers and are marked with the following color labels:

• gray for the default non-editable records (i.e. the obligatory ones)
• white for other default (stack-related) and user-added (either by an environment owner or his collaborators) rules

The very first record is has the highest priority (1) and allows platform infrastructure to access a container. Also, subsequent execution of some container management operations (e.g. creating mount points, installing FTP add-on, etc.) can result in automatic complementation of the default rules list. Herewith, each rule is added with a 10 points priority step, so that you would be able to insert new ones in between the default records without the necessity to edit the already applied connection permissions.

At the dedicated section, the tools panel above the list contains a set of buttons for a convenient firewall rules management, namely: Add, Edit, Remove, Disable (Enable) and Refresh. When adding a new rule, the following parameters should be defined:

• Nodes - allows to select the required environment layer
• Name - to provide name for this record (can be expanded to select from a number of the commonly used rules)
• Protocol - to set the required protocol type (TCP, UDP or TCP/UDP)
• Port Range - to define a particular port (e.g. 80) or their range (e.g. 1024-2048) to be opened/closed for connection; leave this field blank to apply the rule to all ports
• Source - to select the request source:
  • Custom IP Address(es) - a comma-separated list of IPv4/IPv6 addresses and CIDR blocks (e.g. 10.0.0.1,10.0.0.0/24)
  • redefined ranges - All, All IPv4, All IPv6, Local Network, Internet (Public Access)
  • Environment Nodes - node type (layer) from any environment on an account (after appliance this rule will be automatically adjusted upon the appropriate layer scaling)
• Priority - to set a rule priority (where rules with lower value will be applied first)
• Action - to define the required action upon receiving the matching request (either allow or deny)

Subsequently, if meeting the necessity to edit any of predefined rules, you’ll be able to adjust all of the above-described parameters except of the Nodes field (i.e. target layer can not be switched). Also, with testing purposes, you can temporarily exclude some firewall records and reapply them later on with the appropriate Disable/Enable buttons. After some adjustment (for example, topology change), you may need to update the list of rules with the Refresh button.

Back to the top

Private Network Isolation

In confines of PaaS 5.4 release, an automatic account isolation was implemented at a Platform. This explicitly prohibits any unallowed connections between environments of different users via internal platform network (i.e. even in a case some malefactor has managed to gains access to such data as domain name, node ID, internal IP, etc.).

This results in another essential newly added possibility to create a so-called “secure” environment groups, intended to isolate environments of a single account from each other. Just turn on a new Network Isolation switcher within the Add or Edit Group frame.

Platform automatically creates a dedicated IP set for each isolated group, which is composed of the appropriate containers internal addresses. This allows to control access between nodes (i.e. if IPs are within the same set - interconnection is allowed, if not - denied). Also, Platform detects all the appropriate account changes to automatically keep sets up-to-date (e.g. due to environment removal, nodes scaling, etc.).

Also, while managing Network Isolation, the following peculiarities should be considered:

• the feature can be enabled for the top-level group only (i.e. not for subgroups)
• environment groups with enabled isolation are provided with a custom icon for better recognition
• shared environments can not be included into isolated groups by collaborators
• access from outside of the Platform (e.g. via Public IP) could not be limited by this feature

Extra Environment Layers for All Supported Engines

In order to support even greater variety of solutions (through a more flexible topology constructor), a number of special adjustments were applied to the environment wizard:

• all layers include an additional Docker image option now, whilst sections within the Docker tab were complemented with platform-managed templates instead; this allows to combine both certified and custom Docker containers in confines of a single environment
• within the App. Server layer the possibility to select servers for any programming language was added (you’ll be automatically switched to the appropriate tab)
• the Extra layer option was integrated to all tabs, allowing to deploy any platform-managed stack template or Docker container image within the required environment layer; herewith, any required number of additional layers can be created
• added possibility to specify custom layer names via topology wizard

Such changes ensure environments versatility, allowing to create the one, which will suit you the most.

Back to the top

Go Support Integration

The most notable stack provisioning update in confines of PaaS 5.4 release is addition of a new programming language to the list of supported ones - Go. This free and open-source language (originally developed by Google) allows you to leverage with multiple built-in features:

• a concurrency mechanisms to get the most of the multicore systems
• modular program construction to achieve advanced flexibility
• fast compilation into machine codes
• a convenient garbage collection for efficient memory utilization

Go is easy to write on due to utilizing a set of simple tools and commands for operating with code. Below, you can find a list of the most common commands (refer to the official documentation for the complete list):

• go build - compiles packages and builds Go binaries
• go test - tests packages
• go fmt - formats package source code
• go get - downloads and installs packages
• go vet - reports potential errors in code
• go run - builds and executes code
• go doc - displays documentation
• go generate- generates Go files by processing code

The integration of a Golang application server was implemented through addition of the appropriate platform-developed dockerized stack templates, providing the 1.9.1, 1.9.2, 1.9.4 and 1.10 versions of the stack. A new app server supports all of the functionality required to work with Go and provides access to the platform native benefits (e.g. vertical and horizontal scaling, files and logs management, statistics monitoring and load alerts, etc.). Herewith, due to the Go engine specifics, it supports only VCS deployment type (i.e. deployment from archive is not available), whilst the appropriate server could operate with just a single project (context) at once.

Back to the top

UI/UX Improvements

• API Documentation Redesign
• Environment Error Pages Restyle
• Parallel Containers (Re-)Deploy and Restart
• Environment Layer and Master Node Designation
• Simultaneous Removal of Multiple Deployment Archives
• Improved Environment Management Panel Accessibility
• Scrollable Filters Section for Billing History
• Action Logs for Container (Re-)Deploy and Restart Operations
• Container Consumption Statistics for the Last Month
• Official NGINX Logo Integration

  Back to the top

API Documentation Redesign

Within the current platform upgrade, a major redesign of platform API documentation has been implemented. The new style corresponds to the current site and documentation color scheme and ensures better appeal in general. So, currently, API documentation includes three default tabs, which can not be closed:

• Home - general overview of platform API and the common points/recommendations on its usage
• API Documentation - the main section, where the categorized methods list is displayed, allowing to browse through all of the API requests
• Examples - list of useful samples to demonstrate some basic procedures and automation flows, which could be implemented by means of platform API

Additionally, a few functionality optimization were applied to provide better user experience. For example, newly added drop-down list at the top left corner of the page, allows to select platform version (i.e. to display only the appropriate API requests). Next to it, you can find a Search field, which helps to find any API method. Also, for each section, the quick Filter class members field was added (top-right corner) to easily search through this particular group of requests.

More info

Environment Error Pages Restyle

If URL in the address bar points to environment, which can not be reached (e.g. for the reason it does not exist at a platform, or is stopped, or is down due to some maintenance activities, etc.) a dedicated error page will be displayed. Herewith, the platform automatically detects the issue occurred and provides the appropriate description with some of the most common steps (recommendations) to avoid or fix it. In the present PaaS 5.4 release, the corresponding set of error pages were updated, including their redesign to match the latest platform corporate style. Also, the link for contacting the platform support team was moved to the bottom of the page.

Parallel Containers (Re-)Deploy and Restart

In the PaaS 5.4 release, there was added a possibility to choose between two ways of horizontally scaled nodes managing was implemented:

• simultaneously (i.e. all containers at once), which apply changes in a single run, but cause a brief service downtime
• sequentially (i.e. one by one), where nodes are adjusted consecutively with predefined delay between operation on each two containers - to avoid service downtime

Herewith, the first one can be a preferable option during testing/development, while the second one is mandatory for applications in production to ensure constant service operability. The required deployment type can be chosen by means of the appropriate options, which were added to the restart, deploy and update dialog boxes (for horizontally scaled layers only).

Environment Layer and Master Node Designation

Due to the extra environment layer feature, you are able to completely change the default topology structure (e.g. to place same stack within several environment layers). Upon working with such custom topologies, in order to avoid confusion, the new more explicit designation was provided to show node group (layer) and the comprized stack(s) name simultaneously.

Such a change was implemented within all of the corresponding dashboard sections and dialog frames (e.g. load alerts, endpoints, firewall, Docker container linking, etc.). Herewith, upon hovering over a particular item within any of the node group lists, an additional information will be displayed in a pop up.

Also, the very first container within each layer of an environment is automatically considered by the platform as master. This node is required for some specific operations and can additionally be used in the following cases:

• is used as origin for any subsequent container on the load balancers, application servers and VPS layers, i.e. new nodes will be a copy of this initial one
• is required for the cloning operation
• can be configured as a storage server for sharing data within the whole layer
• is recommended to store the main configurations for a cluster, to ensure your data won’t be lost during scale in (as master is the last node to be removed)

In case of a simultaneous creation of the multiple containers, master is not always the first node displayed in the platform dashboard, so, starting with the 5.4 release, the appropriate designation was provided. For now, if layer has more than one node, the special icon will be displayed before the master one, allowing to quickly identify it.

Simultaneous Removal of Multiple Deployment Archives

When working with multiple projects and/or their copies, your Deployment Manager could be occasionally over-filled with numerous Archives, uploaded to it. Such a mess makes it difficult to find the required package, decreasing the service usability in general. So, in order to make the task of unnecessary projects removal quicker and more comfortable, the possibility to delete multiple packages at once was implemented. Just select all of the unnecessary items with the appropriate check boxes and click the Delete button from the tools menu.

Improved Environment Management Panel Accessibility

For quicker access and more convenient usage of the Environment Management panel within the platform dashboard, the possibility to easily expand it to a full-screen size was implemented. Just double-click anywhere on the tabs pane at the top of a frame to fill the whole dashboard space with the current section (i.e. Deployment Manager, Tasks or a particular environment Settings). This allows to percept and manage the required configurations more comfortable. And in order to quickly return to the previous size of the Environment Management panel, just double-click at the top of the frame once more.

Scrollable Filters Section for Billing History

The platform Billing History frame provides an important information about account balance charges. Here, you can review all spends (either per environment or for the whole account) and see all of the appropriate resources (i.e which were charged for). Using the filters section to the left of the tab, you can adjust the Start and End date, select the required Interval, enable or disable the Group by node feature and Refresh results.

And starting with the current Platform release, there was implemented the possibility to operate with the filtering section in case of a cramped space (i.e. low Billing History frame height). For now, the appropriate scrolling bar will automatically appear in case elements can not be fitted within the filtering section.

More info

Action Logs for Container (Re-)Deploy and Restart Operations

By default, the platform automatically provides details on container(s) restart, deploy and redeploy operations by opening a dedicated tab in the Environment Management panel, where the information on the appropriate action is displayed. Currently, such flow was optimized, providing just a dashboard notification with the Show Logs button. This allows to open action log only in case it’s actually necessary. Herewith, for Docker containers the button will expand a drop-down menu with possibility to review both Action Log and Run Log files.

Container Consumption Statistics for the Last Month

In order to allow better analysis of a resource usage on nodes, the Statistics section was adjusted to display data for the whole past month (rather than just a week). If needed, such enlarged period can be selected from the appropriate Duration drop-down list within the Statistics tab. Herewith, it can be used only with the 1 hour and 1 day intervals, which provide the appropriate level of data granulation.

Official NGINX Logo Integration

In the present 5.4 Platform release, the NGINX server logo in the platform dashboard was replaced with its most recent official version. Herewith, changes (with the appropriate recolor to match layers color scheme) were provided for the NGINX PHP/Ruby application servers and load balancer. Such an implementation ensures a more accurate reference to the stack.

Deployment Improvements

• Application Deployment from Container Local File
• Maven Build Node Amendments

  Back to the top

Application Deployment from Container Local File

Within the current Platform upgrade, a possibility to deploy application to container from archive located on the same node was implemented. This can be performed through the URL section of the deployment frame by providing address using the file:// protocol with path to local file (e.g. file:///path/to/archive.war). Herewith, such functionality works with external NFS storages through mount points. For example, you can mount directory with Java projects, which were built by Maven, to your application server, ensuring faster deployment (due to skipping file upload step).

Maven Build Node Amendments

In the present 5.4 Platform release, functionality of the Maven build node was extended with a number of new possibilities, aimed to enhance users experience during the appropriate Java projects deployment:

• Added possibility to add, edit, remove and build project without specifying the target environment, i.e. allowing just to add a new project to the Deployment Manager and/or pre-build it within Maven without its actual deployment. As one of the main advantages, this eliminates the necessity to predefine repository data and re-build a project with exact target environment parameters upon deploying it to multiple environments.

• The Maven build node stack template was provided with a dedicated /opt/maven/conf/variables.conf file, which, in conjunction with the pre-installed java-memory-agent add-on, allows to define values for the most essential Java server options (e.g. -Xmx, -Xms, -Xmn, etc.). Also, the MAVEN_RUN_ARGS and MAVEN_RUN_ARGS_{project} variables were added to the node’s default build, allowing to specify additional Maven command-line parameters for either all or a particular project respectively (where, the {project} name should be stated with underscores “_” instead of spaces and dashes).

• Also, there was added a possibility to deploy Java projects, located in the VCS repository subdirectory, allowing to store various app versions within a single repo and organize them properly. This was implemented through the addition of a new Working Directory field within the Git / SVN deployment form (available for Java instances only). Here, if needed, you can set a repository subfolder with the required application sources.

• The Maven build process was adjusted to be run under the jelastic user to support the webhooks implementation. For now, as both operations are executed by the same user, all of the created files are accessible without any additional changes required. For example, with the appropriate post hook, this allows to run your project immediately after it was built.

Webhooks for Application Build and Deploy Operations

Webhook is a term used to indicate a code insertion to customize original flow of operations based on a certain condition. In the current Platform upgrade, such webhooks were added to provide a possibility to run custom script on nodes before and/or after application deployment. Additionally, for the Maven build node and the Golang application server the pre- and post-build hooks were implemented as well. Such functionality was added to all of the deployment forms (archive, URL, Git/SVN) at dashboard and is located within a new Hooks section of the appropriate frames.

Selecting the Pre or Post hook from the deployment form will open a code editor window, where you can provide your custom script. Herewith, any preferable programming language can be used, you just need to specify the appropriate program for code interpretation (should be pre-installed on container). For example:

Also, you can break your hook (and the appropriate deployment / build operation) execution at any point by providing an exit code, for example exit 1. Herewith, the 0 value is used to indicate success, while any other value assumes an error (will be shown at dashboard). Additionally, in case of a webhook failure, the dashboard notification will point to the appropriate hook.log file, providing details required for troubleshooting. More info

Back to the top

Web SSH Connection via Guacamole

Within the present PaaS 5.4 upgrade, the platform integrated the latest 0.9.13-incubating version of the Guacamole Gateway into the Platform to provide SSH connection to a container of any type directly in browser. Just click a new Web SSH button next to the required node and a dedicated tab with terminal emulator will be opened. Herewith, you’ll be automatically connected to the appropriate container without necessity to provide SSH key or perform any other additional actions.

In the tools panel of the opened frame, you are able to switch between nodes of the horizontally-scaled layer. Starting with the 3rd build of the 5.4 release, the Duplicate Session button was added to open another tab with connection to the current container. This option allows to perform several simultaneous operations on a single node (e.g. tail log in one terminal window and manage your application in another).

More info

Back to the top

Composer Dependency Manager for PHP Servers

Composer is one of the most popular dependency managers for PHP, which provides all of the required packages and libraries for your applications. Being run on the per project basis, Composer allows each one to have a different set of dependencies installed directly into the appropriate working directory. Also, it can automatically load updates to keep your packages up-to-date.

Within the present 5.4 release, the Composer was integrated into both Apache and NGINX PHP application servers (located at the usr/local/bin folder). In order to be further operable from anywhere on the node, this tool was automatically added to the PATH variable and can be called with a composer shortcut (e.g. composer about). Additionally, in case the appropriate project has a composer.json file, such implementation allows to manage dependencies directly during the deploy operation with the appropriate post hook script. Namely, you need to move to your project directory and run the install command:

1
2

cd $WEBROOT/ {project_name}  
composer install

Herewith, Composer is automatically provided for all of the newly created PHP application servers, so you are able to operate dependencies even on the Platforms below 5.4 (e.g. through SSH). In order to work with Composer on the already existing nodes, follow the appropriate guide for manual installation.

Back to the top

HTTP 2.0 Support for Shared and Dedicated Load Balancers

The Shared Load Balancer processes all of the incoming requests to the platform (excluding direct connections to Public IP addresses) and routes them to the destination nodes. In the current PaaS release, to ensure a secure connections over SSL protocol, an OpenSSL tool on SLB was updated to its 1.0.2.k version. The new version additionally supports an ALPN (Application-Layer Protocol Negotiation) extension, which allows Shared Load Balancer to work over the HTTP 2.0 protocol, when SSL is enabled.

Herewith, to support direct access via Public IP, the NGINX and Varnish load balancers were similarly upgraded. In such a way, for the most cases a quicker request processing (compared to the commonly used HTTP 1.1) can be achieved without necessity to adjust your application, i.e. through improved compression of web pages, reduces latency, etc.

Back to the top

Logging of Requests Source Port

Starting with the present PaaS release, each platform’s entry point node - so-called Shared Load Balancer - was configured to automatically log the source port of each incoming requests. For example, such implementation allows to successfully track the users' activity over the mobile internet access, where source client can not be identified with the standard login.

Back to the top

Cloud Scripting Engine Optimization

In the current platform 5.4 upgrade, a number of optimizations were implemented for the Cloud Scripting engine to provide a better interaction with API methods:

• all parameters became case insensitive, so you can can define them in any preferable way
• optional parameters can be skipped entirely (instead of providing the null value)
• the appid (unique environment identifier) and session (unique session of a current user) parameters are specified automatically for all API requests

  Back to the top

Short Aliases for Namespaces in API List for Tokens

Tokens is an authentication method to provide extra consistency compared to the default session-based implementation. It is commonly used within automatization scripts or for access sharing with other users (allowing just the specified range of commands). In the current PaaS release, the possibility to define a list of methods for token (the apiList parameter) using the appropriate API namespace aliases were implemented. Namely, the following shortcuts were allowed:

• env - for the environment group of methods, e.g. env.control.CreateEnvironment
• dev - for the development namespace, e.g. dev.applications.GetAppHosts
• mgmt - for the management API, e.g. mgmt.account.AddSHHKey
• util - for the utils methods, e.g. util.scheduler.GetTasks