Designing a Lightweight Docker Deployment Architecture with Rolling Updates

The article starts by describing a cumbersome deployment architecture where a single Docker image contains MySQL, Nginx, Redis and other middleware, resulting in a 2.44 GB image, long build times and difficult maintenance.

It then outlines best practices for creating a service‑specific base image: single responsibility, minimal size (e.g., alpine:latest or openjdk:8-jre-alpine ), multi‑stage builds, and externalized configuration via environment variables.

Key system settings such as timezone configuration for Alpine Linux ( apk add tzdata and cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime ) and the choice of an init process (e.g., tini ) are discussed, including how to enable Docker’s --init flag.

A complete Dockerfile example demonstrates these concepts, adding a custom entrypoint.sh script that forwards Java commands or executes arbitrary commands, and installing tini as the container’s entrypoint.

The entrypoint.sh script itself is provided, showing conditional execution of Java with additional JVM options and a fallback to the supplied command.

Next, the article presents a directory layout for a multi‑service project and a docker-compose.yml configuration that mounts host directories, sets working directories, and passes environment variables and commands to the containers.

It compares the new architecture with the old one, highlighting that each container now runs a single service and that Nginx acts as a reverse proxy for all services, while databases and caches are deployed separately.

The rolling‑update strategy is explained, detailing the state transitions for a service (e.g., demo-app ) and how to add a new container instance, shift load in Nginx, restart the old container, and finally clean up the temporary instance.

Practical commands for Docker Swarm, Kubernetes, and Docker Compose are provided, such as creating services, updating images, and restarting deployments. Nginx upstream configuration snippets show how to add or remove servers and reload the configuration ( nginx -s reload ).

Automation is achieved with a Bash script that uses yq to duplicate a service definition, adjust container names and ports, and manipulate Nginx configuration with sed . The script includes health‑check loops, functions for adding/removing the backup node, and steps to restore the original service.

The conclusion reflects on the benefits of the new Docker‑Compose‑based architecture, mentions future work such as extending to Docker Swarm/Kubernetes, improving script robustness, handling rollbacks, and adding business‑specific dependencies.

References: [1] https://github.com/krallin/tini [2] https://github.com/mikefarah/yq