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
21.06 and gets repointed based on the latest version or minor version of a new release.
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:
or in the case of
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.
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:
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
21.07 to this image.
We will maintain a stable tag for
latest, for each “major” version, e.g.
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.
|Configuration||Many configuration options are available without the need for a configuration plugin.|
|OSGI Plugins||With a Docker image, you can load and manage OSGI plugins the same way as you would with any other dotCMS distribution.|
|Static Plugins||Note: Deploying static plugins in a dockerized environment has been deprecated and support will be removed in a future version.|
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.