Jelastic 4.9/4.9.2

Since Docker containers allow to handle almost any service inside, commonly it’s rather hard to automatically predict which node type a particular instance belongs to (i.e. whether it’s application server, DB, cache or storage server, etc). In such a way, it’s a user who defines a particular environment topology and decides which environment layer a container should be placed to.

Thus, in order to integrate the Jelastic automatic horizontal scaling functionality support for Docker-based instances (previously available only for nodes in application server environment layer), the whole Auto Horizontal Scaling section was rebuilt. Now it allows to manually choose a particular node group, where automatic scaling should be applied. This can be done within the appropriate drop-down list in the top-left tools panel corner. Obviously, this list can be used only for Docker-based environments, as such selection has no point for Jelastic native containers, where compute node is always placed within the application server layer.

Beside that, some other amendments were implemented - now, upon switching to the Auto Horizontal Scaling section, you will see a table with all scaling triggers that have been applied to the environment. It provides information on the appropriate Nodes and layers names, with Scaling in (to remove nodes) and Scaling out (to add nodes) conditions you’ve specified. And the Add, Edit, Remove and Refresh buttons above this list allow to easily manage it.

Back to the list of Improvements

When scaling server out within Jelastic environment, you automatically gain the advanced availability for your application or service, handled inside it. This is ensured with the sequential restart & deploy mechanism. It’s key point is to run the called process at nodes sequentially (i.e. one-by-one), so that when one container is undergoing the maintenance, the rest ones will remain accessible and operable. Such approach allows to perform various operations like container restart, application deployment (via both plain archive and VCS repo), Docker container update and changing cloudlets amount without the whole service downtime.

However, in some cases, your server instances may require some additional time to restore the full operability (for example, in order to sync sessions after restart). Thus, within the 4.9 Jelastic version, this mechanism was supplemented with a special delay option, that allows to set a particular time frame between running consecutive operations at containers of a single layer.  In such a way, the appropriate procedure on each next node will be initiated only when the stated delay has passed after the same operation completion at the previous instance. The default value of such delay is 30 seconds, but, if needed, it can be enlarged up to 5 minutes.

Back to the list of Improvements

In confines of Jelastic 4.9 release, the horizontal scaling feature availability was implemented for the Dedicated Storage Container node type. So from now, you are able to handle various development scenarios that require several separate storage nodes. This allows to run some specific applications and/or achieve data redundancy.

Storage containers number can be changed through the environment wizard central pane, just as for the rest of Jelastic nodes. Herewith, each Storage container, added during this operation, is created from scratch (so it won’t include any copied data from the already existing nodes). This ensures that you won’t pay for the unrequired disk space consumption and allows to compose the exact data structure you need.

In case of opposite operation (i.e when decreasing the nodes number), the last created container will be removed from the layer. So before performing this, please ensure it does not contain any substantial data.

More info

Back to the list of Improvements

Review & Update of Method Descriptions 

Particularly, methods with “docker” string in denomination were renamed to use the “container” label instead. Also, all method overviews were rechecked and updated to fix minor inaccuracies and provide clear and comprehensive descriptions. Similarly, the detailed explanations were added for all of the comprised data objects.

More info

Back to the list of API Improvements

“Get” Methods for Docker Volumes

• GetContainerVolumesById - returns the list of all Docker volumes for the specified container

• GetContainerVolumesByGroup - outputs the same data for master (i.e. initially created) node of a particular environment layer

Integration of such methods allows to easily get specific volumes information, without the necessity to examine the overall environment response (i.e. data received with the GetEnvInfo call).

More info

Back to the list of API Improvements

GetStats Output Clarification

To make response on this methods’ call easier for perception, a new cloudletsUsed parameter was added to their output. Herewith, it represent equivalent to the already used chanksUsed one (which will be still included to response for compatibility reasons), but can be easier identified by name.

Back to the list of API Improvements

Back to the list of Improvements