Using Docker to Build a Continuous Delivery Pipeline: A Practical Case Study

Project Background

The client, a logistics company, needed a new portal to handle massive traffic spikes such as Double‑Eleven sales. The solution was a Java‑based web application using a REST architecture, OpenCMS for static site generation, a JavaScript front‑end, and a backend task service.

Challenges and Why Docker Was Chosen

Limited hardware (two 4‑core, 8 GB machines) and strict UAT/product environment controls made traditional deployment risky and labor‑intensive. Docker’s lightweight isolation, low OS intrusion, and easy image sharing allowed the team to simulate multiple machines on a single host and create reproducible release packages.

Docker‑Based Continuous Delivery Process

A custom workflow was designed to generate a unique release package containing all WAR/JAR files, database migration scripts, and configuration, ensuring a single source of truth for both manual and automated deployments.

Docker and Continuous Integration

Jenkins was run inside a Docker container, simplifying installation and upgrades. The container was built with a Dockerfile and version‑tagged, e.g.: docker run -d -p 9090:8080 --name jenkins jenkins:1.576 A separate Dockerfile defined the Jenkins environment:

FROM ubuntu
ADD sources.list /etc/apt/sources.list
RUN apt-get update && apt-get install -y -q wget
RUN wget -q -O – http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add –
ADD jenkins.list /etc/apt/sources.list.d/
RUN apt-get update
RUN apt-get install -y -q jenkins
ENV JENKINS_HOME /var/lib/jenkins/
EXPOSE 8080
CMD ["java", "-jar", "/usr/share/jenkins/jenkins.war"]

Builds were tagged with new versions, e.g.: docker build -t jenkins:1.578 --rm . Jenkins slaves were also containerized, each containing the necessary build tools (JDK, SSH server, etc.) and mounted volumes to keep source code and workspace on the host, ensuring no project data resides inside containers.

Docker and Automated Deployment

The team standardized images into three layers: base (common tools like OpenSSH), service (enterprise‑standard runtimes such as Java), and application (CI artifacts). This layering accelerated image builds and kept higher‑level images stable.

Example Dockerfiles for the base and Java layers were provided, showing installation of OpenSSH, JDK, and configuration steps.

Deployment scripts were organized under a deploy directory with role‑based sub‑scripts (nginx, opencms, service‑backend, service‑web), enabling clear, repeatable deployments via commands such as: bin/deploy.sh -e test -p 10.1.2.15 service-web A local Docker Registry was set up to store and share internal images: docker run -p 5000:5000 registry Images were pushed and pulled using the registry’s address, e.g.:

docker push your_registry_ip:5000/java:1.6

Summary

The case study demonstrates how Docker can provide a flexible, lightweight, and scalable foundation for continuous delivery, enabling rapid provisioning, consistent environments, and streamlined CI/CD workflows in resource‑constrained enterprise settings.