Patching DXP in Docker
Liferay patches fix DXP issues and the Patching Tool applies the patches. On Docker Hub, Liferay provides images pre-populated with each new Fix Pack, Security Fix Pack, and Service Pack. Liferay also provides Security Fix Packs, Hotfixes, and new Patching Tool versions to install to DXP containers.
Enterprise Subscription
Always back up your database and installation before patching.
Using Fix Pack, Security Fix Pack, and Service Pack Images
Fix Pack, Security Fix Pack, and Service Pack images are based on Slim Bundles. Slim Bundles start up faster and have a smaller footprint than regular Liferay Tomcat bundles. Only one patch, however, can be applied to a Slim Bundle. These images, therefore, have these patching limitations:
-
Fix Pack and Service Pack images can receive only one additional patch, such as a Hotfix or a Security Fix Pack.
-
Security Fix Pack images cannot be patched. They comprise a Fix Pack patched with a Security Fix Pack already.
Using a new Fix Pack, Security Fix Pack, or Service Pack image requires migrating to a container based on that image. Here is how to migrate from a DXP container to a new patch image.
-
Back up files you’ve used to customize your DXP container.
git commit -a
-
Download the new image from Docker Hub.
docker pull liferay/dxp:[tag]
-
Create a new container based on the image and that uses the artifacts and configuration files from your backup.
For example, you can put your artifacts and files in a local folder structure like this:
[host folder] ├───deploy ├───files ├───patching └───scripts
Then bind mount the host folder to the container’s
/mnt/liferay
folder in yourrun
command.docker run ... -v [host folder path]:/mnt/liferay liferay/dxp:[tag]
DXP launches in the new container using your artifacts and files.
Installing a Patch
Fix Pack images and Service Pack images are limited to receiving one additional patch. The patch can be a Hotfix, Security Fix Pack, or a patch that combines both. To get this last type of patch, create a Help Center ticket and request a patch that includes the latest security fixes and product fixes on top of your current Fix Pack level.
Patching requirements:
-
No existing patches in the container. Any existing patch must be reverted before applying a new patch.
-
The image must not be Security Fix Pack image; those images already include a patch (the Security Fix Pack).
-
A folder in your volume or bind mount that maps to the container’s
/mnt/liferay/patching
folder. Please see Providing Files to the Container for more information.
There are two methods for installing patches to containers:
Installing to an Existing Container
Here are the steps for installing a patch to your existing container:
-
Download the patch and copy it to a folder in a volume or bind mount that maps to the container’s
/mnt/liferay/patching
folder.
Installing to a New Container
Here are steps for installing a patch to a new container:
-
Create a host folder and a subfolder called
patching
.mkdir -p [host folder]/patching
-
Download the patch and copy it to your
[host folder]/patching
folder. For example,cp ~/[patch file] [host folder]/patching
-
Stop your current DXP container, if it’s running.
-
Create a container with a bind mount that maps the patch file’s folder to the container’s
/mnt/liferay/patching
folder. Since this example’s patch file is in a folder calledpatching
, you can bind mount its parent folder ([host folder]
) to the container’s/mnt/liferay
folder. This makes the patch accessible for applying to DXP.docker run ... -v [host folder path]:/mnt/liferay liferay/dxp:[tag]
notePlease see Providing Files to the Container for more information on specifying bind mounts.
The Patching Tool installs the patch and DXP launches.
If the Patching Tool reports this message: [patch file] is incompatible with Patching Tool version [x.y.z]
, install the latest Patching Tool. See Installing the Patching Tool for details.
Reverting a Patch
If you want to revert a patch from a container or install a different patch to a patched container, you must remove the container and create a new one.
-
docker stop [container]
-
Back up the container’s artifacts and files.
-
Remove the container.
docker rm [container]
-
Use the
docker run
arguments you used previously to create a new container from the same image or an image that has a compatible Fix Pack Level. Apply any patch you want via a volume or bind mount.
Updating the Patching Tool
If your current Patching Tool is incompatible with the patch you’re installing, the Patching Tool reports this message: [patch file] is incompatible with Patching Tool version [x.y.z]
, where x.y.z
are the tool’s major, minor, and micro version number.
Here’s how to install a new Patching Tool version:
-
Download the latest Patching Tool from the Customer Portal.
-
If the Patching Tool ZIP file name doesn’t have this format
patching-tool-x.y.z.zip
rename it to use that format. For example,mv patching-tool.zip patching-tool-2.0.15.zip
-
Install the Patching Tool ZIP file to the container via the container’s
/mnt/liferay/patching
folder, in the same way that Hotfixes and Security Fix Packs are installed.
On restarting your container or running a new container, the container entry point installs the new Patching Tool.
Upgrading the Database for a Patch
If a patch requires upgrading the database, you must upgrade it using the Database Upgrade Tool in a non-containerized environment.
-
Install the Liferay Tomcat Bundle installation of the Liferay version you’re using.
-
Apply the patch to the installation. Please see Patching Liferay for more information.
-
Upgrade the database using the Database Upgrade Tool. Please see Using the Database Upgrade Tool for more information.
After the database is upgraded, run your container that uses that database.