How to build a Docker Liferay 7.2 image with the SQL Server 2017 Database support

In the recently published article How to build Docker Liferay 7.2 image with the Oracle Database support, I explained how to create the Liferay 7.2 Docker image by adding support to the Oracle database and in particular I explained how to do it using Blade CLI and Liferay Workspace.

In this article we will see how to achieve the same goal (from the previous article) but adding support for Microsoft SQL Server 2017. The Liferay Digital Experience Platform 7.2 Compatibility Matrix indicated SQL Server 2017 among the certified databases.

The source code of the Liferay Workspace it’s available on this GitHub repository liferay-72-sqlserver-docker-images.  

1. What are the requirements

Before proceeding with the construction of the Docker image, the following requirements must be met.

  1. Installation or upgrade to the latest version of Blade;
  2. Docker Engine 18.x,19.x;
  3. An instance of an SQL Server 2017 database.

For the installation and updating of Blade CLI you could refer to this official Liferay documentation: Installing Blade CLI and Updating Blade CLI. The latest version is You can use this command blade version for checking your version.

Regarding the version of Docker I used both the version 18.09.8 and the 19.03.1. You can check your version with the docker version command. If you do not have an SQL Server 2017 instance ready for use, you might consider using this official Docker image from Microsoft’s Docker Hub account to your local computer and starting that image.

We need to have an instance of SQL Server already configured to host Liferay. No problem, in this article, How to setup Docker container SQL Server 2017 for Liferay Development Environment, I will explain how to do it.


2. Create the Liferay Workspace and Dockerfile

First of all we have to worry about creating the Liferay Workspace that we will use in order to configure and build our docker image. Let’s proceed in this way to create the Liferay Workspace.



The first command initializes the Liferay Workspace while the last command using the Gradle createDockerfile task that creates the Dockerfile. The Gradle task execution creates a new directory structure and the Dockerfile. The new directory structure and file created is shown below (command tree -L 3 build).



The created Dockerfile is not good because it contains the reference to the base image of Liferay 7.1. We instead need version 7.2 of Liferay.



In order for the Dockerfile to be created with the correct version of the Liferay image, the following content must be inserted in the file. The specific image has been set on the liferay.workspace.docker.image.liferay property. To find the possible property values you can set, see the official Liferay Portal Docker Hub’s Tags section (e.g., Liferay Portal Docker Tags). In our case we want to get the version 7.2 GA1 of Liferay Portal: liferay/portal:7.2.0-ga1



At this point we re-launch the Gradle createDockerfile task to recreate the new Dockerfile. Now the FROM directive of the Dockerfile contains the correct version of the image.



Before proceeding further, you need to update the version of com.liferay.gradle.plugins.workspace from 2.0.4 to 2.1.5. The change must be made to the settings.gradle file. From version 3.8 of blade it is no longer necessary to update the version of the plugin because it is already correct.



3. Docker image configuration

Now all that remains to do is configure our personalized image of Liferay 7.2 so that it is able to connect to an SQL Server database.

The configs/docker folder is where your configuration and overlay files for your Docker image. You’ll put files here such as your file, your osgi/configs files, overrides for the tomcat-9.0.x files (where x is going to be the version of tomcat included in the bundle), etc.

What do you need for configuring the new image?

  1. JDBC Driver for SQL Server 2017 (version 7.4);
  2. Liferay Portal Database All-in-One support (download from Maven Repository);
  3. Configuring the connection to the SQL Server database via

The commands shown below do:

  1. The creation of the file whose content is shown below;
  2. The creation of the directory configs/docker/tomcat/lib/ext where the SQL Server JDBC driver will be installed;
  3. The creation of the directory configs/docker/tomcat/webapps/ROOT/WEB-INF/lib where the Liferay driver will be installed for SQL Server database support;
  4. The copy of the driver liferay-portal-database-all-in-one-support in configs/docker/tomcat/webapps/ROOT/WEB-INF/lib.



The file you see, configuring the JDBC connection to the SQL Server database also enables access to the GogoShell.


At this point we re-launch the Gradle createDockerfile task, but specify the environment using the parameter -Pliferay.workspace.environment=docker (blade gw clean createDockerfile -Pliferay.workspace.environment=docker). This time the contents of the build/docker directory will also contain our configurations.


Note that this step (the execution of the Gradle task createDockerfile) is not typically needed. I’m just using this command so I can see what will be used for the Docker image without actually creating the image yet.


4. Build and run the Docker image

At this point we can proceed with the build of our Docker Liferay 7.2 image with support for the SQL Server database. The Gradle buildDockerImage task does just that.

The figure below shows the output of the Gradle task execution, while the following figure shows the details of the image just created.

Figure 1 - Output of the gradle buildDockerImage task

Figure 1 – Output of the gradle buildDockerImage task

As you can see from figure 2, the docker environment is used as a tag of our image (liferay-72-sqlserver-docker-images:docker).

Figure 2 - Output of the command docker image ls

Figure 2 – Output of the command docker image ls

Before creating and running our Liferay container, we need to make sure that the SQL Server instance is running but if you have read the article How to setup Docker container SQL Server 2017 for Liferay Development Environment I guess that SQL Server instance is running.

Figure 3 - Check if SQL Server 2017 instance is running

Figure 3 – Check if SQL Server 2017 instance is running

All that remains is to start our image and we can do it with the command to follow. The docker command makes sure to expose ports 8080 (web) and 11311 (Gogo Shell). It also makes sure to use the volume to allow us to easily deploy our applications, just copy the bundles into the $(pwd)/build/docker/deploy directory.

To view the Liferay logs you need to run the command docker logs -f Liferay72-SQLServer. The Docker command to access the machine is shown on the log.

Figure 3 - Output of the Liferay log file

Figure 3 – Output of the Liferay log file


You can monitor the status of our container using the docker ps command. Figure 4 shows the status and which TCP / IP ports are exposed.


Figure 4 - Output of the command docker ps

Figure 4 – Output of the command docker ps

Figure 5 shows the Oracle schema populated with Liferay tables at start-up.

Figure 5 - Get Liferay portal version from RELEASE_ table

Figure 5 – Get Liferay portal version from RELEASE_ table


Docker has become increasingly popular in today’s development lifecycle, by providing an automated way to package software and its dependencies into a standardized unit that can be shared cross-platform.

You can now manage Liferay’s Docker images in Liferay Workspace and push your Docker custom image on Docker Hub or other registry 😉 !

Antonio Musarra

I began my journey into the world of computing from an Olivetti M24 PC ( bought by my father for his work. Day after day, quickly taking control until … Now doing business consulting for projects in the enterprise application development using web-oriented technologies such as J2EE, Web Services, ESB, TIBCO, PHP.

You may also like...

Cosa sono gli OSGi Remote µServicesOSGi Framework come alternativa ai Microservices

In questo articolo ho voluto dimostrare come il framework OSGi con i suoi veri µServices sia in grado di favorire lo sviluppo di sistemi distribuiti leggeri, affidabili e puliti.