Private corporate batches, live online cohorts and 1-on-1 mentoring in container images, runtimes and registries from kernel primitives to production workflow — 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 from the kernel up — namespaces, cgroups and capabilities before the first docker run — then image internals and layer anatomy, Dockerfile practice including multi-stage builds, volumes and the six network drivers, registry workflows across Docker Hub, Artifactory, Nexus, ECR and ACR, and the runtime comparison between dockerd, containerd, CRI-O and runc. Sessions are demonstrated live against running daemons, and include the monitoring and troubleshooting work that container problems actually require.
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 that means a trainer who has run it in production — container images, runtimes and registries from kernel primitives to production workflow — 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 batchDocker is a platform for building, shipping and running applications inside containers. A container is not a lightweight virtual machine — it is an ordinary Linux process, isolated by kernel features that already existed: namespaces partition what a process can see, cgroups limit what it can consume, and capabilities restrict what it is permitted to do. Docker packages those primitives behind a workflow that a developer can use without knowing they are there.
The artefact at the centre of that workflow is the image: a stack of read-only filesystem layers plus metadata describing how to start a process. Because layers are content-addressed and cached, rebuilding an image after a small change is fast, and because the image includes its dependencies, the thing tested is the thing deployed. Registries — Docker Hub, Artifactory, Nexus, ECR, ACR — move those images between build and runtime.
Around that core sit the pieces production needs: volumes and bind mounts for state, six network drivers for connectivity, Compose for multi-container definitions, and the runtime layer beneath Docker itself — dockerd, containerd, CRI-O and runc — which matters increasingly as Kubernetes clusters use containerd directly. Understanding where Docker ends and the runtime begins is what makes container problems debuggable.
Containers stopped being a differentiator and became the default packaging format for server-side software. CI systems build images, registries store them, and orchestrators run them — so container literacy is now assumed across development, platform and operations roles rather than being a specialism.
What has changed is the depth expected. Writing a Dockerfile that works is straightforward; writing one that produces a small, reproducible, non-root image with sensible layer caching and a multi-stage build is a different skill, and it is the one that shows up in image-scanning reports and cloud bills. Equally, teams increasingly need to reason about the runtime layer, because Kubernetes talks to containerd rather than to Docker, and the distinction surfaces the moment something misbehaves.
Docker also remains the entry point to everything above it. Kubernetes, service meshes and CI pipelines all assume container fluency, so weak fundamentals here produce confusion that compounds later.
The kernel features Docker assembles, before any Docker command is run. Namespaces, cgroups, capabilities and the layered filesystem — the mental model that makes everything later obvious instead of magical.
Topics: Namespaces · cgroups · Capabilities · Boot, root, user and app filesystems · How containers actually work · Containers vs virtual machines
The pieces of the platform and how a command travels through them. Engine, registry, image and container, the client-daemon split, and the overall workflow — plus an honest look at the alternatives.
Topics: Docker Engine · Docker Registry · Images and containers · Docker architecture · Docker workflow · Alternatives to Docker
Getting a working environment on Linux and Windows, configuring the daemon, and the container lifecycle commands — including the differences that trip people up in production.
Topics: Installing on CentOS, Ubuntu and Windows Server · Configuring the daemon · Create, start, stop, restart, pause, remove · docker stop vs docker kill · docker pause vs unpause · Container naming
The commands real work depends on, and the PID 1 problem that explains a surprising number of container bugs. exec, attach, detach, cp, diff, rename, inspect, update and wait.
Topics: Why PID 1 matters · docker run in depth · exec, attach and detaching · Copying files with docker cp · docker diff and inspect · Port mappings · docker update and docker wait
Seeing what containers and the daemon are doing. Container logs, live resource statistics, running processes, and daemon-level events, logging and configuration.
Topics: Fetching container logs · Live resource statistics · Container process inspection · Real-time daemon events · dockerd troubleshooting · Daemon logging and configuration
State in a system built around disposable processes. The three mount types, when each is correct, and the failure modes that follow from choosing wrongly.
Topics: Storage overview · Why volumes exist · Volume types · Volume mounts · Bind mounts · tmpfs mounts · Troubleshooting volume problems
Six drivers and the reasoning behind each. Bridge for the default case, overlay for multi-host, host for performance, IPvlan and macvlan for network integration, and none for isolation.
Topics: Networking overview · Bridge networks · Overlay networks · Host networking · IPvlan networks · Macvlan networks · Disabling networking · Daemon and container network configuration
The artefact at the centre of everything. Image anatomy and layer behaviour, building from a running container versus from a Dockerfile, Dockerfile practice, multi-stage builds, and creating a base image.
Topics: Image anatomy and layers · Building from an existing container · Building from a Dockerfile · Image history and listing · Dockerfile in depth · Dockerfile best practices · Multi-stage builds · Creating a base image
Moving images between build and runtime. Registry options compared, tagging strategy, and the export/import versus save/load distinction that confuses almost everyone the first time.
Topics: Docker registry and Docker Hub · JFrog Artifactory · Sonatype Nexus · AWS ECR · Azure Container Registry · Tagging strategy · export vs save, import vs load · Push and pull workflows
Beyond single containers. Docker Compose for multi-container definitions, Docker Desktop versus Engine, then the runtime layer — containerd, CRI-O, runc — and Swarm, with the reasoning for why Kubernetes bypasses Docker entirely.
Topics: Docker Desktop installation and configuration · Docker Desktop vs Docker Engine · Docker Compose · Multi-container applications · containerd · dockerd vs containerd vs CRI-O vs runc · Docker Swarm
We rebuild the agenda around the tools you actually run.
Request a custom agendaAssemble an isolated process using namespaces, cgroups and a chroot, then compare it to what Docker produces.
Take a bloated application image and rebuild it with multi-stage builds, correct layer ordering and a non-root user.
Run a database with a named volume, destroy and recreate the container, and prove the data survived.
Connect containers on separate hosts with an overlay network, then compare latency and isolation against host networking.
Build once, then promote a tagged image through development, staging and production registries with an auditable trail.
Define a multi-tier application with Compose, then run the same workload directly on containerd and document what changed.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| 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 advisorDelivered onsite at your premises or live online in your timezone.
Prefer to call or email?
More ways to reach us on the contact page.