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 Jelastic PaaS 5.3 and 5.3.2 releases:
For detailed information on using any of Jelastic features, please refer to the users’ documentation.
- Support of Public IPv6 Addresses
- Multiple Public IP Addresses for a Single Container
- Personal Access Tokens for API Request Authentication
Support of Public IPv6 Addresses
The v6 is the most recent version of Internet Protocol (IP), which is responsible for device identification and defining their location within network, as well as for traffic routing across the Internet. The 6th IP revision is an evolutionary upgrade of IPv4, designed to fulfill the need of more addresses, simplify processing by routers, eliminate NAT (Network Address Translation) issues and private address collisions, etc.
Starting with the present 5.3 release, Jelastic Cloud provides out-of-box support of Public IPv6, which can be attached to any container (except for Window-based ones) directly from the topology wizard. Herewith, the availability of this internet protocol version at a particular Platform depends on hosting provider settings. To check this, refer to the Quotas & Pricing frame:
- Account Limits provides information on the Public IPv6 addresses availability for your account (note it can be limited during trial period)
- Pricing > Options section displays the cost of this feature usage at your Platform
The 6th internet protocol version can be used on a par with IPv4, providing all the same functionality. In case the address type to use is not specifically indicated (e.g. in JPS packages, add-ons or when creating a VPS node), the 4th address revision will be used by default.
In order to support IPv6 usage via API, the following changes were implemented:
- the AttachExtIp request was deprecated (still remaining valid for backward compatibility)
- a new SetExtIpCount method was added; operates with two supplementative parameters: type (ipv4 or ipv6) and count (number of IPs to add per container - required for the multiple IPs feature)
- the SwapExtIps method was limited to be used with IPv4 only
Multiple Public IP Addresses for a Single Node (Container)
In confines of the Jelastic 5.3 upgrade, a possibility to attach multiple Public IPs (both IPv4 and IPv6) to a container was implemented. For example, this allows to run several websites on a single node by using a number of dedicated SSL certificates, associated with the specific IPs.
Multiple IPs can be added in two ways due to the following UI updates:
- the Public IPv4 and IPv6 counters were added to topology wizard, so the required IP number can be set right during environment creation / topology adjustment
- each node within the dashboard environment list can be expanded to view and manage all of the attached IP addresses:
- the total number of Public IPs can be adjusted directly from this list using the Attach/Detach IP(s) button (separately for IPv4 and IPv6)
- each particular address can be copied to clipboard or detached from a node with the appropriate buttons
The first Public IP of each type to be added to container will be considered as primary one, i.e. will be used for all the outgoing traffic, while the rest of IPs can only receive it. Also, primary IP can only be removed if it is the last public address attached to node.
Other changes due to this feature integration are listed below:
- the SwapExtIps API method was adjusted to allow swap of particular IPv4 addresses (using the sourceIp / targetIp parameters pair), as well as all of them at once (sourceNodeId / targetNodeId)
- upon attaching new IP to the existing node, you receive the appropriate email notification with the list of all its addresses
- the list of assigned IP addresses is displayed in the WAN IP column of the SSH menu while connecting to the Platform via terminal
Personal Access Tokens for API Request Authentication
Every Jelastic API call requires a special session parameter to verify whether a user is allowed to execute the appropriate operation. In order to get it, the Users > Authentication > SignIn method should be called. However, the obtained session value has a short-term validity, being frequently generated anew due to security reasons.
In the current 5.3 Jelastic release, an alternative approach of authentication via tokens was implemented. It is aimed to maintain the security of the sessions-based approach (i.e. ensuring no one else can operate with your account), at the same time extending the API usability greatly. For example, tokens can be used within various scripts (e.g. during application lifecycle automatization) or be shared with co-workers to grant temporary access to some particular account/environments actions. There are a number of specifics to ensure the best user experience:
- permission management - can be assigned to some specific tasks (each particular token can be allowed to work with a particular API methods only)
- time to live - allows to set an expiration date for token
- multiple tokens - supports up to 100 different tokens per account
- renewal possibility - regenerates lost tokens with the same parameters as original ones
- prohibited self duplication - restricts token usage for the Authentication API methods (i.e. can not be used to create new or to manage existing tokens)
Below, you can find a list of the appropriate API methods, which were provided for tokens management (check the Users > Authentication section of the documentation for detailed information):
- CreateToken - creates token with the required permissions, expiration day and descriptionNote: The exact value (name) of your token will be shown just once and won’t be exposed anywhere afterward, so ensure you’ve saved it before closing method response.
- DeleteTokens - removes token(s) by ID
- EditToken - allows to adjust existing token
- GetTokenApiList - returns a list of all operations, which can be authenticated by token (upon granting the appropriate permissions during creation)
- GetTokens - displays information on a particular (or multiple) account token
- RegenerateToken - generates a new name for existing token, while maintaining all other parameters
- Deployment Manager Improvements
- Unlocked Environment Management During Reconfiguration
- UI/UX Improvements
- Environment Variables Management via API
- Removed Deployment Delay Option for Clusterized GlassFish
- Fixes Compatible with Prior Versions
- Software Stack Versions
Deployment Manager Improvements
The version control systems (VCS) are extremely popular among developers, as they allow to record and recall changes to your application, as well as manage several different versions of it at once. Thus, to simplify integration of VCS projects into Jelastic, a special enhancements were applied to the Platform deployment manager.
Starting with the current 5.3 release, it has two tabs - Archive and Git/SVN. The first one maintains functionality of packages deployment via uploading them from the local machine or providing a direct link to file, while the Git/SVN tab is a new implementation. Here, you are able to store VCS projects for a simpler future deploys (i.e. no need to specify your repository detail multiple times).
Use the Add Project button on the top of the Git/SVN tab of deployment manager to create a new VCS project. Within the opened Add Git / SVN Project frame, you can specify any custom Name, provide Git or SVN repository details and, if needed, Use authentication. When everything is configured, click the Add or Add + Deploy button. Either way, your project will be stored in manager, but, in the later case, you can immediately deploy it to any environment on your account.
Apart from that, some changes were applied to the environments list in dashboard. For now, all of the deployed projects are shown under the Deployments section (former Context / Projects), which is displayed as the first element within the application server layer. Hover over Deployments to get a quick access to the File, URL and Git/SVN deployment dialogs through the same-named buttons. Also, all of the deployment API methods were refactored and gathered under the new Environment > Deployment section:
- CreateProject - creates a project based on sources from a VCS repository (both login/password or ssh key authorization can be used)
- EditProject - edits the specified project
- DeleteProject - deletes project from the deployment manager
- DeployArchive - deploys an application package into the given context (ROOT by default)
- DeployProject - deploys application based on the specified project
- GetProjects - returns information about the projects
- RenameContext - renames application by moving it from the old context to a new one
- Undeploy - removes application from the given context
- Update - updates project from a VCS repository
Unlocked Environment Management During Reconfiguration
While applying changes to an environment, it becomes fully locked (i.e. prohibits any other actions) and automatically closes all the associated tabs and dialogs in dashboard. Starting with the current Jelastic release, such behaviour was changed, allowing to continue environment management during the ongoing time-consuming operation (e.g. topology adjustment, Docker container redeploy, application deploy, etc). Herewith, the list of allowed actions varies depending on the exact process in progress, but in the most cases you’ll be able to access file manager to adjust configs, as well as to monitor environment via logs and statistics.
Additionally, tabs and dialogs related to the adjusted environment will no longer be closed (with the exception of the Docker container redeploy action). Herewith, when frame operates with container, that is being removed, it will automatically switch to another node.
- Possibility to Download Log Files
- Welcome Tutorial Update
- Redesign of the Default HelloWorld Application Example
Possibility to Download Log Files
Logs analysis is an important part of web hosting monitoring, which helps to understand system behaviour as well as perform troubleshooting in case of necessity. Jelastic provides access to server log files directly from dashboard (with the Log button next to the required node) for a quick online analysis.
In the 5.3 Platform upgrade, the possibility to download the appropriate files from a Cloud to your local machine was implemented. This could be done using a new Download button, which was added to the top pane of the log tab. In such a way, you can explore logs with any preferable analysis tools or perform any application-specific operations with the obtained file.
Currently, the first part of the welcome tutorial (i.e. Platform overview presentation) was updated to show info on how to build your application topology. Additionally, some minor adjustments were applied to the other slides to provide even better clarity on the Jelastic Cloud pricing advantages.
Environment Variables Management via API
In the present Jelastic 5.3 release, two new API methods were added to help managing environment variables in Docker containers and dockerized stacks. Both operations were specially designed to work with either single node or a whole layer at once:
- AddContainerEnvVars - adds variables to the target container(s)
- RemoveContainerEnvVars - removes variables from the target container(s)
Herewith, variables are provided in the JSON format, which allows to add / remove several of them at a time. If both single container and layer are specified as target for these methods, the nodeId parameter will have a higher priority (i.e. only specified container will be updated). Also, in case the AddContainerEnvVars method is provided with a variable, which already exists, it will be overwritten using a new value.
Removed Deployment Delay Option for Clusterized GlassFish
Upon deploying a project (either from archive or Git/SVN) to environment with multiple application servers, the appropriate Sequential deployment delay field appears at the confirmation frame. It allows to set a time frame (30 seconds by default) between redeployment of current and subsequent containers in one node group (layer). In such a way, the handled application downtime can be avoided.
Starting with the current 5.3 release, the above-described field won’t be shown at the appropriate dialog box, when deploying to the GlassFish application server. Here, all the configurations are performed on a master node only, while slaves get these changes through replication.
Fixes Compatible with Prior Versions
Below, you can find lists of fixes which except of being implemented within Jelastic 5.3 release, have been also integrated to Platforms with preceding Jelastic versions by means of the appropriate patches:
Software Stack Versions
The most notable software stack updates in confines of Jelastic 5.3 and 5.3.2 releases is addition of the OpenJDK 7/8 engines, which are compatible with the Tomcat 6/7/8, Maven, TomEE dockerized templates. Below, you can check the list of the most accurate Jelastic software stack versions:
|MariaDB||5.5.57 / 10.2.7|
|MySQL||5.6.37 / 5.7.19|
|Node.js||0.10.46 / 0.12.15|
|Node.js 4||4.26 / 4.3.0 / 4.5.0|
|Node.js 5||5.1.1 / 5.6.0|
In the table below, you can see the list of bug fixes in Jelastic PaaS & CaaS 5.3 and 5.3.2:
|Jelastic 5.3.2 (build 6)|
|Jelastic 5.3.2 (build 6)|
|Jelastic 5.3.2 (build 10)|
|Jelastic 5.3.2 (build 11)|