Docker documentation for the dotCMS Content Management System

dotCMS releases and maintains dotCMS Docker containers that can be used as a foundation for hosting a scalable dotCMS installation. Many dotCMS customers are currently using Docker containers for production deployments, using both the official dotCMS Docker containers or customized Docker containers.

The dotCMS-provided container is intended to be used the foundation for your Docker deployments and offer a range of configurable parameters to meet most use cases. All dotCMS web properties run on the official Docker container, including our primary (production) site, our authoring environments, and the dotCMS Demo site.

Images and Versioning

The dotCMS docker image is publicly available on Docker hub: https://hub.docker.com/repository/docker/dotcms/dotcms and can be pulled by using the stable tag latest or by the stable tag for a release number, e.g. docker pull dotcms/dotcms:21.06

Stable vs. Unique Tags

dotCMS docker images follow the concepts of unique tags and stable tags. A unique docker tag is an immutable pointer to a build at a given time and should never change. A stable tag is like latest or 21.06 and gets repointed based on the latest version or minor version of a new release.

Unique Tags

All built images should be uniquely (immutably) tagged in docker hub based on the dotCMS version number followed by an underscore and then the short git commit hash, e.g. git log -1 --pretty=%h. So, when building say 21.06, the action would build the image and uniquely tag it:

dotcms/dotcms:21.03_feacd49

or in the case of 21.06.1

dotcms/dotcms:21.06.1_40c7361

And push the image + unique tags to dockerhub.

If we rebuild the 21.06 image to include either changes to the Docker build process or to the dotCMS code, it will have a new git hash which would be reflected by a new unique tag, e.g. dotcms/dotcms:21.06.2_71f7361

Stable Tags

If the docker image you are building is for a new release, we build it and tag normally it with its unique tag and then we update the corresponding stable tags to this new image as well.

In the case of pushing a new Agile Release, say 21.07, we would build our uniquely tagged image dotcms/dotcms:v21.07_7eacd49 and then point the stable tags: latest and 21.07 to it. If/when we need to push out a point release 21.07.1, we again build a new uniquely tagged image dotcms/dotcms:21.07.1_cd45d54 and repoint the stable tags latest and 21.07 to this image.

We will maintain a stable tag for latest, for each “major” version, e.g. 21.03 or 21.07.

Repeatable Deployments for Production

When deploying for production, dotCMS recommends to always use a uniquely tagged image so that your image does not change inadvertantly during deployments.

Configuration and Plugins

The dotCMS Docker containers have been designed to allow you to configure dotCMS without the need to modify the Docker images, via both configurations and dynamic plugins.

MethodDescriptionAdditional Information
ConfigurationMany configuration options are available without the need for a configuration plugin.
  • Please see the Docker image documentation to see what options are available. Additionally, most dotCMS configuration variables can be overriden by the use of environmental variables. See changing configuration properties for more information
OSGI PluginsWith a Docker image, you can load and manage OSGI plugins the same way as you would with any other dotCMS distribution.
  • Please see the OSGI Plugins documentation for more information.
Static PluginsNote: Deploying static plugins in a dockerized environment has been deprecated and support will be removed in a future version.
  • Map your plugins directory into “/plugins/static” in the Docker image, and the image will automatically find and deploy the plugins.
  • Please see the Docker Reference Implementation documentation for an example of how this is done.

Permissions

The dotcms user and group (1000000000:1000000000) should own /data/shared/assets and /data/shared/felix/. We don't typically modify the permissions of those directories once they have been created by dotcms. However, as long as the user has rwx and the group has at least rx, it shouldn't be an issue.

The dotcms user should be executing the entrypoint script.

For EFS specifically, we generally use access points and specify the POSIX User and Root directory creation permissions with 1000000000 for the UID and GID. Additionally, you can use 0755 for POSIX permissions to apply to the root directory path to be safe since only that specific dotCMS environment should be accessing the files in the path anyway.