In this guide I’ll walk through why Galera needs special load balancing logic, how to set it up with HAProxy using clustercheck/xinetd health checks, and how to make the whole thing reconfigure itself automatically as nodes join, leave, or go into a non-primary state.

Why Galera Load Balancing Is Different From Regular MySQL

A standard master-replica MySQL setup usually routes writes to one master and reads to replicas. Galera is a multi-master, synchronous (virtually synchronous) cluster — every node can technically accept writes. But “can” isn’t “should”:

• Write conflicts: If you write to multiple nodes simultaneously, you increase the chance of certification conflicts and rollbacks under load.
• Flow control: A lagging node can throttle the whole cluster, so blindly balancing writes across all nodes evenly isn’t ideal.
• Node state matters: A node can be Synced, Donor/Desynced, or Joining. Sending traffic to a Joining node means talking to a node with stale or incomplete data.

The standard pattern is: send all writes to a single node at a time (or a small write pool), and distribute reads across all healthy, synced nodes. The load balancer needs to know, in near real time, which nodes are actually fit to serve traffic.

Architecture Overview

                +----------------+
   Clients ---> |    HAProxy     |
                +----------------+
                 |      |      |
             node1   node2   node3
            (Galera) (Galera) (Galera)

HAProxy polls each node’s health-check port. That port is served by clustercheck, a small script that queries wsrep_local_state and returns HTTP 200 (healthy) or 503 (unhealthy) accordingly. This is what makes the balancing “dynamic” — HAProxy doesn’t need a static list of “good” nodes; it discovers node health continuously.

Step 1: Install clustercheck on Each Galera Node

clustercheck ships with Percona XtraDB Cluster and MariaDB Galera packages. If you’re using it standalone:

# On each Galera node
sudo apt-get install -y percona-xtradb-cluster-client xinetd

Create a MySQL user the health check can use:

CREATE USER 'clustercheckuser'@'localhost' IDENTIFIED BY 'ClusterCheckPassword123!';
GRANT PROCESS ON *.* TO 'clustercheckuser'@'localhost';
FLUSH PRIVILEGES;

Edit /etc/sysconfig/clustercheck (or /etc/default/clustercheck on Debian-based systems):

MYSQL_USERNAME="clustercheckuser"
MYSQL_PASSWORD="ClusterCheckPassword123!"
MYSQL_HOST="localhost"
MYSQL_PORT="3306"
AVAILABLE_WHEN_DONOR=0
AVAILABLE_WHEN_READONLY=1
AVAILABLE_WHEN_DONOR_IS_MASTER=0

AVAILABLE_WHEN_DONOR=0 is important — you generally don’t want a node acting as an SST/IST donor to also be taking production traffic, since it’s under extra load and possibly desynced.

Configure xinetd to expose this as an HTTP-style health check on port 9200:

cat <<'EOF' | sudo tee /etc/xinetd.d/mysqlchk
service mysqlchk
{
  disable         = no
  flags           = REUSE
  socket_type     = stream
  port            = 9200
  wait            = no
  user            = nobody
  server          = /usr/bin/clustercheck
  log_on_failure  += USERID
  only_from       = 0.0.0.0/0
  per_source      = UNLIMITED
}
EOF

sudo systemctl restart xinetd
sudo systemctl enable xinetd

Test it locally:

curl -i http://localhost:9200/

Expected output for a healthy, synced node:

HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Content-Length: 40

Percona XtraDB Cluster Node is synced.

An unhealthy node returns HTTP/1.1 503 Service Unavailable.

Step 2: Configure HAProxy for Dynamic Health-Based Routing

Install HAProxy on your load balancer host:

sudo apt-get install -y haproxy

/etc/haproxy/haproxy.cfg:

global
    log /dev/log local0
    maxconn 4096

defaults
    log     global
    mode    tcp
    option  tcplog
    timeout connect 5s
    timeout client  30s
    timeout server  30s
    retries 3

# Write traffic: single active node, automatic failover
frontend galera_write_front
    bind *:3307
    default_backend galera_write_back

backend galera_write_back
    option httpchk
    http-check expect status 200
    default-server port 9200 inter 2s fall 3 rise 2
    server node1 10.0.0.11:3306 check
    server node2 10.0.0.12:3306 check backup
    server node3 10.0.0.13:3306 check backup

# Read traffic: distributed across all synced nodes
frontend galera_read_front
    bind *:3308
    default_backend galera_read_back

backend galera_read_back
    balance leastconn
    option httpchk
    http-check expect status 200
    default-server port 9200 inter 2s fall 3 rise 2
    server node1 10.0.0.11:3306 check
    server node2 10.0.0.12:3306 check
    server node3 10.0.0.13:3306 check

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 5s

What’s happening here:

• Write backend: node1 is primary; node2 and node3 are backup, only receiving traffic if node1 fails its health check. This avoids multi-node write conflicts.
• Read backend: balance leastconn spreads read connections across whichever nodes are currently passing the clustercheck health probe.
• inter 2s fall 3 rise 2 means HAProxy checks every 2 seconds, marks a server down after 3 consecutive failures, and marks it back up after 2 consecutive successes — this is the “dynamic” part: no manual intervention needed when a node drops or rejoins.

Reload HAProxy after any config change:

sudo systemctl reload haproxy

Verify with the built-in stats page at http://<lb-ip>:8404/stats — you’ll see live UP/DOWN status per backend server.

Step 3: Simulate a Failover to Prove It’s Dynamic

Stop MySQL on the current write-primary:

# on node1
sudo systemctl stop mysql

Within a few seconds, curl http://node1:9200/ will return connection refused, HAProxy will mark node1 down, and traffic on port 3307 will automatically shift to node2 (the next available backup server) — no config reload needed.

Check HAProxy logs to confirm:

sudo tail -f /var/log/haproxy.log

Expected output snippet:

Server galera_write_back/node1 is DOWN, reason: Layer4 connection problem
Server galera_write_back/node2 is UP

Bring node1 back and let Galera perform IST/SST to resync it — once clustercheck reports 200 again, HAProxy will automatically re-add it to the pool.

Alternative: ProxySQL for Smarter Query-Aware Routing

HAProxy operates at TCP/HTTP-check level and doesn’t understand SQL. For more advanced routing (query splitting, read/write splitting based on query pattern, connection multiplexing), ProxySQL is the more common modern choice for Galera:

docker run -d --name proxysql \
  -p 6033:6033 -p 6032:6032 \
  -v proxysql-data:/var/lib/proxysql \
  proxysql/proxysql:latest

ProxySQL maintains a mysql_galera_hostgroups table that natively understands wsrep_local_state, so it can dynamically detect donor/joining/synced states without needing an external xinetd health-check port at all. If you’re building a new deployment, it’s worth evaluating instead of HAProxy — but HAProxy remains the simpler, more transparent, and widely documented option, which is why it’s the default in most tutorials.

Security Considerations

• Restrict the clustercheck health-check port (9200) to only the load balancer’s IP using firewall rules (ufw, iptables, or security groups) — don’t expose it publicly.
• Use a dedicated, minimally privileged MySQL user for health checks (PROCESS privilege only, no data access).
• Terminate TLS at HAProxy if clients connect over the internet, and use sslmode=require (or stricter) for the backend MySQL connections if they traverse untrusted networks.
• Keep the HAProxy stats page behind authentication:

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:StrongAdminPassword123!

Monitoring and Troubleshooting

For ongoing monitoring, feed HAProxy’s stats socket into Prometheus using the haproxy_exporter, and track wsrep_cluster_size, wsrep_local_state, and wsrep_flow_control_paused from each node via mysqld_exporter for Galera-specific metrics.

Real-World Deployment Notes

In practice, I’ve found the single-writer pattern shown above works well for most OLTP workloads under moderate write volume, but it does concentrate write load on one box. For higher write throughput, some teams route writes to all three nodes and accept occasional certification-conflict rollbacks at the application layer (with retry logic on deadlock/conflict errors), trading a bit of complexity for horizontal write scaling. Whichever pattern you pick, keep the health-check interval tight enough to fail over quickly but not so tight that transient network blips cause flapping — 2 seconds with a 3-strike fall threshold has been a reliable middle ground across the clusters I’ve run. It’s also worth putting HAProxy itself behind Keepalived or a cloud load balancer with a floating VIP, so the load balancer isn’t a new single point of failure sitting in front of a cluster you built specifically to avoid single points of failure.

Summary

Dynamically load balancing a Galera cluster comes down to one core idea: never route traffic based on a static assumption of node health. By exposing wsrep_local_state through a lightweight clustercheck HTTP endpoint and letting HAProxy poll it continuously, your load balancer reacts to real cluster state — donor nodes get excluded from traffic, failed nodes get removed within seconds, and recovered nodes get automatically re-added. Combine that with a single-writer, multi-reader traffic split and you get a setup that survives node failures without a 2am page.

References

• Galera Cluster Documentation
• Percona XtraDB Cluster – clustercheck
• HAProxy Configuration Manual
• ProxySQL Documentation
• MariaDB Galera Cluster Docs

The post How to Dynamically Configure a Load Balancer for a MySQL Galera Cluster: Complete Guide appeared first on Abdul Wahab Junaid.

What You’ll Need to Understand First

Before touching Docker, it helps to know what makes Galera different from vanilla MySQL replication:

