BitssCloud 5.7.4 5.6
In this document, you will find all of the new features, enhancements and visible changes included to the BitssCloud PaaS 5.7.4 release
The New release will be applicable for dashboard after 6 Sept 2019.
Debian 10 OS Distribution Support
In the present 5.7.6 BitssCloud release, the list of Linux distributions that are supported as a base for Docker images was extended with the latest Debian 10 operating system. Now, the platform can create any custom Docker container based on this OS type.
Supported OS Distributions for Docker Containers
Currently, the following Linux distributions are supported as a base of Docker images that could be deployed at PaaS and properly handled by the system (this information is subject to change):
GlusterFS Storage with Auto-Clustering (5.7.4)
Starting with the current 5.7.4 platform release, the Shared Storage Container was upgraded to the second (2.0) version. It provides built-in Gluster support with the appropriate version (6.3) represented in the stack name – Shared Storage 2.0-6.3.
The GlusterFS RPM packages are provided by default to support clusterization of the Shared Storage nodes but are not enabled on the standalone storage container. The former one can be enabled with the Auto-Clustering switcher in the topology wizard. Consider the following specifics:
- auto-clustering requires Shared Storage 2.0 (i.e. created after the platform upgrade) and is not available for the preceding versions; however, you can use redeploy to update your old storage to 2.0 and then turn on Auto-Clustering via the wizard
- Shared Storage auto-clustering requires the latest Virtuozzo 7 virtualization used on the environment region (depends on your hosting provider)
- for existing environments, auto-clustering can be enabled only in case the storage node is not scaled yet; herewith, the data is replicated to all new containers
- storage auto-cluster requires 2 or more nodes and cannot be disabled after creation
During creation, the GlusterFS volume is mounted into the /data folder and is accessible over NFSv4 protocol. Consequently, when mounting from/to your storage cluster, it is managed as a single component (i.e. not a collection of separate storage containers). In case of failure of one or several nodes, the AutoFS client automatically switches to the working instances, which ensures HA for your storage.
Additionally, within the dashboard, a dedicated icon and label are provided for your storage auto-cluster.
Dashboard Search Amendment (5.7.4)
The dashboard search for environments is performed via name (domain) and alias, so starting with the BitssCloud 5.7.4 release, the search results in the appropriate Environments section are provided with both these values. Compared with the initial implementation of just an alias being displayed, the current one helps to avoid confusion in some cases (e.g. when several environments are provided with the same aliases).
Built-In SSL Description (5.7.4)
The built-in SSL option allows securing your environment with the enterprise-level data encryption as easily as switching a toggle. If enabled, BitssCloud PaaS automatically configures a wildcard SSL certificate on the Shared Load Balancers (SLB).
Herewith, to highlight the incompatibility of such implementation with direct access provided by public IP, the appropriate denotation was added to the description in the topology wizard. It will help to avoid misconfigurations when establishing a secure connection to the application.
Tip: If working over public IP, consider utilizing the Let’s Encrypt SSL (free-of-charge option) to automatically issue certificates for your environment. Alternatively, you can manually provide your custom SSL certificates.
Auto-Clustering Labels (5.7.4)
In the current 5.7.4 BitssCloud release, the “new” label for the auto-clustering option in the topology wizard was removed for all of the supported stacks by default. Herewith, for the newly implemented clusterization of the Shared Storage container, a “beta” label was added.
Deployment Archives Types (5.7.4)
Archive deployment is a quick and simple option to install your application in BitssCloud PaaS. The provided package (either as a local file or via URL) is automatically processed by the platform, making your application available for usage without any manual steps required. A support for the following archive types was added in the BitssCloud 5.7.4: gzip (.gz, .tgz, .taz), compress (.Z, .taZ), bzip2 (.bz2, .tz2, .tbz, .tbz2), lzip (.lz), lzma (.lzma, .tlz), lzop (.lzo), xz (.xz), zstd (.zst, .tzst).
Ruby Rake Deploy Adjustment (5.7.4)
Rake is a software task management and builds automation tool for Ruby used by BitssCloud PaaS. It automatically performs commands from the rake_deploy file (located in the root folder of the project) after the Apache/NGINX server restart. Starting with the current 5.7.4 platform release, the commands from rake_deploy will be run from under the BitssCloud user instead of the root one. Such an adjustment provides better compatibility with projects as it is the default user for all of the Ruby containers.
Custom Color for Extra Layer in Topology Wizard (5.7.5)
BitssCloud PaaS provides a convenient and intuitive color legend for the certified containers based on the node group parameter. It helps to determine the role of each stack visually:
- Load Balancers (“bl“) are green
- Application Servers (“cp” – compute nodes) are blue
- Databases and cache nodes (“cache“, “sqldb“, “nosqldb“) are orange
- VPS, build, and storage nodes (“vds“, “build“, “storage“) are gray
Herewith, all the custom images are added to the extra layers and are gray by default. Starting with the 5.7.5 platform upgrade, it is possible to manually redefine a color for such custom nodes by adding the mission parameter for layer in your JPS. Use the highlighted shortcuts from the list above as a value to set the required color.
Software Stack Versions
Check out the list of the most accurate BitssCloud software stacks for the current platform version:
|Couchbase CE||5.1.1; 6.0.0|
|Docker Engine CE||17.12; 18.09.7; 19.03.1|
|GlassFish||22.214.171.124; 4.1.2; 5.1.0|
|LiteSpeed Web ADC||2.5.1|
|LiteSpeed Web Server||5.4.1|
|MongoDB||2.6.12; 3.6.13; 4.0.10|
|MySQL CE||5.7.26; 8.0.16|
|NodeJS||6.17.1; 8.16.0; 9.11.2; 10.16.0; 11.15.0; 12.6.0|
|PostgreSQL||9.6.14; 10.9; 11.4|
|Tomcat||7.0.96; 8.5.43; 9.0.22|
|Ubuntu (VPS)||16.04; 18.04|
|Varnish||4.1.8; 5.2.1; 6.2.0|
|WildFly||10.1.0; 11.0.0; 12.0.0; 13.0.0; 14.0.1; 15.0.1; 16.0.0; 17.0.1|
|AdoptOpenJDK||8.0.222; 9.0.4; 10.0.2; 11.0.4; 12.0.2|
|Amazon Corretto||126.96.36.199; 188.8.131.52.1|
|Eclipse OpenJ9||0.9.0-184.108.40.206; 0.9.0-10.0.2; 0.11.0-8u192-b12; 0.11.0-11.0.1; 0.15.1-8u222-b10; 0.15.1-11.0.4; 0.15.1-12.0.2|
|Liberica JDK||8.0.222; 11.0.4; 12.0.2|
|Oracle JDK Dev||7.0_79; 8.0_202; 9.0.4; 10.0.2; 11.0.2|
|Oracle OpenJDK||7.0.231; 8.0.222; 10.0.2; 11.0.4; 12.0.2; 13.ea-b31|
|Zulu Community||7.0.232; 8.0.222; 11.0.4; 12.0.2|
|PHP 5||5.3.29; 5.4.45; 5.5.38; 5.6.40|
|PHP 7||7.0.33; 7.1.31; 7.2.21; 7.3.8|
|Ruby||2.3.8; 2.4.6; 2.5.5; 2.6.3|
|Python 3||3.4.10; 3.5.7; 3.6.9; 3.7.4|
|Node.js||6.17.1; 8.16.0; 9.11.2; 10.16.0; 11.15.0; 12.6.0|
|JE-33163||The pricing model is not attached when switching to the new reseller region while keeping the same domain|
|JE-36883||Incorrect conditions are configured for the docker cache location monitoring trigger|
|JE-45191||The MySQL init.d service is started by both init.d and jelinit scripts on Shared Load Balancers|
|JE-46860||Routes to containers are erased after host restart|
|JE-47324||Links to the platform logo should be adjusted based on the SSL configuration in system setting during reseller creation|
|JE-47801||The Phone Number column is hidden in the JCA > Users section if the verification method is not SMS|
|JE-48043||Empty placeholders in a description of the detachExtIp API method in the JCA > Access Control > Audit Log section|
|JE-48521||Environments are not charged for the last hour upon deletion|
|JE-48612||No validation for the Password and Password Confirmation fields in the account activation form|
|JE-48650||The developers’ dashboard remains accessible after activating maintenance mode via JCA|
|JE-48849||A graceful period of 10 days should be provided for the platform without access to JLS before license invalidation|
|JE-48998||Incorrect container name after redeploy|
|JE-49060||After endpoint removal, the connection remains available for a few minutes|
|JE-49103||Events filtering by nodeGroupAlias does not work in Cloud Scripting|
|JE-49131||The settings and globals placeholders don’t work with nodeGroupAlias in Cloud Scripting|
|JE-49199||Iptables rules are removed incorrectly for endpoints|
|JE-49251||Stack colors in the left and central parts of the topology wizard do not match|
|JE-49268||Collaborator should be able to create an environment on another account in the regions of the environment owner|
|JE-49308||An incorrect home directory is set when the rake_deploy file is executed on the Ruby environments|
|JE-49055||The process of data mounting between containers is slow|
|JE-49379||Data cannot be mounted from the custom Docker containers based on the Debian 9 OS templates|
|JE-49443||If mount point creation for the directory fails, existing mounts for the same folder become inaccessible|