When it comes to deploying a common Java server on a common cloud infrastructure, a range of possibilities crosses one’s mind. This article presents some feedback on a particular, real-life, case of deploying Liferay Digital Experience (DXP, aka. Liferay 7 EE) on Microsoft’s Azure cloud platform.
Initial Shopping List
- Liferay DXP, with Enterprise Subscription, fitting in the compatibility matrix
- Process of deploying Liferay DXP on Azure
- Reliance on SaaS solutions as much as possible
- Use of infrastructure & platform provisioned by Ansible
The Happy Path : Azure SaaS Building Blocks
In this process, we consistently use Azure’s SaaS platform. We set up the following three (3) services:
Service I : Azure SQL database
Our team configures Tomcat JDBC using driver sqljdbc42.jar from https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774 .
(note : there seems to be a new MS-SQL JDBC release going on github)
Service II : Azure files
We set up the Liferay document store library using the Advanced File System Store mounted locally on Liferay’s VM. For the mounting process we use CIFS from an Azure file share.
//<storage account name>.file.core.windows.net/<file share name> /var/lib/liferay/data-remote cifs vers=3.0,username=<storage account name>,password=<storage account key>,uid=tomcat8,gid=tomcat8 0 0
Service III : Azure Application Gateway
We use an Application Gateway to handle a)SSL termination ; and b)load-balancing of the web traffic between two Liferay instances (round robin only).
In order to convert the SSL certificate + chain + key to Azure’s .pfx bundle, use :
$> openssl pkcs12 -export -out <new pfx filename>.pfx -inkey <key filename>.key -in <certificate with chain filename>.crt -passout pass:<new pfx password>
The Plain Old Virtual Machine Part
Liferay DXP itself is installed on an Ubuntu Virtual Machine. This matches the recommended installation scheme for a production instance, which is deploying Liferay in the system tomcat8 installation. Liferay Hot Fixes and Service Packs can also be installed in this context, using Liferay’s patching-tool utility.
The Unexpected : Boundaries of Liferay’s Compatibility Matrix
Liferay DXP uses Elastic Search by default as its indexing and search provider. To stay within the compatibility matrix on production, Elastic Search needs to be hosted on a separate, dedicated Java Virtual Machine (JVM) (as opposed to the default development scheme which embeds ES alongside Liferay in a single JVM). Azure does not propose any Elastic Search as a service (managing your ES cluster is up to you). Furthermore, in order to secure a connection from Liferay DXP to a remote Elastic instance (e.g. Elastic cloud), you will need the extra “Liferay Elastic Shield Integration” marketplace item, purchasable as part of the Enterprise Search Add-On Subscription. This extra item would allow you to use Elastic Shield, though you cannot stay in the compatibility matrix today using Elastic Cloud, as its ES version is more recent than the one officially supported by Liferay.
Following this approach, we can install a 2.2 Elastic Search instance on a VM accessible from Liferay without having any need for Elastic Shield (on the same machine or internal network). Figure 1 below presents the summary of the global scheme explained here.
Figure 1. The Summary of the Global Scheme
Based on Figure 1 above, and the detailed explanations we can map three alternatives which can be evaluated and tested in future. First, it seems that the pre-packaged Liferay appliance allows for a single-click deployment on Azure but only for CE edition only. This is one avenue for further discovery. Second, we need to explore and evaluate the feasibility of pushing various Docker Liferay images to Azure Container Service and identify which ones do not offer this possibility. Third, is it possible to deploy Liferay as a custom Azure Web App? This is yet another issue to pursue further. For more insights on deploying Liferay Digital Experience Platform (DXP) on Microsoft’s Azure cloud platform stay tuned…