Running dotCMS in a Docker Container
There are no technical limitations preventing dotCMS from running under the Docker platform. However, some elements of the Docker architecture can introduce performance issues and can interfere with some dotCMS features (especially clustering). Since dotCMS ships with an embedded H2 database and a starter site as the default configuration, the only addtional required element is to install a proper JDK in the Docker container.
Particular attention should be directed toward making sure that persistent data such as your dotCMS assets and database are stored on non-transient storage so that critical data is not lost when containers are undeployed.
Running dotCMS in a Docker Multi-Container Environment
It may be possible to run dotCMS using a Docker multi-container deployment, but only when using a database other than H2. You may wish to use a Docker multi-container deployment to guarantee the modular spirit of docker, and to benefit from an already created and maintained database server image. You may find several database flavors available as a docker image, just make sure the database engine is a supported version.
For all Java web applications to achieve acceptable performance, minimum requirements for CPU, memory and networking. Therefore, if you are considering running dotCMS in Docker, please review the following sections and ensure that Docker is configured properly to minimize performance issues.
As a Java application, the environment that dotCMS runs in should have 100% guaranteed (reserved) access to the CPU resources allocated to it. CPU oversubscription can cause severe performance problems for all workloads on the server due to Java garbage collection dynamics. Guaranteeing CPU allocation to a Docker container inside a virtual machine may be possible, but requires fine-tuned adjustment in the runtime parameters.
For more information on the Docker CPU allocation parameters, please see the Docker documentation.
As a Java application, the environment that dotCMS runs in should have 100% guaranteed (reserved) access to the memory (RAM) resources allocated to it. Memory oversubscription can cause severe performance problems (including application crashes) for all workloads on the server due to Java garbage collection dynamics.
Important: Swap disk should not be used on any server running dotCMS, and this is even more critical in a Docker environment.
For more information on the Docker memory allocation parameters, please see the Docker documentation.
Docker has a number of different options for allocating storage to Docker containers. Unfortunately, many of these introduce overhead and latency to the storage layer which can significantly impact dotCMS performance. Additionally, allocating data storage within the Docker container can introduce significant challenges with dotCMS storage scalability and data lifecycle management & persistence.
The best I/O performance and data management is usually achieved by mounting a host data directory in the dotCMS Docker container (documentation) to use for database, assets (
ASSET_REAL_PATH), and dotsecure (
DYNAMIC_DATA_PATH) storage. This provides a good separation of concerns between the application managed in the Docker container, and the persistent data managed outside of the Docker container.
For more information on the Docker storage parameters, please see the Docker documentation.
Docker has several different options for managing network connectivity for containers using bridging and/or NAT. These can introduce varying levels of system overhead and network latency, although this is typically unnoticeable in a single-server dotCMS environment. However, dotCMS clustering can be fairly sensitive to network latency, and the NAT port mappings used by some Docker networking models can interfere with proper cluster operation. Running a dotCMS cluster will be challenging to configure properly and might not be possible.
For more information on the Docker networking parameters, please see the Docker documentation.