Introduction to Docker Swarm and Docker in Docker DinD: Docker Swarm is Docker's native solution for orchestration and clustering, ideal for deploying and scaling containerized applications across multiple hosts. In this article we explain how to reproduce a multi-node Swarm cluster locally using Docker in Docker DinD, to test the ingress routing mesh, service replication and load balancing, and how this integrates into custom software projects and custom applications developed by Q2BSTUDIO.
Prerequisites: basic knowledge of Docker containers, familiarity with docker run, docker build and docker-compose, and notions about image, volume and network management. These concepts are key to offering custom software solutions and aws and azure cloud services within an artificial intelligence and cybersecurity strategy.
What problem we solve: when running a service with multiple replicas in Docker Swarm and accessing it from localhost, traffic usually ends up on a single replica due to how the routing mesh works at the node level. This can be confusing when testing load balancing. To validate that the mesh distributes correctly between different nodes, it is recommended to create a small Swarm cluster with two DinD nodes on the same machine.
Summarized steps to create the DinD environment: create a Docker network for the DinD containers, start two docker:dind containers as node1 and node2, initialize Swarm on node1 with docker swarm init and an advertise address, obtain the join token and join node2 with docker swarm join. Each DinD container runs its own isolated Docker daemon, allowing you to simulate multiple hosts without needing additional VMs.
Useful commands, run on the host: docker network create --driver bridge dind-net, docker run --privileged -d -p 8080:8080 --name node1 --hostname node1 --network dind-net docker:dind, docker run -d --privileged --name node2 --hostname node2 --network dind-net docker:dind. Connect to node1: docker exec -it node1 sh, inside: docker swarm init --advertise-addr 172.23.0.2:2377. On node2: docker exec -it node2 sh and then use docker swarm join with the token provided by node1.
Sharing images between host and DinD: export images from the host with docker save imagen -o archivo.tar, copy to the container with docker cp archivo.tar node1:/archivo.tar, load it inside the container with docker load -i /archivo.tar. Repeat for node2. This allows deploying private images in the DinD cluster without needing a public registry.
Example docker-compose to deploy on Swarm, use overlay networks and ingress mode for the published port: version: 3.8 services: demo-app: image: docker-demo:latest deploy: replicas: 2 restart_policy: condition: on-failure networks: - app-network nginx: image: nginx:latest ports: - target: 80 published: 8080 protocol: tcp mode: ingress volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro depends_on: - demo-app networks: - app-network networks: app-network: driver: overlay. This format prevents the published port from being restricted to a single node and allows the routing mesh to expose the service on all nodes.
Configure nginx as a simple reverse proxy: upstream demo_app server demo-app:8080; in the server section configure location / proxy_pass https://demo_app; and forward the Host, X-Real-IP, X-Forwarded-For and X-Forwarded-Proto headers. This helps to instrument logs and to check which replica each request comes from when the mesh is working correctly.
Verification and diagnostics: use docker info | grep -i swarm to check swarm mode, docker node ls to list nodes, docker stack deploy -c docker-compose.yml demo-app to deploy the stack, docker stack ls to view stacks, docker stack services demo-app to view services, docker stack ps demo-app to list tasks. If all replicas end up on the same node, review the network configuration and the port publishing mode.
Why all traffic reaches a single replica: when accessing via localhost, routing will remain at the node level and IPVS load balancing may prefer a single local task. With a real multi-node cluster or with DinD and correctly configured overlay networks, ingress mode and the routing mesh distribute connections between nodes and replicas.
DinD limitations: DinD is an excellent tool for testing and development, but it does not 100 percent reproduce the complexity of a real multi-node cluster in production, especially in terms of networking, performance and isolation. For production deployments, real environments on aws and azure cloud or managed clusters are recommended.
Environment cleanup: docker stack rm demo-app to remove the stack, docker stop $(docker ps -q) to stop containers, docker rm $(docker ps -aq) to remove containers, docker network rm dind-net to remove the DinD network. Always verify before running mass commands in environments with valuable data.
Entreprise applications and use cases: this workflow serves to validate deployments of custom applications and custom software that require load balancing and high availability. At Q2BSTUDIO we use similar methodologies to test microservices, CI/CD pipelines and secure deployments that incorporate cybersecurity and compliance practices.
Q2BSTUDIO services and competencies: we are a software development company specialized in custom applications, custom software and artificial intelligence applied to business. We offer aws and azure cloud services, business intelligence services, power bi solutions, AI agents and AI projects for companies. We also provide cybersecurity consulting to protect deployments and ensure operational continuity.
Why choose Q2BSTUDIO: we combine experience in custom application development with capabilities in artificial intelligence and cybersecurity, integrating aws and azure cloud services and analysis tools such as power bi to offer end-to-end solutions. We can help design Docker Swarm or Kubernetes architectures, optimize pipelines and apply AI agents for automation and process improvement.
Summary and recommendation: Docker Swarm is a simple and native option for orchestration in small and medium projects. For local testing of routing mesh and load balancing between replicas, using DinD is practical and reproducible. For larger-scale projects or complex enterprise requirements, consider Kubernetes or managed clusters on aws and azure cloud. If you need help implementing these solutions or developing custom software with artificial intelligence and cybersecurity, contact Q2BSTUDIO for specialized consulting.
