Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs Docker 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 build outward: BuildKit's cache model and the instruction ordering that decides build time, multi-stage builds that strip a toolchain out of the runtime, multi-architecture builds with buildx, non-root users and minimal base images, and registries used as a promotion boundary with scanning and signing attached. Run-time behaviour is taught by breaking things live — PID 1 that ignores SIGTERM, a JVM that misreads a cgroup memory limit, a volume that hides a directory, a network that resolves nothing — so container failures become diagnosable rather than mysterious.
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 built for Bangalore delivery pipelines — BuildKit caching, multi-arch, base image governance and runtime behaviour — 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.
Onsite delivery is at your own office. Docker sessions in Bangalore commonly run in Whitefield, along the Outer Ring Road between Bellandur and Marathahalli, in Electronic City or at Manyata Tech Park, one site per day so peak-hour travel does not eat into lab time. You provide the room, a screen and network access; we ask in advance about proxy configuration, certificate inspection and Docker Hub rate limits on your build agents, because that is the single most common cause of a slow first morning in this city. Attendees can work on Docker Desktop, a Linux VM or a cloud instance, and we support both x86 and Apple Silicon laptops with the same labs. Sessions are scheduled in IST (UTC+5:30) and shaped around your release calendar. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one, and travel within Bangalore is included in the quote.
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 toolchain for building, distributing and running containers, and most of the value engineers get from it is decided at build time rather than run time. A Dockerfile is compiled by BuildKit into a graph of steps whose results are cached by content, which means the ordering of instructions is a performance decision: put the line that changes on every commit above the dependency install and every build reinstalls dependencies. Multi-stage builds separate the toolchain that compiles an artifact from the runtime that ships it, which is how a build image of two gigabytes becomes a runtime image of eighty megabytes.
The image itself is a stack of content-addressed layers plus a configuration blob describing the entrypoint, environment, user, exposed ports and healthcheck. Because it is content-addressed, the same image can be verified, signed and promoted between environments without rebuilding — the artifact that passed testing is bit-for-bit the artifact that reaches production. Registries such as Docker Hub, Artifactory, Nexus, ECR and ACR move those images, and a pull-through cache in front of a public registry is what keeps a build farm working when the upstream is slow or rate limited.
At run time, a container is an ordinary process with a restricted view: namespaces partition what it can see, cgroups cap what it can consume, capabilities and seccomp limit what it may ask the kernel to do. That has consequences people meet the hard way — the process runs as PID 1 and must handle signals or shutdown will hang; a memory limit is enforced by the kernel and the runtime inside must be told about it; storage is ephemeral unless a volume says otherwise; and stdout, not a log file, is where output belongs. Understanding where Docker ends and containerd, runc and the kernel begin is what makes those failures debuggable rather than mysterious.
Containers stopped being a differentiator and became a baseline, which paradoxically raised the skill bar. When only pioneers used Docker, a working image was an achievement. Now every deployment target — Kubernetes, ECS, Cloud Run, a serverless container platform — assumes an image exists, so the interesting questions have moved downstream: how large is it, how long does it take to build, what is inside it, who signed it, and does it behave when the orchestrator sends SIGTERM.
Supply chain expectations pushed hardest. A base image is now something an organisation governs rather than something a developer picks, because every vulnerability in it multiplies across hundreds of services; scanning, provenance, signing and a bill of materials have gone from optional to contractual in regulated sectors. Build performance became the second pressure, since a build that takes twenty minutes and cannot use a cache is paid for on every commit by every engineer.
The third change is architectural. Fleets are increasingly mixed between x86 and ARM — laptops on Apple Silicon, cost-driven migration to ARM instances in the cloud — and images that were never built for more than one platform break in ways that are hard to attribute. So the skill in demand is not 'can you write a Dockerfile' but 'can you produce a small, reproducible, scannable, multi-architecture image that behaves correctly under an orchestrator', which is a genuinely different capability.
Kernel primitives before tooling. Namespaces, cgroups, capabilities and seccomp demonstrated directly on a host, then the client, daemon, containerd and runc layers — so it is clear which component is responsible when something fails.
Topics: Namespaces: PID, mount, network, UTS, IPC and user · cgroups and resource limits enforced by the kernel · Capabilities, seccomp and the default profile · docker CLI, dockerd, containerd, runc and shims · Containers versus virtual machines, honestly · Where the Kubernetes container runtime interface fits
The build is the part that costs money every day. Dockerfile instructions and how each affects the layer graph, BuildKit's cache model, cache mounts and external cache backends, .dockerignore, and the instruction ordering that turns a ten-minute build into a forty-second one.
Topics: Layers, content addressing and what invalidates a cache entry · Instruction ordering for dependency install versus source copy · BuildKit, cache mounts and remote cache backends · .dockerignore and build context size · ARG versus ENV, and secrets that must not land in a layer · Inspecting history and finding the layer that bloated an image
Producing a runtime image that contains only what runs. Multi-stage builds, choosing between full, slim, Alpine and distroless bases with the trade-offs stated, non-root users, and buildx for building one tag that serves both ARM and x86.
Topics: Multi-stage builds and copying only artifacts forward · Full, slim, Alpine and distroless: real trade-offs including glibc and debugging · Running as non-root and fixing what that breaks · buildx, QEMU emulation and native multi-architecture nodes · Manifest lists and how a client picks a platform · Reproducibility and pinning base image digests
The run-time contract most images get wrong. ENTRYPOINT and CMD, exec form versus shell form, PID 1 and signal handling, graceful shutdown, restart policies, resource limits and how a runtime inside the container discovers them.
Topics: ENTRYPOINT, CMD and the shell-form trap · PID 1, SIGTERM handling and init processes · Graceful shutdown and connection draining · Memory and CPU limits, and OOM behaviour · JVM, Node and Python runtimes reading cgroup limits · Healthchecks, restart policies and readiness
What survives and what does not. The writable layer and its cost, named volumes, bind mounts and tmpfs; volume drivers; permissions between host user and container user; and backup, restore and migration for containers that hold state.
Topics: The container writable layer and copy-on-write cost · Named volumes versus bind mounts versus tmpfs · UID and GID mismatches and permission failures · Mounting over a populated directory and what disappears · Volume drivers and remote storage · Backing up and restoring container data
How containers find and reach each other. Bridge, host, none, macvlan and overlay drivers, port publishing and the NAT path, embedded DNS and service discovery, then Compose for defining a multi-container application with dependencies and profiles.
Topics: Network drivers and when each is the right answer · Port publishing, NAT and why localhost differs inside · Embedded DNS and name resolution between containers · User-defined networks and isolation between stacks · Compose files, dependencies, healthcheck conditions and profiles · Debugging connectivity with exec, nsenter and packet capture
Images as controlled artifacts. Tagging discipline and why latest is not a version, registry authentication, pull-through caches and mirrors for rate-limited or proxied networks, scanning, signing, provenance and promoting an identical digest between environments.
Topics: Tagging strategy, digests and immutability · Private registries: Artifactory, Nexus, ECR, ACR and Harbor · Pull-through caching and mirrors behind a corporate proxy · Vulnerability scanning and triaging results that matter · Base image governance and rebuild cadence · Signing, attestation and a software bill of materials · Promotion by digest instead of rebuild
Hardening and diagnosis, then the handover. Least-privilege containers, read-only filesystems, secrets handling, and a systematic debugging method; finally what changes when containers move under Kubernetes and which Docker habits stop working there.
Topics: Dropping capabilities, read-only root filesystem and no-new-privileges · Why the Docker socket is a privilege boundary · Secrets at build and run time, and what leaks into a layer · A systematic method: logs, inspect, exec, events, stats · Resource pressure, disk usage and pruning safely · What Kubernetes changes: no daemon, no Compose, probes and requests · Migrating a Compose stack to Kubernetes manifests
We rebuild the agenda around the tools you actually run.
Request a custom agendaProfile a real build, reorder instructions for cache behaviour, add BuildKit cache mounts and a proper .dockerignore, and record the before and after numbers.
Convert a single-stage build to multi-stage, choose a minimal base with the trade-offs stated, run as non-root, and verify the service still starts and passes its healthcheck.
Build and push a manifest list with buildx covering arm64 and amd64, then verify the correct platform is selected from an Apple Silicon laptop and an x86 host.
Take a service that hangs on shutdown and misreads its memory limit, fix PID 1 signal handling and runtime limit detection, and prove it under a rolling restart.
Diagnose a container that exits immediately, one that starts but cannot resolve a dependency, and one that loses its data on restart — using only logs, inspect, exec and events.
Govern a base image, build through a mirrored registry, scan and sign the result, then promote the identical digest across three environments with no rebuild.
Most Docker work in Bangalore is retrofitting rather than greenfield. The dominant task across the GCC engineering sites along the Outer Ring Road, in Whitefield and at Manyata Tech Park is taking an application that was designed for a virtual machine — a Java or .NET service with a startup script, a configuration file mounted from somewhere, and an assumption that it owns the host — and making it behave correctly as a container. That is where the difficult sessions go: PID 1 and signal handling so a rolling deploy does not hang, filesystem and permission assumptions that break under a non-root user, memory limits interacting badly with a JVM that reads the host's total RAM, and logs written to a file that nobody will ever collect.
Two Bangalore-specific constraints show up in almost every batch. The first is egress: corporate laptops and build agents in the larger engineering sites here often reach the internet through a proxy with certificate inspection, and Docker Hub rate limits combine with that to make the first pull of the day an event — so registry mirroring and pull-through caches stop being an optimisation and become a prerequisite. The second is architecture. Engineers develop on Apple Silicon laptops while production runs on x86, or the company is moving workloads to Graviton instances in the Mumbai region to reduce cost, and an image that was never built multi-arch fails in a way that looks like anything but an architecture problem. Bangalore job specs reflect all of this: container questions in interviews here are increasingly about image size, build cache behaviour, CVE remediation on base images and debugging a container that will not start, rather than about what a container is.
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.
Good discussion, helped us to understand different tools in SRE.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
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.
| 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.