• Synchronous multi-master replication: every node in the cluster certifies transactions before committing, using the Write-Set Replication (wsrep) API.
• Cluster bootstrap: the very first node must be started with --wsrep-new-cluster (or wsrep_cluster_address=gcomm://), because it has nothing to join. Every subsequent node joins by pointing at existing members.
• State Snapshot Transfer (SST): when a new node joins, it needs a full copy of the dataset. This typically happens via mariabackup/xtrabackup (physical) or mysqldump (logical).
• Quorum: Galera needs an odd number of nodes (3, 5, …) to avoid split-brain — with only 2 nodes, a single node failure can’t determine if it’s the majority.

In Docker terms, this means node startup order matters, and each node needs a stable, resolvable hostname — which is exactly what a user-defined Docker network gives you via Docker’s embedded DNS.

Step 1: Create a User-Defined Docker Network

Docker’s default bridge network doesn’t provide automatic DNS resolution between containers by name — a user-defined network does. This is the foundation the whole cluster depends on.

docker network create --driver bridge galera-net

Verify:

docker network inspect galera-net

Expected output (trimmed):

[
    {
        "Name": "galera-net",
        "Driver": "bridge",
        "IPAM": {
            "Config": [{"Subnet": "172.20.0.0/16"}]
        },
        "Containers": {}
    }
]

Step 2: Create Persistent Volumes for Each Node

Never rely on container-internal storage for database data — a container recreation will wipe it. Create a named volume per node:

docker volume create galera-node1-data
docker volume create galera-node2-data
docker volume create galera-node3-data

Step 3: Write a Shared Galera Configuration File

Create a local directory with a galera.cnf that all three nodes will mount:

mkdir -p ~/galera-cluster/conf

~/galera-cluster/conf/galera.cnf:

[mysqld]
binlog_format=ROW
default-storage-engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="docker_galera_cluster"
wsrep_cluster_address="gcomm://galera-node1,galera-node2,galera-node3"
wsrep_sst_method=mariabackup
wsrep_sst_auth="sstuser:SstPassword123!"

Note the wsrep_cluster_address uses the container names — this works because Docker’s embedded DNS resolves them automatically inside galera-net.

Step 4: Start Node 1 — Bootstrap the Cluster

The first node has no cluster to join, so it starts a brand-new one:

docker run -d \
  --name galera-node1 \
  --network galera-net \
  --hostname galera-node1 \
  -e MYSQL_ROOT_PASSWORD=RootPassword123! \
  -v galera-node1-data:/var/lib/mysql \
  -v ~/galera-cluster/conf/galera.cnf:/etc/mysql/conf.d/galera.cnf \
  -p 3306:3306 \
  mariadb:11.4 \
  --wsrep-new-cluster

Check that it started cleanly:

docker logs -f galera-node1

Expected output includes:

[Note] WSREP: Synchronized with group, ready for connections
[Note] mariadbd: ready for connections.

Create the SST user (required for future nodes to sync from this one):

docker exec -it galera-node1 mariadb -uroot -pRootPassword123! -e \
  "CREATE USER 'sstuser'@'%' IDENTIFIED BY 'SstPassword123!'; \
   GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'sstuser'@'%'; \
   FLUSH PRIVILEGES;"

Step 5: Start Nodes 2 and 3 — Join the Cluster

These nodes join normally (no --wsrep-new-cluster flag):

docker run -d \
  --name galera-node2 \
  --network galera-net \
  --hostname galera-node2 \
  -e MYSQL_ROOT_PASSWORD=RootPassword123! \
  -v galera-node2-data:/var/lib/mysql \
  -v ~/galera-cluster/conf/galera.cnf:/etc/mysql/conf.d/galera.cnf \
  mariadb:11.4

docker run -d \
  --name galera-node3 \
  --network galera-net \
  --hostname galera-node3 \
  -e MYSQL_ROOT_PASSWORD=RootPassword123! \
  -v galera-node3-data:/var/lib/mysql \
  -v ~/galera-cluster/conf/galera.cnf:/etc/mysql/conf.d/galera.cnf \
  mariadb:11.4

Watch node2 perform its SST:

docker logs -f galera-node2

Expected output:

[Note] WSREP: State transfer required: Group state: ..., Local state: ...
[Note] WSREP: Requesting state transfer: success
[Note] WSREP: SST complete, seqno: X
[Note] mariadbd: ready for connections.

Step 6: Verify Cluster Membership

From any node:

docker exec -it galera-node1 mariadb -uroot -pRootPassword123! -e \
  "SHOW STATUS LIKE 'wsrep_cluster_size'; SHOW STATUS LIKE 'wsrep_local_state_comment';"

Expected output:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+
+----------------------------+--------+
| Variable_name              | Value  |
+----------------------------+--------+
| wsrep_local_state_comment  | Synced |
+----------------------------+--------+

Test replication by writing to node1 and reading from node3:

docker exec -it galera-node1 mariadb -uroot -pRootPassword123! -e \
  "CREATE DATABASE testdb; USE testdb; CREATE TABLE t1 (id INT PRIMARY KEY); INSERT INTO t1 VALUES (1);"

docker exec -it galera-node3 mariadb -uroot -pRootPassword123! -e \
  "SELECT * FROM testdb.t1;"

Expected output on node3:

+----+
| id |
+----+
|  1 |
+----+

If that row appears on node3 instantly, replication across the Docker network is working.

Doing It the Right Way: Docker Compose

Manually running three docker run commands doesn’t scale for real environments. Here’s the same cluster as a Compose file:

# docker-compose.yml
version: "3.8"

networks:
  galera-net:
    driver: bridge

volumes:
  node1-data:
  node2-data:
  node3-data:

services:
  galera-node1:
    image: mariadb:11.4
    container_name: galera-node1
    hostname: galera-node1
    networks:
      - galera-net
    environment:
      MYSQL_ROOT_PASSWORD: RootPassword123!
    volumes:
      - node1-data:/var/lib/mysql
      - ./conf/galera.cnf:/etc/mysql/conf.d/galera.cnf
    command: ["--wsrep-new-cluster"]
    ports:
      - "3306:3306"

  galera-node2:
    image: mariadb:11.4
    container_name: galera-node2
    hostname: galera-node2
    networks:
      - galera-net
    environment:
      MYSQL_ROOT_PASSWORD: RootPassword123!
    volumes:
      - node2-data:/var/lib/mysql
      - ./conf/galera.cnf:/etc/mysql/conf.d/galera.cnf
    depends_on:
      - galera-node1

  galera-node3:
    image: mariadb:11.4
    container_name: galera-node3
    hostname: galera-node3
    networks:
      - galera-net
    environment:
      MYSQL_ROOT_PASSWORD: RootPassword123!
    volumes:
      - node3-data:/var/lib/mysql
      - ./conf/galera.cnf:/etc/mysql/conf.d/galera.cnf
    depends_on:
      - galera-node1

Important caveat: depends_on only waits for the container to start, not for MySQL/Galera to be ready. In production Compose or Swarm setups, add a healthcheck and condition: service_healthy:

    healthcheck:
      test: ["CMD", "mariadb-admin", "ping", "-uroot", "-pRootPassword123!"]
      interval: 5s
      timeout: 5s
      retries: 10

Bring it up:

docker compose up -d
docker compose logs -f

Internal Architecture: What’s Actually Happening on the Network

Each container gets its own network namespace on galera-net, with an internal IP in the subnet Docker assigned (e.g., 172.20.0.2). Docker runs an embedded DNS server at 127.0.0.11 inside each container, which resolves galera-node1, galera-node2, galera-node3 to those internal IPs — this is what lets wsrep_cluster_address use hostnames instead of hardcoded IPs, which would break every time you recreate the containers.

Galera itself uses several ports:

• 3306: standard MySQL client connections
• 4567: Galera Cluster replication traffic (gcomm)
• 4568: Incremental State Transfer (IST)
• 4444: State Snapshot Transfer (SST)

All of these need to be reachable between containers (handled automatically by the bridge network) but generally should not be exposed to the host/public internet except 3306, and even that ideally only through your load balancer.

Storage and Data Persistence

Named volumes (galera-node1-data, etc.) live under /var/lib/docker/volumes/ on the host and persist independently of container lifecycle. This means you can docker compose down and docker compose up -d again without losing data — but be careful: docker compose down -v deletes volumes, which will destroy your cluster’s data permanently. Always back up before running destructive commands.

Security Best Practices

• Never bake passwords into the image; use environment variables or Docker secrets (docker secret create in Swarm mode).
• Restrict the SST user’s grants to only what’s required (RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT), not ALL PRIVILEGES.
• Don’t expose ports 4567/4568/4444 outside the Docker network — only container-to-container traffic needs them.
• Use docker network create --internal galera-net if you want a fully isolated network with no external routing, and put a reverse proxy/load balancer container on a second, external-facing network instead.

Troubleshooting

Real-World Deployment Notes

For anything beyond local testing, I’d strongly recommend running each Galera node on a separate host with Docker installed, connected via an overlay network (Docker Swarm mode or a CNI-based setup) rather than three containers on one machine — colocating all three nodes on a single host defeats the fault-tolerance purpose of Galera entirely, since one host failure takes down the whole cluster. In Swarm mode, docker network create --driver overlay --attachable galera-net gives you the same hostname-resolution behavior across hosts that the single-host bridge network gives you locally. I’ve also found it worth pinning exact image digests (not just mariadb:11.4) in any environment where reproducibility matters, since a silent minor-version bump across node restarts can occasionally introduce subtle SST incompatibilities between nodes running different patch versions.

Summary

Running Galera in Docker isn’t fundamentally different from running it on bare metal — the wsrep protocol doesn’t care what’s hosting it — but Docker’s networking model changes how nodes discover each other, and container lifecycle changes how you think about data persistence. Get the user-defined network, named volumes, and bootstrap ordering right, and the rest is standard Galera administration.

References

• Docker Networking Overview
• Galera Cluster Documentation
• MariaDB Official Docker Image
• Docker Compose File Reference
• MariaDB Galera Cluster Deployment Guide

The post How to Build a MySQL Galera Cluster on a Docker Network: Step-by-Step Setup Guide appeared first on Abdul Wahab Junaid.

The Architecture

                     +-------------------+
   S3 clients  --->  |  Gateway (API)    |
  (aws-cli, SDKs)     |  S3-compatible    |
                     +-------------------+
                        |            |
                 +-------------+  +----------------+
                 |  Cassandra  |  | Object chunks   |
                 | (metadata + |  | (stored as blobs|
                 |  small obj) |  |  in Cassandra   |
                 +-------------+  |  blob tables)   |
                                  +----------------+
                     All running as StatefulSets/Deployments in Kubernetes

We’ll deploy:

1. A Cassandra StatefulSet (3 nodes) for metadata and object-chunk storage.
2. A lightweight S3 gateway service that translates S3 REST calls into Cassandra reads/writes (implemented conceptually — I’ll show the CQL schema and a minimal Node.js gateway you can extend).
3. Kubernetes networking (headless Service for Cassandra gossip, ClusterIP for the gateway, Ingress for external S3 access).

If you want a production-grade, fully S3-compliant system without building the gateway yourself, the honest recommendation is MinIO or Ceph RGW — I’ll note that in best practices below. But if your goal is specifically “S3-compatible API in front of Cassandra-backed storage” (common in multi-region, tunable-consistency use cases), here’s how it’s built.

Step 1: Namespace and Storage Class

kubectl create namespace object-store

Confirm you have a StorageClass that supports dynamic provisioning (cloud environments usually do by default):

kubectl get storageclass

Expected output (varies by provider):

NAME                 PROVISIONER             RECLAIMPOLICY
standard (default)   kubernetes.io/gce-pd     Delete

Step 2: Headless Service for Cassandra Gossip

Cassandra nodes discover each other via gossip, which requires stable network identities — a headless Service (clusterIP: None) gives each pod a predictable DNS name.

# cassandra-headless-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: cassandra
  namespace: object-store
  labels:
    app: cassandra
spec:
  clusterIP: None
  ports:
    - port: 7000
      name: intra-node
    - port: 7001
      name: tls-intra-node
    - port: 7199
      name: jmx
    - port: 9042
      name: cql
  selector:
    app: cassandra

kubectl apply -f cassandra-headless-svc.yaml

Step 3: Cassandra StatefulSet

# cassandra-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cassandra
  namespace: object-store
spec:
  serviceName: cassandra
  replicas: 3
  selector:
    matchLabels:
      app: cassandra
  template:
    metadata:
      labels:
        app: cassandra
    spec:
      terminationGracePeriodSeconds: 1800
      containers:
        - name: cassandra
          image: cassandra:5.0
          ports:
            - containerPort: 7000
              name: intra-node
            - containerPort: 7199
              name: jmx
            - containerPort: 9042
              name: cql
          resources:
            requests:
              cpu: "1"
              memory: 2Gi
            limits:
              cpu: "2"
              memory: 4Gi
          env:
            - name: CASSANDRA_SEEDS
              value: "cassandra-0.cassandra.object-store.svc.cluster.local"
            - name: CASSANDRA_CLUSTER_NAME
              value: "ObjectStoreCluster"
            - name: CASSANDRA_DC
              value: "dc1"
            - name: CASSANDRA_RACK
              value: "rack1"
            - name: CASSANDRA_ENDPOINT_SNITCH
              value: "GossipingPropertyFileSnitch"
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          readinessProbe:
            exec:
              command: ["/bin/bash", "-c", "nodetool status | grep -E \"^UN\\s+${POD_IP}\""]
            initialDelaySeconds: 60
            periodSeconds: 15
          volumeMounts:
            - name: cassandra-data
              mountPath: /var/lib/cassandra
  volumeClaimTemplates:
    - metadata:
        name: cassandra-data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 20Gi

kubectl apply -f cassandra-statefulset.yaml
kubectl get pods -n object-store -w

Expected output as nodes come up one by one (StatefulSets deploy sequentially):

NAME          READY   STATUS    RESTARTS   AGE
cassandra-0   1/1     Running   0          2m
cassandra-1   1/1     Running   0          90s
cassandra-2   1/1     Running   0          40s

Verify cluster formation:

kubectl exec -it cassandra-0 -n object-store -- nodetool status

Expected output:

Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load      Tokens  Owns   Host ID   Rack
UN  10.244.1.5   115 KiB   16      33.4%  ...       rack1
UN  10.244.2.7   102 KiB   16      33.3%  ...       rack1
UN  10.244.3.9   98 KiB    16      33.3%  ...       rack1

UN means Up/Normal — all three nodes are healthy and joined.

Step 4: Schema for Object Storage

Connect via cqlsh:

kubectl exec -it cassandra-0 -n object-store -- cqlsh

CREATE KEYSPACE object_store
WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': 3};

USE object_store;

CREATE TABLE buckets (
    bucket_name text PRIMARY KEY,
    created_at timestamp,
    owner text
);

CREATE TABLE objects (
    bucket_name text,
    object_key text,
    version_id timeuuid,
    size bigint,
    etag text,
    content_type text,
    created_at timestamp,
    chunk_count int,
    PRIMARY KEY ((bucket_name), object_key, version_id)
) WITH CLUSTERING ORDER BY (object_key ASC, version_id DESC);

CREATE TABLE object_chunks (
    bucket_name text,
    object_key text,
    version_id timeuuid,
    chunk_index int,
    data blob,
    PRIMARY KEY ((bucket_name, object_key, version_id), chunk_index)
);

Design notes: objects are split into chunks (e.g., 1MB each) and stored as blob rows rather than one giant row, because Cassandra performs poorly with very large single cells/partitions. The objects table holds metadata; object_chunks holds the payload, partitioned so retrieval streams chunk-by-chunk.

Step 5: Minimal S3-Compatible Gateway (Deployment)

A trimmed example gateway (Node.js + Express + cassandra-driver) exposing PUT/GET for objects, mapped to basic S3 REST semantics:

// gateway/index.js
const express = require("express");
const cassandra = require("cassandra-driver");
const { v1: uuidv1 } = require("uuid");

const client = new cassandra.Client({
  contactPoints: ["cassandra-0.cassandra.object-store.svc.cluster.local"],
  localDataCenter: "dc1",
  keyspace: "object_store",
});

const app = express();
const CHUNK_SIZE = 1024 * 1024;

app.put("/:bucket/:key", express.raw({ type: "*/*", limit: "5gb" }), async (req, res) => {
  const { bucket, key } = req.params;
  const versionId = uuidv1();
  const data = req.body;
  const chunks = Math.ceil(data.length / CHUNK_SIZE);

  for (let i = 0; i < chunks; i++) {
    const chunk = data.slice(i * CHUNK_SIZE, (i + 1) * CHUNK_SIZE);
    await client.execute(
      "INSERT INTO object_chunks (bucket_name, object_key, version_id, chunk_index, data) VALUES (?, ?, ?, ?, ?)",
      [bucket, key, versionId, i, chunk],
      { prepare: true }
    );
  }

  await client.execute(
    "INSERT INTO objects (bucket_name, object_key, version_id, size, chunk_count, created_at) VALUES (?, ?, ?, ?, ?, toTimestamp(now()))",
    [bucket, key, versionId, data.length, chunks],
    { prepare: true }
  );

  res.set("ETag", versionId.toString()).status(200).end();
});

app.get("/:bucket/:key", async (req, res) => {
  const { bucket, key } = req.params;
  const meta = await client.execute(
    "SELECT * FROM objects WHERE bucket_name = ? AND object_key = ? LIMIT 1",
    [bucket, key],
    { prepare: true }
  );
  if (meta.rowLength === 0) return res.status(404).end();

  const row = meta.first();
  for (let i = 0; i < row.chunk_count; i++) {
    const chunkRes = await client.execute(
      "SELECT data FROM object_chunks WHERE bucket_name = ? AND object_key = ? AND version_id = ? AND chunk_index = ?",
      [bucket, key, row.version_id, i],
      { prepare: true }
    );
    res.write(chunkRes.first().data);
  }
  res.end();
});

app.listen(8080, () => console.log("S3 gateway listening on 8080"));

Dockerfile:

FROM node:20-slim
WORKDIR /app
COPY package.json .
RUN npm install --production
COPY index.js .
EXPOSE 8080
CMD ["node", "index.js"]

Build and push:

docker build -t your-registry/s3-cassandra-gateway:1.0 ./gateway
docker push your-registry/s3-cassandra-gateway:1.0

Deployment manifest:

# gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: s3-gateway
  namespace: object-store
spec:
  replicas: 2
  selector:
    matchLabels:
      app: s3-gateway
  template:
    metadata:
      labels:
        app: s3-gateway
    spec:
      containers:
        - name: s3-gateway
          image: your-registry/s3-cassandra-gateway:1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: 256Mi
            limits:
              cpu: "500m"
              memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  name: s3-gateway
  namespace: object-store
spec:
  selector:
    app: s3-gateway
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

kubectl apply -f gateway-deployment.yaml

Expose externally with an Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: s3-gateway-ingress
  namespace: object-store
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "5g"
spec:
  ingressClassName: nginx
  rules:
    - host: s3.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: s3-gateway
                port:
                  number: 80

Step 6: Test With a Standard S3 Client

kubectl port-forward svc/s3-gateway -n object-store 8080:80

curl -X PUT --data-binary @localfile.txt http://localhost:8080/my-bucket/localfile.txt
curl http://localhost:8080/my-bucket/localfile.txt -o downloaded.txt
diff localfile.txt downloaded.txt

Expected: diff returns nothing, confirming round-trip integrity.

Internals: Why This Works (and Where It Strains)

Cassandra’s NetworkTopologyStrategy with RF=3 gives you the same durability model S3 relies on internally — every chunk is written to 3 nodes across the ring before being acknowledged (tunable via consistency level, e.g. LOCAL_QUORUM). Partitioning chunks by (bucket, key, version_id) spreads large objects across the cluster instead of hammering one node with a giant blob.

Where this genuinely strains compared to purpose-built object stores like MinIO or Ceph: Cassandra wasn’t designed for large binary blobs, and very large objects (multi-GB) will pressure compaction and heap usage. In practice, teams doing this successfully cap object size, tune compaction throughput, and often route only metadata and small objects through Cassandra while large blobs go to a separate blob store — a hybrid model.

Security

• Enable Cassandra internode and client-to-node TLS via cassandra.yaml (server_encryption_options, client_encryption_options) — don’t run gossip traffic unencrypted across namespaces.
• Use Kubernetes NetworkPolicy to restrict which pods can reach Cassandra’s CQL port (9042):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cassandra-allow-gateway-only
  namespace: object-store
spec:
  podSelector:
    matchLabels:
      app: cassandra
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: s3-gateway
      ports:
        - port: 9042

• Store the gateway’s Cassandra credentials in a Kubernetes Secret, not plaintext env vars in the manifest.
• Add authentication (SigV4 or a simpler bearer token scheme) to the gateway before exposing it publicly — the example above has none, intentionally, to keep the code focused on the storage mechanics.

Monitoring and Troubleshooting

Deploy cassandra-exporter or JMX-to-Prometheus exporters as a sidecar for cluster-level metrics (pending compactions, read/write latency, heap usage), and scrape gateway request metrics via a /metrics endpoint for Prometheus + Grafana dashboards.

Summary

Cassandra doesn’t give you S3 out of the box, but its distributed, replicated, partition-tolerant design makes it a solid metadata and chunk-storage backend when you build an S3-compatible API layer on top — especially in Kubernetes, where StatefulSets and headless Services handle the hard parts of stable node identity and gossip discovery for you. For most production object-storage needs, evaluate MinIO or Ceph RGW first; reach for this Cassandra-backed pattern when you specifically need Cassandra’s tunable consistency and multi-datacenter replication model married to an S3-shaped API.

References

• Apache Cassandra Documentation
• Kubernetes StatefulSets
• Kubernetes Headless Services
• Kubernetes NetworkPolicy
• Amazon S3 API Reference
• MinIO Documentation (for a purpose-built alternative)

The post How to Build an S3-Compatible Object Store with Cassandra on Kubernetes: Complete Guide appeared first on Abdul Wahab Junaid.

What Logspout Actually Does

Logspout is not a log storage system — it’s a router. It:

1. Connects to the Docker daemon’s Unix socket (/var/run/docker.sock).
2. Discovers all running containers and attaches to their log streams (the same stream docker logs reads from).
3. Watches for new containers starting/stopping and attaches/detaches dynamically — no restart needed.
4. Forwards each log line, tagged with container metadata, to one or more configured destinations (“routes”).

Because it reads directly from the Docker log driver, it works with any container without requiring you to modify application code to log to a specific place.

Prerequisites

• Docker Engine installed and running.
• Root or a user in the docker group (Logspout needs access to /var/run/docker.sock).

Check your Docker version:

docker version --format '{{.Server.Version}}'

Step 1: Run Logspout With a Basic Route

The simplest setup forwards all container logs to a syslog endpoint. Let’s start with an actual syslog server for testing — papertrail-style or a local syslog-ng container works, but for a first test we’ll just print to a local UDP listener.

docker run -d --name logspout \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  --publish=127.0.0.1:8000:80 \
  gliderlabs/logspout

This starts Logspout with its HTTP API exposed on port 8000 (useful for live-tailing without a destination configured yet).

Verify it’s running:

docker ps --filter name=logspout

Expected output:

CONTAINER ID   IMAGE                  STATUS         PORTS                      NAMES
a1b2c3d4e5f6   gliderlabs/logspout    Up 5 seconds   0.0.0.0:8000->80/tcp      logspout

Step 2: Live-Tail All Container Logs Over HTTP

Logspout exposes a /logs streaming endpoint out of the box:

curl http://127.0.0.1:8000/logs

Start another container to generate some log output:

docker run -d --name test-app alpine sh -c "while true; do echo 'hello from test-app'; sleep 2; done"

Back in your curl terminal, expected output:

test-app|hello from test-app
test-app|hello from test-app

This confirms Logspout picked up the new container automatically — no configuration change or restart required, which is the core value proposition versus manually configuring log shipping per container.

Step 3: Route Logs to Syslog (Real Aggregation)

Most production setups forward to a centralized syslog receiver, Logstash, or a managed log service. The route is passed as a command argument using the syslog:// scheme:

docker run -d --name logspout \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  gliderlabs/logspout \
  syslog://logs.example.com:514

For local testing, stand up a syslog receiver container:

docker run -d --name syslog-server -p 514:514/udp balabit/syslog-ng:latest

Then point Logspout at it via the Docker network (assuming both are on the same user-defined network, logging-net):

docker network create logging-net

docker run -d --name syslog-server \
  --network logging-net \
  -p 514:514/udp \
  balabit/syslog-ng:latest

docker run -d --name logspout \
  --network logging-net \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  gliderlabs/logspout \
  syslog://syslog-server:514

Step 4: Filter Which Containers/Logs Get Shipped

By default Logspout ships stdout+stderr from every container, including itself. You almost always want to exclude some containers (e.g., the log shipper itself, or noisy health-check sidecars). Use environment variables or route-level filters:

docker run -d --name logspout \
  --network logging-net \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  -e EXCLUDE_LABEL=logspout.exclude \
  gliderlabs/logspout \
  syslog://syslog-server:514

Then label containers you want excluded:

docker run -d --name noisy-healthcheck \
  --label logspout.exclude=true \
  alpine sh -c "while true; do echo ping; sleep 1; done"

You can also filter by source stream:

gliderlabs/logspout syslog://syslog-server:514?filter.sources=stdout

This ships only stdout, excluding stderr — useful if you route error logs somewhere different.

Step 5: Route to Multiple Destinations at Once

Logspout supports multiple simultaneous routes, comma-separated:

docker run -d --name logspout \
  --network logging-net \
  --volume=/var/run/docker.sock:/var/run/docker.sock \
  gliderlabs/logspout \
  syslog://syslog-server:514,http://logstash.example.com:8080

This is useful during a migration — ship to your old syslog target and a new ELK pipeline simultaneously while you validate the new one.

Step 6: Docker Compose Setup for a Real Stack

A realistic logging stack pairs Logspout with Logstash/Elasticsearch/Kibana (the classic ELK approach) or a lighter Loki-based stack. Here’s Logspout feeding Logstash:

# docker-compose.yml
version: "3.8"

networks:
  logging-net:
    driver: bridge

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.14.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
    networks:
      - logging-net
    ports:
      - "9200:9200"

  logstash:
    image: docker.elastic.co/logstash/logstash:8.14.0
    volumes:
      - ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf
    networks:
      - logging-net
    depends_on:
      - elasticsearch
    ports:
      - "5000:5000"

  kibana:
    image: docker.elastic.co/kibana/kibana:8.14.0
    networks:
      - logging-net
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

  logspout:
    image: gliderlabs/logspout
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - logging-net
    command: logstash://logstash:5000
    depends_on:
      - logstash

  app:
    image: nginx:alpine
    networks:
      - logging-net

logstash.conf:

input {
  tcp {
    port => 5000
    codec => json_lines
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "docker-logs-%{+YYYY.MM.dd}"
  }
}

docker compose up -d

After a minute, check that logs landed in Elasticsearch:

curl -s http://localhost:9200/_cat/indices?v

Expected output:

health status index                  uuid    pri rep docs.count
yellow open   docker-logs-2026.07.29 xxxxxx  1   1   142

Open Kibana at http://localhost:5601 and create a data view over docker-logs-* to search and visualize.

How Logspout Works Internally

Under the hood, Logspout uses the Docker Engine API’s container attach/logs endpoint with follow=true, which streams multiplexed stdout/stderr frames over the socket connection. Docker’s log driver framing includes a stream-type byte (stdout vs stderr) and a length-prefixed payload — Logspout demultiplexes this, attaches container metadata (name, ID, image, labels), and hands each line off to whichever output adapter matches your configured route scheme (syslog://, http://, logstash://, or a custom Go adapter you register at build time).

Because it uses the logs API rather than reading log files directly, it works regardless of which logging driver the container itself is configured with (json-file, local, etc.), as long as that driver supports the read-back API — note that drivers like none or some remote-only drivers won’t have anything for Logspout to read.

Security Considerations

• Docker socket access is root-equivalent. Mounting /var/run/docker.sock into Logspout gives it the same power as root on the host. Only run trusted, pinned images (use a specific tag/digest, not latest, in production), and don’t expose Logspout’s HTTP API (8000) publicly.
• Encrypt log transport in production — plain syslog:// over UDP is unauthenticated and unencrypted; use syslog+tls:// where supported, or route through a TLS-terminating aggregator.
• Scrub sensitive data (tokens, PII) at the application log-emission level — Logspout ships whatever containers print; it does not redact.

Troubleshooting

Check Logspout’s own logs for adapter errors:

docker logs logspout --tail 50

Real-World Deployment Notes

I’ve run Logspout as a single instance per host in a multi-host fleet, each one shipping to a shared aggregation cluster rather than trying to centralize the shipper itself — it’s stateless, so there’s no coordination needed between instances on different hosts. One thing worth planning for early: log volume grows faster than people expect once every container is shipping unfiltered stdout/stderr, so set up index/retention policies on your Elasticsearch (or equivalent) cluster from day one rather than after a disk-full incident. If you’re on Kubernetes rather than plain Docker hosts, Logspout isn’t the typical choice — Fluent Bit or Vector as a DaemonSet is more common there, since they integrate more natively with the Kubernetes API for pod metadata enrichment. Logspout shines specifically in plain Docker/Compose/Swarm environments where you don’t already have a Kubernetes-native logging pipeline.

Summary

Logspout earns its place in a Docker logging stack by doing one thing well: dynamically discovering containers and routing their log streams without requiring per-container configuration. It’s not a replacement for a full observability stack — you still need something to store, index, and query logs (ELK, Loki, a SaaS platform) — but as the collection layer, it removes the operational burden of manually wiring log shipping into every container you run.

References

• Logspout GitHub Repository
• Docker Engine API — Container Logs
• Docker Logging Drivers
• Elastic Logstash Documentation

The post How to Use Logspout to Collect Container Logs: Centralized Docker Logging Setup appeared first on Abdul Wahab Junaid.

The Basics

docker logs <container_name_or_id>

Example — start a container that emits output on a loop:

docker run -d --name demo-app alpine sh -c "i=0; while true; do echo \"log line \$i\"; i=\$((i+1)); sleep 1; done"

Fetch its logs:

docker logs demo-app

Expected output:

log line 0
log line 1
log line 2
...

Following Logs in Real Time

Add -f (or --follow) to stream new log lines as they’re written, similar to tail -f:

docker logs -f demo-app

This keeps your terminal attached until you Ctrl+C. It does not stop the container — it just detaches your view.

Limiting Output With --tail

For a container that’s been running for hours, dumping the entire log history is rarely useful. Show just the last N lines:

docker logs --tail 20 demo-app

Expected output: the most recent 20 lines only, in order.

Combine with -f to follow starting from the last 20 lines instead of the beginning:

docker logs -f --tail 20 demo-app

Filtering by Time

Two flags control time-based filtering:

• --since — show logs after a given time
• --until — show logs before a given time

Both accept RFC3339 timestamps, Unix timestamps, or relative durations like 10m, 1h.

docker logs --since 5m demo-app

Expected output: only lines logged in the last 5 minutes.

docker logs --since "2026-07-29T10:00:00" --until "2026-07-29T10:15:00" demo-app

Expected output: lines logged only within that 15-minute window — extremely useful when correlating logs to a specific incident window from a monitoring alert.

Including Timestamps

By default, docker logs doesn’t print timestamps. Add -t (or --timestamps):

docker logs -t --tail 5 demo-app

Expected output:

2026-07-29T10:22:01.123456789Z log line 118
2026-07-29T10:22:02.123456789Z log line 119
2026-07-29T10:22:03.123456789Z log line 120
2026-07-29T10:22:04.123456789Z log line 121
2026-07-29T10:22:05.123456789Z log line 122

This is stored internally regardless — Docker always timestamps log entries at capture time — -t just controls whether it’s printed.

Separating stdout and stderr

By default docker logs interleaves both streams. To isolate one:

docker logs demo-app 1>stdout.log 2>stderr.log

This works because Docker’s CLI writes stdout and stderr from the container to the CLI’s own stdout/stderr respectively, so normal shell redirection separates them into files.

Getting Logs From a Docker Compose Service

docker compose logs
docker compose logs -f web
docker compose logs --tail 50 --since 10m worker

Compose’s logs command is effectively a wrapper that aggregates docker logs across all containers in the project, prefixing each line with the service name:

web_1     | 200 GET /health
worker_1  | processing job 4821

Why Logs Sometimes Disappear: Logging Drivers

This is the part that trips people up most. docker logs doesn’t read from the container process directly — it reads from whatever logging driver is configured, which defaults to json-file. That driver writes each container’s stdout/stderr to a JSON file on the host at:

/var/lib/docker/containers/<container-id>/<container-id>-json.log

Check the current driver:

docker info --format '{{.LoggingDriver}}'

Expected output:

json-file

Inspect the raw file directly (useful when docker logs itself is misbehaving):

sudo cat /var/lib/docker/containers/$(docker inspect --format '{{.Id}}' demo-app)/*-json.log

Expected output — raw JSON, one object per line:

{"log":"log line 130\n","stream":"stdout","time":"2026-07-29T10:25:10.123456789Z"}

Critically: if you switch the logging driver to something like syslog, journald, fluentd, awslogs, gelf, or none, docker logs may return nothing or an error, because those drivers don’t support Docker’s log-reading API the same way (some, like journald, do support it; others like awslogs do not). This is by far the most common cause of “why is docker logs empty” support questions.

Check per-container driver override:

docker inspect demo-app --format '{{.HostConfig.LogConfig.Type}}'

If this returns none, that container was explicitly configured to discard logs — set at run time:

docker run -d --log-driver none alpine echo "this won't be captured by docker logs"

Configuring Log Rotation (a Common Production Gotcha)

By default, json-file logs grow unbounded unless you configure rotation — a chatty container can fill your disk. Set size limits and rotation count at run time:

docker run -d --name demo-app \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  alpine sh -c "while true; do echo tick; sleep 1; done"

Verify:

docker inspect demo-app --format '{{json .HostConfig.LogConfig}}'

Expected output:

{"Type":"json-file","Config":{"max-file":"3","max-size":"10m"}}

This caps total log storage per container at 30MB (10MB × 3 files), discarding the oldest once rotated. For a daemon-wide default (applies to all new containers), edit /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

sudo systemctl restart docker

Logs After Container Removal

Once a container is removed (docker rm), its log file is deleted along with it — docker logs on a removed container returns an error:

docker rm -f demo-app
docker logs demo-app

Expected output:

Error response from daemon: No such container: demo-app

This is why production systems ship logs to an external aggregator (see the Logspout guide) rather than relying on docker logs as long-term storage — it’s a live debugging tool, not a retention system.

Combining Flags for Real Debugging Scenarios

Investigating a crash that happened around 14:32, want context before and after, with timestamps:

docker logs -t --since "2026-07-29T14:30:00" --until "2026-07-29T14:35:00" demo-app

Watching a freshly deployed container for errors in real time, ignoring history:

docker logs -f --since 0s demo-app

Grepping logs for a specific error pattern:

docker logs demo-app 2>&1 | grep -i "error\|exception\|panic"

Security Considerations

• Log files under /var/lib/docker/containers/ are readable by root (and the docker group, which is effectively root-equivalent) — treat any secrets accidentally printed to stdout as compromised the moment they’re logged.
• Avoid logging credentials, tokens, or PII from application code; docker logs output is often shipped verbatim to third-party aggregation services.
• Restrict docker group membership on shared hosts — anyone in it can read every container’s logs, not just their own.

Troubleshooting Reference

Real-World Deployment Notes

On any host running more than a handful of containers, I set max-size/max-file defaults in daemon.json on day one — it’s the single most common “why is my disk full” incident I’ve seen with Docker in production, and it’s entirely preventable with two lines of config. For teams already running a log aggregator (ELK, Loki, a SaaS platform), docker logs becomes primarily a local, immediate-feedback tool used during active debugging or in CI pipelines where spinning up a full logging stack isn’t worth it — docker compose logs -f during a test run is often all you need. Where I’ve seen docker logs genuinely fail teams is when they treat it as their only logging strategy in production: it’s tied to container lifecycle and host disk space, neither of which are guarantees you want your incident postmortems depending on.

Summary

docker logs looks like a trivial command until you need it under pressure — then the flags for time filtering, tailing, and stream separation become the difference between finding the root cause in 30 seconds and scrolling through thousands of irrelevant lines. Understanding that it’s backed by a configurable logging driver (not some magic container-internal buffer) explains almost every “why don’t my logs show up” issue you’ll hit, and configuring rotation up front saves you from a full disk during an incident, which is the worst possible time to discover you never set max-size.

References

• Docker CLI Reference — docker logs
• Docker Logging Drivers Overview
• Docker Compose CLI — logs
• Docker daemon.json Reference

The post How to Get the Logs of a Container with Docker Logs: Complete Logging and Troubleshooting Guide appeared first on Abdul Wahab Junaid.

What docker events Actually Is

The Docker daemon maintains an internal event stream for nearly everything that happens to containers, images, volumes, networks, and the daemon itself. docker events is a client that subscribes to that stream in real time over the Docker Engine API (GET /events) — it’s push-based, not polling, so events appear the instant they happen with no delay.

Event categories include:

• Container: create, start, stop, die, kill, restart, pause, unpause, oom, exec_create, health_status
• Image: pull, push, delete, tag, untag
• Volume: create, mount, unmount, destroy
• Network: create, connect, disconnect, destroy
• Daemon: reload

Basic Usage

docker events

This blocks and streams events live. Open a second terminal and generate some activity:

docker run -d --name events-demo alpine sleep 300

Back in the first terminal, expected output:

2026-07-29T10:40:12.123456789Z container create a1b2c3d4... (image=alpine, name=events-demo)
2026-07-29T10:40:12.234567890Z network connect 8f7e6d5c... (container=a1b2c3d4..., name=bridge)
2026-07-29T10:40:12.345678901Z container start a1b2c3d4... (image=alpine, name=events-demo)

Stop it and watch the corresponding events:

docker stop events-demo

2026-07-29T10:41:05.111222333Z container kill a1b2c3d4... (signal=15)
2026-07-29T10:41:05.222333444Z container die a1b2c3d4... (exitCode=143)
2026-07-29T10:41:05.333444555Z container stop a1b2c3d4...

Note the exitCode in the die event — this is one of the most operationally useful fields, letting you distinguish a clean shutdown (0) from a crash (non-zero) without inspecting the container separately.

Filtering Events

Use --filter to narrow the stream — essential once you have more than a couple of containers running, or the output becomes unreadable noise.

By event type:

docker events --filter event=die

By container:

docker events --filter container=events-demo

By image:

docker events --filter image=alpine

By label:

docker events --filter label=environment=production

Combine multiple filters (AND logic between different filter keys, OR logic within the same key):

docker events --filter event=die --filter event=oom --filter label=environment=production

Expected behavior: this streams only die or oom events, restricted to containers labeled environment=production.

Time-Bounded Queries (Not Just Live Streaming)

docker events isn’t only for live tailing — you can query a historical window using --since and --until, exactly like docker logs:

docker events --since "2026-07-29T09:00:00" --until "2026-07-29T10:00:00"

Expected output: every daemon event that occurred in that one-hour window, useful for reconstructing what happened during an incident after the fact — assuming the daemon was running continuously (this reads live from the daemon’s in-memory buffer, not a persisted log, so events before a daemon restart are gone; more on that below).

Relative durations work too:

docker events --since 30m

JSON Output for Scripting

Raw text output isn’t great for programmatic consumption. Use --format:

docker events --format '{{json .}}'

Expected output — one JSON object per line:

{"status":"die","id":"a1b2c3d4...","from":"alpine","Type":"container","Action":"die","Actor":{"ID":"a1b2c3d4...","Attributes":{"exitCode":"137","image":"alpine","name":"events-demo"}},"time":1753784465,"timeNano":1753784465123456789}

Pipe into jq to build a real alerting one-liner:

docker events --filter event=die --format '{{json .}}' | jq -r '"\(.Actor.Attributes.name) exited with code \(.Actor.Attributes.exitCode) at \(.time)"'

Expected output:

events-demo exited with code 137 at 1753784465

Exit code 137 specifically means the container was killed via SIGKILL (128 + 9) — commonly from an OOM kill or a forced docker kill. Combine with the oom event filter to distinguish memory kills from manual ones.

Building a Real Alert Script

Here’s a practical example — a bash script that watches for any container dying with a non-zero exit code and posts to a webhook (e.g., Slack):

#!/usr/bin/env bash
# watch-crashes.sh
WEBHOOK_URL="https://hooks.slack.com/services/XXX/YYY/ZZZ"

docker events --filter event=die --format '{{json .}}' | while read -r event; do
  exit_code=$(echo "$event" | jq -r '.Actor.Attributes.exitCode')
  name=$(echo "$event" | jq -r '.Actor.Attributes.name')

  if [ "$exit_code" != "0" ]; then
    message="⚠️ Container *${name}* exited with code ${exit_code}"
    curl -s -X POST -H 'Content-type: application/json' \
      --data "{\"text\":\"${message}\"}" \
      "$WEBHOOK_URL"
  fi
done

chmod +x watch-crashes.sh
nohup ./watch-crashes.sh &

Run it as a systemd service for durability:

# /etc/systemd/system/docker-crash-watch.service
[Unit]
Description=Watch Docker container crashes and alert
After=docker.service
Requires=docker.service

[Service]
ExecStart=/usr/local/bin/watch-crashes.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now docker-crash-watch.service

Health Check Events

If your containers define a HEALTHCHECK, Docker emits health_status events, which are extremely useful for catching “the process is running but the app is broken” scenarios that die events won’t cover:

docker run -d --name health-demo \
  --health-cmd="curl -f http://localhost/ || exit 1" \
  --health-interval=5s \
  nginx:alpine

docker events --filter event=health_status --filter container=health-demo

Expected output over time:

2026-07-29T10:50:05.000000000Z container health_status: healthy a1b2c3d4... (name=health-demo)

If you then break the container’s health check target, you’d see a transition to health_status: unhealthy — a strong signal to alert on and one that plain die monitoring would completely miss.

Docker Compose and Events

docker events works daemon-wide regardless of whether containers were started via Compose, docker run, or Swarm — Compose doesn’t have its own separate event bus. Filter by Compose project label to scope to one stack:

docker events --filter label=com.docker.compose.project=myapp

Internals: Where This Data Comes From

The Docker daemon (dockerd) maintains an in-memory ring buffer of recent events (default capacity: 1000 events) that the Engine API’s /events endpoint streams from over a long-lived HTTP connection. This has two important consequences:

1. Events are not persisted across daemon restarts. If dockerd restarts, the buffer is cleared — --since queries can’t reach further back than the daemon’s current uptime plus whatever’s still in the buffer.
2. High-volume event bursts can evict old events from the buffer before a slow consumer reads them, though this is rare in normal operation — it matters mainly on hosts running very high container churn (e.g., CI runners spinning up hundreds of short-lived containers per minute).

For durable, long-term event history, you need to actively consume the stream into external storage — there’s no built-in persistence layer, which is exactly why the alert-script pattern above (or shipping into a time-series/log system) matters for anything beyond live debugging.

Security Considerations

• The events API requires access to the Docker socket, which is root-equivalent — treat any script consuming docker events with the same care as anything else touching /var/run/docker.sock.
• Don’t expose the Docker daemon’s remote API (-H tcp://0.0.0.0:2375) without TLS — an unauthenticated remote events endpoint leaks your entire container topology (names, images, labels) to anyone who can reach it.
• If shipping events to a webhook (like the Slack example), use a secrets manager or environment injection for the webhook URL rather than hardcoding it in a script under version control.

Troubleshooting

Real-World Deployment Notes

The alert-script pattern in this guide is genuinely how I’ve bootstrapped monitoring on small Docker fleets before a full observability stack was justified — it’s a few lines of bash and gets you meaningful signal on day one. As the fleet grows, I’ve typically graduated this into a small always-on consumer service (rather than a bash loop) that normalizes events into a message queue (Kafka, RabbitMQ) so multiple downstream systems — alerting, audit logging, autoscaling triggers — can consume the same event stream independently instead of each polling the Docker socket separately. Also worth knowing: on Kubernetes, the equivalent isn’t docker events at all but the Kubernetes Events API (kubectl get events or watching via the API server) — the underlying container runtime events still exist, but orchestration-level tooling on K8s abstracts you away from talking to the container engine directly.

Summary

docker events turns Docker from something you have to actively check on into something that tells you when it needs attention. The combination of --filter for signal-to-noise control, --format '{{json .}}' for scriptability, and the fact that it’s a genuine live push stream (not polling) makes it a small but high-leverage piece of any container monitoring setup — especially for catching OOM kills and unhealthy states that simpler “is the container running” checks miss entirely.

References

• Docker CLI Reference — docker events
• Docker Engine API — Monitor Events
• Docker Health Checks
• systemd.service Documentation

The post How to Listen to Docker Events on Your Docker Hosts: Real-Time Event Monitoring Guide appeared first on Abdul Wahab Junaid.

Basic Usage

docker stats

This launches a live, auto-refreshing table for all running containers:

CONTAINER ID   NAME         CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
a1b2c3d4e5f6   web          2.34%     45.2MiB / 512MiB       8.83%    1.2kB / 850B      0B / 4.1kB        4
f6e5d4c3b2a1   worker       78.91%    390MiB / 512MiB        76.17%   3.4kB / 1.2kB     12MB / 0B         9

Press Ctrl+C to exit — this doesn’t stop any containers, only detaches the view.

Scoping to Specific Containers

docker stats web worker

Or by pattern using shell expansion with docker ps:

docker stats $(docker ps --filter "name=web" --format "{{.Names}}")

Getting a One-Time Snapshot (Not Live-Streaming)

By default docker stats streams continuously, which is awkward in scripts. Use --no-stream for a single sample:

docker stats --no-stream

Expected output: the same table format, printed once, then the command exits immediately — ideal for cron jobs, health-check scripts, or logging snapshots at intervals.

Machine-Readable Output With --format

For scripting or feeding into a monitoring pipeline, use Go template formatting:

docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}"

Expected output:

NAME      CPU %     MEM USAGE / LIMIT     MEM %
web       2.34%     45.2MiB / 512MiB      8.83%
worker    78.91%    390MiB / 512MiB       76.17%

For JSON (much easier to parse programmatically):

docker stats --no-stream --format '{{json .}}'

Expected output — one JSON object per container:

{"BlockIO":"0B / 4.1kB","CPUPerc":"2.34%","Container":"a1b2c3d4e5f6","ID":"a1b2c3d4e5f6","MemPerc":"8.83%","MemUsage":"45.2MiB / 512MiB","Name":"web","NetIO":"1.2kB / 850B","PIDs":"4"}

Pipe through jq to alert on thresholds:

docker stats --no-stream --format '{{json .}}' | jq -r 'select(.MemPerc | rtrimstr("%") | tonumber > 75) | "\(.Name) is at \(.MemPerc) memory usage"'

Expected output when a container crosses 75% memory:

worker is at 76.17% memory usage

Scripted Polling for Monitoring Pipelines

A simple script that logs stats every 10 seconds to a CSV for later analysis:

#!/usr/bin/env bash
# poll-stats.sh
OUTFILE="container-stats.csv"
echo "timestamp,name,cpu_perc,mem_usage,mem_perc" > "$OUTFILE"

while true; do
  ts=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
  docker stats --no-stream --format '{{.Name}},{{.CPUPerc}},{{.MemUsage}},{{.MemPerc}}' \
    | while IFS=, read -r name cpu mem_usage mem_perc; do
        echo "${ts},${name},${cpu},${mem_usage},${mem_perc}" >> "$OUTFILE"
      done
  sleep 10
done

chmod +x poll-stats.sh
nohup ./poll-stats.sh &

This is a lightweight starting point — for anything beyond ad-hoc analysis, feed the same data into Prometheus instead (see below), which handles retention, querying, and alerting far better than a flat CSV file.

Inspecting a Single Container’s Raw cgroup Stats via the API

docker stats is actually a formatted view over the Docker Engine API’s /containers/{id}/stats endpoint, which returns raw cgroup accounting data. You can query it directly:

curl --unix-socket /var/run/docker.sock \
  "http:/containers/web/stats?stream=false" | jq .

Expected output (trimmed): a large JSON object including cpu_stats, precpu_stats, memory_stats, networks, and blkio_stats — this is the raw data docker stats computes its percentages from. Useful when you need finer-grained fields than the CLI table exposes, like per-CPU usage or detailed memory breakdown (cache, rss, swap).

{
  "memory_stats": {
    "usage": 47431680,
    "limit": 536870912,
    "stats": {
      "cache": 2048000,
      "rss": 45383680
    }
  }
}

How Docker Calculates These Numbers (cgroups Under the Hood)

Docker containers get their resource accounting from Linux control groups (cgroups) — the same kernel mechanism that enforces resource limits. Every container is assigned a cgroup, and the kernel tracks CPU time, memory usage, and I/O directly against it. Docker doesn’t measure anything itself; it reads these kernel-maintained counters and does the math.

CPU % is calculated as:

cpu_delta = current_cpu_usage - previous_cpu_usage
system_delta = current_system_cpu_usage - previous_system_cpu_usage
CPU % = (cpu_delta / system_delta) * number_of_cpus * 100

This is why CPU percentages can exceed 100% for multi-threaded containers on multi-core hosts — a container using 2 full cores shows as ~200%.

MEM USAGE is the cgroup’s tracked memory, which by default includes page cache on cgroup v1 — meaning a container reading a lot of files from disk can show inflated memory usage that isn’t actually “at risk” memory the OOM killer would reclaim under pressure. On cgroup v2 (default on modern Linux distros and Docker 20.10+), this accounting is more accurate and generally excludes reclaimable cache from the pressure calculation, though docker stats display still includes cache in the raw usage number.

Check which cgroup version your host uses:

docker info --format '{{.CgroupVersion}}'

Expected output:

2

Setting Resource Limits (What “LIMIT” in the Output Means)

The LIMIT column reflects whatever you constrained the container to at run time — if unset, it defaults to the host’s total memory. Set explicit limits:

docker run -d --name limited-app \
  --memory=256m \
  --memory-swap=256m \
  --cpus="0.5" \
  nginx:alpine

docker stats limited-app --no-stream

Expected output:

NAME           CPU %     MEM USAGE / LIMIT     MEM %
limited-app    0.05%     3.2MiB / 256MiB        1.25%

--cpus="0.5" caps the container to half a CPU core — under sustained load, docker stats CPU% for this container will plateau near 50% even though more capacity exists on the host, because the cgroup CPU quota is throttling it.

Docker Compose Resource Limits and Stats

# docker-compose.yml
services:
  worker:
    image: myapp/worker:latest
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M
        reservations:
          memory: 256M

Note: deploy.resources is honored by docker compose up for local development in recent Compose versions, and always honored in Swarm mode. Check applied limits:

docker inspect worker --format '{{.HostConfig.Memory}}'

Feeding Stats Into Prometheus for Real Monitoring

For anything beyond ad-hoc checks, run cAdvisor, which exposes per-container resource metrics in Prometheus format — this is the standard approach in production rather than polling docker stats yourself:

docker run -d \
  --name cadvisor \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --privileged \
  --device=/dev/kmsg \
  gcr.io/cadvisor/cadvisor:v0.49.1

Verify metrics are exposed:

curl -s http://localhost:8080/metrics | grep container_memory_usage_bytes | head -3

Expected output:

container_memory_usage_bytes{container_label_...,name="web"} 4.7431680e+07

Point a Prometheus scrape config at it:

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['localhost:8080']

From there, Grafana dashboards and alerting rules (e.g., container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.9) give you the sustained, historical view that a live docker stats terminal session can’t.

Security Considerations

• cAdvisor requires broad host mounts and --privileged to read cgroup/proc data — restrict it to trusted internal networks and don’t expose port 8080 publicly without authentication in front of it (e.g., a reverse proxy with auth).
• Access to docker stats requires Docker socket access, same root-equivalent caveat as every other command in this series — don’t grant docker group membership casually on shared/multi-tenant hosts.
• Resource limits (--memory, --cpus) are a security boundary as much as a performance one — an unconstrained container can starve co-located workloads (noisy-neighbor problem) or exhaust host memory, triggering the OOM killer against unrelated processes.

Troubleshooting

Real-World Deployment Notes

docker stats is the tool I reach for first because it needs zero setup — no exporter, no scrape config, just a running Docker daemon. That makes it ideal for the “something feels off, let me check right now” moment. But I’ve learned not to trust a single snapshot too much: a container can look fine at the instant you check and still have been thrashing memory five minutes earlier. That gap is exactly why cAdvisor-plus-Prometheus earns its place once a service matters enough to have an on-call rotation — it turns “what does this look like right now” into “what did this look like during the incident window,” which is almost always the more useful question during a postmortem.

Summary

docker stats gives you a real-time window into what a container is actually doing on the host — CPU, memory, network, and block I/O — sourced directly from the kernel’s cgroup accounting rather than anything Docker computes independently. It’s the right tool for live debugging and quick sanity checks; for anything you need historical trends or alerting on, graduate to cAdvisor plus Prometheus and Grafana, which read the same underlying cgroup data but retain and query it properly over time.

References

• Docker CLI Reference — docker stats
• Docker Engine API — Container Stats
• Docker Resource Constraints
• cAdvisor GitHub Repository
• Prometheus Documentation
• Kernel Documentation — Control Groups v2

The post How to Obtain Usage Statistics of a Running Container: Docker Stats and Resource Monitoring appeared first on Abdul Wahab Junaid.

In this guide I’m going to walk through everything I use docker inspect for day to day — from the absolute basics to the advanced formatting tricks that let you pull exact fields out of the JSON output for use in scripts, monitoring tools, and CI/CD pipelines.

What Is Docker Inspect?

docker inspect is a low-level Docker CLI command that returns detailed configuration and runtime information about Docker objects — containers, images, volumes, networks, and even Swarm services — in JSON format. Think of it as the “X-ray” command for anything Docker manages on your host.

Under the hood, when you run docker inspect, the Docker CLI is really just calling the Docker Engine API’s /containers/{id}/json endpoint (or the equivalent endpoint for images, volumes, or networks) and pretty-printing the response. Everything you see in docker inspect output is metadata that the Docker daemon (dockerd) already tracks internally — inspect just exposes it to you.

Basic Syntax

docker inspect [OPTIONS] NAME|ID [NAME|ID...]

You can pass one or more container names or IDs, and Docker will return a JSON array with one object per target.

Let’s start with a real container so the examples aren’t abstract.

docker run -d --name web-test -p 8080:80 nginx:latest

Expected output:

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
a480a496ba95: Pull complete
...
Status: Downloaded newer image for nginx:latest
3f1a9c2e8b7d4e6f9a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f

Now inspect it:

docker inspect web-test

This dumps a large JSON document. The top-level keys you’ll see most often are:

• Id — the full 64-character container ID
• Created — timestamp of creation
• Path and Args — the entrypoint and arguments
• State — running status, PID, exit code, health status
• Image — the image ID the container was created from
• NetworkSettings — IP address, gateway, ports, and network config
• Mounts — volumes and bind mounts attached to the container
• Config — environment variables, labels, working directory, exposed ports
• HostConfig — resource limits, restart policy, privileged mode, capabilities

Inspecting Specific Sections

Dumping the entire JSON blob is rarely useful on its own. The real power of docker inspect comes from the --format (or -f) flag, which uses Go’s text/template syntax to extract exactly the field you want.

Get the container’s IP address

docker inspect --format='{{.NetworkSettings.IPAddress}}' web-test

Expected output:

172.17.0.2

Get the container’s status

docker inspect --format='{{.State.Status}}' web-test

Output:

running

Get environment variables

docker inspect --format='{{.Config.Env}}' web-test

Output:

[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin NGINX_VERSION=1.27.0 ...]

Get mounted volumes

docker inspect --format='{{json .Mounts}}' web-test

Wrapping a field in json forces Go’s template engine to render it as properly formatted JSON rather than Go’s default struct representation, which is especially handy for arrays and nested objects.

Get restart policy

docker inspect --format='{{.HostConfig.RestartPolicy.Name}}' web-test

Get exposed ports and their host bindings

docker inspect --format='{{json .NetworkSettings.Ports}}' web-test

Output:

{"80/tcp":[{"HostIp":"0.0.0.0","HostPort":"8080"}]}

Filtering with --format and Ranges

Go templates support loops, which is useful when you have multiple containers attached to multiple networks, or several mounts.

docker inspect --format='{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' web-test

This iterates over every mount and prints the source and destination path on its own line — extremely useful when a container has five or six volumes and you just want a clean list instead of a JSON blob.

Inspecting Images, Volumes, and Networks

docker inspect isn’t limited to containers. It’s a general-purpose object inspector.

docker inspect nginx:latest
docker inspect my-volume
docker inspect bridge

For images, you’ll get layers, exposed ports, entrypoint, and the architecture the image was built for. For volumes, you get the mount point on the host filesystem and driver options. For networks, you get subnet, gateway, and which containers are currently attached.

Example: Checking which containers are on a network

docker inspect --format='{{range $k, $v := .Containers}}{{$v.Name}} {{end}}' bridge

Using Docker Inspect for Health Checks

If your image defines a HEALTHCHECK, docker inspect is the primary way to query it programmatically.

docker inspect --format='{{json .State.Health}}' web-test

Expected output (if a healthcheck is configured):

{"Status":"healthy","FailingStreak":0,"Log":[{"Start":"2026-07-29T10:00:00Z","End":"2026-07-29T10:00:01Z","ExitCode":0,"Output":""}]}

This is exactly the kind of field an orchestration script (or a custom Nagios/Prometheus exporter) would poll before deciding whether to route traffic to a container.

Combining Inspect with jq

While Go templates are powerful, most engineers I know prefer to just dump raw JSON and pipe it through jq for anything beyond a single field.

docker inspect web-test | jq '.[0].State'

docker inspect web-test | jq '.[0].NetworkSettings.Networks | keys'

This is often faster to write than remembering Go template syntax, and it composes well with other JSON-aware tooling in a CI pipeline.

Real-World Use Cases

1. Debugging a container that keeps restarting

docker inspect --format='{{.State.ExitCode}} {{.State.Error}}' flaky-app

2. Verifying resource limits before a load test

docker inspect --format='CPU: {{.HostConfig.NanoCpus}} Memory: {{.HostConfig.Memory}}' web-test

3. Auditing security settings

docker inspect --format='Privileged: {{.HostConfig.Privileged}} Capabilities: {{.HostConfig.CapAdd}}' web-test

Running containers as privileged, or with unnecessary added capabilities, is one of the most common container security misconfigurations. Wiring docker inspect into an automated audit script (or using it inside a CI gate before deployment) catches this early.

4. Extracting IPs for a monitoring inventory

for c in $(docker ps -q); do
  echo "$(docker inspect --format='{{.Name}}' $c) $(docker inspect --format='{{.NetworkSettings.IPAddress}}' $c)"
done

Docker Inspect and Container Internals

To really understand what docker inspect is showing you, it helps to understand what a container actually is. A Docker container is a set of Linux namespaces (PID, network, mount, UTS, IPC, user) combined with cgroups for resource limiting, layered together with a union filesystem (usually overlay2). docker inspect‘s GraphDriver field shows you exactly which filesystem driver is in use and where the merged, upper, and lower directories live on disk:

docker inspect --format='{{json .GraphDriver}}' web-test

Output:

{"Data":{"LowerDir":"/var/lib/docker/overlay2/.../diff","MergedDir":"/var/lib/docker/overlay2/.../merged","UpperDir":"/var/lib/docker/overlay2/.../diff","WorkDir":"/var/lib/docker/overlay2/.../work"},"Name":"overlay2"}

This is the actual filesystem view the container process sees, assembled from immutable image layers plus a writable layer on top.

Troubleshooting Tips

• Container exits immediately after start — check State.ExitCode and State.Error first.
• Networking issues between containers — compare NetworkSettings.Networks across the two containers to confirm they’re actually on the same Docker network, not just the same host.
• Volume data not persisting — check Mounts[].Source to confirm the path Docker is actually writing to, since a typo in a Compose file can silently create a new anonymous volume instead of reusing the one you expect.
• “No such object” error — this usually means you’re inspecting a container by a name that has already been removed; docker ps -a will confirm whether it still exists in a stopped state.

Best Practices

1. Always prefer --format or jq over eyeballing raw JSON in scripts — it’s faster and less error-prone.
2. Use docker inspect in your CI/CD pipeline as a post-deployment sanity check (verify image digest, environment variables, and port mappings match what you expect).
3. Don’t rely on docker inspect output format staying identical across major Docker Engine versions — some fields have been renamed or restructured over the years (for example, network settings pre- and post-docker network introduction in Docker 1.9).
4. Combine with docker events for real-time monitoring rather than polling inspect in a tight loop.

Docker Inspect Across Multiple Objects at Once

You’re not limited to inspecting one object per call. Pass several names or IDs together and Docker returns an array covering all of them:

docker inspect web-test nginx:latest bridge

This is handy in scripts that need to correlate a container, the image it was built from, and the network it’s attached to in a single pass, rather than issuing three separate commands.

You can also mix docker ps -q with xargs to inspect every running container in one shot:

docker inspect $(docker ps -q) | jq '[.[] | {name: .Name, image: .Config.Image, status: .State.Status}]'

Expected output:

[
  {"name": "/web-test", "image": "nginx:latest", "status": "running"}
]

Type-Specific Inspection with --type

If you have a name collision between a container and a network (rare, but possible), you can disambiguate with --type:

docker inspect --type=container web-test
docker inspect --type=network web-test

Valid values include container, image, volume, network, plugin, node, service, task, and config (the last few apply only in Swarm mode).

Docker Inspect in Swarm Mode

If you’re running Docker Swarm rather than standalone containers, docker inspect extends naturally to services and tasks:

docker service inspect --pretty my-service
docker inspect $(docker ps -q --filter "label=com.docker.swarm.service.name=my-service")

The --pretty flag on docker service inspect renders a human-readable summary instead of raw JSON — useful when you just need a quick sanity check of replica count, update policy, and published ports without piping through jq.

Frequently Asked Questions

Does docker inspect work on stopped containers? Yes. As long as the container hasn’t been removed (docker rm), docker inspect returns its full configuration, including its last known state and exit code — this is often the first command to run when debugging a container that crashed.

Why does NetworkSettings.IPAddress show an empty string? This field is only populated for containers on the default bridge network. If your container is attached to a user-defined network (which is the norm with Compose), look under NetworkSettings.Networks.<network-name>.IPAddress instead.

Can I use docker inspect to see what command was actually run inside the container? Yes — Config.Cmd and Config.Entrypoint show exactly what was configured, and Path/Args at the top level show what was actually executed as PID 1.

Is there a performance cost to running docker inspect frequently? It’s a lightweight read against data the daemon already holds in memory, so occasional or even per-minute polling in a monitoring script is fine. Avoid tight loops (sub-second polling) against many containers simultaneously, since each call is still a full API round-trip.

Summary

docker inspect is one of those commands that looks simple on the surface but becomes indispensable once you start using its --format flag or piping into jq. It’s the fastest way to answer “what is actually going on inside this container” — IP addresses, mounts, environment variables, health status, resource limits, and security context all live in that one JSON document. Once you’re comfortable extracting specific fields, you can wire docker inspect into monitoring scripts, CI/CD gates, and security audits with very little extra tooling.

References

• Docker CLI reference: https://docs.docker.com/reference/cli/docker/inspect/
• Docker Engine API reference: https://docs.docker.com/reference/api/engine/
• Docker storage drivers documentation: https://docs.docker.com/storage/storagedriver/
• Go text/template package documentation: https://pkg.go.dev/text/template

The post How to Get Detailed Information About a Container with Docker Inspect: Complete Guide appeared first on Abdul Wahab Junaid.

This guide covers exactly how to do that for AWS, Azure, and GCP — including authentication, credential persistence, and building your own multi-cloud CLI image.

Why Run Cloud CLIs in Containers?

Before the how, the why:

• No local pollution. Python version conflicts, Node dependency clashes, and CLI tool version drift never touch your host machine.
• Reproducibility. Everyone on the team runs the exact same CLI version, pinned by image tag.
• Portability. The same container works identically on Linux, macOS, and Windows (via Docker Desktop).
• CI/CD friendliness. The same image you use locally can be dropped straight into a GitLab CI or GitHub Actions job.
• Easy version pinning. Need to test against an older CLI version for a legacy pipeline? Just pull a different tag.

AWS CLI in a Container

AWS publishes an official CLI image.

docker pull amazon/aws-cli:2.17.0

Running a Single Command

docker run --rm amazon/aws-cli:2.17.0 --version

Expected output:

aws-cli/2.17.0 Python/3.11.6 Linux/6.1.0 exe/x86_64.docker

Passing Credentials

The cleanest way is to mount your existing ~/.aws directory as read-only:

docker run --rm -it \
  -v ~/.aws:/root/.aws:ro \
  amazon/aws-cli:2.17.0 s3 ls

Expected output (assuming you have buckets):

2026-01-15 09:32:11 my-app-logs
2026-03-02 14:11:47 terraform-state-prod

Alternatively, pass credentials as environment variables — useful in CI where you don’t want a mounted config directory:

docker run --rm \
  -e AWS_ACCESS_KEY_ID=AKIA... \
  -e AWS_SECRET_ACCESS_KEY=... \
  -e AWS_DEFAULT_REGION=us-east-1 \
  amazon/aws-cli:2.17.0 ec2 describe-instances

Creating a Shell Alias

To make the container feel like a native binary, add this to your .bashrc or .zshrc:

alias aws='docker run --rm -it -v ~/.aws:/root/.aws:ro -v "$PWD":/aws amazon/aws-cli:2.17.0'

Now aws s3 ls works exactly like the local binary would, transparently running inside a container.

Azure CLI in a Container

Microsoft publishes an official Azure CLI image.

docker pull mcr.microsoft.com/azure-cli:2.63.0

Interactive Login

docker run -it mcr.microsoft.com/azure-cli:2.63.0 az login

This prints a device-code URL and code:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin
and enter the code ABCD1234 to authenticate.

Persisting Login Across Container Runs

By default, once the container exits, your login session is gone. Persist the ~/.azure config directory with a named volume:

docker volume create azure-cli-config

docker run -it \
  -v azure-cli-config:/root/.azure \
  mcr.microsoft.com/azure-cli:2.63.0 az login

Subsequent runs reuse that same volume and stay authenticated:

docker run --rm \
  -v azure-cli-config:/root/.azure \
  mcr.microsoft.com/azure-cli:2.63.0 az account show

Expected output:

{
  "environmentName": "AzureCloud",
  "id": "b1234567-89ab-cdef-0123-456789abcdef",
  "isDefault": true,
  "name": "Pay-As-You-Go",
  "user": {
    "name": "you@example.com",
    "type": "user"
  }
}

Service Principal Login (Non-Interactive, CI-Friendly)

docker run --rm mcr.microsoft.com/azure-cli:2.63.0 az login \
  --service-principal \
  -u $AZURE_CLIENT_ID \
  -p $AZURE_CLIENT_SECRET \
  --tenant $AZURE_TENANT_ID

Google Cloud CLI (gcloud) in a Container

Google publishes official images under gcr.io/google.com/cloudsdktool/google-cloud-cli.

docker pull gcr.io/google.com/cloudsdktool/google-cloud-cli:latest

Authenticating

docker run -it \
  -v gcloud-config:/root/.config/gcloud \
  gcr.io/google.com/cloudsdktool/google-cloud-cli:latest \
  gcloud auth login

Using a Service Account Key

For automation, mount a service account JSON key file and activate it:

docker run --rm \
  -v /path/to/key.json:/tmp/key.json:ro \
  gcr.io/google.com/cloudsdktool/google-cloud-cli:latest \
  gcloud auth activate-service-account --key-file=/tmp/key.json

Listing Compute Instances

docker run --rm \
  -v gcloud-config:/root/.config/gcloud \
  gcr.io/google.com/cloudsdktool/google-cloud-cli:latest \
  gcloud compute instances list

Expected output:

NAME        ZONE           MACHINE_TYPE   STATUS
web-server  us-central1-a  e2-medium      RUNNING

Building a Single “Multi-Cloud” CLI Image

Rather than switching between three separate images, many teams build one image with all three CLIs installed, so a single container can talk to AWS, Azure, and GCP in the same script.

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y \
    curl unzip python3 python3-pip apt-transport-https \
    lsb-release gnupg ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# AWS CLI v2
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \
    unzip awscliv2.zip && ./aws/install && rm -rf awscliv2.zip aws

# Azure CLI
RUN curl -sL https://aka.ms/InstallAzureCLIDeb | bash

# Google Cloud CLI
RUN curl -sSL https://sdk.cloud.google.com | bash -s -- --disable-prompts && \
    ln -s /root/google-cloud-sdk/bin/gcloud /usr/local/bin/gcloud

WORKDIR /workspace
ENTRYPOINT ["/bin/bash"]

Build and run it:

docker build -t multicloud-cli:1.0 .
docker run --rm -it multicloud-cli:1.0

Inside the container, verify all three:

aws --version
az --version
gcloud --version

Using Compose to Manage Credential Volumes

If you regularly switch between clouds, a docker-compose.yml makes this cleaner than remembering long docker run commands:

services:
  aws-cli:
    image: amazon/aws-cli:2.17.0
    volumes:
      - ~/.aws:/root/.aws:ro
    entrypoint: aws

  azure-cli:
    image: mcr.microsoft.com/azure-cli:2.63.0
    volumes:
      - azure-config:/root/.azure

  gcloud-cli:
    image: gcr.io/google.com/cloudsdktool/google-cloud-cli:latest
    volumes:
      - gcloud-config:/root/.config/gcloud

volumes:
  azure-config:
  gcloud-config:

Run any of them with:

docker compose run --rm aws-cli s3 ls
docker compose run --rm azure-cli az group list
docker compose run --rm gcloud-cli gcloud projects list

Understanding What’s Actually Happening Under the Hood

It’s worth being clear about what containerizing a CLI does and doesn’t change. The aws, az, and gcloud binaries are ordinary programs — running them inside a container doesn’t make them faster or give them special access to anything. What changes is isolation: the container gets its own filesystem layer, its own set of installed dependencies, and (unless you mount your credential directory in) no access to your host’s files at all by default. That last point is exactly why the -v ~/.aws:/root/.aws:ro pattern matters — without it, the CLI inside the container has no way to find your credentials, because containers don’t inherit anything from the host filesystem unless you explicitly mount it.

This also explains why --rm shows up in almost every example above: without it, Docker leaves a stopped container behind after every single command, and running dozens of aws s3 ls calls a day would otherwise leave dozens of dead containers cluttering docker ps -a.

Handling Output Files and Local Directories

A common need is running a CLI command that writes output to a local file — for example, downloading an S3 object or exporting a Terraform plan. Since the container has its own isolated filesystem, you need to mount your working directory in as well as your credentials:

docker run --rm \
  -v ~/.aws:/root/.aws:ro \
  -v "$PWD":/workspace \
  -w /workspace \
  amazon/aws-cli:2.17.0 s3 cp s3://my-bucket/report.csv ./report.csv

Expected output:

download: s3://my-bucket/report.csv to ./report.csv

The -w /workspace flag sets the container’s working directory to match the mounted volume, so relative paths in the command behave the way you’d expect.

Integrating into CI/CD Pipelines

The exact same images work as pipeline steps. A GitHub Actions example using the AWS CLI container directly (rather than the aws-actions/configure-aws-credentials action) looks like this:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Sync to S3
        run: |
          docker run --rm \
            -e AWS_ACCESS_KEY_ID=${{ secrets.AWS_ACCESS_KEY_ID }} \
            -e AWS_SECRET_ACCESS_KEY=${{ secrets.AWS_SECRET_ACCESS_KEY }} \
            -e AWS_DEFAULT_REGION=us-east-1 \
            -v "$PWD":/workspace -w /workspace \
            amazon/aws-cli:2.17.0 s3 sync ./dist s3://my-app-bucket

The advantage over installing the CLI directly in the CI runner is version pinning — the pipeline behaves identically regardless of what’s baked into the runner image, and upgrading the CLI version is a one-line tag change.

Performance Considerations

Containerized CLIs add a small amount of overhead versus a natively installed binary — mainly image pull time on first use (subsequent runs use the cached image) and a few hundred milliseconds of container startup per invocation. For interactive use this is imperceptible; for scripts issuing hundreds of CLI calls in a tight loop, consider starting a single long-lived container and issuing multiple commands inside it via docker exec, rather than paying the startup cost per call:

docker run -d --name aws-session --entrypoint sleep \
  -v ~/.aws:/root/.aws:ro amazon/aws-cli:2.17.0 infinity

docker exec aws-session aws s3 ls
docker exec aws-session aws ec2 describe-instances

docker stop aws-session && docker rm aws-session

Security Considerations

• Never bake credentials into an image. Layers are cached and can leak secrets even after deletion from later layers.
• Prefer named volumes or bind mounts for credential storage over environment variables when running interactively, since environment variables are visible via docker inspect and process listings on the host.
• Use short-lived tokens where possible — AWS STS assume-role sessions, Azure managed identities, and GCP workload identity federation all reduce the blast radius of a leaked credential.
• Mount credential directories read-only (:ro) whenever the CLI doesn’t need to write back to them.
• Rotate CI service principal / service account credentials regularly, and scope their IAM permissions to the minimum required for the pipeline.

Troubleshooting

• “Unable to locate credentials” (AWS) — double check the mount path matches the CLI’s expected config location (/root/.aws for the root user inside the container, not /home/user/.aws unless you changed the container’s user).
• Azure login opens a browser but the container has no browser — this is expected; use the device code flow (az login without --service-principal) shown above, or use a service principal in headless environments.
• gcloud commands fail with PERMISSION_DENIED — verify the active account/project with gcloud config list before assuming the credentials themselves are bad.
• Volume permissions errors on Linux hosts — if the container runs as a non-root user internally, you may need to chown the mounted directory or pass --user $(id -u):$(id -g) to match host file ownership.

Summary

Running cloud CLIs inside Docker containers removes an entire category of “works on my machine” problems from multi-cloud DevOps workflows. Official images exist for AWS, Azure, and GCP, authentication can be persisted across runs using named volumes, and it’s straightforward to combine all three into a single multi-cloud utility image for scripts that need to touch more than one provider. The same pattern scales cleanly into CI/CD, where these exact images can be reused as pipeline steps.

References

• AWS CLI Docker image: https://hub.docker.com/r/amazon/aws-cli
• Azure CLI Docker image: https://learn.microsoft.com/en-us/cli/azure/run-azure-cli-docker
• Google Cloud CLI Docker image: https://cloud.google.com/sdk/docs/downloads-docker
• Docker Compose file reference: https://docs.docker.com/reference/compose-file/

The post How to Run a Cloud Provider CLI in a Docker Container: AWS, Azure, and GCP Setup Guide appeared first on Abdul Wahab Junaid.

Prerequisites

• An Azure account with an active subscription
• Azure CLI installed locally, or run it via container (see the companion guide on running cloud CLIs in Docker)
• SSH key pair for authentication (ssh-keygen -t ed25519)

Step 1: Log In and Set Your Subscription

az login
az account list --output table
az account set --subscription "Pay-As-You-Go"

Step 2: Create a Resource Group

Resource groups are Azure’s logical container for related resources — keeping everything under one group makes cleanup trivial later.

az group create --name docker-rg --location eastus

Expected output:

{
  "id": "/subscriptions/xxxx/resourceGroups/docker-rg",
  "location": "eastus",
  "name": "docker-rg",
  "properties": {
    "provisioningState": "Succeeded"
  }
}

Step 3: Create a Virtual Machine

Azure has a marketplace image for Docker-ready hosts, but I generally prefer starting from plain Ubuntu and installing Docker myself via cloud-init — it keeps the setup transparent and reproducible.

az vm create \
  --resource-group docker-rg \
  --name docker-host-01 \
  --image Ubuntu2404 \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --custom-data cloud-init-docker.yml

Where cloud-init-docker.yml looks like this:

#cloud-config
package_update: true
package_upgrade: true
runcmd:
  - curl -fsSL https://get.docker.com -o get-docker.sh
  - sh get-docker.sh
  - usermod -aG docker azureuser
  - systemctl enable docker
  - systemctl start docker

Expected output after a minute or two:

{
  "fqdns": "",
  "location": "eastus",
  "publicIpAddress": "20.185.44.112",
  "resourceGroup": "docker-rg"
}

Step 4: Open the Required Network Ports

By default Azure VMs allow SSH (22) but nothing else. Open port 2376 if you plan to expose the Docker daemon remotely (with TLS — never without), and any application ports you need.

az vm open-port --resource-group docker-rg --name docker-host-01 --port 2376 --priority 900
az vm open-port --resource-group docker-rg --name docker-host-01 --port 80 --priority 910

Step 5: SSH In and Verify Docker

ssh azureuser@20.185.44.112
docker --version
docker run hello-world

Expected output:

Docker version 27.3.1, build ce12230
...
Hello from Docker!
This message shows that your installation appears to be working correctly.

Step 6: Securing Remote Docker API Access (Optional but Important)

If you want to run docker commands against this host from your laptop (rather than SSHing in every time), you need to expose the Docker daemon over TCP — and that must be done with TLS certificates, never in plaintext, since an open Docker socket is equivalent to root access on the host.

On the VM, generate a CA and server certificates:

mkdir -p ~/docker-certs && cd ~/docker-certs
openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
openssl genrsa -out server-key.pem 4096
openssl req -subj "/CN=$(hostname)" -sha256 -new -key server-key.pem -out server.csr
echo subjectAltName = IP:20.185.44.112,IP:127.0.0.1 > extfile.cnf
openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem -extfile extfile.cnf

Then configure the Docker daemon to use TLS by editing /etc/docker/daemon.json:

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"],
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server-cert.pem",
  "tlskey": "/etc/docker/server-key.pem"
}

Restart Docker:

sudo systemctl restart docker

On your laptop, generate a client cert signed by the same CA and connect:

export DOCKER_HOST=tcp://20.185.44.112:2376
export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=~/docker-certs/client

docker version

Step 7: Attach a Managed Disk for Persistent Storage

If your containers need persistent storage beyond the OS disk, attach and mount an Azure managed disk.

az disk create \
  --resource-group docker-rg \
  --name docker-data-disk \
  --size-gb 64 \
  --sku Premium_LRS

az vm disk attach \
  --resource-group docker-rg \
  --vm-name docker-host-01 \
  --name docker-data-disk

On the VM:

sudo lsblk
sudo mkfs.ext4 /dev/sdc
sudo mkdir /mnt/docker-data
sudo mount /dev/sdc /mnt/docker-data

Then point Docker’s data root at this disk by adding "data-root": "/mnt/docker-data/docker" to /etc/docker/daemon.json and restarting Docker.

Networking Fundamentals on This Host

Once Docker is running on the Azure VM, container networking behaves exactly as it does anywhere else — the docker0 bridge handles container-to-container traffic on the host, and published ports (-p 80:80) are what Azure’s Network Security Group rules need to allow through externally. It’s a common point of confusion: opening a port in the NSG doesn’t automatically mean a container is listening on it — you still need -p (or a Compose ports: entry) to actually bind the container’s port to the host.

Running a Real Workload

docker run -d --name nginx-demo -p 80:80 --restart unless-stopped nginx:latest

Visit http://20.185.44.112 in a browser — you should see the default Nginx welcome page.

Monitoring the Host

docker stats --no-stream

Expected output:

CONTAINER ID   NAME          CPU %   MEM USAGE / LIMIT   MEM %   NET I/O
a1b2c3d4e5f6   nginx-demo    0.00%   2.4MiB / 1.91GiB    0.12%   1.2kB / 0B

For anything beyond ad-hoc checks, install cadvisor or point Azure Monitor’s VM insights at the host for CPU, memory, and disk metrics over time.

Deploying with Docker Compose on the Azure VM

Most real workloads involve more than a single container, and Compose is usually the fastest way to define them. Install the Compose plugin (already included if you used the get-docker.sh convenience script above) and define a stack:

# docker-compose.yml
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    restart: unless-stopped
    depends_on:
      - api

  api:
    image: myregistry.example.com/api:1.0.0
    environment:
      - DATABASE_URL=postgresql://appuser:apppass@db:5432/appdb
    restart: unless-stopped

  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=appdb
      - POSTGRES_USER=appuser
      - POSTGRES_PASSWORD=apppass
    restart: unless-stopped

volumes:
  db-data:

docker compose up -d

Expected output:

[+] Running 4/4
 ✔ Network azureuser_default   Created
 ✔ Container azureuser-db-1    Started
 ✔ Container azureuser-api-1   Started
 ✔ Container azureuser-web-1   Started

Using an Azure Load Balancer for High Availability

A single VM is a single point of failure. For anything beyond a dev/test environment, put an Azure Load Balancer or Application Gateway in front of two or more identically configured Docker hosts, using a Virtual Machine Scale Set (VMSS) so Azure can add or remove instances automatically based on load:

az vmss create \
  --resource-group docker-rg \
  --name docker-vmss \
  --image Ubuntu2404 \
  --custom-data cloud-init-docker.yml \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --instance-count 2 \
  --lb-sku Standard \
  --public-ip-per-vm false

Each instance in the scale set boots with the same cloud-init script, so Docker and your container startup logic come up identically on every node.

Understanding Azure’s Networking Layers

It helps to keep Azure’s network layers distinct in your head, since they each control a different thing:

• Virtual Network (VNet) and Subnets — define the private IP address space the VM lives in.
• Network Security Group (NSG) — the stateful firewall controlling inbound/outbound traffic to the VM’s network interface; this is what az vm open-port modifies.
• Docker’s own bridge network — entirely internal to the VM, invisible to Azure; controls how containers talk to each other and to the host.
• Published ports (-p) — the bridge between the two; a container port isn’t reachable from the VNet or the internet until it’s published to the host, and the host port isn’t reachable externally until the NSG allows it.

Missing any one of these three layers is the most common reason a “working” container is unreachable from outside the VM.

Best Practices

1. Never expose the Docker API without TLS. An unauthenticated Docker socket over the network is a full remote-root vulnerability.
2. Use Azure Network Security Groups as a second layer on top of TLS — restrict port 2376 to known IP ranges rather than 0.0.0.0/0.
3. Enable automatic OS patching via Azure’s VM guest patching settings, or handle it yourself with unattended-upgrades.
4. Use a managed disk for /var/lib/docker if you expect meaningful image/container storage growth — resizing the OS disk later is more disruptive.
5. Tag resources (--tags env=prod team=platform) from day one; cleanup and cost attribution get painful otherwise.
6. Consider Azure Container Instances or AKS instead of a raw VM if you don’t specifically need daemon-level control — a VM is the right choice when you need custom daemon config, privileged containers, or GPU passthrough.

Troubleshooting

• VM creation fails with quota errors — check az vm list-usage --location eastus --output table for your subscription’s vCPU quota.
• Can’t SSH in — confirm the NSG allows port 22 from your IP, and that you’re using the correct username (azureuser by default in the example above).
• docker run hello-world hangs — check systemctl status docker on the VM; cloud-init logs at /var/log/cloud-init-output.log will show if the install script failed.
• Remote TLS connection refused from laptop — confirm port 2376 is open in the NSG and that daemon.json was loaded correctly (sudo systemctl status docker will show a parse error if the JSON is malformed).

Summary

Standing up a Docker host on Azure is a matter of provisioning a VM (via cloud-init for a repeatable setup), opening the right ports, and — if remote access is needed — securing the Docker API with TLS certificates rather than leaving it open. From there, container networking, storage, and monitoring on Azure behave exactly like they would on any Linux Docker host; the cloud-specific work is really just the provisioning and network security layer around it.

References

• Azure CLI documentation: https://learn.microsoft.com/en-us/cli/azure/
• Docker Engine installation guide: https://docs.docker.com/engine/install/ubuntu/
• Docker Engine API security (TLS): https://docs.docker.com/engine/security/protect-access/
• Azure Virtual Machines documentation: https://learn.microsoft.com/en-us/azure/virtual-machines/

The post How to Start a Docker Host on Microsoft Azure: Complete Deployment and Configuration Guide appeared first on Abdul Wahab Junaid.