How Docker Supercharges Continuous Delivery in Real‑World Projects

Continuous Delivery (CD) aims for short cycles, fine‑grained automation, and frequent software releases, but many traditional enterprises still rely on manual packaging and deployment, which is error‑prone and hard to manage.

Project Background

The client, a logistics company, needed a new portal to handle traffic spikes like Double‑11. The solution is a Java‑based web application using a REST architecture, OpenCMS for static site generation, a JavaScript front‑end, and a background task service.

Dynamic services built with Jersey

Customized OpenCMS for static export

JS front‑end packaged for OpenCMS

Background task service for low‑priority jobs

The system architecture is illustrated in the diagram below.

Challenges and Why Docker

The client required a test environment that mimics the production architecture, but faced severe hardware constraints and strict UAT controls, making traditional deployment cumbersome and risky.

Docker was chosen because:

Containers isolate workloads, allowing multiple simulated machines on a single host.

Low OS intrusion; most Linux distributions run Docker without extra software.

Containers are reproducible and can be shared via export/import, save/load, private registries, or Docker Hub.

Docker and Continuous Integration

Jenkins is run inside a Docker container, simplifying installation and upgrades.

Creating the Jenkins container: docker run -d -p 9090:8080 --name jenkins jenkins:1.576 Sample Dockerfile for the Jenkins image:

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"]

Build and tag the image: docker build -t jenkins:1.578 --rm . Run Jenkins with a volume for persistent data:

docker run -d -p 9090:8080 -v /usr/local/jenkins/home:/var/lib/jenkins --name jenkins jenkins:1.578

Jenkins slaves are also Docker containers that contain only the tools needed for a build, never the project data.

Example Dockerfile for a Java build slave:

FROM ubuntu

RUN apt-get update && apt-get install -y -q openssh-server openjdk-7-jdk

RUN mkdir -p /var/run/sshd

RUN echo 'root:change' | chpasswd

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

Run the slave and expose SSH: docker run -d -P --name java java:1.7 Mount host directories to keep project data outside the container:

docker run -d -v /usr/local/jenkins/workspace:/usr/local/jenkins -P --name java java:1.7

Docker and Automated Deployment

Standardized Docker images are organized in three layers: base images (common tools), service images (enterprise‑standard components), and application images (CI artifacts). This layering speeds up builds and ensures consistency.

Base image Dockerfile (CentOS with SSH):

FROM centos

RUN yum install -y -q unzip openssh-server

RUN ssh-keygen -q -N "" -t dsa -f /etc/ssh/ssh_host_dsa_key && ssh-keygen -q -N "" -t rsa -f /etc/ssh/ssh_host_rsa_key

RUN echo 'root:changeme' | chpasswd

RUN sed -i "s/#UsePrivilegeSeparation.*/UsePrivilegeSeparation no/g" /etc/ssh/sshd_config && sed -i "s/UsePAM.*/UsePAM no/g" /etc/ssh/sshd_config

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

Service layer image adding Java 6u38:

FROM base

ADD jdk-6u38-linux-x64-rpm.bin /var/local/

RUN chmod +x /var/local/jdk-6u38-linux-x64-rpm.bin

RUN yes | /var/local/jdk-6u38-linux-x64-rpm.bin &>/dev/null

ENV JAVA_HOME /usr/java/jdk1.6.0_38

RUN rm -rf var/local/*.bin

CMD ["/usr/sbin/sshd", "-D"]

Application layer adding JBoss on top of the Java image:

FROM java

ADD jboss-4.3-201307.zip /app/

RUN unzip /app/jboss-4.3-201307.zip -d /app/ &>/dev/null && rm -rf /app/jboss-4.3-201307.zip

ENV JBOSS_HOME /app/jboss/jboss-as

EXPOSE 8080

CMD ["/app/jboss/jboss-as/bin/run.sh", "-b", "0.0.0.0"]

Deployment scripts are version‑controlled under a deploy directory, with role‑based sub‑scripts (nginx, opencms, service‑backend, service‑web) that simplify responsibility separation.

Local virtualization with Vagrant allows testing the deployment scripts against two Docker‑enabled virtual machines:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

config.vm.define "server1", primary: true do |server1|

server1.vm.box = "raring-docker"

server1.vm.network :private_network, ip: "10.1.2.15"

end

config.vm.define "server2" do |server2|

server2.vm.box = "raring-docker"

server2.vm.network :private_network, ip: "10.1.2.16"

end

end

A private Docker Registry stores the layered images, enabling push/pull commands such as:

docker run -p 5000:5000 registry

docker push your_registry_ip:5000/base:centos

docker push your_registry_ip:5000/java:1.6

docker push your_registry_ip:5000/jboss:4.3

Conclusion

The case study shows that Docker provides a flexible, lightweight, and highly portable foundation for continuous delivery, allowing enterprises to simulate complex architectures on limited hardware, standardize images, automate builds and deployments, and ultimately achieve faster, more reliable software releases.