Seamless Tomcat Webapp Migration with Docker and Layered Configuration

Application Migration Requirements

Application operations often need migration across machines, data centers, or environments due to hardware failures, data‑center moves, or scaling needs. Core migration requirements are simplicity (one‑click, no learning curve), speed (minimal downtime), and losslessness (identical functionality and data after migration).

Tomcat Webapp Deployment Structure

A typical Tomcat‑based Java webapp consists of two parts:

Static binaries : bin/, lib/ – read‑only, provided by the Tomcat package.

External configuration and data : conf/, logs/, temp/, webapps/, work/ – the actual application package.

Note: Although Tomcat itself includes a conf/ directory, applications often maintain an independent conf/ copy to avoid modifying the package defaults.

For migration, only the external configuration and data need to be moved. Stateless designs further reduce the migration scope to conf/ and webapps/, while directories like logs/, temp/, and work/ can be omitted.

Deploying to a New Environment

Two common approaches:

List required packages (e.g., Tomcat and the application) and install them manually on the target host – the “Juju” style.

Create a single binary image containing all packages and deploy it – the “Docker” style, where a Dockerfile defines the image.

Docker images bundle the OS, standard logs, data paths, and environment variables, offering a ready‑to‑run, standardized environment. Juju achieves similar isolation by creating VMs or LXC containers from a base image.

Single‑Host Multi‑Instance Isolation

Docker containers provide lightweight, isolated runtimes, allowing multiple instances of the same application on a single host without the overhead of full VMs, and they integrate smoothly with micro‑service orchestration.

Package and Configuration Layering

Some packages (e.g., Tomcat) support separating default package configuration from application‑specific configuration by using distinct CATALINA_HOME and CATALINA_BASE directories. Docker’s layered filesystem abstracts this separation, avoiding the need for each package to implement its own configuration‑layering logic.

Configuration Management

Traditional manual edits on individual machines are error‑prone and lack auditability. With Docker, the workflow is to update the image, test it, and roll out the new image to all hosts, letting Docker track image versions and container states. Static configuration should be baked into the image, while frequently changing settings are better managed via feature‑flag platforms or dedicated configuration services such as Diamond.

Docker Container Data Volumes

Container filesystems disappear when a container is removed or updated. Persistent or high‑write data (e.g., logs/, data/) should be stored on the host via Docker volumes, declared in a Dockerfile with the VOLUME instruction.

Docker‑Based Operations Solution

Summarizing the approach, Dockerized operations split an application into three layers:

Base layer: operating system, runtime dependencies, static packages, and immutable configuration – baked into the image.

Dynamic configuration layer: managed by a feature‑flag or configuration platform (e.g., Diamond).

Persistent data layer: mounted as Docker volumes for logs, databases, or other high‑write directories.

Deploying consists of distributing the image, pushing configuration updates via the management platform, and attaching volumes as needed, enabling rapid deployment, migration, updates, rollbacks, and scaling.