Private corporate batches, live online cohorts and 1-on-1 mentoring in native Docker clustering — Raft managers, services, overlay networking, routing mesh and rolling updates — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Docker Swarm around the mechanics that decide whether a cluster survives a bad day rather than around the tutorial path: Raft quorum arithmetic and what actually happens when managers are lost, the difference between the ingress routing mesh and a service virtual IP, how VXLAN overlay traffic and IPVS load balancing behave under partial failure, and rolling update policy including monitoring windows, failure actions and automatic rollback. Sessions cover stack deployment from Compose v3, secrets and configs distributed through the Raft log, placement constraints and node labels, backup and restore of the Raft store, and an evidence-based comparison against Kubernetes so a team can decide where to stay and where to move.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Docker Swarm that means a trainer who has run it in production — native Docker clustering — Raft managers, services, overlay networking, routing mesh and rolling updates — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Docker Swarm batchDocker Swarm is the clustering and orchestration mode built into the Docker Engine itself. A single command, docker swarm init, promotes an ordinary engine into a manager; other engines join as managers or workers using a join token. Manager nodes maintain the cluster's desired state in a Raft consensus log, so an odd number of managers survives the loss of a minority, while worker nodes simply run tasks. There is no separate control plane to install, no etcd to operate and no additional agent — the orchestrator is the same binary that runs the containers.
The unit of work is the service rather than the container. A service declares an image, a replica count or global mode, published ports, networks, secrets, constraints and an update policy, and the orchestrator reconciles reality against that declaration: it schedules tasks, replaces failed ones and rebalances when nodes appear. Traffic reaches those tasks through two mechanisms that are easy to confuse — an internal virtual IP with DNS-based service discovery on an overlay network, and the ingress routing mesh, which publishes a port on every node in the cluster and load-balances inbound connections through IPVS to healthy tasks wherever they happen to be running.
The rest of the model is deliberately small. Overlay networks carry east-west traffic over VXLAN with optional IPsec encryption; secrets and configs are distributed through the Raft log and mounted into containers as in-memory files rather than environment variables; placement constraints, preferences and node labels control scheduling; and rolling updates are governed by parallelism, delay, failure action, monitoring window and automatic rollback. A Compose file at version 3 or above deploys as a stack, which is why teams with existing Compose definitions can reach a working cluster in an afternoon.
Kubernetes won the general case, and pretending otherwise would be dishonest. What Docker Swarm retains is a specific and durable niche: clusters small enough that the operational cost of Kubernetes exceeds its benefit. Edge sites, retail and manufacturing locations, single-tenant customer deployments, internal platforms with a handful of services, and teams with real Compose investment and no platform engineering group all fit that description, and for them Swarm's entire surface — a few dozen commands and one Compose file — is the point.
There is also a large installed base. Swarm estates built between 2016 and 2020 are still running, still carrying production traffic, and increasingly maintained by engineers who never chose them. Those teams need two things: the ability to operate what they have safely, and a clear-eyed assessment of whether and how to migrate. Both are engineering questions, not opinions, and both need someone who understands the Raft quorum behaviour, the routing mesh, and where Swarm's scheduling model genuinely runs out.
Swarm is also the fastest honest way to teach orchestration concepts. Desired state, reconciliation, service discovery, rolling updates and quorum are identical ideas in Kubernetes; learning them without also learning kubelet, CNI, CRI and six API groups at the same time is often the shorter route to competence.
The problem before the tool. Why a single Docker host stops being enough, what an orchestrator has to provide, and how Docker Swarm answers that with no components beyond the engine you already run. An honest positioning against Kubernetes and Nomad, including where Swarm is the wrong answer.
Topics: What orchestration has to solve: scheduling, healing, discovery, updates · Swarm mode versus the legacy standalone Swarm · Managers, workers and the Raft consensus log · Desired state and the reconciliation loop · Docker Swarm compared with Kubernetes and Nomad · Where Swarm's model genuinely runs out · Sizing a cluster: manager count and fault tolerance arithmetic
Standing up a real multi-node cluster and understanding every moving part. Initialisation, join tokens and their rotation, promotion and demotion, node availability states, the ports that must be open between nodes, and the certificate rotation that secures manager-to-manager traffic.
Topics: docker swarm init and advertise addresses · Manager and worker join tokens, and rotating them · Promoting, demoting and removing nodes · Node availability: active, pause and drain · Required ports: 2377, 7946 TCP and UDP, 4789 UDP · Mutual TLS between nodes and automatic certificate rotation · Autolock and protecting the Raft store at rest · Inspecting node state and cluster health
The declarative unit of work. Creating services, replicated versus global mode, the task lifecycle and its states, restart conditions, health checks and how they interact with reconciliation. Then placement: constraints, preferences, node labels, resource reservations and limits.
Topics: docker service create, update, scale, ps and inspect · Replicated versus global services · Task states and the task lifecycle · Restart conditions, delays and maximum attempts · Container health checks and their effect on task replacement · Placement constraints and node labels · Placement preferences and spread strategies · Resource reservations, limits and their scheduling effect · Service logs and troubleshooting a task that will not start
The area that produces the most confusion and the most incidents. How overlay networks carry traffic over VXLAN, how internal DNS and virtual IPs implement east-west discovery, and how the ingress routing mesh publishes a port cluster-wide and balances through IPVS — plus the modes and cases where you want to bypass it.
Topics: Overlay networks and VXLAN encapsulation · Encrypted overlays with IPsec and their cost · The ingress network and the routing mesh · IPVS load balancing and how to inspect it · Virtual IP versus DNS round-robin endpoint modes · Publishing ports: ingress mode versus host mode · Attachable overlays for standalone containers · Segmenting stacks across separate overlay networks · Diagnosing cross-node connectivity failures
Deploying whole applications rather than individual services. Compose v3 and the deploy key, stack lifecycle commands, and the differences between Compose on one host and a stack on a cluster. Then secrets and configs distributed through the Raft log, and the hard question of persistent state in a cluster with no built-in storage layer.
Topics: Compose file version 3 and the deploy section · docker stack deploy, services, ps and rm · What Compose features Swarm ignores, and why · Secrets: creation, rotation and in-memory mounting · Configs for non-sensitive files, and updating them · Environment variables versus mounted secrets · Volumes in a cluster: local volumes, volume drivers and their limits · Strategies for stateful services: pinning, external storage, or keeping state out
Changing a running system safely. Update parallelism, delay, order, failure action and the monitoring window that decides whether an update is judged healthy; automatic and manual rollback; then the operational work — draining nodes, upgrading engines, backing up and restoring the Raft store, and recovering a cluster that has lost quorum.
Topics: Update configuration: parallelism, delay, order and max failure ratio · Monitoring period and how failure is detected · Rollback configuration and automatic rollback · start-first versus stop-first update order · Draining nodes for maintenance and returning them · Rolling engine upgrades across the cluster · Backing up and restoring /var/lib/docker/swarm · Recovering from lost quorum with force-new-cluster · Common failure signatures and how to read them
What it takes to run Swarm as a supported platform, and how to decide whether to keep doing so. Logging and metrics collection across a cluster, edge routing with an external proxy, image supply chain, and then a structured comparison with Kubernetes that produces a decision rather than an opinion.
Topics: Cluster logging: drivers, aggregation and per-service configuration · Metrics with Prometheus, cAdvisor and node exporters · Edge routing with Traefik or NGINX in front of the routing mesh · TLS termination and certificate management at the edge · Registry access, image pinning by digest and pull credentials · Node hardening and limiting the Docker socket · Swarm compared with Kubernetes: scheduling, storage, ecosystem, hiring · Mapping Swarm objects to Kubernetes equivalents · Migration strategies: parallel run, service-by-service, or stay
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a three-manager cluster, kill managers one at a time, observe exactly where the cluster stops accepting changes, then recover it from a Raft backup.
Publish a single-replica service, then answer requests from a node that runs no task for it, and trace the path through the ingress network and IPVS.
Take a real Compose application, add a deploy section, mount its credentials as Swarm secrets, and deploy it to the cluster as a versioned stack.
Configure update parallelism, delay and monitoring window, ship a deliberately broken image, and let automatic rollback restore service.
Drain nodes one at a time, upgrade the engine, return them to the cluster and verify no request was lost throughout.
Run a production-shaped stack on a hardened cluster with logging, metrics and edge routing, then produce a costed comparison against the Kubernetes equivalent.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.