Unlock Docker: Real-World Scenarios for Packaging, Multi-Version Deployments, and Secure Isolation

Compared with VMs, Docker offers clear advantages in lightweight footprint, configuration simplicity, and resource utilization, leading many enterprises to adopt Docker for improving their IT systems.

Application Packaging

Creating traditional packages (RPM, GEM, etc.) requires a clean environment to resolve compile‑time and run‑time dependencies, often involving manual VM or chroot setups that are time‑consuming and error‑prone.

Docker solves these problems by providing ready‑made clean images (e.g., Ubuntu, CentOS) and reproducible Dockerfiles that document the build process.

Clean build environments are easy to prepare using official images.

Dockerfiles act as immutable build scripts, allowing unlimited reuse.

Example:

We need to build an RPM for the PHP‑Redis extension.

First, create a Dockerfile:

FROM centos:centos6
RUN yum update -y
RUN yum install -y php-devel rpm-build tar gcc make
RUN mkdir -p /rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} && \
  echo '%_topdir /rpmbuild' > ~/.rpmmacros
ADD http://pecl.php.net/get/redis-2.2.7.tgz /rpmbuild/SOURCES/redis-2.2.7.tgz
ADD https://gist.githubusercontent.com/mountkin/5175c213585d485db31e/raw/02f6dce79e12b692bf39d6337f0cfa72813ce9fb/php-redis.spec /redis.spec
RUN rpmbuild -bb /redis.spec

Build the image: docker build -t php-redis-builder . Extract the generated RPM from the image:

[ -p /rpms ] || mkdir /rpms
docker run --rm -v /rpms:/rpms:rw php-redis-builder cp /rpmbuild/RPMS/x86_64/php-redis-2.2.7-1.el6.x86_64.rpm /rpms/

Validate the package with a second image:

FROM centos:centos6
ADD php-redis-2.2.7-1.el6.x86_64.rpm /php-redis-2.2.7-1.el6.x86_64.rpm
RUN yum localinstall -y /php-redis-2.2.7-1.el6.x86_64.rpm
RUN php -d "extension=redis.so" -m | grep redis

Build the validator image:

docker build -t php-redis-validator .

Multi-Version Mixed Deployment

Deploying multiple applications or several versions of the same application on a single server often causes file‑path and port conflicts. Docker isolates each container’s filesystem, eliminating path clashes, while port conflicts are resolved by mapping distinct host ports.

Upgrade and Rollback

Upgrades usually involve both the application and its dependencies, which may conflict with previous versions. With Docker, each upgrade is a new image; rolling back simply means stopping the new container and restarting the previous one, completing in seconds.

Multi-Tenant Resource Isolation

For shared‑hosting providers, resource isolation is essential. Docker leverages Linux namespaces and cgroups to isolate resources and enforce quotas. Additional hardening measures include:

Blocking container‑to‑internal‑network traffic with iptables (with selective exceptions as needed).

Applying SELinux or AppArmor profiles to limit container capabilities.

Mounting sensitive sysfs or procfs paths as read‑only.

Using grsecurity to reinforce the kernel.

Controlling memory, CPU, and disk I/O via cgroup quotas.

Shaping bandwidth per container with tc.

In practice, enabling rng-tools on the host mitigates entropy exhaustion that can block random‑number generation in multi‑tenant environments.

Internal Development Environments

Before containers, companies provided each developer with a virtual machine, wasting resources. Docker’s minimal overhead makes it ideal for internal development and testing environments, and shared images promote consistency across teams.

To use a container as a development workstation, one must handle remote login and process management. Although Docker was designed for micro‑services, running multiple processes (e.g., sshd, upstart) inside a container is feasible.

Conclusion

The article summarizes practical Docker scenarios, common challenges, and concrete solutions, aiming to inspire readers to adopt Docker in their workflows.