Docker Deployment Guide: 3-Step Checklist, Data Persistence & 5 Pitfalls to Avoid

This article provides a hands-on Docker deployment walkthrough, moving from basic container usage to production-ready practices. It structures the process into three phases: pre-deployment checks, core deployment operations, and post-deployment verification, plus a list of five frequent rookie mistakes and daily management commands.

1. Pre-Deployment Checks (Three Must-Do Verifications)

1.1 Check Docker Service Status

Before any deployment, confirm the Docker daemon is running. On CentOS/RHEL use systemctl status docker; on Ubuntu/Debian use service docker status. Look for active (running). If inactive, start it with systemctl start docker (CentOS) or service docker start (Ubuntu). For servers, enable auto-start on boot: systemctl enable docker.

1.2 Verify Image Availability

List local images with docker images. If the target image (e.g., nginx, mysql) is missing, pull it with a specific version tag: docker pull nginx:1.24. Avoid latest in production — version updates can introduce breaking changes; pin exact versions like nginx:1.24 or mysql:8.0.

1.3 Check Port Occupancy

Containers map internal ports to host ports (e.g., host 80 → container 80). If the host port is already used, the container fails to start. Check with netstat -tuln | grep 80. If output appears, either stop the occupying process or choose a different host port mapping.

2. Core Deployment Operations

2.1 Basic Deployment: Run Container with Essential Flags

Deploying Nginx as a typical example:

docker run -d -p 80:80 --name nginx-web --restart=always nginx:1.24

Parameter breakdown: -d: Run detached (background) so the container survives terminal closure. -p 80:80: Map host port 80 to container port 80 (format host:container). --name nginx-web: Assign a memorable name for later management ( docker stop nginx-web vs. container ID). --restart=always: Critical for production — auto-restart container on Docker daemon reboot or host reboot. nginx:1.24: Explicit version tag (not latest).

After starting, run docker ps; a STATUS of Up X minutes indicates success. Access http://<server-IP>:80 (or localhost:80 locally) to see the Nginx welcome page.

2.2 Data Persistence: Bind Mount Host Directory

Containers are ephemeral; deleting a container destroys its internal data. For stateful services (databases, uploaded files), mount a host directory into the container using -v. Example for MySQL:

# 1. Create host directory
mkdir -p /root/mysql/data
# 2. Start MySQL with volume mount and root password
docker run -d -p 3306:3306 --name mysql --restart=always \
  -v /root/mysql/data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=123456 \
  mysql:8.0

The flag -v /root/mysql/data:/var/lib/mysql binds the host path /root/mysql/data to the container's MySQL data directory /var/lib/mysql. Even if the container is removed, the data remains on the host and can be re-attached to a new container. Create the host directory first ; otherwise Docker creates it with root ownership, potentially causing permission errors inside the container.

2.3 Post-Deployment Verification

Two mandatory checks after docker ps shows Up:

Inspect logs : If a container shows Exited, run docker logs <container-name> (e.g., docker logs mysql) to diagnose startup failures (invalid password, port conflict, config errors).

Test service accessibility : Locally use localhost:<port>; on a server use <server-IP>:<port>. Successful response confirms the service is reachable.

3. Five Common Pitfalls to Avoid

Using latest tag — leads to unexpected version upgrades; always pin versions ( nginx:1.24, mysql:8.0).

Omitting --restart=always — container won't auto-recover after host or Docker restart.

Port mapping mistakes or conflicts — mismatched host/container ports or occupied ports; verify with netstat beforehand.

Skipping data persistence — deleting a database container loses all data; always use -v for stateful workloads.

Not checking logs after start — assuming Up means healthy; docker logs is the primary debugging tool.

4. Daily Container Management

Routine operations reuse basic commands:

# Stop container (before update)
docker stop <name-or-id>
# Restart container (after config change or glitch)
docker restart <name-or-id>
# Remove container (must stop first)
docker rm <name-or-id>

To upgrade an image (e.g., Nginx 1.24 → 1.25): stop and remove old container → docker pull nginx:1.25 → run new container with same -v, -p, --name, --restart flags.

5. Summary: The 3-Step Deployment Logic

Docker deployment boils down to: Check environment (daemon, image, ports) → Start correctly (detached, named, restart policy, persistence) → Verify (logs + live access). The article emphasizes practical, repeatable steps over theory, enabling beginners to move from "it runs" to "it runs reliably in production."