Service Updates for Liferay Cloud Version 4

The services update to 2020.51.1 includes updates to the Backup, CI, Database, Liferay, and Webserver.

This services update contains minor version increments, which signals that some behavior has changed in this release. Please read these notes carefully before applying to your environment.

Known Issue: User Backup Upload Fails

In Backup version 4.1.0, the a manual upload process will fail. This issue is addressed in 4.1.1. Please see the change log here for details about version 4.1.1

liferay/dxp docker image tags

In an ever evolving effort to provide the best support, the docker tags on liferay/dxp docker repository have changed. The new addition is a `-dx.y.z` designation (e.g. -d1.0.2), which provides information about any changes to the underlying docker scripts that are utilized by the image. The new tags on Dockerhub for liferay/dxp are formatted as follows

liferay/dxp:{Liferay.DXP.Version}-{Patching-Level}-{Docker.Script.Version}-{Timestamp}
liferay/dxp:7.2.10-dxp-7-d1.0.0-202009071842

When selecting which liferay/dxp base image to utilize for your project, please consider the entire docker tag, and be sure to check out the release notes for your patching level before applying to your environment: DXP Release Notes

CI

Deploy Branch Matching for deployToCloud

If using the deployToCloud Jenkins build step in a custom pipeline, the step will now check the branch being built against the argument passed in for deployBranch. 

• an empty deployBranch signals that ALL branches should be deployed to the target environment (i.e. deployTarget)
• a simple match with a name like "develop" will only deploy to the target environment when the step is executed on the "develop" branch
• a regex can be used to specify more than one source branch (i.e. deployBranch) to deploy to the target environment when run. A regex of "(dev[123])" will match branches "dev1", "dev2", and "dev3", but will not match "develop"

Gradle Memory Settings

The liferay service is built using Gradle. Setting the right memory for a Gradle task can be done through Gradle command line arguments. The GRADLE_OPTS environment variable is effective for builds if the Gradle daemon is disabled, but this is not the case by default. In order to provide better clarify around the memory usage of the build process, there is now an environment variable that can be used to set the Gradle memory of the build process.

LCP_CI_GRADLE_JVM_ARGS "-Xmx2g -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8"

LCP_CI_GRADLE_LOGGING_LEVEL lifecycle

Liferay Cloud CLI Logging

The CI service leverages the Liferay Cloud CLI to create and deploy builds for the project. The design concept of the CLI is driven by user interaction. In a normal experience, the user of the CLI would see a status updates as the output of running a command. This was achieved by printing over the same group of lines many times. In the CI service, the logs get printed per line, which was causing the build log to show sometimes hundreds of lines of CLI output. 

We have updated the handling of the CLI output to group those logs together, showing as a single group in the build log.

Liferay

This process is more transparent and allows modifying other configurations in the web.xml. 

non-production portal properties

Liferay has many properties that facilitate development. The default developer portal properties are included in Liferay's bundles under the file portal-developer.properties. However, a non-production environment in DXP Cloud may not be including this property file. In order to facilitate a better  development experience, we have included the following two properties when starting a non-production instance:

LIFERAY_WEB_PERIOD_SERVER_PERIOD_DISPLAY_PERIOD_NODE=true
LIFERAY_COMPANY_PERIOD_SECURITY_PERIOD_STRANGERS_PERIOD_VERIFY=false

Webserver

Updated Logging

The Webserver service utilizes Nginx and HAProxy. Sometimes it is necessary to increase the logging of those underlying processes. 

Nginx logs are configured through the nginx.conf file, but we have exposed an environment variable to allow altering the log level without customizing the default configuration. This environment variable can accept the following values: debug, info, notice, warn, error, crit, alert, or emerg, with the default value set as warn.

ERROR_LOG_LEVEL warn

NGINX_STATUS_ACCESS_LOG off

LCP_HAPROXY_GLOBAL_LOG_LEVEL info

Version Compatibility between 3 and 4

For details on service compatibility between version 3 and 4 please see release update 6/11/2020 Services Update 2020.24.1 or 5/28/2020 Services Update 2020. 22.1 

Feature Exclusion in Version 3 DXP Stack

Due to the deprecation process for the Version 3 DXP Stack, the 3.x service images will no longer receive feature updates. 

Version 4 DXP Stack 2020.45.1 

Version 4 Update Instructions

Only Applicable to Version 4 Images

After upgrading your project using this guide, the Liferay Cloud image versions are no longer set inside of the gradle.properties file. They now need to be set inside of the <service>/LCP.json file. Note, however, that the liferay service uses two image properties. The DXP Cloud image is set in the liferay/LCP.json file, but the liferay/dxp image is set in the gradle.properties. This change was made in order to facilitate easier deployment using the Liferay Cloud CLI.

liferay/LCP.json file would set the liferaycloud/liferay-dxp image:

"image":"liferaycloud/liferay-dxp:7.3-4.1.0"

liferay/gradle.properties file would set the liferay/dxp image:

liferay.workspace.docker.image.liferay=liferay/dxp:7.3.10-ga1-d1.3.1-20201217114152

Once the LCP.json files are updated, commit the changes to your Git repository.

git add . && git commit -m "update dxp cloud stack to 2020.51.1"

After pushing these changes to the remote repository, a build will be created in Liferay Cloud, and it is ready to deploy.

Version 4 Change Log