Docker Example

Docker Example is a collection of small, independent Docker service examples. Each service directory owns its own build.sh and start.sh so the service can be prepared, started, and managed independently.

This repository follows a compose-like idea without requiring one large compose file: every container can live in its own folder, while related containers still communicate through a shared Docker network.

Docker Network

Every example service uses the same Docker network variable in both build.sh and start.sh:

DPANEL_DOCKER_NETWORK="${DPANEL_DOCKER_NETWORK:-dpanel-network}"

If DPANEL_DOCKER_NETWORK is not set, the service keeps using dpanel-network. During build, each build.sh checks whether that network already exists and creates it when missing:

docker network inspect "${DPANEL_DOCKER_NETWORK}" >/dev/null 2>&1 || docker network create "${DPANEL_DOCKER_NETWORK}"

At runtime, each start.sh attaches the container to the same network:

docker run \
  --network "${DPANEL_DOCKER_NETWORK}" \
  ...

To move a service to another Docker network, add or update the environment variable for that service:

DPANEL_DOCKER_NETWORK=production-dpanel-network

Use the same network name for services that must communicate with each other. For example, nsqd and nsqadmin should use the same DPANEL_DOCKER_NETWORK value as nsqlookupd, and their connection variables should point to the target container alias on that network.

Changing the network name affects both the build preparation and the next container start. Rebuild or redeploy each related service after changing the variable so the network exists and all containers are attached to the same target network.

Docker Image Tag

Every example service also uses the same image tag variable in both build.sh and start.sh:

DPANEL_DOCKER_IMAGE_TAG="${DPANEL_DOCKER_IMAGE_TAG:-latest}"

Some services keep a pinned default tag instead of latest to preserve the existing example behavior. Check each service README for its default image and recommended tag.

During build, the script pulls the image with the configured tag:

docker pull "nginx:${DPANEL_DOCKER_IMAGE_TAG}"

At runtime, the script starts the same tag:

docker run \
  ...
  "nginx:${DPANEL_DOCKER_IMAGE_TAG}"

To pin or change an image tag, add or update the environment variable for that service:

DPANEL_DOCKER_IMAGE_TAG=1.27-alpine

After changing DPANEL_DOCKER_IMAGE_TAG, run build and redeploy the service so the target image tag is pulled and the container starts from that same tag.

Docker Volumes

Every example service supports custom bind mounts through DPANEL_DOCKER_VOLUMES. The default is an empty array:

DPANEL_DOCKER_VOLUMES=[]

Set the variable when a service needs persistent data, config files, logs, or host folders mounted into the container. Use a JSON-like array of host:container entries:

DPANEL_DOCKER_VOLUMES=["data:/data","log:/log"]

During build, the script creates the host-side directories when they do not exist. During start, the same entries are converted into Docker --volume arguments:

docker run \
  --volume ./data:/data \
  --volume ./log:/log \
  ...

Relative host paths such as data are treated as folders under the service working directory and are mounted as ./data. Absolute host paths are kept as provided:

DPANEL_DOCKER_VOLUMES=["/srv/nginx/html:/usr/share/nginx/html"]

Read-only and other Docker volume modes can be appended as a third segment:

DPANEL_DOCKER_VOLUMES=["config:/etc/nginx/conf.d:ro"]

The parser is intentionally small so these examples work without adding dependencies such as jq. Keep entries simple: use host:container format, avoid spaces and commas inside paths, and use bind-mount folders rather than Docker named volumes.

Service Guides

Service-specific image tags, required environment variables, ports, volumes, and deployment order belong in each service directory. Check the target service README before deploying it.

Examples:

• ClickHouse
• NSQ Lookupd
• NSQD
• NSQ Admin
• PostgreSQL
• Redis
• Uptrace
• OpenTelemetry Collector

Containers from different service directories can communicate with each other when they are attached to the same Docker network. Containers can also reach the Docker host through host.docker.internal when the Docker environment supports that host alias.